[U-Boot] Custom MPC8548 boot using FDT problem (more info)

[Pieter <phenning@vastech.co.za>]

Jerry Van Baren wrote:
> Pieter wrote:
>> Jerry Van Baren wrote:
>>> Pieter wrote:
>>>> Hi all
>>>> I have been working on booting our custom MPC8548 board using a FDT.
>>>> The board boots up to the point where "controll is passed to Linux"
>>>> and then nothing happens. I have plased the final part of the console
>>>> output at the bottom of this message.
> [snip]
>>> Where did you get your FDT source from?
>>> Did you modify it?
>>> Does your FDT blob get properly fixed up by your u-boot?
>>>
>>> It is difficult (and not very profitable) to try to make a new linux
>>> kernel run with an old u-boot version because both linux and u-boot
>>> fdt handling matured considerably over the last year.  The (kernel)
>>> FDT blob sources have matured a huge amount over the last year.
>>>
>>> Good luck,
>>> gvb
>> I should have added more specific information - i apologize.
>> The board worked on my old plarform which consisted of U-Boot 1.2
>> booting Linux 2.6.24  not using a FDT. ( the ppc architecture).My
>> current effort is porting to U-Boot 2008.10 and booting Linux 2.6.27.
>> This prompted the move to the powerpc architecture and requirement to
>> use a FDT.
>>
>> The Designers of the board I have did not support FDT, thus I created a
>> FDT source for my board based on the sbc8548 board (included in U-boot)
>> and using the  "Booting the Linux/ppc kernel without Open Firmware"
>> document supplied with Lnux 2.6.27. I am uncertain about assigning
>> interrupts to the variouse nodes.
> Interrupts.  I feel your pain.  It is quite possibly your problem as
> well.
>
> Do a dump of the linux log_buf and see what is happening (if anything)
> when linux starts up:
>   <http://www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis>
>
> My bet is that linux is starting OK but the interrupts (in particular,
> console serial) are misconfigured.
> Unfortunately, I don't understand the interrupts magic, so you will
> have to find a real guru if this is your problem.
>> I compiled the blob using dtc Version: 1.1.0:
>> dtc -b 0 -V 17 -p 0x2000 -I dts -R 8 -O dtb -f
>> arch/powerpc/boot/dts/equus.dts > SDH0/tftp/equus.dtb
> FWIIW, you do not need the -V 17 (version) any more unless your dtc is
> really old, in which case you need a new dtc.  (I forgot what -b does,
> the rest look OK.)
>> My FDT blob is minimal, containg the CPU node, Memory node, SOC node
>> and  Localbus. U-boot seems happy with the blob and fill in the
>> appropriate field in the CPU node (bus / cpu clocks) and Ethernet MAC
>> addresses
> Good, but it doesn't take much for u-boot to be happy with the blob
> since it is just fixing up a couple of specific values.  :-/
>> I moved both the uImage and the FDTblob load addresses higher,
>> 0x01000000 and  0x02000000 respectively.
>> but the boot stil hangs after  " ## Transferring control to Linux (at
>> address 00000000) ... Booting using OF flat tree... "
> OK, cheap question, not a good answer.  It was worth a shot...
> Best regards,
> gvb
I have enabled various debug paramaters in the Linux  config , including
"CONFIG_PPC_EARLY_DEBUG=y" and did the post mortem investigation (
__log_buf at 0xc0298bcc, and the kernel  at 0xc0000000) unfortunatly
there was nothing at the memory location 0x00298bcc. Thus leading me to
turn back to FDT problem and U-Boot.

I am not convinced that the chosen node is created correctly (how do i
specify wheather serial0 or 1 should be used? ) using U-boot fdt chosen
command the node is created as:
 chosen {
        linux,stdout-path = "/soc8548 at e0000000/serial at 4500";
        bootargs = "root=/dev/nfs rw nfsroot=10.0.0.1:/equus/build/target
        ip=10.0.0.200:10.0.0.1:10.0.0.1:255.255.255.0:equus:eth0:off
console=ttyS0,115200";
};

I am currently looking at the interrupt and would appreciate input from
people familiar with the creation of device tree source.