Re: odroid hc1 on debian?
On Sun, Oct 08, 2017 at 08:03:08PM +0200, Andreas Jellinghaus wrote:
> Some feedback on the u-boot-exynos package:
>
> The README.exynos is confusing me. Upstream calls the file
> README.odroid - not sure if it would be proper to edit that, or
> to fork it into a debian specific README for the packaging in
> the debian/ direcory.
Hello,
I cannot really follow you here. There is no file README.exynos
in the u-boot-exynos package, only a file README.odroid.gz:
$ dpkg -L u-boot-exynos
/.
/usr
/usr/lib
/usr/lib/u-boot
/usr/lib/u-boot/arndale
/usr/lib/u-boot/arndale/arndale-spl.bin
/usr/lib/u-boot/arndale/u-boot.bin
/usr/lib/u-boot/arndale/uboot.elf
/usr/lib/u-boot/odroid
/usr/lib/u-boot/odroid/u-boot.bin
/usr/lib/u-boot/odroid/uboot.elf
/usr/lib/u-boot/odroid-xu3
/usr/lib/u-boot/odroid-xu3/u-boot.bin
/usr/lib/u-boot/odroid-xu3/uboot.elf
/usr/share
/usr/share/doc
/usr/share/doc/u-boot-exynos
/usr/share/doc/u-boot-exynos/README.odroid.gz
/usr/share/doc/u-boot-exynos/changelog.Debian.gz
/usr/share/doc/u-boot-exynos/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/u-boot-exynos
> Here is the disconnect I noticed:
> * 2 group of boards are mentioned in the README, but the lib/u-boot/ folder in
> the package has three subdirectories.
> * No mention of which subdirectory for which board. I suppose -xu3 for the xu3/
> xu4/hc1 model. No idea what the arndale/ folder is about.
The Arndale is also a devboard (manufactured by a different
company than the Odroid boards) which uses an Exynos SoC as well:
https://en.wikipedia.org/wiki/Arndale_Board
> * The sd_fuse source for the xu4 should be different for xu4:
Indeed the offsets listed in
https://github.com/hardkernel/u-boot/tree/odroidxu4-v2017.05/sd_fuse
are different from the ones in the README.odroid.gz. I suppose
the values in the README are from older Odroid boards. Vagrant?
> # Download u-boot source tree with patches and binary files from hardkernel
> git clone https://github.com/hardkernel/u-boot -b odroidxu4-v2017.05
>
> Not sure if the partitioning is in sync. Debian uses 1MB
> before the first partition?
Yes, as that is the standard layout that all modern partitioning
tools use for MBR-style partition tables.
> Some files for hardkernel used a smaller space, other new files
> use 1MB for u-boot, thus need 2mb in total? Above location
> seems to aim for 720k for u-boot, thus yet another sizing?
I am unclear about where you took the 720k as an offset for
u-boot from. Did you derive that from the filename
"bl2.bin.hardkernel.720k_uboot"? That file isn't u-boot, but
bl2, i.e. the ATF "Trusted Boot Firmware". For an overview
of the ATF naming conventions please refer to
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.rst
Based on the values in the
https://github.com/hardkernel/u-boot/blob/odroidxu4-v2017.05/sd_fuse/sd_fusing.sh
the layout for the XU4 looks as follows:
Image | (512-bytes-)block offset | Size in blocks
------------------------------------------------------
bl1 | 1 | 30
bl2 | 31 | 29
u-boot | 63 | (varying)
tzsw | 1503 | 512
u-boot env | 2015 | 32
--> the last block in use would be 2047, which fits exactly with
the first partition starting at an offset of 1MB.
> Also they propose two partitions: one for fat with the boot
> files, one for the root fs (e.g. linux). Debian proposes the
> same, right? I noticed armbian uses one linux partition
> (haven't checked which fs), thus I wonder: can u-boot read from
> ext4 or similar? Are there reasons to not do that?
Modern u-boot versions (such as the Debian u-boot builds) can
read from FAT16/FAT32, ext2, ext3 and ext4 (although there are
some issues with some newer ext4 features). Older u-boot
versions and in particular many vendor-provided u-boot versions
can only read from FAT16/FAT32, but not from ext2/3/4. Debian
uses a FAT partition for the installer as that is the
widest-supported variant and for loading the installer there is
no need to have a POSIX-compliant filesystem. The partition with
the installer gets wiped anyway during the installation, so it
doesn't really matter for the final system. In the actual
installation created by the installer, the /boot partition is
ext2 by default; the / partition is ext4 by default. The /boot
and / partitions _must_ have POSIX-compliant filesystems, in
particular they must support hardlinks, which FAT doesn't do.
For systems that cannot boot directly from a POSIX-compatible
filesystem (i.e. only from FAT), flash-kernel provides a
mechanism to copy the kernel and the initrd to an additional
FAT partition on kernel installations and upgrades. This is
a workaround for broken/stone-aged u-boot versions and isn't
necessary for the u-boot versions that Debian ships.
A similar issue exists by the way also on amd64 systems with
UEFI. The EFI system partition cannot be used as /boot as the
UEFI spec mandates that it is FAT-formatted. Therefore amd64
UEFI systems mount it into /boot/efi with /boot itself using a
POSIX-compliant filesystem.
> https://d-i.debian.org/daily-images/armhf/daily/device-tree/README
> tells me the dtb files come from the linux kernel?
Yes, they are built from the kernel sources.
> The kernel is the same or close enough, so using the sd-card
> image from network but replacing the initrd and vmlinuz with
> the network-console variant is ok, even with keeping the dtb
> files unchanged?
Yes.
> I failed to find a source for the usb-uart converter with the
> odroid cable that ships within eu, is on stock and not priced
> extremely high, will need to continue hunting for one.
Does the XU4/HC1 work with a 3.3V cable or does it require one of
the rather rare (and expensive) 2.5V or 1.8V models? If a 3.3V
cable is sufficient, send me a PM for a resonably priced source
in Germany.
Regards,
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: