Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Mar 2012 23:08:01 +0100
From:      Rafal Jaworowski <raj@semihalf.com>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Juli Mallett <jmallett@FreeBSD.org>, "freebsd-mips@FreeBSD.org" <freebsd-mips@FreeBSD.org>
Subject:   Re: RouterBOOT on RB450G has a 4MB NAND kernel size limit
Message-ID:  <46D6F510-A824-4F00-9B77-E804A417324D@semihalf.com>
In-Reply-To: <43E920D8-72A6-43F0-8941-32C40783C523@bsdimp.com>
References:  <CACVs6=8o%2B%2BQnDiiFn_nLinNa83sjYSxDNyzEt%2B=Ke14exGnM5Q@mail.gmail.com> <43E920D8-72A6-43F0-8941-32C40783C523@bsdimp.com>

index | next in thread | previous in thread | raw e-mail


On 2012-03-09, at 02:00, Warner Losh wrote:

> 
> On Mar 8, 2012, at 5:24 PM, Juli Mallett wrote:
> 
>> Hey folks,
>> 
>> I thought it might be useful to share this with others, so they don't
>> waste 6 hours diffing ELF files trying to figure out what the problem
>> is.
>> 
>> It turns out that although it can load ELF files of variable size over
>> TFTP, and although the system is configured with a larger kernel NAND
>> partition, RouterBOOT seems to choke (without any clear error, mind
>> you, because that would be gratuitously-sensible) on loading kernels
>> larger than 4MB.  Of course, it's hard to figure this out because
>> nothing useful turns up on a quick search for '"setting up elf
>> image..." hang' or '"setting up elf image..." -"setting up elf
>> image... ok"', although once you figure it out, it's easy to confirm
>> with a quick Google along the lines of 'rb450g 4mb kernel'.
>> 
>> So, be warned if you're thinking that you'll use an OpenWRT kernel
>> with initramfs over netboot to provision devices to use FreeBSD by
>> copying the kernel to NAND.  Or if you've got yaffs patches to your
>> kernel and can just copy over kernels with impunity.
>> 
>> Has anyone looked at using U-Boot as a second stage loader on this
>> hardware?  In order to make loader useful, we'd have to add an awful
>> lot of infrastructure, including another yaffs implementation, when we
>> don't even have one in-tree yet.  What would be most useful, too,
>> would be to have MMC + SPI support in loader (here again, U-Boot is
>> helpful), so that we could load kernels from SD.  That's a lot of work
>> on loader, and U-Boot already does it all, right?  Any thoughts?
> 
> While not specifically for that hardware, I've scoped out the work it would take to port raj@'s work from ARM to MIPS.  It doesn't look huge, once you settle on the right 'syscall' model.  figured it would take a dedicated person in the weeks to months range of effort, depending on the person :).  Maybe semihalf has already done a port?

No, we haven't finally managed to (despite a couple of approaches :-), but the thing is not at all very difficult as you said. One needs to provide U-Boot context/restore and the MIPS 'syscall' routine, plus debugging. The rest of /boot/ubldr code is independent of the arch.

Rafal



help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46D6F510-A824-4F00-9B77-E804A417324D>