> > > So now I'm in the unfortunate situation that different
> > > bootloaders require different and incompatible kernel image
> > > formats but the infrastructure for handling kernels in Debian
> > > assumes that there is _one_ canonical kernel image format per
> > > architecture (which is true for all Debian architectures except
> > > RISC-V), i.e. I cannot simply ship the kernel in two different
> > > formats.
> > >
That sounds bizarre and I was not aware of such a problem until now.
Very educational.
> > What is the standard kerne image format for arm64/x86 ?
>
> For x86/amd64 bzImage, for armhf zImage and for arm64
> plain Image (similar to what your booti patches use).
What I see on my tiny ASUS TinkerBoard :
arm7$
arm7$ uname -a
Linux arm7 4.4.132+ #1 SMP Tue Oct 23 18:03:49 CST 2018 armv7l GNU/Linux
arm7$ ls -lapb /boot
total 53518
drwxr-xr-x 5 root root 1536 Jan 1 1970 ./
drwxr-xr-x 23 root root 4096 Mar 26 08:09 ../
-rwxr-xr-x 1 root root 3027355 Oct 27 2018 System.map-4.9.0-8-armmp-lpae
-rwxr-xr-x 1 root root 190506 Oct 27 2018 config-4.9.0-8-armmp-lpae
drwxr-xr-x 2 root root 512 Mar 24 16:47 extlinux/
drwxr-xr-x 2 root root 512 Mar 24 16:47 hdmi/
-rwxr-xr-x 1 root root 304 Oct 23 2018 hw_intf.conf
-rwxr-xr-x 1 root root 17349059 Mar 24 18:17 initrd.img
-rwxr-xr-x 1 root root 18576809 Mar 26 08:06 initrd.img-4.9.0-8-armmp-lpae
drwxr-xr-x 2 root root 2560 Mar 24 16:47 overlays/
-rwxr-xr-x 1 root root 72281 Oct 23 2018 rk3288-miniarm.dtb
-rwxr-xr-x 1 root root 3821600 Oct 27 2018 vmlinuz
-rwxr-xr-x 1 root root 3821600 Oct 27 2018 vmlinuz-4.9.0-8-armmp-lpae
-rwxr-xr-x 1 root root 7930936 Oct 23 2018 zImage
arm7$
Sadly getting that thing to boot anything else other than the 4.4.132+
version that gets shipped is some sort of a mystery to me. Also it is
stuck with using a FAT32 boot partition and thus the Debian update
scripts fails because the metadata for files simply doesn't exist.
Debian on ppc64 is very reasonable looking and behaves much like any
amd64/x86_64 boxen for kernel updates and such. With the obvious
exception being that there is openfirmware to deal with and that means
GRUB is still a bit of work.
ppc64$
ppc64$ uname -a
Linux hydra 4.19.0-2-powerpc64 #1 SMP Debian 4.19.16-1 (2019-01-17)
ppc64 GNU/Linux
ppc64$ cat /etc/debian_version
buster/sid
ppc64$
ppc64$ ls -lapb /boot/
total 56092
drwxr-xr-x 2 root root 4096 Apr 6 05:21 ./
drwxr-xr-x 22 root root 4096 Jan 14 00:27 ../
-rw-r--r-- 1 root root 170238 Jan 17 18:56 config-4.19.0-2-powerpc64
lrwxrwxrwx 1 root root 29 Jan 28 11:23 initrd.img ->
initrd.img-4.19.0-2-powerpc64
-rw-r--r-- 1 root root 26797511 Apr 6 05:21 initrd.img-4.19.0-2-powerpc64
-rw-r--r-- 1 root root 4300219 Jan 17 18:56 System.map-4.19.0-2-powerpc64
lrwxrwxrwx 1 root root 26 Jan 28 11:23 vmlinux ->
vmlinux-4.19.0-2-powerpc64
-rwxr-xr-x 1 root root 26072720 Jan 17 18:56 vmlinux-4.19.0-2-powerpc64
ppc64$
However I have grub booting and working fine on ppc64.
However arm and ppc64 are both slightly off topic here. Sorry.
Merely providing a reference point.
>
> Thanks for the information. So we can proceed with plain Image/Image.gz
> for now as that suits both Fedora/Debian.
>
> > AFAIK, there is no standard related to Linux Image format in
> > RISC-V land. It would be a good to have one and include it in
> > the Unix Platform specification. We can discuss pros/cons of
> > different format and agree on something during the first
> > meeting which is scheduled next Wednesday (1st May 2019).
Hold on. Why UNIX Platform spec and Linux mixed together? Consistency
is a wonderful thing but I doubt that Oracle folks will ever care to
port Solaris to RISC-V. With FreeBSD 13 I can boot with bbl now and
the FreeBSD kernel format is a bit of a mystery to me. Sorry. I may
look into that.
> >
> > If you want you can join here.
> >
https://lists.risc-v.org/g/tech-unixplatformspec/topics
>
> Getting to an agreement about a standard format would IMHO be
> very useful. Unfortunately I cannot join the Unix platform
> working group discussion because it is only open to RISC-V
> foundation members, but I am not a member and cannot become one
> because doing so would require signing an NDA as part of the
> membership agreement and that is unacceptable to me.
No surprise. Depends on who the members are that are involved but I
doubt that folks from Oracle, IBM and SCO are in there together. If at
all.
>
> For arm64, the kernel format (flat kernel with a specific header)
> and the boot interface are defined in the Linux kernel source
> tree in Documentation/arm64/booting.txt, including the
> conventions for non-EFI and EFI boot. Having a similar document
> for RISC-V would IMHO solve the issue. Discussions about such a
> document should be held in the open, though, in particular as
> this should go into the Linux kernel and doing so requires public
> discussion and review on the respective kernel mailing lists
> anyway.
>
>
> Of course. Anything related to kernel documentation or source goes into
> kernel mailing list for discussion.
> Me & David had a similar discussion about putting up a booting document
> for RISC-V similar to Documentation/arm64/booting.txt.
> I will send it to the mailing list once the booti patches are accepted
> in kernel/U-Boot.
>
So for right now, at this moment, there are maybe two people looking at
this discussion and they are from Western Digital and the other Sifive.
I guess that makes me the non-corporate old UNIX guy.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional