<smaeul>
bauen1: the earlier SPC is a BP147, which has groups of 3 registers, so each "SET" register is 0xc above the last. the new one has groups of 4 registers
<smaeul>
apritzel: I'm surprised that RVBAR appears to be ignored in AArch32. I will do some playing around in crust (that is, from the outside) to verify that
<smaeul>
there's also the option of bringing up a second CPU to run your aarch64 code, then killing it and returning to FEL on CPU0
ChriChri_ has joined #linux-sunxi
<smaeul>
the hotplug and super standby flags are documented in those flowcharts at the beginning of the manual that you always scroll past :)
jstein_ has joined #linux-sunxi
jstein is now known as Guest84970
Guest84970 has quit [Quit: quit]
<smaeul>
apritzel: even if they are backed by SRAM, there is definitely extra logic in the standby/hotplug/related registers. the standby flag requires 2(!) consecutive keys in the high word to write the low word
ChriChri has quit [Ping timeout: 265 seconds]
ChriChri_ is now known as ChriChri
Mangy_Dog has quit [Ping timeout: 272 seconds]
jstein_ has quit [Quit: quit]
<apritzel>
smaeul: yeah, (ab)using a second core was something I also thought about
<apritzel>
but tbh I was hoping for some solution that's not too crazy
KotCzarny has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<apritzel>
smaeul: btw: my understanding is that RVBAR is really different from MVBAR
<apritzel>
according to the A53 TRM the content of RVBAR is sampled at processor reset from some signals (RVBARADDRx[39:2]), which AW chose to back by this CPUCFG MMIO register
apritzel has quit [Ping timeout: 260 seconds]
victhor has quit [Ping timeout: 246 seconds]
gaston1980 has quit [Quit: Konversation terminated!]
gnarface has quit [Remote host closed the connection]
lurchi__ has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
gnarface has joined #linux-sunxi
niceplace has quit [Ping timeout: 264 seconds]
hanni76 has joined #linux-sunxi
tuxillo has quit [Ping timeout: 256 seconds]
tuxillo has joined #linux-sunxi
<smaeul>
bauen1: yes, I've booted a TOC0 with a 39KiB payload. SRAM C immediately follows SRAM A1 and is configured by the SBROM. SBROM moves its stack to the end of SRAM A2 in the middle of processing
tuxillo has quit [Remote host closed the connection]
tuxillo has joined #linux-sunxi
tuxillo has quit [Remote host closed the connection]
tuxillo has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
tuxillo has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
Net147_ is now known as Net147
apritzel has joined #linux-sunxi
<bauen1>
smaeul: actually it moves the stack after deciding it should follow the "normal" boot sequence (i.e. before calling "main")
<bauen1>
wait, the toc0 size is limited to 64Kb
<bauen1>
so overwriting the stack shouldn't be possible
apritzel has quit [Ping timeout: 264 seconds]
<bauen1>
no it isn't 4 bytes -> 4GB
<bauen1>
i should read a bit more carefully before jumping to conclusions
AneoX has joined #linux-sunxi
<bauen1>
i think it might be time to burn my h64s secure boot fuse
lucascastro has quit [Ping timeout: 260 seconds]
<smaeul>
bauen1: I just tried 3072 bit RSA key and it dies with 0x8904000b (failure to check the key item against the ROTPK)
<smaeul>
unfortunately, I was expecting that, because the RSA decryption function hardcodes a 2048 bit RSA operation length when constructing the CE task
<smaeul>
it sets "asymmetric control" to 0x40 at 0x2490
<smaeul>
and I don't think there's a "switch to software RSA" chicken bit in BROM_CONFIG
<bauen1>
smaeul: there is no bit in the BROM_CONFIG that influences the RSA decryption function
<bauen1>
in fact only BROM_CONFIG, VENDORID, ROTPK_HASH are used by the sbrom
<bauen1>
in any case the sbrom forces the length of the key to be below < 0x201 and all buffers are >= that so there's no issues in part#
<bauen1>
smaeul: if you want to try, a toc0 of size ~152KiB, that just has a valid name, magic and length might be able to put the H6 into a reset loop
<smaeul>
bauen1: right, I think that's the *only* part of the BROM that would not work with 3072 bit keys (for either key)
<smaeul>
specifically, all of the buffers for key material are at least 384+32 bytes long (the 32 for alignment)
<bauen1>
yeah
<bauen1>
it's like the idea to support 3072 bit keys was there but it was never tested
<smaeul>
do you have a specific size you want me to try? Note that TOC0 size must be aligned to 512 bytes
<bauen1>
smaeul: from where do you have the 0x8904000b value
<bauen1>
smaeul: not really, just bigger equal than SRAM A1 + SRAM C
<smaeul>
bauen1: 0x30000d0, the SRAM switch / error log register
<smaeul>
s/SRAM/BROM/
<bauen1>
i need to get my monitor working with linux again if i want to do test since my macbook air only has 2 usb ports with one taken by ethernet
hanni76 has quit [Quit: Leaving]
<smaeul>
FEL only needs one USB port...
<bauen1>
right, but uart is easy to use
<smaeul>
hmm, yeah, on Linux I use FEL USB device appeared => failure; no FEL device => success
<smaeul>
if I don't want to bother looking at UART output
<smaeul>
bauen1: I will prepare a table of H6 SBROM error codes
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
<smaeul>
though now that (I think) I have the ASN.1/BER generated correctly, things should Just Work
cmeerw has quit [Ping timeout: 260 seconds]
ganbold has quit [Read error: Connection reset by peer]
ganbold has joined #linux-sunxi
bauen1 has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
victhor has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
tuxillo has joined #linux-sunxi
bauen1 has joined #linux-sunxi
lucascastro has quit [Ping timeout: 240 seconds]
<bauen1>
the h6 dtsi in the linux kernel also has `cpu_speed_grade: cpu-speed-grade@1c { reg = <0x1c 0x4>; };`
<bauen1>
introduced by commit 905434e0b544ee220bcce6da16a6857c0274b8ba says that is related with dynamic voltage and frequency scaling
lucascastro has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
qschulz has quit [Remote host closed the connection]