Date: Sat, 9 Apr 2011 14:29:31 +0200 From: Milan Obuch <freebsd-mips@dino.sk> To: Aleksandr Rybalko <ray@dlink.ua> Cc: Aleksandr Rybalko <ray@ddteam.net>, freebsd-mips@freebsd.org Subject: Re: [RFC] Re: TP link MR3220 status, boot from flash via u-boot question Message-ID: <20110409142931.3d1884a9@atom.dino.sk> In-Reply-To: <20110408113132.3c1df0a8.ray@dlink.ua> References: <20110331101554.68171eed@atom.dino.sk> <AANLkTik9r7XZn2yyJe37EXYXfgkUzyt5Ne-eKd_XqGMO@mail.gmail.com> <20110331142640.07f2101b@atom.dino.sk> <20110401005733.3598e82c.ray@ddteam.net> <20110408095712.1fc36066@atom.dino.sk> <20110408113132.3c1df0a8.ray@dlink.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Apr 2011 11:31:32 +0300, Aleksandr Rybalko <ray@dlink.ua>
wrote:
> On Fri, 8 Apr 2011 09:57:12 +0200
> Milan Obuch <freebsd-mips@dino.sk> wrote:
>
> >> On Fri, 1 Apr 2011 00:57:33 +0300, Aleksandr Rybalko
> >> <ray@ddteam.net> 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.
> >> >
> >> > <code>
> >> > gzip --best --force vmlinux.bin
> >> > </code>
> >> >
> >> > for ELF kernel:
> >> > <code>
> >> > mkimage -A mips -O linux -T kernel \
> >> > -C gzip \
> >> > -a ${LOAD_ADDRESS} \
> >> > -e ${START_ADDRESS} \
> >> > -n 'FreeBSD Kernel Image' \
> >> > -d kernel \
> >> > kernel.uboot
> >> > </code>
> >> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110409142931.3d1884a9>