<fcas>
so, if the H3 starts with secure mode set, I should see something, it shouldn't just jump to FEL Mode if an non-secure image is used written on SD Card?
<fcas>
I got some tests done: 1) I can see the processor using SDIO to read the SD Card (logic analyser) 2) when I use FEL mode and send uboot, I can read the files from SD Card (so, SD Card Read should be working, at least to some point)
<apritzel>
fcas: there are two ways to enter FEL mode: explicitly, through the FEL "button", or as a fallback, because all other boot sources fail
<apritzel>
so I guess you confirmed that it's the latter, because you see SD card activity
<apritzel>
you could double check by "pressing" the FEL button, then you should not see any SD signals
<apritzel>
when the H3 is in secure "mode", it would ignore any normal eGON images, but expect a TOC0 image image
<apritzel>
when you connect via sunxi-fel -v, and the chip has the secure fuse burnt, you would see a message about "Applying SMC workaround..."
<apritzel>
tbh that's unlikely, but it's easy to rule out, much easier than to debug the SD failure
<fcas>
"Applying SMC workaround..." isn't showing here. I tried to read the register 0x01c00024, one of the bits reflects UBOOT pin status (1 when the strap is open, 0 when its short circuited to ground)
<apritzel>
fcas: have you tried uart0-helloworld-sdboot.sunxi?
<apritzel>
that's probably the most minimal SD test
<fcas>
I tried: 1) h3droid 2) armbian 3) yocto custom image 4) yocto core-minimal-image - All of them can boot orange pi pc plus, none can take my module out of FEL mode
<apritzel>
and the debug UART is the same as on the Orange Pi? Can you boot the same image that works via FEL on your board also via FEL on the OPi?
<apritzel>
fcas: and when you boot via FEL on your board, can you check the speed (roughly) of the SD access in U-Boot?
<fcas>
yes, the sch is almost the same. I can boot the orange pi via FEL using the same uboot with spl
<apritzel>
to rule out that for some reason it works on your board only at 400 KHz or so? Which the BROM might not support?
<apritzel>
at the moment I cannot think of much more than the traces on the board, because the negotiation is between the MMC controller (in the SoC) and the SD card, which are the same between your board and the OPi
<apritzel>
and SD card boot in general is pretty robust on Allwinner SoCs, at least I haven't heard or seen any significant issues
<apritzel>
you could add "#define DEBUG" at the *very* top of U-Boot's drivers/mmc/sunxi_mmc.c, and in other generic MMC framework files, to see if this reports anything unusual
<apritzel>
(when accessing the SD card after being booted via FEL)
<apritzel>
from all I know the BROM does not care about card detect, so that cannot be the culprit
<apritzel>
fcas: you bought the H3s from some Chinese website?
fcas has quit [Remote host closed the connection]
faruk has quit []
fcas has joined #linux-sunxi
<fcas>
yes, I got my Allwinners H3 from aliexpress
<fcas>
all from the same vendor
<fcas>
tried the toc iso, still in fel mode
<apritzel>
bummer, did you "dd" it to sector 16 / 8KB? dd if=...toc0 of=/dev/sdX bs=1k seek=8
<fcas>
let me try with that, I just used win32diskimager, sorry
<apritzel>
you could try to prepend 8KB of something to the TOC0 image
<fcas>
got this: Hello from Allwinner H3! Booted from MMC0, entering an infinite loop.
<fcas>
used dd if=...toc0 of=/dev/sdX bs=1k seek=8, and got that answer when poweing up the board
<fcas>
powering*
<apritzel>
alright, so then it's official: your SoCs are secure!
<apritzel>
funny enough we are actually looking for reasons to support secure boot as a first class citizen, so you have just discovered one use case ;-)
<apritzel>
there are already patches underway to generate TOC0 images during U-Boot build (by adding TOC0 support to mkimage)
<apritzel>
fcas: how many chips do you have? There are rumours(?) of an "undo secure" bit in the fuses somewhere
<apritzel>
if you could spare one for experimentation, you could free your H3s, maybe
<apritzel>
does anybody have any details about this "unsecure" fuse? I somehow heard about this: a fuse that undoes the effects of the secure fuse ...
<jemk>
apritzel: it was an idea based on the fact the sbrom reads two bits for all the other flags in LCJS, and only 0x2 is flag set. So burning it to 0x3 would disable it again. The alignment (bit 11 and maybe 10) would allow secure boot to behave the same way, but i never tried it.
<apritzel>
jemk: ah, nice, many thanks!
<jemk>
i have a h6 box where i could need this (secure by manufacturer, with rotpk burned), but i didn't dare to try
<apritzel>
jemk: same here ;-) the few boxes I have in secure I want to keep this way ...
<apritzel>
smaeul: do you know anything about this ^^^ or have even tried it?
<jemk>
well, i don't want to keep it secure, since it only boots the original android, but better boot this than boot nothing anymore
<apritzel>
jemk: it seems like at least the H6 secure BROM is busted, and you can boot whatever you like, after running some exploit
<apritzel>
jemk: can you FEL boot? otherwise you won't gain access to the fuses, I think
<jemk>
apritzel: i can execute some code with fel, but as soon as the smc workaround is applied it never returns to fel successfully, usb always times out. but smc works and i can print the fuses to uart
<jernej>
arnd: got response from Jerome - wfx driver is indeed based on cw1200, but Silabs did a ton of fixes on FW and in the process they changed API. This limits how much code could be reused directly.
<jernej>
arnd: so I guess best way forward is to integrate support for xr819 into cw1200
<arnd>
jernej: yes, makes sense. Would you still want to add a drivers/staging version, or just add any bits that are missing in cw1200?
<jernej>
arnd: I'm more for second option
<jernej>
since it's easy
<jernej>
adding staging driver would bring a ton of clean up work, which I'm not prepared to do
<jernej>
but someone else could, if so desired
<apritzel>
jernej: I second that (fixing cw1200), it seems this one deserves some love anyway
<jernej>
I'm more worry of FW quality, tbh
<arnd>
it may be helpful to go through the commits in the two main known-working drivers, just to see which ones make sense to be ported onto cw1200. If you just git-format-patch all of the commits on the fifteenhex and karabek repos you should get a few hundred files that you can sort into yes/no/maybe categories for porting
<arnd>
one possible reason to start with a staging version would be if the mainline cw1200 driver is already worse, but I don't think this is the case, at least this version would have received a lot of the treewide cleanups that the others may be missing
<jernej>
I checked few commits in fiftenhex repo and it was like changes were inspired by mainline cw1200
<arnd>
yes, at least a subset of them. I would assume that most patches can be discarded right away, e.g. anything that is aobut porting to a later kernel version, or updating the readme and makefile
<arnd>
but I would assume there are also at least some actual bug fixes for problems that are still present in cw1200
cmeerw has joined #linux-sunxi
<apritzel>
there might also be commits to compile out-of-tree for a variety of kernel versions?
<jernej>
sure, but my first target is to do initial xr819 bringup, comparing codebases and fixing bugs comes later
fcas has quit [Remote host closed the connection]
fcas has joined #linux-sunxi
<fcas>
just burned the iso from toc0 image on mmc2, started ok too
Luke-Jr has quit [Ping timeout: 480 seconds]
<gamiee>
fcas: well, so whole time it was in secure mode, oopsie...
fcas has quit [Remote host closed the connection]
<gamiee>
jernej: since the hello world TOC0 image works, does this means that only secure boot is enabled, no rotpk and other things burned?
<jernej>
gamiee: I'm not really familiar with the subject, but it seems so. ping apritzel, smaeul ^
<apritzel>
gamiee: yes, must be, otherwise it wouldn't have booted
<gamiee>
jernej, apritzel: thanks, this is what I though, just I asked in case that TOC0 hello world image have the exploit built in, but it doesn't not. Although, it's interesting to see H3 with secure fuse burnt
<apritzel>
gamiee: even if, as long as you can enter secure via FEL, you can complete the rotpk hash to be all 1's, then the key would be ignored again
<apritzel>
(AFAIK the condition for ignoring is "all bits 1 or 0"
Luke-Jr has joined #linux-sunxi
<gamiee>
apritzel: so it's easy to bypass... I wonder why they even implemented it, (almost) nobody uses it and it's easy exploitable, and as far as I know, even latest SoCs have same flaws.
<apritzel>
it's probably a tick box in some fact sheet ;-)
<apritzel>
"Supports secure boot"
<apritzel>
and I think the exploits were not known until recently
<gamiee>
most likely :D although, I'm still fascinated, how they can do this and also have companies which buys SoCs from them.
<apritzel>
many customers just don't care, I guess?
<gamiee>
most likely, but that's surprising for me (most of customers take care of their software, since sometimes it have bigger value than hardware)
<gamiee>
Most fascinating for me, was that they was able to strip off Android 4.4 "rootfs", keep only some wrappers as their "media pipeline" (so they can reuse their Android wrappers for CedarX) and fit all this into 16 MB and name it "CAMdroid". But they are not able to mainline stuff and write proper drivers.
<apritzel>
gamiee: "hacking the Linux kernel with a jagged axe" until it somehow works is one thing, writing proper code that gets merged is something completely different
<smaeul>
jemk: yeah the SMC workaround is broken on H6, because it switches to SBROM, whereas FEL is implemented in NBROM. to work, sunxi-fel would need to send a thunk with a SMC both before and after the payload, to switch back to NBROM before returning to FEL
<smaeul>
apritzel: I have not seen any evidence of being able to turn off secure mode with LCJS bit 10, but the secure mode bit (11) is handled in hardware, not the BROM, so bit 10 would likely be handled in hardware too
<apritzel>
fcas actually just tried it: he was able to set bit 10, but it did not have any effect
<apritzel>
so we know that now, at least for the H3
<apritzel>
any other volunteers for other SoCs? ;-)
<smaeul>
apritzel: the function for ignoring the ROTPK hash is "all bytes equal to first byte"
<apritzel>
smaeul: ah, thanks for the correction!
fcas has joined #linux-sunxi
<smaeul>
gamiee: for a real application, you would set the write protect eFuse, which would block further changes to ROTPK or the LCJS fuse
<smaeul>
and the stack smashing vulnerability is only applicable to H6 and H616, because they removed the TOC0 length limit. earlier chips are not affected
<smaeul>
(though they could still have some other bug that I'm not aware of)
prefixcactus has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
<machinehum>
Where would I look in the uboot menuconfig if I wanted to boot from spi flash?
<apritzel>
machinehum: CONFIG_SPL_SPI_SUNXI=y
<apritzel>
though I'd recommend adding it to the board's defconfig instead of selecting it manually
<machinehum>
apritzel: Thanks
<jemk>
smaeul: wouldn't that be true on H3 an others too? i thought fel is always implemented in nbrom, or do older socs not switch to sbrom with smc?
<smaeul>
jemk: right. for older SoCs, the SMC handler and monitor mode vector table are copied from SBROM to SRAM A2 before switching to NBROM, and FEL stays in NBROM
<gamiee>
smaeul: so secure boot on H3 is not exploitable, even with FEL?
<jernej>
warpme_: I updated cw1200 with reading MAC from DT
<jernej>
that alias trick should work now
<smaeul>
gamiee: I don't really consider FEL giving you EL3 access to be an exploit, just "how FEL works". I don't know offhand if H3 allows you to disable FEL, like the newer chips
ftg has joined #linux-sunxi
choozy has joined #linux-sunxi
<warpme_>
jernej: thx. current code gives constant mac. nice!
<warpme_>
btw: have you plans to look on suspend/resume in cw1200?
<jernej>
I guess I should just remove it
<jernej>
I got advice in this direction from wfx driver maintainer
<warpme_>
do you mean remove from cw1200 right?
<jernej>
yes, pm.c and pm.h
<warpme_>
you know - isn't that is had also intention to support WoW?
<warpme_>
i mean WoL
<jernej>
yes, he said I should avoid WoL
<jernej>
well, it should be easier to drop it
hlauer has joined #linux-sunxi
<warpme_>
well - if advice is because it will never work (or will systematically break s3ram) - then i fully understand such decision. if however removal is because he don't believe WoL is worth to play due low usage - then i'll disagree abit...
<apritzel>
warpme_: you can always bring it back later, once the basic support has been merged - which should be the focus
<warpme_>
apritzel: well. currently it 1/not works; 2/breaks suspend-resume. for sure imho higher priority should be to not break things so i agree with jernej's proposal. just want to understand rationale of cw1200 developer statement....
<jernej>
I don't know why he suggested that, I'll ask
<gamiee>
smaeul, hmm, well, I see fel as "danger", since even with secure boot, it's possible to boot 3rd party software, isn't it?
<jernej>
warpme_: btw, it was wfx dev who suggested that, not cw1200
<jernej>
and wfx driver doesn't support wowlan
cmeerw has quit [Ping timeout: 480 seconds]
fcas has quit []
hlauer has quit [Ping timeout: 480 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
<machinehum>
Is there something special I have to do to enable USB on the A33? I've already set CONFIG_USB_COMMON=y in the kernel but lsusb doesn't give any output when I plug stuff in
<machinehum>
I've tried a wifi dongle and usb drive