mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 252 seconds]
mmarc__ has joined #linux-sunxi
jstein has joined #linux-sunxi
pcbBob has joined #linux-sunxi
netlynx_ has joined #linux-sunxi
dev1990 has quit [Remote host closed the connection]
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 252 seconds]
victhor has joined #linux-sunxi
specing_ is now known as specing
buzzmarshall has joined #linux-sunxi
apritzel has quit [Ping timeout: 268 seconds]
<mmarc__>
smaeul: I'm using Xulong orangepi-build , so the U-Boot is also theirs
jbrown has quit [Ping timeout: 260 seconds]
<mmarc__>
0x80 in all registers is a definitive indication of a GPU being powered off. But I don't know how UBoot device tree interacts with Linux device tree. Can UBoot influence Linux device-tree at all?
<mmarc__>
By default, Xulong orangepi-build loads panfrost driver, which I disabled. Should I maybe double-check that panfrost also encounters 0x80 in all GPU registers?
jbrown has joined #linux-sunxi
ats has quit [Ping timeout: 250 seconds]
atsampson has joined #linux-sunxi
tuxillo has quit [Remote host closed the connection]
hlauer has joined #linux-sunxi
shailangsa has quit [Ping timeout: 252 seconds]
marvs has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
<apritzel>
mmarc__: so this is a BSP kernel then? And the whole BSP boot chain, with boot0 and Allwinner 32-bit U-Boot and their old Trusted Firmware?
<mmarc__>
apritzel: hopefully not, Linux localhost 5.4.65-sunxi64 #2.1.0 SMP Wed Feb 3 20:59:49 CET 2021 aarch64 aarch64 aarch64 GNU/Linux
<apritzel>
mmarc__: looks like they have a mainline build option in there, which also uses mainline U-Boot
<mmarc__>
apritzel: yes, I see U-Boot v2020.04 being built
shailangsa has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
JohnDoe_71Rus has joined #linux-sunxi
apritzel has quit [Ping timeout: 252 seconds]
kaspter has quit [Quit: kaspter]
jstefanop has joined #linux-sunxi
jstefanop has quit [Remote host closed the connection]
ganbold_ has quit [Ping timeout: 245 seconds]
_0x5eb_ has quit [Ping timeout: 240 seconds]
_0x5eb_ has joined #linux-sunxi
luke-jr has quit [Read error: Connection reset by peer]
<apritzel>
when it works, it identifies the chip, then loads the firmware: Bluetooth: hci0: BCM: chip id 94 => Bluetooth: hci0: BCM: features 0x2e => Bluetooth: hci0: 4343A0
<apritzel>
one difference is WiFi, if I disable that in the DT, it works, if it's in, it doesn't
<apritzel>
and since this kernel of mine doesn't have the WiFi driver, it must be
<apritzel>
... some probe order problem, I guess
jstefanop has quit [Ping timeout: 245 seconds]
<tuxd3v>
apritzel, many thanks..
<tuxd3v>
that is hunting me down for 2 weeks now :D
<tuxd3v>
I never tried disabling the WIFI in the DT..
<tuxd3v>
if disabling it, bluetooth works?
<apritzel>
yes
<apritzel>
(for me, at least)
<tuxd3v>
I believe in a probe order too
<apritzel>
but then you have no network in your case, right?
<apritzel>
(I still have Ethernet)
<tuxd3v>
right :)
<tuxd3v>
you still lucky
<tuxd3v>
with WIFI disabled in the DT does linux find the mmc sdio WIFI device?
<apritzel>
well, it's a hack/experiment anyway, not a solution
<apritzel>
no, of course not
<apritzel>
I actually set status = "disabled" in the mmc1 node, and removed the whole WiFi node
<tuxd3v>
nice test ;)
<apritzel>
(to check if BT would depend on any resources described there)
<apritzel>
which it apparently doesn't, because it still works
<apritzel>
I am looking at EPROBE_DEFER now
<apritzel>
most of the resources look correct, but one interrupt might slip through, checking that now
<apritzel>
and of course with my kernel with debug messages I cannot get it to work again
<apritzel>
so what I see in the failing case looks correct, but it would be good to compare to a working case