<smaeul>
we need some flag to mkimage to allow smaller padding, or else there will be 8K of zeroes in SRAM for one instruction
<apritzel>
smaeul: yeah, this padding is annoying, I think it's just needed for raw NAND (yikes)
<apritzel>
boy, you are sitting on tons of patches, aren't you?
<smaeul>
yeah, though the H3 changes are still very much WIP
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #linux-sunxi
kaspter has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 260 seconds]
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-sunxi
MartijnBraam has quit [Ping timeout: 268 seconds]
Jeremy_Rand_DT[m has quit [Ping timeout: 268 seconds]
Jeremy_Rand_DT[m has joined #linux-sunxi
MartijnBraam has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
victhor has quit [Ping timeout: 260 seconds]
kevans91 has quit [Ping timeout: 246 seconds]
kevans91 has joined #linux-sunxi
random_yanek has quit [Ping timeout: 272 seconds]
kevans91 has quit [Ping timeout: 256 seconds]
kevans91 has joined #linux-sunxi
lkcl has quit [Ping timeout: 265 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri_ is now known as ChriChri
ChriChri has quit [Ping timeout: 246 seconds]
random_yanek has joined #linux-sunxi
lkcl has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
kevans91 has quit [Remote host closed the connection]
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #linux-sunxi
kevans91 has joined #linux-sunxi
lkcl has quit [Ping timeout: 265 seconds]
lkcl has joined #linux-sunxi
asdf28 has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
alexxy has quit [Ping timeout: 260 seconds]
reinforce has joined #linux-sunxi
cmeerw has joined #linux-sunxi
cmeerw has quit [Ping timeout: 260 seconds]
AneoX has joined #linux-sunxi
alexxy has joined #linux-sunxi
apritzel has joined #linux-sunxi
chewitt_ is now known as chewitt
JohnDoe_71Rus has joined #linux-sunxi
apritzel has quit [Ping timeout: 268 seconds]
tnovotny has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
warpme_ has joined #linux-sunxi
mahoux has quit [Quit: Idle for 30+ days]
damex has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 260 seconds]
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
apritzel has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
camus is now known as kaspter
stoupaxyz has joined #linux-sunxi
stoupaxyz has quit [Remote host closed the connection]
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 260 seconds]
victhor has joined #linux-sunxi
ldevulder_ is now known as ldevulder
<apritzel>
... aaaand another 50% MMC performance uplift, just by allowing HS200 (@150 MHz) in the DT
<apritzel>
hdparm reports 120 MB/s instead of 80 MB/s
damex has joined #linux-sunxi
<apritzel>
both on H6 and A64
Mangy_Dog has joined #linux-sunxi
<gediz0x539>
that's great news
<libv>
montjoie: i went through something similar for the fosdem video-hw changes
<mripard>
apritzel: yeah, it looks like we never merged the DT bits to enable it, even though the driver has supported it for years
<libv>
montjoie: pure bisect is indeed not the answer, and it is not fun, but not impossible
<apritzel>
mripard: and for once the manual is right, 150 MHz is the limit: with 200 MHz I get tons of I/O errors
<apritzel>
mripard: I will send DT update after the merge window
<mripard>
apritzel: yeah, I know
<mripard>
it took me quite some time to figure out why it wasn't working :)
<apritzel>
mripard: btw: the default max frequency in the driver is 52 MHz, should that be lifted there, or do we keep this entirely to the DT?
<mripard>
MMC0 and MMC1 have a limit at 150MHz, and the MMC2 at 200MHz
<mripard>
so we'll need the DT anyway
<apritzel>
I originally just enabled HS200, and the driver chose it, but at 52MHz, which was slower than DDR50
<mripard>
and given the current state of the modes in the driver, I'd be inclined to not have something too smart in the driver and just go along wit hthe DT there
<mripard>
yeah, HS200 is SDR
<apritzel>
mripard: yes, makes sense, just wanted to double check
<apritzel>
and btw: the failing 200MHZ was on MMC2 (A64), the manual lists 150MHz as a limit for all controllers, at least in the H6 and H616
<mripard>
hmmm
<mripard>
that's weird
<mripard>
I'm fairly sure I had mmc2 running in HS200 at 200MHz on the A64
<apritzel>
mripard: I guess it could be considered overclocking: might depend on the traces and the connection
<apritzel>
I ran it on the Pine64-LTS, which has a socketed eMMC (that's surely not helping for high speed parallel connections)
<karlp>
there's nothing wrong with sockets if they're designed for it.
<apritzel>
karlp: you said it: "designed for it"
<apritzel>
this is some connector Hardkernel came up with years ago, they published their design, and Pine64 picked that up (after some advice from us)
<ElBarto>
apritzel: mripard: I know that kibab@freebsd never managed to have mmc2 working at 200Mhz on FreeBSD or Linux when he added support for it for us
<ElBarto>
he didn't understood if he made any mistake in freebsd and decided to test on linux
<ElBarto>
I did bang my head on this problem a lot too
<ElBarto>
the mode switch command always result in an error iirc
<apritzel>
karlp: so that's not the the kind of carefully designed, tested and certified connector like PCIe
<ElBarto>
but this was also on a pine64-lts
<apritzel>
ElBarto: and that was at 200MHz, because that's what the spec says?
<ElBarto>
yup
<apritzel>
it seems like AW eventually admitted the issue by putting the limit in the manual ;-)
<ElBarto>
does the manual really state that 150mhz is the limit ?
<apritzel>
in the H6 and H616 manuals
<apritzel>
no word in H5 or A64 manuals
<ElBarto>
ah ok
<karlp>
apritzel: cmon, what? have you got evidence that the connector is unsuitable? or jsut "omg, its not a pcie socket" ?
<ElBarto>
that's why I didn't find it then :)
<apritzel>
karlp: I don't have any evidence, and was just saying: "it's not helping". If the connection was dodgy already to begin with, then adding a connector won't improve things
<apritzel>
karlp: and I wanted to find why it worked for mripard, who probably used a different board with a soldered down eMMC BGA
<ElBarto>
I think that the only A64 board with soldered eMMC that I have is the olinuxino and vccq is fixed at 3.3V iirc
<apritzel>
ElBarto: the BananaPi M64 has eMMC as well
<ElBarto>
mhm, don't remember if I have this one, too many boards here :)
<apritzel>
but it's only an 8GB chip, those typically have limits in the speed of the memory array
<apritzel>
can do more tests later tonight
<apritzel>
I figured the other day we are missing an "eMMC" category in the Wiki. Anyone?
faruk has joined #linux-sunxi
<libv>
apritzel: it's a wiki, go for it :)
<apritzel>
libv: not sure about you, but it's 24 hours per day here ;-)
<libv>
apritzel: same as everyone else
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
<apritzel>
karlp: willmore: btw: I am now fairly confident that we cannot use UHS-1 SD speed modes on existing SoCs (before the H616), because of missing 1.8V support
<apritzel>
the voltage for PortF is VCC-IO, which is shared among other ports (and even internally in the SoC)
<apritzel>
the H6 actually requires VCC-IO to be 3.3V
<apritzel>
the A64 allows 1.8 and 2.5 V there as well (for the whole of VCC-IO), but I doubt there is a board out there allowing this
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
<apritzel>
ElBarto: can you try to figure out if limiting MMC to 150MHz works on FreeBSD (and/or ping kibab)?
<apritzel>
ElBarto: For me just adding a "max-frequency" property in the DT did the trick, that overrides the driver defined limit, at least in Linux
<willmore>
apritzel, thank you for all your work trying this.
<willmore>
But, I will say that the connector that HK chose for the eMMC is very much good at high frequencies. I've seen it used in microwave radio applications for RF connections. It's a controlled impedence connector like you'd want for high speed applications. That said, a poorly designed board or eMMC module makes that pretty much moot.
<willmore>
I trust HK did their work to design their board and modules, but I don't have that kind of faith in other board makers. :)
<karlp>
^^ (it's not the connector)
<apritzel>
I didn't want to question the work of Hardkernel engineers, my experience with those SBC vendors lets me assume the worst, though
<apritzel>
I consider them mostly toys, tbh
<KotCzarny>
educational toys!
<willmore>
HK's layout person Rupi Kim is a magician.
<apritzel>
all fair enough, but the module socket was apparently introduced with the Odroid-U2 in 2012, and the SoC on this does not seem to support HS-200
<apritzel>
(but actually I fail to understand what we are actually arguing about ...)
<karlp>
I was questioning your assertion that you should instantly blame the connector as a source of problems.
<apritzel>
I didn't blame the connector, I was merely pointing out that my board uses a connector, which *might* impose further limits
<apritzel>
and that also implies that I use some eMMC module of unknown quality
<apritzel>
I mean half of the boards here don't properly reset into FEL due to various hardware design issue, so my trust in properly dealing with "radio MMC" is somewhat limited
<apritzel>
I didn't mean to blame the connector or its idea itself, it's the whole bells and whistles attached to having a connector in the first place
<willmore>
That I can agree with.
<willmore>
Routing high speed lines on a PCB is no trivial task and is very easy to get wrong if you don't have experience with it. I once laid out a mixed digital/analog/RF board and it was a nightmare. Probably would have been easier with better tools, but I didn't have them.
gaston1980 has joined #linux-sunxi
kaspter has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
zhovner has quit [Ping timeout: 260 seconds]
Mangy_Dog has quit [Ping timeout: 268 seconds]
<montjoie>
a ha ha ah ah CE is always giving me data len error on H6 for RSA, so lets start a brute force of all possible len
lurchi__ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 264 seconds]
cmeerw 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
popolon has joined #linux-sunxi
<apritzel>
mripard: wens: it seems like newer kernels now go all over the place when it comes to MMC numbering, I sometimes get SD card as mmcblk2 and eMMC as mmcblk0
<apritzel>
what's the position on having mmc<x> aliases in the DT to avoid this?
<apritzel>
I see it's not a problem for distributions with initrds, but for my monolithic test kernels it's a pain ...
<mripard>
Rob has been against it since pretty much forever, with good reasons
<mripard>
but mmc maintainers went ahead and still merged it this release
<mripard>
and there's an ongoing discussion about it
<apritzel>
mripard, I see, thanks for the heads up
<mripard>
and in our case I guess using aliases would make things worse