[U-Boot] [PATCH v2] kwboot: boot Marvell Kirkwood SoCs over a serial link

[David Purdy]

On Mon, May 7, 2012 at 9:38 PM, Daniel Stodden
<daniel.stodden at googlemail.com> wrote:
> On Mon, 2012-05-07 at 20:16 -0500, David Purdy wrote:
>> On Mon, May 7, 2012 at 6:40 PM, Daniel Stodden
>> >
>> > Hey.
>> >
>> > Unfortunately I only have a couple Buffalo boards and a Qnap, all
>> > essentially the same chip.
>> >
>> > Say, if you find the time, could you run it through strace and post the
>> > full output? (strace -o /tmp/kwboot.log -s 256 -T ..).
>> >
>> > Just see where it bails. Maybe it's some issue worth trying to hack
>> > around.
>> >
>> > Thanks,
>> > Daniel
>> >
>>
>> Daniel, I could have been a bit more descriptive...  I don't think it
>> necessarily bails.
>>
>> To be fair, I've looked for one single substantiated claim of someone
>> being able to perform a UART-boot on a v1.11 BootROM device ... and I
>> haven't been able to find it.
>>
>> When attempting this w/ a v1.11 BootROM device, I see exactly what
>> everyone else is experiencing when trying to UART-boot their v1.11
>> BootROM device : nothing...  There is no acknowledgement of
>> handshaking or transfer...   It doesn't crash, it seems to never
>> connect.  The rotary cursor simply continues spinning a bit slower
>> ... never shows any further progress.  The process continues until I
>> stop it...
>>
>> I've tried 3 other binaries over the last month or so, and nothing
>> seems to work correctly w/ these devices.
>>
>> In addition, the first mentions/cases of UART-booting seem to appear
>> shortly after the v1.21 BootROM machines appeared on the market. and
>> are accompanied by some incredulous surprise (and delight) when
>> _finally_ someone as gotten this to work... although only w/ v1.21.
>>  Some hunches regarding voltage and logic problems in v1.11 have been
>> cited here and there, but I've not seen anything official that
>> identifies exactly what the defect/problem in 1.11 is.
>
> Okay. Do we even have any indication in some Marvell docs that the
> BootROM versions earlier even *might* support uart boot?

IIUC, the docs say it is supported, but for whatever reason, AFAIK _no
one_ has gotten it to work reliably/reproducibly w/ v 1.11 BootROM.

>
> As for the trace: First of all, thanks a lot.
>
> There's one (minor) bugfix resulting from that: The select() return
> value check in tty_recv() should probably rather have read (nfds <= 0),
> as opposed to (nfds < 0), to cover the timeout case, too.
>
> Duh. But that's not essential, unfortunately.
>
> Beyond, iff you think it should work, would you like to hack a little?
>
> The interesting bits are where we're getting out of that phase where
> we're timing out in select(). Right now followed by read() = -EAGAIN,
> due to above-mentioned quirk. That must be where you reset the target.
>
> Present Boot-ROM sensing works as follows:
>  Write the message.
>  Read a single byte back.
>  Loop.
>
> You'll see phases where we read '\273'. That's just echoing. Normal
> while only talking to an OS console getty or sth.
>
> The current loop only exits successfully when we read a NAK byte (\21)
> back.
>
> Essentially we're waiting for Xmodem to have kicked in and report
> garbage, at a point where we're still shooting boot messages at it.
>
> That works well on newer boards, obviously.
>
> But in your log, there seems to be a long period where the board
> returning a NUL byte instead. I wonder if earlier boot code would
> faithfull re-read boot messages and wait for us to figure out that NUL.
>
> You might want to try the following snippet as a termination condition:
>
>    rc = kwboot_tty_recv(tty, &c, 1,
>                         KWBOOT_MSG_RSP_TIMEO);
>
>    ...
>  } while (rc || (c != NAK && c != 0));
>
> It's a total crap shot. You'll likely see the sender side hop into
> Xmodem, but no idea what happens next -- so watch your Nand :}
>
>> As you probably know, the BootROM version string can be viewed at
>> offset ff00003c:
>> md ff00003c
>> which produces either  00000111  or  00000121
>
> No, didn't know, didn't have to bother about firmware version issues
> before today. Thanks.
>
>> The log of an unsuccessful attempt is attached...
>
> Cheers,
> Daniel
>
> PS: Intentionally off-the-list? If not, feel free to reconnect again.
>

Will try out that short modification you mentioned...

and I did mean to send this via list, but guest I off-listed the
response...   consider it reattached.

thanks,

Dave