[Caml-list] Ocaml on RaspberryPi bare-metal crashes

[Caml-list] Ocaml on RaspberryPi bare-metal crashes

[Goswin von Brederlow]

Hi,

over the weekend I wrote some boot code and glue to make ocaml run
bare-metal on a RaspberryPi. Here is what I did:

- Compile ocaml source into a single object file:
    ocamlopt -output-obj -o prog.o foo.ml

- Compile a boot.S and main.c file providing the hardware interface
  and libc (libm, libdl) functions needed by ocaml. A lot of stuff is
  just stubs that will return errors or nonsense (like all the math
  functions return 0). But I have memory and print functions working.
  The main() initializes the hardware and calls caml_startup().

- Add libasmrun.a and libgcc.a from the system.

- Link it all together and objcopy to binary to get a kernel image for
  booting.

Everything compiles and links without errors. And the kernel boots and
outputs its startup messages before starting ocaml. But then is where
things get tricky:

---- foo.ml ----
let () = ()
----------------
Ocaml starts and finishes and the kernel outputs its finished message.
Everything seems to be working fine.

---- foo.ml ----
let () = Printf.printf "Hello World\n%!"
----------------
Ocaml does its startup (calls the same libc functions as before) but
then the system resets before printing "Hello World\n". I don't see
any sprintf() or fputs() or fwrite() calls.

I'm not sure why it crashes and I haven't setup exception handlers yet
that would tell me what or where exactly it crashes. But the only new
bits are the initialization of the printf module and the printf call
itself. Must be one or the other.

Does anyone want to take a blind guess what could be wrong?

One idea I got while writing the email is that maybe the stack is the
problem. I only setup a 16k stack at boot. Does ocaml create its own
stack or should I make the stack larger? Would a simple printf exceed
16k stack?

MfG
	Goswin

Re: [Caml-list] Ocaml on RaspberryPi bare-metal crashes

[Peter Zotov]

Goswin von Brederlow писал 04.11.2013 17:10:
> Hi,
> 
> over the weekend I wrote some boot code and glue to make ocaml run
> bare-metal on a RaspberryPi. Here is what I did:
> ...
> I'm not sure why it crashes and I haven't setup exception handlers yet
> that would tell me what or where exactly it crashes. But the only new
> bits are the initialization of the printf module and the printf call
> itself. Must be one or the other.
> 
> Does anyone want to take a blind guess what could be wrong?

If I was you:

1) I'd try to set up an emulator as close to RPi as possible and 
reproduce.
    Qemu has an integrated gdbserver and with RPi's popularity, chances 
that
    someone customized it already.

2) If there's no luck with emulator, I'd link in a GDB stub for ARM
    communicating via a hardware serial port. This one seems to be easy 
enough
    to port: 
https://github.com/BurntBrunch/rockbox-fft/blob/master/gdb/arm-stub.c

(Incidentally, this demonstrates why you don't generally want to use 
hardware
without accessible JTAG. :)

-- 
   WBR, Peter Zotov.

Re: [Caml-list] Ocaml on RaspberryPi bare-metal crashes

[Goswin von Brederlow]

On Mon, Nov 04, 2013 at 05:41:48PM +0400, Peter Zotov wrote:
> Goswin von Brederlow ?????????? 04.11.2013 17:10:
> >Hi,
> >
> >over the weekend I wrote some boot code and glue to make ocaml run
> >bare-metal on a RaspberryPi. Here is what I did:
> >...
> >I'm not sure why it crashes and I haven't setup exception handlers yet
> >that would tell me what or where exactly it crashes. But the only new
> >bits are the initialization of the printf module and the printf call
> >itself. Must be one or the other.
> >
> >Does anyone want to take a blind guess what could be wrong?
> 
> If I was you:
> 
> 1) I'd try to set up an emulator as close to RPi as possible and
> reproduce.
>    Qemu has an integrated gdbserver and with RPi's popularity,
> chances that
>    someone customized it already.
> 
> 2) If there's no luck with emulator, I'd link in a GDB stub for ARM
>    communicating via a hardware serial port. This one seems to be
> easy enough
>    to port:
> https://github.com/BurntBrunch/rockbox-fft/blob/master/gdb/arm-stub.c
> 
> (Incidentally, this demonstrates why you don't generally want to use
> hardware
> without accessible JTAG. :)

I think that only works with interrupts enabled. I'm not that far yet.
Still doing input/output by polling the uart.

I've now setup the exception vector base address register and
installed exception handlers that print out the name of the exception
and a register dump. That showed me 2 problems:

1) doing some kind of output (print_string or Printf.printf) uses
floating point stuff. I didn't have the FPU enabled yet so that threw
and undefined exception. Not sure if the float is used somewhere in
the IO layer or if that triggers something in the GC that uses floats.
Might not even be IO related at all but caused by allocating a heap
value. The simple tests that succeeded before all only used stack.

2) malloc() needs to return 8 byte aligned blocks or storing 64bit
values fails. Doing output initializes the stdout channel, which calls
lseek64 and stores the resultint int64_t.


So now I have ocaml running barebone on my RaspberryPi in a verry
minimal way.

ToDo:
- LED module (turn on/off the OK LED)
- Framebuffer / Graphics modules
- Timer module
- implement free()
- Threads
- USB module
  + keyboard
  + mouse
  + ethernet
- tcp/ip stack
- audio
- GPIO module

If anyone is interested I can upload what I have so far to github. But
beware it is verry much a WIP.

MfG
	Goswin

Re: [Caml-list] Ocaml on RaspberryPi bare-metal crashes

[David Scott]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

Hi,

On Mon, Nov 4, 2013 at 8:38 PM, Goswin von Brederlow <goswin-v-b@web.de>wrote:
...

> 1) doing some kind of output (print_string or Printf.printf) uses
> floating point stuff. I didn't have the FPU enabled yet so that threw
> and undefined exception. Not sure if the float is used somewhere in
> the IO layer or if that triggers something in the GC that uses floats.
> Might not even be IO related at all but caused by allocating a heap
> value. The simple tests that succeeded before all only used stack.
>

FWIW the port of mirage to kFreeBSD (where the ocaml program runs as a
kernel module) hit a similar issue with floats. The workaround was to
replace the floats with a fixed-point implementation:

https://lists.cam.ac.uk/pipermail/cl-mirage/2012-August/msg00012.html

https://lists.cam.ac.uk/pipermail/cl-mirage/2013-September/msg00013.html



> 2) malloc() needs to return 8 byte aligned blocks or storing 64bit
> values fails. Doing output initializes the stdout channel, which calls
> lseek64 and stores the resultint int64_t.
>
>
> So now I have ocaml running barebone on my RaspberryPi in a verry
> minimal way.
>

Nice!


> ToDo:
> - LED module (turn on/off the OK LED)
> - Framebuffer / Graphics modules
> - Timer module
> - implement free()
> - Threads
> - USB module
>   + keyboard
>   + mouse
>   + ethernet
> - tcp/ip stack
>

I'm not sure how difficult USB will be, but once packets start flowing over
the network interface you should be able to use the mirage TCP/IP stack.


> - audio
> - GPIO module
>
> If anyone is interested I can upload what I have so far to github. But
> beware it is verry much a WIP.
>

I'd be interested in checking it out! :-)

Cheers,
Dave

[-- Attachment #2: Type: text/html, Size: 3090 bytes --]