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
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
khuey is now known as khuey|away
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
viccuad has quit [Ping timeout: 276 seconds]
<slapin> how can I enable mali support with mainline kernel (A13)?
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
orly_owl has joined #linux-sunxi
<ssvb> slapin: you need to compile the mali driver for the mainline kernel
<ssvb> afaik nobody tried this yet, but this should not be particularly challenging
apritzel has quit [Ping timeout: 244 seconds]
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
pietrushnic is now known as pietrushnic`away
<slapin> ssvb: the challenging thing is DT setup for boards... also newer drivers don't use UMP...
<slapin> I hope I can use ARM's userspace too
<ssvb> slapin: you don't strictly have to use the newer kernel drivers
pietrushnic`away has quit [Quit: Coyote finally caught me]
<ssvb> but yes, first pick some mali userland blob which is known to work and then try to compile a matching kernel driver
<ssvb> with ump or dmabuf depending on how the userland blob is configured
<slapin> ssvb: can I use blob provided by ARM or I have to use one from Allwinner?
pietrushnic`away has joined #linux-sunxi
Nacho has quit [Remote host closed the connection]
<ssvb> afaik as far as just the functionality is concerned, all of them should work
<ssvb> but the blobs not provided by Allwinner usually have restrictive EULA which forbids their usage on other hardware
<ssvb> but why the mainline kernel? and why mali?
Nacho has joined #linux-sunxi
cajg has quit [Ping timeout: 244 seconds]
vagrantc has joined #linux-sunxi
khuey|away is now known as khuey
cnxsoft has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 248 seconds]
p1u3sch1 has joined #linux-sunxi
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
arokux__ has joined #linux-sunxi
jukivil1 has quit [Ping timeout: 264 seconds]
arokux_ has quit [Ping timeout: 248 seconds]
ninolein has quit [Ping timeout: 268 seconds]
ninolein_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 276 seconds]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 is now known as cnxsoft
khuey is now known as khuey|away
p1u3sch1 has quit [Ping timeout: 276 seconds]
p1u3sch1_ has joined #linux-sunxi
TheSeven has quit [Ping timeout: 248 seconds]
TheSeven has joined #linux-sunxi
Ueno_Otoko has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
tchiwam has quit [Ping timeout: 248 seconds]
tchiwam has joined #linux-sunxi
lamer14567874254 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
libcg has joined #linux-sunxi
reinforce has joined #linux-sunxi
SadSmile has joined #linux-sunxi
montjoie has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
Ueno_Otoko has quit [Ping timeout: 248 seconds]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
Ueno_Otoko has joined #linux-sunxi
Ueno_Otoko has quit [Ping timeout: 252 seconds]
Ueno_Otoko has joined #linux-sunxi
<plaes> anyone familiar with mediawiki navigation templates?
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
robogoat has quit [Ping timeout: 260 seconds]
libcg has quit [Read error: Connection reset by peer]
robogoat has joined #linux-sunxi
arokux__ has quit [Ping timeout: 252 seconds]
IgorPec has joined #linux-sunxi
Andy-D has joined #linux-sunxi
Andy-D has quit [Read error: Connection reset by peer]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
Andy-D has joined #linux-sunxi
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
arete74 has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
Confucij has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
diego_r has joined #linux-sunxi
yann||work has quit [Ping timeout: 260 seconds]
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
MY123 has joined #linux-sunxi
mzki has joined #linux-sunxi
Confucij has left #linux-sunxi [#linux-sunxi]
arokux has joined #linux-sunxi
<montjoie> if someone want a true RNG, my uptime is a good choice
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
robogoat has quit [Ping timeout: 276 seconds]
Andy-D has quit [Ping timeout: 250 seconds]
lemonzest has joined #linux-sunxi
cptG__ has joined #linux-sunxi
cptG___ has joined #linux-sunxi
Andy-D has joined #linux-sunxi
robogoat has joined #linux-sunxi
cptG has quit [Ping timeout: 248 seconds]
cptG_ has quit [Ping timeout: 276 seconds]
reinforce has quit [Quit: Leaving.]
apritzel has joined #linux-sunxi
reinforce has joined #linux-sunxi
cajg has joined #linux-sunxi
yann||work has joined #linux-sunxi
Andy-D has quit [Ping timeout: 276 seconds]
matthias_bgg has joined #linux-sunxi
yann||work has quit [Ping timeout: 246 seconds]
pietrushnic`away is now known as pietrushnic
yann||work has joined #linux-sunxi
viccuad has joined #linux-sunxi
arokux has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
Worf has joined #linux-sunxi
hansg has joined #linux-sunxi
hansg has quit [Remote host closed the connection]
enrico_ has joined #linux-sunxi
lamer14567874254 has quit [Quit: jIRCii - http://www.oldschoolirc.com]
tkaiser has joined #linux-sunxi
avph has quit [Ping timeout: 246 seconds]
avph has joined #linux-sunxi
arokux has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
avph has quit [Ping timeout: 246 seconds]
avph has joined #linux-sunxi
akaWolf has joined #linux-sunxi
<akaWolf> hi guys! can you help me? I'm using mali lib and I've got «Error: eglInitialize failed» with «EGL_BAD_ALLOC»
<akaWolf> hmmm
hipboi has joined #linux-sunxi
Mormegil has joined #linux-sunxi
<Mormegil> Hi! I tried to clean up the formatting of the [[Boot Android from SdCard]] wikipage but the spamfilter stopped me, pointing me here... Anyone could help?
<NiteHawk> Mormegil: could you try again, please? :)
FDCX has joined #linux-sunxi
FDCX has quit [Remote host closed the connection]
FDCX has joined #linux-sunxi
<Mormegil> NiteHawk: Yep, works now, thanks.
<NiteHawk> Mormegil: yw
avph has quit [Ping timeout: 246 seconds]
Mormegil has quit []
avph has joined #linux-sunxi
<NiteHawk> turl: maybe spam filtering (akismet?) is a bit too paranoid currently?
FlorianH has joined #linux-sunxi
gusenkovs has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
<plaes> gusenkovs: use proper mainline driver
<plaes> this issue was fixed Jul 31 2015 in mainline
gusenkovs_ has joined #linux-sunxi
adj_ has quit [Quit: Leaving]
adj_ has joined #linux-sunxi
gusenkovs has quit [Ping timeout: 252 seconds]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
afaerber has quit [Quit: Ex-Chat]
FDCX has quit [Ping timeout: 276 seconds]
afaerber has joined #linux-sunxi
<montjoie> wens: for the official name (and binding) of the ethernet driver, should I use sun8i-h3-emac or sun8i-a83t-emac ?
<Turl> NiteHawk: yeah, it's not ideal for wikis
FDCX has joined #linux-sunxi
gusenkovs_ has quit [Quit: Page closed]
JohnDoe_71Rus has joined #linux-sunxi
arokux has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<tkaiser> gusenkovs: Do you really play around with any of SinoVoip's 4.x kernel forks?
SadSmile has quit [Quit: Leaving]
<apritzel> montjoie: what about "sun8i-emac" as the generic name in your driver and then every SoC can use a more specific name in addition in case it needs specific settings/fixes/workarounds?
cnxsoft has quit [Remote host closed the connection]
<montjoie> apritzel: for a general name I agree, but all binding name I see have always 3 part
diego_r has quit [Remote host closed the connection]
vishnup has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<apritzel> then it's time to deviate ;-)
<KotCzarny> uh oh
kill_-9_1 has joined #linux-sunxi
Worf has quit [Quit: Konversation terminated!]
MY123 has quit [Disconnected by services]
kill_-9_1 is now known as MY123
Ueno_Otoko has quit [Ping timeout: 246 seconds]
JohnDoe0 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 248 seconds]
reinforce has joined #linux-sunxi
vishnup has quit [Remote host closed the connection]
JohnDoe0 has quit [Ping timeout: 248 seconds]
domidumont has quit [Read error: Connection reset by peer]
JohnDoe0 has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Client Quit]
IgorPec has joined #linux-sunxi
JohnDoe0 has quit [Ping timeout: 246 seconds]
JohnDoe0 has joined #linux-sunxi
yann||work has quit [Ping timeout: 248 seconds]
mzki has quit [Quit: leaving]
<plaes> tkaiser: yeah.. he does
p1u3sch1_ has quit [Ping timeout: 276 seconds]
p1u3sch1 has joined #linux-sunxi
montjoie has quit [Ping timeout: 248 seconds]
montjoie has joined #linux-sunxi
Andy-D has joined #linux-sunxi
vagrantc has joined #linux-sunxi
nove has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
khuey|away is now known as khuey
<wens> montjoie: sun8i-emac should be fine
<wens> i don't recall any drivers specifically having the soc name in the driver name, other than the clk and pinctrl ones
<Turl> compatibles do, but for drivers you're usually fine naming them sunNi-stuff
<vagrantc> wens: i was looking at your A80 branches and wondering if any of the branches had working smp, usb and network? or would i have to cobble them together by cherry-picking all the branches together?
<wens> montjoie: i also did a bunch of cleanup on your driver, though haven't tested it
<wens> vagrantc: usb is mainlined already
<vagrantc> that's a start :)
<wens> cc-a80 usb support is pending though, due to its awkward design
<wens> network and wifi are both in my sun9i-wip branch
<wens> smp probably won't get mainlined
<vagrantc> ouch.
<wens> we prefer psci support in u-boot
<vagrantc> any recent u-boot branches for cubieboard4? only one i could find was ancient...
mossroy has joined #linux-sunxi
<vagrantc> wens: and thanks for all your work on this
<wens> vagrantc: u-boot work hasn't progressed much
* vagrantc tried cherry-picking the smp patches, and was surprised they applied fine, but the failed to compile
<apritzel> is PSCI support for a new AW SoC so complicated in U-Boot?
<apritzel> I'd guess it's just a matter of configuration, isn't it?
<wens> apritzel: not really, but u-boot support for a80 is so minimal right now
<wens> so there's a bunch of stuff to do before we get to PSCI
<wens> like PMICs, MMC, USB(?)
<apritzel> Ah, OK, so there is only some vendor U-Boot available atm?
<wens> yeah, pretty much
<wens> it seems not many people are still interested in the a80
p1u3sch1 has quit [Ping timeout: 246 seconds]
p1u3sch1 has joined #linux-sunxi
<apritzel> but it looks to be pretty capable, 4 * A15@2GHz plus USB3 plus much RAM
doppo has quit [Ping timeout: 268 seconds]
apritzel1 has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
doppo has joined #linux-sunxi
TheLinuxBug has quit [Ping timeout: 264 seconds]
MackBoy has quit [Ping timeout: 264 seconds]
<jelle> :S
domidumont has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 244 seconds]
jelle has quit [Quit: ZNC - http://znc.in]
enrico_ has quit [Quit: Bye]
TheLinuxBug has joined #linux-sunxi
MackBoy has joined #linux-sunxi
tkaiser has quit [Ping timeout: 250 seconds]
MackBoy has quit [Ping timeout: 264 seconds]
tkaiser has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser> I ask since my Pine64 immeditely deadlocks when I start it :)
<tkaiser> ssvb: Does cpuburn-a53 starts 4 threads or just one?
afaerber has quit [Quit: Ex-Chat]
FlorianH has quit [Ping timeout: 250 seconds]
naobsd has quit [Ping timeout: 268 seconds]
adj_ has quit [Ping timeout: 250 seconds]
mossroy has quit [Ping timeout: 250 seconds]
solarnetone has quit [Ping timeout: 268 seconds]
mossroy has joined #linux-sunxi
MackBoy has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 268 seconds]
Net147 has quit [Ping timeout: 268 seconds]
indy has quit [Ping timeout: 268 seconds]
Net147 has joined #linux-sunxi
FlorianH has joined #linux-sunxi
TheLinuxBug has quit [Ping timeout: 268 seconds]
TheLinuxBug has joined #linux-sunxi
indy has joined #linux-sunxi
arokux__ has joined #linux-sunxi
heffer has quit [Ping timeout: 268 seconds]
adj_ has joined #linux-sunxi
solarnetone has joined #linux-sunxi
heffer has joined #linux-sunxi
tomboy65 has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 246 seconds]
kill_-9_1 has joined #linux-sunxi
MackBoy has quit [Ping timeout: 264 seconds]
kill_-9_1 has quit [*.net *.split]
solarnetone has quit [*.net *.split]
TheLinuxBug has quit [*.net *.split]
paulk-collins has quit [*.net *.split]
akaWolf has quit [*.net *.split]
tchiwam has quit [*.net *.split]
TheSeven has quit [*.net *.split]
egbert has quit [*.net *.split]
petr has quit [*.net *.split]
kelvan has quit [*.net *.split]
tomboy65 has quit [*.net *.split]
adj_ has quit [*.net *.split]
cptG___ has quit [*.net *.split]
Nacho has quit [*.net *.split]
clonak has quit [*.net *.split]
indy has quit [*.net *.split]
FlorianH has quit [*.net *.split]
p1u3sch1 has quit [*.net *.split]
Andy-D has quit [*.net *.split]
JohnDoe0 has quit [*.net *.split]
orly_owl has quit [*.net *.split]
book` has quit [*.net *.split]
pstef has quit [*.net *.split]
mozzwald has quit [*.net *.split]
FDCX has quit [*.net *.split]
cptG__ has quit [*.net *.split]
pietrushnic has quit [*.net *.split]
iamfrankenstein has quit [*.net *.split]
kaspter has quit [*.net *.split]
zoobab has quit [*.net *.split]
buZz has quit [*.net *.split]
diego71 has quit [*.net *.split]
fest has quit [*.net *.split]
jbrown has quit [*.net *.split]
khuey has quit [*.net *.split]
tyler-baker has quit [*.net *.split]
sigjuice has quit [*.net *.split]
maz has quit [*.net *.split]
joedj has quit [*.net *.split]
kivutar has quit [*.net *.split]
firnsy has quit [*.net *.split]
lordlod has quit [*.net *.split]
_fortis has quit [*.net *.split]
mnemoc has quit [*.net *.split]
lynxis has quit [*.net *.split]
nashpa has quit [*.net *.split]
vickycq has quit [*.net *.split]
ChanServ has quit [*.net *.split]
fredy has quit [*.net *.split]
ssvb has quit [*.net *.split]
atsampson has quit [*.net *.split]
tgaz has quit [*.net *.split]
Jacmet has quit [*.net *.split]
honx has quit [*.net *.split]
gzamboni has quit [*.net *.split]
captainigloo has quit [*.net *.split]
LostSoul has quit [*.net *.split]
mripard has quit [*.net *.split]
mpmc has quit [*.net *.split]
lerc_ has quit [*.net *.split]
leio has quit [*.net *.split]
FergusL has quit [*.net *.split]
cajg has quit [*.net *.split]
VargaD has quit [*.net *.split]
jero has quit [*.net *.split]
oliv3r has quit [*.net *.split]
Dan68 has quit [*.net *.split]
vbmithr has quit [*.net *.split]
wens has quit [*.net *.split]
plaes has quit [*.net *.split]
whitesn has quit [*.net *.split]
azend|vps_ has quit [*.net *.split]
libv has quit [*.net *.split]
formruga has quit [*.net *.split]
NiteHawk has quit [*.net *.split]
longsleep has quit [*.net *.split]
robogoat has quit [*.net *.split]
ganbold has quit [*.net *.split]
dlan has quit [*.net *.split]
codekipper has quit [*.net *.split]
aep has quit [*.net *.split]
GeneralStupid has quit [*.net *.split]
topi` has quit [*.net *.split]
tomcheng76 has quit [*.net *.split]
focus has quit [*.net *.split]
zumbi has quit [*.net *.split]
mcan has quit [*.net *.split]
speakman has quit [*.net *.split]
vpeter has quit [*.net *.split]
SJRvanSchaik has quit [*.net *.split]
ccaione has quit [*.net *.split]
doppo has quit [*.net *.split]
IgorPec has quit [*.net *.split]
reinforce has quit [*.net *.split]
avph has quit [*.net *.split]
arete74 has quit [*.net *.split]
Shirasaka-Hazumi has quit [*.net *.split]
popolon has quit [*.net *.split]
hp197 has quit [*.net *.split]
bgardner has quit [*.net *.split]
mpmctoo has quit [*.net *.split]
Keziolio has quit [*.net *.split]
kadamski has quit [*.net *.split]
Rondom_ has quit [*.net *.split]
arokux__ has quit [*.net *.split]
Net147 has quit [*.net *.split]
mossroy has quit [*.net *.split]
domidumont has quit [*.net *.split]
nove has quit [*.net *.split]
montjoie has quit [*.net *.split]
MY123 has quit [*.net *.split]
viccuad has quit [*.net *.split]
Uninstall has quit [*.net *.split]
pekka30 has quit [*.net *.split]
specing has quit [*.net *.split]
slapin has quit [*.net *.split]
arnd has quit [*.net *.split]
wigyori has quit [*.net *.split]
KotCzarny has quit [*.net *.split]
Michal has quit [*.net *.split]
atenart has quit [*.net *.split]
camh has quit [*.net *.split]
flok420 has quit [*.net *.split]
uwe_ has quit [*.net *.split]
tkoskine has quit [*.net *.split]
pitillo has quit [*.net *.split]
igraltist has quit [*.net *.split]
aballier has quit [*.net *.split]
bfree_ has quit [*.net *.split]
rZr has quit [*.net *.split]
souther has quit [*.net *.split]
xenoxaos has quit [*.net *.split]
andoma has quit [*.net *.split]
ikmaak has quit [*.net *.split]
bamvor has quit [*.net *.split]
fl_0 has quit [*.net *.split]
ojn has quit [*.net *.split]
MoeIcenowy has quit [*.net *.split]
huehner has quit [*.net *.split]
vetkat has quit [*.net *.split]
jelly has quit [*.net *.split]
heffer has quit [*.net *.split]
vagrantc has quit [*.net *.split]
ninolein_ has quit [*.net *.split]
Nyuutwo has quit [*.net *.split]
HeavyMetal has quit [*.net *.split]
bbrezill1 has quit [*.net *.split]
steev has quit [*.net *.split]
MackBoy has joined #linux-sunxi
tomboy65 has joined #linux-sunxi
TheLinuxBug has joined #linux-sunxi
ganbold has joined #linux-sunxi
Keziolio has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
firnsy has joined #linux-sunxi
captainigloo has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<slapin> hi, all!
<slapin> have anybody tried porting mali drivers to newer kernel?
<jemk> ssvb: any hints where to start debugging fel spl command on a80?
<jemk> I cherry-picked your a80 support commit, but it only prints the stack pointers and hangs
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein1 is now known as iamfrankenstein
<slapin> which drivers for mali do I need - only mali.ko or something else?
<slapin> do I need drm driver?
yann||work has joined #linux-sunxi
<ssvb> jemk: don't know, it should be more or less the same as a64
<ssvb> the only idea was to try a different SRAM area for backup storage
cosm has joined #linux-sunxi
<jemk> ssvb: sometimes it gets to "MMU is not enabled...", but most of the time it hangs before that
p1u3sch1 has quit [Ping timeout: 248 seconds]
<jemk> so the backup storage doesn't even get used if i understood it correct
<ssvb> yes, this is strange
p1u3sch1 has joined #linux-sunxi
<jemk> i had to add the V bit to the ignored bits in SCTLR, but i think this is ok
<jemk> no, i use master with d33de20 cherry-picked
<jemk> same result with a64 branch + d33de20
<ssvb> ok
<ssvb> are you setting ".scratch_addr = 0x11000" though?
<jemk> no, 0x12000 as in you patch
<ssvb> not sure if it will help, but maybe try it too
<jemk> i tried, didn't change
<ssvb> it looks like it makes sense to add a lot of debugging prints to the code to check where it fails
<jemk> but after adding a lot of debug prints i now always get to "mmu not enabled"
<jemk> looks like delays improve things...
<ssvb> maybe some barriers are missing?
<jemk> now it fails at the buffer swapping
<jemk> wrong
<ssvb> when modifying some coprocessor registers?
<KotCzarny> apritzel, wens: how much work would it require to move hw init (psci as you say) from 'bootloader' to linux kernel?
<ssvb> jemk: also try to "ping" fel periodically just to check where exactly it fails
doppo has joined #linux-sunxi
<KotCzarny> not to bash on u-boot, but it kinda pins the hw to bootloader
<ssvb> jemk: if one of the fel requests is identified as non-responding, then it's likely the previous one that has messed up things
<ssvb> KotCzarny: do you want to merge the bootloader and the linux kernel into a single monolithic thing?
<jemk> ssvb: now it fails again at reading dacr cp reg, last working was read ttbcr
<KotCzarny> ssvb, nope, bootloader only has to know where and how to load kernel and start it
<KotCzarny> though in similar vein bios on x86 provides acpi map about stuff (and smp too)
<ssvb> KotCzarny: in other words, you want something like just the SPL which directly starts the linux kernel and skips the main U-Boot part
<KotCzarny> ssvb, seems so, and add hw init drivers to kernel
<jemk> ssvb: this is reproducible, either it fails there or when writing the spl to 0x12000-0x15c00
<ssvb> KotCzarny: by the way, PSCI is also not strictly necessary and you can bring up additional cores in the Linux kernel directly (there is even old deprecated sunxi code for that in the kernel code)
<ssvb> KotCzarny: but I don't quite understand what you are trying to achieve (other that just having fun and figuring out how these things work) :-)
<ssvb> jemk: I suspect some sort of coherency issues
<KotCzarny> ssvb, just wondering if it would be possible to have full hw detection/init in kernel
<ssvb> KotCzarny: of course it is technically possible, but PSCI had been introduced for a reason
<KotCzarny> uhum
<ssvb> jemk: for example, if the "fel write" operations which write ARM code to SRAM scratch buffer are not properly synchronized with "fel exec"
<ssvb> jemk: we may need to review the caches setup and possibly add barrier instructions
keesj has joined #linux-sunxi
<keesj> lo
<keesj> I am trying to enable spi (2) on an A10-OlinuXino-LIME board and failing at randomly changing stuff in the dts
<KotCzarny> ssvb, one of the reasons to have detection in kernel would be being able to boot one image on different devices
<keesj> I am following http://linux-sunxi.org/SPIdev (but also compare to the A20 dtb stuff
<KotCzarny> right now as i see the armbian download page it's just one-device-one-image, even if all of them use a20 for example
<KotCzarny> ssvb, nice, gotta check it in the morning
<ssvb> KotCzarny: I had a long e-mail post explaining how and why this approach works - http://lists.denx.de/pipermail/u-boot/2015-January/202306.html
doppo has quit [Ping timeout: 250 seconds]
<ssvb> but the distribution maintainers did not seem to be interested in using this opportunity
doppo has joined #linux-sunxi
<ssvb> IgorPec: ^ if I understand KotCzarny correctly, you now trying to create unified sd card images?
<IgorPec> ssvb: we were trying to do for H3 boards and we came out with two
<ssvb> IgorPec: yes, with some adjustments we can have a unified A10/A13/A20/H3 image to support a set of boards
<IgorPec> ssvb: that would be really nice
<ssvb> either automatically making the decision (take the DRAM size into account and read some GPIO or check the USB bus for built-in USB devices/hubs)
<ssvb> or simply asking the user after booting in a "failsafe" configuration (this is what the current sunxi-bootsetup demo does)
<IgorPec> auto detect is hard to achieve
<ssvb> well, if we don't claim a fully universal image, then it is easy
<IgorPec> in this case yes
<ssvb> for example, you can have a unified Cubieboard1/Cubieboard2/Cubietruck image with full autodetection and no need to ask the user
<IgorPec> CB1 too?
<ssvb> yes, of course
<ssvb> the decision can be made just based on the RAM size and the SoC type
<IgorPec> and bananas can also be added
<ssvb> well, this is where it becomes difficult
<ssvb> differentiating cubieboards and bananas can be tricky without asking the user
<ssvb> if there are two boards using the same soc type and the same dram size, then how the installer would be able to see the difference between them?
<IgorPec> gmac / emac?
<ssvb> how do you suggest to probe for this information?
<IgorPec> don't know ;)
<IgorPec> you mean from uboot?
<ssvb> from anywhere
<ssvb> let's say, you can run a bare metal code on the device
<ssvb> how can you probe for the gmac availability?
<ssvb> especially considering that it may need to be powered up via some gpio which may be different between different boards
<IgorPec> power on, check response, go further .. ?
<ssvb> "power on" as in "write to some gpio which may or may not be used to power up gmac"?
<ssvb> this is dangerous because it may potentially damage the hardware
<IgorPec> this would need to be checked
<ssvb> how?
<ssvb> the users may run this code on some board where this particular gpio is used for something else
<IgorPec> ok, let's forget this
<IgorPec> then user input is a must
<keesj> (sorry to join in) I just read ssvb's message on the list. As a user it is not uboot (detection) that will stop me. While not perfect the debian jessie "sd install" method did work for me ( and I think also would work for average users) it is quite a hack but... does work https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_from_an_SD_card_image
<IgorPec> so we can boot one image on all boards give user a select box and install proper uboot / kernel
<ssvb> keesj: it is not a hack because the "failsafe" configuration relies on the use of the peripherals, which are also used by the boot ROM
<tkaiser> IgorPec: And trust me, there will be some that choose the wrong board and blame you afterwards ;)
<keesj> doesn't mean you need to use different u-boot (you might want to use the same binary if possible)
<ssvb> keesj: for example, the boot ROM can read the SD card when booting from it
<IgorPec> tkaiser: that's solved with "are you sure" "please type "YES I agree" ... :)
<Wizzup> keesj: what kernel are you using on the lime?
<Wizzup> I have spi working on the lime a10 I think
<ssvb> keesj: this fact *ensures* that the SD card can be safely used on all Allwinner devices in a generic way
<keesj> Wizzup: Linux olibox 3.16.0-4-armmp #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) armv7l GNU/Linux
<ssvb> keesj: even if some board manufacturer does not include the SD card slot, the boot ROM will still probe it
<Wizzup> I compile my own kernels. I think I got it to work on 4.3 at least.
<Wizzup> That is spidev
<ssvb> keesj: so the board manufacturer still can't reuse the same pins for something that can be damaged by this probing :-)
<keesj> :P
<ssvb> keesj: and we have exactly the same story with NAND - http://linux-sunxi.org/NAND#More_information_on_BROM_NAND
<ssvb> keesj: if the board manufacturer wants to make NAND bootable, then this NAND hardware can be read in a generic device independent way
<ssvb> IgorPec, tkaiser: this "are you sure" "please type "YES I agree" kind of thing is already implemented by https://github.com/ssvb/sunxi-bootsetup/releases/tag/20141215-sunxi-bootsetup-prototype :-)
<apritzel> KotCzarny: PSCI has been exactly introduced to make a single Linux kernel work on several devices
<apritzel> to have support for every single board specific crap in the kernel
<apritzel> having PSCI in U-Boot was more of a hack because there is no other firmware available for sunxi devices mostly
<ssvb> IgorPec, tkaiser: and of course, the user can't select an obviously incompatible device (if the installer is run on an A10 hardware, then A20 boards are not listed in the selection box)
<apritzel> this is different now with the Pine64, where we have ARM Trusted Firmware for this
<apritzel> This provides the PSCI bits and U-Boot is just what is says on the tin: a boot loader
mosterta has joined #linux-sunxi
<tkaiser> ssvb: thx, we're looking into this more closely
<IgorPec> yes
<tkaiser> Since board auto detection with already running kernel is more or less PITA and might always break in the future
<longsleep> tkaiser: you think i should revert the Pine64 dts cooler table changes so more checks can be made regarding voltage in dvfs table?
<tkaiser> longsleep: as far as I understand it would be the best to be able to disable throttling in the 3.10.65 kernel to be able to run cpufreq-ljt-stress-test really at the intended clockspeeds
<tkaiser> ssvb: Using cpufreq-ljt-stress-test on SoCs with this budget cooling stuff isn't that easy anymore
<tkaiser> cpufreq-ljt-stress-test tries to test 1200 MHz while the kernel throttled down to 816 MHz
<longsleep> even when setting the govenor to performance"
<longsleep> ?
<tkaiser> cpufreq-ljt-stress-test sets it to userspace and throttling always wins
<tkaiser> So either 200¡C in the cooler table or disabled throttling or a powerful fan on top of a huge heatsink ;)
<longsleep> well running with 1152.00 GHz at 1.3V does is around 50C for my pine
afaerber has joined #linux-sunxi
<longsleep> without doing anything
<longsleep> this is the first time i even look at throttling and temperature, so please forgive me if i ask stupid questions :)
<tkaiser> Without heatsink?
<longsleep> yes no heatsink
<longsleep> idle at 4800GHz is around 45C
<tkaiser> Sounds reasonable (especially the 4.8THz ;)
<longsleep> err
<longsleep> that would be hell of a soc
<tkaiser> But if you run 4 threads cpuburn-a8 or cpuburn-a53 this _will_ change
<tkaiser> And for me it's close to impossible to start cpuburn-a53 with high scaling_max_freq since the Pine64 immediately deadlocks
<longsleep> ok thats a start for improvment then
<longsleep> finding settings / fixes which make that work
<tkaiser> longsleep: IMO it's already over. As soon as people realise that 1536MHz are possible with A64 they will start to try to use this. Same story as with H3 back then
<longsleep> hehe - well noone needs to build images with that setting
<longsleep> i could even reduce the max value in kernel
<longsleep> i guess joe average does not succeed building an arm64 kernel nowadays
<tkaiser> They clone your repo and follow your instructions? ;)
<longsleep> mhm - still requires some talent
<longsleep> and all my instructions require linux in the first place
<longsleep> i sill feel pretty save from the random dudes
<tkaiser> 'Unlocking' the 1344 MHz was just dtc/vi/dtc ;)
bonbons has joined #linux-sunxi
<longsleep> lets see what ssvb's cpuburn-arm does to my pine
<jemk> ssvb: i'll give up for today, but will try again
<jemk> ssvb: it always fails at reading the result after executing the code to read DACR.
<jemk> if that works sometimes, it fails in the spl_thunk somewhere in/after swapping the buffers
<ssvb> jemk: that's a good find
<ssvb> jemk: can you maybe try to insert some dummy reads/writes of unused sram areas between aw_fel_write and aw_fel_execute here - https://github.com/linux-sunxi/sunxi-tools/blob/be1b4c7400161b90437432076360c1f99970f54f/fel.c#L684
<longsleep> tkaiser, ssvb tress test looks ok to me: http://paste.ubuntu.com/15262524/
<ssvb> jemk: I still suspect coherency issues, which means that the self-modifying code may be somewhat problematic on A80
<tkaiser> longsleep: While running how many threads what in parallel? cpuburn-a8? cpuburn-a53?
jelly-home has joined #linux-sunxi
<longsleep> did not run anything else :D
<tkaiser> longsleep: Then on a SMP machine pretty useless. We have to adjust the wiki article since the most important part is overseen: "There are border cases in which extended tests show a device might not be stable at certain settings even though they pass the tests in this script. Especially on a multi-core system you may want to run CPU-intensive tasks in the background while running cpufreq-ljt-stress-test in order to keep all
<tkaiser> cores busy. The cpuburn scripts (see below) or compiling a kernel might be suitable tasks for this end."
<longsleep> got it, now how do i compile the .S files in there, gcc gives only errors
<ssvb> longsleep: can you paste these errors?
<tkaiser> cross-compile like this: "arm-linux-gnueabihf-gcc -static -o cpuburn-a8 cpuburn-a8.S"?
<longsleep> err yeah, i probably did run it wrong
<tkaiser> ssvb: I had also troubles to build it in Pine64 directly
Turl has joined #linux-sunxi
<ssvb> tkaiser: pastebin or it didn't happen :-)
<longsleep> gcc -v
<longsleep> grr
<longsleep> gcc version 5.3.1 20160225 (Ubuntu/Linaro 5.3.1-10ubuntu2)
<jemk> ssvb: im getting mad. wrote 100 zeros after the code, and thought it works now. BUT it also works after removing the write again...
<apritzel> ssvb: the A80 is a dual cluster SoC, so coherency is different from the other SoCs
<longsleep> ssvb: cpuburn-a53.S compiled just fine same command
<longsleep> tkaiser: i have now 4 cpuburn-a53 running not crashing
<longsleep> temp alread at 73 C :)
<apritzel> ssvb: does it work on the A83T? (also dual cluster)
<ssvb> longsleep: sure, because cpuburn-a53.S has both 64-bit and 32-bit implementations and cpuburn-a8.S only has 32-bit ARM assembly
<GeneralStupid> hey
<GeneralStupid> i pulled a new git revision and it does not buil
<ssvb> apritzel: I have no A83T hardware
<GeneralStupid> libvdpau-sunxi..
<longsleep> ssvb: ah then the 64bit compiler cannot build it
<jemk> ssvb: it only worked because i had it turned off completely before the test, not only reset
<apritzel> ssvb: or in general: the A80 has Cortex-A15, do you have any A7 specific code in there?
<ssvb> jemk: and this smells like we (or the BROM) are not initializing some important system register properly
<jemk> GeneralStupid: does not build... error message please
<apritzel> ssvb: some system registers have a subtly different layout between A7 and A15, IIRC
<GeneralStupid> device.c:23:27: fatal error: cedrus/cedrus.h: No such file or directory
<longsleep> tkaiser: thermal throttling kicks in now pretty much at once when running ./cpufreq-ljt-stress-test
<GeneralStupid> smartpointers? in C? is it useful? i would try that lib :)
<jemk> GeneralStupid: did you compile and install libcedrus?
<jemk> apritzel: isn't the boot core a A7?
<GeneralStupid> jemk: is it new?
<apritzel> jemk: no idea, is it?
<apritzel> and the FEL code runs completely in UP, right?
<jemk> GeneralStupid: yes, i'm trying to split the decoding from vdpau to reuse it without vdpau
<tkaiser> longsleep: You can prevent that by adjusting the cooler table values insanely high. But I would assume they also implement killing of CPU cores so you might end up with just cpu0 left
<GeneralStupid> ahh ;)
<GeneralStupid> https://github.com/jemk/cedrus this repo?
<longsleep> tkaiser: yes even now i am down to 2 cores :)
<jemk> apritzel: i don't know, i would have thought so, but maybe we should check
<tkaiser> longsleep: And cpufreq-ljt-stress-test still running and testing?
<longsleep> yes
<jemk> GeneralStupid: no, this: https://github.com/linux-sunxi/libcedrus.git as linked in the README
<longsleep> for some reason it skipps 1104 MHz now
<tkaiser> longsleep: that's because throttling already adjusted 1008 MHz or below at this moment
<longsleep> ah yeah i am in cooling state 1
<longsleep> with 2 cpus at 67C
bonbons has quit [Quit: Leaving]
<GeneralStupid> jemk: builds
<ssvb> jemk: another random idea is to try to saving/restoring the r0 register to stack in https://github.com/linux-sunxi/sunxi-tools/blob/be1b4c7400161b90437432076360c1f99970f54f/fel.c#L608-L612
<longsleep> tkaiser: well Overall result : PASSED
<ssvb> jemk: if I understand it correctly, usually the BROM saves/restores all the registers before/after running FEL code
<longsleep> tkaiser: didnt crash but i lost 2 cpus on the way
<ssvb> jemk: but maybe they have messed up something in the A80 BROM
premoboss has joined #linux-sunxi
<tkaiser> longsleep: Unfortunately the result is misleading since neither throttling nor killed CPUs were detected.
<apritzel> ssvb: do you do any cache maintenance in your FEL code?
<tkaiser> longsleep: For SMP/throttling the script should check scaling_cur_freq and also compare 'grep -c /proc/cpuinfo' while executing
<ssvb> apritzel: no, because the cache is expected to be disabled
<tkaiser> longsleep: Otherwise it's rather useless on all modern Allwinner SoCs
<apritzel> well, still you may need maintenance ;-)
<jemk> ssvb: i have to verify, but i think this code is ok. it works perfectly after longer poweroff until i begin loading spls that are big enough to need buffer swaps. then it doesn't work anymore until i remove power
<longsleep> tkaiser: yes got it - but i can use the cpuburn-a53 to generate load on all cores and see what happens manually
<tkaiser> longsleep: BTW: Please use this 'grep -c processor /proc/cpuinfo' in your pine64_health.sh instead of the stuff you copied from the RPi-Monitor template
<apritzel> ssvb: cache are really never off on modern ARM cores
<apritzel> I know, it's a mess, but ...
<longsleep> tkaiser: ok
<longsleep> tkaiser: done, also fixed the THz :)
<apritzel> ssvb: I reckon the cache layout is different with the dual cluster configuration
<ssvb> jemk: does everything work seemingly fine after cold boot?
<jemk> ssvb: no, executing the spl still fails, but as long as no buffer swaps occur it doesn't break the dacr read again
<ssvb> jemk: you can try to debug the cold boot first in order to make everything a little bit more deterministic
<longsleep> Who is usually responsible to bring back the cpus, manually works but elsewise they stay disabled.
<ssvb> longsleep: the 3.4 kernel on H3 also does not seem to bring back the CPUs after they had been killed
<longsleep> ssvb: well, that is stupid
<longsleep> i guess some user space tool would be required ..
<ssvb> we have adjusted the FEX for H3 to make killing off the CPUs only the last ditch effort
<longsleep> ssvb: cool thanks, i will have a look
<tkaiser> ssvb: I'm too dumb for ruby but have 2 feature requests for cpufreq-ljt-stress-test: check scaling_cur_freq after setting it and take care whether count of available CPU cores remains the same
matthias_bgg has joined #linux-sunxi
<ssvb> tkaiser: the cpufreq-ljt-stress-test script was a one evening hack :-)
<tkaiser> ssvb: encouraging H3 users to let cpufreq-ljt-stress-test run failed always
<ssvb> yes, we can make something that is more robust and user friendly
<tkaiser> ssvb: Back then with A10 it was sufficient I would think
<longsleep> sounds like a good cause to learn ruby @tkaiser :)
<ssvb> longsleep: nah, we should rewrite this in C, get rid of the dependency on the external libjpeg-turbo package and do everything automagically
<longsleep> ssvb: thats even better, i had to install ruby just for the script :P
<ssvb> also unify all the cpuburn programs, so that they just rely on the runtime CPU type detection
<jemk> ssvb: if i replace first spl-thunk instruction by "bx lr" everything works, a "bx lr" spl fails. so i'll debug the spl-thunk tomorrow, for today i'm out. bye.
<ssvb> longsleep: as I said, it was just a quick hack, developed when debugging data corruption issue on an A10 Lime board :-)
<tkaiser> ssvb: The last idea is dangerous for Pine64 users ;) Especially when 1344 MHz are enabled and cpuburn-a53 simply deadlocks the board within milliseconds ;)
<ssvb> jemk: thanks for your hard work debugging this
<longsleep> tkaiser: ah, that reminds me - what is the voltage for 1344?
<tkaiser> longsleep: Good question. Countless hours running cpufreq-ljt-stress-test might tell after playing around with dvfs settings and adding some safety headroom ;)
<ssvb> tkaiser: the cpuburn program can a) show a big fat warning first explaining possible consequences and b) gradually increase the power consumption instead of running at full blast from the start
<ssvb> tkaiser: but deadlocking clearly indicates that the hardware is not very robust either way
<tkaiser> ssvb: Great idea. That's what I already do: Increasing scaling_max_freq
<ssvb> tkaiser: you mentioned that you had a bad USB cable?
<ssvb> I also had the same problem, and solved it by replacing a generic standard Micro-USB cable with the cable and the PSU that came with my MSI Primo81 tablet
<tkaiser> ssvb: Yeah, I have one 'crappy' cable here but now use one that should be rather good (still no Multimeter bought, I stop comment on things which I couldn't measure ;)
<tkaiser> With the crappy one even running a simple disk benchmark with a host powered SSD led to a deadlock of Pine64
<tkaiser> cpuburn-a53 is evil :)
<tkaiser> 10 secs after increasing cpufreq to 816 MHz already cpu3/cpu2 killed :)
<longsleep> tkaiser: do you use the new dts from earlier or the old one?
<tkaiser> longsleep: An own one: I wanted to play with 1536MHz already ;)
<longsleep> tkaiser: ok, i might just add additional cpu_budget_cool states to avoid killing cpus so early
<tkaiser> But only the cooler table changes are recognized but not the dvfs stuff (I tried to play H3 overvolting with 1.5V).
<longsleep> mhm - sounds like something to investigate :)
<tkaiser> longsleep: Is the .dtb also used by the BSP u-boot?
<longsleep> tkaiser: yes
<longsleep> tkaiser: it seems to use the dtb only, fex file is essentially empty
<ssvb> the Pine64 board is advertised to have a 1.2GHz CPU, the same as some of the competitors (RPi3 and DragonBoard 410c)
<ssvb> if the users find out that it is "only" 1152MHz, there might be a riot :-)
<longsleep> hehe
<tkaiser> longsleep: What I meant: Is the same file on the 1st partition read or is this part of u-boot/initrd?
<longsleep> tkaiser: ah, it is part of u-boot
<longsleep> tkaiser: see https://github.com/longsleep/build-pine64-image/tree/master/u-boot-postprocess if you want to play with it
<tkaiser> longsleep: try out http://pastebin.com/iZd7rWZ9 and you'll be the overclocker hero! ;)
<longsleep> tkaiser: ok let me try
<longsleep> tkaiser: you think it makes a difference when u-boot loads the table?
<tkaiser> ssvb: Enabling the 1200 MHz by adjusting the cooler table might already work.
<tkaiser> longsleep: No idea and didn't looked into the sources which part is responsible for what. At least cooler table can be adjusted by manipulating the .dtb on the first partition of your image.
<ssvb> tkaiser: yes, but then we have to deal with reliability and potential overheating issues
<tkaiser> ssvb: Sure and A64 behaves not that nice regarding overheating
<tkaiser> ssvb: But I think the defaults in the BSP are for a virtual tablet device (according to comments therein)
<longsleep> tkaiser: https://www.stdin.xyz/downloads/people/longsleep/tmp/pine64-images/u-boot-with-dtb.bin - u-boot with your overclocker dtb inside
<tkaiser> longsleep: 404?
<longsleep> its hidden :D
<tkaiser> longsleep: Thanks
<longsleep> tkaiser: ok i am booting now - smoke incoming :D
<longsleep> mhm crashed on boot
<longsleep> Bad mode in Synchronous Abort handler detected, code 0x86000004
* longsleep tries again
<longsleep> now it booted
<longsleep> and crashed again
<longsleep> tkaiser: i think that does not work
<tkaiser> longsleep: :( Scusa
<longsleep> tkaiser: btw, i can confirm that cpuburn-a53 crashes the Pine64 immediately when enabling 1344 as scaling_max
matthias_bgg has quit [Quit: Leaving]
<tkaiser> longsleep: I would suspect that depends on DC-IN and undervoltage due to massively increasing consumption
lamer14568738409 has joined #linux-sunxi
lamer14568738409 has quit [Client Quit]
<longsleep> tkaiser: well my power supply is only 2A, could be related to that as well
* longsleep is out now - good night everone
tkaiser has quit [Ping timeout: 276 seconds]
xenoxaos has joined #linux-sunxi