[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#535339: Openmoko Neo Freerunner (GTA02) support



Hi

On Fri, Sep 11, 2009 at 01:07:41PM +0100, Martin Michlmayr wrote:
> * x@muc.ccc.de <x@muc.ccc.de> [2009-07-01 19:30]:
> > Package: flash-kernel Version: 2.19 Severity: wishlist
> > 
> > I checked the flash-kernel script and it seems the Openmoko Neo
> > Freerunner (GTA02) isn't among the supported machines.  After taking
> > a look i came to the conclusion that it's probably a better idea to
> > provide someone having the full-scope with the platform specific
> > stuff instead of trying hard but probably still breaking something
> > or at least 'not doing it properly' myself.
> 
> Sorry for the delay but I didn't see your bug report when you file it.
> Gaudenz Steinlin has been working on d-i support for the Freerunner,
> so I assume that he has patches for flash-kernel.
> 
> Gaudenz, can you comment?

I'm still stuck with the kernel as the linus tree does not yet include
all the needed pieces for minimal openmoko support. I'm tring to prepare
a patch for the Debian kernel package that adds a s3c24xx (openmoko) flavour. 
Thus I had no time to work on flash-kernel yet. At debconf Per (CCed)
was doing so research on how to add support to flash-kernel. 

> 
> > so:
> > 
> >   grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//'
> > 
> > returns
> > 
> >   GTA02
> > 
> > the mkimage calls i'm currently using manually are:
> > 
> >   mkimage -A arm -O linux -T ramdisk -C none -a 0x32800000 -n
> >   "Ramdisk Image" -d "/boot/initrd-$version.cpio.gz"
> >   "/boot/initrd-$version.cpio.gz.ub" mkimage -A arm -O linux -T
> >   kernel -C none -a 0x32000000 -n "Kernel Image" -d
> >   "/boot/kernel-$version.cpio.gz" "/boot/initrd-$version.cpio.gz.ub"

The plan is to not use two seperate uboot images for kernel and initrd
but to use a combined image of type "multi" which includes both. For
this to work you can't use the normal zImage, but the kernel image which
is at arch/arm/boot/compressed/vmlinux. Don't ask me why, but it's the
only one which works this way. The resulting image should be called
uImage.bin

> > 
> > It might be best not to do anything else after creating the
> > uboot-images in /boot, but let the user do the rest, as there are
> > plenty of different possibilities regarding the bootloader used, the
> > media and partition where the images are located, and the general
> > setup. E.g. i'm using a uboot bootloader that supports sdhc and
> > ext2, with a cryptroot setup with the boot-partition being the first
> > partition on the sdhc-card, so to set the default boot entry the
> > correct command would be (just in case you might have an idea on how
> > to implement this in a sane and safe way):

With the multi image you should be able to use the factory default
u-boot configuration of the GTA02. Which includes a boot menu entry for
booting from the first partition of the SD card. This partition must be
FAT formatted.

With this we don't need to modify the uboot environment. We only have to
copy the image to the right place. 

Of course this process should be configurable to be adapted to different
boot loader configuration. How to exactly achieve this is not yet clear.

Gaudenz

> > 
> >   uboot-envedit -i /dev/mtd2 -o /dev/mtd2 bootcmd="setenv bootargs
> >   \${bootargs_base} rootfstype=ext2 root=/dev/mapper/modi
> >   rootdelay=5 \${mtdparts} ro quiet; mmcinit; sleep 1; ext2load mmc
> >   1 0x32000000 /kernel.ub; ext2load mmc 1 0x32800000 /initrd.ub;
> >   bootm 0x32000000 0x32800000"
> > 
> > (these are the (factory default) variables set in the uboot
> > environment:
> > 
> >   bootargs_base=rootfstype=jffs2 root=/dev/mtdblock6
> >   console=ttySAC2,115200 console=tty0 loglevel=8 regular_boot
> >   mtdparts=mtdparts=physmap-flash:-(nor);neo1973-nand:0x00040000(u-boot),0x00040000(u-boot_env),0x00800000(kernel),0x000a0000(splash),0x00040000(factory),0x0f6a0000(rootfs)
> > 
> > just to provide all info so you can be sure there's no pitfall
> > hidden somewhere)
> > 
> > "bootcmd" is the variable in the uboot environment used by uboot for
> > the default boot procedure.  "mmcinit" is necessary to initialize
> > sdhc. the "sleep 1" is necessary as there seems to be a bug
> > somewhere (probably mmcinit) that makes the loading from sdhc break
> > if it's done immediately after mmcinit returns. "ext2load" is used
> > to load the image from an ext2 partition. for fat partitions, the
> > command is called "fatload". for both, the first argument "mmc"
> > tells them that the image to load is located on the sdhc card. the
> > next argument is the partition number (starting at 1), followed by
> > the memory address to load the image to, followed by the path (on
> > the partition, hence /... and not /boot/...) of the image to load.
> > "bootm" is the command to start the kernel (at the first address
> > given) with the initrd (at the second address given).
> > 
> > oh and i just checked:
> > 
> >   for i in /dev/mtd?; do if uboot-envedit -p -i $i >/dev/null 2>&1;
> >   then echo $i; break; fi; done
> > 
> > works to find the uboot environment device (uboot-envedit checks the
> > environment crc).  i guess if it can be found, it might be
> > reasonably safe to write the "bootcmd" to it... dunno...  finding
> > the correct "root=" parameter should be solveable with
> > 
> >   mount|grep ' on / type'|awk '{ print $1 }'
> > 
> > or something like that... finding out whether /boot is ext2/ext3 or
> > fat, could be done by something like
> > 
> >   mount|grep ' on /boot type'|awk '{ print $5 }'
> > 
> > but that might not work for / (in cases where mount thinks the type
> > is 'auto')...
> > 
> > and in case you wonder: there are flash-partitions named 'kernel'
> > and 'rootfs'. why ignore them as install targets? i think that's
> > reasonable because: - the NAND-flash is 256MB alltogether. so
> > 'kernel' and 'rootfs' might probably be enough for kernel+initrd.
> > but a debian installation is probably not at all possible, or if it
> > is, it will hardly be useful... i.e. it's more or less necessary to
> > install debian on the sdhc card anyway.  - leaving the default
> > openmoko-os on the NAND-flash, at least for emergency-boot purposes,
> > is certainly a very good idea. using the 'kernel' and/or 'rootfs'
> > NAND-flash partitions for an os installed on a sdhc card would break
> > this, without any need or real advantage. so i doubt there's anyone
> > out there who did such a thing. :)
> > 
> > kind regards,
> > 
> > 	Chris
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.com/

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~

Attachment: signature.asc
Description: Digital signature


Reply to: