[Re: First RSPRO deployed!] flash utility mkfwimage and RSPRO boot question

[Luiz Otavio O Souza]

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.
>>>> 
>>>> You mean the name of the file that mkfwimage generates?
>>>> I just called it something like firmware-image...
>>>> 
>>>> I changed the name, but still got:
>>>> TFTPD: Incoming connection from 192.168.1.102:25789
>>>> Received:  6881688 bytes
>>>> Invalid image format (error: -2)
>>> 
>>> Actually not the filename but if you run mkfwimage with parameters then
>>> you have the version string which in my case is as above.
>>> 
>>> For building image I run:
>>> mkfwimage -v RSPRO.ar7100pro.FreeBSD.Test -B RSPRO -o image.bin -k
>>> kernel.gz\ -r rootfs
>> 
>> Yes, that is correct, i've used the following two version strings with
>> success:
>> 
>> RS.ar7100.FreeBSD - for routerstation
>> 
>> RSPRO.ar7100pro.FreeBSD - for rspro
>> 
>> Just pick the correct one for your board.
>> 
>> I've my scripts here (together with mkfwimage files):
>> http://loos.no-ip.org:280/rspro/rs-mkfwimage.tar.gz
>> 
>> Hope it helps.
>> 
> 
> Hi,
> 
> I can succesfully build world and kernel and using mkflash create an image 
> usable to be loaded by redboot and this is used on regular boot after power 
> on. Fine. I am using currently kernel in on board flash (spiflash) and 
> filesystem on USB flash key. This way I am able to try native buildworld on 
> RSPRO (not too quick, much slower than cross build, but this is expected), 
> test ports etc.

Great !

Building world works with CPUTYPE=mips32 and for ports, add the following line to /etc/make.conf:

CFLAGS=-O2 -pipe -march=mips32


> I observed one thing - original flash is partitioned into five parts, 
> executing 'geom redboot list' tells names
> 
> 1. Name: redboot/RedBoot
> 2. Name: redboot/RedBoot config
> 3. Name: redboot/FIS directory
> 4. Name: redboot/kernel
> 5. Name: redboot/rootfs
> 
> and sizes
> 
>   Mediasize: 196608 (192K)
>   Mediasize: 4096 (4.0K)
>   Mediasize: 61440 (60K)
>   Mediasize: 917504 (896K)
>   Mediasize: 15466496 (15M)
> 
> (total is 128 k, i. e. 2 * 64k blocksize, less than full flash, 16 M). After 
> flashing my kernel, sizes are
> 
>   Mediasize: 196608 (192K)
>   Mediasize: 4096 (4.0K)
>   Mediasize: 61440 (60K)
>   Mediasize: 1638400 (1.6M)
>   Mediasize: 9895936 (9.4M)
> 
> (total is 4864 k, i. e. 76 * 64k blocksize, less full flash, 16 M). My 
> original impression was that rest after kernel is left for rootfs, and while 
> it's not a problem in my scenario, if I would like to put a real filesystem 
> there, would it be limited in size this way or can I use all available flash 
> left after kernel? Could it be a bug in mkfwimage or some layout table needs 
> 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. 
> to store some user config/data? And, one more, could a redboot partition be 
> 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 
> for i386/amd64 and some variants). I would like to try it in place of kernel 
> and have real kernel with some kernel modules (if built and placed in 
> /boot/kernel, they work just fine - I did it with nullfs module, having 
> if_vlan loaded gives me possibility to create arge1.1 etc) and some loader 
> config, which could be used to set some FDT object properties if we decide to 
> move later in this direction. All this would mean greater flexibility in my 
> eyes.

Yeah, this is one is really missing...

> 
> Naturally, flash aware filesystem would be the most elegant solution, but we 
> are not here, yet, unfortunatelly...


Unfortunatelly not yet...

Regards,
Luiz