Dear OFW Users,
I'm trying to build a simple ELF application (e.g. helloworld) that uses OFW client interface to interact with my (geode based) embedded system (later I will use this interface to build an FPGA programmer).
I just go inside ofw/client/lib/x86 and run 'make', after changing just a bit the Makefile, due compiler requirement (I use gcc 3.4.6) After this I just copied the hello.elf on my device and run as following
ok com1 io ok verbose-cif ok boot u:\hello.elf Boot device: /usb/disk:\hello.elf Arguments: Boot device: /usb/disk:\hello.elf Arguments: finddevice ( 101b92 -- ff82b044 ) getprop ( 4 ff9e77a0 101b9a ff82b044 -- 4 ) getprop ( 4 ff9e77a0 101ba0 ff82b044 -- 4 ) getproplen ( 101ba7 ff82b044 -- 44 ) claim ( 4 1000 0 -- ffb73000 ) getprop ( 44 ffb73018 101ba7 ff82b044 -- 44 ) getproplen ( 101bb0 ff82b044 -- 1 ) getprop ( 1 ffb73078 101bb0 ff82b044 -- 1 ) write ( e 101f2c ff9b5180 -- Hello, world e ) exit ( -- ok
That's preatty correct, but if I run it again I got:
ok boot u:\hello.elf [board resets here] þ+bcs Type 'i' to interrupt stand-init sequence First stand-init: Exceptions CIF DHCP init
I also try with this one:
ok com1 io ok load u:\hello.elf Boot device: /usb/disk:\hello.elf Arguments: Boot device: /usb/disk:\hello.elf Arguments: ok go Hello, world ok go Hello, world ok go Hello, world ok load u:\hello.elf Boot device: /usb/disk:\hello.elf Arguments: Boot device: /usb/disk:\hello.elf Arguments: [board halts here]
So it seems that the problem is NOT regarding running the client program but accessing USB device after the program in already run. This is a problem for us because the FPGA programmer require the access to bitstream file:
ok com1 io ok verbose-cif ok boot u:\vme.elf u:\neptune.vme Boot device: /usb/disk:\vme.elf Arguments: u:\neptune.vmeBoot device: /usb/disk:\vme.elf Arguments: u:\neptune.vme finddevice ( 105463 -- ff82b044 ) getprop ( 4 ff9e77b8 10546b ff82b044 -- 4 ) getprop ( 4 ff9e77b8 105471 ff82b044 -- 4 ) getproplen ( 105478 ff82b044 -- 40 ) claim ( 4 1000 0 -- ffb73000 ) getprop ( 40 ffb73018 105478 ff82b044 -- 40 ) getproplen ( 105481 ff82b044 -- f ) getprop ( f ffb73074 105481 ff82b044 -- f ) write ( 2e 1058ac ff9b5180 -- Lattice Semiconductor Corp. 2e ) write ( 2 1058ac ff9b5180 -- 2 ) write ( 34 1058ac ff9b5180 -- ispVME(tm) V12.1 Copyright 1998-2008. 34 ) write ( 2 1058ac ff9b5180 -- 2 ) write ( 43 1058ac ff9b5180 -- For daisy chain programming of all in-system programmable devices 43 ) write ( 2 1058ac ff9b5180 -- 2 ) write ( 38 1058ac ff9b5180 -- Processing virtual machine file (u:\neptune.vme).. .... 38 ) write ( 2 1058ac ff9b5180 -- 2 ) open ( ff9e7668 -- [here the board halt as before]
Can it be a problem of gcc version? (If so, which version should I use for client applications?) Can I debug it somehow?
Best Regards and TIA,
The situation you describe is an intentional "feature", implemented at line 278 of ofw/core/bootparm.fth
OFW resets itself if you boot again after having already booted once. The reason is because, in general, OFW does not know the state of the system after it transfers control to a booted program. Most operating systems "take over" the hardware and do things to it that OFW cannot detect. So, in order to reboot reliably, OFW has to reset so it can reestablish a known state for the hardware.
One workaround would be to do "false to already-go?" before re-executing the boot command.
The USB hang is because dev/geode/usb.fth explicitly turns off the USB hardware when transferring control to the booted program. This was a precautionary measure for Linux. The USB hardware performs DMA to memory descriptors. We were afraid that might interfere with Linux startup in some cases, so we turned off the USB to make the system "quiet" during Linux startup. (We didn't have specific evidence that the USB DMA was causing problems; we were just being careful. Linux was starting properly before this USB turn-off was added.)
If you know that the USB DMA will not cause problems for your system, you can leave USB turned on by adding this line to fw.bth, anywhere after the "fload ${BP}/dev/geode/usb.fth" line:
' noop to go-hook
go-hook is a defer word that is executed just before transferring control to a loaded program. It can be used to do any platform-specific last-second cleanup that you need to do.
Andrea wrote:
Dear OFW Users,
I'm trying to build a simple ELF application (e.g. helloworld) that uses OFW client interface to interact with my (geode based) embedded system (later I will use this interface to build an FPGA programmer).
I just go inside ofw/client/lib/x86 and run 'make', after changing just a bit the Makefile, due compiler requirement (I use gcc 3.4.6) After this I just copied the hello.elf on my device and run as following
ok com1 io ok verbose-cif ok boot u:\hello.elf Boot device: /usb/disk:\hello.elf Arguments: Boot device: /usb/disk:\hello.elf Arguments: finddevice ( 101b92 -- ff82b044 ) getprop ( 4 ff9e77a0 101b9a ff82b044 -- 4 ) getprop ( 4 ff9e77a0 101ba0 ff82b044 -- 4 ) getproplen ( 101ba7 ff82b044 -- 44 ) claim ( 4 1000 0 -- ffb73000 ) getprop ( 44 ffb73018 101ba7 ff82b044 -- 44 ) getproplen ( 101bb0 ff82b044 -- 1 ) getprop ( 1 ffb73078 101bb0 ff82b044 -- 1 ) write ( e 101f2c ff9b5180 -- Hello, world e ) exit ( -- ok
That's preatty correct, but if I run it again I got:
ok boot u:\hello.elf [board resets here] þ+bcs Type 'i' to interrupt stand-init sequence First stand-init: Exceptions CIF DHCP init
I also try with this one:
ok com1 io ok load u:\hello.elf Boot device: /usb/disk:\hello.elf Arguments: Boot device: /usb/disk:\hello.elf Arguments: ok go Hello, world ok go Hello, world ok go Hello, world ok load u:\hello.elf Boot device: /usb/disk:\hello.elf Arguments: Boot device: /usb/disk:\hello.elf Arguments: [board halts here]
So it seems that the problem is NOT regarding running the client program but accessing USB device after the program in already run. This is a problem for us because the FPGA programmer require the access to bitstream file:
ok com1 io ok verbose-cif ok boot u:\vme.elf u:\neptune.vme Boot device: /usb/disk:\vme.elf Arguments: u:\neptune.vmeBoot device: /usb/disk:\vme.elf Arguments: u:\neptune.vme finddevice ( 105463 -- ff82b044 ) getprop ( 4 ff9e77b8 10546b ff82b044 -- 4 ) getprop ( 4 ff9e77b8 105471 ff82b044 -- 4 ) getproplen ( 105478 ff82b044 -- 40 ) claim ( 4 1000 0 -- ffb73000 ) getprop ( 40 ffb73018 105478 ff82b044 -- 40 ) getproplen ( 105481 ff82b044 -- f ) getprop ( f ffb73074 105481 ff82b044 -- f ) write ( 2e 1058ac ff9b5180 -- Lattice Semiconductor Corp. 2e ) write ( 2 1058ac ff9b5180 -- 2 ) write ( 34 1058ac ff9b5180 -- ispVME(tm) V12.1 Copyright 1998-2008. 34 ) write ( 2 1058ac ff9b5180 -- 2 ) write ( 43 1058ac ff9b5180 -- For daisy chain programming of all in-system programmable devices 43 ) write ( 2 1058ac ff9b5180 -- 2 ) write ( 38 1058ac ff9b5180 -- Processing virtual machine file (u:\neptune.vme).. .... 38 ) write ( 2 1058ac ff9b5180 -- 2 ) open ( ff9e7668 -- [here the board halt as before]
Can it be a problem of gcc version? (If so, which version should I use for client applications?) Can I debug it somehow?
Best Regards and TIA,
Mitch Bradley wrote:
The situation you describe is an intentional "feature", implemented at line 278 of ofw/core/bootparm.fth [snip] One workaround would be to do "false to already-go?" before re-executing the boot command.
Thanks for the explanation Mitch!
The USB hang is because dev/geode/usb.fth explicitly turns off the USB hardware when transferring control to the booted program. This was a precautionary measure for Linux. The USB hardware performs DMA to memory descriptors. We were afraid that might interfere with Linux startup in some cases, so we turned off the USB to make the system "quiet" during Linux startup. (We didn't have specific evidence that the USB DMA was causing problems; we were just being careful. Linux was starting properly before this USB turn-off was added.)
If you know that the USB DMA will not cause problems for your system, you can leave USB turned on by adding this line to fw.bth, anywhere after the "fload ${BP}/dev/geode/usb.fth" line:
' noop to go-hook
go-hook is a defer word that is executed just before transferring control to a loaded program. It can be used to do any platform-specific last-second cleanup that you need to do.
Sound reasonable for Linux booting.
I try it and I found that it is possibile to do it at runtime (by typing the command above on ofw console) Thanks for the suggestion
I got another problem while reading the file from usb device:
Running Lattice programmer Boot device: /usb/disk:\vme.elf Arguments: u:\neptune.vmeBoot device: /usb/disk:\vme.elf Arguments: u:\neptune.vme finddevice ( 105463 -- ff82b044 ) getprop ( 4 ff9e77b8 10546b ff82b044 -- 4 ) getprop ( 4 ff9e77b8 105471 ff82b044 -- 4 ) getproplen ( 105478 ff82b044 -- 40 ) claim ( 4 1000 0 -- ffb73000 ) getprop ( 40 ffb73018 105478 ff82b044 -- 40 ) getproplen ( 105481 ff82b044 -- f ) getprop ( f ffb73074 105481 ff82b044 -- f ) write ( 2e 1058ac ff9b5180 -- Lattice Semiconductor Corp. 2e ) write ( 2 1058ac ff9b5180 -- 2 ) write ( 34 1058ac ff9b5180 -- ispVME(tm) V12.1 Copyright 1998-2008. 34 ) write ( 2 1058ac ff9b5180 -- 2 ) write ( 43 1058ac ff9b5180 -- For daisy chain programming of all in-system programmable devices 43 ) write ( 2 1058ac ff9b5180 -- 2 ) write ( 38 1058ac ff9b5180 -- Processing virtual machine file (u:\neptune.vme).. .... 38 ) write ( 2 1058ac ff9b5180 -- 2 ) open ( ff9e7668 -- ff9df5b4 ) read ( 80 ffb730a8 ff9df5b4 -- 80 ) BOUND range exceeded ok2
the last read() is, in C code a simple fgetc(). Is 'still something about USB device or maybe in client interface? (or.. whatever..)
TIA,
Andrea wrote:
I got another problem while reading the file from usb device:
Running Lattice programmer Boot device: /usb/disk:\vme.elf Arguments: u:\neptune.vmeBoot device: /usb/disk:\vme.elf Arguments: u:\neptune.vme finddevice ( 105463 -- ff82b044 ) [snip] read ( 80 ffb730a8 ff9df5b4 -- 80 ) BOUND range exceeded ok2
the last read() is, in C code a simple fgetc(). Is 'still something about USB device or maybe in client interface? (or.. whatever..)
Sorry for the silly question.. of course it was a fault of my application: "BOUND range exceeed" is outside OFW, due the fact that there is a closed bracket around the read call.
The "problem" was on a weird printf() formatting that is not supported by OFW printf() library.
I just remove it and now the program works (well.. it still requires a lot of work on it ;-) )
Thanks anyway,
openfirmware@openfirmware.info
-
Andrea -
Mitch Bradley