From owner-freebsd-mips@FreeBSD.ORG Thu Nov 25 11:12:15 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08F911065672 for ; Thu, 25 Nov 2010 11:12:15 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF1668FC0A for ; Thu, 25 Nov 2010 11:12:14 +0000 (UTC) Received: by yxh35 with SMTP id 35so416652yxh.13 for ; Thu, 25 Nov 2010 03:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=NimQdFlfWTUZ8bqcg9ylNJxGPlNf6KumgGJd4Zb958Q=; b=MJWbq2ldCc8vdiVzo4sxLc4kwEzLbFblY2zPosG5L9X8iYXO/hQyNS7s8lRchECZvu AC69vTYWRSqV2zRrkg0foUc6bsu2+f5IMzyMo5ituqA66gh6HxPrRkCks8wl2z2PXofc QuT1VyWjPO4aQYNYkWaRvPXrr15tcVvkXCAj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=i3S4h+C6H7SQ70rASbQo8/JC6vT8HGK7s5BeQeEwECPi9Nr3yzwvBF5+H7GewGUURA 6Na7t10Hfoc7x97dqE/5NtOBIOarV8T1gPorwRUY7MzqOo8BouaqjhiKFXzCcIQsiNKb TIFjsjLRcgDrIol7Sd0TFThVWhUwmHBps/l1Q= Received: by 10.150.52.18 with SMTP id z18mr2759144ybz.378.1290683532856; Thu, 25 Nov 2010 03:12:12 -0800 (PST) Received: from [192.168.0.86] ([187.39.15.80]) by mx.google.com with ESMTPS id p1sm513135ybn.5.2010.11.25.03.12.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Nov 2010 03:12:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luiz Otavio O Souza In-Reply-To: <201011241145.43480.freebsd-mips@dino.sk> Date: Thu, 25 Nov 2010 09:12:06 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21DE95C5-CD5F-48C0-9569-C40D15BDC215@gmail.com> References: <201011181136.47152.milu@dat.pl> <201011241145.43480.freebsd-mips@dino.sk> To: Milan Obuch X-Mailer: Apple Mail (2.1081) Cc: freebsd-mips@freebsd.org Subject: Re: [Re: First RSPRO deployed!] flash utility mkfwimage and RSPRO boot question X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 11:12:15 -0000 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