<megi>
ah, figured out the offending patches, it has nothing to do with allwinner code
<megi>
it's some cbc-neonbs rework in 5.10
<megi>
the fix is already queued as "crypto: arm/aes-neonbs - fix usage of cbc(aes) fallback"
<megi>
the weird errors that I posted previously were caused by infinite recursion, stack overflow and resulting mess
vagrantc has joined #linux-sunxi
[7] has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
grimR_ has joined #linux-sunxi
grimR has quit [Ping timeout: 264 seconds]
atsampson has quit [Ping timeout: 272 seconds]
KotCzarny has joined #linux-sunxi
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
camus1 is now known as kaspter
apritzel has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus1 has joined #linux-sunxi
camus1 is now known as kaspter
arete74 has quit [Ping timeout: 256 seconds]
_whitelogger has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
grimR_ has left #linux-sunxi [#linux-sunxi]
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
reinforce has joined #linux-sunxi
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #linux-sunxi
MoeIcenowy has quit [Client Quit]
MoeIcenowy has joined #linux-sunxi
random_yanek has quit [Ping timeout: 260 seconds]
camus1 has joined #linux-sunxi
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
kaspter has quit [Ping timeout: 246 seconds]
camus1 is now known as kaspter
MoeIcenowy has joined #linux-sunxi
AneoX has quit [Ping timeout: 260 seconds]
gediz0x539 has joined #linux-sunxi
koty0f has joined #linux-sunxi
AneoX has joined #linux-sunxi
random_yanek has joined #linux-sunxi
cmeerw has joined #linux-sunxi
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #linux-sunxi
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
gediz539 has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
gediz0x539 has quit [Ping timeout: 256 seconds]
kaspter has quit [Ping timeout: 256 seconds]
camus1 has joined #linux-sunxi
camus1 is now known as kaspter
koty0f has quit [Ping timeout: 265 seconds]
florian_kc is now known as florian
matthias_bgg has joined #linux-sunxi
pg12 has joined #linux-sunxi
pg12_ has quit [Ping timeout: 240 seconds]
nga0x539 has joined #linux-sunxi
gediz539 has quit [Ping timeout: 258 seconds]
apritzel has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
tuxillo has quit [Remote host closed the connection]
<hexdump0815>
i'm currently looking at the orange pi zero 2 legacy bsp u-boot - it seems to load its dtb in some kind of package together with u-boot most probably via boot0
<hexdump0815>
then that u-boot seems to be somehow hardcoded to use this u-boot dtb also for the booted kernel and i was not able to load a dtb to fdt_addr_r and use that for the booted kernel
tuxillo has joined #linux-sunxi
<hexdump0815>
i have now hacked arch/arm/lib/bootm.c by setting r2 = 0x43000000; (the default fdt_addr_r) and this way u-boot now provides the kernel properly with my fdt_addr_r loaded dtb
<hexdump0815>
but now i'm running into the next problem: it looks u-boot only supplies the chosen->bootargs from the dtb as cmdline to the kernel and whatever i'm setting in the bootargs env variable gets ignored
<apritzel>
hexdump0815: first: you should abandon BSP U-Boot. (Do it now, then wash your hands.)
<hexdump0815>
:)
<apritzel>
second: does the BSP U-Boot have the "fdt" command?
<hexdump0815>
yes it has the fdt command
<apritzel>
then you can tear down and rebuild the dtb dynamically
<apritzel>
it's tedious, but I had once some small tool to convert a dtb into a serious of "fdt ..." commands
dizzuhen has joined #linux-sunxi
ldevulder_ is now known as ldevulder
<hexdump0815>
but how does this bsp u-boot with packaged fdt work? is that described anywhere?
<apritzel>
hexdump0815: tbh: "packaged dtb" is the canonical way of doing things
<apritzel>
mainline does this as well:
<apritzel>
the SPL loads the DTB as part of the FIT image, appends it to the end of U-Boot proper, where it gets picked up
<apritzel>
then it continues to live at $fdtcontroladdr
<apritzel>
and if you do bootefi $kernel_addr_r (without specifying an extra FDT addr), then it will use exactly that DTB
<hexdump0815>
my idea was to get it working somehow to have an easy way to dual boot the legacy kernel on h313/h616 and for that i wanted to get the bsp u-boot at least to the point that i can tell it which dtb and cmdline to use without having to rebuild the full u-boot image each time
<apritzel>
have you tried chainloading U-Boot?
<apritzel>
works pretty well with mainline U-Boot, I use that to test stuff (loading U-Boot proper via tftp)
<KotCzarny>
or just usb-fel booting (assuming h313/h616 support is added)
<hexdump0815>
the problem is that there is no mainline u-boot for h616 yet and the the bsp u-boot is 32bit but booting a 64bit kernel
<apritzel>
hexdump0815: see above (... wash your hands)
dizzuhen has quit [Client Quit]
<apritzel>
hexdump0815: try building U-Boot for some H6 board, then supply the dtb of choice
<hexdump0815>
ok - looks like this stuff is really nothing to waste time with ... the sources did not even compile when i enabled earlycon due to missing ; at the end of a line etc. :)
kaspter has quit [Ping timeout: 265 seconds]
<hexdump0815>
but if i understand jernej correct that will fail due to non working dram initialization ... i just tried blindly to boot a h6 u-boot and nothing happened ... also tried to chainload a h6 u-boot.bin from the legacy boot but got an error immediately which seemd to be due to 32/64bit
kaspter has joined #linux-sunxi
<apritzel>
ah yeah, of course ...
<apritzel>
how do they boot the kernel? booti?
<hexdump0815>
bootm
<apritzel>
so that does the 64-bit transition
<apritzel>
you can try to sell your mainline U-Boot proper as a kernel
<hexdump0815>
so mkimage a uImage out of it?
<apritzel>
mkimage -A arm64 -O U-Boot -T standalone -C none -a 0x4a000000 -e 0x4a000000 -n U-Boot -d u-boot-dtb.bin u-boot.img
<apritzel>
that's how I wrap U-Boot for chainloading
gediz539 has joined #linux-sunxi
nga0x539 has quit [Ping timeout: 264 seconds]
<apritzel>
aside from that I would rather try to rip out their DRAM init code from boot0
<apritzel>
I once had some success with hacking some branch to the BROM's FEL routine into it (after DRAM init, but before it tried to load stuff), then proceeding with FEL from there
<hexdump0815>
for that i can just wait for you as this is a bit beyond my skill set :)
koty0f has joined #linux-sunxi
<apritzel>
hexdump0815: you need to wait with me: "2020.11.07 21:03 (GMT-7): Departed country of origin"
<hexdump0815>
just tested the chainloading of a mkimage'd h6 u-boot.bin, but it resets immediately to boot0 after starting ...
<hexdump0815>
waiting is no problem - there is no hurry
<Ashleee>
people have not given up on sunxi yet? :)
<Ashleee>
any news about something better than A53 cores?
<Ashleee>
I've been donated a box of all kinds of devices so I am now on 5 different IRC channels regarding different chips and problems... sunxi has the largest community and support, but the chips are aging :(
<diego71>
Ashleee: often age and support correlate :)
<Ashleee>
that's fair point :D
koty00f has joined #linux-sunxi
koty0f has quit [Ping timeout: 260 seconds]
<Ashleee>
albeit switching from A53 to A72 cores shouldn't be that hard as everything is peripherals anyways and it is not married to the actual cores
<Ashleee>
it's just a connection on AHB :)
tuxillo has quit [Remote host closed the connection]
<apritzel>
Ashleee: it's more a market thing: for what AW wants, A53 is good enough
<hexdump0815>
Ashleee: "allwinner silicon" :)
<apritzel>
I mean they introduce new SoCs with A7s, even
<apritzel>
and the A200 is rumoured to have big cores
<apritzel>
I just hope it's not A72
<hexdump0815>
a57 maybe? :)
* apritzel
runs away, screaming ...
<apritzel>
and I don't think anyone does A57 anymore, that's completely superseded by A72
tuxillo has joined #linux-sunxi
hexdump0815 has quit [Remote host closed the connection]
<megi>
I hope they'll not use PowerVR GPU in A200
<megi>
They used G31 MP2 in their latest SoC, so there's some hoping
* maz
eyes the bunch of A57s around him... Precious...
<apritzel>
maz: but also boring, at least in 2020
<gediz539>
what's the important factor to choose GPU? why PowerVR instead Mali? or vice versa
<maz>
apritzel: I wouldn't qualify Seattle as boring. it's still the best box around.
<KotCzarny>
price, performance
<apritzel>
which is true, but also sad
<maz>
apritzel: well, that's the ARM ecosystem for you. a bucketload of horseshit glued together, sold at the right price.
<apritzel>
maz: true, you get what you pay for. AW chips are said to be sold at around 5US$, so ...
tuxillo has quit [Ping timeout: 260 seconds]
<maz>
apritzel: and that's probably a fair price. the problem is with the much more expensive parts, which have the exact same "qualeetee" features as the AW crap. they just end-up crashing faster.
<jernej>
It's not yet working, but it should be close
<jernej>
annoyingly, SPL must power on DRAM power line, which brings I2C and AXP driver into it
<apritzel>
wow, that looks awesome
<apritzel>
and yeah, having the PMIC in there looks really annoying
<apritzel>
jernej: how big does the SPL get? Are you already relying on the H616 allowing 48K sized SPLs/boot0s?
<apritzel>
jernej: can you cheat for the PMIC and just issue an opaque sequence of I2C transfers to enable this one line?
<jernej>
apritzel: I'm building it in 32-bit mode for now, in order to use FEL (must easier for testing)
<jernej>
so I didn't yet consider size
<apritzel>
jernej: I see, same here
<jernej>
one thing at the time
<apritzel>
I have reworked my SPL32 patches and will send them
<apritzel>
I did some research and testing, and it looks like return to FEL from AArch64 is not possible
<jernej>
what does it make impossible?
<apritzel>
glad you ask ;-)
<apritzel>
there are two ways to get back to AArch32:
<apritzel>
either using the RMR (which we use to get into AArch64, just with that bit flipped)
<apritzel>
or dropping "back" into secure SVC, using an ERET
<apritzel>
RMR seems to be a dead end, because it does not seem to honour a changed start address
<apritzel>
at least the normal RVBAR shadow in CPUCFG does not work, and setting MVBAR before also has no effect
<apritzel>
the AArch32 reset vector seems to be hardwired to the BROM
<apritzel>
dropping to AArch32 secure EL1 (aka secure SVC) works, but that's really EL1, so is less privileged and is not the same flavour as the initial secure SVC we boot into
<apritzel>
many things don't work: setting CNTFRQ, reading SCR, switching to monitor mode, and, most importantly: doing an RMR to get back into AArch64 :-(
<apritzel>
so with some simple code I was able to get back into FEL, but things are fishy, I guess we lose too much FEL state over those switches
<apritzel>
for instance I got weird errors from sunxi-fel, pointing at pointers being off and stuff
<apritzel>
with a proper SPL I didn't manage to return properly into FEL, in any case
<jernej>
oh, that's too bad
<jernej>
thanks for detailed explanation!
<apritzel>
so I wanted to push the patches for compiling U-Boot (SPL, really) in AArch32, even for the ARMv8 parts
<apritzel>
jernej: yw, I would be too happy to stand corrected, for instance if there is a way to change the reset vector for AArch32
yann has quit [Ping timeout: 264 seconds]
<jernej>
I always assumed that such parts of cores are not open to integrators, so they always behave the same
<bauen1>
apritzel: your problem is that resetting into aarch32 jumps to the brom at address 0x0000 when you want to land at address 0x0020 (enter_fel) ?
<apritzel>
bauen1: somewhat, but not even 0x20 would be enough, since I need to *return* to where FEL dropped me, initially
<apritzel>
bauen1: so I need to branch to some custom AArch32 code to restore the registers
<bauen1>
apritzel: the brom contains some logic for super standby and some other stuff that could be used to "subvert" the instruction flow before executing any actual boot code
<apritzel>
bauen1: but yeah, I seem to be dropped to 0x0, where FEL restarts, throwing off sunxi-fel
<megi>
I cheat and return to FEL from aarch64 by setting a flag in RTC and issuing a SoC reset and the just jump to 0x20 from very early aarch32 code
<apritzel>
bauen1: interesting, I remember that, might indeed be a way in
<megi>
it seems to work
<bauen1>
megi: that's probably what i'm talking about
<megi>
I do the jump based on RTC flag (and clear it too)
<apritzel>
megi: but that's not proper "return" to FEL, right? It's more like a FEL restart?
<megi>
well I never get into FEL in the first place, so yes
<apritzel>
megi: you mean you start from non-FEL (SD card, SPI, ...), then drop into FEL?
<megi>
yes
<apritzel>
megi: ah, I see. Thanks for that hint, I might spent some time on investigating that
<bauen1>
apritzel: you could save the register information somewhere safe and setup a tiny routine that restores the registers and returns to fel
<apritzel>
bauen1: that's what I am doing, yes
<megi>
but I'm already in aarch64 mode before the restart
<jernej>
RTC has some scrap memory
<megi>
that's why I'm mentioning it
<jernej>
*scratch
<bauen1>
jernej: are you refering to the ~8 words ? or is there more undocumented scratch memory ?
<apritzel>
megi: my hope was to get proper and clean sunxi-fel support using a mainline (AArch64) SPL
<jernej>
I'm not sure how big it is, but 8 words sounds about right
<apritzel>
bauen1: the problem is: that fixup code is never called, because it goes to 0x0
<bauen1>
apritzel: yeah, but you can make the early nbrom code jump to your fixup code (iirc even before the sp is setup)
<apritzel>
bauen1: you mean using this super-standby trick?
florian has quit [Quit: Leaving]
<bauen1>
apritzel: maybe, i think you could also trick the cpu 0 into thinking it's being started as not cpu0 by setting some bits in the rtc and resetting
<apritzel>
SP is not an issue, all registers are gone anyway, because RMR is a reset
<apritzel>
I just need SCTLR, SP, LR, I think, so that's not much
<apritzel>
and SRAM stays alive (it's just a core reset)
<bauen1>
(looking at an h6 sbrom, but should be similiar to nbroms of similiar models): write 0xFA50392F into BOOT_CPU_HP_FLAG_REG and your desired address into CPU_SOFT_ENT_REG0
<apritzel>
so all I need is some branch to my code
yann has joined #linux-sunxi
<bauen1>
apritzel: the nbrom should jump to your address before even messing with any hardware registers
<bauen1>
apritzel: essentially faking a core 0+ reset i think
<apritzel>
bauen1: is that the "super-standby" resume? Or the MPIDR!=0 trick?
<bauen1>
apritzel: what is MPIDR ?
<bauen1>
is that the core number ?
<apritzel>
the core ID
<apritzel>
yes
<bauen1>
i think so
<bauen1>
but at least the sbrom h6 checks if (MPIDR != 0) || (BOOT_CPU_HP_FLAG_REG == 0xFA50392F) -> jump(CPU_SOFT_ENT_REG0)
<apritzel>
Multi Processor ID Register
<bauen1>
would that work ?
<apritzel>
bauen1: cool, thanks, that sounds promising
<apritzel>
bauen1: Is BOOT_CPU_HP_FLAG_REG documented? Do you know the equivalent for A64, for instance?
<bauen1>
apritzel: it's the name of the register in the documentation, not sure how documented it is for A64 (if it exists), let me check
<apritzel>
bauen1: a lot of CPUCFG is missing in the A64, that's why I am asking
<bauen1>
apritzel: it's part of the RTC
<apritzel>
we lifted some registers from AW's ATF code
<apritzel>
oh
<bauen1>
but yeah i don't see it there either
<bauen1>
let me look at the nbrom
<apritzel>
bauen1: many thanks!
<bauen1>
apritzel: write 0xFA50392F into 0x01f01dac, the entry address into 0x01f01da4
<bauen1>
so yeah same offsets into the RTC register space as the h6
<apritzel>
sounds like magic C64 "poke codes" from those 1980's computer magazines ;-)
<bauen1>
lol
<bauen1>
is there a wiki page with a bit more technical information about the registers than https://linux-sunxi.org/RTC ?
<apritzel>
bauen1: I am afraid it's a Wiki, so it would be up to you to enter it there :-D
<bauen1>
yeah, the RTC looks like a very important peripheral with lots of magic that is pretty much the same on all the chips
<apritzel>
bauen1: are those really specific registers, or is it just some scratch SRAM on a separate power line?
<bauen1>
apritzel: part of the rtc reg space is probably just sram
<bauen1>
there's at least 4*8 + 4*3 bytes of it
<apritzel>
and since the BROM is fixed, they have a very specific purpose, I guess
<bauen1>
yes
<bauen1>
looking at the H6 docs, there's all kinds of registers from ~0x0100 to ~0x218 that kind of look like sram
<bauen1>
also not really sure what e.g. CRY_CONFIG_REG is for
<apritzel>
bauen1: that's admitting that reading Allwinner documentation takes its toll ;-)
<bauen1>
i mean if you cross reference enough user manuals from different allwinner chips you probably get a pretty good overview lol
<bauen1>
it's actually quite nice that they don't lie per se, they only lie by omission
<apritzel>
that's true, sometimes they accidentally seem to publish something, for instance the A80 manual is some good source of information
<bauen1>
smaeul: by the way you said that the SPC on the H6 has different registers, how did you determine that ?
iamfrankenstein has joined #linux-sunxi
iamfrankenstein has quit [Client Quit]
lucas_ has joined #linux-sunxi
lucascastro has quit [Ping timeout: 264 seconds]
lucas_ has quit [Ping timeout: 264 seconds]
juri_ has quit [Ping timeout: 260 seconds]
<bauen1>
it also occured to me that if there is enough ("persistent") sram in the RTC you could store (parts of) the a secret in there along with hooking the super standby and hotplug vectors to prevent FEL from ever becoming active without "erasing" the secret
<bauen1>
that would require a RTC battery though
<bauen1>
assuming that all of the values are retained on RTC power
tuxillo has quit [Remote host closed the connection]
<apritzel>
being persistent is the whole point of the RTC SRAM, I would say
<bauen1>
it does require a battery, i think
<apritzel>
cf. CMOS RAM on the IBM PC
<apritzel>
bauen1: across power-off's: yes
<bauen1>
for something like the pine phone that might not actually be that much of an issue
<apritzel>
but at least it VDD_RTC stays on even if the PMIC is otherwise powered off
<apritzel>
exactly: you don't need a separate RTC battery, if you have constant power from some other source
<bauen1>
doesn't really solve the issue of disableing secure boot
<apritzel>
well, there is one solution:
merbanan has quit [Ping timeout: 240 seconds]
<apritzel>
choose another SoC vendor ;-)
<bauen1>
but allwinner is so damm cheap
<KotCzarny>
you get what you pay for
<KotCzarny>
as usual
<bauen1>
true
<apritzel>
that's their tree foremost selling points: yes
<apritzel>
s/tree/three/
<KotCzarny>
imo, being open is also a nice feature
<KotCzarny>
wouldnt you hate throwaway devices without future?
<apritzel>
KotCzarny: what do you mean with "open"? hackable, unbrickable?
<KotCzarny>
as it is even old socs a10/a20/h3 are nicely supported and useful
<KotCzarny>
apritzel: both
<KotCzarny>
hackable and unbrickable
<apritzel>
which is exactly what bauen1 does NOT want ;-)
<KotCzarny>
imagine aw socs without fel and/or sdcard boot priority
<KotCzarny>
there are way to secure os in linux without additional support from hw
<KotCzarny>
*ways
<KotCzarny>
and thats without locking the hw in the first place
<bauen1>
KotCzarny: not against a local attacker with decent knowledge, e.g. desolder/solder components from the pcb, attach to traces but without the ability to decap the SoC (or use lasers to extract the secrets from efuses)
<bauen1>
power glitching would be another fun attack vector to explore
<KotCzarny>
bauen1: resin and explosives?
<bauen1>
hm, booby trapping your computer sounds fun, especially if you ever need to go through customs lmao
<KotCzarny>
there are always ways, its just depends on budget and determination
<KotCzarny>
destroying emmc/soc would be enough
<KotCzarny>
no need to blow up the building
<bauen1>
also, can you like not write to the RTC using sunxi-fel ?
merbanan has joined #linux-sunxi
lurchi__ is now known as lurchi_
andy25225 has quit [Ping timeout: 260 seconds]
andy25225 has joined #linux-sunxi
<bauen1>
quite a lot of the bits in BROM_CONFIG seem to influence how the clocks are configured, i wonder if you can "brick" fel by messing with them
<bauen1>
only ~8 bits, so you would just need ~256 boards to test it :D
<bauen1>
also looks like bit 15 is both used to select software sha256 and booting images without 0x10303
<bauen1>
oh nevermind that was an off-by-one error
lurchi_ is now known as lurchi__
yann has quit [Ping timeout: 260 seconds]
lucascastro has joined #linux-sunxi
yann has joined #linux-sunxi
tuxillo has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
<bauen1>
has anyone ever investigated what changes with the FEL if the magic is present at 0x22800, 0x22804 ?
<bauen1>
it kind of looks like the FEL will skip initialising the GIC (Generic Interrupt Controller) if the magic is copied
<bauen1>
there's a small chance that this could be used to "disable" the FEL without burning pins
<bauen1>
it looks like the sbrom sets SCR.IRQ = 1 (p15,0x0,r3,cr1,cr1,0x0
<bauen1>
doesn't that mean that any IRQs would be handled by the monitor (located at MVBAR)
<apritzel>
bauen1: yes
<apritzel>
and unless it's cleared again later, non-secure world would never see any interrupt
<bauen1>
nice, now i'm seriously confused what exactly sbrom / nbrom is doing
<apritzel>
I am a bit rusty in ARMv7, but I think you need to set this bit when you need to be in secure world in your interrupt handler
gaston1980 has joined #linux-sunxi
<apritzel>
mmh, actually it would only make sense if you running in non-secure world while the IRQ fires, otherwise you would get to "secure IRQ"
<bauen1>
actually something better, with the GIC FIQEn=1 every interrupt to the GIC, e.g. a usb controller, would instead be run as FIQ (and using the FIQ handler instead of IRQ handler) ?
<bauen1>
so if 0x18 (fiq) is an infinite loop and the GIC has been configured with FIQEn=1 then the infinite loop will be executed instead of whatever is at 0x14 (irq)
<bauen1>
at least that's what i would think
<bauen1>
and it just so happens that the SBROM sets GICC_CTLR.FIQEn=1 before jumping to the NBROM / FEL, and the NBROM can be made to skip the GIC init if 2 magic values are stored at a specific SRAM location
<bauen1>
which is done by the SBROM if a certain bit in the BROM_CONFIG is set
<bauen1>
the NBROM expects IRQs and would normally set GIC_CTLR=1 (FIQEn=0)
<bauen1>
anyway, that probably requires bricking an actual board to test \o/
<bauen1>
this is kind of assuming that FEL requires IRQs to work
<bauen1>
so in theory this could be a way of "bricking" FEL