ARM CONFIG_OF_CONTROL status
Hi,
can you please update me about current state of CONFIG_OF_CONTROL for ARM? Are there any other archs/boards which will use this option? Or any other git repo out of mainline u-boot?
Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution.
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Hi,
Quoted 5 lines · Michal Simek
Hi,
can you please update me about current state of
CONFIG_OF_CONTROLfor ARM? Are there any other archs/boards which will use this option?
Or any other git repo out of mainline u-boot?
Quoted 1 line
Exynos is in progress - development is happening in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).
Quoted 5 lines
Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution.
U-Boot doesn't yet have a device model which would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.
There are other limitations also - for example USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.
Regards,
Simon
Quoted 11 lines
Thanks,
Michal--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux -
http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Hi Simon,
Quoted 6 lines · Simon Glass
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]>> wrote:
Hi,
Quoted 7 lines
can you please update me about current state of
CONFIG_OF_CONTROLfor ARM? Are there any other archs/boards which will use this option?Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Quoted 9 lines
Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution.
U-Boot doesn't yet have a device model which would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.
There are other limitations also - for example USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I ended with this code fragment which could be broadly used by other drivers.
int offset = 0;
do {
offset = fdt_node_offset_by_compatible(gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" );
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);
if (reg)
ret |= xilinx_emaclite_initialize(bis, reg, txpp, rxpp);
} while (offset != -1);What do you think? This code is in platform file.
Also I have tested code around aliases which parse DTS aliases list for console initialization and I have also get it work for !CONSOLE_SERIAL_MULTI case.
What was the reason to use compat_names table in fdtdec.c file?
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Hi Michal,
Quoted 48 lines · Michal Simek
Hi Simon,
Quoted 12 lines · Simon Glass
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <[email protected] <mailto:
monstr at monstr.eu>> wrote:Hi,
can you please update me about current state of
CONFIG_OF_CONTROLfor
ARM?
Are there any other archs/boards which will use this option?Quoted 6 lines
Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Quoted 10 lines
Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best
solution.U-Boot doesn't yet have a device model which would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.
Quoted 6 lines
There are other limitations also - for example USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Quoted 9 lines
Firstly I have tried to change emaclite ethernet initialization and I ended with this code fragment which could be
broadly used by other drivers.int offset = 0; do { offset = fdt_node_offset_by_compatible(**gd->fdt_blob,offset, "xlnx,xps-ethernetlite-1.00.a" );
You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->fdt_blob, offset)
Quoted 6 lines
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset,
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset,
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);Maybe fdtdec_get_addr()
Quoted 7 lines
if (reg) ret |= xilinx_emaclite_initialize(**bis, reg, txpp, rxpp); } while (offset != -1);What do you think? This code is in platform file.
Seems reasonable to me.
Quoted 5 lines
Also I have tested code around aliases which parse DTS aliases list for console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Great - I did send a patch to the list for fdt serial, but haven't really got back to it.
Quoted 2 lines
What was the reason to use
compat_namestable infdtdec.cfile?
Just so there is a simple register of everything that uses fdt in U-Boot - the enum is used by driver code. If we end up with a lot of support then we might reconsider one day
Regards,
Simon
Quoted 13 lines
Thanks,
Michal--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux -
http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Hi Simon,
Quoted 50 lines · Simon Glass
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]>> wrote:
Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> wrote:
Hi,
can you please update me about current state of
CONFIG_OF_CONTROLfor ARM? Are there any other archs/boards which will use this option?Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution.
U-Boot doesn't yet have a device model which would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.
There are other limitations also - for example USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I ended with this code fragment which could be broadly used by other drivers.
int offset = 0;
do {
offset =fdt_node_offset_by_compatible(__gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" );
Quoted 8 lines
You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->fdt_blob, offset)
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);Maybe
fdtdec_get_addr()
yeah right.
do {
offset = fdt_node_offset_by_compatible(gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" );
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg");
if (reg != FDT_ADDR_T_NONE)
ret |= xilinx_emaclite_initialize(bis, reg, txpp, rxpp);
} while (offset != -1);Quoted 9 lines
if (reg) ret |= xilinx_emaclite_initialize(__bis, reg, txpp, rxpp); } while (offset != -1); What do you think? This code is in platform file.Seems reasonable to me.
ok.
Quoted 7 lines
Also I have tested code around aliases which parse DTS aliases list for console initialization and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Great - I did send a patch to the list for fdt serial, but haven't really got back to it.
Can you give me link to it or just subject?
Quoted 6 lines
What was the reason to use
compat_namestable infdtdec.cfile?Just so there is a simple register of everything that uses fdt in U-Boot - the enum is used by driver code. If we end up with a lot of support then we might reconsider one day
Is it requirement that all new drivers should extend this table? Because from my point of view is just this not necessary to do. Based on function above this is enough for drivers to be probed.
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Hi Michal,
Quoted 129 lines · Michal Simek
Hi Simon,
Quoted 76 lines · Simon Glass
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <[email protected] <mailto:
monstr at monstr.eu>> wrote:Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi, On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <[email protected]<mailto:monstr at monstr.eu> <mailto:monstr at monstr.eu <mailto:[email protected]>>> wrote:
Hi,
can you please update me about current state of
CONFIG_OF_CONTROLfor ARM?
Are there any other archs/boards which will use this option?Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium
tree and being upstreamed in chunks (although no fdt patches have been sent yet).ok.
Has someone tried to look for devices based on compatible
property?
I see that in usb driver it is based on aliases which is not
the best solution.U-Boot doesn't yet have a device model which would allow this in
the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.There are other limitations also - for example USB supports only a
single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I
ended with this code fragment which could be
broadly used by other drivers.int offset = 0; do { offset = fdt_node_offset_by_compatible(**__gd->fdt_blob,offset, "xlnx,xps-ethernetlite-1.00.a" );
You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->**fdt_blob, offset)
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg",Quoted 5 lines
0);
Maybe
fdtdec_get_addr()yeah right.
do { offset = fdt_node_offset_by_compatible(**gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" ); u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg"); if (reg != FDT_ADDR_T_NONE) ret |= xilinx_emaclite_initialize(**bis, reg, txpp, rxpp); } while (offset != -1);Quoted 11 lines
if (reg) ret |= xilinx_emaclite_initialize(__**bis,reg, txpp, rxpp);
} while (offset != -1);What do you think? This code is in platform file.
Seems reasonable to me.
ok.
Quoted 6 lines
Also I have tested code around aliases which parse DTS aliases list
for console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Quoted 6 lines
Quoted 3 lines
Great - I did send a patch to the list for fdt serial, but haven't really got back to it.
Can you give me link to it or just subject?
WIP: fdt: Add serial port controlled by device tree
These are the related commits in the Chromium tree. I will get to upstreaming these at some point.
1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present 2006b07 gen: fdt: Add serial port controlled by device tree 711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory mapped reg
da92af5 gen: Fix a compiler warning in serial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent' option 376c215 lost: gen: fdt: Add serial port controlled by device tree
Quoted 7 lines
Quoted 7 lines
What was the reason to use
compat_namestable infdtdec.cfile?
Quoted 8 lines
Quoted 4 lines
Just so there is a simple register of everything that uses fdt in U-Boot
- the enum is used by driver code. If we end up with a lot of support then we might reconsider one dayIs it requirement that all new drivers should extend this table? Because from my point of view is just this not necessary to do. Based on function above this is enough for drivers to be probed.
Fair enough. If you don't want to I don't see why it should be a hard requirement.
Regards,
Simon
Quoted 12 lines
Thanks,
Michal--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux -
http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Quoted 118 lines · Simon Glass
Hi Michal,
On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <monstr at monstr.eu <mailto:[email protected]>> wrote:
Hi Simon, On 06/28/2012 03:10 AM, Simon Glass wrote: Hi Michal, On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> wrote: Hi Simon, On 06/27/2012 03:58 PM, Simon Glass wrote: Hi, On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>> wrote: Hi, can you please update me about current state of CONFIG_OF_CONTROL for ARM? Are there any other archs/boards which will use this option? Or any other git repo out of mainline u-boot? Exynos is in progress - development is happening in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet). ok. Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution. U-Boot doesn't yet have a device model which would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model. There are other limitations also - for example USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else. I have looked at the code and did some tests on Microblaze. Firstly I have tried to change emaclite ethernet initialization and I ended with this code fragment which could be broadly used by other drivers. int offset = 0; do { offset = fdt_node_offset_by_compatible(____gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" ); You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->__fdt_blob, offset) u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg", 0); Maybe fdtdec_get_addr() yeah right. do { offset = fdt_node_offset_by_compatible(__gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" ); u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg"); if (reg != FDT_ADDR_T_NONE) ret |= xilinx_emaclite_initialize(__bis, reg, txpp, rxpp); } while (offset != -1); if (reg) ret |= xilinx_emaclite_initialize(____bis, reg, txpp, rxpp); } while (offset != -1); What do you think? This code is in platform file. Seems reasonable to me. ok. Also I have tested code around aliases which parse DTS aliases list for console initialization and I have also get it work for !CONSOLE_SERIAL_MULTI case. Great - I did send a patch to the list for fdt serial, but haven't really got back to it. Can you give me link to it or just subject?WIP: fdt: Add serial port controlled by device tree
These are the related commits in the Chromium tree. I will get to upstreaming these at some point.
Quoted 9 lines
1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present 2006b07 gen: fdt: Add serial port controlled by device tree
711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory mapped reg da92af5 gen: Fix a compiler warning inserial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent' option 376c215 lost: gen: fdt: Add serial port controlled by device tree
Can you also send me link to Chromium tree?
I am going to send RFC for emaclite driver and cleanup Microblaze port.
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Hi,
Quoted 167 lines · Michal Simek
Quoted 153 lines · Simon Glass
Hi Michal,
On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <[email protected] <mailto:
monstr at monstr.eu>> wrote:Hi Simon,
On 06/28/2012 03:10 AM, Simon Glass wrote:
Hi Michal, On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <[email protected]<mailto:monstr at monstr.eu> <mailto:monstr at monstr.eu <mailto:[email protected]>>> wrote:
Hi Simon, On 06/27/2012 03:58 PM, Simon Glass wrote: Hi, On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:[email protected]<mailto:
monstr at monstr.eu>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>> wrote:Hi,
can you please update me about current state of
CONFIG_OF_CONTROLfor ARM?
Are there any other archs/boards which will use this
option?Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the
Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).ok.
Has someone tried to look for devices based on
compatible property?
I see that in usb driver it is based on aliases which
is not the best solution.U-Boot doesn't yet have a device model which would allow
this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.There are other limitations also - for example USB
supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet
initialization and I ended with this code fragment which could bebroadly used by other drivers. int offset = 0; do { offset = fdt_node_offset_by_compatible(**____gd->fdt_blob,offset, "xlnx,xps-ethernetlite-1.00.a" );
You could check if offset < 0 here, or
!fdtdec_get_is_enabled(gd->__**fdt_blob, offset)u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg = fdtdec_get_int(gd->fdt_blob, offset,"reg", 0);
Maybe
fdtdec_get_addr()yeah right. do { offset = fdt_node_offset_by_compatible(**__gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" ); u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg"); if (reg != FDT_ADDR_T_NONE) ret |= xilinx_emaclite_initialize(__**bis, reg, txpp, rxpp); } while (offset != -1); if (reg) ret |= xilinx_emaclite_initialize(___*
*_bis, reg, txpp, rxpp);} while (offset != -1);
What do you think? This code is in platform file.
Seems reasonable to me.
ok.
Also I have tested code around aliases which parse DTS aliases
list for console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.Great - I did send a patch to the list for fdt serial, but haven't
really got back to it.Can you give me link to it or just subject?
WIP: fdt: Add serial port controlled by device tree
These are the related commits in the Chromium tree. I will get to upstreaming these at some point.
Quoted 12 lines
1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present 2006b07 gen: fdt: Add serial port controlled by device tree 711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory mapped reg
da92af5 gen: Fix a compiler warning inserial_fdt.cab1d572 gen: fdt: silence console in response to device tree 'silent' option
376c215 lost: gen: fdt: Add serial port controlled by device tree
Quoted 2 lines
Can you also send me link to Chromium tree?
Yes this should work:
https://git.chromium.org/git/chromiumos/third_party/u-boot.git
Quoted 1 line
I am going to send RFC for emaclite driver and cleanup Microblaze port.
Great!
Regards,
Simon
Quoted 13 lines
Thanks,
Michal--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux -
http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Quoted 137 lines · Simon Glass
Hi,
On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <monstr at monstr.eu <mailto:[email protected]>> wrote:
On 06/28/2012 07:57 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> wrote:
Hi Simon,
On 06/28/2012 03:10 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>> wrote:
Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>>> wrote:
Hi,
can you please update me about current state of
CONFIG_OF_CONTROLfor ARM? Are there any other archs/boards which will use this option?Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution.
U-Boot doesn't yet have a device model which would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.
There are other limitations also - for example USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I ended with this code fragment which could be broadly used by other drivers.
int offset = 0;
do {
offset =fdt_node_offset_by_compatible(______gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" );You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->____fdt_blob, offset)
u32 rxpp =
fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp =fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg =fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);Maybe
fdtdec_get_addr()yeah right.
do {
offset =fdt_node_offset_by_compatible(____gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" ); u32 rxpp =fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0);
u32 txpp =fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0);
u32 reg =fdtdec_get_addr(gd->fdt_blob, offset, "reg");
if (reg !=FDT_ADDR_T_NONE)ret |=
xilinx_emaclite_initialize(____bis, reg, txpp, rxpp);
} while (offset != -1);if (reg)
ret |=xilinx_emaclite_initialize(______bis, reg, txpp, rxpp);} while (offset != -1);
What do you think? This code is in platform file.
Seems reasonable to me.
ok.
Also I have tested code around aliases which parse DTS aliases list for console initialization and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Great - I did send a patch to the list for fdt serial, but haven't really got back to it.
Can you give me link to it or just subject?
WIP: fdt: Add serial port controlled by device tree
These are the related commits in the Chromium tree. I will get to upstreaming these at some point.
1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present 2006b07 gen: fdt: Add serial port controlled by device tree 711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory mapped reg da92af5 gen: Fix a compiler warning inserial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent' option 376c215 lost: gen: fdt: Add serial port controlled by device tree
Quoted 7 lines
Can you also send me link to Chromium tree?
Yes this should work:
https://git.chromium.org/git/chromiumos/third_party/u-boot.git
Thanks.
I have sent support for Microblaze. Currently without dts because I want to clear this part a little bit.
Tegra is using ./arch/arm/dts/tegra20.dtsi and board/nvidia/dts/tegra2-seaboard.dts and they are composed together in dts/Makefile by calling preprocessor. Microblaze will be totally different case because every Microblaze hw design is different. We can use two main buses (little and big endian) and cpu is also configurable. Based on this for Microblaze is the best solution directly to use dts.
(DTS for Microblaze is also generated directly from design tool).
Anyway - here is the bug message I am getting if I use full dts in board/<name>/dts/microblaze.dts and empty arch/microblaze/dts/microblaze.dtsi
<stdin>:34:3: error: invalid preprocessing directive #address <stdin>:35:3: error: invalid preprocessing directive #size <stdin>:52:4: error: invalid preprocessing directive #address <stdin>:53:4: error: invalid preprocessing directive #cpus <stdin>:54:4: error: invalid preprocessing directive #size <stdin>:155:4: error: invalid preprocessing directive #address <stdin>:156:4: error: invalid preprocessing directive #size <stdin>:160:5: error: invalid preprocessing directive #gpio <stdin>:192:5: error: invalid preprocessing directive #gpio <stdin>:209:5: error: invalid preprocessing directive #gpio <stdin>:241:5: error: invalid preprocessing directive #gpio <stdin>:267:5: error: invalid preprocessing directive #address <stdin>:268:5: error: invalid preprocessing directive #size <stdin>:394:5: error: invalid preprocessing directive #interrupt
This is error for opposite case - empty microblaze.dts and full microblaze.dtsi.
make[1]: Entering directory `/mnt/projects/u-boot/dts'
rc=$( cat /mnt/projects/u-boot/board/petalogix/dts/microblaze.dts | microblaze-unknown-linux-gnu-gcc -E -P -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\" - | { { dtc -R 4 -p 0x1000 -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb on file' ; } 3>&1 ) ; \
exit $rc/bin/sh: line 1: exit: too many arguments
make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'
I have just tried to fix it by introducing new CONFIG option for skipping that preprocessor
part. It will be good for Microblaze (probably there is any smarter solution for SKIP case not to have two cats there). The same situation will happen for Xilinx ppc support and partially for upcoming ARM zynq where
full DTS is generated for unique hw design.
Here is the patch to show you what phase I would like to skip.
dts/Makefile +7 -1
@@ -45,9 +45,15 @@ all: $(obj).depend $(LIB) # the filename. DT_BIN := $(obj)dt.dtb +ifndef CONFIG_DTS_SKIP_PREPROCESSOR +SKIP := $(CPP) -P $(DTS_CPPFLAGS) - +else +SKIP := cat +endif + $(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts rc=$$( \ - cat $< | $(CPP) -P $(DTS_CPPFLAGS) - | \ + cat $< | $(SKIP) |\ { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 2>&1 ; \ echo $$? >&3 ; } | \ grep -v '^DTC: dts->dtb on file' ; \
Thanks for your comments.
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
I have sent support for Microblaze. Currently without dts because I want to clear this part a little bit.
Hi Michal,
looks good, I've been waiting a long time on the FDT support in U-Boot for Microblaze -- great -- PS: see my comment on patch 5 ...
Quoted 4 lines
Tegra is using
./arch/arm/dts/tegra20.dtsiandboard/nvidia/dts/tegra2-seaboard.dtsand they are composed together in dts/Makefile by calling preprocessor. Microblaze will be totally different case because every Microblaze hw design is different.
Yes, that's right. We will never be in the position to define a skeleton or a basic platform configuration.
Quoted 3 lines
We can use two main buses (little and big endian) and cpu is also configurable. Based on this for Microblaze is the best solution directly to use dts. (DTS for Microblaze is also generated directly from design tool).
... directly in the context of a board, not arch/cpu, right?
Quoted 20 lines
Anyway - here is the bug message I am getting if I use full dts in board/<name>/dts/microblaze.dts and empty
arch/microblaze/dts/microblaze.dtsi<stdin>:34:3: error: invalid preprocessing directive #address <stdin>:35:3: error: invalid preprocessing directive #size <stdin>:52:4: error: invalid preprocessing directive #address <stdin>:53:4: error: invalid preprocessing directive #cpus <stdin>:54:4: error: invalid preprocessing directive #size <stdin>:155:4: error: invalid preprocessing directive #address <stdin>:156:4: error: invalid preprocessing directive #size <stdin>:160:5: error: invalid preprocessing directive #gpio <stdin>:192:5: error: invalid preprocessing directive #gpio <stdin>:209:5: error: invalid preprocessing directive #gpio <stdin>:241:5: error: invalid preprocessing directive #gpio <stdin>:267:5: error: invalid preprocessing directive #address <stdin>:268:5: error: invalid preprocessing directive #size <stdin>:394:5: error: invalid preprocessing directive #interrupt
Quoted 1 line
This is error for opposite case - empty
microblaze.dtsand fullmicroblaze.dtsi.
That are CPP errors, because the auto generated xilinx.dts is full of CPP pragma like syntax (#something) that are wrong (invalid).
Quoted 11 lines
make[1]: Entering directory `/mnt/projects/u-boot/dts'
rc=$( cat/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts| microblaze-unknown-linux-gnu-gcc -E(quoted diff) +0
-2-P -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\" - | { { dtc -R 4 -p 0x1000 -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb on file' ; } 3>&1 ) ; \exit $rc
/bin/sh: line 1: exit: too many arguments make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'
Quoted 2 lines
I have just tried to fix it by introducing new CONFIG option for skipping that preprocessor part.
Instead of disable / skipp the CPP step you can hide the auto generated xilinx.dts with a second include stage, for example:
board/microblaze/dts/microblaze.dts looks like:
/include/ ARCH_CPU_DTS
/include/ BOARD_DTS
Right, only two lines. The arch/microblaze/dts/microblaze.dtsi remains
empty as you have said above. Just new is BOARD_DTS -- with the attached patch for dts/Makefile you can copy the auto generated xilinx.dts into the specific board directory and the CPP step substitute the right place to board/microblaze/microblaze-generic/dts/microblaze.dts
I think there are no side effects with other ports like the tegra2.
If you want you can omit the ARCH_CPU_DTS inclusion. The architectural microblaze.dtsi file is empty and (!!) have to be empty, because the DTC will break with an error on multiple "/dts-v1/;" lines!
Here is the patch:
dts/Makefile +0 -0
@@ -36,7 +36,8 @@ $(error Your architecture does not have device tree
support enabled. \
Please define CONFIG_ARCH_DEVICE_TREE))
# We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" +DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
+ -DBOARD_DTS=
\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
all: $(obj).depend $(LIB)
br,
Stephan
Quoted 29 lines
It will be good for Microblaze (probably there is any smarter solution for SKIP case not to have two cats there). The same situation will happen for Xilinx ppc support and partially for upcoming ARM zynq where full DTS is generated for unique hw design.
Here is the patch to show you what phase I would like to skip.
dts/Makefile +7
-1@@ -45,9 +45,15 @@ all: $(obj).depend $(LIB) # the filename. DT_BIN := $(obj)dt.dtb +ifndef CONFIG_DTS_SKIP_PREPROCESSOR +SKIP := $(CPP) -P $(DTS_CPPFLAGS) - +else +SKIP := cat +endif + $(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts rc=$$( \ - cat $< | $(CPP) -P $(DTS_CPPFLAGS) - | \ + cat $< | $(SKIP) |\ { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 2>&1 ; \ echo $$? >&3 ; } | \ grep -v '^DTC: dts->dtb on file' ; \
Quoted 3 lines
Thanks for your comments.
Michal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dts-Makefile-BOARD_DTS.patch
Type: text/x-patch
Size: 606 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120629/d3cde911/attachment.bin>
2012/6/29 Stephan Linz <[email protected]>:
Quoted 18 lines
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
I have sent support for Microblaze. Currently without dts because I want to clear this part a little bit.
Hi Michal,
looks good, I've been waiting a long time on the FDT support in U-Boot for Microblaze -- great -- PS: see my comment on patch 5 ...
Quoted 4 lines
Tegra is using
./arch/arm/dts/tegra20.dtsiandboard/nvidia/dts/tegra2-seaboard.dtsand they are composed together in dts/Makefile by calling preprocessor. Microblaze will be totally different case because every Microblaze hw design is different.
Quoted 8 lines
Yes, that's right. We will never be in the position to define a skeleton or a basic platform configuration.
Quoted 3 lines
We can use two main buses (little and big endian) and cpu is also configurable. Based on this for Microblaze is the best solution directly to use dts. (DTS for Microblaze is also generated directly from design tool).
... directly in the context of a board, not
arch/cpu, right?
yes.
Quoted 21 lines
Quoted 21 lines
Anyway - here is the bug message I am getting if I use full dts in board/<name>/dts/microblaze.dts and empty
arch/microblaze/dts/microblaze.dtsi<stdin>:34:3: error: invalid preprocessing directive #address <stdin>:35:3: error: invalid preprocessing directive #size <stdin>:52:4: error: invalid preprocessing directive #address <stdin>:53:4: error: invalid preprocessing directive #cpus <stdin>:54:4: error: invalid preprocessing directive #size <stdin>:155:4: error: invalid preprocessing directive #address <stdin>:156:4: error: invalid preprocessing directive #size <stdin>:160:5: error: invalid preprocessing directive #gpio <stdin>:192:5: error: invalid preprocessing directive #gpio <stdin>:209:5: error: invalid preprocessing directive #gpio <stdin>:241:5: error: invalid preprocessing directive #gpio <stdin>:267:5: error: invalid preprocessing directive #address <stdin>:268:5: error: invalid preprocessing directive #size <stdin>:394:5: error: invalid preprocessing directive #interrupt
Quoted 4 lines
Quoted 1 line
This is error for opposite case - empty
microblaze.dtsand fullmicroblaze.dtsi.That are CPP errors, because the auto generated
xilinx.dtsis full of CPP pragma like syntax (#something) that are wrong (invalid).
I know what it is.
Quoted 54 lines
Quoted 12 lines
make[1]: Entering directory `/mnt/projects/u-boot/dts'
rc=$( cat/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts| microblaze-unknown-linux-gnu-gcc -E(quoted diff) +0
-2-P -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\" - | { { dtc -R 4 -p 0x1000 -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb on file' ; } 3>&1 ) ; \ exit $rc
/bin/sh: line 1: exit: too many arguments make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'Quoted 2 lines
I have just tried to fix it by introducing new CONFIG option for skipping that preprocessor part.
Instead of disable / skipp the CPP step you can hide the auto generated
xilinx.dtswith a second include stage, for example:
board/microblaze/dts/microblaze.dtslooks like:/include/
ARCH_CPU_DTS
/include/BOARD_DTSRight, only two lines. The
arch/microblaze/dts/microblaze.dtsiremains
empty as you have said above. Just new isBOARD_DTS-- with the attached patch for dts/Makefile you can copy the auto generatedxilinx.dtsinto the specific board directory and the CPP step substitute the right place toboard/microblaze/microblaze-generic/dts/microblaze.dtsI think there are no side effects with other ports like the tegra2.
If you want you can omit the
ARCH_CPU_DTSinclusion. The architecturalmicroblaze.dtsifile is empty and (!!) have to be empty, because the DTC will break with an error on multiple "/dts-v1/;" lines!Here is the patch:
dts/Makefile +0
-1@@ -36,7 +36,8 @@ $(error Your architecture does not have device tree support enabled. \ Please define CONFIG_ARCH_DEVICE_TREE)) # We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" +DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
+ -DBOARD_DTS=
\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
Quoted 1 line
all: $(obj).depend $(LIB)
Not sure if using another dts file will be the best approach.
Quoted 140 lines · Simon Glass
Hi,
On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <monstr at monstr.eu <mailto:[email protected]>> wrote:
On 06/28/2012 07:57 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> wrote:
Hi Simon,
On 06/28/2012 03:10 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>> wrote:
Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>>> wrote:
Hi,
can you please update me about current state of
CONFIG_OF_CONTROLfor ARM? Are there any other archs/boards which will use this option?Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution.
U-Boot doesn't yet have a device model which would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.
There are other limitations also - for example USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I ended with this code fragment which could be broadly used by other drivers.
int offset = 0;
do {
offset =fdt_node_offset_by_compatible(______gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" );You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->____fdt_blob, offset)
u32 rxpp =
fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp =fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg =fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);Maybe
fdtdec_get_addr()yeah right.
do {
offset =fdt_node_offset_by_compatible(____gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" ); u32 rxpp =fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0);
u32 txpp =fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0);
u32 reg =fdtdec_get_addr(gd->fdt_blob, offset, "reg");
if (reg !=FDT_ADDR_T_NONE)ret |=
xilinx_emaclite_initialize(____bis, reg, txpp, rxpp);
} while (offset != -1);if (reg)
ret |=xilinx_emaclite_initialize(______bis, reg, txpp, rxpp);} while (offset != -1);
What do you think? This code is in platform file.
Seems reasonable to me.
ok.
Also I have tested code around aliases which parse DTS aliases list for console initialization and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Great - I did send a patch to the list for fdt serial, but haven't really got back to it.
Can you give me link to it or just subject?
WIP: fdt: Add serial port controlled by device tree
These are the related commits in the Chromium tree. I will get to upstreaming these at some point.
1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present 2006b07 gen: fdt: Add serial port controlled by device tree 711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory mapped reg da92af5 gen: Fix a compiler warning inserial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent' option 376c215 lost: gen: fdt: Add serial port controlled by device treeCan you also send me link to Chromium tree?
Quoted 8 lines
Yes this should work:
https://git.chromium.org/git/chromiumos/third_party/u-boot.git
I am going to send RFC for emaclite driver and cleanup Microblaze port.
Simon: Can you please correct this code in arm board.c
gd->fdt_blob = (void *)getenv_ulong("fdtcontroladdr", 16,
(uintptr_t)gd->fdt_blob);Have you tested this option? I am not sure if this can even work in sense
that (-> means call) getenv_ulong -> getenv_f -> env_get_char -> env_get_char_memory/init -> etc.
But gd->env_valid is always 0 because initialization is done in init_sequence below this code. It means that this variable is taken only from default_environment.
Can you please check it?
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Hi,
Quoted 52 lines · Stephan Linz
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
I have sent support for Microblaze. Currently without dts because I want
to clear this part a little bit.
Hi Michal,
looks good, I've been waiting a long time on the FDT support in U-Boot for Microblaze -- great -- PS: see my comment on patch 5 ...
Quoted 2 lines
Tegra is using
./arch/arm/dts/tegra20.dtsiand
board/nvidia/dts/tegra2-seaboard.dtsQuoted 2 lines
and they are composed together in dts/Makefile by calling preprocessor. Microblaze will be totally different case because every Microblaze hw
design is different.
Yes, that's right. We will never be in the position to define a skeleton or a basic platform configuration.
Quoted 1 line
We can use two main buses (little and big endian) and cpu is also
configurable.
Quoted 2 lines
Based on this for Microblaze is the best solution directly to use dts. (DTS for Microblaze is also generated directly from design tool).
... directly in the context of a board, not
arch/cpu, right?Quoted 3 lines
Anyway - here is the bug message I am getting if I use full dts in
board/<name>/dts/microblaze.dts
Quoted 17 lines
and empty
arch/microblaze/dts/microblaze.dtsi<stdin>:34:3: error: invalid preprocessing directive #address <stdin>:35:3: error: invalid preprocessing directive #size <stdin>:52:4: error: invalid preprocessing directive #address <stdin>:53:4: error: invalid preprocessing directive #cpus <stdin>:54:4: error: invalid preprocessing directive #size <stdin>:155:4: error: invalid preprocessing directive #address <stdin>:156:4: error: invalid preprocessing directive #size <stdin>:160:5: error: invalid preprocessing directive #gpio <stdin>:192:5: error: invalid preprocessing directive #gpio <stdin>:209:5: error: invalid preprocessing directive #gpio <stdin>:241:5: error: invalid preprocessing directive #gpio <stdin>:267:5: error: invalid preprocessing directive #address <stdin>:268:5: error: invalid preprocessing directive #size <stdin>:394:5: error: invalid preprocessing directive #interrupt
Quoted 6 lines
Quoted 1 line
This is error for opposite case - empty
microblaze.dtsand full
microblaze.dtsi.That are CPP errors, because the auto generated
xilinx.dtsis full of CPP pragma like syntax (#something) that are wrong (invalid).
Yes - we want to move away from this and use a newer dtc which supports -i for include files, but can't yet. Stephen Warren suggested including the new dtc inside the U-Boot tree.
Quoted 58 lines
Quoted 3 lines
make[1]: Entering directory `/mnt/projects/u-boot/dts' rc=$( cat
/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts|microblaze-unknown-linux-gnu-gcc -E
Quoted 1 line
-P
-DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
- | { { dtc -R 4 -p0x1000Quoted 1 line
-O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC:
dts->dtbonfile' ; } 3>&1 ) ; \
Quoted 7 lines
exit $rc
/bin/sh: line 1: exit: too many arguments make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'I have just tried to fix it by introducing new CONFIG option for
skipping that preprocessor
Quoted 1 line
part.
Instead of disable / skipp the CPP step you can hide the auto generated
xilinx.dtswith a second include stage, for example:
board/microblaze/dts/microblaze.dtslooks like:/include/
ARCH_CPU_DTS
/include/BOARD_DTSRight, only two lines. The
arch/microblaze/dts/microblaze.dtsiremains
empty as you have said above. Just new isBOARD_DTS-- with the attached patch for dts/Makefile you can copy the auto generatedxilinx.dtsinto the specific board directory and the CPP step substitute the right place toboard/microblaze/microblaze-generic/dts/microblaze.dtsI think there are no side effects with other ports like the tegra2.
If you want you can omit the
ARCH_CPU_DTSinclusion. The architecturalmicroblaze.dtsifile is empty and (!!) have to be empty, because the DTC will break with an error on multiple "/dts-v1/;" lines!Here is the patch:
dts/Makefile +0
-1@@ -36,7 +36,8 @@ $(error Your architecture does not have device tree support enabled. \ Please define CONFIG_ARCH_DEVICE_TREE)) # We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" +DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
+ -DBOARD_DTS=
\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
Quoted 2 lines
all: $(obj).depend $(LIB)
I suppose this is ok. Really the better plan would be to use -i and specify the various directories where we can get include files. But for now, ok.
Regards,
Simon
Quoted 42 lines
br,
StephanQuoted 1 line
It will be good for Microblaze (probably there is any smarter solution
for SKIP case not to have two cats there).
Quoted 1 line
The same situation will happen for Xilinx ppc support and partially for
upcoming ARM zynq where
Quoted 30 lines
full DTS is generated for unique hw design.
Here is the patch to show you what phase I would like to skip.
dts/Makefile +7
-1@@ -45,9 +45,15 @@ all: $(obj).depend $(LIB) # the filename. DT_BIN := $(obj)dt.dtb +ifndef CONFIG_DTS_SKIP_PREPROCESSOR +SKIP := $(CPP) -P $(DTS_CPPFLAGS) - +else +SKIP := cat +endif + $(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts rc=$$( \ - cat $< | $(CPP) -P $(DTS_CPPFLAGS) - | \ + cat $< | $(SKIP) |\ { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 2>&1 ; \ echo $$? >&3 ; } | \ grep -v '^DTC: dts->dtb on file' ; \Thanks for your comments.
Michal
Hi,
Quoted 206 lines · Michal Simek
Quoted 188 lines · Simon Glass
Hi,
On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <[email protected] <mailto:
monstr at monstr.eu>> wrote:On 06/28/2012 07:57 AM, Simon Glass wrote: Hi Michal, On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <[email protected]<mailto:monstr at monstr.eu> <mailto:monstr at monstr.eu <mailto:[email protected]>>> wrote:
Hi Simon, On 06/28/2012 03:10 AM, Simon Glass wrote: Hi Michal, On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:[email protected]<mailto:
monstr at monstr.eu>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>> wrote:Hi Simon, On 06/27/2012 03:58 PM, Simon Glass wrote: Hi, On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:[email protected]<mailto:
monstr at monstr.eu>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> <mailto:
monstr at monstr.eu <mailto:[email protected]> <mailto:[email protected]<mailto:
monstr at monstr.eu>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>>> wrote:Hi,
can you please update me about current state
ofCONFIG_OF_CONTROLfor ARM?
Are there any other archs/boards which will
use this option?Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening
in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).ok.
Has someone tried to look for devices based
on compatible property?
I see that in usb driver it is based on
aliases which is not the best solution.U-Boot doesn't yet have a device model which
would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.There are other limitations also - for example
USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.I have looked at the code and did some tests on
Microblaze.Firstly I have tried to change emaclite ethernet
initialization and I ended with this code fragment which could bebroadly used by other drivers. int offset = 0; do { offset =
fdt_node_offset_by_compatible(**______gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" );You could check if offset < 0 here, or
!fdtdec_get_is_enabled(gd->___**_fdt_blob, offset)u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg =
fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);Maybe fdtdec_get_addr() yeah right. do { offset = fdt_node_offset_by_compatible(**____gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" ); u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg"); if (reg != FDT_ADDR_T_NONE) ret |= xilinx_emaclite_initialize(___ **_bis, reg, txpp, rxpp); } while (offset != -1); if (reg) ret |=
xilinx_emaclite_initialize(___**___bis, reg, txpp, rxpp);} while (offset != -1);
What do you think? This code is in platform file.
Seems reasonable to me.
ok.
Also I have tested code around aliases which parse
DTS aliases list for console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI
case.Great - I did send a patch to the list for fdt serial,
but haven't really got back to it.Can you give me link to it or just subject?
WIP: fdt: Add serial port controlled by device tree
These are the related commits in the Chromium tree. I will get to
upstreaming these at some point.1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present 2006b07 gen: fdt: Add serial port controlled by device tree 711f29d fixup: gen: fdt: Fix compile-time errors 0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and
memory mapped reg
da92af5 gen: Fix a compiler warning inserial_fdt.cab1d572 gen: fdt: silence console in response to device tree
'silent' option
376c215 lost: gen: fdt: Add serial port controlled by device treeCan you also send me link to Chromium tree?
Quoted 10 lines
Yes this should work:
https://git.chromium.org/git/**chromiumos/third_party/u-boot.**git<https://git.chromium.org/git/chromiumos/third_party/u-boot.git>
I am going to send RFC for emaclite driver and cleanup Microblaze
port.Simon: Can you please correct this code in arm
board.cgd->fdt_blob = (void *)getenv_ulong("**fdtcontroladdr", 16, (uintptr_t)gd->fdt_blob);
Quoted 9 lines
Have you tested this option? I am not sure if this can even work in sense that (-> means call)
getenv_ulong->getenv_f->env_get_char-> env_get_char_memory/init -> etc.But
gd->env_validis always 0 because initialization is done ininit_sequencebelow
this code. It means that this variable is taken only fromdefault_environment.
But doesn't it use the built-in environment instead in this case? It should...
Quoted 8 lines
Can you please check it?
Thanks,
Michal
Quoted 7 lines
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux -
http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Regards,
Simon
Hi,
Quoted 123 lines · Michal Simek
2012/6/29 Stephan Linz <[email protected]>:
Quoted 7 lines
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
I have sent support for Microblaze. Currently without dts because I
want to clear this part a little bit.
Quoted 8 lines
Hi Michal,
looks good, I've been waiting a long time on the FDT support in U-Boot for Microblaze -- great -- PS: see my comment on patch 5 ...
Quoted 2 lines
Tegra is using
./arch/arm/dts/tegra20.dtsiand
board/nvidia/dts/tegra2-seaboard.dtsQuoted 2 lines
Quoted 2 lines
and they are composed together in dts/Makefile by calling preprocessor. Microblaze will be totally different case because every Microblaze hw
design is different.
Quoted 5 lines
Yes, that's right. We will never be in the position to define a skeleton or a basic platform configuration.
Quoted 1 line
We can use two main buses (little and big endian) and cpu is also
configurable.
Quoted 4 lines
Quoted 2 lines
Based on this for Microblaze is the best solution directly to use dts. (DTS for Microblaze is also generated directly from design tool).
... directly in the context of a board, not
arch/cpu, right?yes.
Quoted 4 lines
Quoted 4 lines
Anyway - here is the bug message I am getting if I use full dts in
board/<name>/dts/microblaze.dts
Quoted 17 lines
Quoted 17 lines
and empty
arch/microblaze/dts/microblaze.dtsi<stdin>:34:3: error: invalid preprocessing directive #address <stdin>:35:3: error: invalid preprocessing directive #size <stdin>:52:4: error: invalid preprocessing directive #address <stdin>:53:4: error: invalid preprocessing directive #cpus <stdin>:54:4: error: invalid preprocessing directive #size <stdin>:155:4: error: invalid preprocessing directive #address <stdin>:156:4: error: invalid preprocessing directive #size <stdin>:160:5: error: invalid preprocessing directive #gpio <stdin>:192:5: error: invalid preprocessing directive #gpio <stdin>:209:5: error: invalid preprocessing directive #gpio <stdin>:241:5: error: invalid preprocessing directive #gpio <stdin>:267:5: error: invalid preprocessing directive #address <stdin>:268:5: error: invalid preprocessing directive #size <stdin>:394:5: error: invalid preprocessing directive #interrupt
Quoted 1 line
Quoted 1 line
This is error for opposite case - empty
microblaze.dtsand full
microblaze.dtsi.Quoted 3 lines
That are CPP errors, because the auto generated
xilinx.dtsis full of CPP pragma like syntax (#something) that are wrong (invalid).I know what it is.
Quoted 4 lines
Quoted 4 lines
make[1]: Entering directory `/mnt/projects/u-boot/dts' rc=$( cat
/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts|microblaze-unknown-linux-gnu-gcc -E
Quoted 1 line
Quoted 1 line
-P
-DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
- | { { dtc -R 4 -p0x1000Quoted 1 line
Quoted 1 line
-O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC:
dts->dtbonfile' ; } 3>&1 ) ; \
Quoted 7 lines
Quoted 7 lines
exit $rc
/bin/sh: line 1: exit: too many arguments make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'I have just tried to fix it by introducing new CONFIG option for
skipping that preprocessor
Quoted 41 lines
Quoted 1 line
part.
Instead of disable / skipp the CPP step you can hide the auto generated
xilinx.dtswith a second include stage, for example:
board/microblaze/dts/microblaze.dtslooks like:/include/
ARCH_CPU_DTS
/include/BOARD_DTSRight, only two lines. The
arch/microblaze/dts/microblaze.dtsiremains
empty as you have said above. Just new isBOARD_DTS-- with the attached patch for dts/Makefile you can copy the auto generatedxilinx.dtsinto the specific board directory and the CPP step substitute the right place toboard/microblaze/microblaze-generic/dts/microblaze.dtsI think there are no side effects with other ports like the tegra2.
If you want you can omit the
ARCH_CPU_DTSinclusion. The architecturalmicroblaze.dtsifile is empty and (!!) have to be empty, because the DTC will break with an error on multiple "/dts-v1/;" lines!Here is the patch:
dts/Makefile +0
-1@@ -36,7 +36,8 @@ $(error Your architecture does not have device tree support enabled. \ Please define CONFIG_ARCH_DEVICE_TREE)) # We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" +DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
+ -DBOARD_DTS=
\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
Quoted 7 lines
Quoted 1 line
all: $(obj).depend $(LIB)
Not sure if using another dts file will be the best approach. From my point of view will be the best to support only one dts file (without dtsi)
because it is much cleaner then using 3 dts files.
Well there is no inherent problem with having multiple include files, except that it is hard to support with the old dtc when there are in different subdirs.
As a workaround, how about putting the include files in the board/vendor/dts subdir as well for now?
Regards,
Simon
Quoted 4 lines
Thanks,
Michal
Hi,
Am Montag, den 02.07.2012, 07:43 +0200 schrieb Michal Simek:
Quoted 112 lines
2012/6/29 Stephan Linz <[email protected]>:
Quoted 18 lines
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
I have sent support for Microblaze. Currently without dts because I want to clear this part a little bit.
Hi Michal,
looks good, I've been waiting a long time on the FDT support in U-Boot for Microblaze -- great -- PS: see my comment on patch 5 ...
Quoted 4 lines
Tegra is using
./arch/arm/dts/tegra20.dtsiandboard/nvidia/dts/tegra2-seaboard.dtsand they are composed together in dts/Makefile by calling preprocessor. Microblaze will be totally different case because every Microblaze hw design is different.Quoted 8 lines
Yes, that's right. We will never be in the position to define a skeleton or a basic platform configuration.
Quoted 3 lines
We can use two main buses (little and big endian) and cpu is also configurable. Based on this for Microblaze is the best solution directly to use dts. (DTS for Microblaze is also generated directly from design tool).
... directly in the context of a board, not
arch/cpu, right?yes.
Quoted 21 lines
Quoted 21 lines
Anyway - here is the bug message I am getting if I use full dts in board/<name>/dts/microblaze.dts and empty
arch/microblaze/dts/microblaze.dtsi<stdin>:34:3: error: invalid preprocessing directive #address <stdin>:35:3: error: invalid preprocessing directive #size <stdin>:52:4: error: invalid preprocessing directive #address <stdin>:53:4: error: invalid preprocessing directive #cpus <stdin>:54:4: error: invalid preprocessing directive #size <stdin>:155:4: error: invalid preprocessing directive #address <stdin>:156:4: error: invalid preprocessing directive #size <stdin>:160:5: error: invalid preprocessing directive #gpio <stdin>:192:5: error: invalid preprocessing directive #gpio <stdin>:209:5: error: invalid preprocessing directive #gpio <stdin>:241:5: error: invalid preprocessing directive #gpio <stdin>:267:5: error: invalid preprocessing directive #address <stdin>:268:5: error: invalid preprocessing directive #size <stdin>:394:5: error: invalid preprocessing directive #interrupt
Quoted 4 lines
Quoted 1 line
This is error for opposite case - empty
microblaze.dtsand fullmicroblaze.dtsi.That are CPP errors, because the auto generated
xilinx.dtsis full of CPP pragma like syntax (#something) that are wrong (invalid).I know what it is.
Quoted 54 lines
Quoted 12 lines
make[1]: Entering directory `/mnt/projects/u-boot/dts'
rc=$( cat/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts| microblaze-unknown-linux-gnu-gcc -E(quoted diff) +0
-2-P -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\" - | { { dtc -R 4 -p 0x1000 -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb on file' ; } 3>&1 ) ; \ exit $rc
/bin/sh: line 1: exit: too many arguments make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'Quoted 2 lines
I have just tried to fix it by introducing new CONFIG option for skipping that preprocessor part.
Instead of disable / skipp the CPP step you can hide the auto generated
xilinx.dtswith a second include stage, for example:
board/microblaze/dts/microblaze.dtslooks like:/include/
ARCH_CPU_DTS
/include/BOARD_DTSRight, only two lines. The
arch/microblaze/dts/microblaze.dtsiremains
empty as you have said above. Just new isBOARD_DTS-- with the attached patch for dts/Makefile you can copy the auto generatedxilinx.dtsinto the specific board directory and the CPP step substitute the right place toboard/microblaze/microblaze-generic/dts/microblaze.dtsI think there are no side effects with other ports like the tegra2.
If you want you can omit the
ARCH_CPU_DTSinclusion. The architecturalmicroblaze.dtsifile is empty and (!!) have to be empty, because the DTC will break with an error on multiple "/dts-v1/;" lines!Here is the patch:
dts/Makefile +0
-1@@ -36,7 +36,8 @@ $(error Your architecture does not have device tree support enabled. \ Please define CONFIG_ARCH_DEVICE_TREE)) # We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" +DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
+ -DBOARD_DTS=
\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
Quoted 3 lines
Quoted 1 line
all: $(obj).depend $(LIB)
Not sure if using another dts file will be the best approach.
For Microblaze you can ignore the ARCH_CPU_DTS and the dtsi file in arch/cpu completely and ...
Quoted 2 lines
From my point of view will be the best to support only one dts file (without dtsi)
... remove the ARCH_CPU_DTS inclusion in board/microblaze/dts/microblaze.dts -- instead use the new CPP substitution BOARD_DTS (patch above) to hide the content of the autogenerated dts from CPP until the new dtc with -i option will be available (see Simons E-Mail).
Content of board/microblaze/dts/microblaze.dts is one line only:
/include/ BOARD_DTS
As an result the board/microblaze/dts/microblaze.dts will never changed again and you can save the autogenerated dts within the board specific code area in board/<vendor>/<boardname>/dts/microblaze.dts -- only one file have to be handled (changed).
br,
Stephan
Quoted 8 lines
because it is much cleaner then using 3 dts files.
Thanks,
Michal
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
Quoted 135 lines
Hi,
Quoted 123 lines · Michal Simek
2012/6/29 Stephan Linz <[email protected]>:
Quoted 7 lines
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
I have sent support for Microblaze. Currently without dts because I
want to clear this part a little bit.
Quoted 8 lines
Hi Michal,
looks good, I've been waiting a long time on the FDT support in U-Boot for Microblaze -- great -- PS: see my comment on patch 5 ...
Quoted 2 lines
Tegra is using
./arch/arm/dts/tegra20.dtsiand
board/nvidia/dts/tegra2-seaboard.dtsQuoted 2 lines
Quoted 2 lines
and they are composed together in dts/Makefile by calling preprocessor. Microblaze will be totally different case because every Microblaze hw
design is different.
Quoted 5 lines
Yes, that's right. We will never be in the position to define a skeleton or a basic platform configuration.
Quoted 1 line
We can use two main buses (little and big endian) and cpu is also
configurable.
Quoted 4 lines
Quoted 2 lines
Based on this for Microblaze is the best solution directly to use dts. (DTS for Microblaze is also generated directly from design tool).
... directly in the context of a board, not
arch/cpu, right?yes.
Quoted 4 lines
Quoted 4 lines
Anyway - here is the bug message I am getting if I use full dts in
board/<name>/dts/microblaze.dts
Quoted 17 lines
Quoted 17 lines
and empty
arch/microblaze/dts/microblaze.dtsi<stdin>:34:3: error: invalid preprocessing directive #address <stdin>:35:3: error: invalid preprocessing directive #size <stdin>:52:4: error: invalid preprocessing directive #address <stdin>:53:4: error: invalid preprocessing directive #cpus <stdin>:54:4: error: invalid preprocessing directive #size <stdin>:155:4: error: invalid preprocessing directive #address <stdin>:156:4: error: invalid preprocessing directive #size <stdin>:160:5: error: invalid preprocessing directive #gpio <stdin>:192:5: error: invalid preprocessing directive #gpio <stdin>:209:5: error: invalid preprocessing directive #gpio <stdin>:241:5: error: invalid preprocessing directive #gpio <stdin>:267:5: error: invalid preprocessing directive #address <stdin>:268:5: error: invalid preprocessing directive #size <stdin>:394:5: error: invalid preprocessing directive #interrupt
Quoted 1 line
Quoted 1 line
This is error for opposite case - empty
microblaze.dtsand full
microblaze.dtsi.Quoted 3 lines
That are CPP errors, because the auto generated
xilinx.dtsis full of CPP pragma like syntax (#something) that are wrong (invalid).I know what it is.
Quoted 4 lines
Quoted 4 lines
make[1]: Entering directory `/mnt/projects/u-boot/dts' rc=$( cat
/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts|microblaze-unknown-linux-gnu-gcc -E
Quoted 1 line
Quoted 1 line
-P
-DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
- | { { dtc -R 4 -p0x1000Quoted 1 line
Quoted 1 line
-O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC:
dts->dtbonfile' ; } 3>&1 ) ; \
Quoted 7 lines
Quoted 7 lines
exit $rc
/bin/sh: line 1: exit: too many arguments make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'I have just tried to fix it by introducing new CONFIG option for
skipping that preprocessor
Quoted 41 lines
Quoted 1 line
part.
Instead of disable / skipp the CPP step you can hide the auto generated
xilinx.dtswith a second include stage, for example:
board/microblaze/dts/microblaze.dtslooks like:/include/
ARCH_CPU_DTS
/include/BOARD_DTSRight, only two lines. The
arch/microblaze/dts/microblaze.dtsiremains
empty as you have said above. Just new isBOARD_DTS-- with the attached patch for dts/Makefile you can copy the auto generatedxilinx.dtsinto the specific board directory and the CPP step substitute the right place toboard/microblaze/microblaze-generic/dts/microblaze.dtsI think there are no side effects with other ports like the tegra2.
If you want you can omit the
ARCH_CPU_DTSinclusion. The architecturalmicroblaze.dtsifile is empty and (!!) have to be empty, because the DTC will break with an error on multiple "/dts-v1/;" lines!Here is the patch:
dts/Makefile +0
-1@@ -36,7 +36,8 @@ $(error Your architecture does not have device tree support enabled. \ Please define CONFIG_ARCH_DEVICE_TREE)) # We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" +DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
+ -DBOARD_DTS=
\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"Quoted 7 lines
Quoted 1 line
all: $(obj).depend $(LIB)
Not sure if using another dts file will be the best approach. From my point of view will be the best to support only one dts file (without dtsi)
because it is much cleaner then using 3 dts files.
Quoted 6 lines
Well there is no inherent problem with having multiple include files, except that it is hard to support with the old dtc when there are in different subdirs.
As a workaround, how about putting the include files in the board/vendor/dts subdir as well for now?
Hi,
good idea -- but they cannot be used directly. The substitution variable ARCH_CPU_DTS is already reserved for dtsi in arch/cpu. The Microblaze architecture needs a board specific dts onyl. That's why I think the new substitution variable BOARD_DTS can be a option to solve the CPP problem today and handle the dtc -i in the future.
BOARD_DTS can point to anything below board/vendor and perhaps with a new configuration option similar to CONFIG_DEFAULT_DEVICE_TREE the substitution could be affected with freely selectable file name instead of DEVICE_TREE only.
br,
Stephan
Quoted 13 lines
Regards,
SimonQuoted 4 lines
Thanks,
Michal_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi,
Quoted 165 lines · Stephan Linz
Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
Quoted 17 lines
Hi,
Quoted 13 lines · Michal Simek
2012/6/29 Stephan Linz <[email protected]>:
Quoted 7 lines
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
I have sent support for Microblaze. Currently without dts because I
want to clear this part a little bit.
Quoted 4 lines
Hi Michal,
looks good, I've been waiting a long time on the FDT support in
U-Boot
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
for Microblaze -- great -- PS: see my comment on patch 5 ...
Quoted 2 lines
Tegra is using
./arch/arm/dts/tegra20.dtsiand
board/nvidia/dts/tegra2-seaboard.dtsQuoted 1 line
Quoted 1 line
and they are composed together in dts/Makefile by calling
preprocessor.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Microblaze will be totally different case because every Microblaze
hw
Quoted 3 lines
Quoted 3 lines
design is different.
Quoted 2 lines
Yes, that's right. We will never be in the position to define a
skeleton
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
or a basic platform configuration.
Quoted 1 line
We can use two main buses (little and big endian) and cpu is also
configurable.
Quoted 1 line
Quoted 1 line
Based on this for Microblaze is the best solution directly to use
dts.
Quoted 38 lines
Quoted 38 lines
Quoted 3 lines
Quoted 1 line
(DTS for Microblaze is also generated directly from design tool).
... directly in the context of a board, not
arch/cpu, right?yes.
Quoted 4 lines
Quoted 4 lines
Anyway - here is the bug message I am getting if I use full dts in
board/<name>/dts/microblaze.dts
Quoted 17 lines
Quoted 17 lines
and empty
arch/microblaze/dts/microblaze.dtsi<stdin>:34:3: error: invalid preprocessing directive #address <stdin>:35:3: error: invalid preprocessing directive #size <stdin>:52:4: error: invalid preprocessing directive #address <stdin>:53:4: error: invalid preprocessing directive #cpus <stdin>:54:4: error: invalid preprocessing directive #size <stdin>:155:4: error: invalid preprocessing directive #address <stdin>:156:4: error: invalid preprocessing directive #size <stdin>:160:5: error: invalid preprocessing directive #gpio <stdin>:192:5: error: invalid preprocessing directive #gpio <stdin>:209:5: error: invalid preprocessing directive #gpio <stdin>:241:5: error: invalid preprocessing directive #gpio <stdin>:267:5: error: invalid preprocessing directive #address <stdin>:268:5: error: invalid preprocessing directive #size <stdin>:394:5: error: invalid preprocessing directive #interrupt
Quoted 1 line
Quoted 1 line
This is error for opposite case - empty
microblaze.dtsand full
microblaze.dtsi.Quoted 3 lines
That are CPP errors, because the auto generated
xilinx.dtsis full of CPP pragma like syntax (#something) that are wrong (invalid).I know what it is.
Quoted 2 lines
Quoted 2 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
make[1]: Entering directory `/mnt/projects/u-boot/dts' rc=$( cat
/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts|microblaze-unknown-linux-gnu-gcc -E
Quoted 1 line
Quoted 1 line
-P
-DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
Quoted 2 lines
Quoted 2 lines
- | { { dtc -R 4 -p
0x1000Quoted 1 line
Quoted 1 line
-O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC:
dts->dtbon
Quoted 7 lines
Quoted 7 lines
file' ; } 3>&1 ) ; \
Quoted 6 lines
Quoted 6 lines
exit $rc
/bin/sh: line 1: exit: too many arguments make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
I have just tried to fix it by introducing new CONFIG option for
skipping that preprocessor
Quoted 3 lines
Quoted 1 line
part.
Instead of disable / skipp the CPP step you can hide the auto
generated
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
xilinx.dtswith a second include stage, for example:
board/microblaze/dts/microblaze.dtslooks like:/include/
ARCH_CPU_DTS
/include/BOARD_DTSRight, only two lines. The
arch/microblaze/dts/microblaze.dtsiremains
Quoted 1 line
Quoted 1 line
Quoted 1 line
empty as you have said above. Just new is
BOARD_DTS-- with theattached
Quoted 1 line
Quoted 1 line
Quoted 1 line
patch for dts/Makefile you can copy the auto generated
xilinx.dtsinto
Quoted 1 line
Quoted 1 line
Quoted 1 line
the specific board directory and the CPP step substitute the right
place
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
to
board/microblaze/microblaze-generic/dts/microblaze.dtsI think there are no side effects with other ports like the tegra2.
If you want you can omit the
ARCH_CPU_DTSinclusion. Thearchitectural
Quoted 1 line
Quoted 1 line
Quoted 1 line
microblaze.dtsifile is empty and (!!) have to be empty, because theDTC
Quoted 28 lines
Quoted 20 lines
Quoted 20 lines
will break with an error on multiple "/dts-v1/;" lines!
Here is the patch:
dts/Makefile +0
-1@@ -36,7 +36,8 @@ $(error Your architecture does not have device tree support enabled. \ Please define CONFIG_ARCH_DEVICE_TREE)) # We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" +DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
+ -DBOARD_DTS=
\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"Quoted 7 lines
Quoted 1 line
all: $(obj).depend $(LIB)
Not sure if using another dts file will be the best approach. From my point of view will be the best to support only one dts file (without dtsi)
because it is much cleaner then using 3 dts files.Quoted 6 lines
Well there is no inherent problem with having multiple include files, except that it is hard to support with the old dtc when there are in different subdirs.
As a workaround, how about putting the include files in the board/vendor/dts subdir as well for now?
Hi,
good idea -- but they cannot be used directly. The substitution variable
ARCH_CPU_DTSis already reserved for dtsi inarch/cpu. The Microblaze architecture needs a board specific dts onyl. That's why I think the new substitution variableBOARD_DTScan be a option to solve the CPP problem today and handle the dtc -i in the future.
Quoted 5 lines
BOARD_DTScan point to anything below board/vendor and perhaps with a new configuration option similar toCONFIG_DEFAULT_DEVICE_TREEthe substitution could be affected with freely selectable file name instead ofDEVICE_TREEonly.
Just in case there is any confusion here...
The device tree file is not necessarily intended to be built with/by the U-Boot Makefile. Yes it is convenient to do that, but where you have multiple board variants it is actually best to have the Makefile build U-Boot without a device tree, i.e. no need to select the particular board variant.
Then, in a separate step:
for board in ${list_of_available_boards}; do
dtc ... ${board}.dts
cat u-boot.bin ${board}.dtb >u-boot-${board}.bin
done
I mention this because if we make U-Boot build the particular board variant, then have we actually achieved the goal of a single U-Boot image that supports multiple boards?
So IMO the infrastructure to support the post-processing of U-Boot binaries and device trees may not in fact belong in the U-Boot Makefile. It is convenient to be able to specify a device tree for U-Boot to pick up and build, but I don't think it should come from the boards.cfg file - after all the whole point is that we support a number of build variants. The board name in boards.cfg will be something generic, like microblaze-dt, or similar.
I hope that makes sense.
Regards,
Simon
Quoted 24 lines
br,
StephanQuoted 13 lines
Regards,
SimonQuoted 4 lines
Thanks,
Michal_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Quoted 165 lines · Simon Glass
Hi,
On Tue, Jul 3, 2012 at 2:21 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]>> wrote:
On 06/29/2012 04:32 AM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> wrote:
On 06/28/2012 07:57 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>> wrote:
Hi Simon,
On 06/28/2012 03:10 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>>> wrote:
Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>>
<mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>> <mailto:monstr at monstr.eu <mailto:[email protected]> <mailto:monstr at monstr.eu <mailto:[email protected]>>>>>> wrote:Hi,
can you please update me about current state of
CONFIG_OF_CONTROLfor ARM? Are there any other archs/boards which will use this option?Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution.
U-Boot doesn't yet have a device model which would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model.
There are other limitations also - for example USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I ended with this code fragment which could be broadly used by other drivers.
int offset = 0;
do {
offset =fdt_node_offset_by_compatible(________gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" );You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->______fdt_blob, offset)
u32 rxpp =
fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0); u32 txpp =fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0); u32 reg =fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);Maybe
fdtdec_get_addr()yeah right.
do {
offset =fdt_node_offset_by_compatible(______gd->fdt_blob, offset, "xlnx,xps-ethernetlite-1.00.a" ); u32 rxpp =fdtdec_get_int(gd->fdt_blob, offset, "xlnx,rx-ping-pong", 0);
u32 txpp =fdtdec_get_int(gd->fdt_blob, offset, "xlnx,tx-ping-pong", 0);
u32 reg =fdtdec_get_addr(gd->fdt_blob, offset, "reg");
if (reg !=FDT_ADDR_T_NONE)ret |=
xilinx_emaclite_initialize(______bis, reg, txpp, rxpp);
} while (offset != -1);if (reg)
ret |=xilinx_emaclite_initialize(________bis, reg, txpp, rxpp);} while (offset != -1);
What do you think? This code is in platform file.
Seems reasonable to me.
ok.
Also I have tested code around aliases which parse DTS aliases list for console initialization and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Great - I did send a patch to the list for fdt serial, but haven't really got back to it.
Can you give me link to it or just subject?
WIP: fdt: Add serial port controlled by device tree
These are the related commits in the Chromium tree. I will get to upstreaming these at some point.
1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present 2006b07 gen: fdt: Add serial port controlled by device tree 711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory mapped reg da92af5 gen: Fix a compiler warning inserial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent' option 376c215 lost: gen: fdt: Add serial port controlled by device treeCan you also send me link to Chromium tree?
Yes this should work:
https://git.chromium.org/git/__chromiumos/third_party/u-boot.__git <https://git.chromium.org/git/chromiumos/third_party/u-boot.git>
I am going to send RFC for emaclite driver and cleanup Microblaze port.
Simon: Can you please correct this code in arm
board.c
gd->fdt_blob= (void *)getenv_ulong("__fdtcontroladdr", 16,
(uintptr_t)gd->fdt_blob);
Quoted 8 lines
Have you tested this option? I am not sure if this can even work in sense
that (-> means call)getenv_ulong->getenv_f->env_get_char-> env_get_char_memory/init -> etc.But
gd->env_validis always 0 because initialization is done ininit_sequencebelow this code. It means that this variable is taken only fromdefault_environment.But doesn't it use the built-in environment instead in this case? It should...
Yes, it is using but is it what you want?
I mean I would expect that you can change it on u-boot command line and store it and save it to flash/spi/mmc/etc. And in the next run you can use different address. But you will still use variable from default_environment.
I am ok if this is expected behavior.
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Quoted 53 lines · Simon Glass
Hi,
On Fri, Jun 29, 2012 at 1:22 PM, Stephan Linz <linz at li-pro.net <mailto:[email protected]>> wrote:
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
> On 06/29/2012 04:32 AM, Simon Glass wrote:
> > Hi,
> >
> > --snip--
>
> I have sent support for Microblaze. Currently without dts because I want to clear this part a little bit.Hi Michal,
looks good, I've been waiting a long time on the FDT support in U-Boot for Microblaze -- great -- PS: see my comment on patch 5 ...
>
> Tegra is using./arch/arm/dts/tegra20.dtsiandboard/nvidia/dts/tegra2-seaboard.dts> and they are composed together in dts/Makefile by calling preprocessor.
> Microblaze will be totally different case because every Microblaze hw design is different.Yes, that's right. We will never be in the position to define a skeleton or a basic platform configuration.
> We can use two main buses (little and big endian) and cpu is also configurable. > Based on this for Microblaze is the best solution directly to use dts. > (DTS for Microblaze is also generated directly from design tool).
... directly in the context of a board, not
arch/cpu, right?>
>
> Anyway - here is the bug message I am getting if I use full dts in board/<name>/dts/microblaze.dts > and emptyarch/microblaze/dts/microblaze.dtsi
>
> <stdin>:34:3: error: invalid preprocessing directive #address
> <stdin>:35:3: error: invalid preprocessing directive #size
> <stdin>:52:4: error: invalid preprocessing directive #address
> <stdin>:53:4: error: invalid preprocessing directive #cpus
> <stdin>:54:4: error: invalid preprocessing directive #size
> <stdin>:155:4: error: invalid preprocessing directive #address
> <stdin>:156:4: error: invalid preprocessing directive #size
> <stdin>:160:5: error: invalid preprocessing directive #gpio
> <stdin>:192:5: error: invalid preprocessing directive #gpio
> <stdin>:209:5: error: invalid preprocessing directive #gpio
> <stdin>:241:5: error: invalid preprocessing directive #gpio
> <stdin>:267:5: error: invalid preprocessing directive #address
> <stdin>:268:5: error: invalid preprocessing directive #size
> <stdin>:394:5: error: invalid preprocessing directive #interrupt
>
> This is error for opposite case - emptymicroblaze.dtsand fullmicroblaze.dtsi.
Quoted 5 lines
That are CPP errors, because the auto generated
xilinx.dtsis full of CPP pragma like syntax (#something) that are wrong (invalid).Yes - we want to move away from this and use a newer dtc which supports -i for include files, but can't yet. Stephen Warren suggested including the new dtc inside the U-Boot tree.
ok
Quoted 55 lines
>
> make[1]: Entering directory `/mnt/projects/u-boot/dts'
> rc=$( cat/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts| microblaze-unknown-linux-gnu-gcc -E > -P -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\" - | { { dtc -R 4 -p0x1000> -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC:dts->dtbon file' ; } 3>&1 ) ; \
> exit $rc
>/bin/sh: line 1: exit: too many arguments
> make[1]: *** [dt.dtb] Error 1
> make[1]: Leaving directory `/mnt/projects/u-boot/dts'
>
>
> I have just tried to fix it by introducing new CONFIG option for skipping that preprocessor > part.Instead of disable / skipp the CPP step you can hide the auto generated
xilinx.dtswith a second include stage, for example:
board/microblaze/dts/microblaze.dtslooks like:/include/
ARCH_CPU_DTS
/include/BOARD_DTSRight, only two lines. The
arch/microblaze/dts/microblaze.dtsiremains
empty as you have said above. Just new isBOARD_DTS-- with the attached patch for dts/Makefile you can copy the auto generatedxilinx.dtsinto the specific board directory and the CPP step substitute the right place toboard/microblaze/microblaze-generic/dts/microblaze.dtsI think there are no side effects with other ports like the tegra2.
If you want you can omit the
ARCH_CPU_DTSinclusion. The architecturalmicroblaze.dtsifile is empty and (!!) have to be empty, because the DTC will break with an error on multiple "/dts-v1/;" lines!Here is the patch:
diff --git a/dts/Makefile b/dts/Makefile
index 914e479..b1f47a1 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -36,7 +36,8 @@ $(error Your architecture does not have device tree support enabled. \
Please defineCONFIG_ARCH_DEVICE_TREE))# We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" +DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
+ -DBOARD_DTS=
\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
Quoted 4 lines
all: $(obj).depend $(LIB)
I suppose this is ok. Really the better plan would be to use -i and specify the various directories where we can get include files. But for now, ok.
What is the problem to add the latest dtc?
Thanks,
Michal
---
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Quoted 161 lines · Simon Glass
Hi,
On Tue, Jul 3, 2012 at 1:22 PM, Stephan Linz <linz at li-pro.net <mailto:[email protected]>> wrote:
Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
> Hi,
>
> On Sun, Jul 1, 2012 at 10:43 PM, Michal Simek <monstr at monstr.eu <mailto:[email protected]>> wrote:
>
> > 2012/6/29 Stephan Linz <linz at li-pro.net <mailto:[email protected]>>:
> > > Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
> > >> On 06/29/2012 04:32 AM, Simon Glass wrote:
> > >> > Hi,
> > >> >
> > >> > --snip--
> > >>
> > >> I have sent support for Microblaze. Currently without dts because I
> > want to clear this part a little bit.
> > >
> > > Hi Michal,
> > >
> > > looks good, I've been waiting a long time on the FDT support in U-Boot
> > > for Microblaze -- great -- PS: see my comment on patch 5 ...
> > >
> > >>
> > >> Tegra is using./arch/arm/dts/tegra20.dtsiand
> >board/nvidia/dts/tegra2-seaboard.dts
> > >> and they are composed together in dts/Makefile by calling preprocessor.
> > >> Microblaze will be totally different case because every Microblaze hw
> > design is different.
> > >
> > > Yes, that's right. We will never be in the position to define a skeleton
> > > or a basic platform configuration.
> > >
> > >> We can use two main buses (little and big endian) and cpu is also
> > configurable.
> > >> Based on this for Microblaze is the best solution directly to use dts.
> > >> (DTS for Microblaze is also generated directly from design tool).
> > >
> > > ... directly in the context of a board, notarch/cpu, right?
> >
> > yes.
> >
> > >
> > >>
> > >>
> > >> Anyway - here is the bug message I am getting if I use full dts in
> > board/<name>/dts/microblaze.dts
> > >> and emptyarch/microblaze/dts/microblaze.dtsi
> > >>
> > >> <stdin>:34:3: error: invalid preprocessing directive #address
> > >> <stdin>:35:3: error: invalid preprocessing directive #size
> > >> <stdin>:52:4: error: invalid preprocessing directive #address
> > >> <stdin>:53:4: error: invalid preprocessing directive #cpus
> > >> <stdin>:54:4: error: invalid preprocessing directive #size
> > >> <stdin>:155:4: error: invalid preprocessing directive #address
> > >> <stdin>:156:4: error: invalid preprocessing directive #size
> > >> <stdin>:160:5: error: invalid preprocessing directive #gpio
> > >> <stdin>:192:5: error: invalid preprocessing directive #gpio
> > >> <stdin>:209:5: error: invalid preprocessing directive #gpio
> > >> <stdin>:241:5: error: invalid preprocessing directive #gpio
> > >> <stdin>:267:5: error: invalid preprocessing directive #address
> > >> <stdin>:268:5: error: invalid preprocessing directive #size
> > >> <stdin>:394:5: error: invalid preprocessing directive #interrupt
> > >>
> > >> This is error for opposite case - emptymicroblaze.dtsand full
> >microblaze.dtsi.
> > >
> > > That are CPP errors, because the auto generatedxilinx.dtsis full of
> > > CPP pragma like syntax (#something) that are wrong (invalid).
> >
> > I know what it is.
> >
> > >
> > >>
> > >> make[1]: Entering directory `/mnt/projects/u-boot/dts'
> > >> rc=$( cat/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts|
> > microblaze-unknown-linux-gnu-gcc -E
> > >> -P
> > -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
> > - | { { dtc -R 4 -p0x1000
> > >> -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC:dts->dtbon
> > file' ; } 3>&1 ) ; \
> > >> exit $rc
> > >>/bin/sh: line 1: exit: too many arguments
> > >> make[1]: *** [dt.dtb] Error 1
> > >> make[1]: Leaving directory `/mnt/projects/u-boot/dts'
> > >>
> > >>
> > >> I have just tried to fix it by introducing new CONFIG option for
> > skipping that preprocessor
> > >> part.
> > >
> > > Instead of disable / skipp the CPP step you can hide the auto generated
> > >xilinx.dtswith a second include stage, for example:
> > >
> > >board/microblaze/dts/microblaze.dtslooks like:
> > >
> > > /include/ARCH_CPU_DTS
> > > /include/BOARD_DTS
> > >
> > >
> > > Right, only two lines. Thearch/microblaze/dts/microblaze.dtsiremains
> > > empty as you have said above. Just new isBOARD_DTS-- with the attached
> > > patch for dts/Makefile you can copy the auto generatedxilinx.dtsinto
> > > the specific board directory and the CPP step substitute the right place
> > > toboard/microblaze/microblaze-generic/dts/microblaze.dts
> > >
> > > I think there are no side effects with other ports like the tegra2.
> > >
> > > If you want you can omit theARCH_CPU_DTSinclusion. The architectural
> > >microblaze.dtsifile is empty and (!!) have to be empty, because the DTC
> > > will break with an error on multiple "/dts-v1/;" lines!
> > >
> > > Here is the patch:
> > >
> > > diff --git a/dts/Makefile b/dts/Makefile
> > > index 914e479..b1f47a1 100644
> > > --- a/dts/Makefile
> > > +++ b/dts/Makefile
> > > @@ -36,7 +36,8 @@ $(error Your architecture does not have device tree
> > > support enabled. \
> > > Please defineCONFIG_ARCH_DEVICE_TREE))
> > >
> > > # We preprocess the device tree file provide a useful define
> > > -DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\"
> > > +DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
> > > + -DBOARD_DTS=
> > > \"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
> > >
> > > all: $(obj).depend $(LIB)
> >
> > Not sure if using another dts file will be the best approach.
> > From my point of view will be the best to support only one dts file
> > (without dtsi)
> > because it is much cleaner then using 3 dts files.
> >
>
> Well there is no inherent problem with having multiple include files,
> except that it is hard to support with the old dtc when there are in
> different subdirs.
>
> As a workaround, how about putting the include files in the
> board/vendor/dts subdir as well for now?Hi,
good idea -- but they cannot be used directly. The substitution variable
ARCH_CPU_DTSis already reserved for dtsi inarch/cpu. The Microblaze architecture needs a board specific dts onyl. That's why I think the new substitution variableBOARD_DTScan be a option to solve the CPP problem today and handle the dtc -i in the future.
BOARD_DTScan point to anything below board/vendor and perhaps with a new configuration option similar toCONFIG_DEFAULT_DEVICE_TREEthe substitution could be affected with freely selectable file name instead ofDEVICE_TREEonly.
Quoted 3 lines
Just in case there is any confusion here...
The device tree file is not necessarily intended to be built with/by the U-Boot
Makefile.
Yes it is convenient to do that, but where you have multiple board variants it is actually best to have the Makefile build U-Boot without a device tree, i.e. no need to select the particular board variant.
Quoted 9 lines
Then, in a separate step:
for board in ${list_of_available_boards}; do
dtc ... ${board}.dts cat u-boot.bin ${board}.dtb >u-boot-${board}.bindone
I mention this because if we make U-Boot build the particular board variant,
then have we actually achieved the goal of a single U-Boot image that supports multiple boards?
Quoted 2 lines
So IMO the infrastructure to support the post-processing of U-Boot binaries and device trees
may not in fact belong in the U-Boot Makefile. It is convenient to be able to specify a device tree for U-Boot to pick up and build, but I don't think it should come from the boards.cfg file -
after all the whole point is that we support a number of build variants.
The board name in boards.cfg will be something generic, like microblaze-dt, or similar.
Quoted 2 lines
I hope that makes sense.
Yes, I am aware about it and make sense.
I am not sure if we can use only one u-boot binary for Microblaze with different device tree because cpu has several variants (Sure we could use the minimum configuration but it is not the best solution from performance point of view). Also ram baseaddr can vary. This can be skip by using MMU but also I don't think that this is good solution for bootloader.
But I think that we could end with generated config.mk file with compilation flags for cpu variants and u-boot start address.
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Quoted 151 lines · Stephan Linz
Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
Quoted 135 lines
Hi,
Quoted 123 lines · Michal Simek
2012/6/29 Stephan Linz<[email protected]>:
Quoted 7 lines
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
I have sent support for Microblaze. Currently without dts because I
want to clear this part a little bit.
Quoted 8 lines
Hi Michal,
looks good, I've been waiting a long time on the FDT support in U-Boot for Microblaze -- great -- PS: see my comment on patch 5 ...
Quoted 2 lines
Tegra is using
./arch/arm/dts/tegra20.dtsiand
board/nvidia/dts/tegra2-seaboard.dtsQuoted 2 lines
Quoted 2 lines
and they are composed together in dts/Makefile by calling preprocessor. Microblaze will be totally different case because every Microblaze hw
design is different.
Quoted 5 lines
Yes, that's right. We will never be in the position to define a skeleton or a basic platform configuration.
Quoted 1 line
We can use two main buses (little and big endian) and cpu is also
configurable.
Quoted 4 lines
Quoted 2 lines
Based on this for Microblaze is the best solution directly to use dts. (DTS for Microblaze is also generated directly from design tool).
... directly in the context of a board, not
arch/cpu, right?yes.
Quoted 4 lines
Quoted 4 lines
Anyway - here is the bug message I am getting if I use full dts in
board/<name>/dts/microblaze.dts
Quoted 17 lines
Quoted 17 lines
and empty
arch/microblaze/dts/microblaze.dtsi<stdin>:34:3: error: invalid preprocessing directive #address <stdin>:35:3: error: invalid preprocessing directive #size <stdin>:52:4: error: invalid preprocessing directive #address <stdin>:53:4: error: invalid preprocessing directive #cpus <stdin>:54:4: error: invalid preprocessing directive #size <stdin>:155:4: error: invalid preprocessing directive #address <stdin>:156:4: error: invalid preprocessing directive #size <stdin>:160:5: error: invalid preprocessing directive #gpio <stdin>:192:5: error: invalid preprocessing directive #gpio <stdin>:209:5: error: invalid preprocessing directive #gpio <stdin>:241:5: error: invalid preprocessing directive #gpio <stdin>:267:5: error: invalid preprocessing directive #address <stdin>:268:5: error: invalid preprocessing directive #size <stdin>:394:5: error: invalid preprocessing directive #interrupt
Quoted 1 line
Quoted 1 line
This is error for opposite case - empty
microblaze.dtsand full
microblaze.dtsi.Quoted 3 lines
That are CPP errors, because the auto generated
xilinx.dtsis full of CPP pragma like syntax (#something) that are wrong (invalid).I know what it is.
Quoted 4 lines
Quoted 4 lines
make[1]: Entering directory `/mnt/projects/u-boot/dts' rc=$( cat
/mnt/projects/u-boot/board/petalogix/dts/microblaze.dts|microblaze-unknown-linux-gnu-gcc -E
Quoted 1 line
Quoted 1 line
-P
-DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
- | { { dtc -R 4 -p0x1000Quoted 1 line
Quoted 1 line
-O dtb -o dt.dtb - 2>&1 ; echo $?>&3 ; } | grep -v '^DTC:
dts->dtbonfile' ; } 3>&1 ) ; \
Quoted 7 lines
Quoted 7 lines
exit $rc
/bin/sh: line 1: exit: too many arguments make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'I have just tried to fix it by introducing new CONFIG option for
skipping that preprocessor
Quoted 41 lines
Quoted 1 line
part.
Instead of disable / skipp the CPP step you can hide the auto generated
xilinx.dtswith a second include stage, for example:
board/microblaze/dts/microblaze.dtslooks like:/include/
ARCH_CPU_DTS
/include/BOARD_DTSRight, only two lines. The
arch/microblaze/dts/microblaze.dtsiremains
empty as you have said above. Just new isBOARD_DTS-- with the attached patch for dts/Makefile you can copy the auto generatedxilinx.dtsinto the specific board directory and the CPP step substitute the right place toboard/microblaze/microblaze-generic/dts/microblaze.dtsI think there are no side effects with other ports like the tegra2.
If you want you can omit the
ARCH_CPU_DTSinclusion. The architecturalmicroblaze.dtsifile is empty and (!!) have to be empty, because the DTC will break with an error on multiple "/dts-v1/;" lines!Here is the patch:
dts/Makefile +0
-1@@ -36,7 +36,8 @@ $(error Your architecture does not have device tree support enabled. \ Please define CONFIG_ARCH_DEVICE_TREE)) # We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -DARCH_CPU_DTS=\"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" +DTS_CPPFLAGS := -DARCH_CPU_DTS= \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
+ -DBOARD_DTS=
\"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"Quoted 7 lines
Quoted 1 line
all: $(obj).depend $(LIB)
Not sure if using another dts file will be the best approach.
From my point of view will be the best to support only one dts file
(without dtsi)
because it is much cleaner then using 3 dts files.Quoted 6 lines
Well there is no inherent problem with having multiple include files, except that it is hard to support with the old dtc when there are in different subdirs.
As a workaround, how about putting the include files in the board/vendor/dts subdir as well for now?
Hi,
good idea -- but they cannot be used directly. The substitution variable
ARCH_CPU_DTSis already reserved for dtsi inarch/cpu. The Microblaze architecture needs a board specific dts onyl. That's why I think the new substitution variableBOARD_DTScan be a option to solve the CPP problem today and handle the dtc -i in the future.
Quoted 4 lines
BOARD_DTScan point to anything below board/vendor and perhaps with a new configuration option similar toCONFIG_DEFAULT_DEVICE_TREEthe substitution could be affected with freely selectable file name instead ofDEVICE_TREEonly.
ok.
Stephan: go ahead and create proper patch with empty dts/dtsi files.
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Am Mittwoch, den 04.07.2012, 08:24 +0200 schrieb Michal Simek:
Quoted 37 lines · Stephan Linz
Quoted 30 lines
Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
Quoted 14 lines
Hi,
Quoted 9 lines · Michal Simek
2012/6/29 Stephan Linz<[email protected]>:
Quoted 7 lines
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
Quoted 6 lines
Well there is no inherent problem with having multiple include files, except that it is hard to support with the old dtc when there are in different subdirs.
As a workaround, how about putting the include files in the board/vendor/dts subdir as well for now?
Hi,
good idea -- but they cannot be used directly. The substitution variable
ARCH_CPU_DTSis already reserved for dtsi inarch/cpu. The Microblaze architecture needs a board specific dts onyl. That's why I think the new substitution variableBOARD_DTScan be a option to solve the CPP problem today and handle the dtc -i in the future.Quoted 4 lines
BOARD_DTScan point to anything below board/vendor and perhaps with a new configuration option similar toCONFIG_DEFAULT_DEVICE_TREEthe substitution could be affected with freely selectable file name instead ofDEVICE_TREEonly.
Quoted 3 lines
ok.
Stephan: go ahead and create proper patch with empty dts/dtsi files.
Hi Michal,
see my patch set, that I've already submitted. The patches are based on your patch set from last week. I've create a bundle on patchwork:
http://patchwork.ozlabs.org/bundle/rexut/microblaze-fdt/
Further you will need a QnD hack to avoid a compilation error due to type conflicts (I've not explored here, not yet):
In file included from key_matrix.c:28:include/malloc.h:364: error: conflicting types for 'memset' include/linux/string.h:71: error: previous declaration of 'memset' was hereinclude/malloc.h:365: error: conflicting types for 'memcpy' include/linux/string.h:74: error: previous declaration of 'memcpy' was here
Here is the QnD hack:
drivers/input/Makefile +0 -0
@@ -32,7 +32,7 @@ COBJS-y += keyboard.o pc_keyb.o
COBJS-$(CONFIG_PS2MULT) += ps2mult.o ps2ser.o
endif
COBJS-y += input.o
-COBJS-$(CONFIG_OF_CONTROL) += key_matrix.o
+#COBJS-$(CONFIG_OF_CONTROL) += key_matrix.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
br,
Stephan
On 07/04/2012 12:02 AM, Michal Simek wrote:
...
Quoted 1 line
What is the problem to add the latest dtc?
To really make use of device tree you need a recent dtc, but we've had pushback requiring a recent dtc because people may not have it installed. I asked Wolfgang a while back whether we could just put a copy of dtc into the U-Boot source tree to avoid this issue, just like the kernel did, but simply haven't received any response. Perhaps the best thing is to just send a patch to do this; patches often get more responses than non-patch email.
Quoted 75 lines · Stephan Linz
Am Mittwoch, den 04.07.2012, 08:24 +0200 schrieb Michal Simek:
Quoted 37 lines · Stephan Linz
Quoted 30 lines
Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
Quoted 14 lines
Hi,
Quoted 9 lines · Michal Simek
2012/6/29 Stephan Linz<[email protected]>:
Quoted 7 lines
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
Quoted 6 lines · Simon Glass
Quoted 3 lines
Hi,
--snip--
Quoted 6 lines
Well there is no inherent problem with having multiple include files, except that it is hard to support with the old dtc when there are in different subdirs.
As a workaround, how about putting the include files in the board/vendor/dts subdir as well for now?
Hi,
good idea -- but they cannot be used directly. The substitution variable
ARCH_CPU_DTSis already reserved for dtsi inarch/cpu. The Microblaze architecture needs a board specific dts onyl. That's why I think the new substitution variableBOARD_DTScan be a option to solve the CPP problem today and handle the dtc -i in the future.Quoted 4 lines
BOARD_DTScan point to anything below board/vendor and perhaps with a new configuration option similar toCONFIG_DEFAULT_DEVICE_TREEthe substitution could be affected with freely selectable file name instead ofDEVICE_TREEonly.Quoted 3 lines
ok.
Stephan: go ahead and create proper patch with empty dts/dtsi files.
Hi Michal,
see my patch set, that I've already submitted. The patches are based on your patch set from last week. I've create a bundle on patchwork:
http://patchwork.ozlabs.org/bundle/rexut/microblaze-fdt/
Further you will need a QnD hack to avoid a compilation error due to type conflicts (I've not explored here, not yet):
In file included from key_matrix.c:28:
include/malloc.h:364: error: conflicting types for 'memset'include/linux/string.h:71: error: previous declaration of 'memset' was hereinclude/malloc.h:365: error: conflicting types for 'memcpy'include/linux/string.h:74: error: previous declaration of 'memcpy' was hereHere is the QnD hack:
drivers/input/Makefile +0
-0@@ -32,7 +32,7 @@ COBJS-y += keyboard.o pc_keyb.oCOBJS-$(CONFIG_PS2MULT) += ps2mult.o ps2ser.o
endif
COBJS-y += input.odrivers/input/Makefile +1
-1-COBJS-$(CONFIG_OF_CONTROL) += key_matrix.o +#COBJS-$(CONFIG_OF_CONTROL) += key_matrix.o
Quoted 2 lines
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
Yes, I have seen this too. I did this.
drivers/input/key_matrix.c +1 -1
@@ -25,7 +25,7 @@#include <fdtdec.h> #include <key_matrix.h> -#include <malloc.h> +//#include <malloc.h> #include <linux/input.h>
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian
Quoted 11 lines · Stephen Warren
On 07/04/2012 12:02 AM, Michal Simek wrote:
...Quoted 1 line
What is the problem to add the latest dtc?
To really make use of device tree you need a recent dtc, but we've had pushback requiring a recent dtc because people may not have it installed. I asked Wolfgang a while back whether we could just put a copy of dtc into the U-Boot source tree to avoid this issue, just like the kernel did, but simply haven't received any response. Perhaps the best thing is to just send a patch to do this; patches often get more responses than non-patch email.
Yeah. When you send the patch, please cc me. I will test it with microblaze.
Thanks,
Michal
Signature · 4 lines
Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian