* [U-Boot] ARM CONFIG_OF_CONTROL status @ 2012-06-27 9:29 Michal Simek 2012-06-27 13:58 ` Simon Glass 0 siblings, 1 reply; 26+ messages in thread From: Michal Simek @ 2012-06-27 9:29 UTC (permalink / raw) To: u-boot 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 -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-27 9:29 [U-Boot] ARM CONFIG_OF_CONTROL status Michal Simek @ 2012-06-27 13:58 ` Simon Glass 2012-06-27 14:35 ` Michal Simek 0 siblings, 1 reply; 26+ messages in thread From: Simon Glass @ 2012-06-27 13:58 UTC (permalink / raw) To: u-boot 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-27 13:58 ` Simon Glass @ 2012-06-27 14:35 ` Michal Simek 2012-06-28 1:10 ` Simon Glass 0 siblings, 1 reply; 26+ messages in thread From: Michal Simek @ 2012-06-27 14:35 UTC (permalink / raw) To: u-boot Hi Simon, On 06/27/2012 03:58 PM, Simon Glass wrote: > Hi, > > On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr at monstr.eu <mailto: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 -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-27 14:35 ` Michal Simek @ 2012-06-28 1:10 ` Simon Glass 2012-06-28 5:50 ` Michal Simek 0 siblings, 1 reply; 26+ messages in thread From: Simon Glass @ 2012-06-28 1:10 UTC (permalink / raw) To: u-boot 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 at 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-28 1:10 ` Simon Glass @ 2012-06-28 5:50 ` Michal Simek 2012-06-28 5:57 ` Simon Glass 0 siblings, 1 reply; 26+ messages in thread From: Michal Simek @ 2012-06-28 5:50 UTC (permalink / raw) To: u-boot Hi Simon, On 06/28/2012 03:10 AM, Simon Glass wrote: > Hi Michal, > > On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr at monstr.eu <mailto: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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-28 5:50 ` Michal Simek @ 2012-06-28 5:57 ` Simon Glass 2012-06-28 6:49 ` Michal Simek 0 siblings, 1 reply; 26+ messages in thread From: Simon Glass @ 2012-06-28 5:57 UTC (permalink / raw) To: u-boot 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 at monstr.eu>> wrote: >> >> Hi Simon, >> >> >> On 06/27/2012 03:58 PM, Simon Glass wrote: >> >> Hi, >> >> >> On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <monstr@monstr.eu<mailto: >> monstr at monstr.eu> <mailto:monstr at 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 > > > >> >> 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-28 5:57 ` Simon Glass @ 2012-06-28 6:49 ` Michal Simek 2012-06-29 2:32 ` Simon Glass 0 siblings, 1 reply; 26+ messages in thread From: Michal Simek @ 2012-06-28 6:49 UTC (permalink / raw) To: u-boot On 06/28/2012 07:57 AM, Simon Glass wrote: > Hi Michal, > > On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <monstr at monstr.eu <mailto: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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-28 6:49 ` Michal Simek @ 2012-06-29 2:32 ` Simon Glass 2012-06-29 8:18 ` Michal Simek 2012-07-03 9:21 ` Michal Simek 0 siblings, 2 replies; 26+ messages in thread From: Simon Glass @ 2012-06-29 2:32 UTC (permalink / raw) To: u-boot 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 at monstr.eu>> wrote: >> >> Hi Simon, >> >> >> On 06/28/2012 03:10 AM, Simon Glass wrote: >> >> Hi Michal, >> >> >> On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <monstr@monstr.eu<mailto: >> monstr at monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu<mailto: >> monstr at monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> >> <mailto:monstr at 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. 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-29 2:32 ` Simon Glass @ 2012-06-29 8:18 ` Michal Simek 2012-06-29 20:22 ` Stephan Linz 2012-07-03 9:21 ` Michal Simek 1 sibling, 1 reply; 26+ messages in thread From: Michal Simek @ 2012-06-29 8:18 UTC (permalink / raw) To: u-boot On 06/29/2012 04:32 AM, Simon Glass wrote: > Hi, > > On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <monstr at monstr.eu <mailto: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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 -- 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 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-29 8:18 ` Michal Simek @ 2012-06-29 20:22 ` Stephan Linz 2012-07-02 5:43 ` Michal Simek 2012-07-03 19:05 ` Simon Glass 0 siblings, 2 replies; 26+ messages in thread From: Stephan Linz @ 2012-06-29 20:22 UTC (permalink / raw) To: u-boot 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: dts-Makefile-BOARD_DTS.patch Type: text/x-patch Size: 606 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120629/d3cde911/attachment.bin> ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-29 20:22 ` Stephan Linz @ 2012-07-02 5:43 ` Michal Simek 2012-07-03 19:21 ` Simon Glass 2012-07-03 19:38 ` Stephan Linz 2012-07-03 19:05 ` Simon Glass 1 sibling, 2 replies; 26+ messages in thread From: Michal Simek @ 2012-07-02 5:43 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-02 5:43 ` Michal Simek @ 2012-07-03 19:21 ` Simon Glass 2012-07-03 20:22 ` Stephan Linz 2012-07-03 19:38 ` Stephan Linz 1 sibling, 1 reply; 26+ messages in thread From: Simon Glass @ 2012-07-03 19:21 UTC (permalink / raw) To: u-boot 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-03 19:21 ` Simon Glass @ 2012-07-03 20:22 ` Stephan Linz 2012-07-04 1:48 ` Simon Glass 2012-07-04 6:24 ` Michal Simek 0 siblings, 2 replies; 26+ messages in thread From: Stephan Linz @ 2012-07-03 20:22 UTC (permalink / raw) To: u-boot 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 at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-03 20:22 ` Stephan Linz @ 2012-07-04 1:48 ` Simon Glass 2012-07-04 6:13 ` Michal Simek 2012-07-04 6:24 ` Michal Simek 1 sibling, 1 reply; 26+ messages in thread From: Simon Glass @ 2012-07-04 1:48 UTC (permalink / raw) To: 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 at lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-04 1:48 ` Simon Glass @ 2012-07-04 6:13 ` Michal Simek 0 siblings, 0 replies; 26+ messages in thread From: Michal Simek @ 2012-07-04 6:13 UTC (permalink / raw) To: 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 at 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 at monstr.eu <mailto:monstr@monstr.eu>> wrote: > > > > > 2012/6/29 Stephan Linz <linz at 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 -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-03 20:22 ` Stephan Linz 2012-07-04 1:48 ` Simon Glass @ 2012-07-04 6:24 ` Michal Simek 2012-07-04 20:27 ` Stephan Linz 1 sibling, 1 reply; 26+ messages in thread From: Michal Simek @ 2012-07-04 6:24 UTC (permalink / raw) To: u-boot 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 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. ok. Stephan: go ahead and create proper patch with empty dts/dtsi files. 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-04 6:24 ` Michal Simek @ 2012-07-04 20:27 ` Stephan Linz 2012-07-09 7:58 ` Michal Simek 0 siblings, 1 reply; 26+ messages in thread From: Stephan Linz @ 2012-07-04 20:27 UTC (permalink / raw) To: u-boot 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 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-- > >>>>> > >>>>> > >>> > >> > >> 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 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-04 20:27 ` Stephan Linz @ 2012-07-09 7:58 ` Michal Simek 0 siblings, 0 replies; 26+ messages in thread From: Michal Simek @ 2012-07-09 7:58 UTC (permalink / raw) To: u-boot 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 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-- >>>>>>> >>>>>>> >>>>> >>>> >>>> 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 -- 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 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-02 5:43 ` Michal Simek 2012-07-03 19:21 ` Simon Glass @ 2012-07-03 19:38 ` Stephan Linz 1 sibling, 0 replies; 26+ messages in thread From: Stephan Linz @ 2012-07-03 19:38 UTC (permalink / raw) To: u-boot 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 at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-29 20:22 ` Stephan Linz 2012-07-02 5:43 ` Michal Simek @ 2012-07-03 19:05 ` Simon Glass 2012-07-04 6:02 ` Michal Simek 1 sibling, 1 reply; 26+ messages in thread From: Simon Glass @ 2012-07-03 19:05 UTC (permalink / raw) To: 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 > > > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-03 19:05 ` Simon Glass @ 2012-07-04 6:02 ` Michal Simek 2012-07-05 15:34 ` Stephen Warren 0 siblings, 1 reply; 26+ messages in thread From: Michal Simek @ 2012-07-04 6:02 UTC (permalink / raw) To: u-boot On 07/03/2012 09:05 PM, Simon Glass wrote: > Hi, > > On Fri, Jun 29, 2012 at 1:22 PM, Stephan Linz <linz at 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-04 6:02 ` Michal Simek @ 2012-07-05 15:34 ` Stephen Warren 2012-07-09 7:59 ` Michal Simek 0 siblings, 1 reply; 26+ messages in thread From: Stephen Warren @ 2012-07-05 15:34 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-05 15:34 ` Stephen Warren @ 2012-07-09 7:59 ` Michal Simek 0 siblings, 0 replies; 26+ messages in thread From: Michal Simek @ 2012-07-09 7:59 UTC (permalink / raw) To: u-boot 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 -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-06-29 2:32 ` Simon Glass 2012-06-29 8:18 ` Michal Simek @ 2012-07-03 9:21 ` Michal Simek 2012-07-03 19:07 ` Simon Glass 1 sibling, 1 reply; 26+ messages in thread From: Michal Simek @ 2012-07-03 9:21 UTC (permalink / raw) To: u-boot On 06/29/2012 04:32 AM, Simon Glass wrote: > Hi, > > On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <monstr at monstr.eu <mailto: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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-03 9:21 ` Michal Simek @ 2012-07-03 19:07 ` Simon Glass 2012-07-04 5:46 ` Michal Simek 0 siblings, 1 reply; 26+ messages in thread From: Simon Glass @ 2012-07-03 19:07 UTC (permalink / raw) To: u-boot 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 at monstr.eu>> wrote: >> >> On 06/28/2012 07:57 AM, Simon Glass wrote: >> >> Hi Michal, >> >> >> On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <monstr@monstr.eu<mailto: >> monstr at monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu<mailto: >> monstr at monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> >> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu<mailto: >> monstr at monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> >> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>>> <mailto: >> monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr@monstr.eu<mailto: >> monstr at monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> >> <mailto:monstr at 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... > > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] ARM CONFIG_OF_CONTROL status 2012-07-03 19:07 ` Simon Glass @ 2012-07-04 5:46 ` Michal Simek 0 siblings, 0 replies; 26+ messages in thread From: Michal Simek @ 2012-07-04 5:46 UTC (permalink / raw) To: u-boot On 07/03/2012 09:07 PM, Simon Glass wrote: > Hi, > > On Tue, Jul 3, 2012 at 2:21 AM, Michal Simek <monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>>>> > <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu>> <mailto:monstr at monstr.eu <mailto:monstr@monstr.eu> <mailto:monstr at 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 -- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2012-07-09 7:59 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-27 9:29 [U-Boot] ARM CONFIG_OF_CONTROL status Michal Simek 2012-06-27 13:58 ` Simon Glass 2012-06-27 14:35 ` Michal Simek 2012-06-28 1:10 ` Simon Glass 2012-06-28 5:50 ` Michal Simek 2012-06-28 5:57 ` Simon Glass 2012-06-28 6:49 ` Michal Simek 2012-06-29 2:32 ` Simon Glass 2012-06-29 8:18 ` Michal Simek 2012-06-29 20:22 ` Stephan Linz 2012-07-02 5:43 ` Michal Simek 2012-07-03 19:21 ` Simon Glass 2012-07-03 20:22 ` Stephan Linz 2012-07-04 1:48 ` Simon Glass 2012-07-04 6:13 ` Michal Simek 2012-07-04 6:24 ` Michal Simek 2012-07-04 20:27 ` Stephan Linz 2012-07-09 7:58 ` Michal Simek 2012-07-03 19:38 ` Stephan Linz 2012-07-03 19:05 ` Simon Glass 2012-07-04 6:02 ` Michal Simek 2012-07-05 15:34 ` Stephen Warren 2012-07-09 7:59 ` Michal Simek 2012-07-03 9:21 ` Michal Simek 2012-07-03 19:07 ` Simon Glass 2012-07-04 5:46 ` Michal Simek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.