<gameblabla>
Btw, was able to make SDL 1.2 work and change the scaling mode. Seems like the kms magic needs to be done within the library itself
<gameblabla>
Although now i wonder if it's able to upscale 8bpp via the Display Engine ? I know that 16bpp isn't supporting for upscaling and indeed, 16bpp isn't mentionned in the A20 doc
<gameblabla>
*supported
<gameblabla>
I had to make SDL 1.2 force to a software surface for 16bpp.
gameblabla has quit [Remote host closed the connection]
gameblabla has joined #linux-sunxi
<gameblabla>
Yup, 8bpp doesn't work
<gameblabla>
So only 32bpp it seems for Display engine
rah_ has joined #linux-sunxi
tuxillo has joined #linux-sunxi
sunshavi has quit [Ping timeout: 264 seconds]
gameblabla has quit [Ping timeout: 246 seconds]
cnxsoft1 has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 256 seconds]
cnxsoft has quit [Ping timeout: 246 seconds]
rah_ has left #linux-sunxi [#linux-sunxi]
netlynx has quit [Quit: Ex-Chat]
gameblabla has joined #linux-sunxi
apritzel has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein is now known as Guest64420
jstein_ is now known as jstein
lucascastro has joined #linux-sunxi
lucascastro has quit [Read error: Connection reset by peer]
Guest64420 has quit [Ping timeout: 264 seconds]
jstein has quit [Quit: quit]
sunshavi has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
asdf28 has joined #linux-sunxi
Net147 has quit [Quit: Quit]
lurchi_ is now known as lurchi__
vagrantc has quit [Ping timeout: 264 seconds]
Net147 has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 240 seconds]
ChriChri_ is now known as ChriChri
JohnDoe_71Rus has joined #linux-sunxi
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
<smaeul>
bauen1: All I know is the SPC register layout (confirmed against the BSP once I knew what to look for), not the meaning of individual bits
<smaeul>
bauen1: the "crypto" registers in the RTC are for DRAM scrambling, which I was able to get working on the A64
<smaeul>
apritzel: yes, they survive a watchdog reset
<smaeul>
the values also survive a power-on reset from the PMIC (since VCC-RTC is maintained), but the registers are ignored at that point
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
asdf28 has quit [Ping timeout: 264 seconds]
random_yanek has quit [Ping timeout: 258 seconds]
random_yanek has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
kevans91 has quit [Ping timeout: 246 seconds]
daregap has joined #linux-sunxi
kevans91 has joined #linux-sunxi
gameblabla has quit [Remote host closed the connection]
<wens>
Tooniis: the gpu itself is render only, i.e. it renders back to memory
<wens>
check under /dev/dri/by-path and you can see what you have active
<Tooniis>
wens: yes it's there
<Tooniis>
but how do I make use of it?
<Tooniis>
what's responsible for copying the data it outputs to the framebuffer?
<Tooniis>
as far as I understand the display engine is responsible for that
<Tooniis>
or does the display engine just take the data in the framebuffer and send it to the display?
<wens>
the latter
apritzel has quit [Ping timeout: 272 seconds]
<Ashleee>
smaeul, bad news, the timer fix on a64 on mainline doesn't work, had +95 years again this morning on one of the nodes :(
<bauen1>
smaeul: nice, do you have some example code of getting DRAM scrambling on the a64 or some general idea of what it does (just xor, or maybe something more complicated ?)
<smaeul>
bauen1: it's address-dependent, so it breaks DRAM size detection if enabled at that point. the easist way to play with it is from the crust "shell"
<smaeul>
patch crust to also call debug_monitor(); in the SS_AWAKE case, and then put Linux in s2idle (*not* mem sleep)
<smaeul>
> m 0x1f00210 0x1689 > m 0x1f00214 0x12345678 > m 0x1f00210 0x1689 > m 0x1f00218 1
<smaeul>
0x1689 is the SoC ID for A64, but the code from the H6 BSP (that does this on H6) uses the same value. I've only tested on A64
<bauen1>
thanks, i'll take a look then when i get to the point of having crust working
<smaeul>
0x1f00218 is enable/disable, so write it back before resuming Linux: > m 0x1f00210 0x1689 > m 0x1f00218 1
<smaeul>
I mean > m 0x1f00210 0x1689 > m 0x1f00218 0
<smaeul>
obviously anything touching these registers has to run from SRAM. TF-A has console_getc() but nothing uses it; crust has the interactive part already :)
<smaeul>
benchmarks with ramspeed-smp showed no difference with scrambling on/off
<bauen1>
so with scrambling it just mixes where the values are actually stored, so that they're no longer stored in a linear order ?
_whitelogger has joined #linux-sunxi
apritzel has joined #linux-sunxi
<bauen1>
apritzel: the 32kb limit is artificial and created by my code in the rtc that "patches" the sbrom to make it actually secure, in theory the h6 can boot a toc0 image up to around 128kb
<bauen1>
but i only have 1 instruction to ensure the size doesn't exceed 128kb, and just storing zeros in the upper two bytes is simple enough
<bauen1>
actually that means i have 64kb *facepalm*
<bauen1>
smaeul: by the way, did you try using mkimage to put the spl directly into the toc0 image ?
<BroderTuck>
Hey, did everything in the "Planned for 5.10" section of "Linux Mainlining effort" land in 5.10?
<jernej>
BroderTuck: only exception I can think of is that one R40 Cedrus patch was missed for 5.10 so it was postponed to 5.11
<bauen1>
smaeul: so far i've used pine_h64_defconfig, adjusted SPL_TEXT_START = 0x20840 and then used mkimage with '-a 0x20840', which should result in not copying the spl around at all
<bauen1>
the spl is loaded and activates uart before going into a loop of printing its version
apritzel has joined #linux-sunxi
<bauen1>
oh, looks like it was trying to boot some left over spl
fl_0 has quit [Quit: STRG + Q]
kaspter has joined #linux-sunxi
fl_0 has joined #linux-sunxi
<smaeul>
bauen1: I use what I pushed, so CONFIG_SPL_TEXT_BASE (== 0x20060). the memmove() is unconditional, I don't know if there's an optimization to skip copying when src == dst
<smaeul>
not sure what you mean by "directly into the toc0 image"
<smaeul>
btw that's why the ruby script has its own shim, so it can copy the boot source byte to where SPL expects it
<bauen1>
there is no optimization, but i would like to avoid having "two" copies of the bootloader in memory, especially if i later need to abuse those header fields to make sure the header is signed
<bauen1>
yes, i just mean without that shim, but everything works fine now
<bauen1>
still even with 64kb i'm having trouble fitting the spl, since the fit_signature features requires massive amounts of code, just for a simple rsa implementation
<smaeul>
yeah, there's a lot of junk in there you don't need. you could probably plug in a CE driver instead of the software implementation
<bauen1>
there's a few other concerning things too, i don't really want to have anything up to a firmware tpm implementation touch dram at all, but that might not be possible without some heavy patches ; and the sbrom still lacks rollback pervention
<bauen1>
i think rollbacks could be prevented by having a tiny shim at the start of any signed boot code that does the rollback counter check
<smaeul>
there's *supposed* to be hardware rollback prevention, if we can figure out how to make it work
<smaeul>
so you mean putting the next-stage counter in the code itself?
<bauen1>
smaeul: i would have to double check the sbrom dump, but i don't think the sbrom actually implements the rollback counter
<smaeul>
bauen1: you could implement the rollback counter using the vendor ID
<bauen1>
the "documented" rollback counter registers of the trusted watchdog are also not persistent, so that is annoying
<bauen1>
smaeul: my idea would be to start the bootloader with a tiny shim that loads the current rollback counter (e.g. from sid or rtc) and then compares it to its own, update the rollback counter if necessary or prevent boot
<smaeul>
set one bit for each update and publish a key item with a new public key
<bauen1>
oh right
<bauen1>
but doesn't the sbrom do a == check on the vendor id ?
<bauen1>
so you would need to first boot with a new image signed by the old key
apritzel has quit [Ping timeout: 258 seconds]
<smaeul>
or an old image signed by the old key
<smaeul>
as long as you update the SPL and program the SID bit before the same reboot
<bauen1>
right, not as smooth as possible, but doable
<bauen1>
you could even put the old image at the backup spl location for automatic fallback i think
<smaeul>
you wanted rollback prevention, but you got rollforward prevention for free :)
<smaeul>
yes, and AFAIK the backup SPL location is the only way to do eGON/TOC0 universal images as well
cmeerw has joined #linux-sunxi
<smaeul>
it's a bit unfortunate that you can't put multiple certificates/binaries in a single TOC0
<bauen1>
if you smash the stack you can do just about anything you want
<smaeul>
:P
<bauen1>
but yes, using vendorid is good enough, and leaves more bytes for the secure state encryption key and rollback counter
vagrantc has quit [Quit: leaving]
<smaeul>
firmware TPM sounds very tricky. the only secure SRAM is A2, and it is already crowded in there
yann has joined #linux-sunxi
yann has quit [Ping timeout: 260 seconds]
<bauen1>
yes, ideally i would use all available sram as secure, including the spi flash as secure peripheral, but even then things are tight
dev1990 has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #linux-sunxi
lucascastro has joined #linux-sunxi
daregap has quit [Quit: daregap]
kaspter has quit [Quit: kaspter]
Mangy_Dog has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
vpeter has quit [Remote host closed the connection]
<bauen1>
actually, probably quite hard, there's only 32k + 80k sram, part of which will be used up by the trusted-firmware-a, so very tight, even if you swap+encrypt pages to dram when possible
vpeter has joined #linux-sunxi
<bauen1>
i'll just worry about that when i run out of memory to put things
apritzel has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
<apritzel>
bauen1: I see, thanks. I thought that this limit was somewhat artificial, just wanted to point out that the SPL can go beyond 32KB (we need this for the H616 already)
<apritzel>
bauen1: and on the H6 the BROM does even boot larger SPLs (up to 139KB) with an eGON header (w/o the secure fuse burnt)
apritzel has quit [Ping timeout: 246 seconds]
apritzel has joined #linux-sunxi
damex has quit [Ping timeout: 240 seconds]
gameblabla has quit [Ping timeout: 264 seconds]
yann has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
yann has quit [Ping timeout: 264 seconds]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 265 seconds]
iamfrankenstein has quit [Ping timeout: 246 seconds]
lurchi__ is now known as lurchi_
lkcl has quit [Ping timeout: 260 seconds]
lurchi__ has joined #linux-sunxi
lurchi__ has quit [Read error: Connection reset by peer]
lurchi_ has quit [Ping timeout: 240 seconds]
lurchi__ has joined #linux-sunxi
lurchi__ has quit [Read error: Connection reset by peer]