Re: Unable to boot NetBSD on Linksys NSLU2 (armbe / armv5tel)

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

2015-03-25 23:42 GMT+02:00 Andy Ruhl <acruhl%gmail.com@localhost>:
> On Wed, Mar 25, 2015 at 2:07 PM, Eddy Petrișor <eddy.petrisor%gmail.com@localhost>
> wrote:
>> Since now I have netbsd_6_1 booting, I suppose trying to combine the
>> 6.1 userland with the trunk kernel should (in theory) work. Is this
>> correct or am I missing some tighter coupling between the kernel and
>> the userland?
>
> It should work (in theory) as long as you keep the COMPAT_60 (and newer)
> options in the kernel config.

It worked even in practice with a 7.99.4 kernel I built previously. Thanks Andi.

Now that I managed to boot I found I was unable to login and was also unable
to clear/change the root password, in spite of the fact the rootfs was
completely
accessible from Linux.

Is there a way to set the root password from the build
system or the system hosting the NFS root without running NetBSD on
any of those?



In other news, I will try to find when things went south for trunk via
git bisect, but
not being able to automate the boot from DHCP slows things considerably.

I looked over APEX to use as a second stage bootloader[1] configured
to boot over
tftp the netbsd image. Unfortunately 1) APEX does not support IP configuration
via BOOTP or DHCP, but only RARP, (so that means for me no boot parameters or
just static configuration), and, after my first attempts, 2) after
loading the apex.bin
image in RAM and running it, the display seems to be broken[2].




[1] I don't want to risk bricking the NSLU2, so rebuilding RedBoot
with my custom
options was out for me (unless I find a way to set a different default
for RedBoot).
APEX is used by Debian as a second stage, so I figured using APEX and configure
APEX would probably be easier and less risky.
[2] I suspect is only an endianness display issue (core is running LE,
but peripherals
are BE) since typing the same thing over and over results in some
consistent output
and there is no endless garbage displayed, a reset or something of
that sort, so the
code seems to be sanely replying to the input.