Re: odroid hc1 on debian?
On Sat, Oct 07, 2017 at 03:41:20PM +0200, Andreas Jellinghaus wrote:
> 2017-10-07 13:57 GMT+02:00 Karsten Merker <merker@debian.org>:
> 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?
On 32bit ARM platforms, vmlinuz is the standard kernel format
nowadays and u-boot handles that without problems. AFAIK on
arm64 the kernel doesn't build a vmlinuz though, only a plain
vmlinux.
> 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.
In principle, the only things needed are the kernel and the
initrd containing the installer, but then you would have to load
them "by hand" at the u-boot prompt. In practice, one usually
wants to have a u-boot bootscript that handles the autobooting
process, like the one at
https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/bootscript/all/bootscr.uboot-generic
The "generic" installer image already contains such a bootscript.
Please note that u-boot expects this bootscript to have a
u-boot-specific header, i.e. you cannot simply use a plaintext
bootscript, but instead have to create a "binary" version
with the following command from the u-boot-tools package:
mkimage -T script -A arm -d bootscript.plain.txt boot.scr
Modern u-boot versions that implement the "distro_bootcmd"
feature automatically look for the boot.scr and execute it.
> 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.
Sorry, no idea. The names of the components look like the system
uses ARM Trusted Firmware (ATF) / TrustZone. I am not
particularly familiar with that kind of stuff and this is the
first 32bit ARM devboard-style system that I actually see it used
on, although ATF is a more common occurence on arm64 devboards.
> 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?
The installer images use a standard MBR (i.e. MS-DOS-style)
partition table with the first partition (FAT32) starting at
(512-Bytes-)sector 2048, i.e. at an offset of 1MB from the start
of the medium. The space between the MBR and the first partition
is used for u-boot and the u-boot environment. The actual
position of u-boot within this area is platform-dependent.
HTH,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: