* 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?
> 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
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
