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
<vagrantc> but yeah, if the vendor ships a reasonable firmware out of the box, that's great :)
cptG_ has quit [Ping timeout: 260 seconds]
nove has joined #linux-sunxi
<ssvb> vagrantc: for debian nothing really changes, you can still have the firmware images there - http://ftp.uk.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/
<ssvb> vagrantc: but at the same time, the board manufacturer can take exactly the same firmware image (maybe even compiled by debian) and write it into the SPI flash before selling the board
<ssvb> vagrantc: the instructions for updating the firmware over USB OTG in FEL mode is here - https://linux-sunxi.org/Bootable_SPI_flash#Using_the_sunxi-fel_tool
<ssvb> vagrantc: but board vendors can probably use some other method to initially program the SPI flash chip, which is better adapted to their production line
<ssvb> BTW, the "spiflash-write" command of the sunxi-fel tool is not going to be used to update the firmware, but a more high level command will be introduced a bit later
<ssvb> and the "spiflash-write" will refuse to work (unless specifically forced) in the case if the sunxi-fel tool can detect a valid firmware
<vagrantc> sounds good to me
arossdotme-planb has joined #linux-sunxi
arossdotme has quit [Ping timeout: 250 seconds]
George__ has joined #linux-sunxi
vagrantc has quit [Ping timeout: 250 seconds]
iaglium has joined #linux-sunxi
stachhu has quit [Ping timeout: 260 seconds]
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
arossdotme-planb has quit [Ping timeout: 265 seconds]
nove has quit [Quit: nove]
arossdotme has joined #linux-sunxi
mzki has quit [Ping timeout: 252 seconds]
jernej has quit [Ping timeout: 256 seconds]
George__ has left #linux-sunxi ["Leaving"]
popolon has quit [Quit: WeeChat 1.4]
apritzel has quit [Ping timeout: 252 seconds]
Colani1200 has joined #linux-sunxi
<wens> ssvb: the whole base address for a80 is different :|
chomwitt has quit [Ping timeout: 260 seconds]
Colani1210 has quit [Ping timeout: 244 seconds]
cnxsoft has joined #linux-sunxi
<wens> tha hacker news thread is kind of depressing :(
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
arossdotme has quit [Ping timeout: 240 seconds]
jernej has joined #linux-sunxi
robogoat has joined #linux-sunxi
ninolein has quit [Ping timeout: 260 seconds]
ninolein_ has joined #linux-sunxi
arossdotme has joined #linux-sunxi
jernej has quit [Ping timeout: 256 seconds]
arossdotme has quit [Ping timeout: 248 seconds]
arossdotme has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
<MoeIcenowy> wens: do you want to order any H2+/H5 board?
<MoeIcenowy> apritzel: I'm wondering what firmware is shipped with the opipc2
<wens> MoeIcenowy: don't think i have time for it :(
<wens> my pine64 is still gathering dust
<MoeIcenowy> mine is also so
<MoeIcenowy> I still like my Q8 tablet :-) it is at least a full device with input device, graphical output device, battery, WLAN :-)
pg12 has quit [Ping timeout: 260 seconds]
pg12 has joined #linux-sunxi
Putti has quit [Quit: Leaving]
kido` has joined #linux-sunxi
vagrantc has joined #linux-sunxi
stk has quit [Ping timeout: 260 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
Nacho has quit [Ping timeout: 260 seconds]
Nacho has joined #linux-sunxi
stk has joined #linux-sunxi
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
vagrantc has quit [Quit: leaving]
jernej has joined #linux-sunxi
petr has quit [Ping timeout: 250 seconds]
kido` is now known as kido
kido has quit [Changing host]
kido has joined #linux-sunxi
petr has joined #linux-sunxi
repka has joined #linux-sunxi
<KotCzarny> all boards on sunxi wiki should really use including generic templates from the soc pages, then differences and subtleties would follow
<KotCzarny> and for xunlong's 'change one tiny part and release as a new device' it's especially true
yeoldetoast has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
jernej has quit [Ping timeout: 246 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
montjoie has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
leviathanch has joined #linux-sunxi
dpg_ has joined #linux-sunxi
dh1tw has joined #linux-sunxi
stacchu has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
codekipper has joined #linux-sunxi
<codekipper> wens: Hi Wens, is your H3 singing yet?
<wens> codekipper: it is
<wens> i'm still waiting for all the a31 patches to get merged before i post it
<wens> to avoid confusion among the similar drivers
<codekipper> I tried your a23-h3-audio tree with my orange pi2 but I think I killed my device when I removed the audio jack
<codekipper> no longer see the power LED
<wens> huh? O.o
<codekipper> I needed to enable codec and add a enable for the PA which the board has.
<codekipper> when I removed the audio jack(i wasn't hearing anything) there was no more serial logging and I've not been able to get it to boot since
<codekipper> did you enable anything in alsamixer(I ramped up the volume on lineout)
<wens> just the normal controls
<wens> yay, 4 cores on the a80
florianH has joined #linux-sunxi
Putti has joined #linux-sunxi
mrnuke has quit [Ping timeout: 260 seconds]
yann has quit [Ping timeout: 256 seconds]
gianMOD has joined #linux-sunxi
bnw has joined #linux-sunxi
mrnuke has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
bugzc has quit [Ping timeout: 260 seconds]
gianMOD has joined #linux-sunxi
Putti has quit [Ping timeout: 244 seconds]
<ssvb> wens: it's only different on A80, for example the A64 also uses a bit different memory map in general (the 0x10000 load address for the SPL) but still the SoC ID is located at the standard address
<ssvb> somebody just made a bad decision with A80, hopefully they learned from it and will not do this again
dh1tw has joined #linux-sunxi
<ssvb> things like the SID base address and different base addresses for peripherals do not cause much harm as long as we can at least derive them from the SoC ID and the SoC ID is at the standard place
<ssvb> uart0-helloworld-sdboot uses a MIDR check hack for detecting A80 at runtime, but this only works if A80 forever remains the only Cortex-A15 based SoC from Allwinner
matthias_bgg has joined #linux-sunxi
<oliv3r> any info on the H2 yet?
<oliv3r> appearantly the opi zero uses it
<beeble> ssvb: i don't think you will see another a15
apritzel has joined #linux-sunxi
<MoeIcenowy> oliv3r: according to the init code of sun8i
<oliv3r> ssvb: looksl ike 408 is the maximum frequency at maximum ambient temperature. I had one reboot in 4 days runtime, which happend during the weekend (so not sure if that was power related or freq. related)
<MoeIcenowy> H2 is also sun8iw7p1, same as H3
<oliv3r> what is the 'oldest and common' sun8i we currently have
<MoeIcenowy> but with different SID value
<oliv3r> so h2 is a dualcore h3
<MoeIcenowy> maybe
<MoeIcenowy> but
<MoeIcenowy> it is said to be quad core according to http://www.allwinnertech.com/index.php?c=product&a=index&id=62
<oliv3r> ssvb: so at 'normal' ambient temperatures 456 - 432 seems 'fine', but raising it to tropical values makes those unstable. 408 is then the 'max' you'd set if your living on the edge. 384 thus seems to be quite sane
<ssvb> oliv3r: do you have the a10-meminfo logs?
<oliv3r> yeah, but temperature 'independant'
<oliv3r> i'll run a few at diff temperatures in a few days on my super unstable board for your referene
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<ssvb> is the reported dram_zq identical on all your boards when running at different ambient temperatures?
<oliv3r> i'll check later
<oliv3r> standup first; then checking all machines to see if they are still up :)
<KotCzarny> lol, seriously? dual core h3?
<ssvb> the calibrated dram_zq seems to be different on *all* my boards depending on whether it is a cold boot or the SoC had time to heat up a bit, see the last table in https://linux-sunxi.org/A10_DRAM_Controller_Calibration#Finding_good_impedance_settings
reinforce has joined #linux-sunxi
<wens> ssvb: looking at the brom code again, it seems the brom header also stores the soc id
<wens> still this might not be of much use, given the brom is also at a different address :(
<ssvb> the BROM address can be detected by checking the V bit in the SCTRL register - https://github.com/linux-sunxi/sunxi-tools/blob/v1.4/fel-sdboot.S#L65-L68
yann has joined #linux-sunxi
<ssvb> but still we would need to hope that Allwinner never changes the BROM header format, and we can't really count on this
<KotCzarny> do they care about what peopl think of their designs?
popolon has joined #linux-sunxi
<Wizzup> http://linux-sunxi.org/Linux_mainlining_effort#Easy_Tasks mentions smart card reader as easy task - any doc on that?
Putti has joined #linux-sunxi
DullTube has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
<Wizzup> right, SMC pins it seems
montjoie has joined #linux-sunxi
<oliv3r> ssvb: i've re-uploaded the document on http://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2
<oliv3r> ssvb: in a few days (when i have confirmed the stability) i'll perform a few boots @ different temperatures to see how that influences memory timings
<oliv3r> should be able to do quite a nice temperature range (-5 - 70
<KotCzarny> dont forget to let it cool to that temperature before booting
<oliv3r> ssvb: when i find time, i'll also put it in the wikified table :)
<Wizzup> rellla: thank you - I was searching for it
<wens> ssvb: i doubt they would, it seems a part of their toolchain
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
mzki has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
premoboss has joined #linux-sunxi
bnw has quit [Quit: Leaving]
codekipper has quit [Ping timeout: 260 seconds]
repka has quit [Quit: Leaving]
AneoX has joined #linux-sunxi
chomwitt has joined #linux-sunxi
station has quit [Remote host closed the connection]
Keziolio has joined #linux-sunxi
dpg_ has quit [Ping timeout: 256 seconds]
<wens> can't figure out why the gic isn't properly setup for psci on the a80 :/
<apritzel> wens: what's the issue?
premoboss has quit [Ping timeout: 260 seconds]
<wens> apritzel: the ipi used to tell core0 to turn off the calling core isn't setup properly as a secure monitor fiq, so linux gets the interrupt :/
<apritzel> wens: but you already checked that IGROUPR has a zero in there, I suppose?
<apritzel> wens: also NSACR
<apritzel> that's not the National Security Agency control register ;-)
<apritzel> wens: but I guess this stuff already works for the other SoCs
<wens> it already works on other socs, which is why i'm puzzled
<apritzel> so I wonder if there are some isb's missing, the A15 may behave differently here due to its OoO execution
<wens> i only have a7 cores up for now
<wens> not even cci400 is configured
<apritzel> so just little CPUs, one cluster?
<apritzel> (where's the fun in that?)
gianMOD_ has joined #linux-sunxi
gianMOD has quit [Read error: Connection reset by peer]
<wens> multi cluster management requires some more code
<MoeIcenowy> mripard: do you have any idea on my sun4i-drm sun8i bug now?
tkaiser has joined #linux-sunxi
<tkaiser> MoeIcenowy: H3 legacy kernel boots flawlessly on H2+
<MoeIcenowy> tkaiser: you tested it?
<tkaiser> MoeIcenowy: So it's more or less the same :) Nope, IgorPec did. His dev samples arrived this morning.
<MoeIcenowy> So it's really H3- :-)
<IgorPec> yes, it works fine :)
<KotCzarny> 4 or 2 cores?
<IgorPec> 4
<KotCzarny> good
<MoeIcenowy> KotCzarny: according to aw, it's 4
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Changing host]
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy> IgorPec: so what you need to do on opi0 of armbian is only porting xradio driver?
<KotCzarny> MoeIcenowy: you never know with aw ;)
<MoeIcenowy> KotCzarny: ?
<IgorPec> Moeicenowy: exactly
<KotCzarny> so, h2+ should be subsection of h3?
<tkaiser> IgorPec: Is XR819 supposed to support BT also?
<IgorPec> that we need to find out. do we have a docs?
<tkaiser> KotCzarny: Most of 'recent' Allwinner SoCs are just different names for other SoCs. And this one doesn't feature GbE and 4K capabilities and seems to be otherwise an H3
<IgorPec> tkaiser: i got few stuff today ... fwd
<tkaiser> IgorPec: I don't see any UART connection to the chip in schematics. But I am not that good in reading this stuff :)
<IgorPec> i haven't got that far yet. i had troubles with server migration. no more arm :(
<miasma> KotCzarny: i could take a look at the generic templates for the wiki, but need to study how to use mediawiki a bit better first
<miasma> don't people know about the sunxi community or why are they spreading this FUD that sunxi boards have a terrible support and no patches will be mainlined
<MoeIcenowy> The drunk layout of Orange Pi PC 2 is now being a joke between my friends
<MoeIcenowy> It's "Post-modern Art Layout" :-)
<IgorPec> armbianmonitor -u @h2+
gianMOD_ has quit [Remote host closed the connection]
<MoeIcenowy> tkaiser: how to get the datasheet? released from xunlong?
gianMOD has joined #linux-sunxi
<KotCzarny> miasma: terrible support usually means aw/vendors provide very bad code if at all
<tkaiser> IgorPec: did you get more than just datasheet and http://linux-sunxi.org/File:AXP8025.pdf ?
<KotCzarny> and not linux-sunxi community per se
<IgorPec> tkaiser: no, that's all i got
<tkaiser> IgorPec: Thanks. BTW: is this a Samsung EVO you're booting of?
lemonzest has joined #linux-sunxi
<miasma> KotCzarny: yes but there's lots of hardware with no support fom the vendor, but still the community supports them
<miasma> to me it looks like the forums are filled with some sockpuppets spreading FUD
<IgorPec> yes, EVO 32
<MoeIcenowy> I think Xunlong gets many free work from us :-)
<MoeIcenowy> IgorPec: you're adding opi0 support to armbian?
<IgorPec> MoeIcenowy: yes. tkaiser added conf yesterday, we need a wifi driver, few more fixes and we are almost there ...
<tkaiser> MoeIcenowy: I tried to hack together the fex file based on available info and schematics, the board is more or less like OPi One or NanoPi NEO + SDIO Wi-Fi.
<apritzel> so H5 has an internal 100Mbit PHY (like the H3), three (plus one) USB host controllers (like the H3), but the more capable MMC (5.1) from the A64
<montjoie> arrgg H5 does not have RSA/ECC CE
<KotCzarny> :)
<apritzel> montjoie: but RSA is listed, or is that not enough?
<montjoie> where ?
<apritzel> "Support Asymmetrical algorithm: RSA512/1024/2048 bit"
<apritzel> montjoie: page 9
<montjoie> we do not see the same file
<miasma> do the nanopi neo and neo air work with the same u-boot and kernel settings?
<apritzel> montjoie: argh, right, I had the A64 datasheet open as well ;-)
<miasma> i could also update the wiki if someone knows what dtb/uboot defconfigs work with Orange Pi Mini 2 and Orange Pi Plus 2. apparently pcDuino4 Nano could also work with nanopi neo/orange pi one settings
<tkaiser> miasma: Nope, Air needs one config line for eMMC and doesn't need Ethernet
<montjoie> apritzel: my fear is that RSA/ECC is buggy and so removed (and so do not work in previous SoC)
<tkaiser> miasma: And BTW: No H3 device can boot from USB or Ethernet ;)
<IgorPec> tkaiser: i'll try
<tkaiser> miasma: pcDuino4 Nano *is* a NanoPi M1 (which is an OPi One from u-boot perspective)
<miasma> tkaiser: i need to fix that. i thought the latest uboots can netboot and load kernel from usb once they boot from some other media
<tkaiser> miasma: Sure but still the 1st bootloader has to be on SPI flash, SD card or eMMC.
* jonkerj was under the impression that with sun8i emac support in recent u-boot, H3 got DHCP/TFTP/NFS boot
<miasma> jonkerj: yes but it can't boot without local media ffor u-boot
<jonkerj> aah
<jonkerj> you're right
<tkaiser> jonkerj: Situation might/will change when all board vendors solder 8Mb SPI NOR flash on their boards ;)
<miasma> tkaiser: so maybe i'll add that they should all work with orange pi one configs and are actually supported
<miasma> just missing dedicated defconfigs and dtbs
<MoeIcenowy> As I know, Banana Pi R2 is no longer a Allwinner board
<miasma> tkaiser: what about the opi mini 2 / plus 2, is it safe to say they also work with opi one configs
<MoeIcenowy> It's MT7623A
<tkaiser> miasma: Nope, they have SY8106A voltage regulator!
<miasma> so orange pi pc instead?
<MoeIcenowy> I think the SPI NOR Flash may be the reason of the 30 degree placed H5 :-)
<tkaiser> miasma: Mini 2 is like 2 and Plus 2 like Plus and I thought both are supported now by u-boot and mainline kernel?
<miasma> tkaiser: i looked at the generated dtb files yesterday and they were still missing
cnxsoft has quit [Read error: Connection reset by peer]
<MoeIcenowy> Someone of Banana Pi "officially leaked" something about BPI R2 on ##Orz (it's a Chinese channel)
cnxsoft has joined #linux-sunxi
<apritzel> MoeIcenowy: anything you can share in English? Is that a successor to the BPi R1? Which SoC? which switch IC?
<miasma> tkaiser: kernel 4.9-rc4 generates these http://pastebin.com/LmvwynRA
cnxsoft has quit [Client Quit]
gianMOD has quit [Remote host closed the connection]
<tkaiser> miasma: that's ok, Plus is suitable for 'Plus 2' also (just more DRAM and eMMC size) and Mini 2 or 2 Mini or whatever this discontuinued thingie is called can be used with OPi 2 settings
<MoeIcenowy> apritzel: yes; the SoC is MT7623A; Switch is still unknown, but the SoC have two seperate MACs
<apritzel> tkaiser: MoeIcenowy: ah, thanks: so wrong channel then ;-)
<MoeIcenowy> but yes use A20 to make a router is tricky
<wens> that page says the SoC has an embedded switch
<apritzel> but it looks like one could use the EMAC and the GMAC independently on the A20
<MoeIcenowy> EMAC is only 100Mbps... but it may be suitable for a WAN port
<apritzel> it just seems that nobody has tried that
<apritzel> indeed
<apritzel> given that the performance of the GBit isn't much better anyway
<apritzel> I guess there are a lot of people with DSL < 50MBit/s
<MoeIcenowy> apritzel: so I say suitable for a WAN
<apritzel> MoeIcenowy: that's what my "indeed" was for ;-)
DullTube has quit [Quit: Leaving]
<apritzel> ah, boring, already has upstream support ;-)
<tkaiser> apritzel: the MTK chip?
<apritzel> tkaiser: yes
<apritzel> at least basic one, I don't see Ethernet in there, though
<wens> apritzel: dtsi shows only uarts and the basics
<tkaiser> apritzel: Well, for a router... ;)
<apritzel> wens: pfff, device drivers ...
<tkaiser> apritzel: If history repeats then BPi R2 will start with Android only and half of the stuff isn't working :)
<apritzel> tkaiser: and the other half broken?
<tkaiser> apritzel: Almost, yes.
<apritzel> I find Ethernet drivers for the MTK on the list, at least
<apritzel> well, not only that, in fact it seems to be merged, just not in the DT
<apritzel> config NET_MEDIATEK_SOC: "MediaTek MT7623 Gigabit ethernet support"
gianMOD has joined #linux-sunxi
<miasma> tkaiser: by any chance, is there a link for nanopi neo air configs somewhere i could link to? the wiki or the friendlyarm pages don't mention how to enable the emmc/wifi in kernel/u-boot
<miasma> it's the last missing part. after that it looks like the h3 boards are pretty much covered in the wiki
<tkaiser> apritzel: So they will ship with a broken OpenWRT based on 3.10.x and trick users again into believing that all these Bananas would be compatible. And then customers start to try to install Bananian for A20 on it :)
OtakuNekoP has joined #linux-sunxi
<apritzel> tkaiser: which should work with a multi_v7_defconfig kernel
<tkaiser> apritzel: well, the tricky part is controlling the switch but if I understand correctly on MT7623A the switch is behind a separate RGMII interface (which is how it should be)
<apritzel> tkaiser: my understanding as well
<tkaiser> miasma: FriendlyARM folks never looked into mainline u-boot or kernel, they still fiddle around with Allwinner's u-boot 2011.09 (which reads this stuff from fex file)
<tkaiser> apritzel: Anyway I wouldn't buy no new device from famous 'Team BPi' since... worst experience ever so far :)
<tkaiser> Well, maybe BPi M2 Ultra to test R40 SATA performance (they still did not show a single performance result for R40)
<tkaiser> miasma: I'm not that happy with http://linux-sunxi.org/H3#Mainline_status
<miasma> tkaiser: what should be done?
<tkaiser> miasma: Plus 2 *is* Plus just with twice the DRAM and eMMC size. There's nothing you could change in DT to address that. It's perfectly ok to point Plus 2 users to Plus.
<miasma> ok
<tkaiser> miasma: I wouldn't mention pcDuino4 Nano all the time as NanoPi M1 OEM since it is exactly that, they're 100% identical.
<tkaiser> NanoPi M1 on the other hand is identical from a DT point of view with OPi One, just usb2/usb3 need to be enabled in DT and then *everything* already works as expected. Only 'difference' is then led color (blue vs. green)
<MoeIcenowy> tkaiser, apritzel: From the picture from MTK
<MoeIcenowy> on MT7623A switch is behind a TRGMII
<mripard> tkaiser: sooo, not identical then.
<MoeIcenowy> mripard: did you analysed my issue then?
<OtakuNekoP> Uhm... BPI-R1 is designed as a "router-on-a-stick", and the performance of A20 is also not enough for the heavy load. So... U know...
<tkaiser> mripard: From a end user's perspective they're identical and end users also don't understand why usb2/usb3 available on OPi One as solder pads (and *used* by users in real world scenarios) are not enabled in DT.
<Wizzup> Are there any R40 boards yet?
<MoeIcenowy> Wizzup: BPi M2 Ultra
<Wizzup> it's supposed to be mostly a20 compatible, right?
* Wizzup hopes for olimex boards
<mripard> tkaiser: end users don't understand that if you modify the hardware, you should modify the software running on it too?
<miasma> tkaiser: but the nanopi m1 page recommends using opi pc configs for u-boot, not opi one
eduardas_m has joined #linux-sunxi
<tkaiser> mripard: No end users want to use hardware without having to fiddle around with dtc tool. It's really that way. They also don't understand why on NanoPi NEO only usb3 is defined since they use usb1/usb2 available on the GPIO header too.
<OtakuNekoP> MoeIcenowy: M2U will maybe in stock at the end of Nov.
<tkaiser> miasma: Reason is simple: Since in OPi One DT usb1 and usb2 are disabled!
<mripard> and pointing to other random DT is not a really good idea anyway
<tkaiser> miasma: Sorry, usb2 and usb3
eduardas_m has quit [Remote host closed the connection]
<miasma> tkaiser, so the different regulator won't cause any issues with a different DT?
<tkaiser> mripard: It's not that random since those board makers copy their own and other designs. I fiddled around with the DT equivalent (fex files) and required changes between those boards are minimal.
<mripard> tkaiser: then too bad for them, because it really should be done that way.
<mripard> tkaiser: minimal != 0
<MoeIcenowy> mripard: end users don't know "if you modify the hardware, you should modify the software running on it too" today, because of the success of IBM-compatible PCs
<tkaiser> miasma: It does and that's a problem. So until an own DT is available for this device users relying on unpatched mainline stuff have to choose between two sorts of misfunction.
<mripard> and I see two majors issues with that. It creates a culture of "using other DT in general is fine" while it's really not
<MoeIcenowy> maybe better to patch to add a dt.
<miasma> i think even the DT stuff is going to be a mess without x86 pc like compatibility but it's really hard to keep track of all the minimal changes. would be easier if there were defconfigs for each board even they were identical
<mripard> and it makes it impossible for us to fix that one issue when it turns out that it was not exactly the same thing after all
<mripard> MoeIcenowy: that's a bogus argument. You can't add a non-discoverable device on a PC either
<tkaiser> mripard: Sure, but Armbian has a quite huge user base and we get a lot of feedback if stuff doesn't work. And H3 boards are all more or less the same with the main exception being the voltage regulation which requires individual treatment.
<tkaiser> I hope that situation with DT overlays will improve.
<apritzel> I wonder if the DTs should be patched / generated in firmware then, given that we have board specific U-Boots anyway
<tkaiser> Since *then* a NanoPi NEO user can use all 4 USB ports instead of just 2 as it's now for reasons I fail to understand.
<MoeIcenowy> mripard: someone can, such as you and me and others here
<MoeIcenowy> but we know the sentence
<mripard> tkaiser: and I'm not sure how that relates to things that work or don't work
<mripard> my point is we want one DT per board
<MoeIcenowy> maybe we should say "one DT per compatibility board"
<tkaiser> Just curious: new Orange Pi Zero exposes USB OTG and one host port as type A port and the other 2 USB host ports on a 13 pin header. How should DT look like? usb2/usb3 disabled by default or not?
<mripard> I don't care how much they have in common, we can have as many includes as we want and share the common stuff that way
<tkaiser> mripard: I fully agree with 'one DT per board'
<miasma> mripard: so what would be the next step to reach there? someone posts the new stuff to linux arm ml? does the upstream know the exact list of missing h3 board DTs?
<MoeIcenowy> miasma: mripard is the upstream maintainer of sunxi dts
<miasma> :P
<MoeIcenowy> and if there's a board that he do not know but you know, you can send your dt patch, and he will then know :-)
<mripard> miasma: I don't but I'd be glad that you show me that list by sending patches :)
<tkaiser> mripard: and who maintains u-boot patches for sunxi/H3 boards?
<mripard> hans
<MoeIcenowy> Hans de Goede
<MoeIcenowy> You can retrieve his email in MAINTAINERS file of U-Boot
<MoeIcenowy> he do not use IRC.
<miasma> mripard: i tried to document the situation a bit by updating the wiki. hopefully it will help a bit so people don't need to ask tkaiser again and again :)
mhlavink_away has quit [Ping timeout: 245 seconds]
<MoeIcenowy> you can try to send out a dt patch
<MoeIcenowy> this may be your way to enter kernel contributing :-)
reinforce has quit [Quit: Leaving.]
<tkaiser> miasma: Mini 2 is like 2 just with 8189ETV not soldered: http://linux-sunxi.org/File:Xunlong_Orangepi_mini2_front.jpg
<tkaiser> So using the DT for OPi 2 is _wrong_ :)
f0xx has joined #linux-sunxi
<tkaiser> In Armbian we don't care about that at all since there we have now a mechanism which checks SDIO and if there's nothing then no Wi-Fi driver is loaded.
<MoeIcenowy> in mainline SDIO can get autoprobed...
<mripard> miasma: we won't maintain the armbian patches though
<MoeIcenowy> miasma: you can try to mainlinize armbian patches
<MoeIcenowy> it will be an advance for both armbian and mainline
<tkaiser> mripard: MoeIcenowy: That's a perfect example: Are users allowed to use DT for OPi 2 on OPi 2 Mini (which *only* lacks the SDIO Wi-Fi chip is otherwise 100% identical)?
<miasma> MoeIcenowy: i don't use armbian :)
<MoeIcenowy> tkaiser: I think the answer is "yes", as it's the same situation we met on Q8s
<MoeIcenowy> some Q8s use USB Wi-Fi, some SDIO Wi-Fi
<MoeIcenowy> so on Q8 general dt, both is enabled
<tkaiser> So stuff is enabled in DT that is missing in reality?
<MoeIcenowy> only for autoprobed buses
<MoeIcenowy> This is my own thoughts
<MoeIcenowy> mripard may not agree
<tkaiser> So why is then usb2/usb3 disabled in OPi One DT or now usb1/usb2 in NanoPi NEO DT (there the available USB port is usb3 for whatever reasons)?
<tkaiser> And how to deal with OPi Zero with 2 USB ports available only on a populated pin header (I know already one guy currently buying a crimp tool for Dupont wires for exactly this reason)
<MoeIcenowy> they are only available for high-level users which can solder a USB port.
<MoeIcenowy> for example, the hardware destroyer, me, cannot use the USB ports :-)
<tkaiser> MoeIcenowy: On OPi Zero if you want to connect the USB touch panel controller to the board you don't need to solder. Jumper wires are enough.
<MoeIcenowy> My opinion is to enable it
<MoeIcenowy> but the final result should be decided by mripard
<MoeIcenowy> I think I can connect some USB Low Speed (1.2Mbps) devices on the bus with Dupont wires
<miasma> so what's the main problem with usb ports enabled that are not physically accessible without soldering? too many usb root nodes that might confuse people?
<tkaiser> miasma: The average users considers USB plug&play and is never confused by root nodes since he not even knows what that might be
paulk-minnie has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<KotCzarny> hmm, is there a way to use usb without dt?
<KotCzarny> via direct module param etc?
f0xx has quit [Quit: terminated!]
<KotCzarny> would solve 'too many dts for single changes'
f0xx has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<wens> KotCzarny: nope
<KotCzarny> wens, even without rewriting usb host driver?
<KotCzarny> s/without/with/
<apritzel> If you need to tinker with the DT, this could be done in U-Boot
<apritzel> Because the kernel does not necessarily need to see the exact DT which is in the source tree
<KotCzarny> nah, i was thinking moving detection to linux driver
<apritzel> you can't reliably detect this
<apritzel> but you can take short cuts in U-Boot, since this is confined to a small number of boards
<tkaiser> apritzel: Yeah, but it's about defaults. When OPi One was available we started with all 3 USB host ports enabled (only 1 host port available as type A receptacle). Then I disabled the two available through solder pads and immediately Armbian users complained.
<KotCzarny> apritzel, it could be easier to autodetect board type/model from linux
<KotCzarny> then you can apply list of known configs in single driver
<apritzel> KotCzarny: why so?
<KotCzarny> single driver vs multitude of dts
<apritzel> Linux is a portable OS, it shouldn't be bothered with detecting every crappy board out there
<tkaiser> And the same 'problem' applies to NanoPi NEO, Air and now OPi Zero. They all have USB ports available on GPIO headers
<apritzel> that's a task of firmware
<KotCzarny> sure, but we dont have any firmware
<wens> how are you supposed to detect it anyway?
<apritzel> KotCzarny: U-Boot fills the gap (for 32-bit boards at least)
<tkaiser> The problem is not a technical but one of the perspective: the tinkerer out there buys the board since he wants to use USB on the pin headers and kernel devs don't want that.
<KotCzarny> apritzel, but technically, would it be possible ?
<apritzel> the point is: the policy whether to not expose non-mounted connectors in the DT is a Linux policy
<tkaiser> KotCzarny: There's nothing to detect, it's just different understandings about enabling hardware or not. The users want to use hardware but can't without tweaking defaults.
<apritzel> surely U-Boot can override this, even by user's command
<apritzel> you could set some env variables for that, for instance
<miasma> apritzel: and the point of rpi zero / nanopi neo / opi zero is to expose crucial stuff via non-mounted connectors :P
f0xx has quit [Ping timeout: 268 seconds]
<apritzel> miasma: barking at the wrong tree, I am not a big fan of not exposing non-mounted connectors either
<apritzel> KotCzarny: you can detect some parts (like SDIO devices)
<apritzel> for others (like USB connectors) you could either let the user select
<apritzel> or you could patch the DT anyway
<KotCzarny> but main difference between same-soc boards are usb ports and regulator circuits
<KotCzarny> gpio and maybe some additional ports
<apritzel> question is whether the USB pins are multiplexed with other pins on some headers
<ssvb> mripard: should every revision of each board have its own dts?
<tkaiser> apritzel: On the aforementioned H3 boards that's not the case
<KotCzarny> ssvb: if they differ ;)
camh has quit [Ping timeout: 260 seconds]
gianMOD has quit [Remote host closed the connection]
<apritzel> ssvb: the kernel should see a matching DT for the board
<ssvb> mripard: for example, the Lime2 board has 7 revisions (from A to G) - https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A20-OLinuXino-LIME2
<wens> apritzel: for allwinner, _most_ usb host pins are dedicated
<apritzel> ssvb: whether we need separate DT files in the kernel source is a different question
<apritzel> wens: I was thinking so
<apritzel> So I don't see many issues with enabling them then
<KotCzarny> imo usb driver should detect board model
<apritzel> KotCzarny: no
<apritzel> the USB driver drives some IP and must not be bothered with something like a board
<ssvb> KotCzarny: ask mripard, being paranoid, he probably does not rule out the possibility that they might be different ;-)
<KotCzarny> then welcome to the dts hell
<KotCzarny> ;)
<KotCzarny> and image f*cktitude hell
<KotCzarny> ssvb's installer could solve this if the idea caught on
<apritzel> KotCzarny: we can do some form of detection, but not in Linux
<apritzel> just do it in U-Boot, problem solved
<apritzel> U-Boot builds are quite board specific anyway, so you can try to differentiate between a small number of board variants
<KotCzarny> apritzel, im thinking from 'minimize the images count' perspective
<apritzel> then patch the DT accordingly, by turning status="disabled" into status="okay"
<apritzel> KotCzarny: sure, one U-Boot to support multiple board, where the exact model can be detected at runtime
gianMOD has joined #linux-sunxi
mhlavink has joined #linux-sunxi
<apritzel> and: we don't explicitly load DTs on the U-Boot command line, but use the one the U-Boot already uses itself
<KotCzarny> anyone tried such detection?
<apritzel> and which it possibly patches
<apritzel> KotCzarny: take for instance the Pine64: 512 MB model -> 100 MBit PHY, >= 1G: 1GBit PHY
<KotCzarny> because all i've seen is one image -- one board
reinforce has joined #linux-sunxi
<apritzel> we have one image for both boards (because DRAM can be autodetected), the derive the rest from there
<apritzel> KotCzarny: yes, because this has been done for years :-(
<tkaiser> KotCzarny: In case of Armbian and the flood of H3 devices we simply had to give up an _auto_ detection since the devices are too similar.
<tkaiser> But ssvb's idea is different
<KotCzarny> tkaiser, is it working? ie. from user's perspective
<tkaiser> KotCzarny: What?
<KotCzarny> or its still split in different makers/boards at places
<ssvb> apritzel: and now imagine one more different Pine64 revision with 1GB RAM
<KotCzarny> (in other words, how many images are there for h3 based boards)
<apritzel> ssvb: we don't need to support every theoretically possible board under the sun
<tkaiser> KotCzarny: For each H3 device on with the exceptions of 'Mini 2' (same as 2) and 'Plus 2' (same as Plus)
<apritzel> ssvb: there is one image which supports known boards
<ssvb> apritzel: the point is that in this case the DRAM based autodetection will fail
<KotCzarny> heh
<apritzel> ssvb: it is not the solution for every problem, but better than what we have today (one image for each known board)
<tkaiser> KotCzarny: But we could provide 2 images and let the user decice on firstrun (which some like and others don't)
<miasma> hmm, I didn't find any regulator related diffs between e.g. opi pc/one dts files. so apparently it's handled elsewhere
<ssvb> apritzel: yes, it's a nice hack, but it does not scale
<apritzel> one image per board does not scale at all
<tkaiser> KotCzarny: And 2 images only since there's a bug in legacy kernel Ethernet driver which would lead to a crash when Fast Ethernet is activated but it's GbE and vice versa.
<apritzel> ssvb: as I said: it's not mean to scale for _every_ board, just for a subset
f0xx has joined #linux-sunxi
<tkaiser> miasma: dvfs/cpufreq scaling didn't arrive mainline so currently there's nothing.
<ssvb> one image per board is what we have now and users are somewhat familiar with
<ssvb> the right solution is having the board identifier stored in a built-in non-volatile memory
<tkaiser> apritzel: Based on experiences with H3 this doesn't work. I second ssvb totally here.
<ssvb> and with SPI flash we are probably moving there
<apritzel> ssvb: sure, that should solve this even better
<apritzel> ssvb: but that isn't reality yet, unfortunately
<mripard> tkaiser: in my mind, no, you shouldn't enable something that is not physically available on the board
<mripard> so, in your OPi2 vs OPi2 mini example, we'd need two DT.
<tkaiser> mripard: And what about USB on OPi Zero? Physically available on a 13 pin header? The header is populated.
camh has joined #linux-sunxi
<ssvb> mripard: I'm interpreting your silence as having no arguments against having a separate dts file for every possible board revision
<ssvb> mripard: when are you going to implement this?
<mripard> ssvb: you should interpret my silence for what it really is: being offline.
<ssvb> :)
avph has quit [Ping timeout: 260 seconds]
<mripard> ssvb: and if they are different, then yes, we'll probably have to have something like that at some point if we don't have a way to autodetect it
lamer14786200075 has joined #linux-sunxi
lamer14786200075 has quit [Client Quit]
paulk-minnie has quit [Quit: Leaving]
Gerwin_J has joined #linux-sunxi
<mripard> tkaiser: and the question should really be: is it usable by default?
avph has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
The_Loko has joined #linux-sunxi
<tkaiser> mripard: Sure, people started immediately to solder USB peripherals to NanoPi NEO (unpopulated) header, used pogo pins with OPi Lite and One and now they'll use jumper wires to control eg. the USB TS interface of an LCD (that's one use case I heard of)
<beeble> if you solder something onto your board you should be able to change your dts
<beeble> thats my opinion
<beeble> because the dts describes your board and you have changed it
<tkaiser> There's no need to solder anything, it's a populated pin header with 2 x USB 2.0 on it, also CVBS, Mic and line out
<tkaiser> These ports are physically exposed and people buy these devices exactly for *this* reason.
<apritzel> tkaiser: so those USB pins are not multiplexed with GPIOs?
<beeble> tkaiser: i was just referring your "to solder USB peripherals to NanoPi NEO (unpopulated) header, used pogo pins [...]"
<tkaiser> apritzel: Nope, on none of these H3 devices.
<apritzel> tkaiser: then they qualify for a standard DT, I think
<ssvb> since the USB pins can't be used for any other function (unless I'm mistaken), do we lose anything by just enabling them as USB?
<tkaiser> beeble: But have you ever looked at the NanoPi NEO. This board is made for hardware tinkerers that do not even not how to enter single user mode in Linux.
<tkaiser> They use smelly OS images from hardware vendors relying on crappy Android kernels and enjoy dealing with hardware. As soon as they switch to mainline kernel fun is over and a lot of stuff works any more for no apparent reason.
<ssvb> are people worried about power consumption? or have some other concern?
<tkaiser> That's the problem people experience with this 'RPi header' be it 40 or 26 pins
<beeble> tkaiser: i'm ok with having the exposed pins in the default dts, especially if it's a single purpose function
<tkaiser> ssvb: I measured consumption on H3 boards, regarding USB it's all or nothing. Only if you disable all USB ports you get some savings
<beeble> but if you have i2c on your header for example you will change your dts for sure. as long as you don't just use it via sysfs usermode
<beeble> same for spi
<tkaiser> beeble: Sure, but those consumer oriented SBC that feature the RPi compatible header... there people expect these interfaces at the usual pins
<beeble> mainline kernel even gives you a nice oops if you have spidev in the dts
<tkaiser> beeble: Exactly
<wens> apritzel: fyi i've no problem enabling dedicated perihperals available on pin headers
<apritzel> wens: I think nobody has, the rationale was to avoid this if for instance GPIOs are multiplexed on those pins as well
deskwizard has quit [Remote host closed the connection]
deskwizard has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
<wens> apritzel: for those my view is if the vendor explicitly states that X pin is for Y function, then we enable it by default
<apritzel> wens: I agree
<apritzel> (it's a dedicated connector, just not a standard one)
<beeble> tkaiser: having sane defaults for the header should be a goal imho
<wens> apritzel: i was thinking the rpi-compatible headers
<apritzel> wens: oh
* wens &
<apritzel> wens: well, I agree to a certain point as well, but I can see mripard's point as well (people could be using them as GPIOs)
<apritzel> I had this discussion with him about UART pins, for instance
<miasma> i don't think the xunlong's manuals for h3 boards show all the multiplexed functions for pins
<miasma> maybe the schematics show, but i couldn't decipher them fully
<apritzel> miasma: but the SoC's datasheet does
<NiteHawk> the .dts arguments are especially relevant for boards that can take peripheral "shields" as add-ons, which might fulfil different functions and require a variety of (GPIO) pin assignments. in those cases, using dedicated .dts (or at least overlays) makes sense
HeavyMetal has quit [Ping timeout: 245 seconds]
station has joined #linux-sunxi
jernej has joined #linux-sunxi
<tkaiser> NiteHawk: But then DT overlays would be the way to go just like the RPi folks did: https://www.raspberrypi.org/documentation/configuration/device-tree.md
<tkaiser> But based on some experiences with Armbian users they expect at least the pin assignments on the RPi header are the same as they were back then when they used the vendor OS image relying on kernel 3.4 (and that's following RPi HAT defaults)
f0xx has quit [Ping timeout: 260 seconds]
<mripard> tkaiser: my main worry with always enabling USB no matter what is that we'll never be able to do proper power management on most boards
<mripard> because once it's in, there's no way to remove it
netlynx has joined #linux-sunxi
<tkaiser> mripard: Ok, my previous testings were all done with BSP kernel (where it's 'all or nothing') so with mainline kernel if the nodes are defined then consumption increases?
<apritzel> mripard: what do you mean with "it's in" and "remove it"? From the actual board DT?
The_Loko has quit [Ping timeout: 256 seconds]
\\Mr_C\\ has quit [Quit: .]
<ssvb> is this a new revision of the Lime2 board?
The_Loko has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
gianMOD has quit [Remote host closed the connection]
<ssvb> mripard: lol, nice timing ^
<Wizzup> ssvb: I think they have an internal revision replacing the phy
<ssvb> if the PHY revision can be detected at runtime, do we still need a separate dts file for the whole board?
<Wizzup> Rev I, I think, but maybe I am just being silly
paulk-collins has joined #linux-sunxi
<mripard> apritzel: yes, if we enable the USB by default for those who might solder something on those headers to use USB, we have regulators enabled for nothing (for the rest of the users)
<mripard> and if one day the time comes where we want to do proper power management, we can't disable them either because it used to be there
<ssvb> x86 solves this particular problem by having a configuration option in the BIOS setup...
<MoeIcenowy> ok we need a bios now :-)
<mripard> or to apply an overlay with u-boot, which we can do now
<MoeIcenowy> in fact the BIOS I mean is also a specially designed U-Boot bootmenu
<MoeIcenowy> for example we can use uEnv to store the situations
<MoeIcenowy> will a uEnv on SPI NOR Flash finally break the Flash block?
alexvf has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<oliv3r> ssvb: yeah the rev g. comes with an rtl8211E (i think). la performance is grray. 960 m it on iperf
<oliv3r> (cold cold fingers here )
<oliv3r> but with my patch we do not eed a sep. dtb as thry both speak rgmii with the same driver
<oliv3r> i think it is a 'xilent upgrade' as users wont notice it
camh has quit [Ping timeout: 248 seconds]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
<tkaiser> BTW: Regarding USB and 'unpopulated' headers, this is just another example (see picture 3): http://blog.unixbigot.id.au/2016/11/safety-first-iot-part-1-getting-started.html
gianMOD has quit [Ping timeout: 245 seconds]
lkcl has quit [Ping timeout: 248 seconds]
camh has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has quit [Changing host]
Ixnus has joined #linux-sunxi
<ssvb> mripard: it's mostly the same thing, the point is that the firmware (u-boot and friends) updates the hardware description (the device tree)
<ssvb> the rest is all about just making it user friendly
<Ixnus> Please excuse me, but is the argument: the "crap" Allwinner BSP does it so copy it in the mainline ?
<ssvb> MoeIcenowy: uEnv or maybe some UEFI variables
<MoeIcenowy> yes
<Ixnus> And the other argument is: there are 2 users of one distribution that are skillfull enough to read technical documentation and soldier but are annoyed to change one line of code ?
<Ixnus> solder*
yann-kaelig has joined #linux-sunxi
<ssvb> Ixnus: yeah, the BSP is "crap", so let's do exactly the opposite :)
<MoeIcenowy> I think I can make a "Sunxi BIOS" PoC in several minutes, which can control one feature :-)
<MoeIcenowy> and maybe the idea of "Sunxi BIOS" can solve the LCD panel problem of A33 Q8
<MoeIcenowy> wens: ^
<ssvb> MoeIcenowy: there is more than one way to do this - https://linux-sunxi.org/Bootable_SPI_flash#Information_for_devboard_designers
<MoeIcenowy> yes
<ssvb> and when we get the Orange Pi PC 2 board, we can implement something
<MoeIcenowy> even users without a SPI Flash can also benefit from such a BIOS
<MoeIcenowy> my opipc2 should reach tomorrow
<ssvb> well, you will have to deal with distro maintainers and convince them that using your "BIOS" is a good idea
<ssvb> most likely they will just stick with the baseline U-Boot and not bother with anything else
<mripard> and then convince your users that all the documentation written for all the other Allwinner boards doesn't apply here
<ssvb> what do you mean?
<MoeIcenowy> or maybe we can make it a plugin of baseline U-Boot
<MoeIcenowy> for example, an enhanced boot.scr
<ssvb> still with the SPI flash, we are decoupling the firmware from the distro and preferably shipping the firmware pre-installed on the board
<mripard> ssvb: that having anything that deviates from the other boards will be a pain, because all the documentation written everywhere will not apply anymore
<MoeIcenowy> ssvb: yes
<ssvb> mripard: first - it does not have to deviate much, second - who said that it is not going to be documented?
<MoeIcenowy> but there may also be users without SPI Flash want to install it
<MoeIcenowy> for example, I use many boot.scr fdt command hacks recently to use sun8i-a33-q8-tablet.dtb to driver all my devices' capabilities possible
<mripard> ssvb: I didn't say it wouldn't be. I said all the previous documentation, howto, tutorials, etc. would not apply anymore
Ixnus has quit [Quit: Page closed]
<MoeIcenowy> we have kill so many documentations, and won't be worse to kill one more :-)
<ssvb> mripard: the sunxi related U-Boot documentation is nonexistent anyway, Hans never bothered to write it :-)
<ssvb> only apritzel has written some nice Pine64 installation readme for U-Boot
matthias_bgg has quit [Quit: Leaving]
<mripard> ssvb: I was also talking about what is on the wiki, on the blog post out there
chomwitt has quit [Ping timeout: 250 seconds]
<mripard> basically everything that shows up when you google "allwinner + <something>"
bugzc has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
OtakuNekoP has quit [Quit: Page closed]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
dpg_ has joined #linux-sunxi
<tkaiser> IgorPec: In case you want to do today something related to OPi Zero: Just tried to fix Wi-Fi and led assignment in fex file. Would be nice if you could give it a try.
f0xx has joined #linux-sunxi
<tkaiser> IgorPec: But either schematics are wrong regarding red led or vendor fex ;)
<IgorPec> tkaiser: i am not sure i'll do this today, perhaps in the morning.
apritzel has joined #linux-sunxi
<IgorPec> most likely something is mixed up
<IgorPec> the driver code had also some syntax errors ... amazing
<IgorPec> tkaiser: aha, i can try those fex changes
<tkaiser> IgorPec: As you like. Might also be an idea to try out Xunlong's Lubuntu image before to see whether Wi-Fi works there. And then it would be great if you've an eye on the red led. They define it as PA17 but according to schematics it's PA15 as on every other H3 device out there except of Beelink X2
<IgorPec> you might downloaded this Lubuntu? Google drive link is n/a .. Baidu rocks :)
<tkaiser> IgorPec: Yeah I used also Baidu -- 4 MB/s :)
<tkaiser> bddown_cli.py download http://pan.baidu.com/s/1gf3EYBL
<IgorPec> [ 45.377465] [XRADIO] Driver Label:L34M.01.08.0002 Nov 8 2016 15:54:41
<IgorPec> [ 45.390875] [XRADIO_ERR] Access_file failed, path:/data/xr_wifi.conf!
<IgorPec> [ 45.385247] [XRADIO] Allocated hw_priv @ c4d91240
<IgorPec> there is some other progress
iamfrankenstein has quit [Quit: iamfrankenstein]
<tkaiser> IgorPec: You could check PA20 (WIFI-POWER-EN) with sunxi-pio
<IgorPec> PA20<1><0><1><0>
<IgorPec> yes, better now
<IgorPec> if i enable
premoboss has joined #linux-sunxi
<tkaiser> IgorPec: Don't remember exactly what jernej said. 'echo 123' to some sysfs node to get SDIO auto detection with BSP kernel?
<jernej> tkaiser: That should not be needed anymore. Also it seems that driver is already autoloaded.
<tkaiser> jernej: true
<mdsrv> echo
<mdsrv> e c h o
<jernej> tkaiser: IgorPec: echo "123" > /proc/driver/wifi-pm/power
<jernej> if you want to power down, just replace with "000"
<IgorPec> but it looks like something else is wrong
<IgorPec> [ 30.888992] [wifi_pm]: set wl_reg_on 1 !
<IgorPec> [ 31.045195] [mmc]: sdc1 power_supply is null
<IgorPec> [ 30.994856] [mmc]: sdc1 power_supply is null
<IgorPec> [ 31.049294] [mmc]: sdc1 power_supply is null
<IgorPec> [ 30.993301] [wifi_pm]: get wifi_sdc_id failed
<IgorPec> [ 31.108539] [mmc]: sdc1 power_supply is null
<IgorPec> [ 31.112621] [mmc]: sdc1 power_supply is null
<IgorPec> [ 31.175192] [mmc]: sdc1 power_supply is null
<IgorPec> [ 31.179286] [mmc]: sdc1 power_supply is null
<IgorPec> [ 31.252927] [mmc]: sdc1 power_supply is null
gianMOD has joined #linux-sunxi
<IgorPec> this is when powering manually and loading the module again
<IgorPec> firmware is in place
gianMOD has quit [Remote host closed the connection]
<tkaiser> IgorPec: Think I got it. My mistake: should read 'module_power0_vol = 1'
<tkaiser> IgorPec: Please check whether you can trigger red led. Since I assume vendor fex is wrong here and it's not PA17 but the default value
<IgorPec> [ 1.516676] no blue_led, ignore it!
<IgorPec> [ 1.517407] no led_0, ignore it!
<IgorPec> [ 1.517424] no led_1, ignore it!
<IgorPec> [ 1.517375] Registered led device: green_led
<IgorPec> [ 1.517143] Registered led device: red_led
<IgorPec> [ 1.517454] no led_3, ignore it!
<IgorPec> [ 1.517439] no led_2, ignore it!
<IgorPec> [ 1.517468] no led_4, ignore it!
<IgorPec> [ 1.517483] no led_5, ignore it!
<IgorPec> [ 1.517498] no led_6, ignore it!
<IgorPec> [ 1.517513] no led_7, ignore it!
<IgorPec> i guess leds are ok
<IgorPec> one moment to prove
<tkaiser> IgorPec: Defined yes, please try to set trigger to default-on
<IgorPec> yes it works
<jernej> wifi?
<tkaiser> led?
<IgorPec> no, red led :)
<tkaiser> Strange, then schematics is wrong :(
<IgorPec> at least auto driver loading works
<IgorPec> but it's not going up
<jernej> Please try to set up PA20 in u-boot and then load the kernel
<tkaiser> IgorPec: And in case you've another 5 minutes I would be interested in output from armbianmonitor -m (pastebin) while 'sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4' is running.
<IgorPec> how long do i wait?
<tkaiser> IgorPec: this takes 5 minutes max and I'm interested in temperatures at the end of the sysbench run
<IgorPec> ok
f0xx has quit [Ping timeout: 250 seconds]
<IgorPec> 19:34:54: 1200MHz 3.46 21% 5% 15% 0% 0% 0% 62°C
<IgorPec> 19:35:00: 1200MHz 3.58 23% 5% 17% 0% 0% 0% 63°C
<IgorPec> 19:35:10: 1200MHz 3.80 25% 5% 19% 0% 0% 0% 62°C
<IgorPec> 19:35:05: 1200MHz 3.69 24% 5% 18% 0% 0% 0% 63°C
<IgorPec> 19:35:15: 1008MHz 3.97 26% 5% 20% 0% 0% 0% 65°C
<IgorPec> 19:35:20: 1008MHz 4.06 27% 5% 21% 0% 0% 0% 64°C
<IgorPec> 19:35:25: 1200MHz 4.13 28% 5% 22% 0% 0% 0% 66°C
<IgorPec> 19:35:30: 1200MHz 4.20 29% 5% 23% 0% 0% 0% 64°C
<IgorPec> 19:35:35: 1200MHz 4.27 30% 5% 24% 0% 0% 0% 64°C
<IgorPec> 19:35:40: 1008MHz 4.32 31% 5% 25% 0% 0% 0% 65°C
<IgorPec> 19:35:45: 1200MHz 4.38 32% 5% 26% 0% 0% 0% 65°C
<IgorPec> 19:35:51: 1200MHz 4.43 33% 5% 27% 0% 0% 0% 66°C
<IgorPec> 19:35:56: 1008MHz 4.47 34% 5% 28% 0% 0% 0% 66°C
<IgorPec> 19:36:01: 1008MHz 4.52 34% 5% 29% 0% 0% 0% 66°C
<tkaiser> IgorPec: Finished already? How long did sysbench run?
<IgorPec> total time: 130.6576s
<tkaiser> IgorPec: Thanks!
<IgorPec> no problem. you are getting it tomorrow :) heeh
<jernej> IgorPec: Can you try enabling PA20 in U-Boot and then booting normaly?
<IgorPec> moment
netlynx has quit [Quit: Ex-Chat]
florianH has quit [Quit: Connection closed for inactivity]
<tkaiser> IgorPec: You run Xenial, true?
<IgorPec> yes
<tkaiser> IgorPec: Ok, that explains the sysbench numbers. The binary in Xenial shows ~30% better scores compared to the one included in Jessie for example
lkcl has joined #linux-sunxi
dpg_ has quit [Ping timeout: 246 seconds]
<IgorPec> jernej: can't break booting :( tomorrow, got enough for 2day.
<jernej> IgorPec: ok, np
<miasma> tkaiser: thanks for the help. i made a more generic template for all h3 boards in the wiki. should be a lot easier to keep track of stuff now
<tkaiser> miasma: Thank you! And what about all the H2 devices? ;)
<tkaiser> At least we now know for sure that H2[+] is just a crippled H3 :)
<miasma> maybe another template for those
<tkaiser> miasma: Why not simply merging H3/H2+, it's really almost identical. And board vendors that now provide boards that only implement Fast Ethernet and are headless might switch to H2+ without notice anyway
<tkaiser> BTW: In case anyone wants to have a look. That is Xunlong's vendor fex for OPi Zero extracted from their Lubuntu 14.04 image released today: http://pastebin.com/480BYtj3
vagrantc has joined #linux-sunxi
<tkaiser> Some settings (eg. dvfs) make no sense, some other (eg. cooler_table, ths stuff) not that much
Gerwin_J has quit [Quit: Gerwin_J]
<miasma> so are they planning to sell different variants with and without nor flash?
<tkaiser> miasma: Who are 'they'?
<miasma> xunlong
<tkaiser> miasma: Well, Steven doesn't answer questions directly, he always just implements stuff ;)
<miasma> ok
<tkaiser> On PC 2 SPI is present, on OPi Zero optional. Maybe when we make some noise it get's soldered there too.
<tkaiser> ssvb already said that this is currently just a chicken-egg problem.
<miasma> although i'm not sure if i do anything with a board with 1 MB of flash :P it's nice to have, but I can fit my whole distro in say 128 MB :)
<miasma> would be nice to have a compact system with everything builtin
<tkaiser> miasma: This has been discussed today (again). It should already be sufficient if there's a device specific boot loader that can then start any device agnostic OS image from whereever
<ssvb> miasma: the expensive high end boards are supposed to have eMMC, and we can probably use its boot partition for the firmware
<miasma> sure
<ssvb> the extreme low cost boards, such as the Orange Pi Zero, probably can't justify any price increase
<tkaiser> To be honest, I really don't understand how that works: Selling an SBC for $7
<ssvb> maybe it's also a loss leader for Xunlong?
<miasma> aren't the chips quite cheap? i think you can buy ddr3 and h3 for few bucks (including shipping)
<miasma> pin headers and other stuff is just few cents
<miasma> all sbc stuff sold in western countries also have the VAT included
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
Nacho has quit [Ping timeout: 246 seconds]
<beeble> razor thin margins. it's only profitable because the sell quite a lot. and of course because they don't do any work around it
<beeble> thats why you see only the allwinner sdk for it with no further support
<tkaiser> beeble: To my surprise they started to do something around. There are at least two guys busy with kernel and OS image stuff. But results so far look scary.
<tkaiser> Anyway, afk now, gin tonic time. Cheers ;)
<miasma> didn't xunlong create a github account recently?
<beeble> tkaiser: prost!
nikre has joined #linux-sunxi
tkaiser has quit [Ping timeout: 256 seconds]
foodev has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
<miasma> :)
IgorPec has joined #linux-sunxi
<miasma> sinovoip also had a repository, but it seemed pretty useless. they didn't bother updating their stuff
<beeble> back to debugging why it matters what side of the usb cable i plug in first
Nacho has joined #linux-sunxi
<miasma> why would it matter?
<beeble> it shouldn't but it does :)
gianMOD has joined #linux-sunxi
<miasma> one end is micro-usb and other is the larger one?
<beeble> yes. i have already two working fixes. but i would like to find out the exact cause. unfortunately with standard probes the problem doesn't occur anymore. will need to get some active probes with high impedance for that
<nikre> any big updates for opi pc in last 2 weeks?
<miasma> the audio might work now with patches
VargaD has quit [Read error: Connection reset by peer]
iamfrankenstein has joined #linux-sunxi
yann has quit [Ping timeout: 256 seconds]
HeavyMetal has quit [Ping timeout: 258 seconds]
VargaD has joined #linux-sunxi
<nikre> status matrix on this page says "clocks" will be available by 4.8 mainline kernel : http://linux-sunxi.org/Linux_mainlining_effort
<nikre> what is meant by clocks?
<nikre> changing clock speed?
<nikre> still not clear for me: "The common clk framework is an interface to control the clock nodes available on various devices today." clock node?
p_rossak has quit [Remote host closed the connection]
IgorPec has quit [Ping timeout: 246 seconds]
<beeble> you have a clock tree that supports all the peripherals with its required clocks
p_rossak has joined #linux-sunxi
<beeble> you have a single input (ok atually its two) and all others are generated out of it
<beeble> and you need to set the correct clocks with plls and dividers
<nikre> so it enables some drivers to work which were previously not available?
<miasma> drivers that rely on periodic events :)
<mripard> miasma: all of them, really. You need a clock just to be accessible on the bus :)
<miasma> i was thinking of stuff like file system drivers
<beeble> this are just "software" timers
<mripard> nikre: yes, it's a piece of infrastructure. It doesn't provide any features by itself, but all the drivers that do needs it
premoboss has quit [Read error: Connection reset by peer]
<nikre> is this somehow related to real time kernel, interrupts etc?
<nikre> btw ty all guys
<mripard> not really
<nikre> i love this channel
<mripard> it's related to making sure that the devices are accessible and running at the right frequency when relevant
<nikre> ty mripard
<mripard> (the relevant one mostly being all the bus controllers, so stuff like MMC, UART, I2C, and so on)
<beeble> take a look at the picture. this is a example of a clock tree
gianMOD has quit [Remote host closed the connection]
<beeble> the clock framework allows you to have a interface to set all the blocks inbetween
IgorPec has joined #linux-sunxi
<beeble> so its just a common way or you can say a driver to do that. so drivers for stuff like sdio, i2s, uart etc can be written in a common way
leviathanch has quit [Remote host closed the connection]
<beeble> on the left you have the inputs and on the right the outputs to the peripheral blocks
nikre has quit [Ping timeout: 256 seconds]
jstein_ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
apritzel has quit [Quit: Leaving.]
jstein_ is now known as jstein
gianMOD has joined #linux-sunxi
bonbons has joined #linux-sunxi
Putti has quit [Ping timeout: 250 seconds]
p_rossak has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has quit [Changing host]
tkaiser has quit [Ping timeout: 260 seconds]
bugzc has quit [Ping timeout: 260 seconds]
station has quit [Quit: Leaving]
nikre has joined #linux-sunxi
IgorPec has quit [Ping timeout: 245 seconds]
mzki has quit [Ping timeout: 260 seconds]
mzki has joined #linux-sunxi
yann has joined #linux-sunxi
nikre has quit [Changing host]
nikre has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
<KotCzarny> hmm, i might be wrong, but somehow mainline runs ~100-200mA cooler than legacy
<KotCzarny> (on bpi-r1)
<KotCzarny> assuming volt/amp reporting didnt change
jstein has quit [Remote host closed the connection]
dh1tw has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
IgorPec has joined #linux-sunxi
whaf has quit [Remote host closed the connection]
paulk-collins has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
nikre has quit [Remote host closed the connection]
tkaiser has quit [Ping timeout: 260 seconds]
<jernej> for anyone who is interested: I have almost working U-Boot H3 HDMI driver here: https://github.com/jernejsk/u-boot It is good enough to be used instead serial cable, but needs some work in DE2.0 area (wrong colors).
IgorPec has quit [Ping timeout: 240 seconds]
<jernej> needs a lot of clean up too...
<miasma> is the boot rom inside the allwinner SoC open?
p_rossak has joined #linux-sunxi
<miasma> some people worry that it might contain trojans
yann-kaelig has quit [Quit: Leaving]
gianMOD has quit [Remote host closed the connection]
The_Loko has quit [Quit: Leaving]
tkaiser has joined #linux-sunxi
tkaiser has quit [Ping timeout: 256 seconds]
gianMOD has joined #linux-sunxi
dpg_ has joined #linux-sunxi
tkaiser has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
tkaiser has quit [Ping timeout: 265 seconds]
cptG_ has joined #linux-sunxi