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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2012-03-09, at 02:00, Warner Losh wrote: >=20 > On Mar 8, 2012, at 5:24 PM, Juli Mallett wrote: >=20 >> Hey folks, >>=20 >> 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. >>=20 >> 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'. >>=20 >> 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. >>=20 >> 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? >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46D6F510-A824-4F00-9B77-E804A417324D>