pkgs
pkgs copied to clipboard
feat: add support for ODroid HC4
Adds the kernel module required to ensure proper functioning of the ODroid HC4's GPU so that HDMI output works as expected.
Adds the kernel module required to ensure proper functioning of the ODroid HC4's SATA ports.
Adds a u-boot variant for the ODroid HC4. This is not used directly, but rather flashed into the SPI of the unit so that it can boot Talos. Documentation on this process can be found in the Talos repo.
/ok-to-test
seems the build is failing. I guess the amlogic script needs something extra
seems the build is failing. I guess the amlogic script needs something extra
I believe the amlogic script is calling an amd64 binary, given that it is assumed that the build environment for u-boot
is amd64. This would also explain why it works on my machine where binfmt_misc
is used to be able to run both amd64 and arm64 binaries simultaneously in the same builder.
Any chance the arm64 builder could be updated to support running amd64 binaries? It'll be slow when it's used, but for this particular use case it shouldn't really matter.
Any chance the arm64 builder could be updated to support running amd64 binaries?
we use dedicated arm64 builder for arm
anyways what binary it's calling, there could be arm64 variant of it
I would also check if the scrip is just creating a final binary blog with BL31 appended, then should be easy to change it to use dd
another option is to build the u-boot for odroid in the amd64 section only https://github.com/siderolabs/pkgs/blob/main/u-boot/pkg.yaml#L20 in the else
part of this
we use dedicated arm64 builder for arm
Yes, I know. I'm wondering if that builder can be updated to include support for amd64
binaries for cases like this.
anyways what binary it's calling, there could be arm64 variant of it
It's calling aml_encrypt_g12a, which is vendored into the repo.
I would also check if the scrip is just creating a final binary blog with BL31 appended, then should be easy to change it to use dd
The script is signing the binaries in addition to other things. This isn't something that can be easily replaced with dd
, as far as I can tell.
Yes, I know. I'm wondering if that builder can be updated to include support for amd64 binaries for cases like this.
you can build the whole u-boot for odroid in the amd64 section, and use CROSS_COMPILE
option i believe
you can build the whole u-boot for odroid in the amd64 section, and use
CROSS_COMPILE
option i believe
Right, but how do we handle this further down the chain? The installer
image is built with --platform=linux/arm64
, for example.
It seems like it would be a lot cleaner to just enable binfmt_misc
on the arm builder and use it sparingly rather than having to massively complicate the build chain for this special case.
binfmt_misc
won;t work as the ci is on talos and the KSPP requires it to be disabled. The installer image can refer the amd64 in the talos dockerfile
Would this also make talos work on an Odroid C4 and Odroid N2+?
@mirceanton The C4 and HC4 are identical with the exception of the SATA ports, so yes. I'm not as sure about the N2+, but I believe the answer is also yes.
All of those boards have support in the upstream kernel, so it's mostly a question of packaging Talos and getting the bootloader situation sorted.
@DWSR this can be now moved to using an overlay. probably a new repo, since amlogic seems to be different from allwinner.
See this: https://github.com/siderolabs/overlays/