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
nashpa has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
FergusL has quit [Ping timeout: 240 seconds]
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<wens> apritzel: because the manual is horribly wrong :(
<wens> apritzel: the phys i've seen all have the reset pin, though most boards leave it floating or pull-ed up
<wens> sun6i-a31-hummingbird.dts also has reset gpio
<wens> though a custom snps,reset-gpio property
<wens> as i mentioned to montjoie, i'm hoping the new bus-related power sequencing bindings could be ironed out so we could use them
<wens> so i looked around the esp8089 code
<wens> it seems the only reason it needs to do a double probe is for platform stuff to turn on the chip?
orly_owl has quit [Ping timeout: 260 seconds]
orly_owl has joined #linux-sunxi
reev has joined #linux-sunxi
luoyi has joined #linux-sunxi
<MoeIcenowy> wens: seems that
<MoeIcenowy> the chip will restart after getting the fw
Nacho has quit [Remote host closed the connection]
Nacho has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
robogoat has quit [Ping timeout: 260 seconds]
<wens> i need to take a look at the firmware loading bits then
<MoeIcenowy> wens: I think this problem is raised by the chip's structure
<MoeIcenowy> it's really a MCU with wifi function rather than simply a WiFi card
<MoeIcenowy> so it seems that a chip reset is required to start the firmware from the entry point
robogoat has joined #linux-sunxi
orly_owl has quit [Ping timeout: 246 seconds]
orly_owl has joined #linux-sunxi
robogoat has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has joined #linux-sunxi
robogoat has joined #linux-sunxi
staplr has quit [Remote host closed the connection]
massi_ has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
robogoat has quit [Ping timeout: 252 seconds]
diego_r has joined #linux-sunxi
robogoat has joined #linux-sunxi
premoboss has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
jstein has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
jstein has quit [Remote host closed the connection]
iamfrankenstein1 has joined #linux-sunxi
<wens> audio bits, sun4567i, a23, h3 look similar
<wens> a23 and h3 separate the analog controls onto a separate bus accessed from prcm
iamfrankenstein has quit [Ping timeout: 276 seconds]
iamfrankenstein1 is now known as iamfrankenstein
IgorPec has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> wens: A83T manual wrong: really? Oh dear...
<apritzel> wens: regarding the reset pin: as you said already, it's wired to PD14, which is part of the MAC pins, but it's RGMII_NULL
<apritzel> so I think I take it out of the rgmii_pins DT node, since it must not be configured as an emac pin, but as an output
<apritzel> I did some experiments yesterday with manually resetting the pin, that didn't change anything though
<apritzel> wens: and for i.MX and Tegra boards I also see reset-gpio properties
<wens> apritzel: right
<wens> it really depends on the board
<wens> on some, the reset line is not bridged, and it's pulled up (likely by the phy regulator)
<apritzel> so we should add a (optional) reset-gpio property to the driver
<apritzel> which actually smells like it should be a generic binding
iamfrankenstein1 has joined #linux-sunxi
<wens> there's a discussion about adding this in the phy node
<wens> (and for usb stuff)
<apritzel> ah, I was wondering about this already
iamfrankenstein has quit [Ping timeout: 276 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<wens> it's why i'm hesitant about adding reset-gpios and regulators
<wens> though obviously people need it
<apritzel> I see
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ricardocrudo has joined #linux-sunxi
<wens> great, figured out why PSCI cpu_on wasn't working when completely written in C
<wens> psci_get_cpu_stack_top in asm touches r5 but doesn't restore it :/
robogoat has quit [Ping timeout: 250 seconds]
The_Loko has joined #linux-sunxi
hpeter has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
premoboss has quit [Quit: Sto andando via]
reinforce has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
tomboy65 has quit [Quit: "perl ... arghl"]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 250 seconds]
iamfrankenstein1 is now known as iamfrankenstein
premoboss has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
robogoat has joined #linux-sunxi
<wens> seems i have bad luck
<wens> every time i try to buy a board, it goes out of stock
<KotCzarny> :)
<KotCzarny> opi+2e?
<wens> yeah
<KotCzarny> lol
<KotCzarny> mine is still in transit
<wens> 2 times i tried buying bpi m3
<wens> both times out of stock
<wens> :/
<KotCzarny> search for ebay-like sites?
<KotCzarny> write to banana org and demand one free?
<KotCzarny> ;)
<plaes> yeah, if someone is entitled to free stuff, it would be you :)
<wens> i got one from foxconn folks, hand delivered :)
<plaes> nice
<plaes> btw, I was looking at reset bits in A20 manual (due to new clock stuff) and saw that the A10/A20 reset layout is really messy
<plaes> compared to H3 at least
<wens> they didn't have dedicated reset control registers back then
<plaes> ok, this explais
* plaes hasn't really browsed H3 user manual yet..
<plaes> so Allwinner's SoC design has improved? :)
The_Loko has quit [Quit: Leaving]
bmeneg has quit [Ping timeout: 252 seconds]
<wens> started with a31
bmeneg has joined #linux-sunxi
jemk_ is now known as jemk
jelly has quit [Remote host closed the connection]
diego71 has quit [Ping timeout: 260 seconds]
IgorPec has quit [Ping timeout: 276 seconds]
jelly has joined #linux-sunxi
reev has quit [Ping timeout: 250 seconds]
diego71 has joined #linux-sunxi
jernej has joined #linux-sunxi
focus has quit [Remote host closed the connection]
focus has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
IgorPec111111 has joined #linux-sunxi
leoncito81 has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
leoncito81 has quit [Ping timeout: 250 seconds]
leoncito81 has joined #linux-sunxi
leoncito81 has quit [Remote host closed the connection]
IgorPec111111 has quit [Ping timeout: 260 seconds]
somedude23 has joined #linux-sunxi
FergusL has joined #linux-sunxi
premoboss has quit [Remote host closed the connection]
IgorPec111111 has joined #linux-sunxi
IgorPec111112 has joined #linux-sunxi
dgilmore has quit [Ping timeout: 240 seconds]
IgorPec111111 has quit [Ping timeout: 276 seconds]
reinforce has quit [Quit: Leaving.]
al1o has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
cosm has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
IgorPec111112 has quit [Ping timeout: 276 seconds]
mnr has joined #linux-sunxi
IgorPec111112 has joined #linux-sunxi
zuikis has joined #linux-sunxi
<mnr> Hello, I'm currently trying to get a 64bit mainline (or sunxi-next) build for the pine64 up on apritzel's current firmware build.
<mnr> The first problem I have encountered is that the sun50i pinctrl driver doesn't get build because it isn't selected in Kconfig.
hansg has joined #linux-sunxi
<mnr> There is a Kconfig entry for PINCTRL_SUN50I_A64, but it doesn't have a selectable entry for use in menuconfig et.al.
<apritzel> mnr: yeah, I found this myself already
<mnr> The other pinctrl drivers get selected based on the ARCH_SUNxI values
<apritzel> there was a line doing that for arm64
<mnr> but we don't have ARCH_SUN50I
<apritzel> mnr: and we don't want to have this
<apritzel> LinusW asked me to remove this line to avoid merge conflicts
<mnr> apritzel: how is the selection intended to work?
<apritzel> via a select statement in arch/arm64/Kconfig.platforms
<apritzel> let me find the mail ...
<apritzel> the point is: in the moment mainline is not usable anyway
<apritzel> that's why I didn't bother to send this one line as a fix
<apritzel> mnr: if you want to build a usable kernel, use the a64-v4 (or a64-wip) branch on my github
<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
orly_owl has quit [Ping timeout: 276 seconds]
orly_owl has joined #linux-sunxi
<apritzel> mnr: for reference: this branch should work: https://github.com/apritzel/linux/commits/a64-v4
<mnr> apritzel: Thanks
<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)
<plaes> this is what the new support looks like ^^
<mnr> apritzel: How does that work with interdependencies, such as multiple children with different dividers depending on the same parent clock?
<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]
apritzel1 has joined #linux-sunxi
<willmore> Someone needs to show this to tkaiser: http://www.phoronix.com/scan.php?page=news_item&px=PTS-Watchdog-Module
<mripard> apritzel1: it works perfectly, as long as you don't uncover a bug in the firmware, and then it's A) undebuggable B) unfixable
<mripard> and using UEFI as an example of good practice is always a good joke :)
<NiteHawk> :D mripard, nice one
<apritzel> mripard: I am not talking about UEFI here
<mripard> "< apritzel> on x86 nobody cares about clocks, really"
<apritzel> mripard: and I don't see how it's undebuggable and unfixable
diego_r has quit [Quit: Konversation terminated!]
<apritzel> mripard: which is not UEFI's fault ;-)
hansg has quit [Quit: Leaving]
<mripard> oh, it's ACPI then ?
<mripard> it also applies though :)
<apritzel> ACPI is even worse
cosm has quit [Ping timeout: 260 seconds]
<apritzel> the x86 comparison is a bit misleading, I admit, since it's more due to much different hardware setup in general
<mripard> still, I'm guessing you would hide it in the secure area
<mripard> so, when you want to set a new rate
<mripard> if the firmware tells you that it's done
<mripard> you have no way to actually check the rate programmed
<mripard> neither physically, since you don't have access to that signal
<mripard> nor in the registers, since you cannot even access them anymore
<apritzel> "3.2.16 Get Clock Value Gets the clock frequency value in Hertz (Hz)."
<apritzel> (from the SCPI spec)
<mripard> yes
<mripard> which, if the firmware implementation is broken, can be just a wrong
<plaes> :)
<mripard> most of the factors have a + 1 compared to the value you program
<apritzel> mripard: hey, it's called "TrustZone"
<mripard> if the firmware forgets to take that +1 into account
<mripard> both are wrong
<plaes> mripard: what are the sunxi-clk-ng plans for "legacy" SoCs?
<apritzel> mripard: let me put this straight: I am not talking about vendor provided firmware blobs here
<apritzel> there I can see your concerns
<apritzel> I am talking about _us_ providing this firmware
<apritzel> as OpenSource
<mripard> apritzel: it's not really the point
<mripard> open source or not, it will have bugs
<apritzel> sure, so we fix them
<mripard> if the only answer to a kernel failing is "upgrade your firmware"
<mripard> that's sooo bad, it's not even funny
<mripard> see how many people complain about bios update.
<mripard> and if you want to put that firmware along with the DT on an SPI flash and never touch it again
<mripard> then it doesn't work at all
<mripard> plaes: use the new SoCs (H3, A83T, A64) as testbeds for it
<apritzel> well, then you make sure that the firmware works and is tested
<mripard> once things settle down, move the old SoCs to it
<mripard> leave the current clock code in, so that the old DT still work
<plaes> ok
<mripard> apritzel: except that it directly depends on the kernel support
<mripard> apritzel: how would you make sure today that your audio clock code work
<plaes> I toyed with it today, and trying to see how it would look like on A20
<mripard> without the driver in the kernel in the first place
<mripard> which in turn, needs some clock code in order to test it while you develop it
<mripard> see the chicken / egg issue ? :)
<apritzel> I would expect some firmware updates during initial development
<plaes> but the lack of common reset control registers like H3 has, made things look really awkward..
cosm has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
<mripard> plaes: this is a bit premature I think
<mripard> apritzel: except we're still in development for 5 years old SoCs
<mripard> it's not something I'm really proud of, but it's a fact
apritzel1 has quit [Ping timeout: 244 seconds]
<mripard> plaes: we're still uncovering a bunch of bugs during the reviews
<plaes> I know
<apritzel> mripard: I see that, but I would hope that the clocks are not the real problem
<apritzel> and I OK with updating the firmware if it gives me a new feature
<mripard> I'd rather not convert (and break) old, widely used SoCs
<apritzel> I don't want to make firmware upgrades as complicated as on PCs
<mripard> apritzel: it isn't, but it just means that 5 years down the road, we might discover new bugs
<apritzel> but if the existing kernels (without audio support, for instance) just happen to work anyway?
<mripard> I guess we just have a philosophical disagreement :)
<apritzel> mripard: I know
<mripard> you hate to upgraed the DT, but are fine upgrading the firmware
<mripard> I'm exactly in the opposite situation :)
<apritzel> unfortunately the Ryanair service from Stansted to Toulouse starts only in November :-(
<apritzel> otherwise I would have paid you a visit already ;-)
<apritzel> it's just tedious to explain this via mail or IRC
<mripard> so I guess, if we take the "I want to put the DT in a ROM and never update it ever"
<apritzel> or even discussing this
<mripard> as a valid use case
<apritzel> mripard: I wouldn't do this in ROM
<mripard> then "I want to put the firmware in a ROM and never update it ever" is just as valid
<wens> i don't see much of a difference here with DT vs some other firmware as an API/ABI
<apritzel> so that you _can_ update it, but don't have to
<apritzel> because it remains compatible
<apritzel> so lets take an example:
<apritzel> Pine64: we toy around till we have something working (firmware-wise)
<apritzel> then we release this and it works with current kernels
<apritzel> we make sure we don't break it with newer kernels
<mripard> yes, but you might have to upgrade a component to get that newer kernel working as expected
<apritzel> yes
<mripard> a component that is not packaged by distros
<mripard> let alone reflashed
<apritzel> but as long as it doesn't break existing kernels
<mripard> well, the border is a bit blurrier than that
<mripard> take the DRM driver example
<mripard> we've had so many clocks bugs, it would have needed a firmware update
<mripard> we had simplefb in the past
<mripard> which was working great
<mripard> you introduce the DRM driver
<apritzel> I guess I see your point if you just look at Linux
<mripard> some downstream user upgrades its distros
<mripard> to have the shiny new driver
<mripard> boom, broken
<mripard> technically, you're right
<mripard> the interface hasn't changed
<mripard> it works just as well as it did
* wens &
<mripard> except that for the actual user
<mripard> it's broken
<mripard> then you can explain that it's not the kernel, SCPI and so on
<mripard> but everyone will not even listen, and will be pissed anyway.
<apritzel> mripard: I was just wondering why we are exposing this clock system in such detail to Linux
<apritzel> ?
avph has quit [Ping timeout: 260 seconds]
<apritzel> does Linux really do reparenting and changing frequencies all of the time?
<apritzel> Can't we work out _one_ static clock static setup?
jernej has quit [Quit: Konversation terminated!]
<mripard> well, we do expose the tree topology because we have to make sure that every clock is enabled in our sub-tree, for every clock we enable
<mripard> and then, it really depends on the clocks
<mripard> some will remain entirely static
<mripard> like all the bus clocks
<mripard> or the UART
<mripard> or the timers
<mripard> some will change over time
<mripard> or from one system / board to another
<apritzel> I am just asking because I see a lot of (arm64) platforms with just "fixed-clock" clocks
<mripard> like the NAND, MMC or display clocks
<mripard> the allwinner SoCs are a pita when it comes to clocks
avph has joined #linux-sunxi
<mripard> most other ARM SoCs have a much simpler clock tree
<mripard> but it's the way it is :/
<apritzel> and I wanted to check if we can improve this by hiding this in "firmware"
<apritzel> to provide a common interface, which unfortunately the SoC vendor failed to provide
<apritzel> instead they move bits around :-)
matthias_bgg has left #linux-sunxi ["Leaving"]
<mripard> yeah, but because most of them don't care
somedude23 has quit [Quit: Ex-Chat]
<mripard> on the opposite of the spectrum, the marvell Armada for example just have one PLL for all the peripherals, one array of gates, and that's it
<mripard> plus one PLL for each CPU in the system
avph has quit [Ping timeout: 260 seconds]
<apritzel> mripard: yeah, let's move to those boards, then ;-)
<apritzel> mripard: out of curiosity, are you aiming for 4.8 with your sunxi-clk-ng series?
Netlynx has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
jstein has joined #linux-sunxi
<mripard> for the H3 at least, yeah, that would be great
<mripard> the A64 is not very different, so with some luck, we might be able to support it too
<apritzel> yeah, let me check if that would make my approach impossible ;-)
<apritzel> ideally I wanted to piggy back on it, so provide a "firmware based" clock driver
<apritzel> which provides the same service as a SoC-specific one, but instead is SoC agnostic and relies on firmware to provide the clocks
<apritzel> this could be an experiment for the beginning
<apritzel> so we can have it in parallel
<apritzel> mripard: oh, maybe you know: some anyone ever worked on a mailbox driver for some sunxi chip
<apritzel> the manual calls it "message box", I think
ricardocrudo has quit [Read error: Connection reset by peer]
<mnr> apritzel: the only "mailbox" driver I know of is for communicating with the VC4-firmware on the rpi
<apritzel> I guess the BSP kernel uses them to communicate with the arisc
<apritzel> mnr: thanks, I will take a look then
<apritzel> (not high-priority, though)
IgorPec has joined #linux-sunxi
<apritzel> mnr: btw: did the kernel from my branch work?
<apritzel> (on the Pine64?)
<mnr> apritzel: yes, it boots without problems
<apritzel> that's boring ;-)
<apritzel> I will try to rebase it on sunxi-next later today
gusenkovs_ has joined #linux-sunxi
<gusenkovs_> bpi r1 buggy WiFi Linux 4.4 OpenWrt
staplr has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
gusenkovs_ has quit [Ping timeout: 250 seconds]
lemonzest has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
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
<willmore> The window manager?
<mnr> willmore: container system
<willmore> Ahh.
<willmore> So many acronyms.
<longsleep> err yes, the standard Ubuntu 16.04 container manager - http://www.ubuntu.com/cloud/lxd
<longsleep> its seems nice as it integrates with apparmor by default
apritzel has joined #linux-sunxi
cosm has quit [Quit: Leaving]
<longsleep> wah anyone knows why https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/init/Kconfig?id=refs/tags/v3.10.101#n1112 cannot be enabled when building with XFS_FS?
<longsleep> seems like i killed container support accidentially by enabling XFS :/
<KotCzarny> because bugs?
<KotCzarny> who knows
<KotCzarny> compile mainline and see if it kills containers there too
ricardocrudo has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 244 seconds]
<longsleep> KotCzarny: you are right, in mainline user namespaces do not depend on UIDGID_CONVERTED
<longsleep> KotCzarny: so no XFS in Kernel 3.10 then
jernej has joined #linux-sunxi
fredy has quit [Excess Flood]
igraltist has quit [Remote host closed the connection]
igraltist has joined #linux-sunxi
fredy has joined #linux-sunxi
Nacho___ has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
Nacho has quit [Ping timeout: 276 seconds]
mnr has quit [Quit: leaving]
c5e3 has joined #linux-sunxi
c5e3 has left #linux-sunxi ["Leaving"]
raknaz has joined #linux-sunxi
cyrozap has quit [Ping timeout: 240 seconds]
JohnDoe0 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
ajeandet has joined #linux-sunxi
ajeandet is now known as jeandet
akaizen has quit [Remote host closed the connection]
Netlynx has quit [Quit: Leaving]
raknaz has quit [Quit: raknaz]
<Amit_t_> what it mean by this message while booting ovr USB , SPL: failure code 'eGON'
jstein has quit [Ping timeout: 276 seconds]
bmeneg has quit [Quit: Leaving]
IgorPec has quit [Ping timeout: 276 seconds]
cyrozap has joined #linux-sunxi
<ssvb> hmm, does Orange Pi PC Plus board really have EMMC, but no FEL/Upgrade button?
yann|work has joined #linux-sunxi
<ssvb> if yes, then one might easily brick it by writing some bad firmware on eMMC
<KotCzarny> O.o
<KotCzarny> note to self: dont install uboot to emmc
<KotCzarny> unless it boots sd before emmc
jernej has quit [Ping timeout: 260 seconds]
<ssvb> yes, I'm not completely sure about H3, they keep changing boot priority in different SoCs
<ssvb> the H3 manual says "Support system boot from the following devices: - NAND Flash - SD/TF card - eMMC - Nor Flash"
<ssvb> hmm, the A64 manual says exactly the same (the boot options are listed in the same order)
<ssvb> and eMMC has higher boot priority than the SD card on A64
iamfrankenstein has quit [Quit: iamfrankenstein]
<ssvb> KotCzarny: btw, didn't you order the plus2e board?
Amit_t_ has quit [Quit: Page closed]
<ssvb> so the unbricking feature is included in the "expensive" variant of the board :-)
lemonzest has quit [Quit: Leaving]
ricardocrudo has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
jeandet has quit [Quit: jeandet]
<ssvb> Amit_T: it this all? just 'eGON' and nothing else?
<ssvb> Amit_T: I would guess that it might be one of these two failure types - https://github.com/linux-sunxi/sunxi-tools/blob/ce9cf33606492076b81e1157ba9fc54b56379335/fel-to-spl-thunk.S#L155-L166
<ssvb> NiteHawk: yes, this solution should work too, but not sure about it being more efficient than the other alternatives
<NiteHawk> ssvb: true. the key point is using readl(spl_header + x) instead of spl_header[y]. this avoids the "null pointer dereference"
<ssvb> NiteHawk: your other patch https://gist.github.com/n1tehawk/776bdd1e3f0fdeb04deefbec3b531bdd is a bit smaller :-)
<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]
tsuggs has joined #linux-sunxi
<mripard> apritzel: I don't think anyone did
zuikis has left #linux-sunxi [#linux-sunxi]
JohnDoe0 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
ricardocrudo has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 252 seconds]
Shirasaka-Hazumi has joined #linux-sunxi