Re: 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>]

Hi all,

For anyone in the future trying to use this code, there is a catch for
which the published code will not work out of the box on the NSLU2,
not even on the ones having the same version as my own.

During my tests I have always started Apex with the 'go' command, but
the built-in command in RedBoot is actually 'boot;exec 0x01d00000".
These commands actually copy the Kernel and Ramdisk flash partitions'
contents into RAM (Kernel partition at address 0x01d00000) then
prepare things for executing a Linux kernel and give control to the
code copied from flash.

After a few tests, I realised 'exec' deinitializes/changes some of the
things in RedBoot which make any call from Apex not return[J] and
making the code not reach its goal. For reasons why this is necesary
see [R]

WARNING: DO NOT DO WHAT THE NEXT PARAGRAPH SUGGEST UNLESS YOU HAVE
CONFIRMED AND CHECKED YOU CAN USE JTAG TO REFLASH YOUR NSLU2! THE
SUGGESTED APPROACH CAN BRICK YOUR NSLU2!

What can work is if the flashed RedBoot image is copied from the slug
to a host machine then changed to have 'boot; go 0x01d00000' as the
default builtin command and the modified version is flashed back into
the NSLU2. I haven't done that myself yet because I haven't confirmed
yet I can use JTAG to reflash the slug, in case something goes wrong.

So currently I am on hold because I am waiting for a JTAG dongle from
Olimex[O] to arrive, but I will send an updated once I have new
information.


[J] and since I wasn't able to single step the ixp420 chip on the
board, although I have JTAG on the board, I can't easily analyse to
fix/workaround from Apex
[R] the NSLU2 needs some non-freely distributable code from Intel to
provide a network driver (NPE), but the version Apex worked with can't
be found anymore, and the new version doesn't work with the old build
system (which is very odd); so to have network access to load the
NetBSD image via TFTP I decided to call the RedBoot 'load' command
which actually works. The downside is this makes the code tightly
coupled to the RedBoot version on the NSLU2.
[O] I ordered this one: https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/

2015-04-26 15:00 GMT+03:00 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