Re: [openfirmware] OFW Client Programs Problems

[Mitch Bradley]

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,