[E3-hacking] PBL & running arbitrary code

[Ralph Corderoy]

Hi David,

> >     0338  eb001b44  bl rx_uart0_byte
> 
> So 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.