Add support for the SiFive HiFive Unmatched board
- Copy the bootscr.uboot-generic scripts for the riscv64 architecture.
- Add the HiFive Unmatched board to the data base.
- Enable building for the riscv64 architecture.
Closes (#1006926)
Merge request reports
Activity
Yes, riscv64 is a copy of arm64.
We currently have four architectures to consider:
- arm64
- armel
- armhf
- riscv64
armel and armhf both use bootscript/all/bootscr.uboot-generic.
Only when dropping architecture armel your suggestion would help.
How about having directories
- bootscript/all64/ for all 64bit architectures
- bootscript/all32/ for all 32bit architectures
Then we could
- Move all scripts from bootscript/armhf/ to bootscript/all32/.
- Move all scripts from bootscript/arm64/ to bootscript/all64/.
- Detect the bitness in debian/rules.
Best regards
Heinrich
Do any armel architectures use bootscr.uboot-generic?
It seems like the main difference between the two scripts is booti vs. bootm... and booti is used on arm64 and riscv64, and bootm is used on armhf and possibly armel?
Would it make sense to use boot script fragements, such as various imx boards do on armhf:
Machine: Wandboard i.MX6 Dual Lite Board
... U-Boot-Script-Name: bootscr.imx-base bootscr.uboot-genericThen it could become something like:
U-boot-Script-Name bootscr.imx-base bootscr.base bootscr.bootm
And riscv64 would become:
U-Boot-Script-Name: bootscr.base bootscr.booti
Ugh. It's kind of ugly to have to specify for each and every board...
If during the build it could assemble the bootscr.uboot-generic with a booti (arm64/riscv64) and bootm (armhf/armel) tail, maybe that would be better.... I don't know.
... not super fond of flash-kernel, but no time to make an alternative.
-
Vagrant Cascadian commented:
Do any armel architectures use bootscr.uboot-generic?
It seems like the main difference between the two scripts is booti vs. bootm... and booti is used on arm64 and riscv64, and bootm is used on armhf and possibly armel?
bootz is used on 32bit. booti is used on 64bit.
bootm is only used in non-generic scripts:
bootscript/arm64/bootscr.xgene-mustang bootscript/armhf/bootscr.cubox bootscript/armhf/bootscr.mx5 bootscript/armhf/bootscr.omap
Would it make sense to use boot script fragements, such as various imx boards do on armhf:
Machine: Wandboard i.MX6 Dual Lite Board ... U-Boot-Script-Name: bootscr.imx-base bootscr.uboot-generic
Then it could become something like:
U-boot-Script-Name bootscr.imx-base bootscr.base bootscr.bootm
And riscv64 would become:
U-Boot-Script-Name: bootscr.base bootscr.booti
Ugh. It's kind of ugly to have to specify for each and every board...
I think the easiest thing to do is adding a variable @@BOOTCMD@@ in bootstr.uboot-generic.
We can use 'dpkg-architecture -q DEB_HOST_ARCH_BITS' to determine if we are on a 64bit system or not and then do the replacement in mkimage_script().
If during the build it could assemble the bootscr.uboot-generic with a booti (arm64/riscv64) and bootm (armhf/armel) tail, maybe that would be better.... I don't know.
... not super fond of flash-kernel, but no time to make an alternative.
Flash-kernel is a useful helper both for GRUB and u-boot-menu.
On Ubuntu Jammy with non-secure boot flash-kernel is used to provide the devicetree loaded by GRUB's devicetree command. Ubuntu's GRUB then calls into U-Boot's EFI_DT_FIXUP_PROTOCOL to fixup the devicetree.
See: https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL https://lists.gnu.org/archive/html/grub-devel/2021-02/msg00012.html
Best regards
Heinrich
added 5 commits
Toggle commit listmentioned in commit d49a8462
-
@xypron thanks for working through it, that looks good to me!
-
I did think of a corner case; when building an environment on a foreign architecture, uname might not work to correctly to detect the architecture; any objection to switching to using dpkg --print-architecture instead? Is flash-kernel used outside of systems where dpkg is installed?
It would also obviously require forcing the Machine target in this case, so it is pretty niche, but still...
-
'dpkg --print-architecture' should also work fine. Both commands are in system-essential packages.
But you already merged the request with 'uname -m'.
To me it is unclear how would you run dpkg and uname such that the system call invoked by uname returns a different architecture than the architecture that dpkg was built for.
Best regards
Heinrich
-
Vagrant Cascadian commented on a discussion: !29 (comment 304743)
Well, 'uname -m' would return the wrong result when building an armhf image on a machine running an arm64 kernel.
Will just switch to dpkg --print-architecture...
We already have function get_mkimage_architecture().
I guess we need to add riscv64 there too?
Should we use $mkarch instead of calling 'dpkg --print-architecture'?
Best regards
Heinrich
-
At first thought, get_mkimage_architecture sounds better... although mkimage only takes "riscv" as an architecture; not sure we could use that to distinguish between riscv32, riscv64 or riscv128...
I don't know how realistic those other architectures are in the context of debian ever supporting them.
That said, it means any generated bootscripts on riscv64 are currently using "arm" as the architecture argument!
-
Vagrant Cascadian https://salsa.debian.org/vagrant commented on a discussion !29 (comment 304745):
At first thought, get_mkimage_architecture sounds better... although mkimage only takes "riscv" as an architecture; not sure we could use that to distinguish between riscv32, riscv64 or riscv128...
Looking at the platform specification for RISC-V riscv32 is not expected to be used for Linux distributions. If we ever see riscv128 this will be probably on servers not using U-Boot.
On Ubuntu the RISC-V kernel is called:
/boot/vmlinuz-5.15.0-1006-generic
On amd64:
/boot/vmlinuz-5.15.0-25-generic
So you don't have the architecture in the file name. get_kfile_suffix() returns "generic".
So it seems get_mkimage_architecture is broken.
I don't know how realistic those other architectures are in the context of debian ever supporting them.
That said, it means any generated bootscripts on riscv64 are currently using "arm" as the architecture argument!
For mkimage -T script the architecture is not relevant. We could simply drop the -arch parameter in
functions:498: mkimage -A "
saddr" -e "$saddr" \Best regards
Heinrich