Re: RPi4b 8GB 13.0-Current, XHCI broken, wrong U-Boot ?

> Am 03.01.2021 um 14:29 schrieb Emmanuel Vadot <[email protected]>:
> 
>> ….
> 
> Ok, one thing at a time please.

O.K, one thing at a time while I’m sorry in advance , that this will be a lot ;-)
> 
> And again please provide an overlay for this with an explanation of
> what and why things are needed.
Well, as commented in https://reviews.freebsd.org/D26853#598685
the reset-function  is triggered in line 2363 bcm2711-rpi-4-b.dts while has places in line 1965 
and 1422 . So what I assume is that the function has to be triggered at a special moment,
That’s why I DIDN`T consider to create an overlay, since bcm2711-rpi-4-b.dtb comes UNCHANGED from upstream(afaik),
And is NOT compiled by ourselves(what I don’t like)( I do not know everything you do in new releases or elsewhere and I haven’t access to the filesystem).
This doesn’t necessarily mean that we shouldn’t  want to provide an overlay but it makes things much much more complicated, e.g. :
sys/dts/arm64/overlays/spigen-rpi4.dtso / sys/modules/dtb/rpi/Makefile 
I do not see an spigen-rpi4.dtbo loaded by the firmware although it is available in  : dtb/overlays on the msdos partition .
Output of firmware-load(which shows that bcm2711-rpi-4-b.dtb is loaded FIRST and misses spigen-rpi4..)  :
—
Read start4.elf bytes  2213312 hnd 0x00000896 hash '19bbfbc3ec1da69d'
Read fixup4.dat bytes     5428 hnd 0x00000019 hash '5481e23d9a139ecb'
0x00d03114 0x00000000 0x0000003f
MEM GPU: 76 ARM: 947 TOTAL: 1023
Starting start4.elf @ 0xfeb00200 partition 0

MESS:00:00:05.341884:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:05.344650:0: brfs: File read: 187 bytes
MESS:00:00:05.412783:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:05.431333:0: brfs: File read: 187 bytes
MESS:00:00:05.893817:0: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
MESS:00:00:05.901072:0: *** Restart logging
MESS:00:00:05.906275:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:05.915565:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:05.921499:0: HDMI0: hdmi_pixel_encoding: 300000000
MESS:00:00:05.926967:0: HDMI1: hdmi_pixel_encoding: 300000000
MESS:00:00:05.937190:0: dtb_file 'bcm2711-rpi-4-b.dtb'
MESS:00:00:05.942006:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
MESS:00:00:05.945296:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x4000 size 0xbab8
MESS:00:00:05.964151:0: brfs: File read: 47800 bytes
MESS:00:00:06.021379:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:06.023868:0: dtparam: audio=on
MESS:00:00:06.036453:0: dtparam: i2c_arm=on
MESS:00:00:06.045531:0: dtparam: spi=on
MESS:00:00:06.053747:0: brfs: File read: 187 bytes
MESS:00:00:06.055998:0: brfs: File read: /mfs/sd/overlays/mmc.dtbo
MESS:00:00:06.073055:0: Loaded overlay 'mmc'
MESS:00:00:06.102564:0: brfs: File read: 1221 bytes
MESS:00:00:06.104918:0: brfs: File read: /mfs/sd/overlays/disable-bt.dtbo
MESS:00:00:06.124664:0: Loaded overlay 'disable-bt'
MESS:00:00:06.162765:0: brfs: File read: 1073 bytes
MESS:00:00:06.164881:0: Failed to open command line file 'cmdline.txt'
MESS:00:00:07.205210:0: brfs: File read: /mfs/sd/armstub8-gic.bin
MESS:00:00:07.208193:0: Loading 'armstub8-gic.bin' to 0x0 size 0x1700
MESS:00:00:07.214371:0: brfs: File read: 5888 bytes
MESS:00:00:07.242883:0: brfs: File read: /mfs/sd/u-boot.bin
MESS:00:00:07.245355:0: Loading 'u-boot.bin' to 0x80000 size 0x8c708
MESS:00:00:07.251440:0: Device tree loaded to 0x4000 (size 0xbf2c)
MESS:00:00:07.260578:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:07.266906:0: uart: Baud rate change done...
MESS:00:00:07.268962:0: uart: Baud rate change done...
MESS:00:00:07.274289:0: bfs_xhci_stop
MESS:00:00:07.277204:0: XHCI-STOP
MESS:00:00:07.280402:0: xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
MESS:00:00:07.288600:0: PCI reset

U-Boot 2020.10-rc5 (Oct 05 2020 - 03:08:23 +0000)
——

We see here that the xhci-reset is the last thing loaded before u-boot.
So., O.K., if we could ensure that an overlay with a pure reset-function could be loaded after everything else 
we could perhaps go this way.
But I ask myself : why?
bcm2711-rpi-4-b.dts in https://reviews.freebsd.org/D26853 is a decompilation from a professional distribution 
which is proved to be working , even proved by Andy McClements to boot vanilla or whatever from USB.
And: the original xhci-reset-patch is from a u-boot programmer ( Nicolas Saenz of Suse linux, while this is not a decompilation from Suse)-
I asked myself why it didn’t make it upstream but manu@ himself found the answer :-)

> Am 03.01.2021 um 14:29 schrieb Emmanuel Vadot <[email protected]>:
> remember that RPI doesn't care about u-boot
> so they might don't care about this problem.


So, from my view(while not important:-) : why should I care about an upstream which doesn’t care about me ???

> Am 03.01.2021 um 14:29 schrieb Emmanuel Vadot <[email protected]>:
> We will not replace a dts in sys/gnu/ with some other one coming from
> a different upstream.
I know. And my intention of course wasn’t to overwrite any directory which is probably even not in use by fbsd.
My intention is to replace the current bcm2711-rpi-4-b.dtb in the msdos - partition with a proved working one which 
contains things we need, created by people who know what they’re doing and who care about u-boot( because they ARE contributors to u-boot).

The original patch by Nicolas Saenz is intended to live in bcm2711-rpi-4-b.dtb ,
 While , O.K.: we could „play around“ a little with overlays the next days…

Regards

K.




_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"