On Mon, May 7, 2012 at 9:38 PM, Daniel Stodden daniel.stodden@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