<Lightsword>
how does FEL boot work when secure boot is enabled?
dsimic is now known as Guest12879
dsimic has joined #linux-sunxi
Guest12879 has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
<junari>
jernej: Have you started work on the DE A523 yet? I looked at the BSP code and it looks like the main problem is related to the new INNO phy hdmi controller
smaeul_ has joined #linux-sunxi
smaeul has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
bauen1 has joined #linux-sunxi
<Lightsword>
I keep getting usb_bulk_send() ERROR -7: Operation timed out whenever I try to FEL boot a h616 for some reason
gsz has joined #linux-sunxi
smaeul_ has quit [Ping timeout: 480 seconds]
<junari>
And does anyone have a user manual for the T527 (not a523)?
smaeul has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hexdump02 has quit []
hexdump0815 has joined #linux-sunxi
<hexdump0815>
not sure if this is of any help and the same thing, but i think some rockchip socs have a inno hdmi
<gamiee>
Lightsword : you use mainline or vendor u-boot?
<Lightsword>
gamiee, tried building mainline, seemed to have a similar issue with vendor u-boot binary
<gamiee>
Lightsword : I am asking due which UART it uses.
<Lightsword>
gamiee, well when I tried with mainline I configured the build to use sdcard uart
<apritzel>
Lightsword: with secure boot enabled, you get FEL in non-secure world (SVC with SCR.NS set). In previous SoCs (definitely A64), you then just execute an "smc", which returns with the .NS bit cleared
<apritzel>
this is what sunxi-fel implements: the moment it detects a non-secure FEL environment (by trying to read from secure SRAM, for instance), it issues this SMC
<apritzel>
now there is some indication that this doesn't work anymore on more recent SoCs. For instance FEL was still non-secure after the smc on an A133
<apritzel>
on the H616 it's less straight-forward to detect secure vs. non-secure, since it doesn't have secure SRAM
<gamiee>
ohh, the device have secure boot enabled? Oops
<apritzel>
now the reason nothing with mainline works in this case is that the BootROM runs AArch32, and to switch to AArch64 you need to be in the highest implemented exception level, which means secure SVC in our case
<gamiee>
BTW, isn't FEL "security risk" when trying to achieve secure boot, since it let's you to write memory and execute literally anything? (I probably miss something, but I do not know the architecture that well)
<apritzel>
that's why I typically but "secure boot" in quotation marks when talking about Allwinner ;-)
<apritzel>
this smc returning with .NS cleared is clearly some backdoor built into the BootROM
<Lightsword>
apritzel, so...any suggesions on how I should go about getting uart working or stuff booting off of usb fel?
<gamiee>
So they still did not "fixed" it ? Eugh. I would at least hope there is some eFuse option to disable FEL, but I didn't saw that on wiki.
<apritzel>
I am not sure you will get very far with FEL, if it's really true that the smc doesn't work any longer. I tried for a while, but couldn't find anything on this A133 tablet of mine
<apritzel>
gamiee: they built this smc backdoor in deliberately, not sure AW actually *wants* to fix that, or if anybody really cares
paulk-ter has joined #linux-sunxi
<apritzel>
Lightsword: you should still be able to execute code in FEL, so output something on the UART, or blink LEDs, you just cannot run 64-bit code or even 32-bit Linux (the GIC won't work)
<Lightsword>
apritzel, how would I output to sdcard uart from FEL?
paulk-bis has quit [Ping timeout: 480 seconds]
<apritzel>
Lightsword: go into uart0-helloworld-sdboot.c and add FLAG_UART_ON_PORTF to the H616 description
<apritzel>
then compile this into the normal .sunxi (eGON) format and try to execute this via "sunxi-fel spl"
<gamiee>
apritzel : oh... So in Secure Boot mode, FEL is running in non-secure mode, that still let write and read memory, and execute code. Thus I presume it can access eMMC, NAND etc. That sounds for me like backdoor. (to other side, it's named Secure Boot, not securing the chip itself or "hardening")
radxanaoki has joined #linux-sunxi
<apritzel>
my hunch is it's a tick box for customers: Do you support secure boot? Yes, we do!
<gamiee>
(also I wonder, how could Allwinner get Google Play certification with such "security level")
<apritzel>
exactly with that trick: they demonstrate this secure boot method, and avoid talking about FEL (or this all ones/all zeroes ROTPK hash)
<gamiee>
wow, congrats allwinner
<Lightsword>
apritzel, it doesn't need to be signed or anything right?
<apritzel>
no, it's sunxi-fel parsing and loading that image, so it has to be the normal unsigned eGON format
<apritzel>
sunxi-fel doesn't even support TOC0. I made some patches a while ago, but there was a problem with them, and I didn't follow up on this
<gamiee>
about the ROTPK hash all ones trick, I think it makes sense, it's unusual to see it, but mostly when you already have internal execution rights for doing this, it does not matter anyway you can disable ROTPK verification. (+ I probably saw similar mechanisms in several MCUs). But yeah, having FEL as is even in secure mode is... wrong.
<apritzel>
gamiee: thing is all tablets I have seen with "secure boot" have ROTPK all zeros, so you can still create a valid TOC0, with your own made-up key and it boots
<apritzel>
and those are the tablets that are sold, even on Amazon
<gamiee>
sigh... Like, I would understand all of this for Chinese low-cost tablets, but the fact that Google gave them certification is .... mind blowing for me.
<Lightsword>
btw one thing weird I had noticed was that the normal sd card that forces the system into FEL mode doesn't actually work on mine...but it seems that led flash image you sent me does actually for whatever reason put it in FEL mode
<Lightsword>
lol, and somehow I end up trying to bring up a board where they really love putting in as much anti-reverse engineering techniques as possible
<apritzel>
Lightsword: you mean the normal uart0-helloworld-sdboot image from sunxi-tools? That is out of the box just eGON, you would need to manually convert this into TOC0 - if you haven't done this
<apritzel>
Lightsword: sorry, I meant the fel-sdboot image
<apritzel>
Lightsword: my tool literally ends with the same "go to FEL" sequence, but I am not sure it gets there even, it might just be that the BROM falls back to FEL because the SD card boot somehow failed
<Lightsword>
yeah, kinda guessing it's just a boot failure
<Lightsword>
anyways will give that a shot tomorrow, about to head to bed
warpme has quit []
apritzel has quit [Read error: Connection reset by peer]
<Lightsword>
or is it uart0-helloworld-sdboot.sunxi?
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
Lightsword: neither, it's .bin ;-)
<apritzel>
.bin is "objcopy -O binary" from the .elf, .sunxi is "mkimage -T sunxi_egon" from the .bin, .toc0 is "mkimage -T sunxi_toc0" from .bin
<apritzel>
the build system is not using mkimage for the .sunxi generation, as mkimage learned that trick a lot later only
<Lightsword>
apritzel, ah, and what's correct sunxi-fel command to load it?
warpme has quit [Ping timeout: 480 seconds]
junari has quit [Remote host closed the connection]
<apritzel>
sunxi-fel requires an eGON header - and only an eGON header, but that's actually not necessary, at the end it just upload some binary to SRAM
<Lightsword>
so like sunxi-fel --verbose --progress write 0x2000 uart0-helloworld-sdboot.bin should work?
<Lightsword>
and then "sunxi-fel --verbose --progress exec 0x2000"?
<apritzel>
well, somewhat. First, it's 0x20000, but also the BROM's IRQ stack is at 0x21400 (don't ask why!)
<Lightsword>
apritzel, so once I have the bin file what's the correct mkimage command to use with it?
<apritzel>
that's why we have "sunxi-fel spl", which does quite some clever trickery to avoid that problem
<apritzel>
mkimage -T sunxi-egon -d yourcode.bin yourcode.sunxi (I think)
<apritzel>
(sunxi-tools uses mksunxiboot, which is a one-trick pony, predating mkimage's eGON capabilities)
<Lightsword>
apritzel, um...so I build uart0-helloworld-sdboot.bin with sunxi-tools right? then I do mkimage -T sunxi_egon -d uart0-helloworld-sdboot.bin uart0-helloworld-sdboot.egon then I do sunxi-fel --verbose --progress spl uart0-helloworld-sdboot.egon to load it? is that right?
<apritzel>
yes
<Lightsword>
apritzel, any idea why I would get "=> Executing the SPL... done." then "usb_bulk_send() ERROR -7: Operation timed out"?
<Lightsword>
I shouldn't try passing other options to mkimage right? like mkimage -A arm -O Linux -T sunxi_egon -C none -a 0x20060 -e 0x20060 -n bootinfo -d uart0-helloworld-sdboot.bin uart0-helloworld-sdboot.egon or something?
<apritzel>
you can, but it shouldn't change anything, really. Those are mostly for the now so-called "U-Boot legacy image", which wants all those fields to populate
<apritzel>
what we really need is the magic, the checksum, and the length in the eGON header
<Lightsword>
apritzel, hmm, well I have no idea why this doesn't do anything, I mean it seems to upload fine but then times out when executing
<apritzel>
which means the code hangs for some reason, and doesn't return to the FEL routine in the BROM
<apritzel>
is that the original, unchanged uart0-helloworld-sdboot?
<Lightsword>
apritzel, hmm, oh wait, I had added an infinite print loop
<Lightsword>
apritzel, removed that and now it does seem to return back
<Lightsword>
apritzel, so sounds like it is actually doing something then...but no uart output still, argh
<Lightsword>
apritzel, one thing is that I've been triggering fel mode using a toc0 sd card that doesn't boot, then I swap the sd uart adapter in before executing sunxi-fel
<apritzel>
Lightsword: you can also use "sunxi-fel writel 0x<address> 0x<value>" to directly write to MMIO, or "sunxi-fel readl" for reading, if you want to directly poke peripherals
<Lightsword>
apritzel, does FLAG_UART_ON_PORTF actually work for sdcard uart on h616 boards? or is that kinda an unknown?
<apritzel>
this switching should work, but PortF on H616 is indeed mostly untested
<apritzel>
let me try this...
<Lightsword>
oh, and to make a toc0 version of fel-sdboot I should do "make fel-sdboot.bin" then "mkimage -A arm -O Linux -T sunxi_toc0 -C none -a 0x20060 -e 0x20060 -n bootinfo -d fel-sdboot.bin fel-sdboot.toc0"?
warpme has joined #linux-sunxi
<apritzel>
yes
<apritzel>
I just see that you need to change MUX_2 to MUX3 in the H616 entry if you want UART on SD card
<apritzel>
yeah, that works for me, on the OrangePi Zero2
<apritzel>
(instead of the SMC, that's just the binary encoding of "smc #0", hiding it from the jealous assembler)
<Lightsword>
apritzel, works, but something a bit odd, throws a "usb_bulk_send() ERROR -1: Input/Output Error"
<Lightsword>
but seems to be temporary the error
warpme has quit [Ping timeout: 480 seconds]
<Lightsword>
also throws a bit of garbage over uart right after "Returning back to FEL."
<apritzel>
I see, the BROM might be confused about this change, and maybe some banked register breaks this
<apritzel>
what's extra tricky is that this is AArch32, but on a v8 chip, which is a bit niche in this early state (AArch32 EL3)
<Lightsword>
apritzel, yeah, guessing it's causing some extra hardware to get reset when going back to fel mode from 64 bit mode or something?
<apritzel>
we are still in AArch32, it's just secure SVC vs. non-secure SVC
<apritzel>
the smc workaround has some documentation in sunxi-tools.git/fel.c:aw_apply_smc_workaround()
<Lightsword>
apritzel, ah, guess maybe secure->non-secure transition when returning to fel triggers some USB/ttl reset?
<apritzel>
no, it's just a bit in SCR that's changed, it leaves the rest of the chip and in particular the peripherals completely untouched
<apritzel>
but some registers are banked between secure and non-secure (the GIC comes to mind), so the BROM suddenly uses a separate copy, which doesn't hold the old values anymore
warpme has joined #linux-sunxi
<apritzel>
that's all explained in the 1332 pages of "part G: The AArch32 System Level Architecture" in the ARMv8 ARM ;-)
<Lightsword>
apritzel, heh, so this means I should be able to load uboot over fel?
<apritzel>
yes, eventually this should work
<apritzel>
we might need to fix something to not confuse the BROM, though
<apritzel>
does FEL survive after this? So can you run "sunxi-fel ver" again?
<apritzel>
OK, this is good. After up executed the SMC trick, can you run the version without the smc, but with the "mcr" line again? To see if this works now?
<apritzel>
(to check whether the smc effect is persistent across multiple calls, not that the BROM reset or fell otherwise back to non-secure)
<Lightsword>
ah, sec
<Lightsword>
apritzel, does not seem to persist
warpme has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
<apritzel>
bummer, I guess it somehow crashes and/or resets, which brings you back to FEL, but to the non-secure version again
<apritzel>
it's not a showstopper, just makes this a bit more complicated
<apritzel>
Lightsword: can you add ".needs_smc_workaround_if_zero_word_at_addr = 0x1158," at the end of the H616 stanza in soc_info.c, then rebuild sunxi-fel? That's a hack, but should activate the smc workaround automatically
<apritzel>
(0x1158 is just some address in the BROM that happens to be 0, to trigger that condition)
<apritzel>
maybe verify this with "sunxi-fel readl 0x1158", in case your BROM is slightly different
warpme has joined #linux-sunxi
<apritzel>
there is a high chance this doesn't work, but it's worth a try
<Lightsword>
that value is 0x00000000
<Lightsword>
enabling that workaround didn't seem to make the version without smc work
<Lightsword>
it seems to break things actually
<apritzel>
yeah, I guess the first time it works, but it issues the smc repeatedly, on every run, which might break things
<apritzel>
this later version should dump the state as the BROM FEL code sees and expects it, and we would need to transplant that to monitor mode
<Lightsword>
apritzel, ah head, looks like now it's giving 0x1d3 like your board
warpme has joined #linux-sunxi
<apritzel>
exactly, it looks like mine, but mine is in secure SVC to begin with (because it's not secure *boot*), so it can read secure registers and switch to 64-bit and things, no need for an smc call
<Lightsword>
apritzel, so what state needs to be transplanted exactly?
<apritzel>
ah, I have an idea, maybe forcing it to secure SVC again from monitor mode fixes the issue...