<nabblet>
hi, i am using your sunxi u-boot and sunxi linux kernel and want to change to mainline. reading in your wiki i saw several warning about various version-combinations of uboot and the kernel. What's the recommended "upgrade" path?
Gerwin_J has joined #linux-sunxi
akaizen has joined #linux-sunxi
<nabblet>
nevermind :) I actually asked this kind of question before...
mozzwald has quit [Ping timeout: 244 seconds]
mozzwald has joined #linux-sunxi
nabblet has quit [Quit: leaving]
Gerwin_J has quit [Quit: Gerwin_J]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
adj__ has joined #linux-sunxi
adj__ has left #linux-sunxi ["Leaving"]
kaspter has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<wens>
montjoie: yup the fix works
luoyi has joined #linux-sunxi
keh has quit [Ping timeout: 264 seconds]
kaspter has quit [Ping timeout: 250 seconds]
<wens>
ethernet and wifi working on bpi m2+
reev has joined #linux-sunxi
kaspter has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<montjoie>
wens: cool, was my fault to not reread syscon patch
<montjoie>
wens: your fix also made some progres on opiplus of alain
<montjoie>
apritzel1: so the ethernet works now ?
jernej has quit [Quit: Konversation terminated!]
WB6ALX has quit [Read error: Connection reset by peer]
WB6ALX has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<dave0x6d>
KotCzarny: is mainline oPi One decent enough for daily usage yet?
<KotCzarny>
havent checked yet
<KotCzarny>
for now i need better power brick
<KotCzarny>
(which im buying now, almost decided on meanwell rs-50-5)
<dave0x6d>
Dang, how many watts does it take?
<KotCzarny>
i own opi+2e
<KotCzarny>
not opione
<KotCzarny>
and my 2A brick is not enough for full cpu load
<dave0x6d>
I was gonna power my One with a 2.54mm DuPont connector, hopefully it won't melt...
<dave0x6d>
Wow, do these top out at 15W then?
<KotCzarny>
who knows, but for stable operation it should have some power margin
<KotCzarny>
opi+2e has a bit of more peripherials than opione
<KotCzarny>
emmc, wifi, 2gb of ram
<KotCzarny>
thats why its more power hungry
<dave0x6d>
I was thinking of maybe doing a Orange Pi cluster once my EC2 and DO credits run out.
<wens>
i running my boards from a anker 60w 10 port usb charger
<buZz>
time to order me a pocketchip
<buZz>
before the reduced price stops ;)
mossroy has joined #linux-sunxi
<oliv3r>
wens: i'm sure you know :) but is a MAC address programmed into the emac/gmac/dw part (there are registers for it) or set via the mdio into the phy. I'm wondering if those registers are just 'storage' or if that is actually the method of setting a mac addres
<bbrezillon>
ssvb: hi, how do you want to proceed with the changes you asked for (sunxi-nand-image-builder)?
<bbrezillon>
will you revert my patch or should I do incremental patches?
<NiteHawk>
bbrezillon: oliv3r merged it into master, so i'd dislike "rewriting history" - we should build upon that. (if it still would have been at PR stage, force-pushing updates is *somewhat* okay)
paulk-aldrin has joined #linux-sunxi
<NiteHawk>
best practice is probably to open another, 'incremental' PR that can be reviewed - and will then be merged when accepted
<bbrezillon>
NiteHawk: ok
<NiteHawk>
bbrezillon: but as said - for me, reviewing on the ML is fine too
<bbrezillon>
NiteHawk: ok, I'll do both so that you can merge the changes directly if you're happy with, but I prefer reviews on the ML ;)
enrico_ has joined #linux-sunxi
<NiteHawk>
sure, np :)
cnxsoft has quit [Quit: cnxsoft]
cnxsoft has joined #linux-sunxi
<NiteHawk>
bbrezillon: btw - is there a (very) small testcase (reference data) that could be added for verifying that sunxi-nand-image-builder works correctly? i'm working on adding some functional tests to the sunxi-tools repo, and that might be nice to have too
reinforce has joined #linux-sunxi
akaWolf has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
Worf has joined #linux-sunxi
<Amit_T>
Where can I get armv8 toolchain for i686 host ?
<Amit_T>
I have armv8 toolchain that works on x86_64 host but I need it for i686 host.
<buZz>
KotCzarny: sry, should have clarified as x86
<KotCzarny>
some itx board cpus dont do 64bit
<KotCzarny>
and i think intel had some low power cpus without 64bit too
<Amit_T>
buZz: what do you mean, on ubuntu 12.04/i686 , is it possible run aarch64 toolchain ?
<wens>
KotCzarny: it doesn't support x86 either :p
<KotCzarny>
wens, details, details :P
<buZz>
Amit_T: there is no requirement to run a 64bit OS to run a 64bit-TARGETTING toolchain
<buZz>
Amit_T: there is a requirement to not keep systems never updated, on +5 year old distros
<jonkerj>
hello everyone, I'm trying to get mainline working on my orange pi plus (H3). Most is working fine, except ethernet
<jelle>
jonkerj: it's not supported mainline yet I think
<enrico_>
bbrezillon: sorry to bother you again, i've compiled chip u-boot (2016.01 next) for lime2, added some nand options in config, nandwrite in mtd0 but it doesn't boot (no console output at all), any hints?
<jonkerj>
I've tried wens' h3-emac, jwr's sunxiwip, and montjoie emac-wip, but they all fail
<jonkerj>
most of them complaining about not able to attach to the PHY
<Amit_T>
old distros: with ubuntu14.04, my graphics card really don't work, now what ?
<KotCzarny>
jelle, do you know if/when is eth support planned for h3?
<jelle>
KotCzarny: I am not working on it, so no :-)
<jonkerj>
jelle: well, the patches and wiki suggest it could/should be working
<bbrezillon>
NiteHawk: we could provide reference images to do the non-regression tests, but these images will be built with this tool in the first place :)
<bbrezillon>
enrico_: oops, forgot --ecc 64/1024
<wens>
can't figure out why brcmfmac fails to load firmware from fs :(
<wens>
the file is there, the path is correct...
<NiteHawk>
bbrezillon: m-kay... at least that somewhat should still be a safeguard against introducing regressions later on? admittedly i'm not sure if it's worth the effort
<enrico_>
bbrezillon: i think ecc was 40 from the datasheet, or is it needed by the brom code to be like that?
<bbrezillon>
NiteHawk: yep, that would be useful for non-regression tests, but I don't think we want to keep a whole bunch of pre-generated images in the sunxi-tools sources
<bbrezillon>
that's up to you, let me know if you want me to add this kind of tests
<NiteHawk>
yes, that's my concern - we're either 'flooding' the test suite with ecc images, or risk problems going undetected. and in the latter case we might just as well do without the test...
<NiteHawk>
bbrezillon: i took the liberty to fix your PR text ... you have "please do merge" there :D
zoobab has joined #linux-sunxi
<NiteHawk>
s/have/had/
<bbrezillon>
thanks :)
fdcx has joined #linux-sunxi
<bbrezillon>
enrico_: it's probably safer to repeat the SPL image every 64 pages within the erase block
<bbrezillon>
and since your NAND seems to require data scrambling, you might want to fill the gaps between to images with pseudo random data
<bbrezillon>
s/to/2/
<enrico_>
bbrezillon: right now i have the problem that it doesnt find u-boot (Trying to boot from NANDSPL: failed to boot from all boot devices### ERROR ### Please RESET the board ###)
<bbrezillon>
enrico_: you're using nextthing/2016.01/next right?
<jonkerj>
wens: it seems to work, tnx!
<enrico_>
yes
<enrico_>
added nfc to sun7i/lime dts
<bbrezillon>
and you've flashed the uboot binary (u-boot-dtb.bin) @0x400000
<bbrezillon>
in normal mode
<enrico_>
uhm maybe it was u-boot.bin (without dtb), let me check
<wens>
jonkerj: cool
<bbrezillon>
doesn't seem to be a 'missing dtb' problem
<wens>
git fetch mmc
<wens>
oops
<bbrezillon>
you've changed U_BOOT_OFFS and U_BOOT_REDUND_OFFS to 0x400000 and 0x600000
<enrico_>
yes
Worf has quit [Quit: Konversation terminated!]
<enrico_>
nandwrite -p /dev/mtd2 u-boot-dtb.bin
<enrico_>
and mtd3
<bbrezillon>
oh, and can you try to pad the u-boot-dtb image with 0x0 until the end of the block
<KotCzarny>
another clue: my eth on banana starts acting up when some music is playing
<plaes>
shared IRQ?
hansg has quit [Quit: Leaving]
gianMOD_ has quit [Remote host closed the connection]
<KotCzarny>
playes: even if shared irq it should be fixed
tkaiser has joined #linux-sunxi
<KotCzarny>
and no, audio irq is on cpu0, eth on cpu1 (assuming 1c02000.dma-controller is audio)
<tkaiser>
KotCzarny: Since you're using your BPi M1 always in 'low power' mode try to increase load a lot: 'stress -c 2 -m 2' for example. Just to rule out one common reason for such failures: undervoltage (GbE PHY needs approx. an additional 180 mA)
<KotCzarny>
tkaiser, yup, it triggers it
<tkaiser>
If you would use Armbian's kernel you could read out voltage available to AXP209 I guess
<KotCzarny>
cpu is quite hot with 4.7 too, hrm, 51C, or its just broken reading
<tkaiser>
KotCzarny: Please stop mixing up temperatures and voltages. It get's boring ;) Especially with A20 where chances are rather high to get values that are not precise at all
<KotCzarny>
tkaiser, its just a note this time, not saying its the reason
<KotCzarny>
and as i said, reading might be wrong
<tkaiser>
You can't trust the readouts for A20. Still uncalibrated. You focus on possible reasons not unrelated symptoms.
<tkaiser>
And as already said: Mikhail provided some patches for AXP209 where all this consumption/voltage stuff could be read out easily. If you power the board through Micro USB this is always the first place to look
<montjoie>
apritzel: which uboot branch I need to use your a64-v5 ?
<KotCzarny>
tkaiser: i've ordered good psu today, with 10A out, should be enough for bpim1+opipc+opi+2e
<apritzel>
I used the latest HEAD
<apritzel>
montjoie: but you can't rebuild the firmware stuff without my ATF patches
<KotCzarny>
also, can you remind where is that axp patch for mainline?
<apritzel>
which I just haven't managed to push yet
<apritzel>
(sorry, only 24 hours here per day)
<enrico_>
bbrezillon: thanks i'll try and let you know
<apritzel>
montjoie: so for the time being: just use the firmware image, that has everything you need: boot0, ATF with PMIC enablement and the latest U-Boot
<tkaiser>
KotCzarny: 10A sounds nice but if you have an AWG 28 rated cable between your 5V source and the board under some load voltage might drop way below 4.5V
<KotCzarny>
tkaiser: nope, im going to power it via gpio then
<apritzel>
montjoie: then compile a64-v5 with defconfig and put the resulting "Image" to the FAT partition on the microSD
<JohnDoe_71Rus>
i have trouble with d-sub monitor + hdmi-d-sub converter. mainline u-boot 2016.01 no image on screen. probably no edid from converter
<apritzel>
montjoie: yes
<tkaiser>
KotCzarny: Ok, if you really want to fry your board then do it. You've been warned that Oranges are not Bananas
<JohnDoe_71Rus>
how to fix?
<KotCzarny>
JohnDoe_71Rus: is that dumb 'converter' ?
<KotCzarny>
otherwise you might try disabling hdcp
<KotCzarny>
tkaiser: isnt gpio pin connected to dcin on bpim1?
<KotCzarny>
and i say i will power my bpi via gpio, for oranges i will use normal barrel plug
<bbrezillon>
NiteHawk: I have a new version of the 'nand-image-builder improvements' series ready, but I'll wait a bit for other reviews (unless you think it's not necessary)
<tkaiser>
KotCzarny: Look at schematics to be sure. AFAIK it's not since many many many people already suffered from this crappy Micro USB connector and for BPi M1 the accepted solution is powering through SATA connector and for Lamobo R1 and BPi M1 as well also providing 5V on battery connector (solder pads on BPi M1)
<tkaiser>
AXP209 will disable charger if voltage there exceeds 4.2V
<KotCzarny>
btw. download links on bananapi.com changed
Ultrasauce has quit [Remote host closed the connection]
Ultrasauce has joined #linux-sunxi
<JohnDoe_71Rus>
KotCzarny: " disabling hdcp" can i fix it change config or need recompile u-boot?
<KotCzarny>
mainline or legacy?
<JohnDoe_71Rus>
armbian (cb2) u-boot 2016.01. think it is mainline
<tkaiser>
BTW: Does anyone here working on mainline for H3 knows if megous' THS patches (dvfs/throttling) for H3 boards (both SY8106A as on the larger Oranges as well as the more primitive SY8113B used on OPi One/Lite and NanoPi M1) are on its way upstream? https://github.com/megous/linux/commits/orange-pi
<KotCzarny>
the ones in first paragraph, not .fex ones
<JohnDoe_71Rus>
KotCzarny: to native hdmi work fine. trouble with converter. but old cubiez 3.4 kernel script.bin work with converter
<KotCzarny>
tkaiser, that axp20x sysfs patch doesnt apply cleanly to 4.7-rc1
<KotCzarny>
JohnDoe_71Rus: you've said mainline, then try those bootparams anyway
jelly-home is now known as jelly
kaspter has joined #linux-sunxi
<JohnDoe_71Rus>
KotCzarny: ok
ganbold has quit [Remote host closed the connection]
<tkaiser>
KotCzarny: As expected ;)
<mripard>
tkaiser: I haven't seen the patches, so I don't think so
<tkaiser>
mripard: This THS stuff is important at least for the smaller boards since given the actual experiences when testing H3 the SoC might be damaged easily without throttling
<mripard>
tkaiser: then push for him to mainline it
ganbold has joined #linux-sunxi
Akagi201 has quit [Remote host closed the connection]
<tkaiser>
mripard: I'll ask him about status. IIRC he wanted to send them upstream, came into IRC chat a few weeks ago and then disappeared again. And at least I'm too inexperienced (managed to use his patches but then my boards didn't boot anymore and I got lost between u-boot and kernel)
<bbrezillon>
ssvb: not sure what you really want. Do you want to delay NAND devs until the sunxi-fel NAND detection/flashing infra is ready, or are you just showing where we should head to
<tkaiser>
I would like to add OPI Lite to OPi One page in our wiki since they're really pretty similar. Any objections? And if not how to change the title from 'Xunlong Orange Pi One' to 'Xunlong Orange Pi One / Lite'?
<KotCzarny>
i think that needs more powerful account
<KotCzarny>
funfact: thunderstorm can turn off the bpi-m1
<KotCzarny>
let's see if it can be powered on again
<NiteHawk>
hmmm... is that combined title a good idea? maybe a page redirect would be better. on second thought, both models could redirect to a common page
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<tkaiser>
NiteHawk: That was my idea, 4 redirects to the combined page (2 with 'Xunlong ' prefix, two without)
<KotCzarny>
or just add lite as a variant of one ?
<NiteHawk>
tkaiser: you'd need "bureaucrat" access level to move pages, or i could do that for you.
<NiteHawk>
what's the main difference between "OPi Lite" and "OPi One"?
<tkaiser>
NiteHawk: The less permissions the better, please do it :) OPi One has EMAC that is saved on Lite. Lite has 8189FTV WiFi, one more USB host port exposed, Microphone and IR. That's it.
<NiteHawk>
in case it's just a stripped down version, i'd treat it as a variant and have the "Lite" pages redirect to the existing ones
Net147 has quit [Quit: Quit]
<tkaiser>
NiteHawk: No it's not stripped down but both can be treated as variants. So I will add Lite to One as variant and if some bureaucrat decides whether renaming is ok or not then this will happen or not ;)
<tkaiser>
Both are pretty similar due to same voltage regulator (thermal behaviour), dimensions and most features.
<NiteHawk>
seems sensible - so I'd rename the page and add the placeholders... redirect pages, here I come! :D
Net147 has joined #linux-sunxi
<tkaiser>
NiteHawk: Thx, then I wait editing and start photo shooting with Lite now. Sunlight is perfect at the moment ;)
<KotCzarny>
i would make two pages: xunglong orange pi (a20) and xunlong orange pi (h3) then list respective models there
<KotCzarny>
with differences
<KotCzarny>
and delete all other orange pi pages
<tkaiser>
KotCzarny: Don't do this please!
<buZz>
are you sure those are the only two?
<KotCzarny>
;)
<KotCzarny>
buzz, yup, with options and strippings
<buZz>
sure that funklong isnt also producing them?
<NiteHawk>
tkaiser: we can't have the / in the page title at that particular place! alternatives?
<KotCzarny>
tkaiser, but more seriously, most sunxi boards are similar, and so the problems/tricks and tricks
<NiteHawk>
it works with the suggested title
<NiteHawk>
mhmm... that makes it a subpage, which is not good :(
<tkaiser>
NiteHawk: Yeah, and if '%2f' doesn't work either then maybe using ' & '?
<NiteHawk>
%2f wont't make a difference, i think '&' is reasonable
<tkaiser>
KotCzarny: Whatever you do don't delete individual pages. They are necessary since pictures are needed, buttons have different locations, and such things like DRAM reliability testing needs own pages. What you can do _if_ you want to improve things is to use sub pages (/) and put specific information there and then link from all device pages to there. Eg. state of mainline kernel and u-boot since this is really 99 percent
<tkaiser>
the same for all H3 Xunlong boards.
<KotCzarny>
another idea would be some funky utf sign
<KotCzarny>
tkaiser: i was just kidding, not going to
<tkaiser>
NiteHawk: Thx, I will then clean up the mess regarding contents there this evening and add Lite
nove has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
premoboss has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
* jonkerj
is not an expert on mediawiki, but isn't there a way to include common information in one place instead of duplicating pages?
<KotCzarny>
yup
<jonkerj>
it seems the discussion above could be solved if there is a way make a include/template hierarchy
<KotCzarny>
but it requires another page
<jonkerj>
just like how DT works
<NiteHawk>
jonkerj: you can use templates for that, but those could quickly become a maintenance nightmare on their own. and they're not very intuitive for 'casual' wikimedia users
<tkaiser>
jonkerj: KotCzarny: Feel free to try this out on an experimental sub page. The main purpose of this wiki is to get information into. If people have to study a few hours Mediawiki stuff before then this will stop. At least i don't like this.
<NiteHawk>
yes, try to encourage people to contribute - don't scare them away :)
reev has quit [Ping timeout: 240 seconds]
premoboss has quit [Quit: Sto andando via]
<KotCzarny>
tkaiser, btw. opi one page suggests powering via gpio pins, is that also in error?
reinforce has quit [Quit: Leaving.]
<oliv3r>
wens: as I expected, just wanted to confirm. it just struck me as odd that there are 3 32bit registers for the mac, and it looks like the mac is split up into 2 sections of 3 bytes each. what is the 3rd register used for ...
<oliv3r>
(we do not use it right now)
<oliv3r>
the dw driver for example, uses 4 bytes for the high part, and 2 bytes (of the 4) for the low part
<wens>
oliv3r: h3 emac? the mac is stored in 2 registers, one for lower 4 bytes, one for higher 2 bytes
<tkaiser>
KotCzarny: Nope, that's possible with all H3 boards from Xunlong (and convenient if you set up a cluster ;) )
paulk-aldrin has quit [Remote host closed the connection]
<KotCzarny>
tkaiser, umkay, so in oranges h3 case they are routed in the dc directly
<jonkerj>
tkaiser: agreed, it needs to be useable/simple
* jonkerj
is not going to change anything, just posing suggestions
iamfrankenstein has quit [Quit: iamfrankenstein]
IgorPec has joined #linux-sunxi
tkaiser has quit [Ping timeout: 240 seconds]
tkaiser has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Akagi201 has quit [Remote host closed the connection]
Net147 has joined #linux-sunxi
vagrantc has joined #linux-sunxi
reinforce has joined #linux-sunxi
pietrushnic has quit [Quit: Coyote finally caught me]
iamfrankenstein has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
mpmc has joined #linux-sunxi
Net147 has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
Net147 has quit [Ping timeout: 252 seconds]
gianMOD has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
Net147 has joined #linux-sunxi
jstein has joined #linux-sunxi
ricardocrudo has quit [Read error: Connection reset by peer]
gianMOD_ has joined #linux-sunxi
<vagrantc>
yay, pine64+ boards arrived!
diego_r has quit [Ping timeout: 244 seconds]
gianMOD has quit [Ping timeout: 240 seconds]
gianMOD_ has quit [Remote host closed the connection]
<vagrantc>
apparently the usb-serial adapter add-on requires jumper cables to actually use it?
gianMOD_ has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
gianMOD_ has quit []
<NiteHawk>
vagrantc: huh? that's UART-side / a peculiarity of your serial cable then, or?
<NiteHawk>
i'm connecting a cheapo PL2303 straight to the pine64 pins (euler or EXP connector, EXP recommended)
zuikis has joined #linux-sunxi
<vagrantc>
ah, the EXP connector looks like it would fit the connector
<tkaiser>
ssvb: I will wipe out eMMC on my OPi Plus 2E now (emergency replacement of a recently died Sun Fire280 at a customer ;) so can't test through eMMC boot scenarios. But shouldn't matter since IgorPec told me his OPi Plus 2E started its journey to you today :)
<bmeneg>
hello everyone, I would like to know if there is any kind of standard to the pin map on the old Kernel version, where .fex files were used to pass hardware information to the kernel.
mossroy has quit [Quit: Quitte]
<bmeneg>
what I mean by standard is the GPIO pins numbers passed to Kernel would be always the same to all distros using the old kernel version.
<NiteHawk>
bmeneg: the GPIO numbers are directly related to the routing / wiring / schematics of the device in question. so they shouldn't change between OSes or kernel versions
<bmeneg>
NiteHawk, the name and pad numbers are the same, but the reference passed to the kernel are completely different.
Nacho has quit [Ping timeout: 250 seconds]
Mr__Anderson has quit [Remote host closed the connection]
<NiteHawk>
vagrantc: i don't know that cable you got. the EXP connection is only described in the corresponding text section of our wiki. it has the slight advantage that it should prevent the uart RX from leaking current to the board
<bmeneg>
NiteHawk, for instance, on old kernels where .fex files are used, pins PH20 and 10 have references as 1 and 2 (according the link I sent), but on new kernel version the reference number passed to the kernel use a specific "formula" specified in the wiki page.
<bmeneg>
which are completely different numbers.
<vagrantc>
NiteHawk: i got whatever came with the backerkit thing ... it's got a 4-pin cable, and a 10-pin female connector that physically fits the 10-pin exp port, but no idea of the pinout (on the cable side)
<ssvb>
tkaiser: so you have lost your opi+2e now, this is sad?
<ssvb>
tkaiser: yes, I hope to receive this board soon and do some tests with emmc and mali drivers on it :-)
<NiteHawk>
vagrantc: no description provided? that's ... bad
Nacho has joined #linux-sunxi
<NiteHawk>
if it connects to four specific EXP pin, maybe you can deduct from the wiki description how it's supposed to fit the pin header?
<vagrantc>
NiteHawk: to add insult to injury, it doesn't even have a unique serial id ... so if i plug in multiples, it depends on arbitrary usb bus enumeration which comes up as ttyUSB0, ttyUSB1, etc. :(
<vagrantc>
NiteHawk: and the case doesn't fit with the cable plugged in, presuming you just plug it into the exp header...
* vagrantc
will just use jumper cables, as at least tx, rx and GND are labeled on the 5-pin to 4-pin cable
iamfrankenstein1 has joined #linux-sunxi
<NiteHawk>
vagrantc: i'm routing my uart through a case opening with jumper cables, too. otherwise I'd also have difficulties connecting to them.
<vagrantc>
apritzel: but the cable-side of the exp isn't well documented, so hrm.
<NiteHawk>
there are areas where the pine64 show's it "el cheapo" origin a bit :P e.g. it's a shame they couldn't afford power and reset switches on the board, and another gpio-driven led
* vagrantc
likes the acrylic case
<apritzel>
NiteHawk: but at least there are pads for those switches, I soldered two I found in my box and it worked like a charm
<NiteHawk>
bmeneg: if you look at it that way, then yes: they differ. it's two different systems of enumerating gpio pins for older (3.4.x) kernel and mainline (4.x)
<NiteHawk>
bmeneg: the .fex file just says "hey, i hereby declare 67 GPIOs pins. here are their ports" (in a somewhat arbitrary order). the 4.x kernel has a system of numbering pins based on PIO "bank" and pin number
<tkaiser>
ssvb: OPi Plus 2E is not 'lost', I just prepare to replace a Sun 'server' with the board. An aging Sun Fire 280 died hosting an image data archive for 20 Macs doing layout jobs. Image data has been uncompressed so it fits now on a 64GB SD card after applying compression to the TIFFs. And OPi Plus 2E is faster than this Sun Fire they used as server before. Weird. Really weird.
<NiteHawk>
nevertheless: among the same kernel familes ('legacy' vs. 'mainline') they won't differ from distro to distro
<NiteHawk>
..families
<jelly>
tkaiser: offtopic, how sane is it to host a basically file server on a SD card with usually has very limited number of writes?
<jelly>
s/ with / which /
* vagrantc
usually at most only puts /boot on SD
<tkaiser>
jelly: It's an archive, so almost WORM. And the whole idea is weird since I recovered the data in a Solaris x86 VM where they connected the aging SCSI RAID. But it's just fun to move a system that consumed +1000W with 8 rotating disks to a 5W setup without moving parts ;)
<bmeneg>
NiteHawk, but as you said, is it really arbitrary how people choose the gpio pins numbers or there is a standard somewhere as "best choice"?
<tkaiser>
jelly: For me having ECC RAM and filesystems that ensure data integrity (read as ZFS or btrfs) is a must on real servers. But that's different.
<NiteHawk>
bmeneg: if the device in question has some sort of "primary" GPIO connector (e.g. the 26- or 40-pin raspberry-types), then it may be a good idea to preserve the pin numbers from that for the corresponding gpio_pin_* declarations. other than that, i think it's really arbitrary
<tkaiser>
jelly: But to get a bit more on-topic again: On SBCs with mainline kernel and btrfs and often 'btrfs send/receive' to another storage location I wouldn't be that afraid storing data on SD cards.
<NiteHawk>
bmeneg: and usually people will just dump into .fex what they received from some vendor file anyway
<tkaiser>
jelly: After decreasing CPU and DRAM clockspeeds to a reasonable minimum value since bit flips aren't fun.
massi has quit [Remote host closed the connection]
fredy has quit [Ping timeout: 260 seconds]
<bmeneg>
NiteHawk, right, I am asking that because I am porting a library to the cubietruck platform and these old numbering schema just messed up my mind =). I think I will use the same "cubian" numbering schema and make some observations
<bmeneg>
NiteHawk, or do you have some other better option?
enrico_ has quit [Quit: Bye]
alain has joined #linux-sunxi
fredy has joined #linux-sunxi
<alain>
montjoie, wens : happy to report success for sun8i-emac driver on OrangePI Plus (running wens' latest version). You guys rock!!
<NiteHawk>
bmeneg: no idea, sorry. the connectors on cubietruck don't seem to fall into any scheme i recognize
<bmeneg>
NiteHawk, lol.. ok then, what can we do, right? =D I'll do my best. thank you very much
alain has quit [Ping timeout: 250 seconds]
<tkaiser>
Another one for the linux-sunxi wiki people here. We (at Armbian) want to start improving _user_ documentation a bit. Due to limited ressources by asking/encouraging users to do so (and there's at least one hardware vendor who tries to support that somehow). What about creating a stub page http://linux-sunxi.org/Orange_Pi_H3 with the main purpose to 'host' sub pages like http://linux-sunxi.org/Orange_Pi_H3/Use_GPIO_header or
<tkaiser>
The target audience of this stuff are _end users_ and not developers. Any objections? We could try to do this 'Armbian internally' but IMO that's not the right way since it's mostly hardware related and a lot of distros people might want to use
<NiteHawk>
tkaiser: that would cover all Xunlong H3 devices, I presume?
<tkaiser>
s/and/and relevant for /
<tkaiser>
NiteHawk: Sure, all boards share so much. Applies even to the clones (BPi M2+ and FriendlyARM's NanoPi M1)
<NiteHawk>
to me that seems a useful idea - no objections from my side. maybe libv / turl / rella have some opinion on ^
pmattern has joined #linux-sunxi
<nove>
tkaiser: my opinion, is that general information should be done in a board agnostic way
<nove>
and anything that is specific to a board, should be in the board page
<tkaiser>
nove: Agreed. But I'm talking about stuff like 'get I2S working on OPi xy' (always the same with every H3 OPi)
<NiteHawk>
in the past stuff like the often went into subpages - but if many devices share certain components, that quickly become awkward. that's where the idea of a 'virtual' parent comes into play, i think
<nove>
libv: the definition of "open-source" is changing, that there is even thinking about finding a new word to describe the new thing that is being called "open-source"
<libv>
nove: both allwinner and banana pi have had enough time to learn and have been thrashed often enough for being who they are
<libv>
they should know better by now.
Akagi201 has joined #linux-sunxi
<oliv3r>
wens: yeah h3 being designware, but the sun4i-emac stores them strangly and has an extra 3rd register :)
<oliv3r>
brb, rebooting
oliv3r has quit [Quit: leaving]
jernej has joined #linux-sunxi
<nove>
then new thing can be simplified as said in a comment in the above link, "you can use my software, if you ignore the law"
<KotCzarny>
[*] R.I.P. GMAC in my banana
<KotCzarny>
apparently thunderstorm damaged it today, can receive, cant send
<Turl>
did sbdy ping me here?
<libv>
KotCzarny: happens
<libv>
induction is a female dog :)
<libv>
KotCzarny: did your bpi at least reach 88mph?
<KotCzarny>
could be powerline surge too
<KotCzarny>
libv, nope, no flameys
<libv>
aw :(
Akagi201 has quit [Ping timeout: 260 seconds]
<KotCzarny>
funnily enough phy survived, because autoneg works
<NiteHawk>
turl: that's how i understood tkaiser. with a collection of subjects under a common Orange_Pi_H3 "parent". btw, tkaiser - pages usually include the manufacturer - so i guess "Xunlong_H3" would be preferable to "Orange_Pi_H3"
<Turl>
I don't have any objections, as long as it's device specific. General stuff (like common usb wifi chipsets and such) should probably go on the general namespace though
<Turl>
libv: ^ thoughts?
<Turl>
KotCzarny: storm once fried my cablemodem, router and onboard GbE on my PC
<Turl>
luckily it stopped there :)
iamfrankenstein1 has quit [Ping timeout: 260 seconds]
<tkaiser>
Turl: NiteHawk: I'll have to think about that stuff again. Another example. _Users_ are interested into using their devices. Eg using vdr on their H3 device. What rellla outlined here http://linux-sunxi.org/User:Rellla/Armbian applies to any H3 device and to any Debian based distro. And I think about where to store this sort of information
<KotCzarny>
turl, yeah, i had a friend whos modem was subject to induction of thunder striking 2 houses away, he said 'sparks everywhere, modem flying through the room'
mosterta has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<rellla>
I felt it was too generic to find it's place in the "public" wiki
<KotCzarny>
there are few howtos on the sunxi wiki already
<KotCzarny>
display, uart, spi etc
<tkaiser>
rellla: Sure but it can serve as instructions (at least according to change log you're really trying to be precise). And more such instructions should be available (and I still hope someone with some interest/knowledge in this stuff joins Armbian team to create maintained .debs from these instructions so users just have to do an 'apt-get install armbian-pvr' :) )
iamfrankenstein has quit [Quit: iamfrankenstein]
<rellla>
tkaiser: did you follow the csc thread i answered? I think there is sth messed up ...
jstein_ has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
<tkaiser>
rellla: Read through and I believe you're right. But won't look into it due to different priorities. Unfortunately the Armbian core team consists solely of ignorant CLI people ;\
<rellla>
Then we need a real howto section. But it's difficult to keep it specific but complete enough. <- the howtos
IgorPec has quit [Ping timeout: 260 seconds]
<rellla>
I don't think everyone would be glad of that :) wouldn't you, libv? :p
<vagrantc>
is that just theoretical support once boot0/ATF have 64-bit ports available?
<JohnDoe_71Rus>
tkaiser: good idea. as _end users_
Netlynx has quit [Quit: Leaving]
<rellla>
tkaiser: maybe too less interest in the media things, yes. Because there things get freaky. I use armbian just as a minimal system and tweak it for my needs like i did it with pure debian before. Its just more comfortable now imho. So nice piece of scripts...
<KotCzarny>
but for endusers there are operating systems which provide packaged goods
<KotCzarny>
so its a work for os maintainers, not for endusers
<KotCzarny>
(and for hackers/devs)
<rellla>
The "packaging" problems are the same. With debian and armbian.
<KotCzarny>
but users wont have to follow howtos, they just want an os that works, not to twiddle (that's for devs/hackers)
<rellla>
KotCzarny: why do they buy development boards then ;)
<JohnDoe_71Rus>
KotCzarny: as enduser i prefer lxde, but armbian has xfce desktop, and based on ubuntu
<KotCzarny>
JohnDoe_71Rus: armbian is based on scripts which use ubuntu or debian
<KotCzarny>
you choose your image
<mripard>
rellla: because every test compares it to the rpi
<KotCzarny>
and debian/ubuntu repos have lxde most likely
<KotCzarny>
just run synaptic
* rellla
was never a friend of the thousands of cubieboard images, you don't know whats inside...
<JohnDoe_71Rus>
and i choose console debian based (4.5.5) and install lxde and some else
<JohnDoe_71Rus>
now i have some trouble with localisation
<diego71_>
JohnDoe_71Rus: which kind of troubles?
<JohnDoe_71Rus>
diego71_: i choose ru_RU.UTF8 interface, but it still eng
<rellla>
and i won't download an 1GB image from some dubious file hoster as well. But yes, endusers like that probably.
<tkaiser>
rellla: Same reason brought me to Armbian (while I don't like some aspects of Debian at all. But if you want to have something users can deal with and should be able to follow RPi instructions somewhere on the net then being Debian based isn't the worst choice)
<rellla>
KotCzarny: i have two rpi here, but don't know what to do with them. Its no fun to join this mainstream "community". At least not for me. For me the rpi people seem to have (german) "Scheuklappen" sometimes
<KotCzarny>
rellla, i have replaced my x86 boxes with sbc
<rellla>
Just my personal opinion.
<KotCzarny>
one was server/router and another was audio player
<KotCzarny>
third is going to replace my desktop
<KotCzarny>
main reason was lowering power usage
<rellla>
My real "server" is 386 :) DVB server, music, file, squeeze, web... My focus atm is on sbc as clients. Music, video, weather station, squeezelite yeah.
<rellla>
There is so much that is possible, sadly too less time ;)
<KotCzarny>
with a20 you can do 'server' role almost completely
<rellla>
A 7" touch tft waits to do sth nice... Since over a year now.
<KotCzarny>
fridge notes?
<KotCzarny>
;)
<KotCzarny>
portable av player?
<KotCzarny>
game console?
<rellla>
KotCzarny: yes i know. I had cubietruck as a production server running, since some soldering broke :( since then i did not invest time to get a20 up as server.
<rellla>
Wait ...
<KotCzarny>
with armbian you are probably 10 minutes from achieving that
<phipli>
thought it wasn't running until I saw the blades were blurred
<jrg>
you had to mount it externally tho? couldn't get it inside the case?
<phipli>
I did, but only because of the heatsink
<jrg>
did you solder the wires on or just swap the leads for something that can connect to the gpio power?
<phipli>
there would have been room if I hadn't put on one, or had a slightly lower one
Nacho has quit [Quit: No Ping reply in 180 seconds.]
<phipli>
I've put two female wires onto it and wired into the gpio for now
<phipli>
undervoltage
<phipli>
but shouldn't really matter
<phipli>
I have some 5v fans the same size on the way in the post
<phipli>
I'll compare and use the best of the two
<jrg>
well... i need to solder a barrel connector to my bpi.. i'd rather put the fan on that than the opi plus 2e
<jrg>
just to see what the bananapi can do under load with enough amps and a fan/heatsink
<jrg>
it almost seems like under a load it may be impossible to keep all 8 cores on
<phipli>
:)
Nacho has joined #linux-sunxi
<phipli>
I think if I was overclocking I'd want to run this fan at the ful 12v
<phipli>
*full
<phipli>
I'll see how loud it is when I do that in a bit
<jrg>
i'm throttling this bpi to 1.2GHz
<jrg>
it's the only way it will stay stable but then again that could be to a lack of power from the microusb connector
<phipli>
The OPi One is a 1.2ghz H3
<jrg>
at least that's what tk was scolding me about lol
<jrg>
heh. not like the plus 2e is a bug bump
<jrg>
1.3GHz H3
<jrg>
i was looking for pi sized boards with gbit tho
<phipli>
isn't it 1.6?
<phipli>
the OPi PCs were 1.6, but it is a stupid speed without at least a big heatsink
<jrg>
Orange Pi product pages show H3 @ 1.6GHz but this can be considered marketing. Limiting maximum cpufreq to 1296 MHz is realistic and when using a heatsink the board can run rather heavy workloads on all 4 CPU cores at this clockspeed