Date   : Sat, 27 Nov 2010 09:27:42
From   : heyrick.beebsoc@... (Rick Murray)
Subject: [BeebSoc] Killing Linux - but how?

Hi,

I have a Neuros OSD which is basically an MPEG4 video recorder based 
around a TI ARM+DSP SoC. [I won't describe it here, it's on my b.log if 
you're interested - just search for OSD]

What I would *like* is to be able to load a replacement firmware. If I 
am able to do this, then I can see about drawing a big smiley face on 
the video output. This, while serving no actual purpose, will permit an 
exercise in bringing up the system.

Now, the box itself supports uboot and is capable of TFTPing an image 
into memory, however I am not keen on this approach because:
   1. The Neuros-supplied serial lead is "back to front". I don't recall
      the genders offhand, but the plug won't go into the PC's serial
      port because they're both the same gender. Hence a back-to-back
      will need to be constructed on a bit of veroboard (I say vero
      because I don't know if it needs to be a crossover or not).

   2. Because it is a serial link, it requires another PC, the LAN, and
      VNC...

   3. The use of "uboot" is "destructive". In other words, I am NOT able
      to restore normal behaviour by power-cycling the unit. I would need
      to go back into uboot and reconfigure its options, and hope like
      hell I don't screw it up. [= instant brick]


There ought to be another option. And I think there should be. I'm 
thinking of something more or less akin to the RISC OS softloader.

So the questions are:

   1. How can I load an image into CONTIGUOUS memory? Unlike the big
      expansive sprawling baby-Debian, I would expect something in the
      order of 4Mb tops.
      The machine contains, IIRC, 64Mb, but Linux is hardwired to 'see'
      only 34Mb (by the "mem=34M" in the boot command line). I guess the
      rest is reserved for DSP use?

   2. How can I effectively shut down a running Linux system? I know I
      can kill most activity with:
        killall deskmon nmsd xmms2d nwm main-menu scheduler lighttpd
      But this kills the PVR applications. The next step (once memory is
      loaded) is to bring down the filing systems in a sane way. This is
      important as while the base system is on Flash, the later versions
      of the OSD (plus the third-party hack of the firmware) run off of
      a CF card in read/write mode, so it might well be best to dismount
      correctly.

   3. The next step, disable all interrupts (or maybe just ignore them
      and catch this when the replacement OS is up? how does the RISC OS
      softloader deal with this situation?)

   4. Branch to the softloaded code, in SVC32 mode.


Thus, to try my code, it should require little more than:
   cd ~
   wget http://azumi/myimage.img
   softload myimage.img


Given that Linux is a rather hacker-friendly OS, I would be quite 
surprised if there wasn't some sort of softloader kicking around. Can 
anybody help?
If it helps, everything is "root" so there shouldn't be any priv. issues 
to deal with.


In short: On an ARM based embedded machine running a version of Debian, 
I want to load a 4Mb file into a contiguous lump of memory, shut down 
the currently-running Linux, and start executing this new code.


Best wishes,

Rick.