rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at - *only registered users can talk*
popolon has quit [Quit: WeeChat 3.0]
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
Mangy_Dog has quit [Ping timeout: 265 seconds]
gaston1980 has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 264 seconds]
ChriChri_ is now known as ChriChri
jstein has quit [Quit: quit]
camh has quit [Ping timeout: 260 seconds]
camh has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
camus1 has joined #linux-sunxi
camus1 is now known as kaspter
victhor has quit [Quit: Leaving]
xes_ has quit [Ping timeout: 272 seconds]
lucascastro has quit [Ping timeout: 240 seconds]
gaston1980 has quit [Quit: Konversation terminated!]
xes_ has joined #linux-sunxi
<wens> limited window size is one thing. IIRC the issue was the "fixed" address window that is actually another bus / address range that is only partially visible to the SoC
<wens> IIRC the RK3399 only has like 64k PCI window, but none of the extra broken translation layer stuff, so it's usable for most applications
<MoeIcenowy> KotCzarny: I did a try on virtualization
<MoeIcenowy> by trying to make the PCIe controller looks normal to OS
lkcl has quit [Ping timeout: 240 seconds]
<MoeIcenowy> jernej: is H616 DRAM controller similar to H6?
lkcl has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
<jernej> MoeIcenowy: Controller yes, PHY no
lurchi__ has quit [Ping timeout: 260 seconds]
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus1 is now known as kaspter
tlwoerner has quit [Ping timeout: 256 seconds]
tuxd3v has quit [Ping timeout: 240 seconds]
tlwoerner has joined #linux-sunxi
daregap has joined #linux-sunxi
akaWolf has quit [Ping timeout: 256 seconds]
_whitelogger has joined #linux-sunxi
ddlstwrr has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
akaWolf has joined #linux-sunxi
lkcl has joined #linux-sunxi
apritzel has joined #linux-sunxi
akaWolf has quit [Ping timeout: 260 seconds]
akaWolf has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
fl_0 has quit [Quit: STRG + Q]
asdf28 has joined #linux-sunxi
fl_0 has joined #linux-sunxi
fl_0 has quit [Ping timeout: 240 seconds]
fl_0 has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
cmeerw has joined #linux-sunxi
fl_0 has quit [Ping timeout: 256 seconds]
fl_0 has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
fl_0 has joined #linux-sunxi
macc24 has quit [Ping timeout: 244 seconds]
kaspter has quit [Ping timeout: 256 seconds]
macc24 has joined #linux-sunxi
kaspter has joined #linux-sunxi
jlusticky has joined #linux-sunxi
fl_0 has quit [Ping timeout: 265 seconds]
fl_0 has joined #linux-sunxi
fl__0 has joined #linux-sunxi
fl_0 has quit [Ping timeout: 260 seconds]
fl__0 is now known as fl_0
vagrantc has quit [Quit: leaving]
AneoX has quit [Ping timeout: 240 seconds]
AneoX has joined #linux-sunxi
lkcl has quit [Ping timeout: 256 seconds]
apritzel has joined #linux-sunxi
Perlovka has quit [Ping timeout: 240 seconds]
Perlovka has joined #linux-sunxi
florian_kc has joined #linux-sunxi
lkcl has joined #linux-sunxi
<apritzel> Does anyone know details about the H616 BROM's memory usage for FEL?
<apritzel> The V831 comment in sunxi-fel mentions "beginning of SRAM A1 and end of SRAM C", is this all, and are there more details?
<apritzel> I tried to extend the SPL limit to 48K (the H616 BROM can deal with eGON images of this size), but ran into errors (eGON.BAD)
lkcl has quit [Ping timeout: 240 seconds]
<apritzel> ah, nevermind, found it, the thunk address was in the way
lkcl has joined #linux-sunxi
jlusticky has quit [Quit: Leaving]
lucascastro has joined #linux-sunxi
lkcl has quit [Ping timeout: 264 seconds]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
lkcl has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria]
victhor has joined #linux-sunxi
victhor has quit [Remote host closed the connection]
victhor has joined #linux-sunxi
<bauen1> another note on the h6 sbrom: it clears almost all bits of SYS_CFG (0x03000000), which seems to be responsible for enabling SRAM
<bauen1> just a few more bytes wasted
tuxillo has quit [Remote host closed the connection]
cnxsoft has quit [Read error: Connection reset by peer]
kaspter has quit [Quit: kaspter]
tuxillo has joined #linux-sunxi
mauz555 has joined #linux-sunxi
eduardas has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
mauz555 has quit [Remote host closed the connection]
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
florian_kc is now known as florian
daregap has quit [Quit: daregap]
arti_ has joined #linux-sunxi
arti has quit [Ping timeout: 260 seconds]
ddlstwrr1 has joined #linux-sunxi
ddlstwrr has quit [Ping timeout: 240 seconds]
<jernej> apritzel: did you found any issue with sunxi-fel support for h616?
<apritzel> jernej: when loading eGON SPL images larger than 32K
<apritzel> it's a relatively easy fix (ignoring my ignorance of the thunk area above)
<apritzel> but brings up the question why we have a 32K limit in there in the first place
<jernej> history, I guess
<apritzel> for FEL loading that sounds rather arbitrary
<apritzel> actually we don't even need this to be in eGON format
<jernej> IIRC older SoC have such limit, but I'm not sure
<apritzel> yeah, but we already determine a limit dynamically, based on the location of the various swap buffers
<jernej> did you by any chance test your 64-bit FEL support on H616?
<jernej> oh, I guess it doesn't matter until DRAM driver is fixed
<apritzel> jernej: yeah, also I don't know the HP flag register location yet
<apritzel> jernej: I am just about to hack the OPi Zero2 boot0 to return to FEL, so I can use that to initialise DRAM, for unblocking U-Boot and Linux development
<apritzel> jernej: but apart from the 32K limit FEL works fine, so thanks for adding support!
<jernej> np, thanks for helping me with this!
<jernej> last few bits in DRAM driver are always most annoying...
<jernej> apritzel: so, initially, only FEL boot will be possible?
gaston1980 has joined #linux-sunxi
tnovotny has joined #linux-sunxi
<apritzel> jernej: yeah, just a quick hack to get beyond that, it's a clear "don't try this at home" (so no real workaround for the missing DRAM driver)
<apritzel> it should allow to easily dump registers, but I guess you did that already?
<jernej> yes, there is always a way, even if there is no /dev/mem device in android :)
mauz555 has joined #linux-sunxi
<jernej> however, it will be much simpler to play with SoC once custom versions of U-Boot can be run
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #linux-sunxi
mauz555 has quit [Ping timeout: 272 seconds]
<apritzel> jernej: I also need to do a Trusted Firmware port, which is a bit annoying since I probably need to put it in DRAM
<jernej> can you check where does BSP U-Boot put it?
<apritzel> AW always put in DRAM (even before TF-A actually supported that)
<apritzel> so an H6 U-Boot proper works out of the box, after this boot0 FEL hack initialised the DRAM
<apritzel> and I see mainline kernel output, then a crash because of missing PSCI
<bauen1> apritzel: please make sure that the dram you put it in is actually protected by what ever form of SMC (Secure Memory Controller) there is
<bauen1> or check if the rom actually sets that up for you
<apritzel> bauen1: sure, that's the easy part: there is a well known SMC, and it's easy to protect the first n KB
<bauen1> apritzel: ohhh, any links to documentation about the SMC or SPC (Secure Peripheral Controller) ?
<bauen1> kind of lacking the docs for that on the H6
<apritzel> but actually on all Allwinner boards TF-A runs in SRAM A2, which is NOT protected atm (without secure boot actually enabling the SPC)
<bauen1> true
<bauen1> and the SPC setup of the sbrom is lacking as smaeul noted e.g. the RTC isn't protected allowing privilege escalation
<apritzel> so A64 has it in its manual, and H616 as well, but indeed the H6 misses it
<jernej> apritzel: great! can you give me hacked boot0? I would like to do some memory dump...
<apritzel> bauen1: (SPC and SMC, I mean)
<bauen1> apritzel: yeah but it appears that the h6 has a different spc at least
<bauen1> apritzel: let me check the a64 / h616 docs if they match
<apritzel> jernej: sure, it's not the full return to FEL version yet, but it branches to 0x20 after DRAM init (restaring FEL), which makes sunxi-fel abort, but works otherwise
<jernej> apritzel: new fel commands can be executed afterwards?
<apritzel> jernej: yes, and DRAM is accessible
<jernej> apritzel: so wouldn't be easier/better to have ATF in DRAM for all SoCs - for security reasons and any ARISC FW could use full A2 then
<apritzel> jernej: yes, I was thinking about this as well
<bauen1> smaeul: apritzel: according to the h616 manual the sbrom supports "AES-128, SHA-256, RSA-2048, DES" so the _STATUS flags can probably be used for loading encrypted firmware images
<bauen1> in the h616 they actually document offset 0x64 of the sbrom as fel_enter (i.e. offset 0x20 of nbrom)
<apritzel> jernej: so far we leave *all* of the DRAM to non-secure, which has some nice touch
<jernej> what "nice touch"?
<apritzel> jernej: with the first KB being secure, I expect some usability problems (people trying to load kernels there, etc)
<smaeul> apritzel: SRAM A2 is not switchable. once you blow the secure fuse, it's always secure-only
<bauen1> oh this h616 doc is a gold mine
<apritzel> jernej: as the secure world being more or less invisible (SRAM A2 isn't mentioned in the DT, I think)
<bauen1> apparently there is some form of DRAM encryption, which is awesome
<apritzel> smaeul: yes, I know, but it's the SPC which ensures this, I believe
<bauen1> apritzel: sadly only the memory location of the SPC / SMC are documented for the h616, no register locations
<apritzel> bauen1: I am afraid at this stage we are happy if we can run something at all, totally unencrypted and insecure ;-)
<bauen1> apritzel: true lol
<jernej> apritzel: imo using custom load addresses is just looking for trouble, usually there is a reason why U-Boot default load addresses are set to specific location
<jernej> so I wouldn't bother too much with that
<apritzel> bauen1: the SMC was an ARM TZ-380, with some ID registers somewhere, so you might be able to scan for it, or verify its location
<smaeul> apritzel: sure, and it's the TZASC ("SMC") which lets you partition DRAM for ATF. the comparison is moot because neither works on sun50i without the secure fuse
mauz555 has joined #linux-sunxi
<apritzel> jernej: yeah, it *should* work, but I expect some surprises here and there
<apritzel> smaeul: are you sure? I think the SMC works, even in non-secure
<apritzel> *boot
<smaeul> jernej: SRAM A2 is really the right place for ATF, because it's "always" (with fuse) secure, because SCPI shared mem is also in SRAM A2, and because putting it in SRAM allows you to kill DRAM during idle states
<apritzel> btw, smaeul, bauen1: did you find any secret bit that enables the SCP in the SBROM? Or is this directly tied to the secure fuse?
<bauen1> apritzel: on the H6 the SPC (and probably the SMC) are initialised before jumping to fel
<bauen1> 0x00002d50
<smaeul> bauen1: that's the "set everyting to non-secure" function. the A64/H5 SBROM does the same when entering FEL
<bauen1> smaeul: well it does set a few things to secure
mauz555 has quit [Ping timeout: 260 seconds]
<smaeul> apritzel: no secret bit as far as I can tell, only reference is ^^, so I think it's just the fuse.
<smaeul> bauen1: no, it doesn't touch the SMC, just the DMA controller, both CCUs, the GIC, and the SPCI
<smaeul> *SPC
<bauen1> smaeul: right
<jernej> smaeul: fair point
<bauen1> smaeul: do you know why exactly the nbrom fel doesn't work with the `smc 0` trick yet ?
<jernej> btw, H616 has some DRAM hold pin bit in RTC
<jernej> for even lower power consumption, I guess
<apritzel> bummer, I was hoping for it to eventually become usable on non-secure-boot SoCs as well
<smaeul> bauen1: no, I haven't looked into it, but I blame the GIC setup. probably fixing a GIC register or two in the SMC thunk is all that's needed
_rze has quit [Ping timeout: 256 seconds]
<bauen1> smaeul: perhaps copying the "fel magic" might do something, since that will skip some code where the fel touches the fel
<bauen1> and normally breaks the fel
rzerres has joined #linux-sunxi
rzerres has quit [Read error: Connection reset by peer]
rzerres has joined #linux-sunxi
<bauen1> kind of ironic since that's what i plan on using to "disable" fel
alexxy has quit [Ping timeout: 246 seconds]
alexxy has joined #linux-sunxi
eduardas has quit [Quit: Konversation terminated!]
mauz555 has joined #linux-sunxi
<bauen1> 0x108000 up to 0x00117FFF should be usable SRAM, right ?
<bauen1> but read/writes from fel would be ignored since SRAM A2 is marked as secure ?
<jernej> apritzel: it's interesting that OPi DRAM configuration spits a lot of warnings (errors?) on my T95 box, but DRAM seems to work nevertheless
<apritzel> bauen1: SRAM A2 should be RAZ/WI (read-as-zero/write-ignore) with the NS bit set (on secure boot boards), at least that's what I got from U-Boot
mauz555 has quit [Ping timeout: 264 seconds]
<apritzel> jernej: "[27980]read_calibration error", "[27983]retraining final error"? I get those as well
<apritzel> jernej: qualeetee!!!
<bauen1> oh nice i'm getting confused because binutils as doesn't read `;` as comment
widora_tinkerer has joined #linux-sunxi
<jernej> yes and write training errors too
<jernej> boot0 on t95 is much quieter
<apritzel> jernej: yeah, you could do the same trick with your box' boot0, I guess, or at least try to copy the DRAM parameters from the beginning of your boot0 into the OPi-Zero2 one
<jernej> that's what I plan to do
<jernej> btw, can you give me command for booting U-Boot proper? I guess you already have it :)
<apritzel> jernej: "sunxi-fel write 0x4a000000 u-boot.bin reset64 0x4a000000"
<apritzel> jernej: I just build a Pine H64 config
<apritzel> "close enough"
<jernej> apritzel: thanks!
<jernej> apritzel: is there a way to quickly update SPL checksum? but as you said, we don't really need header for fel...
<apritzel> jernej: yeah, I got annoyed over that as well :-(
<bauen1> hm, so my rtc code does seem to copy the sbrom to 0x108000 successfully, but when trying to jump to it something goes wrong at some point
<apritzel> I have my own sunxi firmware decoding tool, that outputs should-be and actually-is checksum, then I use a hex editor ...
<bauen1> the sbrom should be relocatable ...
<apritzel> jernej: but I guess it's actually easier to just disable the checksum check in sunxi-fel?
<jernej> apritzel: I'll try
<apritzel> bauen1: what makes you think so? I mean it might still contain absolute addresses (for SRAM buffers, initial stack pointer, ...)
<jernej> apritzel: nope, eGON.BAD
<bauen1> apritzel: well, the code shouldn't try to jump back into the original sbrom, the buffer are still at their "old" location
<bauen1> apart from maybe the part that copies the monitor code
<bauen1> or should i say, fel doesn't come up anymore
<bauen1> but my attack sd doesn't work anymore if i enable my "patching" code, so success i guess ?
<bauen1> oh right, maybe enabling the spc when trying to enter fel breaks things
<apritzel> jernej: remembered that my old boot0img tool prints the should-be checksum (with -c):
widora_tinkerer has quit [Ping timeout: 245 seconds]
<jernej> apritzel: what if I try regular write & execute approach instead of spl mode? that should work, right?
<apritzel> jernej: for uploading boot0? not really, since you probably overwrite the sunxi-fel code and the BROM FEL buffers and stack
<jernej> yeah, just figured as much
mauz555 has joined #linux-sunxi
mauz555 has quit [Ping timeout: 272 seconds]
<jernej> apritzel: so it seems DRAM init is pretty sensitive to parameters, not sure how easy would be to have same ones for all boards
mauz555 has joined #linux-sunxi
<jernej> the worst thing is that boot0 can hold up to 16 DRAM configurations and one is loaded on some parameter, GPIO value I think
<jernej> ok, default parameters work, now I need to dump everything and compare
florian has quit [Quit: Leaving]
<apritzel> jernej: what is the effect of having the wrong parameters? Does it not finish initialisation successfully? Then we could retry with other parameters.
<apritzel> jernej: I managed to run the very same binary image on boards with LPDDR3 and DDR3 DRAM (on a A64) using this method
<jernej> yes, it fails, but number of combinations is just big
vagrantc has joined #linux-sunxi
<jernej> and it seems that boot0 in some cases (both TV boxes I have) does only read calibrations, while OPi also does write leveling, read trainin and write training
<jernej> this is along with different PHY parameters
<jernej> now that parameters are updated, I guess only missing thing is bit delay compensation
dev1990 has quit [Quit: Konversation terminated!]
mauz555 has quit [Ping timeout: 260 seconds]
<bauen1> smaeul: how can i use the new mkimage to generate a toc0 from a binary blob ?
<bauen1> currently i'm trying `../u-boot/tools/mkimage -A arm64 -O linux -C none -a 0xDEADDEAD -e 0xC0DEC0DE -d test4.bin -T sunxi_toc0 test.img` but that doesn't produce any headers
tnovotny has quit [Quit: Leaving]
<jernej> apritzel: I guess this qualifies as success: :)
<jernej> never mind board model...
<jernej> and amount of DRAM is artificially halved due to the fact that 4 GiB doesn't fit into 32-bit variable used in 32-bit build
<apritzel> jernej: \O/
<jernej> let me push code
<apritzel> jernej: awesome, did you push that already? ;-)
<jernej> not yet
<jernej> apritzel: force pushed
<jernej> apritzel: anyway, that won't work as-is on OPi, due to different memory organization
<jernej> and different dram parameters
<jernej> let me try first to enable auto-detection code
<jernej> apritzel: updated again, rank, bus width and RAM size auto detection works
<jernej> so, potentially different parameters are in bit delay compensation, odt config, training and calibration selection and mrctrl1 values here:
<jernej> apritzel: OPi has mrctrl1 parameters as follows: 0x840, 4, 8, 0 and my T95 0x1f14, 4, 0x20, 0
<jernej> on my box read calibration fails if first value is incorrect
<bauen1> smaeul: also it looks like fb3040a0844fbc73f2807bc3353ede9cefad1cd2 in u-boot makes the mkimage step fail
<bauen1> unless maybe i've miscompiled mkimage in some way for some reason
<jernej> apritzel: will you work on TF-A support?
matthias_bgg has quit [Ping timeout: 260 seconds]
<apritzel> jernej: yeah, that's the plan
ldevulder_ has joined #linux-sunxi
<apritzel> jernej: shouldn't be too hard, just to find a nice solution for sharing most of the H6 code, but using a different load address
<apritzel> jernej: you should be able to go ahead with Linux by just disabling the secondary cores in the DT (and removing PSCI from the first one, too)
<jernej> ah, it's that simple? :)
ldevulder has quit [Ping timeout: 260 seconds]
<jernej> apritzel: first I would need 64-bit FEL support, updating kernel on SD card is annoying
<bauen1> i figured out that mkimage excepts some private keys, `openssl genpkey -outform PEM -algorithm rsa -out rotpk.pem -pkeyopt rsa_keygen_bits:2048` is what i've used
<bauen1> oh of course copying all of the sbrom instead of just 256 bytes helps a lot /s
<bauen1> stupid off by one errors
<apritzel> jernej: it looks like the H616 should be compatible to the H6, as far as the FEL64 patch is concerned
<jernej> yeah, I think so too
<jernej> apritzel: doesn't work...
<jernej> apritzel: there is no 0x1b8 RTC register documented in H616 manual
<apritzel> jernej: yeah, I saw, but the super standby is there, at the same address as in the H6
<apritzel> jernej: but maybe they ditched that along with the arisc
<apritzel> jernej: can you try 0x1f8 instead of 0x1b8?
<jernej> apritzel: nope, it doesn't work
<psydruid> I've built linux-next and am running it now but I can't see hdmi audio among the possible audio outputs
<jernej> psydruid: as I said yesterday, it's not yet finished
<jernej> a ton of patches required for hdmi audio landed, but it's not finished yet
<jernej> however, if you're ok with stereo, you can enable it pretty easily with DT changes only
<psydruid> could you tell me how to enable it, so I can test that for now?
<jernej> which SoC?
<psydruid> Allwinner A64 on the Orange Pi Win Plus
<jernej> in the mean time, I'll prepare another chunk
<psydruid> jernej, thanks, I'll do that
lucascastro has quit [Remote host closed the connection]
<apritzel> bauen1, smaeul: do you know what's the difference between super standby and this CPU hotplug, as far as the BROM is concerned?
<apritzel> at the end of the day that's just some other address to branch to, isn't it?
<jernej> psydruid: and add this in a64 dtsi file, before "soc {" line
lucascastro has joined #linux-sunxi
<jernej> psydruid: then you have to make sure that you have designware hdmi i2s audio and simple sound card drivers enabled, along sun4i-i2s
<bauen1> apritzel: super standby does a lot more than just jump to the address
<bauen1> apritzel: among other things it sets up a few registers related to clocks and then verifies that some magic (similiar to egon) is (near ?) the pointer
gaston1980 has quit [Quit: Konversation terminated!]
<jernej> psydruid: I made mistake in pastebin snippet - it should be sound-dai = <&i2s2>; <-- number 2
<apritzel> bauen1: thanks! is the magic the same, at least? 0xfa50392f?
<apritzel> I mean the one in the "Super Standby Flag Register"
<bauen1> apritzel: SUP_STAN_FLAG_REG (0x070001f8) & 0xFFFF == 0xefe8
<psydruid> jernej, I will try all of this and let you know if I get it to work
<bauen1> if that holds true the sbrom jumps to 0x00003694
<bauen1> then the sbrom compares the first 8 bytes at CPU_SOFT_ENT_REG1 with "eGON.BT0"
<apritzel> it never gets boring with Allwinner ...
<bauen1> i think it just expects a normal egon image at CPU_SOFT_ENT_REG1
<bauen1> apritzel: another fun thing, "brom_config_value" at 0x00117f00 is (i think) the only data the sbrom puts into SRAM A2
<bauen1> apritzel: the memory layout of s/n brom in general is "interesting"
<apritzel> bauen1: can one read the SBROM even when booted without the secure boot fuse burned? by flipping that bit?
<apritzel> then I could dump the H616 SBROM
<bauen1> apritzel: yes, but keep in mind that fel will stop working
<apritzel> bauen1: right, good point, will do it from an SD card then
<bauen1> apritzel: i think smaeul: did it that way for the H6 before figuring out that you can (ab)use the cpu 0 hotplug feature to enter secure mode
<bauen1> apritzel: smaeul: has a repo with all the rom dumps here
<apritzel> bauen1: yeah, I know, but I think it's missing the H616
<bauen1> apritzel: the bit to flip (at least on H6 sbrom) is i think at SYS_CFG+0xd0 == 0x030000d0
<apritzel> and I always forget the mapping for those stupid AW names ;-)
<bauen1> apritzel: to enable the nbrom the sbrom does ` 000097b0 02 41 84 e3 orr r4,r4,#0x80000000`
<bauen1> apritzel: some of these are directly from the H6 manual, some of them i've come up with myself so i always note the address
ats_ has joined #linux-sunxi
<bauen1> apritzel: perhaps a bit unclear, but 0x030000d0 is the address of the register you want to touch
<apritzel> I think I got this, thanks
atsampson has quit [Ping timeout: 260 seconds]
<bauen1> hm, i might be hitting another bug in the sbrom
<bauen1> i think the routine that handles loading from smhc0 will underflow if the image length is 0
* apritzel opens the drawer to look for that laser to patch it ...
<bauen1> personally i prefer butterflies
<bauen1> i didn't even put the length at the correct offset but my attack image still worked
<apritzel> does anyone have a datasheet for the AXP305?
mauz555 has joined #linux-sunxi
lucascastro has quit [Remote host closed the connection]
mauz555 has quit [Remote host closed the connection]
<bauen1> apritzel: smaeul: for the stack smashing PoC
<bauen1> and my PoC to prevent it by "patching" the sbrom is also working
<bauen1> ./sunxi-fel -v -p writel 0x070001b8 0xFA50392F writel 0x070001bc 0x07000100 writel 0x07000100 0xe3a07403 writel 0x07000104 0xe5874000 writel 0x07000108 0xe3a07942 writel 0x0700010c 0xe5948000 writel 0x07000110 0xe7878004 writel 0x07000114 0xe2844004 writel 0x07000118 0xe3540801 writel 0x0700011c 0x9afffffa writel 0x07000120 0xe59f9004 writel 0x07000124 0xe5879ba4 writel 0x07000128 0xe287fe32 writel
<bauen1> 0x0700012c 0xe1c061be wdreset
netlynx has quit [Quit: Ex-Chat]
mauz555 has joined #linux-sunxi
lucascastro has joined #linux-sunxi
<bauen1> nice, my test setup worked as intendet
<bauen1> so in theory all you need is an rtc battery + connector to securely store secrets in the H6 SoC (and similiar too probably)
<bauen1> with the biggest caveat being that decapsulating the chip (while powered), poking laser at it or perhaps using power faults to bypass the secure boot check
<bauen1> could still be used
<bauen1> and a few power side channel attacks could probably be used to extract the secret too
<bauen1> smaeul: the h6 manual too says that the sbrom supports `AES128,SHA256,RSA2048,DES` so maybe the STATUS field isn't unused ?
warpme_ has quit [Quit: Connection closed for inactivity]
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #linux-sunxi
mauz555 has quit [Ping timeout: 240 seconds]
willmore has quit [Remote host closed the connection]
datagutt has quit [Quit: kthxbai]
datagutt has joined #linux-sunxi
datagutt has joined #linux-sunxi
datagutt has quit [Changing host]
mauz555 has joined #linux-sunxi
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
mauz555 has quit [Ping timeout: 272 seconds]
willmore has joined #linux-sunxi
asdf28 has quit [Ping timeout: 240 seconds]
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
lurchi_ is now known as lurchi__
cmeerw has quit [Ping timeout: 272 seconds]
lynxis has quit [Remote host closed the connection]
mauz555 has joined #linux-sunxi
mauz555 has quit [Ping timeout: 260 seconds]
gaston1980 has joined #linux-sunxi