PHY not found after migration of gianfar driver to an of_platform_driver

[Grant Likely]

On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche <mike at it-loops.com> wrote:
> On Sun, 1 Mar 2009 18:15:32 -0700, Grant Likely <grant.likely at secretlab.ca>
> wrote:
>>
>> So, what you need is a new adapter which parses the data passed in by
>> routerboot (maybe call it routerImage?) and modifies the .dtb blob to
>> match.  You can use simpleImage as a starting point.
> I had a look at that. And this is what I understood so-far.
> SimpleImage just takes the dtb from the segment and parses it as the new
> device tree.
>
>  _dtb_start = .;
>  .kernel:dtb : { *(.kernel:dtb) }
>  _dtb_end = .;
>
> No I do understand that dtb_start points to this device tree. I also know
> that the standard kernel boot-process
> is able to read he device tree out of the firmware/bootloader (it works if
> I just put with a standard kernel image)

Only if the firmware supports passing in a device tree.  Many embedded
firmwares do not, in which case the .dtb must be linked into the
bootwrapper statically.

> but I cannot figure out, where
> exactly (in the code) it is doing that.

Every bootwrapper image (simpleBoot, zImage, cuImage, etc.  uImage is
the exception; it doesn't use the bootwarpper) has a function called
platform_init() with the arguments r3, r4, r5, r6, and r7 which hold
the values of those registers when the bootwrapper is called.
platform_init() is called by crt0.S before calling the 'start()' entry
point in main.c and one purpose of it is to adapt the information
available about the board into the device tree.

platform_init is different for each kind of bootwrapper image.  In
simpleboot.c, r3-r7 are simply ignored.  In a cuImage, a pointer to
the bd_info structure is retrieved from r3 (cuboot.h).

> My problem is now that I have zero
> documentation of the existing bootloader. All I know is that the prom code
> is able to find and parse it.
> So now my question, is there a way to get to the device tree at this stage
> of the boot process?

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.

>>> Can't I just add them in the rbppc.c specific init stuff
> programmatically
>>> withouth a DTS file?
>>
>> You need a device tree.  You could theoretically generate the entire
>> tree programmatically, but that is the long way around.  What you want
>> is a base .dts file and a new bootwrapper to fill in the missing bits
>> at boot time.
>
> Well the board already provides a device tree so all I would need is the
> missing entries so the PHYs are detected correctly. So I would modify an
> existing tree.

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.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.