Hi David,
0338 eb001b44 bl rx_uart0_byteSo what does rx_uart0_byte return if the FIFO is empty? It either blocks, in which case we could find the timeout, or else it just returns failure --- probably 0. In which case, the only way of triggering the boot loader is to make sure that the byte hits the FIFO before this piece of code gets called.
There's more code before the bit I quoted.
032c eb001b37 bl is_uart0_rx_fifo_empty 0330 e3500000 cmp r0, #0 0334 0a000006 beq &0354
So rx_uart0_byte isn't called unless there's a byte in the FIFO.
This whole bit of code is run each iteration around one of the states of the main FSMs. I can't remember more detail at the moment.
Since both our programs are spamming the thing silly with ESC chars, then I suspect there might be some other condition that needs to be met before this code even gets called.
Possibly. Both Matt and I independently assumed a key held down on the telephone keypad, that's probably our Acorn backgrounds, but nothing in the code suggests that AFAIK.
It just happens to be true on your E3 and Matt's E2, but not on mine.
I think that's unlikely.
Might there be some sort of hardware query buried in the setup routine in main()?
Maybe. But there's quite a lot of code and it calls out to lots of places that nest quite deep.
Attached is a small tar file, exp-1.tar.bz2, containing exp.c and various other gubbins. I've heard it has some effect with the E3 doing what you state above.
This seems to send a single 1B, and bail with a EOF error when it tries to read the response.
It shouldn't do that. Is that what actually happens, in which case the stdout and stderr would be handy, or what you think from a quick look?
It writes ESCs for a while and then switches to sending a few protocol messages for luck. All the while it looks for anything coming back. Both read(2) and write(2) are non-blocking, it doesn't use poll(2), so it's a busy loop which is fine for a quick hack.
Use environment variables to tweak parameters, especially baud rate.
$ ./exp -h exp: wrong number of arguments. usage: [EXPTTY=tty] [EXPBAUD=baud] [EXPTXLEN=txlen] [EXPTXGAP=txgap] exp tty is the serial port to use, default /dev/ttyS0. baud is the baud rate to use, default 115200. txlen is the seconds spent sending escapes, default 30. txgap is the seconds between sending escapes, default 0.005. $
How were you running it? Before boot, after boot?
By setting txlen large you've time to turn on the E2 once ./exp has started sending.
Perhaps Matt can specify what his procedure is that got the E2 to suspend booting.
Cheers,
Ralph.