FreeBSD booting freescale P1020wlan eval board, via u-boot?

[Aleksander]

Hi!

Try the patch attached to the message. It should fix the bug in
booke_init(). It also has p1010_printf() which is early printf that uses my
p1010 DUART registers. If you want to use it, check if cn_ptr and cn_lst
variables in p1010_putc have proper values. The main fixup is in lines
375-396 of the original file (107 of patch).
Without this patch, my board (p1010rdb) hung without any message, so the
symptoms were similar to yours.


On Thu, Apr 4, 2013 at 9:56 PM, John Clark <jeclark2006 at aim.com> wrote:

>
> On Apr 3, 2013, at 12:04 PM, Aleksander wrote:
>
> > please attach some output, maybe I could help.
> >
> > The booke_init() function has a bug, which is not yet fixed in HEAD.
> >
> > Anyway, you need to use kernel image (not ubldr) either binary or elf
> (if elf, you need to jump with offset to __start function
>
> I've been continuing to look into why things aren't working.
>
> I believe the diagnostic output was due to jumping into the 'wrong' places.
>
> When I objcopy out a binary image, load that, the use the u-boot 'go'
> command at 1000000, there is nothing that is output
> to the console.
>
> I've checked and believe a FDT file is statically linked into the code,
> and it seems to match up with the p1020rdb.dts, with a few
> differences due to the 'wlan' version. However, the serial ports are the
> same, as well as various memory and other devices.
>
> One thing that did occur to me was the default speed of the serial port as
> a console. My u-boot is setup for 115200, but I did try
> 9600 and 19200, just in case someone took the lowest speeds (these
> days...). But still no output.
>
> I did disassemble the kernel... verified that there's the some what
> expected startup code, which was setting up an initial translation table,
> then a call the 'booke_init'.
>
> You indicated a bug in 'head' for booke_init.c... what are the symptoms?
> And where to get a fixed version?
>
> If you have other ideas I'd appreciate them as well.
>
> Thanks,
> John Clark.
>
>
>


-- 
regards
aleek