lurchi_ has quit [Read error: Connection reset by peer]
lurchi_ has joined #linux-sunxi
lurchi_ is now known as lurchi__
jstein has quit [Remote host closed the connection]
lurchi__ is now known as lurchi_
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
libv_ has quit [Ping timeout: 260 seconds]
a|3x has quit [Ping timeout: 240 seconds]
libv has joined #linux-sunxi
a|3x has joined #linux-sunxi
lurchi_ is now known as lurchi__
nuuuciano has quit [Ping timeout: 255 seconds]
libv has quit [Ping timeout: 260 seconds]
dddddd has quit [Remote host closed the connection]
qeed has quit [Ping timeout: 240 seconds]
libv has joined #linux-sunxi
codefree has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
libv has joined #linux-sunxi
codefree has quit [Client Quit]
libv has quit [Ping timeout: 260 seconds]
tllim has quit [Read error: Connection reset by peer]
tllim has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
libv has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
book` has quit [Ping timeout: 248 seconds]
lurchi__ has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
book` has joined #linux-sunxi
thehungus has joined #linux-sunxi
<thehungus>
does anyone know what "sunxi-mmc 1c0f000.mmc: could not find pctldev for node /soc@lc00000/pinctr1@1c20800/mmc0@0, deferring probe" means? am trying to get mainline 4.15.2 going on an pcduino3b (A20) following the mainline u-boot and mainline kernel wiki pages.
<wens>
it just means something is not ready yet, and will try later, as in it is deferring probe of the current device
<thehungus>
kernel boots and panics as can't mount rootfs from mmcblk0p2, which it reports doesn't exist. CONFIG_MMC_SUNXI=y CONFIG_EXT4_FS=y, etc, ie. am pretty sure the required drivers are in the kernel
<thehungus>
the aforementioned message from sunxi-mmc is the only thing that even suggest there was a problem initialising MMC
<thehungus>
mmm, ok. is that to say it's probably not related and there's some other reason MMC can't be mounted?
<wens>
missing regulator drivers might be another caues
<wens>
* cause
<thehungus>
at the risk of sounding completely ignorant... regulator drivers?
<thehungus>
apologies, quite comfortable with desktop linux kernel builds and bootloaders, still quite new to u-boot and device tree, etc
<wens>
CONFIG_REGULATOR in kernel config
<thehungus>
CONFIG_REGULATOR=y
IgorPec has joined #linux-sunxi
<thehungus>
my config is based on cat /proc/config.gz from a running 3.4.79 kernel which shipped with the board, plus 'make ARCH=arm oldconfig' of course. using the sun71-a20-pcduino3.dtb device tree blob from the linux-4.15.2 tree
reinforce has joined #linux-sunxi
<thehungus>
perhaps a pertinent question is, what exactly is meant by the statement "mainline kernel should work on any bootloader (with the notable major exception being the A20)" on the mainline kernel howto wiki page?
<thehungus>
is there any way to know for sure that the kernel has picked up the .dtb loaded by u-boot?
<KotCzarny>
yes, by seeing some other devices powered up
<KotCzarny>
try compiling 4.13 or 4.14 to confirm you are not doing some silly omission
<thehungus>
thanks KotCzarny, can't see any 'OF:' line in my kernel output, so perhaps it's not picking up the dtb which would no doubt break everything
<thehungus>
how would building 4.13 or 4.14 tell me if I've ommitted something? worth asking as kernel rebuilds take quite a while on an A20...
<KotCzarny>
i'm booting quite old kernel though (4.9) maybe it changed later
<KotCzarny>
otoh, how do you compile it? which config do you use?
<icenowy[m]>
I think use 3.4 config as base config of 4.x is totally silly
<thehungus>
config dumped from /proc/config.gz on a working 3.4 kernel shipped with the board, plus make ARCH=arm oldconfig
<KotCzarny>
then it's wrong
<KotCzarny>
start with make sunxi_defconfig
<thehungus>
ok
<thehungus>
thanks :)
<KotCzarny>
as icenowy already mentioned 3.4 and 4.x differ totally
<thehungus>
so he did
<KotCzarny>
she
<KotCzarny>
:)
<thehungus>
duly noted...
<KotCzarny>
while i stick to 'there are no girls on the irc/internet' it's confirmed she is a she
<t3st3r>
thehungus> if you run mainline it could be somewhat different of sunxi kernesl. Quite different.
<thehungus>
sound advice always welcome, whatever the source. thanks for the tip
<thehungus>
will distclean and try again, thanks all
<t3st3r>
so to my taste its better to start from defconfig or at least test selected features very thoroughly.
<KotCzarny>
nah, in this case sunxi_defconfig is best bet
<KotCzarny>
then menuconfig to customize
<thehungus>
might leave custimization until after i get something that boots...
<t3st3r>
KotCzarny> yeah, I've meant it like that. I did it and it worked for me.
<t3st3r>
thehungus> you have to check selected configuration to ensure it boots or something. At very most you want all prerequisites for SD/MMC or whatever you use to boot
<t3st3r>
system would fail to boot if these not met obviously and it have to be expected
<thehungus>
t3st3r: have run make sunxi_defconfig and checked for CONFIG_MMC_SUNXI=y, CONFIG_EXT4_FS=y, and CONFIG_MACH_SUN7I=y (believe required to get the needed .dts?). is there anything else key?
<t3st3r>
well, if that got all the drivers for underlying block device (i.e. mmc controller and so on) and its prerequisites (e.g. regulators) for your platform it meant to be ok.
<thehungus>
ok, will give it a whirl. chur :)
<t3st3r>
I guess you can try to build and see if that worked and if you can see mmc card detected, etc. If it's not you've to carefully check things.
<thehungus>
to spend hours trolling through .config or hours waiting for a build which *might* work. that is the question... am willing to have some faith in my SBC being listed as supported and the promising status of the A20 on the mainlining effort wiki page. seems plausible that my misguided stunt with config.gz is probably the biggest problem here :D
clemens3 has joined #linux-sunxi
<t3st3r>
thehungus> menuconfig allows one to navigate config reasonably and you do not have to rebuild ALL kernel after changing few options if I remember.
<t3st3r>
buildystem would try to figure out what changed and build only that, if I remember. so trying small changes to config could be faster than hours.
<thehungus>
all true, but i've just distclean'd to be on the safe side. perhaps not necessary, but is done now. first build will take some time.
<t3st3r>
and also powerful machine to build kernels speeds things up. I guess sunxi defconfig builds for me like in few minutes.
<t3st3r>
so one may really want at least 6-8 cores to get things faster, make -j parallels very well after all
<thehungus>
building natively, seemed simpler. i have a day job, it may as well do some work while i do ;)
IlyaM has joined #linux-sunxi
<t3st3r>
hmm... you mean you build it right on ARM device?
<thehungus>
yup
<thehungus>
(i can hear the laughter from here)
<t3st3r>
Impressive :D but can be slow.
<t3st3r>
I'm fine with exotic configs and have been curious if someone dares to try that.
<t3st3r>
next strange thing would be using cluster like BenG83 created for something like distcc :D
cnxsoft has quit [Read error: Connection reset by peer]
<t3st3r>
(and it probably could work, why not?)
cnxsoft has joined #linux-sunxi
<t3st3r>
but from purely pragmatic standpoint, crosscompile of Linux kernel is quite straightforward, especially if your linux distro got arm toolchain in repos
<buZz>
t3st3r: dont they all? :)
<buZz>
i mean, one you run natively on ARM , usually has a ARM toolchain aswell
<buZz>
oh, cross
<buZz>
nmind :P
<t3st3r>
buZz> that's what I don't know so I would be careful about such an optimistic statement :)
<buZz>
i've run many distros on ARM , and usually just build the kernel natively
<buZz>
even with just 1GB ram, works fine
hanni76 has joined #linux-sunxi
<t3st3r>
I'm pretty sure one can get reasonable armhf or aarch64 toolchain from Debian/Ubuntu repos, but I'm not sure about others, never tried.
<buZz>
devuan is my flavour lately :)
<t3st3r>
I guess its repos mostly like debian anyway, esp in regard of crosscompile
<buZz>
uhuh
<thehungus>
it's slow but it's not unmanagable, i only have a few hours at most to throw at this project a day, so long builds can run while I'm away without really hold up too much
<thehungus>
also, i'm a gentoo fan (for good or worse) so things are gonna have to compile natively at some point
<t3st3r>
thehungus> sure, but it sounds like good way to build known good config. Trying different setups this way can prove to be time consuming.
<t3st3r>
I can imagine it improves a bit on high-end boards :)
<thehungus>
you make a good point. if this build doesn't work i'll definitely bang out cross-dev on my desktop
<t3st3r>
don't get me wrong, I think its cool platform is self sufficient :)
<thehungus>
but if it works, it's probably about 50/50. the last kernel took an hour and a bit, it's not thaaaat much slower than my aging desktop
<thehungus>
i'm not sure anything based on the A20 counts as high end :D
<t3st3r>
well, it is quite slow for things like that...
<buZz>
A20 is a lot faster than a pi-zero though :P
<t3st3r>
though I've dared native build of fairly large program even on arm VM, which is even slower on x86 :)
<t3st3r>
because cross-compiling apps on x86 is a bit over of my head :P
<buZz>
fyi, you could even do cross-compiling over distcc ;)
f0xx has joined #linux-sunxi
<thehungus>
buZz: true that. i've got one of those too, it just gets a pre-built distro flashed to SD end of story...
sr-digitronic has joined #linux-sunxi
<thehungus>
yeah i read about distcc, not sure what the advantage is if there's only one other system to run build jobs?
<t3st3r>
buZz> well, I had experience with that program and building it and it wasn't urgent so fire-and-forget was an option, VM did its job and I've got results.
<buZz>
well, if the other system is a 10 core xeon? a lot
<t3st3r>
so thehungus haves a point ... if you're not in hurry. Unfortunately trying different settings to get things right isn't exactly like that.
<thehungus>
the other system is an almost decade old i5. faster, but we're not talking a factor of a 100 here haha
<buZz>
:)
<t3st3r>
I guess it isn't factor of 100 but if you'll use all cores it can get like factor of 10 or so I guess. Well, you can do some fancy benchmark.
<thehungus>
hell probably plugging in a sata disk and migrating the root fs of mmc would probably help as much as anything
<t3st3r>
Could improve things, I guess, esp on SSD. HDD is only fast for builds if you have few GB of RAM to cache it.
<t3st3r>
so most IO hits the cache reasonably rather than waiting for heads movement
<thehungus>
scrap that idea then, pcduino3 has 1GB last i checked
<t3st3r>
so if one wants to do kernel builds on HDD they want at least 4-8Gb RAM to get disk caching on their side doing right thing
<thehungus>
the wee thing built gcc-6 natively, i'm not sure if that's a bigger hit than a linux kernel but it certainly took longer heh
<t3st3r>
well, I guess IO size when building kernel could exceed 1Gb and OS can't use all RAM for cache, so I would expect jobs getting stuck waiting for HDD
<t3st3r>
and it wouldn't speed up things for sure. OTOH if you've got plenty of RAM, "hot rebuild" when you're trying slightly different config can be at SSD-like speed.
<t3st3r>
due to massive cache hits on read, can speed things up even further.. but takes plenty of RAM and repeated builds.
<thehungus>
haha, probably you're right. plenty of RAM is not something this board has.
<t3st3r>
unfortunately HDDs suck at small "random" IO and kernel build is pretty much in this spirit
<thehungus>
i gather SSD also sucks at this
<t3st3r>
no, they dont
<t3st3r>
at least for reading it would give speed of light compared to HDDs
<thehungus>
really? well they obviously don't have issues with mechanical seek time, but i at least had the impression they were optimised for high throughput in bulk transfers, ie. for HD video recording, etc
<t3st3r>
they do not have seek time in orders of milliseconds, and it matters A LOT.
<thehungus>
granted it's mostly presumably a bus limitation with things like the A20, but one doesn't exactly expect the 90 MB/s stated on the box
<t3st3r>
Even fast SD card, not to mention modern eMMCs things and SSDs could beat HDD when it comes to random reads and so on.
<thehungus>
good to know
<t3st3r>
write could be somawhat worse since flash devices are large block devices internally
<thehungus>
one gets a factor of 4-5 faster reported by hdparam -t for the sata bus over the mmc bus on this sbc, but that is presumably not very relevant except for large transfers
<thehungus>
write surely matters for a kernel build
<t3st3r>
Linear IO only matters if you write large file at once or so and filesystem isn't very fragmented.
<thehungus>
too true
lemonzest has joined #linux-sunxi
<t3st3r>
its nearly ideal case one can get but kernel builds are nowhere like it
silviop has joined #linux-sunxi
<silviop>
quick & dirty , how change SUN4I_PINCTRL_40_MA from kernel 4.9 to 4.14 in dtbs ?
clemens3 has quit [Ping timeout: 248 seconds]
libv has quit [Read error: Connection reset by peer]
<t3st3r>
hmm? Edit desired DTS in arch/arm/boot/dts (or arm64) and run "make dtbs" again?
tllim has quit [Read error: Connection reset by peer]
<t3st3r>
that would rebuild changed DTS into dtb blobs and is quite fast
<silviop>
this costant give me syntax erreo in kernel 4.14 , i read somewhere that something is changed in pinmux
<silviop>
ok allwinner,drive = 3; give syntax error
<silviop>
fossxplorer: no mpi support in uboot and only patch for mainline kernel and a there i a lack of a procedure to extract panel initialization from android so there is a lot of work to do
<silviop>
i fell it will be full supported in 2020-21 as append on all allwinner socs (about 2-3 years from presentation)
yann has quit [Ping timeout: 260 seconds]
<fossxplorer>
I see. I'll look for other alternatives meanwhile. I got the first Samsung Chromebook i could try to install Linux on. Thanks for your reply!
msimpson has joined #linux-sunxi
<fossxplorer>
Or look for a solution to connect a screen to one of the sunxi supported devices. Mainly to be used in my car and leave it there
<IlyaM>
how to enable gpclk pin, cause I’m trying to generate signal and my logic analyzer shows nothing?
<thehungus>
t3st3r: build w/ sunxi_defconfig finished, booted first try without any config tweaks :) thanks again for taking the time to point out the obvious
amonakov has joined #linux-sunxi
<thehungus>
it's neat to see an SBC boot a recent vanilla kernel without having to faff with any patches, etc. although i guess i shouldn't be surprised, a lot of effort has obviously been put into this by the sunxi community. good job!
<plaes>
silviop: we now use standard gpio flags
<plaes>
SUN4I_PINCTRL_40_MA will change to drive-strength = <40>
<silviop>
thanks
<plaes>
and SUN4I_PINCTRL_PULL_UP would be just 'bias-pull-up';
<t3st3r>
thehungus> glad it worked :) and yeah vanilla kernels.. got to like 'em too :)
BenG83 has quit [Quit: Leaving]
lemonzest has quit [Quit: Quitting]
<KotCzarny>
t3st3r: on 2x H3 building kernel takes ~10-20 minutes
<KotCzarny>
on sdcard
tom_nov has joined #linux-sunxi
<KotCzarny>
mostly it takes cpu power, io isnt so much influencing in such setup
yann|work has joined #linux-sunxi
<t3st3r>
:D you've set up cluster?
<thehungus>
apparently?
<t3st3r>
and I guess sd card is fine as it lacks "heads seek"
<KotCzarny>
distcc is trivial to setup
<KotCzarny>
sometimes i'm even using remote machines connected via vpn
thehungus has quit [Quit: WeeChat 1.9.1]
aalm has quit [Ping timeout: 256 seconds]
<t3st3r>
for me it has been easier to run builds on powerful 8-core as crosscompile
thehungus has joined #linux-sunxi
<KotCzarny>
yeah, but native setup is nice in a way you dont have to keep pc around
<montjoie>
why not use both? distcc and powerfull 8 core ?
<t3st3r>
yeah, I like when things can be self sufficient
<montjoie>
adding 4+1 ARM core to my 8core give me improvments
<t3st3r>
montjoie> would distcc handle cross + non cross easily? oO
<montjoie>
it seems to work with same gcc version cross + native
<montjoie>
using gentoo help for having the exact same version
<thehungus>
woo gentoo (sorry)
<t3st3r>
from practical standpoint I've just got to point it works ok for me at reasonable efforts level
BenG83 has joined #linux-sunxi
fkluknav has joined #linux-sunxi
lkcl has joined #linux-sunxi
silviop has quit [Remote host closed the connection]
silviop has joined #linux-sunxi
<silviop>
back-light is shuttered off by kernel as axp initialization , how can address gpio1 that control backlight enable ? on kernel 4.9 i disable axp , but i like enable it
megi has joined #linux-sunxi
alexxy[home] has quit [Remote host closed the connection]
ornitorrincos has quit [Quit: ZNC 1.6.5 - http://znc.in]
<silviop>
I start tracing i2c between axp209 and cat gpio generate traffic but echo does not (direction of gpio is out), can make more test ?
IgorPec has joined #linux-sunxi
<wens>
try enabling gpiolib debug?
<silviop>
how ? I'm not kernel developer i only add some printk to axp209-gpio driver and trace i2c
<wens>
it's a kconfig option under the GPIO menu
<wens>
DEBUG_GPIO
<silviop>
ok compilin
BenG83 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 264 seconds]
megi has quit [Ping timeout: 255 seconds]
qeed has joined #linux-sunxi
rodrigoaguilera has left #linux-sunxi ["User left"]
paulk-gagarine-s has quit [Quit: Leaving]
paulk-gagarine has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
bamvor has quit [Quit: Connection closed for inactivity]
dave0x6d has quit [Quit: Connection closed for inactivity]
<f11f12>
is the layout of the bananapi m2 berry available?
<willmore>
zoobab, Do you know if that ch341 USB<>serial adapter in I2C mode has a proper hardware I2C controller or are they just bit banging it in the driver?
<BenG83>
the datasheet suggest they do it in firmware
<BenG83>
not sure if they just bit-bang
<BenG83>
I just ordered two of those things on Ali :P
<willmore>
BenG83, firmware of the CH341?
<BenG83>
yes
<willmore>
BenG83, do keep me informed.
<willmore>
firmware on the chip is good enough.
<BenG83>
I saw hints on some websites that there may be firmware updates for it
<willmore>
As long as it doesn't have those silly long USB latencies to it.
<willmore>
Interesting. You can download them to the chip or would they just be newer versions of the chip?
chlorine has quit [Remote host closed the connection]
<willmore>
How funny would it be if the cheapest USB<>serial adapter chips are really full up microcontrollers with USB and serial just doing the job of a bridge.
<t3st3r>
[17:56:43] <willmore> BenG83, firmware of the CH341? <- chinese serial ICs eventually happen to be some microcontroller with firmware.
<BenG83>
so I can have some I/Os
<t3st3r>
Fake FTDIs were like that as well.
reinforce has quit [Quit: Leaving.]
<willmore>
t3st3r, I find it humerous that they can do a full up uC when someone like FTDI can't even be competetive with a hardware solution.
<willmore>
BenG83, makes sense.
<willmore>
Also, 5V I/O which is not common for these <3.3V SoCs.
<t3st3r>
willmore> there're more epic examples. STM32 clones are cheaper than original ones AND use ... external flash IC. They do multi-chip package cheaper than single chip!
t3st3r has quit [Remote host closed the connection]
<BenG83>
that looks like it can configure the ch341 eeprom
<BenG83>
ah no it's another programmer sw
<BenG83>
but the EEPROM contents of the CH341 are in the datasheet
<BenG83>
where some things can be configured
<lurchi_>
the cp2102N is really nice, high baudrate, couple of GPIOs, 5V tolerant
<willmore>
BenG83, you can always use a bluepill board for GPIO. Burn firmata onto it and off you go. It's 3.3V, but it does have a bunch of 5V tolerant pins.
chlorine has quit [Remote host closed the connection]
libv_ has joined #linux-sunxi
afaerber has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
megi has joined #linux-sunxi
tllim has joined #linux-sunxi
BenG83 has joined #linux-sunxi
Christian_ has joined #linux-sunxi
megi has quit [Quit: WeeChat 2.0.1]
reinforce has joined #linux-sunxi
<Christian_>
Hi! Are there plans to add mali device tree bindings for the A13?
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-sunxi
msimpson has quit [Read error: Connection reset by peer]
aalm has quit [Ping timeout: 265 seconds]
<hanni76>
Christian_: I don't think that it's going to work even if you add DT nodes for it
clemens3 has quit [Ping timeout: 248 seconds]
<Christian_>
I had hoped it's only a matter of dt bindings (which I could not find all information for in that allwinner manual). Why do you think it wouldn't work?
<hanni76>
Christian_: i just said i am not sure
<hanni76>
you can try of course
<vagrantc>
device-tree is just a description of the hardware, it also needs support in appropriate drivers
<hanni76>
Christian_: there are examples for sun7i, sun8i.. and you can used a13 manual + binding txt file for reference
<hanni76>
*use
<hanni76>
vagrantc: driver exists, but I don't think anyone tested it with a13
<Christian_>
So now I'm stuck with dt details, for example I cannot find anything regarding the reset line. Any tips for better examples or documentation? How similar is the A10 compared to the A13 in respect to the GPU?
<vagrantc>
willmore: it's all video to me. :)
* vagrantc
mostly works with headless systems anyways
matthias_bgg has quit [Remote host closed the connection]
rej has quit [Quit: Obviously a major malfunction.]
rej has joined #linux-sunxi
rej has joined #linux-sunxi
rej has quit [Changing host]
<Christian_>
ups just found reset :) - ok, I'll just look harder. thx
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
IlyaM has quit [Quit: IlyaM]
chlorine has quit [Remote host closed the connection]
IlyaM has joined #linux-sunxi
<Christian_>
hanni76: thanks, and I do not expect problems with these parts of the puzzle. I have troubles mapping the docs to the device tree...
<hanni76>
Christian_: it should be very similar to ones for sun7i , sun8i
<Christian_>
aha
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
anarsoul|2 has quit [Ping timeout: 264 seconds]
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 276 seconds]
IlyaM has quit [Quit: IlyaM]
tl_lim has quit [Read error: Connection reset by peer]
tl_lim has joined #linux-sunxi
<BenG83>
I tried booting the 4.9 BSP kernel with mainline u-boot for science, but it seems it doesnt want to work with mainline ATF because of the arisc stuff