Date: Thu, 25 Nov 2010 09:12:06 -0200 From: Luiz Otavio O Souza <lists.br@gmail.com> To: Milan Obuch <freebsd-mips@dino.sk> Cc: freebsd-mips@freebsd.org Subject: Re: [Re: First RSPRO deployed!] flash utility mkfwimage and RSPRO boot question Message-ID: <21DE95C5-CD5F-48C0-9569-C40D15BDC215@gmail.com> In-Reply-To: <201011241145.43480.freebsd-mips@dino.sk> References: <D74327E9-0A8A-4B46-B4DD-16D0FAF8E3BB@gmail.com> <201011181136.47152.milu@dat.pl> <CBBB7D88-210F-4706-A8FD-83FDA7EBA914@gmail.com> <201011241145.43480.freebsd-mips@dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 24, 2010, at 8:45 AM, Milan Obuch wrote: > On Thursday 18 November 2010 12:07:34 Luiz Otavio O Souza wrote: >> On Nov 18, 2010, at 8:36 AM, Maciej Milewski wrote: >>>>> Do you have proper name of this fw image? I've read somewhere that = it's >>>>> required. >>>>> My working name is RSPRO.ar7100pro.FreeBSD.Test and you can change = the >>>>> last two words for sure. >>>>=20 >>>> You mean the name of the file that mkfwimage generates? >>>> I just called it something like firmware-image... >>>>=20 >>>> I changed the name, but still got: >>>> TFTPD: Incoming connection from 192.168.1.102:25789 >>>> Received: 6881688 bytes >>>> Invalid image format (error: -2) >>>=20 >>> Actually not the filename but if you run mkfwimage with parameters = then >>> you have the version string which in my case is as above. >>>=20 >>> For building image I run: >>> mkfwimage -v RSPRO.ar7100pro.FreeBSD.Test -B RSPRO -o image.bin -k >>> kernel.gz\ -r rootfs >>=20 >> Yes, that is correct, i've used the following two version strings = with >> success: >>=20 >> RS.ar7100.FreeBSD - for routerstation >>=20 >> RSPRO.ar7100pro.FreeBSD - for rspro >>=20 >> Just pick the correct one for your board. >>=20 >> I've my scripts here (together with mkfwimage files): >> http://loos.no-ip.org:280/rspro/rs-mkfwimage.tar.gz >>=20 >> Hope it helps. >>=20 >=20 > Hi, >=20 > I can succesfully build world and kernel and using mkflash create an = image=20 > usable to be loaded by redboot and this is used on regular boot after = power=20 > on. Fine. I am using currently kernel in on board flash (spiflash) and=20= > filesystem on USB flash key. This way I am able to try native = buildworld on=20 > RSPRO (not too quick, much slower than cross build, but this is = expected),=20 > test ports etc. Great ! Building world works with CPUTYPE=3Dmips32 and for ports, add the = following line to /etc/make.conf: CFLAGS=3D-O2 -pipe -march=3Dmips32 > I observed one thing - original flash is partitioned into five parts,=20= > executing 'geom redboot list' tells names >=20 > 1. Name: redboot/RedBoot > 2. Name: redboot/RedBoot config > 3. Name: redboot/FIS directory > 4. Name: redboot/kernel > 5. Name: redboot/rootfs >=20 > and sizes >=20 > Mediasize: 196608 (192K) > Mediasize: 4096 (4.0K) > Mediasize: 61440 (60K) > Mediasize: 917504 (896K) > Mediasize: 15466496 (15M) >=20 > (total is 128 k, i. e. 2 * 64k blocksize, less than full flash, 16 M). = After=20 > flashing my kernel, sizes are >=20 > Mediasize: 196608 (192K) > Mediasize: 4096 (4.0K) > Mediasize: 61440 (60K) > Mediasize: 1638400 (1.6M) > Mediasize: 9895936 (9.4M) >=20 > (total is 4864 k, i. e. 76 * 64k blocksize, less full flash, 16 M). My=20= > original impression was that rest after kernel is left for rootfs, and = while=20 > it's not a problem in my scenario, if I would like to put a real = filesystem=20 > there, would it be limited in size this way or can I use all available = flash=20 > left after kernel? Could it be a bug in mkfwimage or some layout table = needs=20 > to be modified? I don't understand the calculation you've done... But that is the way the mkfwimage tool works, it creates two slices, on = for kernel and another for rootfs (the first three slices are fixed). It will extend the rootfs to 'all remaining space' on flash (even if we = set it as an empty 64k block - like the sample on my script). So in this case you can use the rootfs slice (with 9.4M) as you want = (remember it only works with 64k reads and writes). > Also, is it possible to have new, 'non-standard' partition created, = used e. g.=20 > to store some user config/data? And, one more, could a redboot = partition be=20 > assigned filesystem label? Yes, but not with mkfwimage. Look at pfsense sample: http://devwiki.pfsense.org/RouterStationPRO You can create the slices by hand that way. The geom_redboot class already add the slice label to /dev/redboot/label > On a related problem - there is no boot loader for mips (as = /boot/loader is=20 > for i386/amd64 and some variants). I would like to try it in place of = kernel=20 > and have real kernel with some kernel modules (if built and placed in=20= > /boot/kernel, they work just fine - I did it with nullfs module, = having=20 > if_vlan loaded gives me possibility to create arge1.1 etc) and some = loader=20 > config, which could be used to set some FDT object properties if we = decide to=20 > move later in this direction. All this would mean greater flexibility = in my=20 > eyes. Yeah, this is one is really missing... >=20 > Naturally, flash aware filesystem would be the most elegant solution, = but we=20 > are not here, yet, unfortunatelly... Unfortunatelly not yet... Regards, Luiz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21DE95C5-CD5F-48C0-9569-C40D15BDC215>