<wb9688>
And does e.g. the A64 just use Mesa and DRM and GBM and stuff so that you could just use a Wayland compositor with hardware acceleration?
<juri_>
I don't have an A64, so *shrugs*.
<juri_>
I'm also still using XOrg.
<wb9688>
Well, A20, A23, A33, H3, and R40 use the same Mali GPU
<juri_>
right, so i can confirm XOrg works, but i can't tell you much about the 3D side from personal experience.
<wb9688>
Oh, OK. What hardware are you using (just out of curiosity)?
<juri_>
A20 boards, H3 boards, and a pile of H2+ boards.
<wb9688>
Ah, what boards?
<juri_>
I've experienced no defects on the A20 boards, the H3 had graphical trouble with one of my displays (tl;dr: problems with 2560x1440 having artifacts), and the H2 boards have no display.
sunshavi has quit [Remote host closed the connection]
<juri_>
Bannana Pi, Bannana Pi Pro, CubieBoard, Orange Pi...
<juri_>
whatever i could snipe on ebay with the chip i wanted for the cheapest cost.
sunshavi has joined #linux-sunxi
dlan has joined #linux-sunxi
<linkmauve>
wb9688, I have an A64 in my phone, DRM and Mesa stuff work fine on mainline.
<wb9688>
Oh, cool
<linkmauve>
I also have a bunch of A20, which have an issue with Lima making some geometry jump around.
<linkmauve>
Someone told me it might be caused by an errata, but I don’t have access to them…
<wb9688>
I recognize your name :P
<linkmauve>
Where from? ^^
<wb9688>
Good question
<wb9688>
Oh, you're in #wayland, #sway-devel and #sway as well
<linkmauve>
Multiple boards of mine have the same jumpy issue, both A20 and A10 actually.
<linkmauve>
And some A20 will shutdown whenever I start using the GPU.
<linkmauve>
You’re also from #pipewire and ##xdc2020. :)
<wb9688>
I'm not in those channels anymore
<wb9688>
And haven't been very active there
<wb9688>
I don't even use Sway anymore though :P
<wb9688>
linkmauve: What compositor are you using on your phone?
<linkmauve>
Phoc atm.
<linkmauve>
It’s based on wlroots.
asdf28 has quit [Ping timeout: 264 seconds]
<linkmauve>
Doesn’t support scanout though, which is a big issue for efficiency. :/
<wb9688>
Ah, yeah, especially as you mostly use fullscreen apps on phones
<linkmauve>
Anyway, I’m out, see you later! \o_
asdf28 has joined #linux-sunxi
asdf28 has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
asdf28 has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
asdf28 has quit [Ping timeout: 246 seconds]
asdf28 has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
Putti has joined #linux-sunxi
jstein has joined #linux-sunxi
sunshavi has quit [Ping timeout: 246 seconds]
iamfrankenstein has joined #linux-sunxi
<jernej>
apritzel: out of desperation due to non-working HDMI, I booted OPi 02 with modified BSP boot0
<jernej>
guess what, HDMI now works
<jernej>
to be clear, everything is from mainline, except boot0
<jernej>
so, we are missing something very fundamental
<jernej>
and explains why going over the U-Boot and Linux BSP sources yielded nothing
<jernej>
apritzel: command "mw.l 0x07010250 0x10" solves the issue
<jernej>
but I have no idea what it does
<apritzel>
that's in PRCM, right?
<apritzel>
jernej: did you learn about this by comparing PRCM dumps between boot0 and SPL?
<jernej>
actually, I noticed one routine which set up clocks in boot0 during DRAM driver RE
<jernej>
at that time it didn't make any difference, but now it does :)
<smaeul>
what's the value of the register at reset?
<jernej>
there are other things in it, like enabling all enable bits in PLL (bit 31), so clock driver only drives output enable bit
<jernej>
smaeul: 0
warpme_ has quit [Quit: Connection closed for inactivity]
<jernej>
actually, using output enable instead of enable bit for PLL is also recommended by manual
<smaeul>
huh. that register is VDD_SYS_PWROFF_GATING_REG, so I would expect any set bits to turn things *off*, not on. but they must have put some other random bit in there
<jernej>
since there is no boot0 source, I'm not sure we'll get much info on that
<jernej>
anyway, should we done the same, enable it in SPL clock setup and be done with it?
<smaeul>
yes. that register is secure-only, so you can't set it in the PRCM CCU driver
<jernej>
we don't really know what it does, so imo safest way is to mimick BSP and have it set all the time
<jernej>
ok, I'll send a patch
<smaeul>
speaking of secure-only, H616 NBROM has some major changes, including 1) verification of a new kind of signature appended to eGON images, 2) a way to check the ROTPK hash from the SID in non-secure state, and 3) the ability to disable FEL with an eFuse bit
<smaeul>
oh, and 4) it also wipes the entire SRAM when entering NBROM, which means no more SMC hack
<jernej>
so, in theory, more secure than predecessors?
<smaeul>
in theory. still vulnerable to stack smashing
<KotCzarny>
and more brickable
<smaeul>
yes, that too. I don't plan to even document how to disable FEL until I get a full SBROM dump and can reliably make images it accepts
apritzel has quit [Ping timeout: 240 seconds]
<smaeul>
I have an H616 that is burned to secure, but right now I only have NBROM because the stack smashing attack only works after it switches BROMs
<bauen1>
hm sounds interesting
<bauen1>
smaeul: so stack smashing using an evil toc0 image doesn't work and it just goes to FEL ?
<smaeul>
bauen1: it's hard to say exactly what happens without the SBROM code, but it appears that the stack smashing works when it tries to enter FEL
<bauen1>
smaeul: i'm still confused, so if you supply an extremly long toc0 image (which one btw) what happens ?
iamfrankenstein has quit [Quit: iamfrankenstein]
<bauen1>
and from all this i assume that you don't yet have an image that is actually accepted ?
<bauen1>
and the rtc trick (cpu 0 hotplug) didn't work either ?
<smaeul>
CONFIG_SPL_TEXT_BASE=0x20840 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1c0, pad u-boot-spl.bin to (0x38000-0x20840) with 0x20840, then mkimage
<smaeul>
so my final TOC0 is exactly the size of SRAM. larger images are rejected
<smaeul>
bauen1: RTC trick would not work because entire SRAM is zeroed when entering BROM
<bauen1>
smaeul: you can put enough code into the rtc "general purpose" to do some magic probably
<bauen1>
though knowing how the sbrom looks makes it easier ...
sunshavi has joined #linux-sunxi
<smaeul>
yeah, I could exfiltrate SBROM 16 bytes at a time :P
<bauen1>
something like `./sunxi-fel writel 0x07022000 0x17777777 writel 0x07022010 0x80 # set link led on`
<bauen1>
smaeul: you could also use the led (or other gpio) to transmit data
<smaeul>
also the hotplug registers are moved back to R_CPUCFG, and there's now a separate entry address for each core
<bauen1>
smaeul: or maybe try to switch to the nbrom and jump to $0x0
<bauen1>
well that might make this also not work then
<smaeul>
bauen1: I don't know where the BROM switch is. that's the problem.
<smaeul>
so using hotplug to dump SBROM via GPIO and reading it with a logic analyzer may be the easiest solution
<bauen1>
smaeul: but does the hotplug trick still work (and you have ~0x20 bytes of storage to work with ?) ?
<smaeul>
I have not tried it, but it should work for the RTC (or any other bits of sram outside 0x20000-0x58000)
<bauen1>
smaeul: is the sram cleared by sbrom or nbrom and if it wasn't would that help ?
<bauen1>
oh and worst case you could also try to do a power fault injection attack to bypass toc0 verification, might need an fpga
asdf28 has quit [Ping timeout: 264 seconds]
<smaeul>
bauen1: it is cleared by NBROM first thing in the FEL entry path. I assume SBROM probably clears it first thing as well, but I haven't checked
<bauen1>
smaeul: maybe try to see if the "nbrom jump code" is copied to the same address as the h6, or use the rtc to find the address of something that looks like it then dump it
<bauen1>
oh wait no sram is cleared
<bauen1>
so they've actually done things mostly right this time
<bauen1>
i suppose you could still try to do that by resetting the h616 at just the right time before the sram is cleared, but that's annoying to do
gaston1980 has quit [Quit: Konversation terminated!]
giomba has joined #linux-sunxi
<bauen1>
smaeul: and keep in mind that at the time the rtc hotplug is (presumably) checked sram was still disabled on the h6 and required setting some magic bits to enable
<bauen1>
so loading some code into sram is a bit more difficult
<bauen1>
smaeul: stack smashing can be prevented by clever signing, so that would could make the h616 "secure" against "conventional" attacks
<bauen1>
now i kind of want one ...
<bauen1>
smaeul: and i haven't tried this, but if you're willing to sacrifice a few sid bytes you could use it to get some more code and call it from rtc, that could allow you the space to implement uart
<bauen1>
at the cost of potentially bricking the board forever if you're not careful
<smaeul>
that's why I made the 512MB board secure, not the 1GB board :)
<bauen1>
smaeul: another idea, if the sbrom is anything like the h6, find the first non-0 word from the end and then start dumping there, with a bit of luck it's the fel enter code