NiteHawk has quit [Remote host closed the connection]
rex_victor has joined #linux-sunxi
<apritzel>
ha, fun fact: the OrangePi Zero 2 exposes some MMC2 pins on the headers, enough (CLK, CMD, DAT0) to connect an SD card with a single data line
NiteHawk has joined #linux-sunxi
<apritzel>
as expected, not really fast, but I get exactly the expected speed (5.6 MB/s)
<apritzel>
surely enough for data logging or some slow storage (should be even enough for a normal 4K video stream)
robogoat has quit [Ping timeout: 272 seconds]
rex_victor has quit [Ping timeout: 260 seconds]
apritzel has quit [Ping timeout: 246 seconds]
Mangy_Dog has quit [Ping timeout: 264 seconds]
kaspter has joined #linux-sunxi
lkcl has quit [Ping timeout: 256 seconds]
<wens>
montjoie: I take it you want this enabled so it gets tested through kernelci?
hexdump0815 has quit [Ping timeout: 245 seconds]
victhor has quit [Ping timeout: 256 seconds]
lkcl has joined #linux-sunxi
zoobab has quit [Ping timeout: 272 seconds]
zoobab has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cnxsoft1 has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
faruk has joined #linux-sunxi
faruk has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
mcf_ has joined #linux-sunxi
mcf has quit [Ping timeout: 260 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
TheSeven has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
Putti has quit [Remote host closed the connection]
Putti has joined #linux-sunxi
rtp has quit [Ping timeout: 260 seconds]
rtp has joined #linux-sunxi
mcf_ is now known as mcf
<gediz0x539>
does crypto engine provide an entropy source to accelerate the process of creating ssh keys?
<gediz0x539>
if it does, how much should i expect from in terms of performance. using A13 btw.
<gediz0x539>
compared to some tools like gkernel-rngd
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 258 seconds]
<montjoie>
wens: it is both for testing and for being smart with users
lkcl has quit [Ping timeout: 256 seconds]
reinforce has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus has joined #linux-sunxi
camus is now known as kaspter
JohnDoe_71Rus has joined #linux-sunxi
lkcl has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
asdf28 has joined #linux-sunxi
cmeerw has joined #linux-sunxi
<montjoie>
gediz0x539: on A13 you have the sun4i-ss PRNG
cmeerw has quit [Ping timeout: 272 seconds]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus is now known as kaspter
lkcl has quit [Ping timeout: 256 seconds]
tnovotny has joined #linux-sunxi
lkcl has joined #linux-sunxi
<mripard>
montjoie: I wasn't cc'd on that defconfig patch
lkcl has quit [Ping timeout: 272 seconds]
<gediz0x539>
montjoie: oh, okay then. thanks.
dev1990 has joined #linux-sunxi
lkcl has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
netlynx has joined #linux-sunxi
<montjoie>
mripard: will resend in that case
lkcl has joined #linux-sunxi
<mripard>
we're in the middle of the merge window, there's no rush to send it before rc1
yann has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
victhor has joined #linux-sunxi
lkcl has quit [Ping timeout: 264 seconds]
apritzel has joined #linux-sunxi
lkcl has joined #linux-sunxi
azend has quit [Ping timeout: 246 seconds]
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 240 seconds]
ldevulder_ is now known as ldevulder
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
lucascastro has quit [Ping timeout: 265 seconds]
lucascastro has joined #linux-sunxi
lucascastro has quit [Ping timeout: 256 seconds]
<willmore>
apritzel, I'm impressed that the MMC driver even supports single pin mode.
<karlp>
well, spi mode right?
<karlp>
uhs allowed cards to stop supporting it iirc.
<karlp>
and the pins are probably on the header for spi, not for "mmc2" ?
<apritzel>
karlp: no, it's not SPI mode (that would be much slower)
lucascastro has joined #linux-sunxi
<karlp>
are those pins shared with a spi peripheral?
<karlp>
what I mewant was, I don't beleive they put a single pin mmc interface on pin headers for people to mount sd card slots...
<apritzel>
willmore: it's just two bits in register SMHC_CTYPE (offset 0xc) to select the bus width
<apritzel>
karlp: I don't know if they did this on purpose
<karlp>
the drvier should most certainly support 1,2,4 bit wide, I'd be more suprised if it ididn't .)
<apritzel>
indeed
<apritzel>
IIRC 1 bit is mandatory, you use that initially to negotiate wider bus width
<apritzel>
and it works pretty nicely but just putting bus-width = <1>; in the DT
<karlp>
they explicitly talk about having a SPI periph available on the pin headers, I expect it's just that
<willmore>
apritzel, I was curious how you told the driver how wide the bus was. karlp is probably right in that the SPI and mmc probably share the same pins--they're pretty darn similar after all.
<willmore>
Try it? :) Does the SoC generate the 1.8V internally (odd) or is there an output to control a regulator? And if you're using a PMIC, how does all that signalling happen?
lucascastro has quit [Ping timeout: 272 seconds]
<apritzel>
actually I am about to do this. The manuals of the A64 and H6 at least claim to support 1.8V on the pads
<apritzel>
but PortF is VCC_IO, which can be hardly be anything else than 3.3V
ganbold has joined #linux-sunxi
<apritzel>
there *might* be an internal regulator just for the PortF pads (similar to what SD cards do: they can switch their pad voltage on command and generate the 1.8V internally)
* willmore
is curious how this turns out.
<apritzel>
actually during the H616 bringup I accidentally had the base PERIPH PLL wrong (twice as high), and I saw SD speeds of about 45 MB/s
<apritzel>
still with normal 3.3V signalling, and officially with SD high speed mode
<apritzel>
just that the clock wasn't 50 MHz as per the spec, but 100 MHz
<apritzel>
and I find some sources that say that UHS-I DDR50 also works with 3.3V signalling
rex_victor has joined #linux-sunxi
<willmore>
Though it's not officially supported and the card is allowed to brick itself if you do it.
<apritzel>
I don't think this is really dangerous, unless you actually claim to switch the voltage and then don't do it
<apritzel>
(which you wouldn't do)
<willmore>
I thought the switch to 1.8V was part of the 'switch to UHS mode' command.
<apritzel>
for the card, yes
<apritzel>
scratch that, the voltage switch is a separate CMD
<willmore>
k
<apritzel>
you request it first via ACMD41, then execute it via CMD11
<MoeIcenowy>
PortC does not support in-chip voltage select
<MoeIcenowy>
but you can do select by altering VCC-PC manually
<MoeIcenowy>
BTW many eMMC cards will just work under fixed 1.8V VCC-PC
<MoeIcenowy>
apritzel: BTW the V831 SoC (and H616 should be the same) have vcc-io and vcc18-io pins
<MoeIcenowy>
and vcc-pf can be switched internally between these vcc*-io
<apritzel>
MoeIcenowy: yeah, I saw that after your email yesterday
kaspter has quit [Quit: kaspter]
<apritzel>
for the older SoCs you can only switch the whole of VCC-IO, but H616 adds just PortF
<apritzel>
I was still wondering how the older SoCs could claim 1.8V pads in the manual
<apritzel>
ah, they actually don't for MMC0 (H6 says 1.8V pads only for MMC1 and MMC2, the other don't specify a certain controller, and probably rely on switch whole port voltage supplies)
lucascastro has joined #linux-sunxi
<apritzel>
anyway, as soon as I execute CMD11 (with bit 28 set), communication stops
<apritzel>
at least cards and SoC are still working ;-)
<apritzel>
(that is on the A64)
<apritzel>
MoeIcenowy: where did you find vcc18-io? I only see VCC-PLL in the datasheet, but I guess that has the same effect (a 1.8V supply)
<apritzel>
wens: MoeIcenowy: is anyone looking at this PortF switch regulator code already? Sounds not too complicated to have something like regulator-gpio, but using that new PIO register bit instead of an GPIO
<smaeul>
apritzel: re TF-A: I was planning to rework some of the common code to add a 32-bit SP_MIN port, but I guess that can wait for your patches
<wens>
apritzel: not me.
<apritzel>
smaeul: yeah, I will review and +1 your patches today, then rebase my H616 port on top
<apritzel>
smaeul: and I guess you aim at the H3, so that's pure ARMv7? (there are some subtleties with the EL semantic if you reset an ARMv8 core into AArch32, as Allwinner does)
gaston1980 has joined #linux-sunxi
t3st3r has quit [Remote host closed the connection]
t3st3r has joined #linux-sunxi
fl_0 has quit [Ping timeout: 272 seconds]
fl_0 has joined #linux-sunxi
t3st3r has quit [Read error: Connection reset by peer]
t3st3r has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
gaston1980 has quit [Quit: Konversation terminated!]
<wens>
so confusing :|
<apritzel>
wens: I know :-(
cmeerw has joined #linux-sunxi
<apritzel>
wens: wait till you hear that EL3 in AArch32 looks like secure SVC, but secure EL1/AArch32 is also secure SVC. BUT it's not the same state ...
<apritzel>
I call it job security :-D
lkcl has joined #linux-sunxi
<MoeIcenowy>
apritzel: for V831 I have a schematics
<MoeIcenowy>
and for PIO exporting a regulator, I still wonder whether this is appropriate (although it's simple, right)
<apritzel>
MoeIcenowy: well, we could handle it in sunxi_mmc_card_power(), but would still need access to the PIO MMIO region (via a regmap?)
<mripard>
I don't see why we wouldn't use a regulator
<apritzel>
MoeIcenowy: what are your concerns regarding the PIO exported regulator? To me that sounds like the right thing to do ...
<mripard>
it's the proper abstraction and it's handled by the framework already
asdf28 has quit [Ping timeout: 256 seconds]
<apritzel>
agreed
asdf28 has joined #linux-sunxi
andy25225 has quit [Ping timeout: 240 seconds]
andy25225 has joined #linux-sunxi
lucascastro has quit [Ping timeout: 246 seconds]
<MoeIcenowy>
apritzel: well, okay
<apritzel>
MoeIcenowy: it was a serious question, happy to hear about any issues
<MoeIcenowy>
from coding view, I also think it's good
<MoeIcenowy>
I was just trying to think critically