From owner-freebsd-mips@FreeBSD.ORG Sat Apr 9 12:29:50 2011 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 E3320106566B; Sat, 9 Apr 2011 12:29:50 +0000 (UTC) (envelope-from freebsd-mips@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4CE8FC12; Sat, 9 Apr 2011 12:29:49 +0000 (UTC) Received: from atom.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by loki.netlab.sk with ESMTPSA; Sat, 09 Apr 2011 14:29:40 +0200 id 00033C04.4DA05134.0000A681 Date: Sat, 9 Apr 2011 14:29:31 +0200 From: Milan Obuch To: Aleksandr Rybalko Message-ID: <20110409142931.3d1884a9@atom.dino.sk> In-Reply-To: <20110408113132.3c1df0a8.ray@dlink.ua> References: <20110331101554.68171eed@atom.dino.sk> <20110331142640.07f2101b@atom.dino.sk> <20110401005733.3598e82c.ray@ddteam.net> <20110408095712.1fc36066@atom.dino.sk> <20110408113132.3c1df0a8.ray@dlink.ua> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , freebsd-mips@freebsd.org Subject: Re: [RFC] Re: TP link MR3220 status, boot from flash via u-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: Sat, 09 Apr 2011 12:29:51 -0000 On Fri, 8 Apr 2011 11:31:32 +0300, Aleksandr Rybalko wrote: > On Fri, 8 Apr 2011 09:57:12 +0200 > Milan Obuch wrote: > > >> On Fri, 1 Apr 2011 00:57:33 +0300, Aleksandr Rybalko > >> wrote: [ snip ] > >> > Draft for wiki page 'Run from NOR flash with U-Boot' > >> > > >> > >> In my case, to be exact, there is SPI flash, actually... > > SPI is a interface, but flash type also NOR, IIRC > Well, maybe, but I found no mention about that in datasheet from Eon (cFeon) for EN25F32... but this is not that important. > >> > Keywords: U-Boot, embedded > >> > > >> > 1. Ask U-Boot: "what do you support to boot?" > >> > > >> > Normally, U-Boot use special image for kernel/ramfs packing. But > >> > we need to know which compression support U-Boot that fleshed to > >> > our target board. > >> > > >> > >> This one is easy - I can use gzip packed kernel only. If I try > >> other compressing method, u-boot complains with 'bad gzip data' > >> message so this one is clear in this case, I think. > > Did you try all lzma typed (oldlzma, lzma and xz)? > > Because I made 4M system with kernel compressed with LZMA(oldlzma) > and fs is iso.ulzma In gzipped kernel case we have kernel partition > 200-600 Kb bigger. Then it hard to make usable FS. > For lzma, u-boot told 'bad gzip data, must reset'. No joy. I have no idea on old lzma method, will try xz, but I have little hope it will be any better. [ snip ] > >> > 2. Create image > >> > 2.1. More canonical way, we have mkimage, gzip or bz2 and > >> > compiled kernel, maybe kernel.bin also. > >> > > >> > > >> > gzip --best --force vmlinux.bin > >> > > >> > > >> > for ELF kernel: > >> > > >> > mkimage -A mips -O linux -T kernel \ > >> > -C gzip \ > >> > -a ${LOAD_ADDRESS} \ > >> > -e ${START_ADDRESS} \ > >> > -n 'FreeBSD Kernel Image' \ > >> > -d kernel \ > >> > kernel.uboot > >> > > >> > LOAD_ADDRESS - in most cases this is RAM base address > >> > START_ADDRESS = LOAD_ADDRESS + ELF_HEADER_SIZE (0x1000 for ELF > >> > image) > >> > > >> > for kernel.bin: > >> > > >> > LOAD_ADDRESS = RAM_BASE_ADDRESS + 0x1000 > >> > START_ADDRESS = RAM_BASE_ADDRESS + 0x1000 > >> > > >> > Don't forget to check/change KERNLOADADDR of kernel config file. > >> > KERNLOADADDR must be equal to START_ADDRESS. > >> > > >> > >> I tried it various way, no success yet. When I load kernel via > >> TFTP to address set in kernel config (0x80050000 in my case) I can > >> issue a go command to 'start' address, usually 0x80050100, but > >> sometimes it is 0x80050120 - I am checking for this after kernel > >> is built - and kernel boots correctly and works. > > 0x80050120 - something weird (maybe 0x20 U-Boot or TPlink header size) This has nothing to do with u-boot or tplink, yet. It comes from running command 'nm kernel | grep _start'. For some reason sometimes there is somewhat bigger ELF header, no idea why. > 0x80050100 - START_ADDRESS in case we use elf > > to save some space make > objcopy -S -O binary kernel kernel.bin > then run mkimage with load and start address 0x80050100 > Will try with -O binary, actually I am using it now without this option. > >> As already mentioned, there is a mktplinkfw utility, which combines > >> kernel and root fs (or uses kernel with embedded root fs), > >> prepends a required header and pads generated image to full size > >> of flash minus 128 kB for u-boot itself. I am able to flash such > >> image into flash, but bootm tells only about success uncompressing > >> kernel, starting kernel and that's all. > > I not work with mktplinkfw yet, so I can't hint you about that. > > >> > >> ## Booting image at 9f020000 ... > >> Uncompressing Kernel Image ... OK > >> > >> Starting kernel ... > >> > >> Nothing more, powerdown necessary to start again. > >> > >> > 2.2. Longest way, but have smallest footprint, used only if > >> > U-Boot support LZMA. > >> > > >> > Problem 1: Current version of mkimage from ports, don't support > >> > LZMA. So we need new: > >> > http://my.ddteam.net/files/u-boot.new.tar.gz > >> > > >> > Problem 2: Devices I know support only old LZMA. > >> > I use LZMA 4.17. > >> > > >> > Then mkimage, like in 2.2., but -C lzma. > >> > > >> > 3. Now we have kernel U-Boot image, so transfer it to device and > >> > try with `bootm' command. > >> > > >> > 4. If all fine, write image to flash kernel partition. > >> > > >> > > >> > Hope this help :) > >> > > >> > >> [ snip ] > >> > >> Not much yet, unfortunatelly... > >> > >> On a side note, there is one thing to be addressed. As my device > >> has only 4 MB flash, I still need to shrink the image I would like > >> to use there. I could put there working kernel, when flash boot > >> issue is solved, but root fs not yet, together they do not fit. I > >> still need to save as much as 600 kB of space... Do you have any > >> tips to share? In some older mails here I saw you managed to do it > >> for other device... > > 1. compile with NOSHARED=no > 2. delete .h, .a, .o and many other docs and unused binary's (I think > that step you know :) ) 3. mkulzma+geom_uncompress instead > mkuzip+geom_uzip > There are following files at http://my.ddteam.net page: 2011-01-19_add_contrib_xz-embedded.patch 2011-01-19_geom_ulzma_and_mkulzma.patch 2011-01-21_geom_ulzma_and_uzip.diff 2011-01-23_geom_uncompress.diff 2011-01-23_geom_uncompress.patch 2011-01-24_mkulzma.patch Which one should I use? There is no mkulzma in base now... Regards, Milan