image-builder-odroid-c2
image-builder-odroid-c2 copied to clipboard
hypriot
U-boot loader hangs with a solid blue light
The U-boot loader hangs with a solid blue light, image created with:
flash -n minion9 https://github.com/hypriot/image-builder-odroid-c2/releases/download/v0.0.4/sd-card-odroid-c2-v0.0.4.img.zip
We still need some fine tuning. The boot loader expects the boot.ini to be loaded from a fat filesystem, but the image comes with only one large ext4 partition (which I prefer by myself). If you know how to work with u-boot, you can boot manually:
setenv m "1080p60hz" # Progressive 60Hz
setenv m_bpp "32"
setenv condev "console=ttyS0,115200n8 console=tty0"
setenv bootargs "root=UUID=f1ca88a5-b2d3-400d-8751-43a165b083e1 rootwait rw ${condev} no_console_suspend hdmimode=${m} m_bpp=${m_bpp} vout=${vout} fsck.repair=yes"
setenv loadaddr "0x11000000"
setenv dtb_loadaddr "0x1000000"
setenv initrd_loadaddr "0x13000000"
ext4load mmc 0:1 ${initrd_loadaddr} /boot/uInitrd
ext4load mmc 0:1 ${loadaddr} /boot/Image
ext4load mmc 0:1 ${dtb_loadaddr} /boot/meson64_odroidc2.dtb
booti ${loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}
Ok, thanks :) I was very eager getting my c2 up, and running docker. I found a temporary solution using odrobian.
I have the same issue. @umiddelb I could not make much sense of the automated setup, how can I use those scripts to get docker on C2? Are those intended to be executed on a odrobian distro? Which one should I run first?
Thanks
In the meantime we have ordered some C2 to have a faster feedback loop making this work.
To use these scripts you need to have you C2 up and running with ubuntu / debian / whatever.
If you run sh debian-01.sh you will end up with a complete Debian rootfs which will be able to run Docker. You need to copy these contents to the device you want to use with your C2. Due to current limitations you still need a vfat partition containing the boot.ini (if you don't want to modify the boot loader settings).
- you start with a 'used' uSD card (then you already got the boot loader), delete all existing partitions and create/format a 20 MB vfat partition and an ext4 partition covering the rest.
- you mount the ext4 partition to
/mntand the vfat partition to/mnt/media/boot - you copy the contents of ./rootfs to the uSD card:
cd ./rootfs; sudo find . | sudo cpio -dump /mnt - you need to adjust the bootargs settings for
root=...in/mnt/media/boot/boot.ini(sudo blkidwill tell you the right value for UUID) - you unmount
/mnt/media/bootand/mnt( and runsynca few times).
Now you have your plain Debian boot media for your C2.
I tried to follow those steps @umiddelb but I think I missed something that maybe between the lines there.
I started with a fresh odroibian install, I've cloned the repo and ran the debian-01.sh it all went well
I then deleted both partitions, and then created a FAT 32 with 20M and the ext4 (for some reason I could not create using mkfs, but the moment I've ran mount it seemed to be fine)
Copied all the files
I'm assuming the root=... you refer the UUID for the ext4 partition, used that
when I ran sudo sync I got an error about odroid64 not being a valid host
I tried to restart and I'm getting "invalid key" errors (hard to tell, resolution seems to be set to 640x480 on my TV.
I'm sure I did not followed the instructions, seems that I missed some steps that should seem trivial to a more experienced user like yourself.
Anything missing here?
Thanks
hm, you shouldn't try to overwrite the media you've booted from (mkfs refuses to create filesystems on partitions currently in use). You can attach an USB card reader to your C2 or build the rootfs on uSD while having booted from eMMC (and vice versa).
In case you have booted from eMMC (/dev/mmcblk0), you can initialize/erase your uSD(/dev/mmcblk1) prior to execute debian-01.sh. This script below will do the job and use the correct UUID referenced in boot.ini to create the root file system, so you don't have to adjust this setting in your boot.ini (the downside is that you will have two filesystems carrying the same UUID at the same time).
#!/bin/sh
dev=mmcblk1
curl -sSL http://dn.odroid.com/S905/BootLoader/ODROID-C2/c2_bootloader.tar.gz | tar -C /tmp -xzvf -
sudo dd if=/tmp/c2_bootloader/bl1.bin.hardkernel of=/dev/$dev conv=fsync bs=1 count=442
sudo dd if=/tmp/c2_bootloader/bl1.bin.hardkernel of=/dev/$dev conv=fsync bs=512 skip=1 seek=1
sudo dd if=/tmp/c2_bootloader/u-boot.bin of=/dev/$dev conv=fsync bs=512 seek=97
rm -rf /tmp/c2_bootloader/
sync
/bin/echo -e "o\nn\np\n1\n3072\n262143\nn\np\n2\n262144\n\nt\n1\nb\nw\n" | sudo fdisk /dev/$dev
sync
sudo mkfs.vfat -n boot /dev/${dev}p1
sudo mkfs.ext4 -O ^has_journal -b 4096 -L rootfs -U e139ce78-9841-40fe-8823-96a304a09859 /dev/${dev}p2
sudo mount /dev/${dev}p2 ./rootfs
sudo mkdir -p ./rootfs/media/boot
sudo mount /dev/${dev}p1 ./rootfs/media/boot
Maybe this is more of an issue with the build.sh script since U-boot should boot from a single ext4 partition. Just curious if anyone has actually run the script, loaded the image on SD and tried to boot it without making any modifications to boot.ini. I am starting to look in to this closer since I have tried the release image (does not boot) along with making a fresh image from the source per the instructions, same result
When running the tests, the results are as follows:
SD card image exists Partition table has one partition has a root-partition with a ext4 filesystem
Root filesystem is based on debian is debian version jessie is a HypriotOS has a HYPRIOT_OS= entry has a HYPRIOT_OS_VERSION= entry has a HYPRIOT_DEVICE= entry has a HYPRIOT_IMAGE_VERSION= entry is for architecure 'HYPRIOT_OS="HypriotOS/arm64"' is for device 'HYPRIOT_DEVICE="ODROID C2"' uses os-rootfs version 'HYPRIOT_OS_VERSION="v0.7.2"'
U-boot should boot from a single ext4 partition
Of course u-boot is able to load the kernel image, etc. from an ext4 partition, but the cfgload mechanism used in the C2 U-boot expects a vfat partition to load boot.ini from. cfgload is implemented in u-boot macro language and you can find various implementation across the different ODROID boards. At this time HK does't seem to be interested in fixing broken cfgload implementations, see here.
I've talked to @DieterReuter and we agreed on re-introducing a small vfat partition where the boot.ini is to be stored, the kernel image, dtb, etc. will remain on the ext4 partition.
Thanks. When will the build.sh script be adjusted to include the vfat partition for storing boot.ini so the generated image for C2 can be booted without having to manually address?
ping @StefanScherer ?
btw. there are no Aarch64 Debian packages on https://packagecloud.io/Hypriot/Schatzkiste at this time.
Since the C2 image is not functional without manual intervention, the best option recommended would be go for another distro and just use the other scripts to layer on docker and so forth?
@DarkBlaez It's our second shot of a SD card image for C2 and we still do not have C2 boards in our labs. Will be shipped next week. With a little help from the community we could be a little faster, I think. But any feedback is welcome, so we know better how you want to use such a SD image.
I also agree that we should add a vfat partition, it is also needed for the flash script or users to easily add some configuration for better firstboot experience.
@umiddelb And yes we also have to prepare a docker deb for aarch64.
@StefanScherer so if we end up with a leading FAT partition anyway, that would be interesting. The C2's SD card "slot" is badly accessible so I was thinking about putting the image on USB and just having the early boot stuff on SD. Please keep us posted with your experiences once you got the toys ;-)
You only need the leading FAT partition if you stick to the cfgload/boot.ini mechanism (HK's u-boot version for the C2 is unable to read the boot.ini file from ext2/ext4 filesystems) . If you use the u-boot environment directly (instead of boot.ini) you can omit this partition.
Like the Ubuntu Partition table as in http://odroid.com/dokuwiki/doku.php?id=en:c2_partition_table ?
@umiddelb Thanks for https://github.com/hypriot/image-builder-odroid-c2/issues/8#issuecomment-198248159 now as we have some devices I understand :-) Changing the boot.ini to ext4 for now as a small next step.