<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
<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
<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?
<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]
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
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 :-(
<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.
<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
<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
<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?
<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?
<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 ;)