Re: odroid hc1 on debian?

2017-10-07 13:57 GMT+02:00 Karsten Merker <merker@debian.org>:

The installer handles this case well :-). At the point at which
it starts partitioning and formatting the installation target,
all components required by the installer are already in RAM, so
it is no problem to overwite the SD card from which the installer
had originally been loaded.

thanks great. Meanwhile I found we have a proper u-boot deb for the plattform with instructions for partitioning and merging the blobs into the bootloader:

u-boot-exynos_2017.09+dfsg1-2_armhf.deb

as for the hardware I wasn't clear enough: the vendor states the kernel and u-boot for xu4 works for hc1 without changes. And changes are pushed upstream, so the plain kernel/u-boot should be fine. The only new/different parts are usb2sata and usb-gige-network controllers, thanks to usb they should work with no issues.

Partitioning: first 2MB not used (partition table and uboot), then a fat partition for booting and then normal partitions.

I see the network-install image for armhf has vmlinuz and initrd.gz:

http://ftp.de.debian.org/debian/dists/testing/main/installer-armhf/20170828/images/network-console/

Also the device-tree/ directory has exynos5422-odroidxu4.dtb.

Thus two questions:

1.) I thought u-boot requires a plain kernel, but maybe this is outdated. Does it boot the compressed vmlinuz too?

2.) Is copying those files to the fat boot partition enough? any wiki page or similar with more info?

https://wiki.debian.org/DebianInstaller/NetworkConsole

the wiki page doesn't cover the use case of arm boards and microsd cards.

Ok, so that unfortunately means that there is no way for Debian
to provide official bootable SD card images for this platform.

sure. but images with zero blocks would be good enough. the u-boot deb already has a nice README explaining things, thus it seems to me only the documentation needs some clarity, but all necessary components are available. Will try later once I find some free time.

Debian has a separate u-boot binary for every platform as u-boot
is always platform-specific. U-Boot isn't only a bootloader like
GRUB but also provides BIOS-like functions (e.g. setting up the
DRAM controller and providing PSCI callbacks to the kernel, which
is highly hardware-dependent). The kernel itself is generic;
the platform-specific information required by the kernel is in
the device-tree file.

ok, sounds great. Thus we have u-boot, kernel and dtb file, and the binary blobs from the vendor.

Thus all I need to do is partition the microsd card and install files into the right sectors, create the fat partition,

download initrd, kernel and dtb file.

btw, I spend a brief moment looking at the u-boot source code and noticed config like

include/configs/odroid.h

#define CONFIG_DFU_ALT_BOOT_SD \

"u-boot raw 0x3f 0x800;" \

"bl1 raw 0x1 0x1e;" \

"bl2 raw 0x1f 0x1d;" \

"tzsw raw 0x83f 0x138\0"

with strings on the binary file I can find those again. Is there a nicer way to read those values? something to look up a value by the variable name or similar in a *.elf file or the u-boot binary?

The shell script to fuse blob and u-boot in the end encodes the same values, and it would be nice if they can't get out of sync.

I think the best way would be to get a serial console cable for
the board so that you can interact with u-boot and see debug
output. You could then start with the "generic" netboot installer
SD card image (which contains the kernel, the device-trees and
the installer, but no u-boot) and try adding a proper u-boot and
device-tree for your platform to it. Once this works, you could
then move on to trying it with the net-console variant.

To get the "generic" image, run the following steps:

$ wget https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/partition.img.gz
$ wget https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/firmware.none.img.gz
$ zcat firmware.none.img.gz partition.img.gz > SD_card.img

Note: today's daily image build has failed due to a kernel
upgrade in unstable that needs adjustments in the installer
source code; I'm just in the process of addressing that, so
please wait until tomorrow before trying it out ;-).

cool, thanks! I found the wiki page about this procedure:

https://wiki.debian.org/InstallingDebianOn/Allwinner

seems the same should work for my device, except I need to fuse in those binaries.

As long as the location of the proprietary bootcode for the Exynos
doesn't conflict with our standard partition layout, that should
work.

where can I read up what the d-i partition layout is?

https://anonscm.debian.org/cgit/d-i/

lists too many repositories to quickly download them all and hunt for the relevant file.

Thanks, Andreas