FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20201210-7578a4862f0 broken ?

[Søren Schmidt]

> On 31 Dec 2020, at 14.18, Emmanuel Vadot <manu at bidouilliste.com <mailto:manu at bidouilliste.com>> wrote:
> 
> On Thu, 31 Dec 2020 13:49:19 +0100
> Søren Schmidt <soren.schmidt at gmail.com <mailto:soren.schmidt at gmail.com>> wrote:
> 
>> Hi gang
>> 
>> On my quest on getting the pinebookpro booting again I think I can rule out u-boot for now.
> 
> I thought it was rockpro64 that gave you problems ?

Those where solved with the latest 2021.01rc4 u-boot.

I should have changed the subject, or rather I thought I did, got interrupted 4 times during that mail by wife :)

> 
>> Back on the u-boot-2020.07 where a -current kernel from late July/early august would boot just fine a current kernel fails to talk to the SD card, the only change to an up to date current is not setting the 800Hmz cpll clock and that is known not to make any difference.
> 
> How is it known that it doesn't make any difference ?

There is no difference in behaviour, it fails exactly the same way.

> cpll is one of the possible parent (and likely the default one) for
> sd/emmc/sdio clocks.

Doesn’t seem to affect anything but the clock for the display from my poking around so far..

> Did you tested without this change ?

Yes, plain -current with no changes as said above fails exactly the same.

> 
>> Again the same SDcard works just dandy with net/openBSD also I 50Mhz mode. 1 in 10 boots finds the card as 25Mhz and then it ?just works?.
>> 
>> Any Ideas ?
> 
> Cna you provide a boot verbose log please ?

Sure, rather long though so I’ve uploaded the bits on 
https://people.freebsd.org/~sos/PinebookPro <https://people.freebsd.org/~sos/PinebookPro>

Including the odd drivers I’ve done / updated that’s included in the working boots..

What have me intrigued is this in the early boot stage:

--- verbose-success     2021-01-01 12:59:24.624917000 +0000
+++ verbose-fail        2021-01-01 13:03:21.444189000 +0000
@@ -831,7 +824,7 @@
 gic0: CPU0 Re-Distributor woke up
 gic0: CPU0 enabled CPU interface via system registers
 its0: <ARM GIC Interrupt Translation Service> mem 0xfee20000-0xfee3ffff on gic0
-rk_iodomain0: <RockChip IO Voltage Domain> mem 0-0xff31ffff,0-0xfff on rk_grf0
+rk_iodomain0: <RockChip IO Voltage Domain> mem 0xff320000-0xff320fff on rk_grf0
 rk_iodomain1: <RockChip IO Voltage Domain> mem 0-0xff76ffff,0-0xffff on rk_grf1
 rk_pinctrl0: <RockChip Pinctrl controller> on ofwbus0
 gpio0: <RockChip GPIO Bank controller> mem 0xff720000-0xff7200ff irq 71 on rk_pinctrl0

And a litte later that interrupts are offset by 1 from here on:

@@ -1017,7 +1004,7 @@
 nvme0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0xfa000000
 ofw_pci mapdev: start fa000000, len 16384
 nvme0: attempting to allocate 5 MSI-X vectors (16 supported)
-nvme0: using IRQs 77-81 for MSI-X
+nvme0: using IRQs 78-82 for MSI-X
 nvme0: CapLo: 0x780100ff: MQES 255, CQR, TO 120
 nvme0: CapHi: 0x00100030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 1
 nvme0: Version: 0x00010300: 1.3


--
Søren Schmidt
sos at deepcore.dk <mailto:sos at deepcore.dk> / sos at freebsd.org <mailto:sos at freebsd.org>
"So much code to hack, so little time”