<mnr>
apritzel: thanks for the pointer. Just to understand the problems I am seeing: eben with the pinctrl driver compiled in (in sunxi-next), initialization fails:
<mnr>
sun50i-a64-pinctrl: probe of 1c20800.pinctrl failed with error -16
<mnr>
Is there still something missing functionality-wise?
<apritzel>
interesting, didn't see this before
<apritzel>
-16 is EBUSY, right?
IgorPec111112 has quit [Ping timeout: 260 seconds]
<apritzel>
I didn't try it on top of sunxi-next for a while, though
<apritzel>
I think one commit of those is in sunxi-next already
<apritzel>
mnr: ah, what DT are you using?
<mnr>
apritzel: the one you ship with u-boot
<apritzel>
OK, that should work
<mnr>
I have decompiled it with dtc and to me it seems that it should work
<apritzel>
mnr: I think it's the one from the a64-v4 branch
* mnr
does a test build of the a64-v4 branch
<apritzel>
mnr: I think what I tested is the kernel from this branch, I wanted to rebase it once 4.7-rc1 is out
<apritzel>
this is all kind of in jeopardy with mripard's new clock stuff anyway
avph has quit [Ping timeout: 260 seconds]
<mnr>
apritzel: "new clock stuff" is about moving clock driver functionality from C code to dts?
<apritzel>
mnr: well, unfortunately it's effectively the other way round, I am afraid
<apritzel>
the DT part is pretty small, basically a compatible string
<apritzel>
the rest is in the kernel
<mnr>
ok, the whole clock driver framework is still black art to me :-)
<apritzel>
this approach has some advantages and is really better than the current one
<apritzel>
also I like the idea that it keeps the DT stable
<apritzel>
I was toying with the idea of moving the clocks into firmware
avph has joined #linux-sunxi
<mnr>
apritzel: but that would mean that one would need compatible firmware implementations for all platforms, wouldn't it?
<mnr>
Isn't that just placing the problem at another place?
<apritzel>
but there should be _one_ firmware for _one_ board
<apritzel>
and one DT
<apritzel>
possibly multiple OSes
<apritzel>
BSD, Linux, Windows, Xen, you-name-it
<apritzel>
and firmware abstracts the clock stuff
<apritzel>
like it is done one other sane platforms
<mnr>
Sorry if I don't get it: wouldn't that need lots of driver changes?
<apritzel>
So here is the idea:
<apritzel>
you need to enable/disable clocks
<apritzel>
also change the frequency
<apritzel>
I don't see why Linux should be responsible for knowing which exact clock with what divider, what source clock, which enable bit, what frequency
<apritzel>
if all it cares about is: please enable this Ethernet clock
<apritzel>
so we create an interface to firmware at roughly that abstraction level
<apritzel>
and provide _one_ driver (to rule them all)
<apritzel>
if a platform has this kind of firmware, it advertises this feature in the DT and the generic driver takes over
<apritzel>
mnr: if a certain platform has this kind of property, the firmware can handle this
<apritzel>
frankly: this is how it works on many platforms out there
<apritzel>
on x86 nobody cares about clocks, really
<apritzel>
same on many arm64 boards
<mnr>
Well, on x86 one normally doesn't have a bunch of IP blocks driven bei CPU-internal clocks, but usually completely separate PCI devices with their own clock hardware.
<mnr>
s/bei/by/ :-)
<apritzel>
I don't see why this would make a difference
<mnr>
apritzel: No interdependencies
<apritzel>
firmware could take care of this
<apritzel>
if the Ethernet clock for instance depends on some other clock, firmware could just turn it on
<apritzel>
I am not saying this is a walk in the park
<apritzel>
but in the long run is saves us from a lot of troubles
<apritzel>
especially from this new SoC support catchup we play _every_ time a new SoC shows up
scream has joined #linux-sunxi
<apritzel>
merging mostly data driven drivers in the kernel
<mnr>
apritzel: That assumes the SoC vendor provides the firmware, which probably won't work well in practice if we look at the quality of "firmware" (u-boot et.al.) relases SoC vendors usually provide.
<mnr>
apritzel: I see the merit of the idea, but I am sceptical about the pratical part :-)
<apritzel>
mnr: I don't expect SoC vendors to provide anything (anymore), especially not the vendor of popular SoCs discussed in this channel
<apritzel>
we provide the firmware anyway
<apritzel>
we = OpenSource community or linux-sunxi
<mnr>
apritzel: But then I don't get the "we don't need to catch up for new SoCs" argument. We still need to implement the new clock handling for every new SoC, be it in the kernel or in the firmware.
<apritzel>
so instead of crafting yet another clock driver for this new SoC in Linux, we code something in firmware
<apritzel>
but:
<apritzel>
there is _one_ firmware
<apritzel>
and every kernel runs with it out of the box
<apritzel>
even Ubuntu LTS, which came out months before the SoC was even made
<apritzel>
because they use _one_ stable interface
<apritzel>
if the hardware vendor cannot provide a stable clock interface, we should try to wrap this in firmware
<apritzel>
the best thing: there is something close to this already in the kernel: it's called SCPI
yann|work has quit [Ping timeout: 244 seconds]
<apritzel>
that may not cover everything (I need to try it), but it's at least close to this
reinforce has joined #linux-sunxi
scream has quit [Remote host closed the connection]
massi_ has quit [Remote host closed the connection]
cyrozap has quit [Ping timeout: 276 seconds]
cyrozap has joined #linux-sunxi
<longsleep>
Mhm, is it just me or is the Rpi3 unstable, i am tempted to replace it with a Pine64 ..
<mnr>
longsleep: no stability issues on the rpi3 here
<mnr>
longsleep: I have a heatsink on it, though
<mnr>
longsleep: I have found it to be rather sensitive regarding the choice of the powersupply.
<longsleep>
well i have a heatsink and the official psu
<mnr>
longsleep: A powersupply that feeds a cubietruck without problems gives undervoltage on the rpi3 under load
<mnr>
I also use the official PSU, no problems since then
<longsleep>
well, i think its a problem with all the fancy kernel stuff which is used by lxd
<willmore>
I found that I could not run all four cores on the Rpi3 with cpuburn with micro-USB provided power. It was fine if I powered it via the GPIO header, longsleep.
<longsleep>
willmore: yeah that could be it - i was wondering if people have seen crashes on Rpi3 under heavy load with the official micro usb psu
<willmore>
I don't have the official one, though.
<mnr>
I haven't tried synthetic loads like cpuburn, but my pi runs large compile jobs on all cores for days without any hiccup (with the official powes supply)
<willmore>
But I did try several. One known to handle >2A well when charging phones.
<longsleep>
mhm phone chargers are usually "smart" chargers starting with 500mA until told otherwise
<willmore>
mnr, it seems to be an edge case with cpuburn (surprise!). It ran fine with three cores, but when I added that fourth, it went into low voltage downclocking.
<longsleep>
anyhow, crashes seem to be random - kernel nullpointer derefence in some uart functions and full blown 10000+ line kernel oopses
<longsleep>
and now it just works fine again - didnt change anything ..
<willmore>
It wasn't a thermal issue as the SoC was well heatsunk and there was a fan blowing on it. I later verified that it wasn't thermal when I powered it via the GPIO and it ran fine with all four cores of cpuburn and was about 10 degrees under the thermal throttle threshold.
<willmore>
longsleep, are you sure they didn't update the firmware on you? ;)
<longsleep>
willmore: uhm - i get security updates automatically from ubuntu-security
<longsleep>
let me check
<longsleep>
well i think i am running the latest firmware
<longsleep>
raspberrypi-firmware soc:firmware: Attached to firmware from 2016-05-03 17:44
gusenkovs_ has joined #linux-sunxi
<longsleep>
and i am running the official Ubuntu rpi kernel
<longsleep>
4.4.0-1010-raspi2 #13-Ubuntu
<longsleep>
i know its for raspi2 but that does not matter
<willmore>
Interesting. I didn't know there was an 'official' ubuntu for rpi.
gusenkovs_ has quit [Client Quit]
<longsleep>
there is since 15.10 - but only official for rpi2
<mnr>
longsleep: I run a minimal raspian that then starts a Debian container :)
<longsleep>
but now lets come back to sunxi - my BSP Kernel tree for Pine64 now seems to support lxd
<NiteHawk>
it "hides" a bit of the 'true' start of SPL, so i kept looking for something that would preserve the original address. but i can live with that other patch too :D
<ssvb>
I don't have a strong opinion, but we probably want to make this code very small and clean
<ssvb>
just to show that doing all this GPIO and UART programming in bare metal code is really easy
cyrozap has quit [Quit: Client quit]
<ssvb>
the U-Boot SPL is gradually turning into an ugly oversized bloatware, so people trying to read its code might get a very wrong idea :-)
<NiteHawk>
agreed. and it looks like different compiler versions might have enough surprises waiting for us, so keeping the code complexity down is probably a good idea
reinforce has quit [Quit: Leaving.]
<NiteHawk>
you don't want libgcc for uart0-helloworld? 8^)
staplr has quit [Remote host closed the connection]
<ssvb>
I have a local patch here for it :-) to make use of integer division
<ssvb>
added this when prototyping the SPI code
<NiteHawk>
i got bitten by that when trying to add decimal output to the helloworld demo - hex is trivial since it can be done with shifting, but decimal requires modulo or division by 10...
<ssvb>
right :-)
jstein has joined #linux-sunxi
<apritzel>
decimal output is for wimps
<apritzel>
NiteHawk: did you use udiv for that?
<NiteHawk>
apritzel: no, it was just a quick&dirty attempt - so i didn't really investigate alternatives. is udev an arm intrinsic?
<apritzel>
udiv is an (optional) ARMv7 instruction
<apritzel>
but A7s have it
<ssvb>
apritzel: and A8 does not have it
<apritzel>
ssvb: indeed
<apritzel>
ha, just found my ancient div10 implementation in AVR assembler
<apritzel>
(most AVRs don't even have mul ;-)
juri_ has quit [Ping timeout: 252 seconds]
juri_ has joined #linux-sunxi
<KotCzarny>
ssvb: lol
<KotCzarny>
ssvb: seriously, that makes a nice warning to a lesser expensive variant a must ;)
Mr__Anderson has quit [Quit: Leaving.]
jstein has quit [Remote host closed the connection]