narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - official channel moved from Freenode - publicly logged on https://libera.irclog.whitequark.org/linux-amlogic
luka177 has joined #linux-amlogic
luka177 has quit [Ping timeout: 260 seconds]
GNUtoo has quit [Ping timeout: 252 seconds]
GNUtoo has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 245 seconds]
hexdump0815 has joined #linux-amlogic
djrscally has joined #linux-amlogic
naoki has joined #linux-amlogic
konsgn has quit [Ping timeout: 252 seconds]
konsgn9 has joined #linux-amlogic
knuxify has quit [Quit: The Lounge - https://thelounge.chat]
knuxify2 has joined #linux-amlogic
paulk has quit [Ping timeout: 245 seconds]
paulk has joined #linux-amlogic
paulk has joined #linux-amlogic
ldevulder has joined #linux-amlogic
ldevulder has quit [Quit: Leaving]
jacobk has quit [Ping timeout: 248 seconds]
jacobk has joined #linux-amlogic
konsgn has joined #linux-amlogic
konsgn9 has quit [Ping timeout: 276 seconds]
psydroid has joined #linux-amlogic
naoki has quit [Quit: naoki]
psydroid2 has joined #linux-amlogic
chewitt has joined #linux-amlogic
buzzmarshall has joined #linux-amlogic
konsgn8 has joined #linux-amlogic
<lvrp16> the new spicc dma patch does not send valid data on certain sizes like the old PIO code.
konsgn has quit [Ping timeout: 252 seconds]
konsgn8 is now known as konsgn
<lvrp16> some of the SPI_BURST_LEN logic does not look like it makes sense, I'll try to fix/rewrite it and try to test if I can shoehorn in DMA for small words in.
chewitt has quit [Quit: Zzz..]
vagrantc has joined #linux-amlogic
<f_> first time using b4 :P
<lvrp16> well, dma does not work on GXL. I've built a test suite for SPI and some certain speeds and bpw combinations don't work. spi is a mess.
<lvrp16> the current driver needs to be overhauled. will see if I finish it this weekend.
<lvrp16> and certain size transfers don't work either with the new dma code even though it should. 4136 bytes for example
<lvrp16> running an exhaustive test against every 8 byte transfer from 16B up to 1MB on GXL, G12B and SM1 right now, for 8 16 32 64 bpw.
psydroid has quit [Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/]
vagrantc has quit [Ping timeout: 265 seconds]
f_[x] is now known as funderscore
funderscore is now known as f_1
<f_> Ok so I'm wondering if I should upstream my tv stick u-boot patches after the DT patches..
<f_> that device is special in that regular amlogic bl2 will not work
<f_> because secureboot is enabled. So one needs to either patch bl2 to remove secureboot checks, or use the wip u-boot-spl stuff
<f_> speaking of U-Boot SPL I've been cleaning up the code lately
<lvrp16> wait, bl2 can be patched to remove secureboot?
<lvrp16> so for GXL, it's wide open?
<f_> lvrp16: you can do binary patching to remove BL2's secureboot checks once you gain unsigned code execution yeah.
<f_> either that or run u-boot-spl
<lvrp16> so there's no chain of trust from bl1 to bl2?
<lvrp16> eg, the bootrom does not verify bl2 signature?
<f_> BL1 does checks to BL2
<lvrp16> then how do you patch bl2 and still have the sig be valid?
<f_> when secureboot is enabled it checks BL2's signature. It can also decrypt BL2 if it's AES-encrypted and the efuses have been burned to allow it
<f_> lvrp16: this is where the amlogic-usbdl vuln comes in
<f_> ^ because of this, you can run unsigned code from the bootROM's USB mode
<f_> It's inconvenient to do, but allows you to do all sorts of fun stuff
<f_> like, run your own BL2 payload!
<f_> at this point the payload can be anything. So it can be u-boot-spl, just like it can be a BL2 patched to remove secureboot checks
<f_> The only way to mitigate it, is to lock USB mode behind a password.
<f_> and this affects almost all pre-2021 Amlogic SoCs, to my knowledge
<lvrp16> ahh did they ever patch bl1?
<f_> Not to my knowledge, no
<f_> My TV Stick's BL1 is identical to lepotato's BL1 which is identical to lafrite's BL1
<f_> so you can be certain all three have the vulnerability
<lvrp16> Well, that site said S905D3
<f_> yes, it was originally found on S905D3
<lvrp16> yeah so I'm wondering if they ever patches S905D3 and A311D bl1 since these chips are still active.
<f_> Good question
<f_> I could probably dump alta's ROM to compare
<f_> or, well, dump solitude's ROM too since that one has S905D3
<f_> If they patched it, could be worth documenting.
djrscally has quit [Ping timeout: 265 seconds]