<smaeul>
apritzel: ah, so you want a way to intercept control flow at EL3, from EL1... sounds like a security vuln :D
<apritzel>
smaeul: no, I just want to boot into FEL, from the U-Boot prompt ;-)
<apritzel>
this works on the H6, because we can do an (unprivileged) watchdog reset
<apritzel>
and the registers survive
<apritzel>
on the other cores they don't
<smaeul>
and because you can do an unprivileged write to the hotplug entry point
<apritzel>
so we would need to do a core reset only
<apritzel>
yes
<smaeul>
sounds like what you want is a vendor-specific SMC call, no?
<apritzel>
PSCI 1.0 specifies a SYSTEM_RESET2 call
<smaeul>
or a vendor-specific SYSTEM_RESET2 method :)
<apritzel>
"The function is intended to provide a fast reboot path that guarantees not to reset system main memory."
<apritzel>
either vendor specific, but maybe the architected version ^^^^^ fits already
<smaeul>
no, because SPL will trash main memory
<smaeul>
we would need to detect that DRAM was still working and skip DRAM init
<smaeul>
then I guess we could meet the requirement
<apritzel>
yeah, those details would need to be worked out
<apritzel>
btw: I was wondering if the DRAM content actually resets over the DRAM controller init
<apritzel>
maybe due to missing refreshs during the init phase?
<smaeul>
we don't do pad hold during dram init, so CKE won't stay low, and the DRAM won't stay in self refresh
<smaeul>
even if the DRAM was already in self refresh when DRAM init started (which it wouldn't be)
<apritzel>
and we have enough delays in the init routines to exceed the 64ms max refresh period?
<smaeul>
it's not just delay that matters -- there are clock stability requirements, the fact that we're putting garbage on the command bus, etc.
<apritzel>
yeah, I guess it's quite a stretch to hope for preservation over init
<apritzel>
but anyway we wouldn't actually need that
<apritzel>
we can just go vendor specific and define this as a core-reset, which preserves SRAM and MMIO
<apritzel>
or we could be very specific, reset everything expect CPUCFG and SRAM, then do the RMR
<apritzel>
I guess CPUIDLE doesn't allow a reset, does it?
<apritzel>
it's just off or on?
<smaeul>
off then on :)
<smaeul>
as long as you can trigger an IRQ with a delay, it'll turn the CPU back on
<apritzel>
ah, so we could trigger a timer IRQ?
<smaeul>
that should work
<smaeul>
would you want a reset type specifically for FEL? or a generic one and put the entry point in the cookie?
<apritzel>
not decided yet
<apritzel>
pure FEL reset sounds nice and confined
<smaeul>
and not a vuln
<apritzel>
exactly
<apritzel>
(or less of it, maybe)
<apritzel>
also the firmware could do the SoC specific details, like put the magic and FEL entry point in the right registers
<apritzel>
(TF-A in this case)
<apritzel>
are the CPUIDLE registers accessible from non-secure, by any chance?
<smaeul>
crust can do a complete "system domain" reset
<smaeul>
apritzel: haha no, they're in R_CPUCFG, just like the hotplug/standby registers
<apritzel>
and this part is observed, for a change, right?
<smaeul>
(where "system domain" aka VDD-SYS includes the CCU, so it includes everything with a reset line in the CCU)
<smaeul>
what is observed?
<apritzel>
yeah, for best FEL operation we should reset as much as possible
elros1 has quit [Remote host closed the connection]
<apritzel>
the secure-only accessibility of the registers
<smaeul>
right, we can't assume the clocks are set up "carefully" like U-Boot does
<apritzel>
in contrast to "secure SRAM A2"
<apritzel>
which can be accessed from non-secure (if booted without the secure fuse)
<smaeul>
depends on the SoC
<apritzel>
is there one that protects it?
<apritzel>
definitely A64 doesn't, and I believe H5 and H6 don't as well
<smaeul>
H3 I know for sure
<smaeul>
that's why you can't start crust (deassert CPUS reset bit) using /dev/mem
<apritzel>
don't care too much, H3 misses half the bits anyway :-D
<smaeul>
I'd have to try H616
<smaeul>
if TF-A is setting things up, why does it matter?
<apritzel>
I was wondering if this could be triggered easier by U-Boot
<apritzel>
U-Boot proper only, I mean
<smaeul>
oh, well if you include U-Boot SPL, you can look at the RTC registers to select a boot mode, like p-boot does
<apritzel>
mmh, true
<smaeul>
and Linux supports an easy way of configuring this (nvmem-reboot-mode)
<smaeul>
but this requires a valid boot device, whereas doing the setup before the reset does not
<apritzel>
ah, of course
<apritzel>
and the SPL loaded must support this
<apritzel>
so it wouldn't work with BSP firmware on eMMC, for instance
<apritzel>
well, that's not really a big problem, you would have needed to load mainline U-Boot somehow first for that anyway ...
<apritzel>
smaeul: btw: do you have a nice way of checking the actual code and data size consumption of TF-A? This page alignment makes it hard to assess, it either fits, or not
<apritzel>
so it's hard to say whether there are 1000, 100 or 3 bytes free in that last page
<smaeul>
`grep fill bl31.map` and sum
<smaeul>
also `make SEPARATE_CODE_AND_RODATA=0`
<apritzel>
ah, awesome!
Mangy_Dog has quit [Ping timeout: 260 seconds]
akaWolf has quit [Ping timeout: 265 seconds]
<apritzel>
oh, we waste almost 1.5KB before the vectors ...
<apritzel>
similar problem as in U-Boot: we can't really fill this gap nicely in an automatic way
<smaeul>
need a way to tell ld "fill the rest of this page with strings"
<apritzel>
yeah, or: stuff various smaller functions in there
<smaeul>
ld --sort-section=knapsack
<apritzel>
lol
<apritzel>
smaeul: so at least the SPC is RAZ/WI from non-secure on the H616
<apritzel>
do you have a table with the bits somewhere? which bits toggle which device?
<smaeul>
no, all I know is the one for NBROM/SBROM
<smaeul>
the rest you could determine experimentally, maybe without blowing any fuses (though I do have one OpiZero2 with the fuse blown)
<smaeul>
there was one manual that documented an SPC with the new register layout... let me see if I can find the one and if it has a table
apritzel has quit [Ping timeout: 268 seconds]
cnxsoft has joined #linux-sunxi
fl_0 has quit [Ping timeout: 260 seconds]
fl_0 has joined #linux-sunxi
jbrown has quit [Ping timeout: 260 seconds]
jbrown has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
buzzmarshall has quit [Remote host closed the connection]
fl__0 has joined #linux-sunxi
fl_0 has quit [*.net *.split]
ganbold has quit [*.net *.split]
tuxd3v has quit [*.net *.split]
Putti has quit [*.net *.split]
megi has quit [*.net *.split]
bantu has quit [*.net *.split]
ScrumpyJack has quit [*.net *.split]
Nemo_bis has quit [*.net *.split]
pnill has quit [*.net *.split]
xeniter has quit [*.net *.split]
xeniter has joined #linux-sunxi
bantu has joined #linux-sunxi
megi has joined #linux-sunxi
Nemo_bis has joined #linux-sunxi
ganbold has joined #linux-sunxi
Putti has joined #linux-sunxi
tuxd3v has joined #linux-sunxi
pnill has joined #linux-sunxi
ScrumpyJack has joined #linux-sunxi
apritzel has joined #linux-sunxi
hlauer has joined #linux-sunxi
apritzel has quit [Ping timeout: 252 seconds]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 265 seconds]
cnxsoft has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
cmeerw has joined #linux-sunxi
qschulz has quit [Remote host closed the connection]
qschulz has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 265 seconds]
apritzel has joined #linux-sunxi
qschulz has quit [Remote host closed the connection]
Laa[m] has quit [Quit: Idle for 30+ days]
Ke has quit [*.net *.split]
Tooniis has quit [*.net *.split]
mnemoc has quit [*.net *.split]
Tooniis has joined #linux-sunxi
Ke has joined #linux-sunxi
mnemoc has joined #linux-sunxi
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: Ping timeout: 999,999,999 years]
ldevulder has joined #linux-sunxi
jernej has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
hlauer has quit [Ping timeout: 240 seconds]
dev1990 has quit [Quit: Konversation terminated!]
jstefanop has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Changing host]
Mangy_Dog has joined #linux-sunxi
jstefanop has quit [Ping timeout: 260 seconds]
apritzel has quit [Ping timeout: 252 seconds]
jstefanop has joined #linux-sunxi
elros1 has joined #linux-sunxi
jstefanop has quit [Ping timeout: 240 seconds]
choozy has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
specing has quit [Ping timeout: 252 seconds]
specing has joined #linux-sunxi
akaWolf has joined #linux-sunxi
bauen1 has quit [Remote host closed the connection]
<gediz0x539>
MoeIcenowy: I could download the files in English. Maybe it's about default language selection?
<smaeul>
the interface was also English, which was not true earlier in the week :)
<montjoie>
exactly the same algo before, still dont understand why they persist on keeping DES/3DES
linkmauve has quit [Ping timeout: 260 seconds]
mossroy has quit [Quit: Leaving]
mossroy has joined #linux-sunxi
mossroy_ has joined #linux-sunxi
mossroy_ has quit [Remote host closed the connection]
mossroy has quit [Client Quit]
mossroy has joined #linux-sunxi
<mossroy>
Hi! I have some A64-OLinuXino-2Ge8G-IND boards, working not-so-badly with the images provided by the manufacturer (debian buster with a patched 5.10.x kernel). I'd like to install a "real" debian on them instead, through the debian-installer. Using https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/, I can install it but it is stuck on "Booting kernel..." on first start
elros1 has quit [Remote host closed the connection]
<tuxd3v>
hello guys, I was wondering if someone managed to get ap6212 working correctly, and by that I mean enforcing the regulatory database frequencies and transmission power
<tuxd3v>
I managed to get the frequency channels regulated, but not the transmission power..
<tuxd3v>
my device is transmitting at full 31 dbm, which is 20 times more than what the law parmits..
tuxillo has quit [Ping timeout: 252 seconds]
<tuxd3v>
fir what I understand we should not set 'CONFIG_CFG80211_CERTIFICATION_ONUS'
<tuxd3v>
and I have it ok..
<tuxd3v>
other than that I don't find a way to get power transmission regulated :/
<tuxd3v>
unledd by hand..
paulk-leonov has quit [Ping timeout: 276 seconds]
<mossroy>
I managed to start on the USB stick with the arm64 iso (from the url I gave). It starts but fails reading 'pool/main/d/debian-archive-keyring/debian-archive-keyring-udeb_2021.1.1_all.udeb' on step cdrom-retriever. I suppose it's a bug in this version of the ISO
<apritzel>
mossroy: on the first glance it looks like the AXP regulator driver is missing?
<mossroy>
I need to double check with a restart
<apritzel>
mossroy: what DTB was it using before?
<mossroy>
The one bundled by debian-installer, named sun50i-a64-olinuxino.dtb (with no overlay)
<apritzel>
mossroy: which is probably the one from the associated kernel, so 5.10 mainline?
<mossroy>
Yes, both are on a kernel 5.10 (but the one of olimex probably has some more patches)
jstefano_ has quit [Remote host closed the connection]
tuxd3v has quit [Ping timeout: 240 seconds]
<apritzel>
was this overlay from Debian or from Olimex?
<apritzel>
and what's there on I2C?
<mossroy>
sun50i-a64-olinuxino-2Ge8G.dtb and sun50i-a64-i2c0.dtbo are from Olimex. I copied them from the Olimex image in the boot partition made by debian-installer (next to the existing sun50i-a64-olinuxino.dtb file)
jstefanop has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: Ping timeout: 999,999,999 years]
<apritzel>
mossroy: do you have a link to those Olimex files?
<mossroy>
Maybe they are commited in one of their github repo, too
<apritzel>
mossroy: thanks, looking at them
<apritzel>
the U-Boot you use is also from this image?
<mossroy>
No, the u-boot and kernel are the ones provided by debian-installer
<apritzel>
why does everyone still has their own patches? Olimex should know better
<vagrantc>
oh, at least someone is using those images :)
<vagrantc>
or parts of them ...
<apritzel>
can someone please tell Olimex that there is no need to separate DTs with just an eMMC added?
<apritzel>
this can be well autodetected, works fine on those Pine64 boards with the eMMC socket
* vagrantc
wonders about that sometimes
<apritzel>
and some fixes look legit (like the eMMC frequency limit to 150 MHz, which got merged independently in 5.12), but it would be good to discuss this publicly, then get this merged
<apritzel>
and they could piggy back on this ongoing U-Boot approach to auto-detect extensions and applying overlays automatically
<mossroy>
Olimex is not very good on communication, but all they do is public on their github repos
<apritzel>
and I think that's the big misunderstanding about Open Source: it's not done with pushing something to your Github and pointing people to
<apritzel>
that's fine as a preliminary measure, during development
<apritzel>
mossroy: well, yes, but it rots there, and there are Olimex DTs in the mainline kernel
<apritzel>
I understand their business is product facing, but in the long run everyone would be better off with proper fixes in mainline
<mossroy>
+1 about open-source. I've had to insist a lot to make them understand we needed a changelog of their images (and that the github repos were not that changelog)
<apritzel>
mossroy: yeah, that's the dodgy fix I saw earlier
jstefanop has quit [Ping timeout: 260 seconds]
<apritzel>
I mean this whole approach is broken: they fix is *somehow*, without a real understanding, or asking for feedback from people who understand the issue
jstefanop has joined #linux-sunxi
tuxd3v has joined #linux-sunxi
<apritzel>
smaeul: in case you feel brave enough to deal with this nasty A64 timer bug again ^^^^
<apritzel>
apparently there is an issue with ondemand governor in connection to the workaround
<mossroy>
yes, that's why they forced the governor to performance in latest images (and even disabled the ondemand governor)
<apritzel>
which is a hack
<mossroy>
Sure
<apritzel>
and there are people out there willing to help, they just need to know about it
<apritzel>
and no, Github issues and forums are not the way this is done in Linux
<apritzel>
I think Olimex boards see a lot of more serious users, that's why any error reports are very valuable
<apritzel>
mossroy: sorry, this is not against you, btw.
<mossroy>
apritzel: I know, don't worry :-)
<apritzel>
oh, right, I wanted to mount that image ... ;-)
jstefanop has quit [Remote host closed the connection]
<mossroy>
It looks like they did not submit or discuss this much with you, from what you say?
<apritzel>
not that I am aware of (but I don't read all the lists)
<apritzel>
and they don't need to provide fixes for everything, reports and testing are very important and useful too
<apritzel>
especially if people have a lot of hardware at hand, and do some testing anyway
<mossroy>
Would you like me to suggest them a kind of meeting with you (and/or other linux-sunxi members) to find a way to better cooperate?
<mossroy>
(I could attend it, too, if people wish)
<apritzel>
I think I met some of them before, as FOSDEMs
jstefanop has joined #linux-sunxi
<mossroy>
You probably saw in the posts I made in their forum that I was sometimes disappointed by their communication and testing. But they are truly open-source and open-hardware promoters
<apritzel>
the solution is simple: please send bug reports and issues to the mainline people: as found in /MAINTAINERS under the "ARM/Allwinner sunXi SoC support" entry
<apritzel>
wow, the A64 Olinuxino mainline DTS still has phy-mode = "rgmii"; (or are they the rare exception which actually needs that?)
<mossroy>
Sorry, where is this "ARM/Allwinner sunXi SoC support" entry?
<mossroy>
So my board starts (not all the time, but it might be because of my SD-card : I'll test with another one). A "reboot" command nevers works anyway
<mossroy>
In any case, it's a huge progress : many thanks for your hints
<apritzel>
mossroy: thanks for trying the official Debian installer!
<mossroy>
It's becoming late, I'll get some sleep but will try to come back in the following days
<apritzel>
sure, sorry, didn't want to keep you up
jstefanop has joined #linux-sunxi
<mossroy>
I'd love Olimex and linux-sunxi teams to better cooperate : I'd be pleased to help on that if I can
jstein has quit [Ping timeout: 240 seconds]
mossroy has quit [Quit: Leaving]
jstefanop has quit [Ping timeout: 265 seconds]
jstefanop has joined #linux-sunxi
cmeerw has quit [Ping timeout: 276 seconds]
<smaeul>
apritzel: the issue with cpufreq when using the "wrong" (freescale) workaround is entirely expected
<apritzel>
smaeul: you mean comparing old and new?
<smaeul>
the pll_cpux rate change notifier reparents the CPU to osc24m, which means one tick == one cycle
<smaeul>
yes, so the workaround which requires the same value returned twice is never going to succeed, and will time out
<apritzel>
yeah, right!
<smaeul>
and delays are used in the reparenting code
<apritzel>
the question is just why they changed your better approach
<smaeul>
because my approach does not catch 100% of cases, apparently
<apritzel>
which would be good to hear about ...
<apritzel>
I think we had the one odd report about this before, right?
<apritzel>
smaeul: so the discussion fizzled out, and MoeIcenowy's patch was never applied?
<smaeul>
right
<apritzel>
so they are actually two issues, right? One is that the A64 timer bug workaround is not perfect, and the other is the CPU clock switching requires switching to OSC24M
<apritzel>
and only hack-fixing the A64 timer workaround exposes the reparenting problem
<smaeul>
well, the reparenting is problematic regardless, due to the performance hit
<smaeul>
and the reparenting is itself only a workaround
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
<apritzel>
right, so changing just that would be good anyway, but wouldn't fix the occasional time jump
<apritzel>
but it would allow us to use a more "Freescale like" workaround instead