<smaeul>
apritzel: I have four reasons for caring about secure boot. 1) so I can boot boards which are already in secure mode. I have 5 of these now, the 4 I mentioned in the patch series, plus the A50 tablet which was shipped that way
<smaeul>
2) supporting firmware (TEE) and driver development and testing when the security hardware is fully enabled. this is sort of an extension of #1
<smaeul>
in other words, try not to write ourselves into a corner where secure mode means breaking changes everywhere
<smaeul>
3) taking advantage of the larger or non-existent TOC0 image size limit, to allow growing SPL, p-boot, etc.
<smaeul>
4) verified boot. while the H6/H616 are vulnerable to stack smashing, the A64/H5 SBROMs do have a TOC0 size limit (0x20000). maybe the SBROMs are all broken, but I have reservations about throwing the whole thing out
<smaeul>
(and people would be more inclined to play with secure boot if it didn't mean sacrificing a board)
<smaeul>
those are roughly in order of importance -- I have something like $150 worth of hardware tied up by #1 :D
ftg has quit [Read error: Connection reset by peer]
<apritzel>
smaeul: yeah, I agree, I just wanted to avoid that we develop something "just because"
<apritzel>
and this A50 tablet being shipped "secure" is a good point
<apritzel>
as long as there are device shipped this way, we have enough reasons to support this
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has quit [Ping timeout: 480 seconds]
<jernej>
smaeul: but 3) doesn't help much if unsecured is supported
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cmeerw has joined #linux-sunxi
vagrantc has joined #linux-sunxi
vagrantc has quit []
<gamiee>
jernej: yes, but I found some things which are not listed in register info on sunxi wiki (I added a few) + I wanted to know more how the encoding process works, so I'm reversing the blobs from scratch
cmeerw has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
diego71_ has joined #linux-sunxi
diego71_ has quit []
tnovotny has joined #linux-sunxi
tnovotny has quit []
prefixcactus has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme_ has joined #linux-sunxi
<warpme_>
guys: i'm looking on wifi in tanix-tx6s (h616) box and see 2 references to gpio (i think) to enable power and probably for interrupt:
<warpme_>
it is possible to translate wlan_regon line to DT gpio operation declared with semantic used by mainline DT?
<apritzel>
warpme_: that would be PE18 and PE15, but I found those references in the BSP DT very unreliable
<apritzel>
in some cases I found the same GPIO assigned to two different devices
<warpme_>
apritzel: how you will read line "wlan_hostwake"? In many mainline DT's is it usually interrupt used by wifi. looking on tx6s android /proc/interrupts i see:
<warpme_>
so do you think 'wlan_hostwake' is about wifi interrupt or rather i.e. gpio for wifi reset?
<apritzel>
it's a GPIO configured to trigger an interrupt
<warpme_>
ah ok. good. so i'm concluding tx6s needs only power_on gpio mangling (to turn power on wifi) + interrupt for wifi. let me propose DT to test this....
choozy has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<apritzel>
warpme_: so the Tanix TX6s comes with an already supported WiFi chip?
<apritzel>
warpme_: can you take some pictures from the back and side connectors and upload to the Wiki?
<apritzel>
and fix that bold claim of "USB 3.0" in there (which I guess is just there because it's a blue socket)
tnovotny has joined #linux-sunxi
<warpme_>
apritzel: my tx6s variant has xr919 and it seems armbian has driver for this crappy chip (afaik armbian goes with this code: https://github.com/karabek/xradio ) btw: if any of armbian users can confirm this driver works on 5.12/5.13 - would be great!. I have another box with xr819 where karabek driver loads but fails with io operations on firmware reading....
<warpme_>
apritzel: re. pictures: sure i'll do.
<warpme_>
xr919->xr819
<warpme_>
this another xr819 box is tx6-mini (h6 based)
arti has quit [Quit: arti]
arti has joined #linux-sunxi
ndufresne has quit [Quit: Ping timeout (120 seconds)]
tuxd3v has quit [synthon.oftc.net charon.oftc.net]
prefixcactus has quit [synthon.oftc.net charon.oftc.net]
Mangy_Dog has quit [synthon.oftc.net charon.oftc.net]
arti has quit [synthon.oftc.net charon.oftc.net]
insep has quit [synthon.oftc.net charon.oftc.net]
montjoie_ has quit [synthon.oftc.net charon.oftc.net]
Nemo_bis has quit [synthon.oftc.net charon.oftc.net]
pg12 has quit [synthon.oftc.net charon.oftc.net]
zumbi has quit [synthon.oftc.net charon.oftc.net]
tnovotny has quit [synthon.oftc.net charon.oftc.net]
diego71 has quit [synthon.oftc.net charon.oftc.net]
PPA has quit [synthon.oftc.net charon.oftc.net]
mripard has quit [synthon.oftc.net charon.oftc.net]
jernej has quit [synthon.oftc.net charon.oftc.net]
matteoscordino has quit [synthon.oftc.net charon.oftc.net]
libv has quit [synthon.oftc.net charon.oftc.net]
obbardc has quit [synthon.oftc.net charon.oftc.net]
hallyn has quit [synthon.oftc.net charon.oftc.net]
oliv3r has quit [synthon.oftc.net charon.oftc.net]
plaes has quit [synthon.oftc.net charon.oftc.net]
milek7 has quit [synthon.oftc.net charon.oftc.net]
jemk has quit [synthon.oftc.net charon.oftc.net]
choozy has quit [synthon.oftc.net charon.oftc.net]
juri_ has quit [synthon.oftc.net charon.oftc.net]
jelly has quit [synthon.oftc.net charon.oftc.net]
gediz0x539 has quit [synthon.oftc.net charon.oftc.net]
megi has quit [synthon.oftc.net charon.oftc.net]
pmp-p has quit [synthon.oftc.net charon.oftc.net]
gamiee has quit [synthon.oftc.net charon.oftc.net]
bantu_ has quit [synthon.oftc.net charon.oftc.net]
psydroid has quit [synthon.oftc.net charon.oftc.net]
kayterina[m] has quit [synthon.oftc.net charon.oftc.net]
Tooniis[m] has quit [synthon.oftc.net charon.oftc.net]
dittid[m] has quit [synthon.oftc.net charon.oftc.net]
maz has quit [synthon.oftc.net charon.oftc.net]
apritzel has quit [synthon.oftc.net charon.oftc.net]
gsz has quit [synthon.oftc.net charon.oftc.net]
indy has quit [synthon.oftc.net charon.oftc.net]
hramrach has quit [synthon.oftc.net charon.oftc.net]
vpeter has quit [synthon.oftc.net charon.oftc.net]
heap01_ has quit [synthon.oftc.net charon.oftc.net]
ats has quit [synthon.oftc.net charon.oftc.net]
akanouras has quit [synthon.oftc.net charon.oftc.net]
Esmil has quit [synthon.oftc.net charon.oftc.net]
rellla has quit [synthon.oftc.net charon.oftc.net]
narmstrong has quit [synthon.oftc.net charon.oftc.net]
<warpme_>
apritzel: fyi: looking on Opi-zero2 DT and android's tx6s DT wifi fragment is the same. so this tells me wiring of wifi might be quite the same. so - looking on Opi-zero2 schematics - i see: 1\wifi power is hard-wired to aldo2; 2\wifi has wl_reg_on wired to PG18. At 11:44AM (by interpreting dt i provied) you mention regon is PE18. I went with PG18 and xr819 driver started to load :-)
<warpme_>
but probe segfaults :-(. Good is that this wifi dt fragment should also be valid for Opi-zero2 wifi (uwe5622) and tx6s variants with ap6330 i hope
<warpme_>
is there anybody with FriendlyARM NanoPi DUO or Orange Pi Zero or Sunvell R69 and armbian? Those boxes have also xr819. I want to verify is karabek driver working ok on 5.13 mainline.
<karlp>
I never got one to work any more htan probing and wifi scan
<karlp>
it might scan and might _maybe- connect once or twice, but it was beyond worthless.
<karlp>
I have a opi zero here somewhere.
<gamiee>
warpme_ : I have Orange pi Zero, but it's broken (probably broken coil) :(
<warpme_>
karlp: do you remember what kernel/OS was when you were playing with this crappy xr819?
<karlp>
an older armbian
<karlp>
I don't expect it to have changed.
<karlp>
by all accounts the vew people potentially competent enough to work on it got very burnt out by the rudeness of people demanding proper drivers for it.
<karlp>
which looks like last meaningful commits were 2013 by solomon peachy.
cmeerw has joined #linux-sunxi
<apritzel>
karlp: what do you mean with "last meaningful commit"? for the cw1200 driver? I see some fixes and updates lately, some of them indeed from tree-wide clean ups, but not all of them
<karlp>
most of them seem to be just refactorings in mac80211?
<apritzel>
well, but this means that it's kept up-to-date, right?
<karlp>
sure, but doesn't mean it's anymore functional
<karlp>
maintained in a perfect state of not-really-working...
<apritzel>
how do you know?
<jernej>
why do you think so?
<jernej>
XR819 has different SDIO ID
<karlp>
well, yes, the cw1200 might work, the xr819 is suspected to be rebadged. I've no idea if the cw1200 actualyl works well, I doubt it's very common hardware
<apritzel>
in an ideal world this is exactly what you would hope for: a driver working, and just being updated to match refactorings and changes in the framework
<karlp>
indeed, but drivers being in tree doesn't mean they're fully functional, unfortunately, much as we might believe in ivory towers...
<apritzel>
but this is all pure speculation?
<jernej>
maybe not fully functional, but functional enough to be useful
<karlp>
speculation on the part of the cw1200 yes.
<karlp>
but burnt enough on other "rare" drivers to no longer assume...
<jernej>
I wouldn't dare to speculate on things I have zero experience
<karlp>
well, the internet's wonderful. I'm not going to try any driver soup on the xr819.
<warpme_>
jernej: apritzel: quick Q about nogo on h616 above 1,3HGz. I have 2 boxes with h616 and behaviour is exactly the same: enabling 1.5GHz in opp makes box totally unstable with random panics in kenrel. Isn't this issue happens because pmic dcdcb works on common load with dcdca - but is not enabled by dt? looking on dt i see we are touching only dcdca. what about dcdcb in dt?
ftg has joined #linux-sunxi
<jernej>
polyphase should be enabled via GPIOs by board designer
<jernej>
if this is enabled, dcdcb register is ignored
<warpme_>
jernej: ...and i understand this is not case now in 2 boards i have?
<apritzel>
doesn't the OPi-Zero2 schematic hint at DCDCB being totally unused?
<warpme_>
in my v1.3 - no
<warpme_>
pls look on p8
<apritzel>
pls look at p3
<apritzel>
;-)
<apritzel>
and mind the "RESERVED" and "NC" markings on DCDCB
<warpme_>
ough - p3 is for sure blind copy done by secretary of mr.designer.....
<apritzel>
the whole thing is ...
prefixcactus has quit [Ping timeout: 480 seconds]
<jernej>
only way to know for sure is to read PMIC register and check if polyphase is configured or not
<apritzel>
exactly
<jernej>
you can do that with debugfs (/sys/kernel/debug/regmap/...)
<warpme_>
so what i need to do with peakpoke? :-p
<jernej>
nothing, unless you want to drive RSB manually :)
<jernej>
*if
<jernej>
use debugfs as I suggested above
<warpme_>
ah ok - forgot pmic is communicated via rsb
<apritzel>
tbh I wrote peekpoke to be able to talk via RSB to the AXP(803), hence all those wait commands ...
<apritzel>
... which suggests no polyphase, supported by PHSET being wired to GND in the schematic
tnovotny has quit []
<warpme_>
so.....is it strategy of programmed crippling hw to create differentiation of member in products-line? (ie. "we will move 0R resistor from rp8 to rp9"; this will make "new product"; "new" product magically start to be overclockable; we will ask price up by 10$; as we are selling to whole world - we will get extra bilions of $$) kidding.....
<jernej>
karlp: quick driver comparison suggest that cw1200 driver doesn't support FW uploading mode suitable for XR819
<apritzel>
you are projecting far too much intention in those things ...
<jernej>
(yet)
<jernej>
warpme_: you can change that register manually (also over regmap debugfs), but if HW is not wired correctly, it won't help anything
<warpme_>
seriously: can't believe grounded PHSET is overlook - effectively making zeropi2 and tx6s false spec (both says cpu@1,5 iirc) while our hypothesis tells they will never go with 1.5GHz due too low current supply from pmic. Maybe polyphase mode can be turn-on by reg?
<jernej>
read what I wrote again
<jernej>
and note that there can be other factors for instability
<jernej>
IIRC once there was an issue with PLL configuration
<warpme_>
jernej: what register is to play with polyphase?
<jernej>
check datasheet, I don't know from top of my head
<warpme_>
ah ok
<jernej>
apritzel: did you test mmc1 on H616? for some reason it's not instantiated, I see only mm0 and mmc2 in dmesg
<apritzel>
jernej: I don't remember exactly, maybe not, on my boards there is nothing to see there anyway (read: AW859A)
<jernej>
well, you could at least see driver loading
<jernej>
I mean bus scan
<jernej>
apritzel: what about X96? maybe something more interesting?
<jernej>
ah, bug in DT, as usual
<jernej>
board DT, that is
choozy has joined #linux-sunxi
<apritzel>
jernej: X96 has the same crappy chip :-(
cmeerw has quit [Ping timeout: 480 seconds]
<warpme_>
jernej: re mmc1: fyi: for me it started to appear at all only when i correctly applied power to periph. (wifi) connected to mmc1. before this - no matter what - no single entry in dmesg about mmc1....
<warpme_>
jernej: what h616 box you have?
<jernej>
yeah, power was the issue
<jernej>
I have T95 with xr819
<warpme_>
ough.....
<warpme_>
iirc armbian goes with https://github.com/karabek/xradio and i wasn't able to find anything more fresh that this for xr819.....
<jernej>
apritzel: yes, but only 3 GiB of RAM actually used
<apritzel>
even thought the MMC DMA can actually do 34 bit PAs, we still keep the DMA mask to 32 bit
<apritzel>
but if your box is limited anyway ...
<apritzel>
(I was just wondering if some incoming buffer (from the network layer?) was beyond 4GB, but you don't have memory there ...)
<apritzel>
wait, that address doesn't look like a PA at all (with bit 47 set)
<apritzel>
probably some DMA framework usage problem?
<jernej>
maybe, very strange problem...
<apritzel>
the address itself (minus bit 47) looks reasonable
<apritzel>
but mapping only 4 bytes looks a bit off
<arnd>
jernej: apritzel: bit 47 could mean a vmalloc or module .data address got passed in
<apritzel>
yeah, but this should be a dma_addr_t anyway, not sure how a VA pointer could sneak in there
choozy has quit [Ping timeout: 480 seconds]
<arnd>
apritzel: I mean a vmalloc address passed into dma_map_sg(): virt_to_bus adds 0x1.0000.0000.0000 to the kernel virtual address to convert it from the 0xffff.0000.0000.0000 range to the 0-based bus address
<arnd>
vmalloc space starts at 0xffff800000000000, so adding the virt offset gets you to 0x8000.0000.0000
<arnd>
this can happen if a kmalloc() gets changed to vmalloc()/kvmalloc(), or if a driver accidentally passes a pointer to a global variable, which would (mostly) work for a built-in driver, but not a loadable module
<arnd>
apritzel: jernej: __cw1200_reg_read_32() passes a pointer to an on-stack variable named __tmp
<jernej>
yeah, I just wanted to say that
<arnd>
this fails when CONFIG_VMAP_STACK is set
<jernej>
can I just disable it?
<arnd>
and it may cause random stack corruption otherwise because of the cache maintenance
<arnd>
jernej: maybe ask ulfh (mmc maintainer) about whether this should be allowed for sdio devices or not
<arnd>
it probably should not, in which case the correct fix is to change __cw1200_reg_{read,write}_{16,32}() to kmalloc() a temporary buffer instead of using the on-stack variable
<jernej>
ok, thanks! I'll change the code for now
<arnd>
jernej: if this works, can you send the patch for the driver Cc:Ulf Hansson <ulf.hansson@linaro.org>, Arnd Bergmann <arnd@arndb.de> so we can discuss whether that is the correct fix?
<jernej>
arnd: sure, but my simple approach may be too simple
<arnd>
It's fairly clear that there has to be a kmalloc(), but maybe that should be in the sdio core instead of the driver for the sdio device
gsz has quit []
<jernej>
arnd: thanks, it works now. But code is ugly: http://ix.io/3qMO Should I just send it as-is, to start discussion?
<arnd>
jernej: that line in drivers/net/wireless/st/cw1200/cw1200_sdio.c doesn't belong into the patch, right?
<arnd>
the rest is pretty much what I expected, yes, so please post that as an RFC
<jernej>
right
<apritzel>
arnd, thanks for the explanation!
<apritzel>
and this one line in cw1200_sdio.c is the reason jernej is doing this ;-)
<apritzel>
jernej: looks ugly enough to motivate people to find a better solution
<jernej>
I hope so :)
<jernej>
interestingly, xr819 driver has another mode of operation, called ETF (no idea what it stands for)
<jernej>
it loads different FW and uses different ops
<jernej>
ops -> commands
<jernej>
maybe this is source of issues
<jernej>
since it's enabled unconditionally in all versions of the driver
<arnd>
do you mean the xr819 works with an otherwise unmodified cw1200 driver? I think I read in the past that the drivers were related, but I had not expected them to be compatible enough
<arnd>
is this originally an ste design, or did they just license it from a third party?
<jernej>
I have no idea
<jernej>
some modifications of cw1200 driver will be needed for sure
<jernej>
for example, FW upload is not supported for this variant
<jernej>
actually, bootloader needs to be uploaded first
<jernej>
I'm just looking how far I can get with minimal changes