<KotCzarny>
but for a quickie just grab the already built one
<KotCzarny>
everything should work out of the box
willmore has quit [Ping timeout: 276 seconds]
asmir has joined #linux-sunxi
<KotCzarny>
keep in mind armbian uses armhf debian repos and adds only few allwinner specific bits
<KotCzarny>
so it's just plain debian
<KotCzarny>
or ubuntu if you choose that one
<ordex>
oh nice, I like plain stuff
<KotCzarny>
do you plan to use media decoding on your board?
<ordex>
nope
<KotCzarny>
then you can go with mainline(vanilla)
<ordex>
you mean debian vanilla ?
<KotCzarny>
igor named his builds as legacy (3.4.x kernel) and vanilla (mainline kernel, 4.x)
<ordex>
I see
<ordex>
thanks for explaining
<ordex>
ah, what about the wifi driver ? I remember this chip is using a closed source driver - still the case ?
<ordex>
or is i tusing some rtl8* module now ?
<ordex>
*it
<KotCzarny>
dont see anything in build notes about wifi so should work out of the box
<KotCzarny>
probably using mainline kernel driver
reev has quit [Ping timeout: 252 seconds]
<KotCzarny>
anyway, bbl
<ordex>
cool
<ordex>
thanks KotCzarny, ttyl
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
reev has joined #linux-sunxi
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
jernej has quit [Ping timeout: 252 seconds]
FDCX has quit [Remote host closed the connection]
asmir has quit [Quit: WeeChat 1.0.1]
willmore has joined #linux-sunxi
<edolnx>
I was wondering if someone could give me some pointers on getting UART2 working on a pcDuino3-nano? I think I need to modify and recompile the dtb but my first attempt didn't seem to work...
domidumont has quit [Ping timeout: 276 seconds]
IgorPec has quit [Ping timeout: 248 seconds]
Keziolio has quit [Ping timeout: 252 seconds]
Keziolio_ has joined #linux-sunxi
domidumont has joined #linux-sunxi
IgorPec has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
cajg has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
<NiteHawk>
don't we usually want the vendor "prefix"? so make "Orange Pi mini" a redirect to "Xunlong Orange Pi mini"
<plaes>
ah yea.. the other way around
<KotCzarny>
:>
<plaes>
like that? :)
<KotCzarny>
move the 'one' and 'pc then
<KotCzarny>
to make things consistent
<plaes>
doing it
<KotCzarny>
also, out of curiosity, why is my ip misreported?
<NiteHawk>
the xunlong pages still give me the creeps... a lot of it was created back then by some poor marketing drone of them, and consists of clueless copy&paste from the banana pi information - quite often factually wrong / not applicable to the devices
<KotCzarny>
even from different networks, is wiki behind some http-nat ?
<NiteHawk>
cloudflare caching / CDN ?
<ordex>
codekipper: yeah i think i need a few patches
<ordex>
I am creating a new target profile in openwrt
<ordex>
and go through he various things
<ordex>
first of all i ave t change the target for uboot
<ordex>
*have
<KotCzarny>
nitehawk: yeah, but isn't it making ip user bans flaky?
<NiteHawk>
KotCzarny: i guess so. but with the dns "out of control" (handled by cloudflare), you're unable to tell which 'incoming' circuit a user will be assigned to ("originating" ip from the wiki's point of view). thore are the implicit drawbacks of these kind of networks
<NiteHawk>
s/thore/those/
<Wizzup>
that and cloudflare is particularly evil
<NiteHawk>
Wizzup: how so? =)
<KotCzarny>
nitehawk, i think i remember ip being correct few weeks/months ago
<Wizzup>
They are very annoying to Tor
p1u3sch1 has quit [Ping timeout: 244 seconds]
<Wizzup>
and they are basically just a mitm
<NiteHawk>
KotCzarny: agreed. maybe they changed their caching logic / handlers for post requests?
p1u3sch1 has joined #linux-sunxi
<KotCzarny>
when i first noticed 162.* ip, i thought wiki got hacked ;)
<codekipper>
ordex: just hack similar patche in and then make menuconfig to select your device
<ordex>
yeah
<ordex>
I think the most important change was the target of uboot
<ordex>
but the rest...should be the same as the a20lime
lerc has quit [Ping timeout: 268 seconds]
lerc has joined #linux-sunxi
lerc has quit [Ping timeout: 260 seconds]
lerc has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
vishnup has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
iamfrankenstein1 is now known as iamfrankenstein
viccuad has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 246 seconds]
phil42 is now known as phil43
phil43 is now known as phil42
medvid has quit [Ping timeout: 260 seconds]
medvid has joined #linux-sunxi
Keziolio_ has quit [Ping timeout: 244 seconds]
afaerber has quit [Quit: Ex-Chat]
hipboi has quit [Quit: This computer has gone to sleep]
TheLinuxBug has quit [Ping timeout: 264 seconds]
TheLinuxBug has joined #linux-sunxi
<ordex>
codekipper: any clue as of why openwrt produces a .img.gz and then we have to gunzip it before writing it on the sdcard ?
<ordex>
what is the sense of that ?
reev has quit [Ping timeout: 252 seconds]
afaerber has joined #linux-sunxi
<mripard_>
wigyori: ^ :)
<KotCzarny>
ordex: maybe because you can pipe gzip | dd ?
<ordex>
KotCzarny: sure, but I guess why gzipping a file that has to be gunzipped right after ?
<KotCzarny>
and because img is full of zeros anyway
<ordex>
I imagine there is a meaning behind
<ordex>
mh
<KotCzarny>
my guess is space saving
<ordex>
mh could be
<plaes>
imagine building multiple multi-gig images...
<ordex>
mhhh...ok
<ordex>
not really convincing :D but I was just curious
<wigyori>
ehe
<wigyori>
ordex: lack of updated doc
<wigyori>
let me take care of that :)
<ordex>
wigyori: thanks :) that would be great - feel free to ping me if you want me to read/check
<ordex>
I am trying to work on a new profile in the sunxi target for the orange pi mini
<wigyori>
ordex: the 'older' one with a20?
<ordex>
yes
<ordex>
v1.1
<ordex>
that is what is written on the pcb ;P
<wigyori>
ok, create the new profile in target/linux/sunxi/profiles, you'll need the image/Makefile as well, and please make sure that the uboot is built for the board as well (package/boot/uboot-sunxi) :)
<ordex>
yeah just finished with those 3 steps
<ordex>
compiling now :)
<wigyori>
nice :)
pietrushnic`away has quit [Quit: Coyote finally caught me]
<ordex>
wigyori: btw it seems there is a missing dep on uboot
<ordex>
this happened also before - the target compilation files because uboot was not built yet
<ordex>
it looks for the scr file and it is not there ye
<ordex>
yet
<ordex>
this happened when building for the a20-lime too
<ordex>
but maybe the problem is another :d
<ordex>
mh no, even after having compiled uboot manually i still get the same error ..
<ordex>
wigyori: even after compiling uboot with Orangepi_mini I still get Could not determine boot source
<ordex>
:(
<ordex>
oh maybe it's because of my old patch ..
<KotCzarny>
ordex, just install mainline uboot on that image
<KotCzarny>
and be done with it
<ordex>
KotCzarny: wait :D I am almost there :D
<KotCzarny>
;)
<ordex>
but really - this is mainline uboot with few lines modified
<ordex>
:D
<KotCzarny>
heh
<KotCzarny>
btw. did armbian image boot?
<ordex>
did not try yet :( I was at work
<ordex>
then I realized that I was using the wrong target, so now my first attempt was to fix the target
<ordex>
debian will wait :P
<ordex>
bootinggggggggggggggg
<ordex>
yesssss the kernel is loading :D
<ordex>
thanks KotCzarny, wigyori, codekipper :)
<KotCzarny>
:)
<ordex>
wigyori: the wifi module is not in by default - I guess I need to tweak the profile to make sure it compiles what needed for this board
<ordex>
KotCzarny: any link where I can read how to enlarge the root partition at runtime ?
SadSmile has quit [Quit: Leaving]
lemonzest has joined #linux-sunxi
<ordex>
what does sunxi stand for ?
<montjoie>
x is for any number, allwinner call their SoC sun4i sun8i etc..
ricardocrudo has quit [Ping timeout: 260 seconds]
<KotCzarny>
ordex: easiest to do is to pop the card/image into partition magic on pc
<KotCzarny>
but you can probably just edit partition table, reboot, then resize2fs (and probably another reboot)
<KotCzarny>
armbian has partition resizing in firstrun scripts
<KotCzarny>
but i personally do it a bit other way, 1/ install os, 2/ rsync files somewhere, 3/ resize partitions and recreate fs with proper stride/stripe params, 4/ rsync things back
<KotCzarny>
i do it because i prefer /boot to be on separate partition and to squeeze a bit more speed out of the card
cnxsoft has quit [Quit: cnxsoft]
<wigyori>
ordex: what wifi module does the omini has, that ampak module?
domidumont has quit [Remote host closed the connection]
IgorPec has joined #linux-sunxi
domidumont has joined #linux-sunxi
arokux_ has joined #linux-sunxi
yann|work has joined #linux-sunxi
willmore has quit [Ping timeout: 246 seconds]
<montjoie>
anybody with a cubieboard2 with kernel > 4.5rc6 ? (and a working ethernet)
mosterta has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
<cosm_>
montjoie: 4.5-rc2 IIRC
<cosm_>
why?
cosm_ has left #linux-sunxi ["Leaving"]
yann|work has quit [Ping timeout: 248 seconds]
willmore has joined #linux-sunxi
sdschulze has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 244 seconds]
p1u3sch1 has joined #linux-sunxi
<sdschulze>
Something is wrong with the Gigabit support of Olinuxino A20-LIME2; when I run it in 100Mb/s mode, it achieves kinda full speed, but in 1Gb/s mode, it hardly gets 1Mb/s.
<sdschulze>
running 4.3.0-0.bpo.1-armmp-lpae
pekka20 has quit [Quit: WeeChat 1.2]
pekka20 has joined #linux-sunxi
nove has joined #linux-sunxi
<montjoie>
cosm: because I lost ethernet link since 4.5-rc7
<memfrob>
hi all, i've been reading over the uboot code and kernel code for the H3 Orange Pi boards and i can't find anything about CPU frequency
<memfrob>
if i'm building mainline uboot and kernel, how and where is it getting the values for the cpu clock since it doesn't use fex, rather dts, but no cpu clocks in dts?
<memfrob>
i've been digging through all the sunxi code and the only cpufreq / throttling stuff i can find is in the "sunxi-3.4" branch here: https://github.com/linux-sunxi/linux-sunxi/ but that hasn't been touched in a year (no sun8i / orange pi support) so i'm really baffled.
<mnr>
sdschulze: It seem to hit only some boards and only on some switches.
<mnr>
sdschulze: The Olimex people have run various experiments and came up with the following:
<mnr>
the production time of the phy chip (RTL8211B/C) seems to play a role.
tomboy64 has quit [Ping timeout: 244 seconds]
<mnr>
Depending on the datecode of the chip (nominally the "same" chip) the behaviour is different
<mnr>
It also seems to depend on the model of the ethernet switch
<mnr>
There could also be a software component in it.
<mnr>
People have reported that they have problems with mainline but not with sunxi-3.4.
tomboy64 has joined #linux-sunxi
<mnr>
Sunxi-3.4 uses a different ethernet driver for the gmac.
<mnr>
I have done lengthy experiments with the GMAC TX/RX delay chain settings, but changing those from the defaults makes the problems worse instead of better.
<sdschulze>
So basically the hardware is broken?
<sdschulze>
I don't really need Gigabit; I was only curious.
<mnr>
sdschulze: that's not fully clear. If the same hardware works for somebody with kernel 3.4 but not with mainline, it looks like it is at least not a pure hardware issue.
<vagrantc>
(or at least there's a hackish workaround in software)
<mnr>
sdschulze: Could you perhaps give your board a try with a 3.4-based distribution, perhaps armbian with the "legacy" kernel?
<mnr>
sdschulze: I would be very much interested in the results.
<sdschulze>
If different chips with the same label show a different behavior, there is something wrong...
<mnr>
sdschulze: yes, that shouldn't happen, indeed.
<sdschulze>
(figuring out the easiest way to get 3.4 on mainline Debian)
<mnr>
sdschulze: 3.4 on mainline Debian is rather fiddly.
<mnr>
sdschulze: setting up a separate SD card with armbian "legacy" is probably easier.
<mnr>
sdschulze: That's why I am interested :-). The LIME2 and the A20-SOM-EVB design are very similar.
tomboy64 has quit [Ping timeout: 264 seconds]
<mnr>
sdschulze: yes, u-boot could also play a role. For example the TX delay chain settings are set by u-boot and not by the kernel. On the other hand, I have tested those and they are not the source of the problem.
<sdschulze>
I have a spare 2GB card; is that sufficient?
<mnr>
sdschulze: size should be enough for a very basic install, but 2GB cards are usually "classic" SD cards and not SDHC. There have been various reports of the Allwinner SD controller having problems with "classic" SD cards.
<mnr>
sdschulze: So you might experience problems with that card. Cards of 4GB and larger are usually SDHC.
tomboy64 has joined #linux-sunxi
<sdschulze>
I'll give it a try; if there are problems, they should be unrelated to the Gigabit issue, right?
<mnr>
sdschulze: yes
pekka20 has quit [Quit: WeeChat 1.2]
cosm_ has joined #linux-sunxi
pekka20 has joined #linux-sunxi
cosm has quit [Ping timeout: 244 seconds]
<mnr>
sdschulze: I'll have to leave soon, but I'll check the channel log tomorrow. I would also be very grateful if you could summarise your test results in an emain to debian-boot@lists.debian.org in the thread at https://lists.debian.org/debian-boot/2016/03/msg00149.html
<sdschulze>
OK, this will take w hile.
<mnr>
s/emain/email/
tomboy64 has quit [Read error: Connection reset by peer]