APEX as a second stage bootloader on NSLU2 to allow net booting NetBSD without manual intervention (was: Re: Unable to boot NetBSD on Linksys NSLU2 (armbe / armv5tel))

[Eddy Petrișor <eddy.petrisor+netbsd.org%gmail.com@localhost>]

Hello all,

Just wanted to announce that I have managed to make a hacked Apex
version that can be written into the NSLU2 flash to allow automatic
net booting of the netbsd-nfs.bin image. (I also managed to find and
fix the cause for the issues related to the first parameter being
ignored - it was a wrong assumption on my part).

The latest code is available (on the netbsd branch) at:
https://github.com/nslu2/apex/tree/netbsd


The current version is tagged and available at:
https://github.com/nslu2/apex/releases/tag/1.6.10-netbsd-0.1

NOTE: this code is highly dependent on the RedBoot version running on
the NSLU2 because Apex is calling RedBoot functions to automate TFTP
loading of the netbsd-nfs.bin image. The NSLU2 on which this was
tested and worked reported this version[V]:

      RedBoot(tm) bootstrap and debug environment [ROMRAM]
      Red Hat certified release, version 1.92 - built 15:16:07, Feb  3 2004

      Platform: IXDP425 Development Platform (XScale)
      Copyright (C) 2000, 2001, 2002, Red Hat, Inc.

      RAM: 0x00000000-0x02000000, 0x000723a0-0x01ff3000 available
      FLASH: 0x50000000 - 0x50800000, 64 blocks of 0x00020000 bytes each.


This allows booting NetBSD via TFTP+NFS without the need to type
anything in the RedBoot prompt, the netbsd-nfs.bin image is
automatically downloaded via TFTP in the regular Sercomm boot
sequence.

I also added two new Makefile targets in Apex to allow creation of the
correct images to be written in Linksys' NSLU2 flash:
 - apex_nslu2.flash: target for the Apex image (which shold be written
in flash at 0x50060000)
 - empty_nslu2.flash: target for a fake/dummy/empty ramdisk image;
although this makes no sense for NetBSD booting, it was necessary
because RedBoot will crash if it can't find a correct/reasonable
Sercomm header at address 0x50160000.


The Apex image can be flashed into the NSLU2 by following the steps
(checked as correct on a Debian GNU/Linux host with the IP facing the
NSLU2 set as 192.168.0.2):
0) backup your NSLU2, I am not responsible for any damage, data loss,
killed kittens during this procedure
(on host)
1) git clone https://github.com/nslu2/apex.git && cd apex
2) cp src/mach-ixp42x/netbsd-nfs-nslu2_config .config
3) make apex_nslu2.flash empty_nslu2.flash
4) (copy files to be available via tftp) # cp apex_nslu2.flash
empty_nslu2.flash /srv/tftp/
(on NSLU2, at RedBoot telnet prompt)
5) telnet into RedBoot: http://www.nslu2-linux.org/wiki/HowTo/TelnetIntoRedBoot
6) (transfer the empty ramdisk image into NSLU2's RAM): load -r -b
0x200000 -h 192.168.0.2 empty_nslu2.flash
6.a) (check the file was correctly transfered): cksum
6.b) on the host run cksum on empty_nslu2.flash and make sure the
numbers are identical as the one on NSLU2
7) (flash the empty ramdisk image - RedBoot needs this): fis write -f
0x50160000 -b 0x200000 -l 32
8) (transfer the hacked apex image into NSLU'2 RAM): load -r -b
0x200000 -h 192.168.0.2 apex_nslu2.flash
8.a) check the file was correctly transfered (cksum at RedBoot prompt
and check agains the output of 'cksum apex_nslu2.flash' ran on host)
9) flash the Apex image in the Kernel Flash partition of the NSLU2[R]:
fis write -f 0x50060000 -b 0x200000 -l <size>
10) (reset from the RedBoot prompt): reset

If eveything went well, you TFTP and NFS servers are correctly set,
the NSLU2 should now automatically boot using the netbsd-nfs-bin image
from your TFTP server at 192.168.0.2 (this is the default hardcoded
address in the commands stored in the chain_cmds variable in
src/apex/cmd-redboot.c).


Any feedback is welcome.



[V] Other versions can be made to work, but some configurability
changes need to happen in Apex before that can be possible. (changes
are not hard to implement, but I had no reason to do them now).

[R] Make sure to change the '<size>' part of the command at step 9
with the size of your resulting apex_nslu2.flash file. <size> can be
writen in decimal, so the ouptu of 'ls -l apex_nslu2.flash' should
provide the correct value which can be copy-pasted into the command.


2015-04-18 19:04 GMT+03:00 Eddy Petrișor <eddy.petrisor+netbsd.org%gmail.com@localhost>:
> Apex did not have an easily obtainable NPE driver, so I had to investigate
> the call-back-to-RedBoot method/hack mentioned below.
>
>> P.S.: [..]
>> Since RedBoot already supports everything via console commands
>> (kbd_proc and cmd_proc functions in RedBoot) and since cmd_proc relies
>> on kbd_proc to place the input in a static buffer (ch_buf[256]) I
>> could inject the necessary redboot commands from a bastardized apex
>> (or a new binary) into the ch_buf buffer then call RedBoot's cmd_proc
>> efectively simulating a user interaction at the RedBoot prompt.
>
> I have implemented a version of this method. It took me a lot of time
> because a) the version of RedBoot running on the slug is not the one one can
> obtain if compiling the RedBoot source provided by Linksys in their
> so-called source GPL package and b) for some unknown reason the RedBoot
> arguments parser fails to process the first parameter passed to the
> commands.
>
> Fortunately I realised a simple workaround is to pass another parameter (-v
> for the 'load' command). The downside is that I have to find out a parameter
> to ignore for the 'ip_address' command, but I don't expect this to be a
> problem.
>
> If anybody is curious, the hacked apex version is available on github at the
> repo below on the 'hardcodecmds' branch (pointing out any error on my side
> is highly appreciated):
>
> https://github.com/nslu2/apex/tree/hardcodecmds?files=1
>
> EddyP