--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: Openmoko Neo Freerunner (GTA02) support
- From: x@muc.ccc.de
- Date: Wed, 01 Jul 2009 19:30:16 +0200
- Message-id: <4A4B9D28.3070106@muc.ccc.de>
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.
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"
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):
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
--- End Message ---