Re: Hints for Bananapi and -current

[Markus Kilbinger]

Am Mi., 8. Mai 2019 um 00:51 Uhr schrieb Jason Thorpe :
>
> > On May 7, 2019, at 2:37 PM, Jared McNeill  wrote:
> >
> > On Tue, 7 May 2019, Markus Kilbinger wrote:
> >
> >> - I was not able to bootarm.efi this kernel from its local ffs2 (!)
> >> netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?
> >
> > It uses ffs support from libsa, so I would expect it to work (but can't say 
> > that I have tried it on armv7).
>
> ...and it looks like ffsv2 is in the fs ops table in efiboot, so... *boggle*

boogled:

1. I had to disklabel(8) my sdcard (was just fdisk-ed before) to make
bootarm.efi successfully find the kernel on its ffsv2 partition.
W/should be gpt-ing it sufficient, too?

2. Played with bootarm.efi (stored on sdcard) on my cubietruck and a
connected gpt-ed sata disk: u-boot seems to detect it as scsi disk, I
had to "scsi scan" before it and its partitions would be correctly
detected for / by bootarm.efi.
I managed to make bootarm.efi boot from the recognised sata disk by
setting manually "dev hd0b" at its boot prompt (defaults to the sdcard
"hd1a").
After tons of
  CACHE: Misaligned operation at range [bf4cdb70, bf4d1b70]
 messages it finally loaded the kernel from the harddisks ffsv2
partition ("hd0b" aka "dk1") and booted successfully into NetBSD :-).
2.1 How to get rid of the "CACHE..." messages?
2.2 How to instruct bootarm.efi to boot automatically from a
non-standard / -default device / partition?

Regards, Markus.

Re: Hints for Bananapi and -current

[Jason Thorpe]

> On May 7, 2019, at 4:54 PM, Andrew Luke Nesbit  
> wrote:
> This is a really great thread, which I am enjoying very much.
> 
> I don't use any  BPi because I am a user of Orange Pi (especially the
> OPi+2E).
> 
> But considering they are very close in architecture and use
> (essentially) the same SoC, I would imagine that a lot of the
> information  in this thread would be at least somewhat applicable to any
> OPi that uses the Allwinner H3.
> 
> Would I be correct in framing my re-interpretation of this discussion in
> this way?

Yah, you're pretty much correct.

(Note: Not all BPIs use AllWinner SoCs... there's at least one that uses a 
Mediatek SoC and at least one that uses a Realtek SoC.)

-- thorpej

Re: Hints for Bananapi and -current

[Andrew Luke Nesbit]

On 07/05/2019 22:37, Jared McNeill wrote:
> On Tue, 7 May 2019, Markus Kilbinger wrote:

[...]

This is a really great thread, which I am enjoying very much.

I don't use any  BPi because I am a user of Orange Pi (especially the
OPi+2E).

But considering they are very close in architecture and use
(essentially) the same SoC, I would imagine that a lot of the
information  in this thread would be at least somewhat applicable to any
OPi that uses the Allwinner H3.

Would I be correct in framing my re-interpretation of this discussion in
this way?

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Re: Hints for Bananapi and -current

[Jason Thorpe]

> On May 7, 2019, at 2:37 PM, Jared McNeill  wrote:
> 
> On Tue, 7 May 2019, Markus Kilbinger wrote:
> 
>> - I was not able to bootarm.efi this kernel from its local ffs2 (!)
>> netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?
> 
> It uses ffs support from libsa, so I would expect it to work (but can't say 
> that I have tried it on armv7).

...and it looks like ffsv2 is in the fs ops table in efiboot, so... *boggle*

-- thorpej

Re: Hints for Bananapi and -current

[Jared McNeill]

On Tue, 7 May 2019, Markus Kilbinger wrote:


- I was not able to bootarm.efi this kernel from its local ffs2 (!)
netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?


It uses ffs support from libsa, so I would expect it to work (but can't 
say that I have tried it on armv7).



- In case of a connected sata disk: Is it possible to directly boot
from that via bootarm.efi (or specify explicitly a boot device)?


Only if the UEFI implementation (in this case U-Boot) supports the SATA 
controller.


Cheers,
Jared

Re: Hints for Bananapi and -current

[Markus Kilbinger]

Am Di., 7. Mai 2019 um 12:17 Uhr schrieb Jared McNeill :
> [...]
> 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.

Great news!
It tried / played with that on my bananapro with some limited success:

- I just managed to boot successfully a netbsd elf kernel via network
/ pxe. (How to disable / reorder pxe booting?)

- I was not able to bootarm.efi this kernel from its local ffs2 (!)
netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?

- In case of a connected sata disk: Is it possible to directly boot
from that via bootarm.efi (or specify explicitly a boot device)?

Once the kernel is found and loaded everything seems to run fine!

Regards, Markus.

Re: Hints for Bananapi and -current

[Frank Kardel]

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  that has U-Boot 
already applied for your board.


Hope this helps!
Jared


On May 1, 2019, at 5:07 PM, Frank Kardel > wrote:


Thanks - that got me beyond screen initialization.

but

bootm 8200 - $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: 
[   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 8200 netbsd-GENERIC.ub

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

The output always stops at:

Re: Hints for Bananapi and -current

[Jared McNeill]

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  wrote:
> 
> Thanks - that got me beyond screen initialization.
> 
> but
> 
> bootm 8200 - $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: 
> [   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 8200 netbsd-GENERIC.ub
>>> 
>>> bootm 8

Re: Hints for Bananapi and -current

[Nick Hudson]

On 01/05/2019 21:07, Frank Kardel wrote:
[snip]


[   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 ?


This is likely missing interrupts. Does

show events

show you interrupts on

[   1.600] ehci1: interrupting on GIC irq 72

or

[   1.600] ohci1: interrupting on GIC irq 97

Nick

Re: Hints for Bananapi and -current

[Frank Kardel]

Thanks - that got me beyond screen initialization.

but

bootm 8200 - $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: 
[   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 8200 netbsd-GENERIC.ub

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

The output always stops at:

[   1.000] NetBSD 8.99.37 (GENERIC) #2: Sun Apr 28 10:09:56 CEST 
2019
[   1.000] 
kardel@Andromeda:/src/NetBSD/cur/src/obj.evbarm/sys/arch/evbarm/compile/GENERIC

[   1.000] total memory = 1022 MB
[   1.000] avail memory = 1012 MB
[   1.000] armfdt0 (root)
[   1.000] simplebus0 at armfdt0: LeMaker Banana Pi
[   1.000] simplebus1 at simplebus0
[   1.000] cpus0 at simplebus0
[   1.000] simplebus2 at simplebus0
[   1.000] simplebus3 at simplebus0
[   1.000] cpu0 at cpus0: Cortex-A7 r0p4 (Cortex V7A core)
[   1.000] cpu0: DC enabled IC enabled WB enabled LABT branch 
prediction enabled

[   1.000] cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
[   1.000] cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data 
cache

[   1.000] cpu0: 256KB/64B 8-way write-through L2 PIPT Unified cache
[   1.000] vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN 
propagation, denormals

[   1.000] cpufreqdt0 at cpu0
[   1.000] cpu1 at cpus0
[   1.000] cpufreqdt1 at cpu1
[   1.000] gic0 at simplebus1: GIC
[   1.000] armgic0 at gic0: Generic Interrupt Controller, 160 
sources (150 valid)

[   1.000] armgic0: 16 Priorities, 128 SPIs, 7 PPIs, 15 SGIs
[   1.000] fclock0 at simplebus2: 2500 Hz fixed clock 
(mii_phy_tx)
[   1.000] fclock1 at simplebus2: 12500 Hz fixed clock 
(gmac_int_tx)

[   1.000] fclock2 at simplebus2: 2400 Hz fixed clock (osc24M)
[   1.000] fclock3 at simplebus2: 32768 Hz fixed clock (osc32k)
[   1.000] gtmr0 at simplebus0: Generic Timer
[   1.000] gtmr0: interrupting on GIC irq 27
[   1.000] armgtmr0 at gtmr0: ARM Generic Ti

Re: Hints for Bananapi and -current

[Jared McNeill]

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 8200 netbsd-GENERIC.ub

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

The output always stops at:

[   1.000] NetBSD 8.99.37 (GENERIC) #2: Sun Apr 28 10:09:56 CEST 2019
[   1.000] 
kardel@Andromeda:/src/NetBSD/cur/src/obj.evbarm/sys/arch/evbarm/compile/GENERIC

[   1.000] total memory = 1022 MB
[   1.000] avail memory = 1012 MB
[   1.000] armfdt0 (root)
[   1.000] simplebus0 at armfdt0: LeMaker Banana Pi
[   1.000] simplebus1 at simplebus0
[   1.000] cpus0 at simplebus0
[   1.000] simplebus2 at simplebus0
[   1.000] simplebus3 at simplebus0
[   1.000] cpu0 at cpus0: Cortex-A7 r0p4 (Cortex V7A core)
[   1.000] cpu0: DC enabled IC enabled WB enabled LABT branch prediction 
enabled

[   1.000] cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
[   1.000] cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
[   1.000] cpu0: 256KB/64B 8-way write-through L2 PIPT Unified cache
[   1.000] vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, 
denormals

[   1.000] cpufreqdt0 at cpu0
[   1.000] cpu1 at cpus0
[   1.000] cpufreqdt1 at cpu1
[   1.000] gic0 at simplebus1: GIC
[   1.000] armgic0 at gic0: Generic Interrupt Controller, 160 sources 
(150 valid)

[   1.000] armgic0: 16 Priorities, 128 SPIs, 7 PPIs, 15 SGIs
[   1.000] fclock0 at simplebus2: 2500 Hz fixed clock (mii_phy_tx)
[   1.000] fclock1 at simplebus2: 12500 Hz fixed clock (gmac_int_tx)
[   1.000] fclock2 at simplebus2: 2400 Hz fixed clock (osc24M)
[   1.000] fclock3 at simplebus2: 32768 Hz fixed clock (osc32k)
[   1.000] gtmr0 at simplebus0: Generic Timer
[   1.000] gtmr0: interrupting on GIC irq 27
[   1.000] armgtmr0 at gtmr0: ARM Generic Timer (24000 kHz)
[   1.420] sun4ia10ccu0 at simplebus1: A20 CCU
[   1.420] sunxinmi0 at simplebus1: NMI
[   1.420] sunxigmacclk0 at simplebus2: GMAC MII/RGMII clock mux
[   1.420] sunxigpio0 at simplebus1: PIO
[   1.420] gpio0 at sunxigpio0: 175 pins
[   1.420] sunxigpio0: interrupting on GIC irq 60
[   1.420] sunxisramc0 at simplebus1: SRAM Controller
[   1.420] sunxidebe0 at simplebus1: Display Engine Backend 
(display-backend@1e6)
[   1.420] sunxidebe1 at simplebus1: Display Engine Backend 
(display-backend@1e4)


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