On Mon, 2 Mar 2009 08:08:02 -0700, Grant Likely <grant.lik...@secretlab.ca>
wrote:
> On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche <m...@it-loops.com>
wrote:
> You mean like loading it of the CF or something? Yeah, I suppose so
> if you wrote a minimal CF driver, but that seems the hard way around
> also. You're far better off to statically link in a .dtb image and
> modify it. If the bootloader doesn't provide you with any useful
> information, you can read the SoC registers to detect memory size and
> clock rate. If you're lucky, the bootloader will have already
> assigned the correct MAC addresses for you and you can read those out
> also.
>
> You can also try inspecting the memory pointed to by r3-r7 and seeing
> if any of them point to something interesting.
Regarding the registers I did a
printf("Reg: %lu\n", r3);
after the init of the serial console. While r4 to r7 where empty, I got
back a number 8756... from R3.
I do not know what's in there though. Is there another better way to get to
the data?
> Oh. So routerboot does understand dtb blobs? Okay, I didn't
> understand that. Yes, you can call the libfdt functions in your
> platform_init() to add the missing nodes.
I don't know if routerboot understands dtb blobs. If I boot with a standard
vmlinux image the board boots
as well so I think that the firmware provides a tree the prom code can
read.
As for adding additional information to the tree, can I also use libfdt
functions in platform/83xx/rbppc.c or is it better to do this via a
dedicated platform_init that simpleboot then uses?
Once again thank you very much for helping me with this,
Michael
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
