Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
bugzc has joined #linux-sunxi
bugzc has quit [Changing host]
bugzc has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
arossdotme has quit [Ping timeout: 245 seconds]
yann-kaelig has quit [Client Quit]
terra854 has joined #linux-sunxi
mzki has quit [Quit: leaving]
libv_ has joined #linux-sunxi
jernej_ has quit [Ping timeout: 268 seconds]
libv has quit [Ping timeout: 264 seconds]
IgorPec has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
IgorPec has joined #linux-sunxi
orly_owl has joined #linux-sunxi
Colani1210 has joined #linux-sunxi
Colani1200 has quit [Ping timeout: 256 seconds]
Ntemis has quit [Remote host closed the connection]
Gerwin_J has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 250 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 245 seconds]
perr has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 244 seconds]
KotCzarny has joined #linux-sunxi
ninolein has quit [Ping timeout: 245 seconds]
ninolein has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
terra854 has quit [Quit: Connection closed for inactivity]
lynxis has joined #linux-sunxi
terra854 has joined #linux-sunxi
pg12 has quit [Ping timeout: 260 seconds]
pg12_ has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
arossdotme has joined #linux-sunxi
TheSeven has quit [Ping timeout: 245 seconds]
TheSeven has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
Putti has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
f0xx has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
IgorPec has joined #linux-sunxi
reinforce has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
Putti has joined #linux-sunxi
jernej_ has joined #linux-sunxi
<KotCzarny> i must say raspberry is apple of sbc world
<KotCzarny> (looking at i2s prices on the list comparing to the same products on aliexpress)
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
<wens> :p
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
Putti has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
<KotCzarny> and if anyone is interested that es9023 sabre is on promo in one store (8usd, free shipping)
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
jernej_ has quit [Ping timeout: 260 seconds]
<KotCzarny> hmm, is there any way to flash/convert to plain img for livesuit images?
<KotCzarny> this has some work started but seems old and abandoned
whaf has quit [Quit: Leaving.]
Putti has joined #linux-sunxi
premoboss has joined #linux-sunxi
premoboss has quit [Ping timeout: 250 seconds]
perr has quit [Ping timeout: 252 seconds]
Nacho has quit [Ping timeout: 246 seconds]
ericxdu has quit [Remote host closed the connection]
<wens> beeble: can i cc you on a patch enabling pull-ups for mmc?
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
ericxdu has joined #linux-sunxi
massi has joined #linux-sunxi
havoc_ has quit [Ping timeout: 260 seconds]
Putti has quit [Ping timeout: 265 seconds]
havoc_ has joined #linux-sunxi
<jelle> KotCzarny: oh hmm i2c supposed to be better then jack?
<jelle> *i2s
<miasma> onboard jack? probably depends a lot on the board quality
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
<jelle> oh silly me, I have an usb plug ofcourse
<jelle> well i2s would mean a smaller case, and no usb overhead
<KotCzarny> jelle, its digital, so you can take it away from the board (comparing to the builtin audio)
<KotCzarny> also, it doesnt use up the usb port
<jelle> KotCzarny: I'll have to check now if the C.H.I.P. has it
IgorPec has joined #linux-sunxi
<jelle> ah no i2s
<KotCzarny> yeah, a13 apparently has no i2s
lemonzest has joined #linux-sunxi
<jelle> KotCzarny: weird, A10 has it and the GR8
fvogt has joined #linux-sunxi
<miasma> i've bought boards with enough usb ports and used usb dacs. seem to work, but otoh i only use $1000 headphones and $4000 speakers. $5 ebay dacs are good enough for me
<jelle> haha
<KotCzarny> :)
<jelle> KotCzarny: but the c.h.i.p. pro has it but that doesn't have a nice battery charger
<KotCzarny> im going to use it with a20
<mripard> jelle: it has the same battery charger than the CHIP
<KotCzarny> mripard s/than/as/ ?
<jelle> mripard: ah yes I see the pins
<jelle> btw, does anyone else have ethernet issues for the H3 with u-boot? I think the 'in progress' part can be removed since it worked on my orange pi h3 devices https://linux-sunxi.org/Mainline_U-boot
<jelle> can't test A83T/A64 though
iamfrankenstein1 has joined #linux-sunxi
<mripard> KotCzarny: yes
Putti has joined #linux-sunxi
tkaiser has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
<longsleep> tkaiser: thanks!
<tkaiser> longsleep: But at least in germany it should be available through distributors soon. I would check with ALLNET first.
<longsleep> tkaiser: yes, lets see what the price will be in EURO :)
<miasma> so is sinovoip now the official bpi vendor? not lemaker?
alexxei has quit [Ping timeout: 246 seconds]
<tkaiser> miasma: It's easy but even more complicated ;)
<tkaiser> miasma: Foxconn orders a design, Xunlong does it as ODM, then SinoVoip does manufacturing and scaring customers away (look into that banana forum) and LeMaker is out of the game since approx a year now
<KotCzarny> xunlong still does odm for bananas? o.O
<wens> dunno
<miasma> at least the sinovoip can't compete with prices against xunlong
<wens> miasma: foxconn claims they have higher hardware QA standards
<tkaiser> KotCzarny: No one knows. But the differences between BPi M3 and M2 Ultra and M64 now are eligible
Putti has quit [Ping timeout: 268 seconds]
diego_r has joined #linux-sunxi
<tkaiser> longsleep: And this one http://wiki.friendlyarm.com/wiki/index.php/NanoPi_A64/zh should be available through jacob.de (2017)
iamfrankenstein has quit [Read error: Connection reset by peer]
<longsleep> tkaiser: interesting thanks
iamfrankenstein1 has quit [Read error: Connection reset by peer]
<jelle> hmm everyone makes A64 boards these days
<longsleep> but nobody one with 3GB RAM .. :/
iamfrankenstein has joined #linux-sunxi
<miasma> didn't 32-bit SoCs like h3 support up to 2GB too
<tkaiser> longsleep: But I don't know whether GbE will be available and fear that it will be prone to overheating. And now with H5 (internal Fast Ethernet PHY) it doesn't make that much sense to use A64 at all unless battery is needed?
<longsleep> tkaiser: yes, but i do not care much about the SoC itself, just arm64, GbE and 2GB+ RAM :)
<longsleep> tkaiser: and it should be very cheap and small
<tkaiser> I wonder whether the '3 GB max' can only be achieved with 12 Gb DRAM modules or also by combining 2 x 4 Gb + 2 x 8 Gb...
<KotCzarny> longsleep: i guess you should wait for xunlong's 2gb offering then?
<longsleep> KotCzarny: yes, i certainly will look into that one once the details are available
<tkaiser> longsleep: Same size and connector positions as with http://linux-sunxi.org/Orange_Pi_Plus_2E -- not that small but most probably showing good heat dissipation.
premoboss has joined #linux-sunxi
berenm has quit [Quit: berenm]
<beeble> wens: sure, even if i'm not sure if i qualify :)
bugzc has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 260 seconds]
whaf has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<wens> beeble: i did a clean up of PSCI, and now i get CC-ed on all U-boot PSCI patches
<wens> beeble: i don't think i'm qualified either :)
<NiteHawk> wens: patman loves you :)
<wens> NiteHawk: what's that?
<KotCzarny> maybe short from 'patch manager'
<NiteHawk> exactly. it's a tool within u-boot that helps with automated patch submission - and it likes to CC people that have touched portions of the code ;)
Pepe has joined #linux-sunxi
<montjoie> like getmaintainer.pl for linux
<wens> NiteHawk: didn't know u-boot had this, thx
<KotCzarny> might be also a tiny bot that likes to pat men
<jelle> but u-boot also has get_maintainer.pl
<zoobab> @tkaiser "brute-force attempt" <- love the approach
apritzel has joined #linux-sunxi
<tkaiser> zoobab: But testing was useless, with H5 BSP kernel in its current state you get 940 MBits/sec in RX direction after applying the usual tunables but are stuck at 500 Mbits/sec in the other direction. I think first the tons of patches longsleep did to A64 BSP kernel need to be applied there too.
scelestic has joined #linux-sunxi
<zoobab> the difference is due to those length tunings?
<Net147> I wonder if the Mali X11 blobs can be made to work on fbdev by writing a shim library...
apritzel has quit [Read error: Connection reset by peer]
<tkaiser> zoobab: Nope, I tested through 0-7 TX delay and 0-31 RX delay in all variations and it's basically always the same. And in TX direction it seems to be CPU bound (or IRQ handling).
<Net147> at least it would be simpler to have a single Mali blob that works with both X11 and fbdev
<buZz> Net147: fbcp exists
<tkaiser> zoobab: IIRC with Pine64 it was similar in the beginning and improved then 'over time'. But 'over time' the kernel has also been patched up from 3.10.65 to 3.10.104 ;)
<Net147> buZz: that just seems to copy framebuffers...
<Net147> buZz: I was thinking a shim that pretends to be X11 so you don't need X11 server at all
<KotCzarny> or well.. you know, get the source?
<tkaiser> zoobab: And replacing the kernel with those from latest Xunlong 'server image' greatly decreased network speed. I put the board back into the drawer now :)
<KotCzarny> tkaiser: when are you getting r40 board?
<tkaiser> KotCzarny: As soon as Xunlong does the one from my wishlist ;)
<KotCzarny> not risking the banana?
<tkaiser> KotCzarny: No way
<buZz> Net147: well the output of mali moves to fb, doesnt it?
<KotCzarny> :)
<buZz> Net147: i -think- the r6 mali drivers can do direct to fb
<Net147> buZz: any idea how?
<buZz> i mean the binary driver thats now supplied with the 'CHIP's image
<buZz> it appears it just ignores X all together
<Net147> buZz: last time I tried it, it handles X windowing and requires X to be running
<buZz> well last night it didnt
<buZz> are you sure you use r6 version of the driver? cause thats pretty new
<Net147> buZz: I am using r6p0 on A20
<buZz> hmm
<buZz> maybe its just the setup on CHIP then
<mripard> buZz: the setup on the CHIP uses X.
<buZz> ah guess i'm confused by the lack of DRM
<buZz> nevermind :)
apritzel has joined #linux-sunxi
terra854 has joined #linux-sunxi
perr has quit [Quit: Leaving]
lkcl has joined #linux-sunxi
<mripard> and it has DRM
<mripard> but we already had that discussion :)
alexxei has joined #linux-sunxi
<buZz> yeah but not used for mali :)
Putti has joined #linux-sunxi
<scelestic> i'm trying to figure out mainline kernel support for H3, it seems the only things missing (for me) would be THS and emac, emac i can find recent versions but THS seems to link to a patch dated november 2015, anyone know if this really is the latest?
<tkaiser> scelestic: https://github.com/megous/linux
<jonkerj> take the orange-pi-4.9 branch
<scelestic> thanks
<tkaiser> jonkerj: Do you get thermal readouts with this branch?
<tkaiser> jonkerj: I mean query SoC temperature through sysfs?
<jonkerj> on 4.8 I got those
<jonkerj> 4.9 seems to have issues irt NFS
<jonkerj> (and I rely on that)
<tkaiser> jonkerj: ok, since I tried 4.9 and everything works except of this (so cpufreq scaling --> ok, throttling --> no)
<jonkerj> I had both on 4.7/4.8 with megi's patches on Orange Pi Plus and ~PC
<jonkerj> using cpuburn the temperature rose, max freq was lowered, voltage too
<tkaiser> jonkerj: With 4.6 and 4.7 everything was ok. Seems i should give 4.8 a try and drop megi a note
<jonkerj> when I quit cpuburn, freq raised and voltage too
<jonkerj> but on 4.9 the kernel oopses when I mount NFS
<jonkerj> only when DVFS is enabled
<wens> the new GPADC driver should be easy to port to H3
<wens> is it merged yet? i kinda lost track
<mripard> it wasn't
<mripard> and qschulz has some patches to make it standalone too
<wens> there were so many versions that i kinda just tuned out
petr has quit [Ping timeout: 244 seconds]
petr has joined #linux-sunxi
<mripard> yes, I know...
<mripard> it would have been too easy to have a driver split and written properly
<mripard> so we chose to have that DT ABI to have something convoluted instead
Putti has quit [Ping timeout: 256 seconds]
Putti has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
Putti has quit [Ping timeout: 258 seconds]
<MoeIcenowy> mripard: I think my issue will be reproducible on many A33 devices
<MoeIcenowy> maybe you'd try it on your SinA33/Parrot?
whaf has quit [Quit: Leaving.]
whaf has joined #linux-sunxi
berenm has joined #linux-sunxi
f0xx has joined #linux-sunxi
berenm has quit [Client Quit]
montjoie has quit [Ping timeout: 244 seconds]
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
mpmc has quit [Ping timeout: 246 seconds]
mpmc has joined #linux-sunxi
Pepe has joined #linux-sunxi
montjoie has joined #linux-sunxi
* jski throws a rubber duck at his imlicit declaration of function that makes no sense
Putti has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
JohnDoe71rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
terra854 has quit [Quit: Connection closed for inactivity]
Putti has quit [Ping timeout: 260 seconds]
Putti has joined #linux-sunxi
paulk-minnie has quit [Quit: Leaving]
premoboss has quit [Ping timeout: 245 seconds]
premoboss has joined #linux-sunxi
montjoie has quit [Ping timeout: 248 seconds]
<mripard> MoeIcenowy: not in the upcoming days / weeks
premoboss has quit [Ping timeout: 256 seconds]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe71rus has quit [Ping timeout: 244 seconds]
alexvf has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
Gerwin_J has quit [Quit: Gerwin_J]
terra854 has joined #linux-sunxi
ErwinH has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<Net147> mripard: any progress on HDMI?
<ErwinH> tkaiser: I was looking at the code you linked, and noticed a difference in the dtsi files between branch 4.7 and 4.8/4.9 for sun8i-h3, maybe that's the reason why the THS doesn't work anymore?
<mripard> Net147: yes, but nothing working at the moment
montjoie has joined #linux-sunxi
<Net147> mripard: I2C driver for EDID + EDID parsing?
<mripard> that works
<mripard> but it's basically the only thing that does
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
tkaiser has joined #linux-sunxi
<tkaiser> miasma: Was it you who were interested in 'suspend consumption' yesterday?
IgorPec has quit [Ping timeout: 248 seconds]
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
Pepe has joined #linux-sunxi
apritzel has left #linux-sunxi [#linux-sunxi]
premoboss has joined #linux-sunxi
victhor__ has joined #linux-sunxi
scream has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
IgorPec has joined #linux-sunxi
cnxsoft has quit [Client Quit]
<tkaiser> Anyway, just tried it out with OPi PC 2 and BSP u-boot/kernel: http://pastebin.com/FfkbYjba -- consumption now is +700 mW which is not that great.
<tkaiser> But I fear I use still wrong DT settings. The Xunlong guy is still pretty busy fiddling around with DT and added the necessary fix to 'wake up' the board now with power key just yesterday. And the kernel I use does not even contain that feature so I have to restart anyway now.
Nacho__ has joined #linux-sunxi
enrico__ has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
premoboss has quit [Ping timeout: 240 seconds]
Pepe has joined #linux-sunxi
<jelle> :P
f0xx has quit [Ping timeout: 260 seconds]
theone has quit [Ping timeout: 258 seconds]
<miasma> tkaiser: ok that doesn't sound too great.
theone has joined #linux-sunxi
<tkaiser> miasma: True, but maybe just settings aren't ok now. My powermeter showed 0.3W (PSU included) when I did tests with OPi PC. Which would translate to less than 250 mW in this mode.
popolon has joined #linux-sunxi
yann-kaelig has quit [Quit: Leaving]
<miasma> tkaiser: it still sounds like the whole SoC is on but the clock rate is just lower? even 0.3W is quite a lot if it's just a simple mcu or something similar
<tkaiser> miasma: Don't know exactly. But I just remembered that we had to build the kernel with CONFIG_SUNXI_GPIO_KEY=y to be able to wake up with the button defined in [gpio_power_key] section (PL03 on all H3 devices). No idea whether ARISC can take over and wait for PL03 to wake up A7 cores.
mzki has joined #linux-sunxi
mzki has quit [Client Quit]
mzki has joined #linux-sunxi
<tkaiser> OTOH this whole design is meant for OTT TV boxes. Dimming the backlight of the 40" screen nearby by 1% has probably way more influence on overall consumption than standby mode of the OTT box
<miasma> tkaiser: i get < 100 mW idle power consumption with a esp8266 (160 MHz, 32b single core) controlled solid state relay :) it has a full wifi stack and listents to ethernet packets
JohnDoe_71Rus has joined #linux-sunxi
<tkaiser> miasma: Sure, the ESP8266 is not a OTT box ;) And as already said: I doubt Xunlong's current OPi PC 2 settings match reality yet.
<MoeIcenowy> mripard: I thought that there's some clock change
<MoeIcenowy> then I checked the clock
<MoeIcenowy> I used the clk_dump json file in /sys/kernel/debug/clk
<MoeIcenowy> Then I found that the position of lcd-ch0 changed
f0xx has joined #linux-sunxi
<MoeIcenowy> reg1 is working, reg3 is not working
jernej_ has joined #linux-sunxi
<ssvb> tkaiser: ARISC can use GPIO just fine, the ar100-info project has everything that is necessary
<ssvb> I'm not sure about IRQ handling though, nobody has tried this yet
victhor__ has quit [Ping timeout: 256 seconds]
<ssvb> ARISC can handle its own interrupts just fine (the timer, the unknown instruction trap, etc.), but I don't know how to configure handling of the interrupts from GPIO
<ssvb> naturally, you don't want to be just polling the PL03 pin if you care about power consumption
<tkaiser> ssvb: Is Allwinner's ARISC stuff open or blobs?
<ssvb> the allwinner stuff is a blob
afaerber has joined #linux-sunxi
<ssvb> it can be disassembled though, and megous did that when investigating how to implement dvfs - https://github.com/megous/h3-ar100-firmware-decompiler
lamer14793951358 has joined #linux-sunxi
<ssvb> if you want to compile your own ARISC firmware from sources, then you can use https://github.com/skristiansson/ar100-info/
reinforce has quit [Quit: Leaving.]
tkaiser has quit [Ping timeout: 265 seconds]
lamer14793951358 has quit [Client Quit]
tkaiser has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
<tkaiser> ssvb: I neither want nor can. But it's interesting, especially the idea to run only on the OpenRISC core in ultra low-power mode and only activate the ARM cores on demand :)
afaerber has quit [Ping timeout: 245 seconds]
<KotCzarny> yeah
afaerber has joined #linux-sunxi
<ssvb> tkaiser: well, everything is already there, and you only need an OpenRISC toolchain to compile it
<KotCzarny> i wonder if in that mode power consumption would be comparable to esp8266 and friends
<KotCzarny> ssvb: how does it look from the dev side? is it c-like compiler or more like assembly?
<KotCzarny> is there simple libc?
<tkaiser> ssvb: We should suggest this to Brian Benchoff from HaD to write something about (this one is the Allwinner basher) ;)
<ssvb> KotCzarny: it's just a GCC compiler with newlib as a standard C library
<KotCzarny> curious.
<KotCzarny> and you have all dram available or limited to something builtin openrisc core?
<ssvb> have a look at https://linux-sunxi.org/AR100
<KotCzarny> pretty slow for writing any bigger app, hum (ie. audio player)
<ssvb> why would you want a bigger app there?
<ssvb> however allwinner seems to have some sort of audio handling there there :)
<KotCzarny> well, audio feedback/mic recorder?
<ssvb> it probably makes sense to have a low power mp3 decoder running on the openrisc core, while the arm cores are sleeping
<MoeIcenowy> mripard: yes, it's a ccu issue -- I temporary disabled pll-mipi as a parent of lcd-ch0, and the switch works properly...
<wens> MoeIcenowy: it'l likely the pll has gone way beyond the working limits
<MoeIcenowy> wens: you mean that pll-mipi failed to work here?
<wens> i have plans to add 'hardware constraints' to the CCU driver
<MoeIcenowy> and generates no clock output?
<MoeIcenowy> I think for RGB/LVDS output, pll-mipi is not necessary
matthias_bgg has quit [Quit: Leaving]
<wens> MoeIcenowy: it's just a possible parent, the CCU is free to switch around
matthias_bgg has joined #linux-sunxi
<wens> we just need to tell it that there may be certain contraints on the clock rate
<mripard> I don't know why it's taking that decision though
<MoeIcenowy> wens: ccu itself will choose the best?
<MoeIcenowy> mripard: of course we shouldn't remove the parent
<wens> MoeIcenowy: can you dump /sys/kernel/debug/clk/clk_summary for both when it works and when it doesn't?
<MoeIcenowy> I will only use it as a temporary workaround for me.
<mripard> MoeIcenowy: that's not really what I'm saying :)
<MoeIcenowy> wens: https://pastebin.anthonos.org/view/17a10bdb (but it's clk_dump, not clk_summary, and it's a diff
<wens> mripard: probably pll-mipi can deliver a closer clock rate
<mripard> MoeIcenowy: what puzzles me is that it calls twice the clk_set_rate function, and comes up with two different parents and rates
<KotCzarny> ssvb, btw. how to app running on it, can it write to uart?
<MoeIcenowy> mripard: yes I also wonder why they are clocked differently
<MoeIcenowy> I will check the clock now (I patched ccu, entered system, stopped X, and TCON got restarted
<MoeIcenowy> and TCON works now
<zoobab> @ssvb this AR100 core is another core then the ARM cores on H3?
<wens> MoeIcenowy: can you do a full dump?
<MoeIcenowy> wens: yes
<MoeIcenowy> do you want both the working one and not-working one?
<wens> both
<wens> thx
<miasma> KotCzarny: in esp8266 most of the power consumption comes from wifi. the idle consumption with radio of is like 15 mW
<miasma> *off
<mripard> MoeIcenowy: thanks for looking into that :)
<miasma> it seems AR100 is a lot lower powered
<MoeIcenowy> I suddenly thought about clocks :-)
<MoeIcenowy> it's some kind of inspiration :-)
<MoeIcenowy> I will firstly revert my tcon changes (as the real reason is in ccu)
<MoeIcenowy> maybe the reason why mripard didn't discover this issue is that he's not using a 800x480 screen :-)
The_Loko has joined #linux-sunxi
f0xx has quit [Ping timeout: 250 seconds]
simosx has joined #linux-sunxi
<MoeIcenowy> wens, mripard: https://pastebin.anthonos.org/view/e0342504 , in which "patched" means patched ccu (removed pll-mipi parent), "vanilla" means ccu in 4.9-rc; "before" means before bug-triggering (which works), "after" means after bug-triggering (which doesn't work with vanilla ccu)
<wens> MoeIcenowy: possible, another likely reason is that fex file timings already have the dot clock rounded to MHz
<wens> MoeIcenowy: whereas you and i are using some 800x480 panel we dug up from panel-simple, and also need the 5% tolerance patch :)
<MoeIcenowy> yes
<wens> the tolerance lets you use the panel, but because of the clock rate granularity mismatch, it may try to use pll-mipi instead
<MoeIcenowy> But I think pll-mipi should theortically also be usable, right>
<MoeIcenowy> ?
<wens> it should, yes
<MoeIcenowy> the problem is only that it's not capable of outputing such a clock?
<wens> it should, yeah
vagrantc has joined #linux-sunxi
<MoeIcenowy> wens: how can you fix this point of ccu?
<wens> i'm digging through allwinner's kernel
<wens> suprise suprise
<wens> * surprise
<jelle> that's a lot of suprises
<MoeIcenowy> what's surprise?
<wens> allwinner's kernel also sets bits 22 and 23 when enabling pll-mipi
<wens> those bits are labeled "LDO{1,2}_EN" in A23 and A31 manuals
<MoeIcenowy> also in A33 manuals
<wens> MoeIcenowy: so, can you change the 'gate' part to BIT(31) | BIT(23) | BIT(22) and test again?
<MoeIcenowy> ok
IgorPec has joined #linux-sunxi
<wens> and if it works, please send a patch :)
<MoeIcenowy> is it clean enough as a fix?
<wens> what do you mean?
<MoeIcenowy> just add the LDO bits into clock gate
<wens> MoeIcenowy: why not? just document it properly
tkaiser has quit [Ping timeout: 260 seconds]
<wens> you can say that pll-mipi didn't seem to be running, and after some comparison, found that allwinner's kernel enabled those 2 bits as well
tkaiser has joined #linux-sunxi
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<MoeIcenowy> wens: ok
<MoeIcenowy> this time the clock works properly under pll-mipi
<MoeIcenowy> wens: should I add it for A23/31?
<MoeIcenowy> I only found the LDO enable code for A33
<wens> i guess you should
<wens> at least my A23 doesn't work, though i haven't dug into it :|
<MoeIcenowy> I will submit only A33 at v1 patch
<ssvb> KotCzarny: Yes, the ar100-info application uses UART for output. And I'm going to be awfully rude, but all the information about the OpenRISC core had been already documented. Just read it rather than asking questions.
* jbrown perks up -- hmm? Is there an Allwinner thing with an OpenRISC core on it?
<rellla> 4 days left to the 4th anniversary of the first mainline commit :p
<MoeIcenowy> rellla: congrats!
jernej_ has quit [Quit: Konversation terminated!]
<rellla> not mine :) sunxi's
<MoeIcenowy> oh also congrats to sunxi!
Pepe has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
<MoeIcenowy> wens: I think you should check your failure, and check whether the lcd-ch0 clock's parent is set to pll-mipi when your tcon fails to start
<wens> MoeIcenowy: yeah, need to find time to do that
<wens> MoeIcenowy: one of your tablets uses lvds?
<MoeIcenowy> could you also test it on your A31s board?
<MoeIcenowy> wens: yes, an A33 one.
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<MoeIcenowy> the tablet is already mainlined by me
<wens> the sinlinx lcd is 1024x768
<wens> (i think)
<wens> no, 1024x600
<MoeIcenowy> I remembered it's 1024x600
<wens> anyway i didn't have issues with it with the panel i picked
<MoeIcenowy> but my 10" LVDS A33 is 1024x768
<wens> i did have some trouble with the VGA output on my A31 hummingbird
<MoeIcenowy> I think what mripard used to test A33 drm is also Sinlinx LCD, right?
<wens> yup, but he used the timings from the fex file
<wens> MoeIcenowy: do you know if those tablets are still available?
<MoeIcenowy> you mean my LVDS 1024x768 tablet?
<wens> yes
reinforce has joined #linux-sunxi
<MoeIcenowy> A variant of this tablet is, Onda V975s Quad Core v7
<MoeIcenowy> (only v7 is A33)
<MoeIcenowy> (other versions are A31)
<MoeIcenowy> (but they share the same LCD)
<MoeIcenowy> (the variant uses USB Wi-Fi, not SDIO Wi-Fi as my tablet)
<wens> really hard to find allwinner tablets on taobao now
<MoeIcenowy> yes
<MoeIcenowy> mediatek is occuping the market
fvogt has quit [Quit: Konversation terminated!]
<zoobab> really?
<zoobab> which mediatek chip? Mediatek is horrible when it comes to GPL code publication
<tkaiser> zoobab: Which is exactly what the average tablet buyer is thinking about all the time ;)
<zoobab> you mean my mom?
<zoobab> I was hacking SOCs for routers when one of my routers showed up in a German court for the first case of GPL enforcement :-)
<zoobab> 17 apr 2004 - GPL testing in court by the Netfilter/Iptables team, due to refuse to give source code of the Sitecom WL-122 (isl3893 based!). In the same time, some source code has appeared on the webserver of Sitecom.
<MoeIcenowy> yes usual tablet users do not care about GPL ;-)
<MoeIcenowy> they only care about that MediaTek tablets come with integrated baseband
<zoobab> nice to have
<MoeIcenowy> but allwinner cannot make basebands
<zoobab> they have to add another chip
<MoeIcenowy> to be honest I got interested into some Uniscom tablets
<zoobab> which might lead to higher prices
<MoeIcenowy> they *claims* to have A33 SoC, 2G RAM, high-quality IPS screen
<MoeIcenowy> oh I broke the TF card in my A33 tablet when disassebling it, and it cannot work at all now...
<ssvb> MoeIcenowy: A33 only has 16-bit DRAM bus width, the performance will be horrible if you use it with a good high resolution screen
<MoeIcenowy> (Finally I know why in movies the spies will try to chew up the TF card, as thus it's really difficult to restore it
<MoeIcenowy> ssvb: but it claims to be dual-channel...
<ssvb> I believe that A13, A23 and A33 have been designed for cheap 800x480 LCD screens, where the memory bandwidth does not matter much
<ssvb> are you sure about dual-channel?
<MoeIcenowy> not so sure
<MoeIcenowy> A33 is now not only a 800x480 chip... it is now the main tablet chip of Allwinner
<ssvb> the manual says "Support 16-bit single-channel DDR3/DDR3L SDRAM"
<ssvb> 1024x600 is probably also OK
<ssvb> what about the A64 tablets?
<MoeIcenowy> yes I'm wrong :-(
<MoeIcenowy> ssvb: at least I cannot find A64 ones on Taobao
<MoeIcenowy> maybe someday I should go to Shenzhen to seek one in Huaqiang North
montjoie has quit [Ping timeout: 260 seconds]
<MoeIcenowy> in 11.11 an A83T tablet by Onda is on sale in only ¥399 (~$70)
<tkaiser> Didn't Allwinner try to position A64/A83T as 'hybrids' now? Like Azpen Hybrx?
<MoeIcenowy> maybe it's the target of H
<MoeIcenowy> although H64 is really A64 (the same chipid)
<MoeIcenowy> H8 is very very like A83T (although chipid is different)
montjoie has joined #linux-sunxi
<MoeIcenowy> I'm wondering whether there's any V3/V3s development boards...
<Pepe> but Azpen Hybrx for early bird backers had good price for all components..
<MoeIcenowy> several days ago a link to V3s datasheet/user manual is present in this channel
<tkaiser> Pepe: Did you had a look at the display?
<MoeIcenowy> allwinner's live is also difficult now :-)
<Pepe> No, just images what they provide to their campaign.
<tkaiser> MoeIcenowy: V3s has 64 MB DRAM integrated. And people want more than 2 GB on dev boards ;)
<MoeIcenowy> ;-)
<MoeIcenowy> I have only one devborad with 2G RAM :-( (Pine64+ 2GB ver)
<tkaiser> Pepe: Something I would want to work with should have a display where I can look into more than 10 minutes without getting headache ;)
<MoeIcenowy> the second popular version of devboard is that which has a smaller RAM amount (256MB/512MB) but is very small in size
<tkaiser> MoeIcenowy: s/size/price/
<MoeIcenowy> e.g. Raspberry Pi Zero, Nano Pi NEO {,AIR}, Orange Pi Zero
<MoeIcenowy> I really mean size
<Pepe> I see your point. I agree with you, but I don't have this issue, so I'm clear XD
<MoeIcenowy> although the size-limited boards are also price-limited
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy> OK I think I can provide a full stable 3D acceleration stack on A33 Q8 800x480 tablets when 4.9 is out
<tkaiser> Pepe: I thought about buying the Azpen to use it as Linux laptop. But then Pine64 LCD arrived which reminded me how cheap LCDs look like.
<MoeIcenowy> some allwinner tablets come with acceptable LCDs, for example, my iNet D978 Rev02-based A33 tablet
<MoeIcenowy> it's a 10" 1024x768 LVDS, very good quality, can be used to do long-time read
<MoeIcenowy> (but the tablet is expensive in A33 world -- ¥460 even in Huaqiang North)
<MoeIcenowy> ok mripard's xf86-video-armsoc fork have still some issues... will try to fix them
<MoeIcenowy> and try to mainline sun4i part to xf86-video-armsoc
IgorPec has joined #linux-sunxi
<tkaiser> terra854: Do you read IRC logs?
gzamboni has joined #linux-sunxi
premoboss has joined #linux-sunxi
<terra854> tkaiser: Not always. Why?
<tkaiser> terra854: Since you could make a lot of Pine64 users happy: https://irclog.whitequark.org/linux-sunxi/2016-11-16#18192536;
<tkaiser> terra854: The 'not waking up after sleep' issue with Linux BSP kernel on Pine64 is most probably none.
<terra854> tkaiser: none?
<TheLinuxBug> I think he meant 'one'
<tkaiser> terra854: wakeup sources have to be configured. And the power button needs a driver to be treated as a 'key', then it needs a definition in DT and then you can send the board to sleep and it wakes up at the press of a (the) button
<tkaiser> Maybe this driver is simply missing. No idea, never tested but it should work since... it's a BSP kernel made for tablets
utente_ has joined #linux-sunxi
<terra854> tkaiser: So basically this patch will let the attached power button act like those power/lock buttons on typical Android phones?
premoboss has quit [Ping timeout: 256 seconds]
<tkaiser> terra854: But I've no idea whether this is directly transferrable to A64. But since it works with Android it *has* to work with Linux BSP kernel right out of the box too. Don't believe this BS some stubborn old men tell over there that hardware only works with Android (LCD for example) ;)
whaf has quit [Quit: Leaving.]
whaf has joined #linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
utente__ has joined #linux-sunxi
<terra854> tkaiser: Oh I get it, so it allows someone to boot the device via power button on the IR remote?
<terra854> tkaiser: tbh, i am kind of confused on what that patch does
utente_ has quit [Ping timeout: 240 seconds]
<tkaiser> terra854: I don't know really whether it can be applied (since 'wakeup from IR remote' is more of an OTT box thing). But at least every basic stuff like sleep/suspend that originates from Android should work with BSP kernel in Linux too.
<terra854> tkaiser: Do we need any patches to uboot for the "wake on ir or power button" feature?
<tkaiser> terra854: That would only be required to 'power on' the Pine64 via power key or ir remote. To wake from sleep only kernel functionality should be needed.
cptG_ has joined #linux-sunxi
enrico__ has quit [Quit: Bye]
cptG has quit [Ping timeout: 250 seconds]
<terra854> tkaiser: So with the patch, it allows the Pine to do what the sleep command on Windows does?
f0xx has joined #linux-sunxi
massi has quit [Quit: Leaving]
<tkaiser> terra854: Windows? No idea. This patch enables the power button as 'key'. On H3 devices this key will then be mapped to PL03 or let's better say there are 'wakeup_src' settings defined like here: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepipc.fex#L141-L142
<tkaiser> And this has happened then a H3 board wakes up from sleep. But only if the kernel also has this sunxi gpio key setting enabled. Maybe it's just that.
<tkaiser> In longsleep's DT WiFi and BT wakeup_src is also defined as PL03/PL06: https://github.com/longsleep/build-pine64-image/blob/master/blobs/pine64.dts#L3101
<tkaiser> So maybe all that's missing is definition of the power key to match PL03 as the said patch does: https://github.com/OrangePiLibra/OrangePi_H5SDK/commit/5fa506bb9e52cd00b9592e67516b7355435071f4
f0xx has quit [Ping timeout: 260 seconds]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
Gerwin_J has quit [Quit: Gerwin_J]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
phipli has joined #linux-sunxi
mzki has quit [Quit: leaving]
|Jeroen| has joined #linux-sunxi
Andy-D has quit [Ping timeout: 250 seconds]
Putti has quit [Quit: Leaving]
ErwinH has quit [Ping timeout: 260 seconds]
simosx has quit [Quit: Yakkety Bye!]
kivutar_ has joined #linux-sunxi
Ntemis has joined #linux-sunxi
Putti has joined #linux-sunxi
<KotCzarny> thelinuxbug: ping
leviathanch has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser> Pepe: Do you have this Azpen already?
<Pepe> No, no. Backers inc. me are waiting for it. They should ship it at end of November.
<tkaiser> Pepe: ok, would've been interesting to get the .dtb
<Pepe> I can provide it to you, when I will receive it :-)
<tkaiser> Pepe: Would really be interesting to be able to have a look. I would assume they use an I2C trackpad and maybe driver is already included in BSP sources.
<tkaiser> Pepe: also interesting whether display is accessed through HDMI/eDP or not. But this should also be clear by looking at DT
IgorPec has quit [Ping timeout: 252 seconds]
phipli has quit [Ping timeout: 240 seconds]
<jelle> apritzel1: hi
IgorPec has joined #linux-sunxi
leviathanch has quit [Read error: Connection reset by peer]
lamer14794131424 has joined #linux-sunxi
lamer14794131424 has quit [Client Quit]
leviathanch has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
The_Loko has quit [Ping timeout: 240 seconds]
apritzel1 has quit [Ping timeout: 260 seconds]
mzki has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
yann-kaelig has joined #linux-sunxi
jernej has joined #linux-sunxi
<Ntemis> jernej: hi
<jernej> Ntemis: hi
<Ntemis> in the fex where it says dram_mr0 = 6208
<Ntemis> can i use dram_mr0 = 0x6208?
<Ntemis> or it wont work?
<KotCzarny> ntemis: did you test limamemtester?
<jernej> I don't know what these settings really are. I just adopted them. But that is great difference anyway, hex vs dec
<Ntemis> yes but others are hex others are dec
phipli has joined #linux-sunxi
<beeble> mripard: damn, applying patches a minute before i send out my email. now i look stupid :)
<Ntemis> yes it is u r right
<jernej> Aren't those settings used only in U-Boot anyway?
<jernej> except maybe ram frequency
<Ntemis> yes but will it read them?
<jernej> no
<Ntemis> in whatever format hex or dec
<tkaiser> jernej: BSP u-boot only
<jernej> mainline u-boot doesn't use them
<Ntemis> ok
<jernej> Ntemis: AFAIK there is no use changing ram settings in fex if you are using mainline u-boot
<jernej> except frequency
<Ntemis> am using sunxi one
<Ntemis> same as your oe
<tkaiser> jernej: legacy kernel honors the remaining info there only if CONFIG_DEVFREQ_DRAM_FREQ=y
<tkaiser> jernej: And then *only* if throttling occurs
<jernej> nope, my OE fork is using mainline kernel
<jernej> *u-boot
<Ntemis> oh
<jernej> a long time, around 8 months?
<jernej> a bit less
<jernej> half a year maybe
<Ntemis> jernej: i am adapting opipc2 dram timings to opipc
<jernej> as I said, I don't really understand those ram settings, so I can't help here
<jernej> but there are others here which can
<jernej> I didn't yet start working on opi pc 2
<jernej> to much fun with u-boot video driver...
leviathanch has quit [Read error: Connection reset by peer]
<Ntemis> jernej: thank you
<jernej> no problem
<jernej> just one question for you
<jernej> those patches you applied to bsp kernel
<jernej> they improve anything annoying
<jernej> ?
<jernej> or just for stability in general?
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<Ntemis> jernej: u have a pm
The_Loko has joined #linux-sunxi
<tkaiser> Ntemis: Be assured that those stuff you try to copy&paste is not the result of testing but of using Allwinner BSP defaults: https://github.com/OrangePiLibra/OrangePi_H5SDK/blob/5fa506bb9e52cd00b9592e67516b7355435071f4/kernel/arch/arm64/boot/dts/OrangePiH5_PC2.dts#L3510-L3539
Andy-D has joined #linux-sunxi
phipli has quit [Ping timeout: 252 seconds]
mzki has quit [Ping timeout: 265 seconds]
apritzel has joined #linux-sunxi
<apritzel> jelle: hi, how did it go?
<apritzel> On my way home I was thinking of putting all of this into a script
<jelle> apritzel: hmm well I don't have a kernel etc. setup
<jelle> apritzel: but I saw u-boot loaded but it hanged on 'detecting usb devices'
<apritzel> jelle: exactly ;-)
<apritzel> I saw this too, I am just wondering why, obviously it's something in ATF
<mripard> beeble: you don't, all those details are awesome :)
<apritzel> jelle: was that with FEL boot
<MoeIcenowy> finally got a GNOME Shell running on A33 4.9 kernel with Mali...
<jelle> apritzel: sd card
<mripard> beeble: and please continue to provide them :)
Mr__Anderson has joined #linux-sunxi
<mripard> MoeIcenowy: yay! :)
<apritzel> jelle: yes, so that's expected
<MoeIcenowy> mripard: the main problem is not drm -- it's Mutter's bug
<jelle> apritzel: ok, I have to read up about the kernel don't know much about aarch64 but I find it interesting
<apritzel> MoeIcenowy: awesome!
<mripard> MoeIcenowy: I can't do anything for that one :)
<MoeIcenowy> but to be honest Mali blob is many times better than LLVMpipe :-)
<MoeIcenowy> mripard: I reported it to GNOME bugzilla
<apritzel> jelle: the config patch and the DT is in my a64-v6-wip branch
<jelle> cool, I can try that later =)
<jelle> apritzel: I could put it on the wiki, the instructions
<apritzel> jelle: don't bother, I wil write a script
<jelle> ok
<apritzel> it's temporary anyway
<apritzel> eventually it will be much easier
<jelle> apritzel: what I fail to understand is why you need to compile something 32 bit and then 64 bit
<apritzel> libdram is a 32-bit Allwinner blob
<apritzel> which does the DRAM init
<apritzel> we link it into U-Boot and call it from the SPL code
<jelle> ah ok
vagrantc has quit [Ping timeout: 240 seconds]
<apritzel> also the SoCs boot in 32-bit
<jelle> ok interesting
<apritzel> so the SPL starts in 32-bit anyway, in any case
<apritzel> also 32-bit means we can use Thumb2 encoding, which creates much smaller binaries
<apritzel> which is important as the SPL cannot exceed 32KB
<jelle> aha ok
utente__ has quit [Ping timeout: 260 seconds]
<beeble> mripard: will do whenever i can. was ment as a joke anyway
utente__ has joined #linux-sunxi
|Jeroen| has quit [Quit: dada]
<MoeIcenowy> apritzel: are you REing sun50iw2 libdram?
<apritzel> MoeIcenowy: no, not at the moment
<apritzel> I am setting some hope into jemk ;-)
<MoeIcenowy> and have you tried your old boot0 patcher?
<MoeIcenowy> I think I have gave you a usable boot0 :-)
<apritzel> I will dump the registers at some time and send it to him
<apritzel> MoeIcenowy: next bad news: this boot0 process changed
<apritzel> the layout is different
<apritzel> so yeah, the boot0 from your image boots
<apritzel> but the offsets are different, also I think there is a new data structure in between
<MoeIcenowy> I think boot0 maybe partly open-sourced
<MoeIcenowy> in the BSP U-Boot source tree
<MoeIcenowy> or precisely, brandy/u-boot-2014.07/sunxi_spl/boot0/
<apritzel> yeah, but still it uses libdram ...
<MoeIcenowy> I think before we get a usable libdram, we must try to patch boot0
<apritzel> MoeIcenowy: I am quite hopeful that the right guy can fix U-Boot's DRAM code quite quickly
<apritzel> the DRAM controller can't be that far from either the H3 or the A64
<MoeIcenowy> we hope so
<apritzel> MoeIcenowy: yeah, I wanted to have another look at patching boot0
<apritzel> but not today
<apritzel> maybe on the weekend
<jemk> apritzel: i don't have h5, but i would have expected a64 code to work (after fixing delays maybe)
<MoeIcenowy> I think I should go back from A33 to A64/H3/H5
<apritzel> jemk: oh, hi
<apritzel> jemk: I tried both H3 and A64, A64 bailed out earlier ;-)
<MoeIcenowy> especially A64... My A64 has been ignored for many weeks
IgorPec has quit [Ping timeout: 268 seconds]
<MoeIcenowy> is the A64 SPL upstreamed?
<apritzel> MoeIcenowy: no
<apritzel> MoeIcenowy: I got send back to make it work with 64-bit first ;-)
<apritzel> which is basically ready (it boots), but needs some cleanup
<jemk> apritzel: hm, ok, early is bad, then it might be more than delays
<apritzel> also there is the H5
<apritzel> also there is the SPL FIT loading
<apritzel> MoeIcenowy: you get the idea ...
<MoeIcenowy> we cost too much time on A64, that we got mess when H5 is out
<MoeIcenowy> maybe because H5 is early access this time :-)
<apritzel> jemk: yeah, the H3 looked more promising, but I am really stupid when it comes to DRAM
reinforce has quit [Quit: Leaving.]
<apritzel> jemk: the H5 looks to be pin compatible to the H3, so my guess is that's the H3 DRAM controller there
<apritzel> jemk: but I could be wrong, as they also took the MMC controller from the A64
<jemk> apritzel: h3 has the strange zq calibration quirk, i would hope they fixed it in h5
<apritzel> jemk: ah, remember this one
<MoeIcenowy> I think when 4.9 is out I can provide a patched gaming-ready A33 kernel
<apritzel> jemk: we'll see, if you are happy with me sending you register dumps tomorrow or one the weekend?
<apritzel> MoeIcenowy: I compiled a 4.8.8 kernel with one tiny Kconfig patch and it booted on the H5 yesterday
<jemk> apritzel: apart from that there aren't many differences in the initialisation, only some parameters
<MoeIcenowy> apritzel: congrats :-)
<MoeIcenowy> but we still have no user manuals...
<apritzel> MoeIcenowy: in fact I am trying to push this thing into 4.9 still
<MoeIcenowy> which makes it difficult to make a ccu
<MoeIcenowy> a precise ccu *
<apritzel> MoeIcenowy: from all we know it's the H3 CCU
<MoeIcenowy> it won't be such simple :-)
<apritzel> I know ;-)
<tkaiser> jemk: In case you're interested I could send out the OPi PC 2 lying here around
<MoeIcenowy> and ccu is still not so clear nowadays
<MoeIcenowy> even for mainlined ones
<MoeIcenowy> I have met two bugs in A33 CCU :-)
<apritzel> MoeIcenowy: I wanted to use: compatible = "sun50i-h5-ccu", "sun8i-h3-ccu";
<MoeIcenowy> yes
<MoeIcenowy> apritzel: have you tested sun5i-a13-mmc on your Banana Pi M64's eMMC?
<apritzel> MoeIcenowy: so that older kernels use the H3 one, but we can easily fix everything upstream
<apritzel> MoeIcenowy: yes, but no change
<MoeIcenowy> still cannot work?
<apritzel> MoeIcenowy: but mripard got a lead
<apritzel> it's CMD18 (multi-block read) failing
<MoeIcenowy> apritzel: I mean, that, get sun50i-a64-mmc compatible removed
<mripard> and CMD25
<MoeIcenowy> only sun5i-a13-mmc left
<apritzel> he has a small hack to restrict the driver to just use one block at a time
heffer has quit [Ping timeout: 260 seconds]
<apritzel> MoeIcenowy: sure, that's what I meant too
<MoeIcenowy> I haven't still received my Banana Pi M64...
<apritzel> MoeIcenowy: but the issue is with the MMC (not SD) multi-block read sequence
<jemk> tkaiser: if you don't need it, i've laying around enough boards, but it would make dram dev easier than reading regdumps ;)
<MoeIcenowy> apritzel: only MMC have this command?
<MoeIcenowy> so it's not the problem of DDR, but a really new function in MMC controller?
<mripard> no
<apritzel> MoeIcenowy: the issues happens with DDR and SDR
<mripard> it's a function that used to work on older SoCs but doesn't on the A64
<apritzel> yeah, so definitely an issue with the driver not being able to fully handle the new controller
<apritzel> MoeIcenowy: on MMC (but not SD) you can specify _beforehand_ how many block you want to read
<apritzel> MoeIcenowy: then fire off the command
<apritzel> MoeIcenowy: on SD you are expected to stop the transfer, but this MMC feature stops automatically
<apritzel> MoeIcenowy: at least this is my understanding
<apritzel> now the respond from the eMMC to this automatic stop is different from what the driver expects
<apritzel> MoeIcenowy: so if I got mripard correctly, it gets the IRQ (or was it masked?), but somehow ignores it
<MoeIcenowy> I also met some strange problems on H3 MMC..
<MoeIcenowy> (when testing XRadio driver with Orange Pi Zero
alexxei has quit [Remote host closed the connection]
heffer has joined #linux-sunxi
<apritzel> I think mripard mentioned that CMD25 has the same issue, which is used by SDIO
<mripard> apritzel: it gets an IRQ, but the bit we're supposed to have is not set
<mripard> and SDIO uses CMD53, which also has the issue
<mripard> CMD25 is write multiple blocks
<apritzel> numbers....
<apritzel> right
<apritzel> mripard: oh, so write is effected as well?
<mripard> it is
<mripard> it's just less likely to occur
<apritzel> mripard: since your patch tested for read explicitly
<mripard> yeah, I found that out after giving you that patch :)
* apritzel stops the build ...
<MoeIcenowy> mripard: I also want the patch :-)
<apritzel> MoeIcenowy: say: "please"
<apritzel> ;-)
<MoeIcenowy> oh sorry ;-)
<MoeIcenowy> thanks :-)
<mripard> it's just a hack at this point
<MoeIcenowy> oh it's now the time for me to read out the MMC spec...
<mripard> but I couldn't make it break during my hour or so testing today
<mripard> MoeIcenowy: I don't really have found anything in there
<MoeIcenowy> I cannot even know what CMD number is what command...
<mripard> MoeIcenowy: this really seems to be related to the controller itself
<apritzel> mripard: btw, I restricted it to (card->host->caps & MMC_CAP_NONREMOVABLE)
<apritzel> MoeIcenowy: the spec doesn't seem to be public
<MoeIcenowy> MMC ones seems to be
<MoeIcenowy> at least lite versions
<apritzel> MoeIcenowy: this one has some information: http://elm-chan.org/docs/mmc/mmc_e.html
<MoeIcenowy> thanks
<tkaiser> jemk: Will send out OPi PC 2 tomorrow :)
<jemk> tkaiser: thanks, lets relieve apritzel a bit
<mripard> apritzel: you have to register, but you can download it after that
<apritzel> cheers guys!
<apritzel> sounds like silver.arm.com ;-)
The_Loko has quit [Ping timeout: 260 seconds]
<MoeIcenowy> ok it's the time for me to go bed...
<MoeIcenowy> and for others here, to wake up :-(
<MoeIcenowy> it's 6:14 am now
<beeble> apritzel: and use bugmenot if you don't like to register...
<apritzel> beeble: ah, nice one ;-)
yann-kaelig has quit [Quit: Leaving]
<apritzel> beeble: and where can I download the two extra days to spend on this? ;-)
<beeble> sorry, i'm only good at erasing days not at creating new ones :)
<apritzel> ;-)
<apritzel> my application for the 28h day is still pending ...
<apritzel> beeble: anyway, that PDF is definitely useful, thanks for the link
<beeble> you are welcome
phipli has joined #linux-sunxi
<beeble> and maybe you want to petition on http://30hd.org/
<apritzel> yeah!
<apritzel> I definitely enjoyed that last Sunday in October ...
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
paulk-collins has quit [Quit: Leaving]
Mr__Anderson has quit [Quit: Leaving.]
jernej has quit [Ping timeout: 260 seconds]
scream has quit [Remote host closed the connection]
mzki has joined #linux-sunxi
tkaiser has left #linux-sunxi [#linux-sunxi]
utente__ has quit [Quit: Sto andando via]
jstein has quit [Remote host closed the connection]
mzki has quit [Quit: leaving]
Nyuutwo has quit [Ping timeout: 268 seconds]
phipli has quit [Ping timeout: 260 seconds]