Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
rwmjones has quit [Ping timeout: 240 seconds]
rwmjones has joined #linux-sunxi
donbit has quit [Ping timeout: 240 seconds]
dev1990_ has quit [Quit: Konversation terminated!]
perr has joined #linux-sunxi
ganbold has joined #linux-sunxi
doppo has quit [Ping timeout: 255 seconds]
rwmjones has quit [Ping timeout: 260 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
doppo has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 260 seconds]
rwmjones has joined #linux-sunxi
Andy-D_ has quit [Ping timeout: 268 seconds]
egbert has quit [Ping timeout: 240 seconds]
egbert has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
lkcl has joined #linux-sunxi
<wens> MoeIcenowy: all? or just some? check /sys/kernel/debug/regulator/regulator_summary for the tree
cnxsoft has joined #linux-sunxi
<wens> MoeIcenowy: you're missing the Xin-supply properties in your axp803 node
wookey has quit [Ping timeout: 260 seconds]
wookey has joined #linux-sunxi
techping has joined #linux-sunxi
victhor has quit [Ping timeout: 268 seconds]
pg12 has quit [Ping timeout: 252 seconds]
pg12 has joined #linux-sunxi
reev has joined #linux-sunxi
IgorPec has joined #linux-sunxi
terra854 has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
lennyraposo has joined #linux-sunxi
kloczek has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
<zoobab> @wookey you here!
<wens> sun6i hdmi DDC not getting anything :/
jernej has joined #linux-sunxi
f0xx has joined #linux-sunxi
<MoeIcenowy> wens: but how to specify them?
<MoeIcenowy> use a fixed regulator?
<wens> the ldos could be supplied from any dc-dc
<wens> the dc-dc's, if supplied from ips-out or the board's 5v supply, you can just ignore them
dave0x6d has joined #linux-sunxi
foxx has joined #linux-sunxi
<wens> then indeed, the regulator core will connect them to a dummy regulator
<MoeIcenowy> wens: but it won't hurt, right?
<wens> yes
jernej has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has joined #linux-sunxi
DullTube has joined #linux-sunxi
pmpp_ has joined #linux-sunxi
pmpp has quit [Ping timeout: 255 seconds]
OtakuNekoP has joined #linux-sunxi
reinforce has joined #linux-sunxi
<wens> EDID works now
<Net147> wens: cool. what changed?
<wens> DDC clock needs to be enabled first :p
<wens> on the A31, the DDC clock is a separate clock
<wens> now thinking about the whole thing, the tmds clock needs to be enabled as well
<Net147> TMDS clock is parent of DDC clock in current driver
<wens> yes, that is true for sun[457]i
<wens> but it still needs to be enabled
<wens> or the upstream PLL won't be started
<Net147> wens: interestingly, pll-video0-2x/hdmi-tmds/hdmi-ddc all have enable_cnt=0 and prepare_cnt=0 for me
<wens> and that is bad
<Net147> but it is actually outputting an HDMI signal and can read EDID
<wens> likely because the tcon has pll-video0 enabled
<wens> however it's a fragile setup
<wens> and explains why EDID doesn't work if you don't have HDMI plugged in during U-boot
<wens> because U-boot doesn't setup simplefb, and the PLL was never enabled
<wens> in the DRM driver, the TCON's special / dot clock is only enabled when the display is enabled
<Net147> enabling ddc clock seems to help
<Net147> it enables the ancestors clocks too
kloczek has quit [Read error: Connection reset by peer]
<wens> yes
Andy-D_ has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
foxx has quit [Ping timeout: 258 seconds]
matthias_bgg has joined #linux-sunxi
yann|work has quit [Ping timeout: 260 seconds]
ganbold has quit [Ping timeout: 240 seconds]
<MoeIcenowy> wens: have you checked my sun50i-a64-r-intc series patch?
ganbold has joined #linux-sunxi
deskwizard_ has joined #linux-sunxi
robogoat_ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 255 seconds]
miasma_ has joined #linux-sunxi
Pe3ucTop has quit [Write error: Broken pipe]
miasma has quit [Write error: Broken pipe]
beeble has quit [Write error: Broken pipe]
wookey has quit [Write error: Broken pipe]
xdanger has quit [Write error: Broken pipe]
_hp197 has quit [Write error: Broken pipe]
oliv3r has quit [Write error: Broken pipe]
doppo has quit [Write error: Broken pipe]
deskwizard has quit [Quit: No Ping reply in 180 seconds.]
robogoat has quit [Remote host closed the connection]
wookey has joined #linux-sunxi
oliv3r has joined #linux-sunxi
beeble has joined #linux-sunxi
Pe3ucTop has joined #linux-sunxi
doppo has joined #linux-sunxi
pmpp has joined #linux-sunxi
xdanger has joined #linux-sunxi
pmpp_ has quit [Ping timeout: 240 seconds]
uwe__ has joined #linux-sunxi
uwe_ has quit [Ping timeout: 260 seconds]
popolon has joined #linux-sunxi
kloczek has joined #linux-sunxi
kloczek has quit [Read error: Connection reset by peer]
yann|work has joined #linux-sunxi
thal has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
<thal> Hi, I am trying a cubieaio board and I am not able to use the serial port. Any need of enabling it?
lkcl has quit [Ping timeout: 268 seconds]
Andy-D_ has quit [Ping timeout: 252 seconds]
kloczek has joined #linux-sunxi
<thal> I'm just trying to write something from an hyperterminal on my PC to the board. In the board I just execute a cat /dev/ttyS4 to see what I'm writting but I don't see anything.
<KotCzarny> wrong terminal? reversed pins?
<thal> The same in the other way executing an echo to the device: echo "hello" > /dev/ttyS4
<thal> I think the terminal is ok, also the pinout
<mripard> thal: did you change the baudrate ?
<thal> yes, the baudrate is ok
<thal> just to ask if it is needed to enable anything....
<thal> I don't think so...
<mripard> thal: on both sides ?
<mripard> also on the device ?
<mripard> cat will not change it.
<thal> yes, on both sides. On the hyperterminal and on /dev/ttyS4.
<mripard> howo do you set it ?
<thal> stty -F /dev/ttyS4 9600
destroyedlolo has joined #linux-sunxi
<KotCzarny> try 115200 ?
<destroyedlolo> Hi
<destroyedlolo> I would like to know where are defined Vol+ / Vol- for my tablet.
kloczek has quit [Remote host closed the connection]
<destroyedlolo> Having a look on its Fex file, I can't see any key definition.
<destroyedlolo> No tabletkeys_para section
<destroyedlolo> no keyN_code
kloczek has joined #linux-sunxi
<destroyedlolo> I can see some tkey section but they are all disabled.
<destroyedlolo> So definitively ... I need your expertise :)
lkcl has joined #linux-sunxi
<thal> The same with 115200
<tuxillo> hi
<tuxillo> !seen tkraiser
<MoeIcenowy> here's no InfoBot ;-)
<MoeIcenowy> and his nick is spelled tkaiser, not tkraiser
fkluknav has joined #linux-sunxi
<tuxillo> ouch :)
<tuxillo> he passed me the other day a link where it stated that in the default debug selector mode, opi 2g iot had to be connect at 921600 bauds
<tuxillo> but I have here a document which specifies how to connect to it with kermit and the config is 115200
<tuxillo> the User manual 0.9.1
<tuxillo> and today they posted an armbian image for it
<KotCzarny> wow, they went for it?
<tuxillo> I can see it in the downloads section but I haven't tried it yet
<tuxillo> I am trying to get the uart thing going
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 252 seconds]
kloczek has quit [Ping timeout: 240 seconds]
kloczek has joined #linux-sunxi
<tuxillo> it seems 921600 is only for android according to the user manual
hp197 has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
kloczek has quit [Ping timeout: 260 seconds]
Gerwin_J has joined #linux-sunxi
uwe__ is now known as uwe_
\\Mr_C\\ has quit [Quit: .]
BenG83 has joined #linux-sunxi
<tuxillo> crap, I only get gargabe :(
OtakuNekoP has quit [Ping timeout: 240 seconds]
dave0x6d has quit [Quit: Connection closed for inactivity]
<destroyedlolo> I'm back with my key handling question.
<destroyedlolo> As per sun4i-keyboard.c, it seems, or key are handled by GPIO, or by LRADC ... but it seems to me we can't use both at the same time.
<destroyedlolo> But as there is nothing in the code disabling LRDAC stuffs ... I wonder if GPIO based keys can be handled ... at all.
<destroyedlolo> Any tip ?
\\Mr_C\\ has joined #linux-sunxi
<jelle> mainline or not?
<destroyedlolo> Legacy one 3.4.x
<MoeIcenowy> we cannot support legacy 3.4.x now...
<destroyedlolo> Ha :(
<destroyedlolo> In this case, there is a good tool to convert FEX to DTB ?
<wens> why are people still using GCC 4.x ...
<plaes> no, not really
popolon has quit [Quit: WeeChat 1.7]
<MoeIcenowy> wens: as some "LTS" distros ship with 4.x
<destroyedlolo> ok, in this case, I will ... try :) Adding an tabletkeys_and see what happened :)
popolon has joined #linux-sunxi
<wens> MoeIcenowy: you can always get newer toolchains from linaro
<MoeIcenowy> yes
<MoeIcenowy> but many people are lazy
<wens> hell, buildroot doesn't even like when you use system toolchains
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
kloczek has joined #linux-sunxi
kloczek has quit [Ping timeout: 240 seconds]
libv_ is now known as libv
kloczek has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
techping has quit [Ping timeout: 260 seconds]
fkluknav is now known as bloodbath
Leepty has quit [Ping timeout: 252 seconds]
Leepty has joined #linux-sunxi
larik has joined #linux-sunxi
<larik> hi, i came across this: http://linux-sunxi.org/Bootable_SPI_flash and was wondering if the spi flash emulation could be used to boot the whole system over spi (bootloader, kernel, filesystem) i.e. some kind of pxe boot via the gpio pins
<larik> could this work theoretically? and if yes what speed could be expected?
<KotCzarny> it would be slow
<larik> how slow?
<KotCzarny> hundreds of kB/s max?
cptG_ has joined #linux-sunxi
<KotCzarny> someone wrote that 500kB takes ~0.5s at 6mhz clock
<Wizzup> larik: what do you mean, emulation?
<Wizzup> What kind of emulation - with a mcu?
komunista has joined #linux-sunxi
<KotCzarny> another thing would be question how spi device is presented in linux, is it block device?
<larik> Wizzup: last part under " the brom implementation details"
cptG has quit [Ping timeout: 240 seconds]
<Wizzup> > Such SPI flash emulation using another board probably does not make much practical sense because it is possible to just connect a real SPI flash chip to the SPI pins.
<Wizzup> Why not just connect a nor flash chip with spl + u-boot + linux + initramfs?
<Wizzup> and then to pxeboot from there
<Wizzup> (or just from u-boot if you prefer)
<larik> 500 kB at 0.5s sound not too bad, i'm thinking mostly about rather small systems of maybe some hundred MB, any possibility yo increase the speed?
<Wizzup> Why would you load everything using some weird spi emulation layer?
<Wizzup> Just load u-boot and use proper networking.
<larik> yeah normal pxe boot would be the alternative, was just wondering if it is possible via spi
<Wizzup> What's the point?
<Wizzup> You can do tcp over spi, but it makes no sense :)
<Wizzup> just put u-boot on the spi flash chip and do whatever you want from u-boot
<Wizzup> it doesn't have to be pxe, you can also boot to a linux with initramfs and wget/scp some image
<larik> the point was mostly not wanting to plug/unplug lan cables :D
<Wizzup> So what is the backing storage for the spi flash
<Wizzup> another lab cable?
<Wizzup> lan*
<buZz> larik: but you -do- want to plug/unplug GPIO cables?
<buZz> why?
<buZz> whats the gain
<Wizzup> buZz: let's just figure out the plan first
<buZz> yeah i'm curious :D
<Wizzup> I don't he ever said he wanted to unplug cables
<Wizzup> don't think*
<buZz> 13:52:19 < larik> the point was mostly not wanting to plug/unplug lan cables :D
<buZz> ^^
<Wizzup> gpio cable == eth cable?
<Wizzup> buZz: we can imagine a 100 scenarios ourselves, but I'm curious what larik wants to achieve exactly
<zoobab> reflashing the SPI flash, but for that it is easy to add a flasher to the SPI flash on the fly
bloodbath is now known as fkluknav
<Wizzup> If the point is just to load new/updated code remotely, then just use u-boot, and load from usb/eth/sata. Most other means seems incredibly silly
<larik> plan was (sort of) boot some sbc router via pxe: but since sbc's mostly have not that much interfaces it would mean to attach lan cable for pxe boot, then unplug it again and plug in the other one for normal routing stuff, having more than one router means just more (un)plugging, me being lazy was thinking about some kind of central solution which does not involve lan cables to load everything which is required to boot up the r
<Wizzup> can't you just use a networks witch, or do I not get the problem?
halex has joined #linux-sunxi
<Wizzup> network switch*
<larik> sure i could, or usb-ethernet adapters etc, the question in the end would be what does cost more, is more complicated etc, but the first problem was to figure out if this "spi-pxe-boot" would work at all
<larik> the other idea was to have the whole filesystem, kernel etc already in the onboard spi chip, but i don't know if there chips of the required size and if it would be faster
<Wizzup> you can easily get 16MB chips
<larik> most stuff should be readonly anyway and the rw stuff should be in ram
<Wizzup> so if you don't use systemd, you can probably fit the entire usable OS in there
<larik> mhh yeah, was also thinking nanobsd or something could fit in there
<MoeIcenowy> ssvb: Will NEON code make more heat than your cpuburn-a7?
The_Loko has joined #linux-sunxi
<Wizzup> larik: usually linux+busybox is an easy way to do it
<Wizzup> alpine minimal rootfs is 1.7MB gzip'd - https://alpinelinux.org/downloads/
<montjoie> wens: gentoo just set gcc5.4 as default this week
dgp has quit [Ping timeout: 240 seconds]
terra854 has joined #linux-sunxi
<beeble> something sitting in my homedir uImage-signed.fit 5.7M. kernel with initramfs based on busybox. configures a network switch and set up routes and stuff
gzamboni has quit [Read error: No route to host]
<beeble> and without any real optimization
<beeble> for size
dgp has joined #linux-sunxi
<ssvb> MoeIcenowy: no, it will not
<ssvb> MoeIcenowy: Cortex-A7 has a slow half-width NEON unit, which does not seem to be able to consume much power
<zoobab> if you have JTAG access, you can also try loading a u-boot in RAM directly without all the other storage chips
<MoeIcenowy> ssvb: then is it possible to heat A7 more than cpuburn-a7?
<beeble> you already have the ability to load code via USB. so jtag would be more effort then to do it via FEL
<larik> zoobab: looks interesting, do you know any other boards which could be booted in this way?
<zoobab> this is for a MIPS board, because it has a dep to a mips32 binary
<zoobab> should be doable for ARM
<Wizzup> Complicated Solutions Inc™ ;-)
<ssvb> MoeIcenowy: cpuburn-a7 does not use NEON (but all the other cpuburn variants do)
<MoeIcenowy> yes
<MoeIcenowy> I saw it
<larik> Wizzup: :P
<ssvb> MoeIcenowy: you can run cpuburn-a8, cpuburn-a9 and cpuburn-krait on Cortex-A7 too
<ssvb> MoeIcenowy: but they just consume less power than cpuburn-a7
<MoeIcenowy> how about if I run a9 and a7 at the same time?
<MoeIcenowy> (oh seems this sentence is wrong
<MoeIcenowy> what will happen if I run a9 and a7 at the same time?
<ssvb> you are surely free to experiment with this :-)
<KotCzarny> if they run on the same core, it might be less heat
<MoeIcenowy> P.S. is it possible that the NEON "optimization" will lead to worse performance on A7?
<ssvb> if you run them at once, then you will get something average between them both
<ssvb> yes, sometimes NEON optimized code may be slower on A7
dave0x6d has joined #linux-sunxi
<ssvb> this is a very painful question of runtime CPU type and CPU features detection
<ssvb> and ARM has been doing a spectacularly bad job in this area
<ssvb> some "genius" decided that access to MIDR should be privileged and can't be accessed from userland
<ssvb> and the kernel developers have been doing a spectacularly bad job too
<dgp> the presence of neon is in the output of /proc/cpuinfo isn't it?
<KotCzarny> dgp, but which neon implementation? ;)
<KotCzarny> though vfp* variants are reported
<dgp> I thought there was one for 32 bit and one for 64 bit
<ssvb> dgp: yes, libjpeg-turbo currently parses /proc/cpuinfo - https://github.com/libjpeg-turbo/libjpeg-turbo/issues/88
<ssvb> but some people think that this is "wrong"
victhor has joined #linux-sunxi
<dgp> Those people are free to provide a better kernel interface to get the same flags
<ssvb> they think that they already provide it
<dgp> Usually people are incredibly vocal about things they think are wrong but less motivated to fix it. If it's 5 or so lines of code to get it out of /proc/cpuinfo then who cares..
<KotCzarny> Theauxv interface proposed by Lennart
<KotCzarny> THAT lennart?
<KotCzarny> then yeah, it's awful ;)
chomwitt has joined #linux-sunxi
<dgp> KotCzarny: Lennart seems to think confusing binary data formats can fix anything
<willmore> ^^^this
<ssvb> well, many years ago I tried to discuss runtime CPU features detection with ARM people
<ssvb> their response was kinda like this (not literally, but implied): "if you don't know how to use -mcpu option to optimize for the processor in your device, then you are an idiot" :)
<dgp> ssvb: They see their chips as being in stuff you flash on the factory floor, chuck it in a box and never touch again
<ssvb> and when I tried to ask why they restrict access to MIDR, they said that evil trojan code could use this information to exploit errata, etc.
<KotCzarny> it assumes one distro image for every possible cpu flags combination
<KotCzarny> hah.
<willmore> KotCzarny, that truely was the mindset.
<dgp> KotCzarny: you're meant to be using a highly customised yocto build you have zero hope of keeping up to date
<KotCzarny> it works that way in embedded world apparently
<ssvb> now fast forward to the present days
<ssvb> they are implementing new sysfs interfaces in the kernel to report the CPU type information, so that JIT engines can workaround CPU errata :)
<wens> /proc/cpuinfo not good enough?
<ssvb> and they also trap MIDR accesses and emulate them in the kernel
<wens> :/
larik has quit [Ping timeout: 260 seconds]
<KotCzarny> why not just emulate cpu in cpu?
<KotCzarny> that way you can software patch your broken hw ;)
<dgp> KotCzarny: or just have upgradable microcode
<willmore> Because that would be horribly efficient, KotCzarny.
<KotCzarny> upgradeable microcode == evil trojans
<KotCzarny> willmore, i think amd was doing it with athlons
<KotCzarny> in a way
<ssvb> wens: /proc/cpuinfo is not good enough for big.LITTLE systems - https://patchwork.kernel.org/patch/9221167/
<ssvb> now the problem is that this sysfs interface is very modern
<KotCzarny> this whole big.LITTLE crap should be banned
<dgp> When is this coming to my 3.14 allwinner bsp kernel?
<ssvb> and we have tons of android running old kernels, and of course we want to do runtime CPU features detection on them too
<KotCzarny> it will end up in more overhead than little cores would add as a gain
<ssvb> dgp: exactly
reev has quit [Ping timeout: 258 seconds]
<KotCzarny> also, arent cpu features presented in cpuinfo per core anyway?
<dgp> ssvb: To be fair though Android 7 is at least using kernels with device tree that are post noah era.. so that crap is more allwinners problem
<willmore> KotCzarny, they are, so I don't see the problem.
<ssvb> and again, there was some "genius" in ARM who has decided that /proc/cpuinfo format should be different on 32-bit and 64-bit ARM
<ssvb> just because they can, right?
lkcl has quit [Ping timeout: 260 seconds]
<willmore> *sigh*
<dgp> ssvb: you shouldn't be parsing that text anyways!
<willmore> This is why we can't have nice things.
<dgp> :p
<ssvb> and now if we run a 32-bit binary on a 64-bit system, some special gymnastics is also involved - https://github.com/ssvb/tinymembench/pull/10
<ssvb> the kernel can present two different versions of /proc/cpuinfo to applications, depending on whether they are 32-bit or 64-bit
<willmore> There's a particularly toasty bit of hell reserved for that fellow.
Leepty has quit [Ping timeout: 240 seconds]
<dgp> They seem to have been trying to fix the mistake of making the output different in the first place. Not sure you can be too hard on them.. unless they made the original mistake
<KotCzarny> the best part is reusing acronyms for different instructions depending on 32 or 64 bit, lol
DullTube has quit [Quit: Leaving]
<willmore> Well, not having a per-cpu features/flags section was stupid from the beginning. It's not like other architectures hadn't already avoided that problem.
<willmore> Heck, if /proc/cpuinfo can handle a massive NUMA system, it can handle your silly big.LITTLE SoC.
<ssvb> well, Intel has a nice CPUID instruction and it just works
<ssvb> ARM decided to do all of this in a very roundabout way
<KotCzarny> does intel have any heterogenous core cpus?
<ssvb> it does not matter, if you disable preemption or set cpu affinity first, then you can easily get the features of the current CPU core using the CPUID instruction
<ssvb> on ARM the solution with trapping and emulating access to MIDR is not very nice - http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html
<dgp> Are you saying the intel do some stuff better than ARM? surely that's some sort of hatespeech
<dgp> s/the/that/
<ssvb> yes, I think that this kind of stuff is definitely better on x86
<ssvb> how is it a hatespeech?
<willmore> KotCzarny, Hyperthreading.
<KotCzarny> ssvb: i think he is a bit ironic
<dgp> ssvb: People seem to have a huge fanboy crush for ARM. Saying intel do anything better even if it is a register with some flags probably hurts their feelings
<willmore> bummer for them, then. reality >> fanboy buthurt
<ssvb> the only rational reason that I can come up with is that maybe ARM was afraid that the CPUID instruction or the whole concept of runtime CPU features detection was patented?
<willmore> ssvb, I would think that's likely
lkcl has joined #linux-sunxi
Leepty has joined #linux-sunxi
<dgp> Intel seem to have a ton of similar patents :/
afaerber has quit [Quit: Leaving]
<ssvb> yes, this shit is very scary
<destroyedlolo> Hello,
<destroyedlolo> I decided to move my BananaPIs to the mainline kernel (from legacy 3.4.103).
<destroyedlolo> I read on your web site, the mainline Uboot is able to boot both the legacy one and the new one, is it true ?
thal has left #linux-sunxi [#linux-sunxi]
<MoeIcenowy> yes
afaerber has joined #linux-sunxi
<destroyedlolo> So, can I first upgrade uboot and then build a kernel using normal Gentoo installation procedure ?
<destroyedlolo> I mean, everything is already present in main kernel repo for the BananaPI or do I have to use Sunxi own repo ?
menomc is now known as mnemoc
vbmithr_ has quit [Read error: Connection reset by peer]
gzamboni has joined #linux-sunxi
<ssvb> destroyedlolo: you don't need to exactly follow the Gentoo installation procedure
JohnDoe_71Rus has joined #linux-sunxi
<ssvb> first you get U-Boot and kernel and when they work, then just unpack the gentoo stage3 tarball
<ssvb> actually which installation procedure are you trying to use? have a link?
fkluknav has quit [Ping timeout: 268 seconds]
<destroyedlolo> My Banana are already running Gentoo, but with legacy 3.x kernel.
cnxsoft has quit [Quit: cnxsoft]
<destroyedlolo> I must first update manually uboot but after, I would like to use the normal Gentoo ways, that is to install Gentoo-source (which is in fact the Linus' kernel) and then make my kernel follow Gentoo's update.
<destroyedlolo> But I duno if Linus' kernel is enough or if I need to keep the one from SunXI.
<montjoie> I have just created two branch sun8i-emac-v5.1 (yes the old) and dwmac-sun8i-v5
<mripard> montjoie: you should kill it once for good some time :)
<montjoie> mripard: inserted backdoor in it
<mripard> montjoie: nice move :)
<mripard> but you should not disclose it publicly ;)
<wens> funny, hdmi on my a31 doesn't do vblank the first time
<wens> but subsequent calls using modetest seem to work :/
lemonzest has joined #linux-sunxi
aballier has quit [Ping timeout: 240 seconds]
<MoeIcenowy> montjoie: what the hell
<KotCzarny> MoeIcenowy: well, he has to test his ideas on both apparently
<MoeIcenowy> wens: is the vblank very slow?
<montjoie> MoeIcenowy: ?
<MoeIcenowy> I don't want you to add backdoor into emac branch
<MoeIcenowy> as emac branch is in fact more useful
<MoeIcenowy> until the first LTS after dwmac-sun8i is merged releases
<montjoie> ah ah ah a horrible one, it install systemd which run win95 IOT
aballier has joined #linux-sunxi
<KotCzarny> o.O
<KotCzarny> now that's getting scary
<montjoie> systemd or win95 IOT? still dont know which one scare me the most
<mripard> MoeIcenowy: just backport dwmac-sun8i and that's it
<MoeIcenowy> mripard: backporting dwmac-sun8i means backporting nearly all dwmac
<mripard> MoeIcenowy: well, this is what you have to endure when you don't want to upgrade your kernel.
reinforce has quit [Quit: Leaving.]
perr has quit [Quit: Leaving]
jernej has joined #linux-sunxi
ibu[m] has quit [K-Lined]
mic-e[m] has quit [K-Lined]
raknaz[m] has quit [K-Lined]
vagrantc has joined #linux-sunxi
mic-e[m] has joined #linux-sunxi
raknaz[m] has joined #linux-sunxi
ibu[m] has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
<plaes> mripard: o/
<plaes> I don't see any clk rate setting calls in the ahci_sunxi driver
mozzwald has quit [Ping timeout: 258 seconds]
vagrantc has joined #linux-sunxi
<montjoie> mripard: any idea for my clk build error ?
mozzwald has joined #linux-sunxi
<wens> plaes: there aren't any
<wens> plaes: it only does enable/disable
<plaes> I disabled sata in u-boot and then sata setup fails
<plaes> ...in Linux
<MoeIcenowy> plaes: even with old clock driver?
<plaes> hmm.. good catch :)
<plaes> didn't test that
<plaes> I'll try it out
nOOb__ has joined #linux-sunxi
LargePrime has quit [Ping timeout: 260 seconds]
<montjoie> mripard: I just found the CCU problem, when no CCU driver is select ccu_common is still compiled and need ccu_gate
<montjoie> I will send a patch
reinforce has joined #linux-sunxi
<plaes> MoeIcenowy: yeah, works with old clocks
matthias_bgg has quit [Quit: Leaving]
<plaes> hrm.. I don't understand it at all...
<wens> montjoie: yeah, i had meant to send a patch for it, hadn't gotten around to it yet
<wens> it was introduced in 02ae2bc6febd clk: sunxi-ng: Add clk notifier to gate then ungate PLL clocks
<wens> maybe i should've put that in ccu_gate instead of ccu_common
jernej has quit [Ping timeout: 268 seconds]
<montjoie> wens: patch ready:)
dev1990 has joined #linux-sunxi
<destroyedlolo> Hum, I created an SD with mainline u-boot with my previous 3.4.103 kernel (that worked) but it fails with following error
<destroyedlolo> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
<destroyedlolo> Error: unrecognized/unsupported machine ID (r1 = 0x100010bb).
mozzwald has quit [Ping timeout: 264 seconds]
mozzwald has joined #linux-sunxi
<destroyedlolo> I did a make Bananapi_defconfig
<destroyedlolo> so ... why ?
<plaes> destroyedlolo: there's solution for you in the wiki
<destroyedlolo> Well, I followed it (I hope :) )
<destroyedlolo> Get u-boot
<destroyedlolo> make Bananapi_defconfig
<destroyedlolo> make
<destroyedlolo> install the spl in the SD card.
<plaes> and which page did you follow?
<plaes> there's troubleshooting section
<destroyedlolo> The only difference is I natively compile uboot on my Banana and not cross compiling.
souther has quit [Ping timeout: 258 seconds]
souther has joined #linux-sunxi
<destroyedlolo> Arg, yes, I missed it :( I thought it was in the kernel, not in uboot.
<destroyedlolo> Recompiling ...
kloczek has quit [Ping timeout: 255 seconds]
Andy-D_ has joined #linux-sunxi
yann|work has quit [Ping timeout: 260 seconds]
souther has quit [Ping timeout: 255 seconds]
kloczek has joined #linux-sunxi
souther has joined #linux-sunxi
popolon has quit [Ping timeout: 260 seconds]
popolon has joined #linux-sunxi
kloczek has quit [Ping timeout: 245 seconds]
souther has quit [Remote host closed the connection]
deskwizard_ has quit [Quit: disapeared.]
souther has joined #linux-sunxi
lkcl has quit [Ping timeout: 258 seconds]
Mr__Anderson has quit [Remote host closed the connection]
medvid has quit [Quit: !]
popolon has quit [Quit: WeeChat 1.7]
itdaniher has joined #linux-sunxi
<itdaniher> just got my pinebook
<itdaniher> minus the requested trimmings, but it's a pretty sweet looking piece of hardware nevertheless
<itdaniher> going to try Armbian_5.27.170426_Pine64_Ubuntu_xenial_dev_4.10.0.7z and see if it boots off SD
lkcl has joined #linux-sunxi
destroyedlolo has quit [Quit: Leaving]
medvid has joined #linux-sunxi
BluRaf is now known as BluRaf_
BluRaf_ is now known as BluRaf
lennyraposo has quit [Quit: Leaving.]
kloczek has joined #linux-sunxi
kloczek has quit [Read error: Connection reset by peer]
|Jeroen| has joined #linux-sunxi
kloczek has joined #linux-sunxi
kloczek has quit [Read error: Connection reset by peer]
kloczek has joined #linux-sunxi
kloczek has quit [Remote host closed the connection]
kloczek has joined #linux-sunxi
kloczek has quit [Read error: Connection reset by peer]
kloczek has joined #linux-sunxi
pmpp_ has joined #linux-sunxi
pmpp has quit [Ping timeout: 240 seconds]
yann|work has joined #linux-sunxi
jernej has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
kloczek has quit [Quit: kloczek]
netlynx has quit [Quit: Ex-Chat]
quard has joined #linux-sunxi
marble_visions has joined #linux-sunxi
<marble_visions> hi all, does anyone know what's the issue with having the DTS files for olimex boards in the linux-sunxi legacy kernel?
<jelle> marble_visions: don't really understand the question, what do you want to do?
<marble_visions> jelle: nothing in particular, it's just that mainline uses dts for all boards, but sunxi legacy has some boards using dts, some not
<marble_visions> and the olimex boards are still using fex files
<jelle> the majority of the people only work with mainline here
<marble_visions> oh, ok.
<beeble> but to answer you question anyways. fex was/is a allwinner invention and was never used by someone else. so the sunxi legacy tree is based on the allwinner sources that uses that fex files. in the meantime allwinner switched also to devicetree for newer kernel versions
<marble_visions> beeble: thanks. i'm reading that mali support is still in legacy only. is that true? are there any reasons to stick with legacy? i'm seeing nextthingco/chip integrating a mali stack for their distro.. maybe the sunxi wiki is outdated?
<plaes> marble_visions: graphics stack isn't currently 100% working yet
<plaes> well, except with A13
<plaes> but it is possible to get mali working
<marble_visions> plaes: ooh, do tell. where can I read up about the state of affairs? yep, A13 is a hot concern with me
<marble_visions> (state of affairs of the graphics stack)
<plaes> don't really know where to read about it
<MoeIcenowy> in fact I have Mali running on A33 mainline after some patches are applied
<plaes> yeah, and there's at least one person with A20
<marble_visions> nice.. i'll be trying to do that soon with an a13
kloczek has joined #linux-sunxi
Wizzup has quit [Remote host closed the connection]
Wizzup has joined #linux-sunxi
Wizzup has quit [Remote host closed the connection]
<marble_visions> jelle: beeble: plaes: MoeIcenowy: gtg, thanks for the info!
Wizzup has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
<MoeIcenowy> without it your sunxi-mali driver cannot run at all
<MoeIcenowy> but it seems a bit ugly
miasma_ is now known as miasma
<willmore> montjoie, April first was a long time ago. :)
phil42 has quit [Remote host closed the connection]
bonbons has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
terra854 has quit [Quit: Connection closed for inactivity]
cptG_ has quit [Ping timeout: 240 seconds]
Mr__Anderson has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 240 seconds]
|Jeroen| has quit [Quit: dada]
Gerwin_J has quit [Quit: Gerwin_J]
quard has quit [Quit: Leaving]
afaerber has quit [Quit: Leaving]
reinforce has quit [Quit: Leaving.]
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
lurchi_ is now known as lurchi__
mzki has quit [Ping timeout: 240 seconds]
f0xx has quit [Ping timeout: 240 seconds]
lurchi__ has quit [Ping timeout: 240 seconds]
mzki has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
f0xx has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
cptG has joined #linux-sunxi
jstein has joined #linux-sunxi
f0xx has quit [Read error: Connection reset by peer]
f0xx has joined #linux-sunxi
The_Loko has quit [Quit: Leaving]
f0xx has quit [Ping timeout: 260 seconds]
_filt3r_ is now known as filt3r
komunista has quit [Quit: Leaving.]
cptG has quit [Ping timeout: 240 seconds]
jernej has quit [Ping timeout: 246 seconds]
paulk-collins has quit [Quit: Leaving]
tgaz has quit [Ping timeout: 255 seconds]
tgaz has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
perr has joined #linux-sunxi
perr has joined #linux-sunxi
perr has quit [Changing host]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
tgaz has quit [Ping timeout: 268 seconds]
tgaz has joined #linux-sunxi
cptG has joined #linux-sunxi
vagrantc has joined #linux-sunxi
atsampson has quit [Ping timeout: 255 seconds]
atsampson has joined #linux-sunxi
medvid has quit [Ping timeout: 255 seconds]
jstein has quit [Remote host closed the connection]
medvid has joined #linux-sunxi
nOOb__ has quit [Ping timeout: 246 seconds]