u-boot: Wrong Image Format for bootm command

[Bram Stolk]

I have been following these instructions:

https://linux-sunxi.org/Allwinner_Nezha#Mainline_kernel

But u-boot does not accept my kernel image.

I tried both Image.gz and Image

=> ext4load mmc 0:1 ${kernel_addr_r} Image
20515704 bytes read in 1906 ms (10.3 MiB/s)
=> bootm ${kernel_addr_r}
Wrong Image Format for bootm command
ERROR: can't get kernel image!

The load command works fine. But when trying to boot it from memory, the format is not accepted?

The image was built with:

$ make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu-
...
  OBJCOPY arch/riscv/boot/Image
  GZIP    arch/riscv/boot/Image.gz
  Kernel: arch/riscv/boot/Image.gz is ready

The host PC just identifies it as 'data' though:

$ file Image
Image: data

[Samuel Holland]

Hi Bram,

On 5/25/22 2:10 PM, Bram Stolk wrote:
> I have been following these instructions:
> https://linux-sunxi.org/Allwinner_Nezha#Mainline_kernel
>
> But u-boot does not accept my kernel image.
> I tried both Image.gz and Image
>
> => ext4load mmc 0:1 ${kernel_addr_r} Image
> 20515704 bytes read in 1906 ms (10.3 MiB/s)
> => bootm ${kernel_addr_r}
> Wrong Image Format for bootm command
> ERROR: can't get kernel image!
>
> The load command works fine. But when trying to boot it from memory, the format
> is not accepted?

"bootm" expects the kernel to be wrapped in a U-Boot-specific header. To boot an
unmodified Linux "Image" file, you need to use the booti command[1].

There is a (rather non-obvious, I admit) note to this effect on the wiki[2],
which I just edited to note that it also applies to RISC-V.

Regards,
Samuel

[1]: https://u-boot.readthedocs.io/en/latest/usage/cmd/booti.html
[2]: https://linux-sunxi.org/U-Boot#Booting_with_boot.cmd

[Bram Stolk]

Thanks again, Samual, for all your help.

Still not getting there:

=> booti ${kernel_addr_r} ${ramdisk_addr_r}:0 ${fdt_addr_r}
Moving Image from 0x40040000 to 0x40200000, end=415e10d8
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree

I will read up on "device trees" but I am not sure if I am responsible for setting that up before booting?

--

Owner/Director of Game Studio Abraham Stolk Inc.

Vancouver BC, Canada

b.s...@gmail.com

[Samuel Holland]

On 5/25/22 7:08 PM, Bram Stolk wrote:
> Thanks again, Samuel, for all your help.

>
> Still not getting there:
>
> => booti ${kernel_addr_r} ${ramdisk_addr_r}:0 ${fdt_addr_r}
> Moving Image from 0x40040000 to 0x40200000, end=415e10d8
> ERROR: Did not find a cmdline Flattened Device Tree
> Could not find a valid device tree
>
> I will read up on "device trees" but I am not sure if I am responsible for
> setting that up before booting?

It is recommended to reuse the devicetree from U-Boot, which is already loaded
into RAM. Its address is stored in the predefined environment variable[1]
$fdtcontroladdr. Since it appears you don't have a ramdisk, you can try:

booti ${kernel_addr_r} - ${fdtcontroladdr}

where the hyphen is a shortcut for "no ramdisk".

The devicetree at $fdtcontroladdr contains extra information detected by
firmware during boot, such as the size of RAM, which varies between boards. That
information would be missing, and Linux would fail to boot, if you loaded a DTB
file with "ext4load" or similar.

A generally simpler option may be to use an extlinux.conf file, since that hides
most of these details. The following example may be all you need:

# cat /boot/extlinux/extlinux.conf
label default
linux ../Image
append root=/dev/mmcblk0p2 rootwait
#

This will be loaded automatically if you mark your boot partition as bootable in
the partition table. Then you don't have to deal with environment variables,
booti vs. bootm, scripts, or devicetrees, etc.

Regards,
Samuel

[1]:
https://u-boot.readthedocs.io/en/latest/develop/devicetree/control.html?highlight=fdtcontroladdr#configuration

[Bram Stolk]

Awesome!

I now have the mainline kernel running.

Thanks for all your help.

I added this info to the wiki.

(I did have to add some kernel parameters to get the serial console.)

I also copied my Debian rootfs, and it works fine.

And indeed, the display stays black.

I do see the backlight come on, for the display.

But copying data to /dev/fb0 does nothing.

I'll try to poke around a bit, to see if I can get more info.

Maybe the driver has a verbose flag that I can turn on.

$ sudo fbset -v -i -s
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "480x480"
    geometry 480 480 480 480 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

Getting further frame buffer information
Frame buffer device information:
    Name        : sun4i-drmdrmfb
    Address     : 0
    Size        : 921600
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1920
    Accelerator : No

[Bram Stolk]

I will document what I can find about the RV86 screen, here: https://linux-sunxi.org/Lichee_RV_86_Panel

[Bram Stolk]

It got worse with the new u-boot?

I no longer have  a /dev/fb0 and this is reported by the kernel:

# journalctl | grep drm
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: Adding to iommu group 0
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5100000.mixer (ops 0xffffffff80c5f628)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5200000.mixer (ops 0xffffffff80c5f628)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: Adding to iommu group 0
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5100000.mixer (ops 0xffffffff80c5f628)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5460000.tcon-top (ops 0xffffffff80c63ca8)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5200000.mixer (ops 0xffffffff80c5f628)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5460000.tcon-top (ops 0xffffffff80c63ca8)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: No panel or bridge found... RGB output disabled
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5461000.lcd-controller (ops 0xffffffff80c5c6d8)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5470000.lcd-controller (ops 0xffffffff80c5c6d8)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: No panel or bridge found... RGB output disabled
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5461000.lcd-controller (ops 0xffffffff80c5c6d8)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5470000.lcd-controller (ops 0xffffffff80c5c6d8)
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5500000.hdmi (ops 0xffffffff80c5e718)
May 25 16:58:49 sipeed kernel: [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: bound 5500000.hdmi (ops 0xffffffff80c5e718)
May 25 16:58:49 sipeed kernel: [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: [drm] Cannot find any crtc or sizes
May 25 16:58:49 sipeed kernel: sun4i-drm display-engine: [drm] Cannot find any crtc or sizes
May 25 16:58:50 sipeed systemd[1]: Starting Load Kernel Module drm...
May 25 16:58:50 sipeed systemd[1]: Starting Load Kernel Module drm...
May 25 16:58:50 sipeed systemd[1]: modp...@drm.service: Deactivated successfully.
May 25 16:58:50 sipeed systemd[1]: Finished Load Kernel Module drm.
May 25 16:58:50 sipeed systemd[1]: modp...@drm.service: Deactivated successfully.
May 25 16:58:50 sipeed systemd[1]: Finished Load Kernel Module drm.
May 26 09:28:15 sipeed sudo[1098]:   sipeed : TTY=pts/0 ; PWD=/home/sipeed ; USER=root ; COMMAND=/bin/grep sun4i-drm /var/log/syslog
May 26 09:28:40 sipeed sudo[1124]:   sipeed : TTY=pts/0 ; PWD=/home/sipeed ; USER=root ; COMMAND=/bin/grep -a sun4i-drm /var/log/syg

Also, backlight is off now.

I grabbed the tgz and then built: u-boot-d1-2022-05-26 and ran mkimage again, and dd'd the toc1.

On Fri, May 27, 2022 at 7:33 AM Samuel Holland <sam...@sholland.org> wrote:

On 5/26/22 11:33 AM, Bram Stolk wrote:
> I will document what I can find about the RV86 screen, here:
> https://linux-sunxi.org/Lichee_RV_86_Panel

I figured out what was wrong with mainline -- I had forgotten the pinctrl node
in the devicetree for the RGB LCD interface. As a result, all of the data/clock
pins were tri-stated, and of course that meant no picture. It turns out the
driver itself was fine.

If you update to the latest U-Boot tag, that will come with the fixed
devicetree, and the panel should start working:

https://github.com/smaeul/u-boot/releases/tag/d1-2022-05-26

Regards,
Samuel

[Cheo fusi]

Hi

I've got the Lichee RV running https://github.com/smaeul/linux/blob/d1-wip-v5.18-rc4. Thanks Samuel. 

I also do not have a /dev/fb0 node. Maybe the DRM driver doesn't implement fbdev emulation yet ??

Sincerely,

Brandon.

[Bram Stolk]

>I also do not have a /dev/fb0 node. Maybe the DRM driver doesn't implement fbdev emulation yet ??

I have a /dev/fb0 with that kernel, although it has a colour issue, it does show up for me now.

Did you get the fixed u-boot to go with that kernel?

The link is in Samuel's reply.

 Bram

[Cheo fusi]

By 'fixed u-boot' do you Samuel's fork ? I'm using https://github.com/smaeul/u-boot/tree/d1-wip. 

Brandon