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
<hp197> Hi, if I have dts patches for the h3 opi-pc
<hp197> which repo should i use?
<hp197> but im not sure if that will be merged
<apritzel> hp197: mripard's repo is the authoritative, I guess
<hp197> but that one doesnt have any support for the opi-pc yet?
pmattern has quit [Quit: Genug für heute.]
<apritzel> Indeed I see Orange Pi Plus only in there
<hp197> no sun8i-h3-orangepi-pc.dts
<hp197> and im unsure if jwr's one can merge into...
interrobangd has quit [Quit: Leaving]
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
cnxsoft has joined #linux-sunxi
clonak has quit [Ping timeout: 240 seconds]
keh has quit [Ping timeout: 248 seconds]
clonak has joined #linux-sunxi
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
tomboy65 has joined #linux-sunxi
cajg has quit [Read error: Connection reset by peer]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cajg has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 276 seconds]
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
cajg has quit [Read error: Connection reset by peer]
arokux__ has joined #linux-sunxi
cajg has joined #linux-sunxi
ninolein has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
arokux_ has quit [Ping timeout: 250 seconds]
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
leio has quit [Remote host closed the connection]
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
keh has joined #linux-sunxi
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
tomboy64 has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 250 seconds]
cajg has quit [Read error: Connection reset by peer]
cajg has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 240 seconds]
tomboy64 has joined #linux-sunxi
<Turl> keh: iirc cubietruck does have GbE, it's cubieboard2 that doesn't
<keh> well, it's a jungle of so many pros and cons of so many soc. So far the olimex looks nice, but I think I'll look deeper into in some weeks ;)
<keh> But I write cubietruck on my watchlist, Turl ;)
cajg has quit [Ping timeout: 248 seconds]
<Turl> the things that olimex makes tend to be OSHW so there's that too :)
<Turl> oliv3r: look at the lists when you get a chance, there's patches for sun7i irq pins, iirc you had trouble making the higher numbered ones work, maybe they'll interest you
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 276 seconds]
tomboy65 has joined #linux-sunxi
<keh> Turl: What's OSHW ?
<Turl> open source hardware
p1u3sch1 has quit [Ping timeout: 240 seconds]
p1u3sch1 has joined #linux-sunxi
leio has joined #linux-sunxi
FDCX has joined #linux-sunxi
IgorPec has joined #linux-sunxi
kaspter has joined #linux-sunxi
IgorPec has quit [Ping timeout: 255 seconds]
reev has joined #linux-sunxi
ganbold has joined #linux-sunxi
leio_ has joined #linux-sunxi
leio has quit [Ping timeout: 248 seconds]
<hp197> keh: It depends a bit where you want to use the board for whatever you need 1gbps or not
<hp197> and even while ct has a 1gbps interface, i highly doubt they'll hadle that speed
<hp197> (sustained)
<hp197> Also the SATA interface of the ct looks nice, but irl this interface isnt bluffing fast
<hp197> not faster then the nand/emmc
<hp197> ---
<hp197> A good comparison table would be hard to make
<hp197> A lot of board differ from soc, so its a bit apples and pears comparison
<hp197> you can only compare the boards with the same soc onto each other, and these numbers are fairly low
<hp197> cpu comparisment table is here: https://en.wikipedia.org/wiki/Allwinner_Technology
<hp197> doesnt tell you much though...
tkaiser has joined #linux-sunxi
<hp197> good morning tkaiser
<hp197> I have a question for you, you might be able to answer :)
<tkaiser> Morning. It should be noted that unfortunately a few people experience pretty low Ethernet throughput with Olimex' Lime2
<hp197> my question at the top (about the patches for H3 dts)
<tkaiser> What's the question?
diego71_ has joined #linux-sunxi
<tkaiser> Ah, ok
IgorPec has joined #linux-sunxi
<hp197> I see you created your own patches on armbian
<hp197> do you create them upstream?
<tkaiser> Yes, but the mainline stuff has been done by IgorPec, I do not even know on which branch he relied.
<hp197> :(
<tkaiser> But he joined a few secs ago ;)
<hp197> awh, I see :)
<tkaiser> Currently I only did stuff for the outdated 3.4.x kernel and since no one wants to maintain this thing, we collect patches...
<hp197> It looks like H3 support is so scattered around, that nobody seems to hold the most recent code anymore
diego71 has quit [Ping timeout: 244 seconds]
IgorPec has quit [Ping timeout: 276 seconds]
<plaes> there was someone who has improved it, but this work has yet to appear in mailing lists
<plaes> I think it's published somewhere in armbian forums
<tkaiser> plaes: But that's more focussed on reading values out through sysfs: http://forum.armbian.com/index.php/topic/611-wip-axp209-mainline-sysfs-interface/
vagrantc has joined #linux-sunxi
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
arokux__ has quit [Ping timeout: 248 seconds]
<wens> plaes: we already have an axp usb power supply driver by hans in mainline
<wens> someone just has to copy it for ac in
<wens> also a fuel gauge driver and charger driver for axp288, which probably can be adapted
IgorPec has joined #linux-sunxi
<hp197> Somebody here who can help me with device tree register settings?
<hp197> reg = < <base address> <length> >;
<wens> how?
<hp197> is what I read, is that correct?
<wens> yes
IgorPec has quit [Ping timeout: 250 seconds]
<hp197> how is the length choosen?
<hp197> for example, H3 uart0
<hp197> base addr is: 0x01C28000
<hp197> uart1 addr is: 0x01C28400
<hp197> so, based on this i would say the length is 0x400 (which is correct)
<hp197> but you shouldn't rely on the next address for the currect length right?
<hp197> where does the length come from?
premoboss has quit [Quit: Sto andando via]
tkaiser has joined #linux-sunxi
mzki has joined #linux-sunxi
<tkaiser> ssvb: Small question regarding lima-memtester for H3
<hp197> tkaiser: lol, I read others are asking for legacy as well :p
<hp197> guess H3 as a whole seems to be a bit unmaintained
<tkaiser> hp197: I would believe as soon as the mainline Ethernet driver for H3/A64 is working everything will improve soon.
<tkaiser> Regarding legacy/3.4: Who cares? ;)
<hp197> well, hard to work on for anybody if nobody knows what the base of the code is.
<hp197> e.g. if we base from sunxi-next, then we have to include all the orangepi-pc patches as well
<wens> hp197: normally you choose it to cover all the registers
<wens> or use the length from the memory map
mossroy has joined #linux-sunxi
<hp197> wens: I guess length from the memory map is what the maintainers mostly did for our socs, because i cant correlate offsets to the length 1:1 (length is always more)
<pitillo> tkaiser: hello, is the kernel ready to be built with gcc 5.x? (I gave a try to sun8i_h3_defconfig with/without patches and there are some problems with a native build, now I'll use cross with a gcc 4.x based toolchain)
<hp197> its a bit fuzzy, because if I look at that uart register
<hp197> last offset is 0xA4 + 32bits in that register
<tkaiser> pitillo: Should work, that was one of the reasons to choose yann|work's h3-wip branch as base for Armbian: https://github.com/O-Computers/linux-sunxi/commit/acdcb2a675ed117c97e321ddf3a4e077994b1e43
<pitillo> tkaiser: I'm using that repo and branch currently
<tkaiser> pitillo: No idea, I don't do gcc experiments now and use the one Igor chose for Armbian since strange things already happened (Igor had no HDMI output with the 3.4 kernel on his Plus but with the same settings -- but different gcc -- I had a display)
<pitillo> really strange... a read of the kernel build should be needed with the problematic gcc
<tkaiser> I also never tried to compile on the board itself, always cross-compiling in an Ubuntu VM
<pitillo> I'll keep playing with it, native and cross and see where I can reach
<pitillo> here I usually use a jail for cross building with different toolchains (custom crosstols) and I gave a native try because my devel machine was powered down this weekend
vagrantc has quit [Quit: leaving]
reinforce has joined #linux-sunxi
IgorPec has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
yann|work has joined #linux-sunxi
yann|work has quit [Ping timeout: 250 seconds]
<plaes> wens: would it make sense to send some of these clock patches for A10/A20 KMS?
paulk-aldrin has joined #linux-sunxi
<wens> plaes: if you can verify they work, or they are simple enough to match against the manual, i don't see why not
<plaes> gates and PLL3/PLL7 patches
<wens> sure
<wens> hmm, linus did -rc5 on saturday
<wens> codekipper: spdif branch merged into sunxi-next, in case you want something to base dt patches on, or to test
FlorianH has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
premoboss has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 276 seconds]
p1u3sch1 has joined #linux-sunxi
libv_ is now known as libv
<topi`> I made a fatal mistake with the loboris orangepi image: running apt-get update before I did fs_resize
<topi`> running completely out of space on a SD card is an exercise in patience... every fs op seems to take ages
yann|work has joined #linux-sunxi
apritzel has joined #linux-sunxi
<paulk-aldrin> plaes, does that make the drm drver work on sun7i?
<plaes> paulk-aldrin: nope
<paulk-aldrin> okay
<plaes> I only added clocks for now
ganbold has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
MY123 has joined #linux-sunxi
_massi has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
paulk-aldrin has quit [Quit: Quitte]
matthias_bgg has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 240 seconds]
iamfrankenstein1 is now known as iamfrankenstein
enrico_ has joined #linux-sunxi
leviathancn_szu has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
FlorianH has quit [Ping timeout: 248 seconds]
ganbold has joined #linux-sunxi
FlorianH has joined #linux-sunxi
<pitillo> tkaiser: cross building with gcc 4.8.3 only gives a problem with gen_check_code, avoided disabling resume support atm (without applying patches to kernel sources... nest build with patches)
leviathancn_szu has quit [Remote host closed the connection]
Worf has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
<tkaiser> pitillo: x86 or x64 host?
<tkaiser> In case it's 32 bit please have a look at http://moinejf.free.fr/opi2/
viccuad has joined #linux-sunxi
gzamboni has quit [Read error: Connection reset by peer]
hp197 has quit [Remote host closed the connection]
<pitillo> it's a 64b host with a 32b jail (then it's a x86 host really). Taking a look to that link. Rebuilding cross kernel with all patches applied (I'll move it to the orangepipc and try again a native build with gcc 5.x, may be I made a mistake applying all those patches)
zerotri_ has joined #linux-sunxi
<pitillo> tkaiser: good catch... thank you very much... trying to run a x64 binary on a x86... no comments, sorry
jukivili has quit [Ping timeout: 240 seconds]
zerotri has quit [Ping timeout: 240 seconds]
lynxis has quit [Ping timeout: 240 seconds]
MoeIcenowy has quit [Ping timeout: 240 seconds]
zerotri_ is now known as zerotri
Tartarus has quit [Ping timeout: 240 seconds]
<tkaiser> pitillo: Still want to try to compile on the board itself? ;)
jukivili has joined #linux-sunxi
lynxis has joined #linux-sunxi
<pitillo> tkaiser: sure... this is pretty faster than old machines (X86/ARM)
candratech has joined #linux-sunxi
MoeIcenowy has joined #linux-sunxi
Tartarus has joined #linux-sunxi
<longsleep> apritzel: Your Allwinner ATF branch works great and hypervisor seems to be possible now
<longsleep> [ 18.126574] kvm [1]: Using HYP init bounce page @79893000
<longsleep> [ 18.127090] kvm [1]: interrupt-controller@1c84000 IRQ25
<longsleep> [ 18.127533] kvm [1]: timer IRQ27
<longsleep> [ 18.127554] kvm [1]: Hyp mode initialized successfully
<apritzel> does udev create /dev/kvm for you?
<longsleep> apritzel: i already updated my docs https://github.com/longsleep/build-pine64-image/tree/master/u-boot-postprocess to your ATF tree/branch
<apritzel> longsleep: you can use bl31 as the build target when building ATF
<apritzel> that avoids building all the other stuff we don't need
<apritzel> so: make ... bl31
paulk-collins_ has joined #linux-sunxi
whitesn has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 240 seconds]
IgorPec has quit [Ping timeout: 255 seconds]
paulk-collins_ has quit [Quit: Quitte]
paulk-collins has joined #linux-sunxi
avph has quit [Ping timeout: 240 seconds]
avph has joined #linux-sunxi
<longsleep> apritzel: good point, will change that tonight
domidumont has joined #linux-sunxi
keh has quit [Ping timeout: 248 seconds]
paulk-collins has quit [Ping timeout: 252 seconds]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
paulk-collins has joined #linux-sunxi
gzamboni has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<longsleep> apritzel: forgot to paste: [alarm@alarm ~]$ ls /dev/kvm
<longsleep> /dev/kvm
<longsleep> apritzel: so yeah, /dev/kvm is there
IgorPec has quit [Ping timeout: 248 seconds]
<maz> longsleep: you seem to be using a *very* old version of the kernel...
<plaes> ?
<maz> plaes: just by looking at the kernel messages, I can tell this is extremely old.
<longsleep> maz: yes this is the BSP Kernel 3.10.65 for Allwinner A64
<plaes> first steps to get u-boot working
<apritzel> plaes: you mean like this: https://github.com/apritzel/u-boot/commits/a64
<plaes> yeah
<maz> longsleep: KVM was merged in 3.12 on arm64. so somebody did a backport. good luck with that! ;-)
<apritzel> Indeed it's not only an old kernel, it's a Franken-kernel, really!
<maz> apritzel: yeah. and given the number of fixes we're queuing every single release, I can safely predict some good fun with that one.
<apritzel> maz: not to speak of the fixes that went in between 3.10.65 and the latest 3.10.97 ;-)
cnxsoft has quit [Quit: cnxsoft]
<maz> apritzel: I've stopped caring about 3.10 at the end of June 2013.
arokux has joined #linux-sunxi
viccuad has quit [Ping timeout: 255 seconds]
<steev> apritzel: to be fair... all kernels are franken kernels unless they are vendor sources... then they are mostly wtf
<TheLinuxBug> LOL
<TheLinuxBug> thats a great quote right there
<steev> amlogic dicked around in mm... swap doesn't work properly on their A53
<steev> i'm too scared to even look in there
<NiteHawk> EXTRAVERSION = -wtf
<NiteHawk> :D
iamfrankenstein has quit [Ping timeout: 240 seconds]
iamfrankenstein has joined #linux-sunxi
reev has quit [Ping timeout: 240 seconds]
iamfrankenstein has quit [Ping timeout: 240 seconds]
iamfrankenstein has joined #linux-sunxi
IgorPec has joined #linux-sunxi
viccuad has joined #linux-sunxi
Worf has quit [Quit: Konversation terminated!]
IgorPec has quit [Ping timeout: 248 seconds]
IgorPec has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 255 seconds]
Worf has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 248 seconds]
IgorPec2 has joined #linux-sunxi
vagrantc has joined #linux-sunxi
IgorPec2 has quit [Client Quit]
IgorPec2 has joined #linux-sunxi
IgorPec2 has quit [Client Quit]
IgorPec2 has joined #linux-sunxi
IgorPec2 has quit [Client Quit]
cosm has joined #linux-sunxi
zoobab has quit [Ping timeout: 252 seconds]
premoboss has quit [Quit: Sto andando via]
zoobab has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
<montjoie> alea jacta est
Shirasaka-Hazumi has quit [Ping timeout: 240 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
alexst has joined #linux-sunxi
<apritzel> montjoie: thanks for posting this!
<apritzel> not the latin phrase, but the driver ;-)
<jelle> oh nice
<longsleep> apritzel: well, i have extracted the new BSP from Pine64.com and after i have applied this i will look into merging from linux-stable 3.10 head. I did that a couple of times before where it was easy, but that was without any android stuff inside
<apritzel> longsleep: so you just gave enough rationale to not do this
<apritzel> frankly I'd rather see your expertise in pushing the upstream kernel
<apritzel> it seems we have a lot of stuff lying around: there is a DE2.0 driver, also some information about the HDMI transmitter
<apritzel> also montjoie just posted the Ethernet driver
<apritzel> USB may even be a low hanging fruit
<jelle> I hope someone finds the orange pi pc issue :-)
kill_-9_1 has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
MY123 has quit [Ping timeout: 240 seconds]
<montjoie> I hope so
kill_-9_1 is now known as MY123
<montjoie> In general it is when I ask a question that I found the solution, so perhaps tonight...:)
alexst has quit [Ping timeout: 252 seconds]
<longsleep> apritzel: yeah - i started learning about device tree and the values inside, but it goes slowly and failure is frustrating
<longsleep> apritzel: i will look into the new BSP first and then update my images to have 1000M working and then i guess i am back at new Kernel fun :)
<candratech> Great news re. the Ethernet driver (at least I'm hoping it's the H3 EMAC ;-) I have an OPi PC and would love to try it out, where was it posted?
<apritzel> it would be very helpful if you could look at USB stuff, I reckon we have everything in place
JohnDoe_71Rus has joined #linux-sunxi
<apritzel> candratech: to the linux-sunxi mailing list
<candratech> Thanks :-)
<longsleep> apritzel: i need to fix the crashing issue first though - figure out the reason for it at least
<candratech> Just thought, I'm guessing that means I can't access it yet then :-(
ganbold has quit [Ping timeout: 244 seconds]
KotCzarny has joined #linux-sunxi
alexst has joined #linux-sunxi
<apritzel> candratech: you can try to extrace the patches from here: https://groups.google.com/forum/#!topic/linux-sunxi/ZrVjF74mliY
<apritzel> *extract
<plaes> montjoie: could you resend to linux-arm mailinglist too?
<candratech> Thanks apritzel, I'll have a look at that tonight and see how much of a mess I can get myself into ;-)
premoboss has joined #linux-sunxi
orly_owl has quit [Ping timeout: 276 seconds]
domidumont has quit [Read error: Connection reset by peer]
avph has quit [Ping timeout: 250 seconds]
Nacho has quit [Ping timeout: 276 seconds]
doppo has quit [Ping timeout: 240 seconds]
doppo has joined #linux-sunxi
<apritzel> montjoie: what kernel version was this driver against? something older?
avph has joined #linux-sunxi
Worf has quit [Quit: Konversation terminated!]
<montjoie> apritzel: Curently based on a git checkout from hans repo. I need to rebase all my stuff on mainline
<montjoie> plaes: If I could avoid more posting until I reduce crappiness
<apritzel> plaes: if you care about accessibility, we can surely find some repo to merge it in preliminarily
alexst has quit [Quit: Lost terminal]
<montjoie> I need to create a linux github repo also
IgorPec2 has quit [Quit: Nettalk6 - www.ntalk.de]
<apritzel> montjoie: that would be good, please post it the URL then to the linux-sunxi ML
tucker has joined #linux-sunxi
hp197 has joined #linux-sunxi
nove has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 255 seconds]
<tucker> What's the status of nand support in mainline? Is the H3 supported? is SKhynix H27UCG8Y2ETR (MLC) supported enough to read the allwinner-formatted boot area without instantly destroying it on probe?
<tucker> Gah, typo, meant T2 not Y2 in the middle of that.
yann|work has quit [Ping timeout: 255 seconds]
<ssvb> tucker: what kind of device is that?
<ssvb> oh, that's nice
<ssvb> AFAIK the H3 based Orange Pi boards don't have NAND and they are the most popular H3 devices
<hp197> looking at the pic, indeed a nice device
<hp197> accidentally I updated the H3 PIO page last night
<ssvb> tucker: you can track the mainline NAND driver development progress here - http://linux-sunxi.org/MTD_Driver
<hp197> guess the nand is connected to PC*
tkaiser has joined #linux-sunxi
avph has quit [Ping timeout: 250 seconds]
<tucker> Mine is in a differently colored case (bronze) with a camera, unlike the one pictured on the page, so the fex should differ slightly from the one von_fritz placed on the page. Sadly, script_extractor just segfaults, and using the fel command gives a libusb error...
<ssvb> tucker: Free Electrons developers have been hired to develop the NAND driver for CHIP among other things, so probably things will be in a better shape by June 2016 (the expected release date for CHIP)
<ssvb> however they are targeting older SoC variants, so H3 support might require some additional work on top of this
<ssvb> tucker: can you debug the script_extractor segfault issue?
avph has joined #linux-sunxi
<ssvb> are you using the latest sunxi-tools from git?
<ssvb> tkaiser: what kind of question about lima-memtester did you want to ask?
KotCzarny has joined #linux-sunxi
khuey|away is now known as khuey
<tucker> ssvb: from http://linux-sunxi.org/H3_Manual_build_howto "SDKs only ship a binary version of boot0. This is a pristine version, and needs to be seeded with information such as the debug UART, DRAM clock rates, NAND/MMC ports. Normally this is done during the packing process." and then a lot of
<tucker> convoluted instructions involving binary-only tools on how to pack the fex into the boot0 binary...
matthias_bgg has quit [Quit: Leaving]
<tucker> it probably just ends up somewhere else in memory, not at the 'magic address' the script_extractor tool (or the fel instructions) expect it.
<ssvb> tucker: this magic address is still a valid physical address in RAM, so the tool should not crash anyway
<ssvb> you can add more debugging prints to it
<ssvb> as for the magic address itself, you can find and confirm it in the kernel sources
<ssvb> IIRC, it is still the same for H3, so there should be no problem with it
<ssvb> I would guess, the reason of failing might be that you just don't have root privileges in Android
<ssvb> tucker: does the hardware vendor provide a recovery image for this device?
<tucker> Not that I've found
<tucker> Pretty much a noname box
<ssvb> I had some difficulties extracting FEX for http://linux-sunxi.org/MSI_Primo81 due to having no root privileges in Android out of the box, but at least Primo81 has a recovery image provided by MSI
enrico_ has quit [Quit: Bye]
<KotCzarny> aren't there rooting apps around?
<tucker> it's supposed to be rooted, at least su works
<ssvb> KotCzarny: well, the rooting applications are exploiting various vulnerabilities, and these vulnerabilities are normally expected to be fixed eventually
<ssvb> KotCzarny: I tried many rooting applications on Primo81 and they did not work at that time
<ssvb> KotCzarny: fortunately or not, Android vendors are doing a rather sloppy job updating their firmware and Linux kernel has tons of security holes discovered on a regular basis :-)
<KotCzarny> :)
<KotCzarny> time to try again?
<jelle> you really have to think when you buy a device :p
<KotCzarny> jelle, said the man with the sunxi devices :P
<tucker> Android vendor: "You want an update? What are you smoking?"
<jelle> KotCzarny: I just hope to get it mainlined and then it works out of the box :-)
<ssvb> KotCzarny: FYI, the MSI Primo81 tablet is already nicely supported in the mainline U-Boot & kernel since a long time ago
_massi has quit [Quit: Leaving]
apritzel1 has quit [Ping timeout: 248 seconds]
keh has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
<ssvb> sigh, 1GB RAM way too small for ARM64, the Clang compilation got stuck doing heavy swapping
<KotCzarny> swap over nfs?
<jelle> wot :P
<jelle> KotCzarny: better swap on usb :p
<KotCzarny> nfs is much faster on many small writes/reads
<ssvb> I probably need to kill it and restart the whole build using just a single CPU core
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
<ssvb> when one has 1.5G of swap used up (in addition to 1G RAM), it does not matter what kind of storage media is backing the swap
<KotCzarny> compile without debug/with lower optimization level?
IgorPec2 has quit [Ping timeout: 248 seconds]
<ssvb> well, still having at least 2G of RAM is probably a good idea in general
yann|work has joined #linux-sunxi
<ssvb> the guys who had designed ODROID-C2 probably know what they are doing :-)
<KotCzarny> ssvb, depends on use case
<KotCzarny> but i agree, 1gb on opipc is a tad small
<jelle> orange pi one is worse then
<KotCzarny> (if one would like to use it as a webmachine)
FlorianH has quit [Ping timeout: 252 seconds]
<KotCzarny> jelle, for home server/audio box 512 is more than enough
<ssvb> jelle: Orange Pi One uses a 32-bit CPU, this helps to reduce the memory footprint
<jelle> true
clonak has quit [Ping timeout: 240 seconds]
<ssvb> in fact, pine64 users are likely going to have a much more usable system with a 32-bit rootfs, at least initially (until the software/libraries get properly optimized for arm64)
ricardocrudo has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
<keh> Is there a pgp chain-of-trust for Igor Pecovnik's public key 9F0E78D5 on open keyserver or anyone who can verify it's him?
<KotCzarny> ask him here?
<KotCzarny> (after he returns)
<keh> he is here?
<KotCzarny> or on armbian forums for the key
<keh> well, in general the forum could be also compromitted as the downloadserver or the dns entry for pubkeyserver IPs as well for a country. But so far it's all digital. =/
<KotCzarny> sure, and your ssl connections are already monitored and modified on-the-fly
Netlynx has joined #linux-sunxi
<keh> Maybe I would trust if he is on a picture with his pgp fingerprint is scratched into his breast :P But to get back real: A few more sites with Igor's signatur trusted would look a bit safer than just searching his pgp fingerprint in ixquick and duckduckgo and just finding 2-4 results on nearly the same sites. ;,(
<keh> Or cutting the key which is new in version 6 and have several ppl who can sign an image
clonak has joined #linux-sunxi
apritzel has joined #linux-sunxi
arokux has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<tkaiser> ssvb: I wanted to encourage users of OPi One to start submitting lima-memtester results to the wiki
<jelle> if I receive mine I will
<jelle> tkaiser: mine is supposed to be "transported by air" now
<tkaiser> jelle: They ship pretty fast. My 1st PC took just a week
<tkaiser> But the problem is that with kernel 3.4, the different 'voltage regulator' on the One tons of 'ARISC ERROR' are produced.
<jelle> ugh
<tkaiser> And I don't know whether that affects lima-memtester
<tkaiser> Just an example: http://pastebin.com/SNRMPSMJ This got worse later. My OS X machine already stalled since too much error messages came over the serial connection :)
<tkaiser> After exchanging the fex file with appropriate settings everything's ok. But I fear whether that might affect lima-memtester or not
IgorPec has joined #linux-sunxi
<plaes> keh: here's Igor ^^ :)
IgorPec has quit [Ping timeout: 255 seconds]
<ssvb> tkaiser: generally using the correct script.bin or *.dtb blob is strongly recommended
<tkaiser> ssvb: Understood. So I would've to rebuild memtester?
<ssvb> tkaiser: just update the shell script to provide the right script.bin blob
<tkaiser> That easy? Oh my...
<ssvb> tkaiser: yes, however this is becoming somewhat cumbersome, considering that we have more than one board to support...
<tkaiser> Agreed
jstein has joined #linux-sunxi
cole has joined #linux-sunxi
<KotCzarny> ssvb, isnf fel mode providing board identification anyway?
<ssvb> KotCzarny: just the SoC type
cole has quit [Client Quit]
<keh> plaes: Maybe it was just a logintest from Igor or someone with his name
<keh> :p
<ssvb> KotCzarny: we can of course ask the user about the board type (maybe via a dialog menu), but this means that the tool is becoming a little bit more advanced than it is now
<KotCzarny> keh, freenode support logging in, just do a whois
<KotCzarny> ssvb, writing menu using dialog is easy
<ssvb> KotCzarny: definitely doable, but I just would like to know if there are any potential users before starting to code anything :-)
<KotCzarny> :)
<KotCzarny> ssvb, slightly offtopic, did you get enough results for opipc?
arokux__ has joined #linux-sunxi
<ssvb> KotCzarny: more is always better, but there are enough results even now
<tkaiser> ssvb: Will give it then a try with http://kaiser-edv.de/tmp/4U4tkD/orangepione.bin and report back later
<ssvb> KotCzarny: for example, an interesting question is whether there any boards in the wild failing the test at 648MHz DRAM clock speed
<KotCzarny> ssvb, i can run mine overnight
IgorPec has joined #linux-sunxi
<KotCzarny> better question would be how much ambient temperature affects stability
<ssvb> KotCzarny: based on the current results distribution, probably we can expect a very small fraction of such 648MHz incompatible boards (just a few percents)
<KotCzarny> ssvb, mine was tested in ~19C ambient
<KotCzarny> in 4-5 months summer should come
<KotCzarny> with 26C ambient it could make the results a bit different
<ssvb> KotCzarny: the temperature is unlikely to have any significant impact
<KotCzarny> ssvb, heatsink not doing anything then?
<ssvb> we can always compare two sets of boards: with and without heatsinks
<ssvb> and check if there is any statistically significant difference
<KotCzarny> yes
<ssvb> that's why there is the 'Notes' column in the table
<ssvb> people are free to dump their speculations and extra information there :-)
<tkaiser> ssvb: The overvolted lima-memtester is running ;) In the meantime I realised that I'm the only 'One' owner with wrong voltage settings.
<tkaiser> A few people checked the test points on the PCB and 1.1V/1.3V could be measured
<ssvb> tkaiser: well, I'm a bit skeptical until you confirm this with a multimeter :-)
<tkaiser> I know :)
<tkaiser> But my board gets hotter with heatsink being idle than other's running benchmarks or cpuburn-a7
<tkaiser> Same with consumption
Netlynx has quit [Quit: Leaving]
<tkaiser> But there the powermeter might make the difference ;)
khuey is now known as khuey|away
khuey|away is now known as khuey
<ssvb> tkaiser: there are some differences between chips, your temperature sensor may be a bit more broken than the others, the SoC itself may be a little bit more power hungry, etc.
<tkaiser> ssvb: Ok, but the only thing I want to do with the One currently is to get basic Armbian support ready and push users to test this thing regarding DRAM clock
<tkaiser> Then I throw it away :)
<ssvb> tkaiser: I find it a bit hard to believe that your board has a different voltage regulator out of the blue
<tkaiser> But my board behaves totally different. Mine works reliable on the lower voltage up to 1200MHz.
<KotCzarny> early batch?
<tkaiser> All other users get random crashed when voltage remains at 1.1V
<tkaiser> ssvb: But you're right. I should confirm with a Multimeter. And I should've ordered 2 of them
<tkaiser> Is it ok, when I take your archive, add script.bin for One, put the new package online and relink from the wiki to it?
<ssvb> yes, it's fine
domidumont has quit [Ping timeout: 276 seconds]
<KotCzarny> just rename the version to -tk1
<KotCzarny> :)
apritzel has quit [*.net *.split]
keh has quit [*.net *.split]
vickycq has quit [*.net *.split]
NiteHawk has quit [*.net *.split]
topi` has quit [*.net *.split]
LostSoul has quit [*.net *.split]
captainigloo has quit [*.net *.split]
azend|vps has quit [*.net *.split]
_fortis has quit [*.net *.split]
lauri has quit [*.net *.split]
vbmithr has quit [*.net *.split]
mripard has quit [*.net *.split]
lerc has quit [*.net *.split]
flok420 has quit [*.net *.split]
vpeter has quit [*.net *.split]
tchiwam has quit [*.net *.split]
wens has quit [*.net *.split]
longsleep has quit [*.net *.split]
adj_ has quit [*.net *.split]
rellla has quit [*.net *.split]
tkoskine has quit [*.net *.split]
kadamski has quit [*.net *.split]
Michal has quit [*.net *.split]
jero- has quit [*.net *.split]
focus has quit [*.net *.split]
formruga has quit [*.net *.split]
wigyori has quit [*.net *.split]
petr has quit [*.net *.split]
wigyori has joined #linux-sunxi
topi` has joined #linux-sunxi
vbmithr has joined #linux-sunxi
mripard has joined #linux-sunxi
wens has joined #linux-sunxi
LostSoul has joined #linux-sunxi
kadamski has joined #linux-sunxi
petr has joined #linux-sunxi
focus has joined #linux-sunxi
tchiwam has joined #linux-sunxi
Michal has joined #linux-sunxi
formruga has joined #linux-sunxi
tkoskine has joined #linux-sunxi
NiteHawk has joined #linux-sunxi
vickycq has joined #linux-sunxi
longsleep has joined #linux-sunxi
apritzel has joined #linux-sunxi
rellla_ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
lerc has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
adj_ has joined #linux-sunxi
vpeter has joined #linux-sunxi
Guest627 has joined #linux-sunxi
flok420 has joined #linux-sunxi
captainigloo has joined #linux-sunxi
azend|vps has joined #linux-sunxi
vpeter has quit [Remote host closed the connection]
<tkaiser> IIRC DRAM settings in script.bin are ignored since you deactivated that in your kernel?
vpeter has joined #linux-sunxi
lauri has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
_fortis has joined #linux-sunxi
tkaiser has quit [Ping timeout: 250 seconds]
viccuad has quit [Ping timeout: 250 seconds]
tkaiser has joined #linux-sunxi
<longsleep> No wonders the new BSP from Pine64 is 22GB, it contains a complete Android build environment including all the temporary files and the same for two Linux Kernels ..
<KotCzarny> :>
<KotCzarny> getting lazy in hopes no one would be crazy enough to download 22GB with 50kB/s rate?
<longsleep> it actually downloaded in 10 hours for me, excluding the 10 hours it was just stalled
<longsleep> and not including the 5 hours i had to spend to get torrent running :P
cosm has quit [Quit: Leaving]
<longsleep> btw, any suggestion how to get KVM for ArchLinux aarch64?
<longsleep> does not seem to be in the repo
<apritzel> longsleep: easiest is kvmtool
<longsleep> apritzel: great thanks
doppo has quit [Ping timeout: 240 seconds]
doppo has joined #linux-sunxi
paulk-collins has quit [Quit: Quitte]
MY123 has quit [Quit: Leaving]
<apritzel> this can be easily cross-compiled, like the kernel (make ARCH=arm64 CROSS_COMPILE=...)
<apritzel> you can even create a static binary, make lkvm-static
<longsleep> yeah, just looking at the README
<apritzel> then it's as easy as running: ./lkvm run -k Image
<longsleep> but the BSP tree has just synced, let me push that to GitHub first
<apritzel> which will r/o mount your running rootfs into the guest ...
<apritzel> sure
<longsleep> thats on top of the earlier BSP import
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
<longsleep> apritzel: better overview of whats changed: http://paste.ubuntu.com/15174117/ (a lot)
NetForHack has joined #linux-sunxi
cosm has joined #linux-sunxi
avph has quit [Ping timeout: 250 seconds]
<longsleep> mhm i guess i need to cross compile libftd first
avph has joined #linux-sunxi
<apritzel> yeah, sorry for that ;-)
<apritzel> I wrote quite something into the README about that ...
tkaiser has quit [Read error: Connection reset by peer]
<longsleep> well libfdt compiled, but fails to install
<apritzel> you just need the .h and .so files
<longsleep> for whatever reason it runs /usr/bin/ld on it
<apritzel> have you followed the instructions?
<longsleep> yes
<longsleep> the last sudo make ... fails
<apritzel> not sudo
<longsleep> probably i did not follow the instructions before :)
<longsleep> well its sais sudo for libfdt
<apritzel> yeah, depends on where you install it
tucker has quit [Quit: Leaving]
<apritzel> (I have the SYSROOT accessible as a normal user)
<apritzel> you need CC to point to the cross compiler and export that
<longsleep> i got that
<apritzel> do you have CROSS_COMPILE defined? what does "echo $CC" say?
<longsleep> echo $CC
<longsleep> aarch64-linux-gnu-gcc
<longsleep> apritzel: here is the error http://paste.ubuntu.com/15174269/
<apritzel> try make clean ;-)
<apritzel> you seem to have a x86-64 binary in there
<longsleep> mhm right, seems like the sudo did a rebuild sorry
<longsleep> ok i got the stuff in /tmp/usr now
<longsleep> just put it in /usr and thats it?
<apritzel> put it anywhere you like
<apritzel> /usr/local/bin for instance
<apritzel> it's just that one binary that you need
<longsleep> no i mean libfdt
<apritzel> no other libraries or support files
<apritzel> ohg
<apritzel> oh
<apritzel> into $SYSROOT
<longsleep> yes which is / for me
<apritzel> that is where the _cross-compiler_ looks for it's libraries
<apritzel> so you have multiarch then, I guess
<longsleep> yes
<apritzel> does aarch64-linux-gnu-gcc -print-sysroot really print "/" ?
<longsleep> hooray it builds now
tkaiser has joined #linux-sunxi
<longsleep> aarch64-linux-gnu-gcc -print-sysroot
<longsleep> /
<longsleep> yes
<apritzel> frankly the build is easy and quick enough that you could have done it natively as well :-P
<apritzel> (in contrast to QEMU)
<longsleep> well i would need to install all the build tools first then
<longsleep> and i do not know much about arch
<longsleep> arch linux i mean
<longsleep> cross compile alreay all set up
<longsleep> so i got the binary now
<apritzel> yeah, cross-compiling is fine
<longsleep> ah let me build the static one
<apritzel> I use it all the time
<apritzel> exactly!
<apritzel> make lkvm-static
<longsleep> its also faster i guess
<apritzel> cross-compiling you mean?
<longsleep> yes
<apritzel> in case of kvmtool it does not really matter, for QEMU it can quite some difference, yes
<longsleep> ok i got lkvm-static on the device, now what? do you have a link for a small test boot image?
<apritzel> ./lkvm run -k Image
<apritzel> no need for a boot image
<apritzel> kvmtool magic
<apritzel> it uses the host rootfs with some kind of overlay magic
<longsleep> lkvm-static run -k Image # lkvm run -k Image -m 448 -c 4 --name guest-20532 Fatal: Unable to open kernel Image
<apritzel> well, Image must be an arm64 kernel
<longsleep> ah
<apritzel> for instance the one you booted
<apritzel> host = guest kernel is the usual practise
<longsleep> sure let me find it
<longsleep> you know i only have the crappy android format
<apritzel> but you have compiled it, right?
<apritzel> so you could just take arch/arm64/boot/Image
<longsleep> sure, if i hadnt cleaned the tree earlier to import the BSP changes :/
<apritzel> you can dd the kernel out there
<apritzel> (of the Android image)
<apritzel> let me just dig out the details
vagrantc has quit [Quit: leaving]
<longsleep> i found the one from your tree
<longsleep> lets try that first while the other kernel builds again
<apritzel> the Android image?
<longsleep> i build that later out of the Image file
<longsleep> so the kernel tree builds the Image just fine
<longsleep> i just did make clean earlier
<apritzel> ah
<longsleep> lkvm-static run -k Image # lkvm run -k Image -m 448 -c 4 --name guest-20550 Info: Loaded kernel to 0x80080000 (11018240 bytes) Info: Placing fdt at 0x8fe00000 - 0x8fffffff Info: virtio-mmio.devices=0x200@0x10000:36
<longsleep> Info: virtio-mmio.devices=0x200@0x10200:37
<longsleep> Info: virtio-mmio.devices=0x200@0x10400:38
<longsleep> something more supposed to happen?
<apritzel> well, you should see the output of the kernel booting ...
<longsleep> probably the FDT incompatibility between the one i booted with and the one your Kernel expects
<apritzel> no, that's mach-virt
<apritzel> independent of the host
<longsleep> ok
<apritzel> kvmtools creates the DT on the fly
<longsleep> nice tool
<apritzel> I guess it's just the host kernel being too old
<apritzel> as maz hinted earlier already
<longsleep> that would be a shame
<apritzel> try --debug
<apritzel> ./lkvm run -k Image -p "earlycon=uart,mmio,0x3f8" --debug
<longsleep> no difference with --debug
<longsleep> ah thats better
<apritzel> you can also look into dmesg to check whether kvm complains
Michal has quit [Changing host]
Michal has joined #linux-sunxi
<longsleep> i guess thats success: http://paste.ubuntu.com/15174411/
<longsleep> except that the console gets disabled quickly with no replacment but the Kernel seems to boot
<apritzel> mmh
<apritzel> try to append "console=ttyS0" after the earlycon
<longsleep> yes just did that
<apritzel> (so within the ticks)
<longsleep> it came to ALS device list
<longsleep> and then the host kernel crashed :)
<apritzel> oh well, as maz said: have fun with backported KVM support
<apritzel> but actually it came pretty far ;-)
<longsleep> yeah, maybe it works better with the BSP kernel
<longsleep> BSP kernel booting mainline Kernel would be pretty awesome though
<longsleep> host is dead now
<apritzel> no, I guess the BSP kernel as a guest would be worse
<longsleep> mhm ok
<apritzel> mainline kernel should be the easiest
p1u3sch1 has quit [Ping timeout: 240 seconds]
<apritzel> unlike KVM on x86 this is an-all virtual platform
<apritzel> mach-virt
<longsleep> i see
<apritzel> so beside the timer and the GIC KVM or kvmtool do not need to emulate stuff
<longsleep> it even got an ip address in the VM
<apritzel> see?
<longsleep> so it cannot be that far of
<apritzel> did the host kernel output something?
<longsleep> yes, millions of lines of crash dumps
p1u3sch1 has joined #linux-sunxi
<apritzel> the first one would be interesting ;-)
<longsleep> yeah, very hard to come by i guess let me reproduce and try to disconnect uart in time
Guest627 is now known as jero
<longsleep> apritzel: got it http://paste.ubuntu.com/15174460/
<KotCzarny> or just redirect output somewhere
<apritzel> ah, I remember that bug ;-)
<longsleep> apritzel: is that good or bad?
<apritzel> it means that there was once a fix for this
<longsleep> apritzel: in kvm kernel drivers you mean?
<apritzel> in the host kernel, yes
orly_owl has joined #linux-sunxi
<longsleep> ok well thats something at least, might be possible to backport - not today though :)
<longsleep> virt/kvm did not change with the new BSP - so no luck there
<apritzel> if you can find that set_bit the report complains about
<apritzel> and change it into a __set_bit
<apritzel> I think that was the fix
<longsleep> sure i guess that should be possible
<apritzel> yeah, but as you said, not really urgent
<longsleep> sounds like a quick fix though
<apritzel> yeah, grep for vgic_v2_sync_lr_elrsr
<longsleep> found it and replaced, lets build
<apritzel> not even sure we eventually went for the non-atomic set_bit here, or we changed the alignment of the bitmap in question
<apritzel> (as the latter sounds like the proper fix)
<longsleep> it cannot crash any worse :)
<apritzel> but that crappy kernel it shouldn't matter ;-)
avph has quit [Ping timeout: 240 seconds]
<longsleep> exactly
<apritzel> well, it could take all the data with it ...
<longsleep> may the data rest in peace then
<longsleep> my image building gear is quite solid, so i do not care overly much
<longsleep> i even added instructions how to install X11 on arch so i do not have to look it up all the time on Google
<longsleep> apritzel: btw, did you have time to check up on the Firefox crashing issue?
<apritzel> no, sorry, forgot about that
<apritzel> but I am pretty sure that bug was fixed
<apritzel> is that the firefox binary provided by Arch Linux?
avph has joined #linux-sunxi
<apritzel> does their arm64 kernel come with PAGES_64K?
<longsleep> apritzel: nope, also their sunxi drivers for wifi and other stuff use compat types all over the place
<longsleep> (without any proper ifdefs)
<longsleep> i did not bother to fix that up or disable the parts which need compat enabled
<longsleep> apritzel: guess what, it works ! hooray!
<longsleep> [ 0.588921] No soundcards found.
<longsleep> [ 0.592850] VFS: Mounted root (9p filesystem) on device 0:15.
<longsleep> [ 0.596167] devtmpfs: mounted
<longsleep> [ 0.599800] Freeing unused kernel memory: 736K (ffffff80049b3000 - ffffff8004a6b000)
<longsleep> Mounting...
<longsleep> sh-4.3#
<longsleep> sh-4.3# uname -a
<longsleep> Linux 4.5.0-rc3-next-20160212+ #1367 SMP PREEMPT Tue Feb 16 17:46:40 GMT 2016 aarch64 GNU/Linux
<apritzel> wohoo
<longsleep> i guess thats something
<apritzel> I feel a bit bad now that I helped you enable this on their shitty kernel ;-)
<longsleep> hehe
<KotCzarny> dirty job
<longsleep> i will come back to your Kernel - i promise
<longsleep> after i fixed 1000M networking and built a new image :)
<longsleep> but thats for tomorrow
mzki has quit [Quit: leaving]
<longsleep> apritzel: https://github.com/longsleep/linux-pine64/commit/2d4c3da2c6adf3b0de46aba25c7cc6a5c90a3bb9 - i gave you full credit so you can feel even more bad :P
<apritzel> oh great, hope that _m_a_z_ does not see this ;-)
mossroy has quit [Quit: Quitte]
<longsleep> hehe i will not tell
ricardocrudo has quit [Remote host closed the connection]
<tkaiser> Anyone here that had a look in the new A64 BSP what sun8iw10/sun8iw11 might be?
<apritzel> tkaiser: something with A7s :-P
<longsleep> most of the changes in the new A64 BSP seem to be related to either sun8iw11/11 or rtl87XX
<tkaiser> A53 or A7? I don't care as long as it's slow! ;)
Nacho has joined #linux-sunxi
alexst has joined #linux-sunxi
alexst has quit [Client Quit]
jstein has quit [Remote host closed the connection]
nove has quit [Quit: nove]
<tkaiser> longsleep: Is there something interesting in the headers of arch/arm/boot/dts/sun8iw10p1.dtsi or arch/arm/boot/dts/sun8iw11p1.dtsi?
<longsleep> tkaiser: i pushed it all to https://github.com/longsleep/linux-pine64/tree/lichee-dev-v3.10.65-bsp1.2/arch/arm/boot/dts if you want to look yourself
premoboss has quit [Quit: Sto andando via]
<tkaiser> longsleep: Thx, Sorry I missed that
<longsleep> tkaiser: i did not see anything except sun8iwwhatever platform
<longsleep> but also did not look much yet
<longsleep> tkaiser: did you see http://paste.ubuntu.com/15174117/ - easy overview of what changed in the kernel tree in comparison to the earlier BSP
<tkaiser> longsleep: Sure, there I spotted sun8iw10/11
<longsleep> ah :)
<ssvb> tkaiser: the allwinner naming scheme is explained at http://linux-sunxi.org/Allwinner_SoC_Family#2013_naming_scheme_change
<ssvb> sun8i means that it is something based on Cortex-A7
<tkaiser> ssvb: Yeah, I know. But I never heard of sun8iw10 before. And after looking through the .dtsi I'm just confused and decided to go to bed immediately! Cheers!
<tkaiser> ssvb: I know, just grepped through the both .dtsi files.
<tkaiser> Was just curious. We'll see which brand new A7 designs they show us soon ;)
yann|work has quit [Ping timeout: 240 seconds]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
leio_ has quit [Ping timeout: 240 seconds]
FDCX has quit [Remote host closed the connection]
IgorPec has joined #linux-sunxi
yann|work has joined #linux-sunxi
candratech has quit [Quit: Page closed]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
tomboy65 has quit [Quit: Uhh ... gotta go.]
tomboy64 has joined #linux-sunxi