That looks much cleaner will try that.
Frank
On 05/01/19 22:58, Jared McNeill wrote:
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 <http://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 <kar...@netbsd.org
<mailto:kar...@netbsd.org>> 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>
