Date: Fri, 1 Jan 2021 14:26:48 +0100 From: =?utf-8?Q?S=C3=B8ren_Schmidt?= <soren.schmidt@gmail.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20201210-7578a4862f0 broken ? Message-ID: <CCF47E00-8CD3-41E2-8B42-3A78F4D736DD@gmail.com> In-Reply-To: <20201231141821.274a45ffa0299cca5a7bb1f1@bidouilliste.com> References: <a9fca4d433dadbe2d1ca490bff3b189a@pyret.net> <4434862ed87c21113fb7f98636fe4694d73856ce.camel@freebsd.org> <0D6FCA87-F101-4AA0-A1BF-6EDBA003BC9F@gmail.com> <87B7940E-119D-4C7F-AB9D-0C78E7F8D3A3@gmail.com> <20201213180746.1224166dffb81cb6770ff80d@bidouilliste.com> <6784D541-8FED-4753-8631-B36886508165@gmail.com> <23CCE944-C9F0-42C9-8A93-DAC312FE01E2@gmail.com> <E8135EC2-8387-4377-A03C-772FC511F68C@gmail.com> <20201231141821.274a45ffa0299cca5a7bb1f1@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 31 Dec 2020, at 14.18, Emmanuel Vadot <manu@bidouilliste.com = <mailto:manu@bidouilliste.com>> wrote: >=20 > On Thu, 31 Dec 2020 13:49:19 +0100 > S=C3=B8ren Schmidt <soren.schmidt@gmail.com = <mailto:soren.schmidt@gmail.com>> wrote: >=20 >> Hi gang >>=20 >> On my quest on getting the pinebookpro booting again I think I can = rule out u-boot for now. >=20 > 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 :) >=20 >> 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. >=20 > 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=E2=80=99t 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. >=20 >> 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?. >>=20 >> Any Ideas ? >=20 > Cna you provide a boot verbose log please ? Sure, rather long though so I=E2=80=99ve uploaded the bits on=20 https://people.freebsd.org/~sos/PinebookPro = <https://people.freebsd.org/~sos/PinebookPro>; Including the odd drivers I=E2=80=99ve done / updated that=E2=80=99s = 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=C3=B8ren Schmidt sos@deepcore.dk <mailto:sos@deepcore.dk> / sos@freebsd.org = <mailto:sos@freebsd.org> "So much code to hack, so little time=E2=80=9D
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CCF47E00-8CD3-41E2-8B42-3A78F4D736DD>