[U-Boot] ARM CONFIG_OF_CONTROL status

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

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
>

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

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
>

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

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
>

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

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
>

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Stephan Linz]

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>

[U-Boot] ARM CONFIG_OF_CONTROL status

[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.

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

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
> >
>
>
>

[U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[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?

Regards,
Simon


>
> Thanks,
> Michal
>

[U-Boot] ARM CONFIG_OF_CONTROL status

[Stephan Linz]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Stephan Linz]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

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
>
>
>
>
>

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[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--
>>>>>
>>>>> 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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Stephan Linz]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Stephen Warren]

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.

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

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