Your message dated Fri, 5 Nov 2010 14:10:44 +0000
with message-id <20101105141044.ga27...@jirafa.cyrius.com>
and subject line Implemented
has caused the Debian Bug report #535339,
regarding Openmoko Neo Freerunner (GTA02) support
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
535339: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535339
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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 ---
--- Begin Message ---
Version: 2.35
This has been implemented now. See #593235
--
Martin Michlmayr
http://www.cyrius.com/
--- End Message ---
