[U-Boot] [PATCH] qemu-ppce500: Update get_phys_ccsrbar_addr_early()

[Simon Glass]

Hi Tom,

On 3 August 2017 at 08:09, Tom Rini <trini at konsulko.com> wrote:
> On Thu, Aug 03, 2017 at 08:04:33AM -0600, Simon Glass wrote:
>> Hi Tom,
>>
>> On 3 August 2017 at 07:16, Tom Rini <trini at konsulko.com> wrote:
>> > The logic of what fdt_get_base_address() will search for and return has
>> > changed.  Rework get_phys_ccsrbar_addr_early() to perform the logic that
>> > fdt_get_base_address used to perform.
>> >
>> > Fixes: 336a44877af8 ("fdt: Correct fdt_get_base_address()")
>> > Cc: Simon Glass <sjg at chromium.org>
>> > Cc: Alexander Graf <agraf at suse.de>
>> > Signed-off-by: Tom Rini <trini at konsulko.com>
>> > ---
>> >  board/freescale/qemu-ppce500/qemu-ppce500.c | 8 +++++++-
>> >  1 file changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
>> > index 6cb5692eda6e..0c65ec72d209 100644
>> > --- a/board/freescale/qemu-ppce500/qemu-ppce500.c
>> > +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
>> > @@ -50,13 +50,19 @@ uint64_t get_phys_ccsrbar_addr_early(void)
>> >  {
>> >         void *fdt = get_fdt_virt();
>> >         uint64_t r;
>> > +       int size, node;
>> > +       u32 naddr;
>> > +       const fdt32_t *prop;
>> >
>> >         /*
>> >          * To be able to read the FDT we need to create a temporary TLB
>> >          * map for it.
>> >          */
>> >         map_fdt_as(10);
>> > -       r = fdt_get_base_address(fdt, fdt_path_offset(fdt, "/soc"));
>> > +       node = fdt_path_offset(fdt, "/soc");
>> > +       naddr = fdt_address_cells(fdt, node);
>> > +       prop = fdt_getprop(fdt, node, "ranges", &size);
>> > +       r = fdt_translate_address(fdt, node, prop + naddr);
>>
>> Reviewed-by: Simon Glass <sjg at chromium.org>
>>
>> Maybe that function wasn't supposed to do what I thought? With no
>> comments on it, it's not really possible to divine intent.
>>
>> From what I can tell this is reading a DT that is stored somewhere,
>> but it isn't using CONFIG_OF_CONTROL, right?
>
> Correct.  QEMU passes in a DTB file to us (or the kernel) and then we
> make use of it.

The really strange thing about this uncommented function and code is
that it appears to return the size of the peripheral, not the address.
That 'prop + naddr' threally confused me. Anyway from what I can tell
you have replicated the behaviour.

Regards,
Simon