Re: Hints for Bananapi and -current

[Jared McNeill <jmcneill%invisible.ca@localhost>]

So there is a better way to boot modern NetBSD/arm (using UEFI and bootarm.efi). If you want to boot the old way, it goes something like this:

  setenv bootargs root=ld0a console=fb

  fatload mmc 0 $kernel_addr_r netbsd-GENERIC.ub

  fatload mmc 0 $fdt_addr_r $fdtfile

  fdt addr $fdt_addr_r

  bootm $kernel_addr_r - $fdt_addr_r

This method relies on 1) the kernel being wrapped with a legacy U-Boot image header, and 2) both the kernel and .dtb file being present on the FAT partition.

Now on to the modern boot method..

Using U-Boot 2018.11 or later, setup a FAT partition with the following files on it:

  EFI/BOOT/bootarm.efi

  your-fdt-file.dtb

U-Boot will automatically launch the UEFI bootloader and you will be presented with a countdown timer. bootarm will load a native ELF kernel (by default /netbsd) from the first FFS partition on the same drive that the loader came from. In addition, bootarm passes information about where to find the root device to the kernel automatically, so you shouldn’t need to specify a root= option. GENERIC and GENERIC64 kernels are setup to automatically use fb when available, so console=fb is also no longer required.

Fast path to try this all out is to grab armv7.img from a build, add your U-Boot to it, and write to SD card. The image should boot automatically. Alternatively, you can download an image from www.invisible.ca/arm that has U-Boot already applied for your board.

Hope this helps!

Jared

On May 1, 2019, at 5:07 PM, Frank Kardel <kardel%netbsd.org@localhost> wrote:

Thanks - that got me beyond screen initialization.

but

bootm 82000000 - $fdt_addr_r root=ld0a console=fb

asked for the root device, swap, fs tape and init - so the parameters probably did not reach the kernel at all.

starting X didn't show anything on the 4K screen, X seemed to be running though.

I am also not sure whether the Bananapi HDMI can do the u-boot determined 3940x2160 resolution. I have yet to play around with hdmi configuration.

The dmesg output is attached.

Adding a usb keyboard uncovered a panic while awaiting root device input:

[   3.4159917] ehci1: handing over low speed device on port 1 to companion controller
[   3.6660050] boot device: <unknown>
[   3.6660050] root device: uhidev0 at uhub3 port 1 configuration 1 interface 0
[   5.0672791] uhidev0: DaKai (0xe8f) 2.4G RX (0xa8), rev 1.10/3.11, addr 2, iclass 3/1
[   5.1663953] ukbd0 at uhidev0: 8 Variable keys, 6 Array codes

[   5.3375655] This port is broken, it does not call cnpollc() before calling cngetc().
[   5.4375739] This should be fixed, but it will work anyway (for now).
[   5.6775820] wskbd0 at ukbd0: console keyboard, using wsdisplay0
[   5.7732545] uhidev1 at uhub3 port 1 configuration 1 interface 1
[   5.8694170] uhidev1: DaKai (0xe8f) 2.4G RX (0xa8), rev 1.10/3.11, addr 2, iclass 3/1
[   5.9727975] panic: usbd_transfer: not done
[   6.0611224] cpu0: Begin traceback...
[   6.1478907] 0x9c695b84: netbsd:db_panic+0x14
[   6.2380975] 0x9c695b9c: netbsd:vpanic+0x194
[   6.3276372] 0x9c695bb4: netbsd:snprintf
[   6.4161552] 0x9c695bf4: netbsd:usbd_sync_transfer
[   6.5075330] 0x9c695c34: netbsd:usbd_do_request_flags+0xa4
[   6.6012676] 0x9c695c4c: netbsd:usbd_do_request+0x20
[   6.6932964] 0x9c695c7c: netbsd:usbd_set_idle+0x70
[   6.7838060] 0x9c695d54: netbsd:uhidev_attach+0xdc
[   6.8737881] 0x9c695d8c: netbsd:config_attach_loc+0x1b4
[   6.9701440] 0x9c695dbc: netbsd:config_found_sm_loc+0x54
[   7.0606941] 0x9c695e5c: netbsd:usbd_attachinterfaces+0x1b0
[   7.1525235] 0x9c695e8c: netbsd:usbd_probe_and_attach+0x84
[   7.2413633] 0x9c695ef4: netbsd:usbd_new_device+0x254
[   7.3280048] 0x9c695f5c: netbsd:uhub_explore+0x2dc
[   7.4155137] 0x9c695f84: netbsd:usb_discover.isra.2+0x74
[   7.5044602] 0x9c695fac: netbsd:usb_event_thread+0x84
[   7.5926830] cpu0: End traceback...
Stopped in pid 0.59 (system) at netbsd:cpu_Debugger+0x4: bx      r14

Any ideas ?

Frank

On 05/01/19 18:40, Jared McNeill wrote:

Remove the following devices from your kernel config and the kernel should use simplefb instead: sunxidebe, sunxitcon, sunxihdmi, sunxidep

I just peeked at the code quickly and it looks like the DE drivers are blindly using the display's advertised preferred mode without taking its own capabilities into consideration.


On Wed, 1 May 2019, Frank Kardel wrote:

I tried -current with my Bananapi an had limited success:

Using the first steps copying the image armv7 and the 2018.05 u-boot I found the u-boot load attempting to perform a dhcp boot as nothing was found on the mmc drive in autoboot. Did I miss somethnig to set up there ?

I finally got a kernel to start booting with following chants:

mmc dev 0

fatload mmc 0:1 $fdt_addr_r $fdtfile

fatload mmc 0:1 82000000 netbsd-GENERIC.ub

bootm 82000000 - $fdt_addr_r root=ld0a console=fb/none

The output always stops at:

[   1.0000000] NetBSD 8.99.37 (GENERIC) #2: Sun Apr 28 10:09:56 CEST 2019
[   1.0000000] kardel@Andromeda:/src/NetBSD/cur/src/obj.evbarm/sys/arch/evbarm/compile/GENERIC
[   1.0000000] total memory = 1022 MB
[   1.0000000] avail memory = 1012 MB
[   1.0000000] armfdt0 (root)
[   1.0000000] simplebus0 at armfdt0: LeMaker Banana Pi
[   1.0000000] simplebus1 at simplebus0
[   1.0000000] cpus0 at simplebus0
[   1.0000000] simplebus2 at simplebus0
[   1.0000000] simplebus3 at simplebus0
[   1.0000000] cpu0 at cpus0: Cortex-A7 r0p4 (Cortex V7A core)
[   1.0000000] cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled
[   1.0000000] cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
[   1.0000000] cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
[   1.0000000] cpu0: 256KB/64B 8-way write-through L2 PIPT Unified cache
[   1.0000000] vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
[   1.0000000] cpufreqdt0 at cpu0
[   1.0000000] cpu1 at cpus0
[   1.0000000] cpufreqdt1 at cpu1
[   1.0000000] gic0 at simplebus1: GIC
[   1.0000000] armgic0 at gic0: Generic Interrupt Controller, 160 sources (150 valid)
[   1.0000000] armgic0: 16 Priorities, 128 SPIs, 7 PPIs, 15 SGIs
[   1.0000000] fclock0 at simplebus2: 25000000 Hz fixed clock (mii_phy_tx)
[   1.0000000] fclock1 at simplebus2: 125000000 Hz fixed clock (gmac_int_tx)
[   1.0000000] fclock2 at simplebus2: 24000000 Hz fixed clock (osc24M)
[   1.0000000] fclock3 at simplebus2: 32768 Hz fixed clock (osc32k)
[   1.0000000] gtmr0 at simplebus0: Generic Timer
[   1.0000000] gtmr0: interrupting on GIC irq 27
[   1.0000000] armgtmr0 at gtmr0: ARM Generic Timer (24000 kHz)
[   1.0000420] sun4ia10ccu0 at simplebus1: A20 CCU
[   1.0000420] sunxinmi0 at simplebus1: NMI
[   1.0000420] sunxigmacclk0 at simplebus2: GMAC MII/RGMII clock mux
[   1.0000420] sunxigpio0 at simplebus1: PIO
[   1.0000420] gpio0 at sunxigpio0: 175 pins
[   1.0000420] sunxigpio0: interrupting on GIC irq 60
[   1.0000420] sunxisramc0 at simplebus1: SRAM Controller
[   1.0000420] sunxidebe0 at simplebus1: Display Engine Backend (display-backend@1e60000)
[   1.0000420] sunxidebe1 at simplebus1: Display Engine Backend (display-backend@1e40000)

So in summary I seem to get up to video initialization. For my 4K TV I had to increase the MAX_FB reserved memory to 32M but that didn't help, also not connecting any HDMI device didn't help.

The u-boot bootm command was change to manage ramdisk images thus the tips on our web site don't apply to the new bootm syntax.

Any other things I can try or that I overlooked?

Frank

<bananapi-boot-20190501.txt>