From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 29 17:49:04 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 983D0BBA; Mon, 29 Jul 2013 17:49:04 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E4F6A2540; Mon, 29 Jul 2013 17:49:03 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id c13so498363eek.5 for ; Mon, 29 Jul 2013 10:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=moBpmPuT2qvMn0lgaUS/trAIISbvM7oAuEcrrwpdxa4=; b=ojAJ4WRRHp+CXfwQfmyWbyC5LopNZyu85x1o6cgNLtejU/I/lPjG1Cfjegd73PTFEm XyMubtGgvIUDBWQ0pitD2euJIJY6X6kxrHb5E3LGxLP05cMoDXC3/U8Jbp3Jk3v/zQ56 yHefQ2sYDYqIawFYhMuK2Kj/Hev3XtxCNgH+qCj8J2NwE5OQagLhA4uJDICAOUhC9i08 6GfN0YYm4dXivEdhnAfOpc5oDWPKAwhgXgIHswlb07Mz7PQ0vMnZfndfv4CjvAnbzzRh gJKSPp7WR9e+HRburd+gC/0p/1saMncYlEg+y6jcCFtZ1rFXPsUB3cv33MRJFprwGvkK HD6w== MIME-Version: 1.0 X-Received: by 10.15.42.72 with SMTP id t48mr60680883eev.105.1375120142260; Mon, 29 Jul 2013 10:49:02 -0700 (PDT) Received: by 10.14.105.137 with HTTP; Mon, 29 Jul 2013 10:49:02 -0700 (PDT) In-Reply-To: <20130729151943.70ce473e14d88588337e57ba@ddteam.net> References: <20130729151943.70ce473e14d88588337e57ba@ddteam.net> Date: Mon, 29 Jul 2013 10:49:02 -0700 Message-ID: Subject: Re: Making Picostation m2HP work From: hiren panchasara To: Aleksandr Rybalko , Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:49:04 -0000 On Mon, Jul 29, 2013 at 5:19 AM, Aleksandr Rybalko wrote: > On Sun, 28 Jul 2013 11:51:09 -0700 > hiren panchasara wrote: > >> On Fri, Jul 19, 2013 at 12:41 PM, Adrian Chadd wrote: >> > So here's the fun bit: >> > >> > mtdparts=mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),5760k(rootfs),256k(cfg),64k(EEPROM) >> > >> > Now, strictly speaking, you don't _have_ to obey the kernel/rootfs >> > split. But the default 'boot' line executes a boot image from the >> > offset in flash where 'kernel' is. >> > >> > What I tend to do, if I can: >> > >> > * leave uboot and uboot-env where they are >> > * kernel is the first partition, good, so start it there but make it >> > 1.5mb so you have a chance in hell of fitting an lzma'ed uboot kernel >> > image in there >> > * you don't need a 256kb cfg partition, only 64k >> > * the last 64k (EEPROM) _MUST NEVER BE OVERWRITTEN_ as it contains the >> > calibration/config data for the wifi chip. >> > >> > So look at an existing hints file with the 'map' entries, and write up >> > a new set of map entries for the agreed flash layout. >> > >> > Once you've done that, post it here for sanity checking. >> Here is the hints file I am using: >> >> # mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM) >> >> hint.map.0.at="flash/spi0" >> hint.map.0.start=0x00000000 >> hint.map.0.end=0x00040000 # 256k u-boot >> hint.map.0.name="u-boot" >> hint.map.0.readonly=1 >> >> hint.map.1.at="flash/spi0" >> hint.map.1.start=0x00040000 >> hint.map.1.end=0x00050000 # 64k u-boot-env >> hint.map.1.name="u-boot-env" >> hint.map.1.readonly=1 >> >> hint.map.2.at="flash/spi0" >> hint.map.2.start=0x00050000 >> hint.map.2.end=0x00150000 # 1024k kernel >> hint.map.2.name="kernel" >> hint.map.2.readonly=1 >> >> hint.map.3.at="flash/spi0" >> hint.map.3.start=0x00150000 >> hint.map.3.end=0x006f0000 # 6528k rootfs >> hint.map.3.name="rootfs" >> hint.map.3.readonly=0 >> >> hint.map.4.at="flash/spi0" >> hint.map.4.start=0x006f0000 >> hint.map.4.end=0x00730000 # 256k config >> hint.map.4.name="config" >> hint.map.4.readonly=1 >> >> hint.map.5.at="flash/spi0" >> hint.map.5.start=0x00730000 >> hint.map.5.end=0x00740000 # 64k EEPROM >> hint.map.5.name="art" >> hint.map.5.readonly=1 > > Looks like you have mistake somewhere. Sum of mtd sizes give us 8M, but > last block you define end on 0x00740000, but must be 0x00800000 Thanks for catching that. I've updated that. > > # 256k(u-boot) > start=0x00000000 > end=0x00040000 > # 64k(u-boot-env) > start=0x00040000 > end=0x00050000 > # 1024k(kernel) > start=0x00050000 > end=0x00150000 > # 6528k(rootfs) > start=0x00150000 > end=0x007b0000 > # 256k(cfg) > start=0x007b0000 > end=0x007f0000 > # 64k(EEPROM) > start=0x007f0000 > end=0x00800000 > > Also, to not depend on kernel size limit you can back kernel and rootfs > into single image, but align rootfs offset to block size (64k here) > Than you will be able to replace kernel.end and rootfs.start with > "search" value: > hint.map.2.end="search:0x00100000:0x10000:.!/bin/sh" > hint.map.3.start="search:0x00100000:0x10000:.!/bin/sh" > > In that case geom_map will search for ".!/bin/sh" ("." is single-char > wildcard) starting at offset 0x00100000 (1MB) with 0x10000 (64k) step > til end of media. > > kernel must be packed, but format depend on what is supported by loader. > uboot can be compiled with gzip, bzip2 and lzma support, but every > compressor is optional. > > If everything too bad with loader uncompressor, you can use un-gzip > support in out trampoline. Maybe even extend it with embedded lzma which > already in sys/contrib. I am not completely following you here (as I do not understand very many things :-)) But currently I am trying to use adrian's scripts to generate image. I have following things: 1) AP91.initial.img - filesystem img 6.2M (generated by ubnt-mkfwimage/mkfwimage.c) 2) mfsroot-ap91.img.ulzma - mfsroot img 4.8M 3) kernel.AP91 - the kernel 3.5M Where/how should I load these files? Thanks, Hiren > >> > >> > (Then the next trick will be building a kernel and rootfs image that >> > will fit in those flash partitions.. then you write up a config file >> > for adrian's build scripts that enforce those size limits so you don't >> > generate overly large images, then we do a test erase/flash.) >> >> Kernel that is being generated is of 3.5M. Need to understand how to >> prepare complete image with your scripts. >> >> Thanks a lot, >> Hiren