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

Bug#535339: marked as done (Openmoko Neo Freerunner (GTA02) support)

Your message dated Fri, 5 Nov 2010 14:10:44 +0000
with message-id <20101105141044.GA27312@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 owner@bugs.debian.org

535339: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535339
Debian Bug Tracking System
Contact owner@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.


  grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//'



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

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,


--- End Message ---
--- Begin Message ---
Version: 2.35

This has been implemented now.  See #593235

Martin Michlmayr

--- End Message ---

Reply to: