On Mon, May 7, 2012 at 9:38 PM, Daniel Stodden <daniel.stod...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
