[U-Boot] 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
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek monstr@monstr.eu 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).
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
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,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr@monstr.eu mailto:monstr@monstr.eu> 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" ); 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
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek monstr@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 <monstr@monstr.eu mailto: monstr@monstr.eu> 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()
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.
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.
What was the reason to use compat_names table in fdtdec.c file?
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
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,
On 06/28/2012 03:10 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr@monstr.eu mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>> 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?
What was the reason to use compat_names table in fdtdec.c file?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
Hi Michal,
On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek monstr@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 <monstr@monstr.eu mailto: monstr@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 <monstr@monstr.eu<mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu mailto:monstr@monstr.eu>> wrote:
Hi, can you please update me about current state ofCONFIG_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 Chromiumtree and being upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Has someone tried to look for devices based on compatibleproperty? 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 inthe 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 asingle 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 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
What was the reason to use compat_names table in fdtdec.c file?
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.
Fair enough. If you don't want to I don't see why it should be a hard requirement.
Regards, Simon
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
On 06/28/2012 07:57 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <monstr@monstr.eu mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>>> 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.
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
Can you also send me link to Chromium tree?
I am going to send RFC for emaclite driver and cleanup Microblaze port.
Thanks, Michal
Hi,
On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek monstr@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 <monstr@monstr.eu mailto: monstr@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 <monstr@monstr.eu<mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu mailto:monstr@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 <monstr@monstr.eu mailto:monstr@monstr.eu <mailto:monstr@monstr.eumailto: monstr@monstr.eu> <mailto:monstr@monstr.eu mailto:monstr@monstr.eu <mailto:monstr@monstr.eu mailto:monstr@monstr.eu>>> wrote:
Hi, can you please update me about current state ofCONFIG_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 theChromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).
ok. Has someone tried to look for devices based oncompatible 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 allowthis 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 USBsupports 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 ethernetinitialization 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 aliaseslist 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'treally 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
Can you also send me link to Chromium tree?
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.
Great!
Regards, Simon
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
On 06/29/2012 04:32 AM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <monstr@monstr.eu mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>>>> 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. 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 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.
diff --git a/dts/Makefile b/dts/Makefile index 914e479..d670cb8 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -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
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.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.
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 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.
That are CPP errors, because the auto generated xilinx.dts is full of CPP pragma like syntax (#something) that are wrong (invalid).
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.
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:
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 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
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.
diff --git a/dts/Makefile b/dts/Makefile index 914e479..d670cb8 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -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
2012/6/29 Stephan Linz linz@li-pro.net:
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.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.
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?
yes.
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.
That are CPP errors, because the auto generated xilinx.dts is 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 -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.
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:
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 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)
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.
Thanks, Michal
Hi,
On Sun, Jul 1, 2012 at 10:43 PM, Michal Simek monstr@monstr.eu wrote:
2012/6/29 Stephan Linz linz@li-pro.net:
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.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.
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?
yes.
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.
That are CPP errors, because the auto generated xilinx.dts is 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 -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.
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:
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 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)
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
Thanks, Michal
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@monstr.eu wrote:
2012/6/29 Stephan Linz linz@li-pro.net:
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.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.
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?
yes.
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.
That are CPP errors, because the auto generated xilinx.dts is 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 -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.
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:
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 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)
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_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
Regards, Simon
Thanks, Michal
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi,
On Tue, Jul 3, 2012 at 1:22 PM, Stephan Linz linz@li-pro.net 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@monstr.eu wrote:
2012/6/29 Stephan Linz linz@li-pro.net:
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.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.
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?
yes.
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.
That are CPP errors, because the auto generated xilinx.dts is 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 -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.
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:
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 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)
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_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.
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
br, Stephan
Regards, Simon
Thanks, Michal
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 07/04/2012 03:48 AM, Simon Glass wrote:
Hi,
On Tue, Jul 3, 2012 at 1:22 PM, Stephan Linz <linz@li-pro.net mailto:linz@li-pro.net> 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@monstr.eu <mailto:monstr@monstr.eu>> wrote: > > > 2012/6/29 Stephan Linz <linz@li-pro.net <mailto:linz@li-pro.net>>: > > > 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.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. > > > > > > 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? > > > > yes. > > > > > > > >> > > >> > > >> 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. > > > > > > That are CPP errors, because the auto generated xilinx.dts is 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 -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. > > > > > > 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: > > > > > > 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 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) > > > > 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_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.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.
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
On 07/03/2012 10:22 PM, Stephan Linz wrote:
Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
Hi,
On Sun, Jul 1, 2012 at 10:43 PM, Michal Simekmonstr@monstr.eu wrote:
2012/6/29 Stephan Linzlinz@li-pro.net:
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.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.
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?
yes.
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.
That are CPP errors, because the auto generated xilinx.dts is 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 -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.
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:
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 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)
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_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.
ok.
Stephan: go ahead and create proper patch with empty dts/dtsi files.
Thanks, Michal
Am Mittwoch, den 04.07.2012, 08:24 +0200 schrieb Michal Simek:
On 07/03/2012 10:22 PM, Stephan Linz wrote:
Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
Hi,
On Sun, Jul 1, 2012 at 10:43 PM, Michal Simekmonstr@monstr.eu wrote:
2012/6/29 Stephan Linzlinz@li-pro.net:
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
On 06/29/2012 04:32 AM, Simon Glass wrote: > Hi, > > --snip--
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.
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 here include/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:
diff --git a/drivers/input/Makefile b/drivers/input/Makefile index 5c831b2..5efeeb3 100644 --- a/drivers/input/Makefile +++ b/drivers/input/Makefile @@ -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 10:27 PM, Stephan Linz wrote:
Am Mittwoch, den 04.07.2012, 08:24 +0200 schrieb Michal Simek:
On 07/03/2012 10:22 PM, Stephan Linz wrote:
Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
Hi,
On Sun, Jul 1, 2012 at 10:43 PM, Michal Simekmonstr@monstr.eu wrote:
2012/6/29 Stephan Linzlinz@li-pro.net:
Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek: > On 06/29/2012 04:32 AM, Simon Glass wrote: >> Hi, >> >> --snip-- > >
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.
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 here include/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:
diff --git a/drivers/input/Makefile b/drivers/input/Makefile index 5c831b2..5efeeb3 100644 --- a/drivers/input/Makefile +++ b/drivers/input/Makefile @@ -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)
Yes, I have seen this too. I did this.
diff --git a/drivers/input/key_matrix.c b/drivers/input/key_matrix.c index 84b898f..804a761 100644 (file) --- a/drivers/input/key_matrix.c +++ b/drivers/input/key_matrix.c @@ -25,7 +25,7 @@
#include <fdtdec.h> #include <key_matrix.h> -#include <malloc.h> +//#include <malloc.h> #include <linux/input.h>
Thanks, Michal
Hi,
Am Montag, den 02.07.2012, 07:43 +0200 schrieb Michal Simek:
2012/6/29 Stephan Linz linz@li-pro.net:
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.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.
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?
yes.
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.
That are CPP errors, because the auto generated xilinx.dts is 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 -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.
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:
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 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)
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 ...
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
because it is much cleaner then using 3 dts files.
Thanks, Michal _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi,
On Fri, Jun 29, 2012 at 1:22 PM, Stephan Linz linz@li-pro.net 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.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.
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 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.
That are CPP errors, because the auto generated xilinx.dts is 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.
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.
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:
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 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)
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
br, Stephan
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.
diff --git a/dts/Makefile b/dts/Makefile index 914e479..d670cb8 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -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
On 07/03/2012 09:05 PM, Simon Glass wrote:
Hi,
On Fri, Jun 29, 2012 at 1:22 PM, Stephan Linz <linz@li-pro.net mailto:linz@li-pro.net> 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.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. 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 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. That are CPP errors, because the auto generated xilinx.dts is 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
> > 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. 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: 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 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)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
On 07/04/2012 12:02 AM, Michal Simek wrote: ...
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.
On 07/05/2012 05:34 PM, Stephen Warren wrote:
On 07/04/2012 12:02 AM, Michal Simek wrote: ...
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
On 06/29/2012 04:32 AM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <monstr@monstr.eu mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>>>> 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. 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 Can you also send me link to Chromium tree?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
Hi,
On Tue, Jul 3, 2012 at 2:21 AM, Michal Simek monstr@monstr.eu wrote:
On 06/29/2012 04:32 AM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <monstr@monstr.eu mailto: monstr@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 <monstr@monstr.eu<mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu mailto:monstr@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 <monstr@monstr.eu mailto:monstr@monstr.eu <mailto:monstr@monstr.eumailto: monstr@monstr.eu> <mailto:monstr@monstr.eu mailto:monstr@monstr.eu <mailto:monstr@monstr.eu mailto:monstr@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 <monstr@monstr.eu mailto:monstr@monstr.eu <mailto:monstr@monstr.eumailto: monstr@monstr.eu> <mailto:monstr@monstr.eu mailto:monstr@monstr.eu <mailto:monstr@monstr.eu mailto:monstr@monstr.eu>> <mailto: monstr@monstr.eu mailto:monstr@monstr.eu <mailto:monstr@monstr.eumailto: monstr@monstr.eu> <mailto:monstr@monstr.eu mailto:monstr@monstr.eu <mailto:monstr@monstr.eu mailto:monstr@monstr.eu>>>> wrote:
Hi, can you please update me about current stateof 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 happeningin the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet).
ok. Has someone tried to look for devices basedon 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 whichwould 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 exampleUSB 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 onMicroblaze.
Firstly I have tried to change emaclite ethernetinitialization 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 parseDTS 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 toupstreaming 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 andmemory 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
Can you also send me link to Chromium tree?Yes this should work:
https://git.chromium.org/git/**chromiumos/third_party/u-boot.**githttps://git.chromium.org/git/chromiumos/third_party/u-boot.git
I am going to send RFC for emaclite driver and cleanup Microblazeport.
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.
But doesn't it use the built-in environment instead in this case? It should...
Can you please check it?
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
Regards, Simon
On 07/03/2012 09:07 PM, Simon Glass wrote:
Hi,
On Tue, Jul 3, 2012 at 2:21 AM, Michal Simek <monstr@monstr.eu mailto:monstr@monstr.eu> wrote:
On 06/29/2012 04:32 AM, Simon Glass wrote: Hi, On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@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 <monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu <mailto:monstr@monstr.eu>>>>>> 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. 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 Can 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); 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.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
participants (4)
-
Michal Simek -
Simon Glass -
Stephan Linz -
Stephen Warren