[U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass <sjg@chromium.org>]

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