\\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]
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 :)
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
<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>
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>
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]