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
iamfrankenstein has quit [Ping timeout: 276 seconds]
iamfrankenstein has joined #linux-sunxi
pitelpan has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
kaspter has joined #linux-sunxi
lennyraposo has quit [Ping timeout: 276 seconds]
jernej has quit [Ping timeout: 272 seconds]
<MoeIcenowy> GeneralStupid: yes
<MoeIcenowy> while building the kernel
<MoeIcenowy> dtb is generated
ganbold has quit [Ping timeout: 264 seconds]
kaspter has quit [Ping timeout: 240 seconds]
ganbold has joined #linux-sunxi
mosterta has quit [Ping timeout: 250 seconds]
Zliba has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-sunxi
Zliba has quit [Ping timeout: 272 seconds]
<wens> looks like bpi r1 is now worth getting
<MoeIcenowy> bbrezillon: it seems that sun8iw5 nand driver doesn't use ahb clock...
<MoeIcenowy> I cannot find code to set ahb in the official driver
<wens> do you mean the ahb clock gate?
<wens> the allwinner clk code manages mod clocks together with the ahb gates
<wens> (and resets)
<jrg> orange pi "gbit" lan goes like 10-15MB/s over cifs heh
<MoeIcenowy> wens: oh
<jrg> talk about a letdown
<wens> jrg: mainline?
<wens> maybe someone could benchmark the 3.4 kernel
<jrg> Linux opi 3.4.112-sun8i #10 SMP PREEMPT Wed Jun 1 19:43:08 CEST 2016 armv7l GNU/Linux
<jrg> yah it doesn't seem to get anywhere near gbit speed for me.. although. i am r/w from the same source
<jrg> so it's pretty much cp a file from the same cifs share to another dir on the same share
<jrg> too bad cp doesn't support server side copy :/
<jrg> but yeah. at best i'm getting 15MB/s
<MoeIcenowy> now i tried to enable nand on sun8iw5
<MoeIcenowy> but get sunxi_nand 1c03000.nand: wait interrupt timedout
<MoeIcenowy> interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; in the sun8i-a23-a33.dtsi
<MoeIcenowy> according to #define SUNXI_IRQ_NAND (SUNXI_GIC_START + 70) /* 102 */ in lichee
<MoeIcenowy> @bbrezillon
<wens> seems right
<wens> did you check clocks and resets?
<MoeIcenowy> clocks are ahb_gates 1 and nand_clk
<MoeIcenowy> nand_clk is copied from sun7i, but removed <&pll5 0>
<MoeIcenowy> s/1/13/
<wens> what about resets?
<MoeIcenowy> no resets is set
<wens> a23 has separate reset lines, so you have to add them
<wens> (unless the controller doesn't have one)
<wens> right, the driver doesn't support it yet
p1u3sch1 has quit [Ping timeout: 250 seconds]
p1u3sch1 has joined #linux-sunxi
<MoeIcenowy> wens: however the register map is similar
<wens> i meant the driver doesn't support reset lines
<MoeIcenowy> it seems that the driver in 4.7-rc3 used a lot of polls instead of interrupts...
<MoeIcenowy> I'll now bump to 4.7-rc3
<wens> MoeIcenowy: you still need to add reset control support to the driver if you want to use it on A23/A33
<wens> the hardware is held in reset by default, so you need to deassert the reset control
reev has joined #linux-sunxi
reev has quit [Ping timeout: 272 seconds]
IgorPec has joined #linux-sunxi
jernej has joined #linux-sunxi
reev has joined #linux-sunxi
zhouer has joined #linux-sunxi
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
merbanan has quit [Ping timeout: 250 seconds]
<MoeIcenowy> wens: which reset line?
zuikis has joined #linux-sunxi
reinforce has joined #linux-sunxi
merbanan has joined #linux-sunxi
lemonzest has joined #linux-sunxi
IgorPec has quit [Ping timeout: 264 seconds]
<wens> MoeIcenowy: in sun8i-a23-a33.dtsi, you'd see all the other peripherals have resets = <...>;
<wens> that is the reset line
zuikis has left #linux-sunxi [#linux-sunxi]
IgorPec7 has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
apritzel has joined #linux-sunxi
solarnetone has quit [Remote host closed the connection]
solarnetone has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
<KotCzarny> wens: bpi r1? you mean lamobo r1?
iamfrankenstein has quit [Ping timeout: 260 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<wens> KotCzarny: yeah
<KotCzarny> jrg: did you try interrupts cpu offload trick?
<KotCzarny> wens: i have one, can you elaborate?
<wens> KotCzarny: the driver for the switch IC has been merged
<KotCzarny> ahm, cool, did you do some tests already?
<wens> and there is a patch "ARM: dts: sun7i: Add BCM53125 Device Tree nodes" on lakml
<wens> i don't have the board
<KotCzarny> i'm away from home, i wonder if i can get tkaiser to benchmark it, hehe
IgorPec8 has joined #linux-sunxi
<KotCzarny> hi igor
<KotCzarny> do you have lamobo r1?
IgorPec7 has quit [Ping timeout: 250 seconds]
IgorPec9 has joined #linux-sunxi
jernej has quit [Ping timeout: 260 seconds]
IgorPec8 has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
dearfibonacci has joined #linux-sunxi
massi has joined #linux-sunxi
<tkaiser> wens: SinoVoip confirmed schematic being wrong: BPi M2+ VDD_CPUX is 1.3V
IgorPec9 has quit [Ping timeout: 260 seconds]
<tkaiser> http://forum.banana-pi.org/t/detailed-powering-schematic/1831/13 (what puzzles me: they use exactly the same SY8113B as one OPi One/Lite but refrain from switching voltage through GPIO)
IgorPec has joined #linux-sunxi
igraltist has quit [Remote host closed the connection]
igraltist has joined #linux-sunxi
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<wens> tkaiser: got it
<MoeIcenowy> wens: how can I know which reset line should be in nfc dt node?
<wens> MoeIcenowy: look up the index in the user manual, it's part of the CCU
<wens> clock control module/unit
<MoeIcenowy> wens: do you mean BUS_SOFT_RST_REG0
<MoeIcenowy> its bit13 is said to be NAND_RST
<GeneralStupid> MoeIcenowy: armbian dosnt have such file -.-
apritzel has quit [Ping timeout: 244 seconds]
<wens> MoeIcenowy: yes
<MoeIcenowy> GeneralStupid: build your own mainline kernel.
popolon has joined #linux-sunxi
<GeneralStupid> MoeIcenowy: short answer: no.
<GeneralStupid> is it possible to debug my boot.cmd? i have two gpio set commads in front of it, they work (for "debugging") but thats it...
libv_ is now known as libv
<GeneralStupid> is it possible to start my uboot with qemu?
<TheLinuxBug> wow what a piece of grabage the Android release for OrangePi Plus 2E is, there is no way to functionally root it because they us some special kernel security making it so you can't ever remount the /system volume and even if you do get OTG installed and used adb which you can get root, all system volumes are mounted nosuid so chmoding 4755 su does nothing at al. Then too boot they have it so broke there is no way to install GAPPS. *sigh*
<TheLinuxBug> why do these groups release such garbage
<TheLinuxBug> can't run any real licensed apps on it, only hacked versions from non standard app stores
<TheLinuxBug> means every app has ads
<TheLinuxBug> just total junk.
<TheLinuxBug> /rant
Mr__Anderson has joined #linux-sunxi
<dearfibonacci> hello. trying to setup sunxi-kernel / sunxi-uboot on a device (ye older versions because of graphics) here's the uart log of what can I see.the script bin is in the /boot dir with the zImage and boot.scr http://pastebin.com/raw/tzB7kbH2
<KotCzarny> �TheLinuxBug:have you tried to build whole thing from source?
<GeneralStupid> dearfibonacci: is boot on your ext4 partition?
<GeneralStupid> dearfibonacci: and paste boot.cmd too, plt
<GeneralStupid> plz
<tkaiser> KotCzarny: Still kidding? https://github.com/orangepi-xunlong/orangepi_android
<KotCzarny> tkaiser, yeah ;)
<KotCzarny> tkaiser: care to forward info to igor about lamobo r1 switch driver getting to mainline?
<KotCzarny> his betwork connectivity seems to be bad
<tkaiser> KotCzarny: Nope, we're busy doing serious stuff, no time to deal with crapboard R1
apritzel has joined #linux-sunxi
<KotCzarny> hehe
Mr__Anderson has quit [Remote host closed the connection]
<dearfibonacci> GeneralStupid: boot.cmd paste: http://pastebin.com/raw/sxMpyHWL
<dearfibonacci> GeneralStupid: ye on the ext4 (working with buildroot, so only one partition..no vfat small boot partition)
apritzel1 has joined #linux-sunxi
<GeneralStupid> ok
<dearfibonacci> GeneralStupid: another build in progress trying with uImage as it seems to be missing instead of zImage
<GeneralStupid> dearfibonacci: you can use || to try both -.-
<GeneralStupid> like a fallback
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
ricardocrudo has joined #linux-sunxi
<MoeIcenowy> wens: I built 4.7-rc3 for my tablet
<MoeIcenowy> in booting dmesg
<MoeIcenowy> "sun8i-a23-r-pinctrl 1f02c00.pinctrl: Reset controller missing" and "sun6i-dma 1c02000.dma-controller: No reset controller specified"
<MoeIcenowy> is it normal?
apritzel has quit [Ping timeout: 244 seconds]
<oliv3r> ssvb: i hope that it's expected that sun50i u-boot does not yet compile?
<ssvb> oliv3r: what do you mean?
<wens> MoeIcenowy: it's probably normal, since the reset controller is probed after dma
<ssvb> oliv3r: there is no SPL support for sun50i but it should compile (I haven't tested it lately though)
<wens> MoeIcenowy: and the r-pinctrl block does not have reset either
<apritzel1> oliv3r: works for me on v2016.07-rc1
<apritzel1> oliv3r: do you have an aarch64 cross compiler setup? CROSS_COMPILE=aarch64-linux-gnu-
<ssvb> oliv3r: just checked it, seems to build fine
<oliv3r> ssvb: bah :p
<oliv3r> ssvb: i'm using the pine64 defconfig and i get
<oliv3r> ssvb: ohh wait, i probably need a different compiler :)
<MoeIcenowy> wens: thx
<MoeIcenowy> I'm now trying to make full otg work on 4.7...
<ssvb> oliv3r: pine64 uses a 64-bit processor and needs a 64-bit toolchain to build U-Boot :)
<ssvb> oliv3r: have you just received a pine64 board yourself?
<oliv3r> ssvb: nah, doing compiletests atm only :(
<oliv3r> to ensure i didn't break anything :)
<oliv3r> ssvb: more importantly, i just booted a baord from eMMC and dumping memory :)
[7] has quit [Ping timeout: 258 seconds]
<oliv3r> ssvb: and it looks like there is more data injected into the sram then just the bootmedia, or am I miss-reading something here : http://sprunge.us/MeTJ
TheSeven has joined #linux-sunxi
<oliv3r> ssvb: or does u-boot corrupt things?
<ssvb> oliv3r: what is in the first 0x40 bytes of your SPL file for comparison?
<oliv3r> let me find that
<oliv3r> hmm it actually contains the same junk; i wonder why
<oliv3r> ssvb: http://sprunge.us/OHZB
<oliv3r> old version of course
<oliv3r> let me reflash my bootloader with a fresh copy :)
<ssvb> oliv3r: looks like you don't have the http://git.denx.de/?p=u-boot.git;a=commit;h=b19236fd1c1ef289bab9e243ee5b50d658fcac3f fix yet and your SPL header size is 32 bytes
<oliv3r> ssvb: exactly, old u-boot
<oliv3r> makes sense as the bootloader was on this board for quite some time :)
<oliv3r> the problem is now though, the nand bootloader i have doesn't have the fix either, so i'd have to a) figure out how I built the bootloader back then, patch it to 64 bytes (easy) and then flash it again
<ssvb> that's why you are getting the byte at 0x28 changed from 0x14 to 0x02 (overwriting the U-Boot's reset vector code)
<oliv3r> i've read up on your patches :) just didn't correlate it this early in the morning :)
kaspter has joined #linux-sunxi
<ssvb> you can still use your old nand bootloader, this kind of corruption is not life threatening for U-Boot (otherwise somebody would have noticed it much earlier) :)
<GeneralStupid> whats the fallback if boot.scr isnt working?
<oliv3r> ssvb: yeah but i want to dump offset 0x28
<ssvb> you still can do this
<oliv3r> with the corruption going on?
<ssvb> yes
<oliv3r> ah okay :)
<oliv3r> let me first get my emmc board working with the md stuff
<oliv3r> as it was not compiled in for some reason
<ssvb> because you had exactly the same with your eMMC test
<jelle> ssvb: btw, pushed a refactored u-boot to my h3-hdmi branch
<jelle> HPD still works, EDID is still a mystery
<ssvb> oliv3r: and your eMMC test already showed the 0x02 code at the offset 0x28 :)
<oliv3r> ah you looked further then i did :)
<oliv3r> ok then i'll check the nand loader in a min
<oliv3r> ah there it is indeed
<oliv3r> i'll double check the nand, then send you a quick patch
<ssvb> send it to the U-Boot mailing list and add me to CC
<ssvb> jelle: thanks!
<oliv3r> ssvb: of course
<mripard> jelle: you know that you can't look at the current Allwinner kernel code to implement it in U-boot, right?
<oliv3r> mripard: the latest aw kernel is not gpl-ed?
<jelle> mripard: uhh no?
<jelle> mripard: if that's the case, it's impossible to create a u-boot hdmi driver
<oliv3r> heh, so they are in gpl violation and we can't use their stuff
<oliv3r> jelle: clean-room RE
<oliv3r> jelle: someone writes the specs (register info etc on the wiki) you implement it based on that spec
<ssvb> mripard: Allwinner has to eventually resolve this issue, because they have no right to use this code inside of the Allwinner kernel code themselves
<oliv3r> jelle: since technically you have been poisoned by the current implementation, you can technically only write the docs, and someone clean can implement it
<oliv3r> but as ssvb says, they are in violation of the gpl so in the end their code must turn into gpl or removed
<ssvb> mripard: AFAIK this is being resolved now, with the Pine64 people doing all the pushing of Allwinner in the right direction :)
RzR has left #linux-sunxi ["Leaving"]
<jelle> damn this is an annoying situation
<jelle> it's also the first time I'm attempting to implement something so big
<ssvb> jelle: yes, but after Allwinner releases the fixed kernel source code, you would be able to contribute this code to U-Boot
IgorPec has quit [Ping timeout: 240 seconds]
<wens> legal stuff is always annoying :/
<jelle> otherwise I'll be able to contribute some docs
caog has joined #linux-sunxi
<ssvb> jelle: yes, you can document all your findings in the wiki
<jelle> does anyone know if the controller is really the same as the one mentioned used in imx.6
<wens> didn't someone figure out the controller is designware with some obscuring on the data lines?
<jelle> AW also still has to publish the h3 u-boot right?
<jelle> or is that only on github?
<oliv3r> jelle: that's sorta publishing it isn't it?
<mripard> oliv3r: the HDMI part has "All rights reserved. Allwinner"
<mripard> so not GPL
<jelle> wens: I've found something in here http://moinejf.free.fr/opi2/
<mripard> they're definitely not in their right
<mripard> but still.
<oliv3r> yeah
<jelle> wens: yeah de2_hdmi_h3.c says it * Synopsys DesignWare HDMI controller
<jelle> but further down it says: //fixme: strange values / IMx.6 doc
<oliv3r> ssvb: just to confirm: http://sprunge.us/WPbS
<ssvb> oliv3r: is this from eMMC?
<oliv3r> aye
<oliv3r> with updated u-boot
<jelle> guess there are no docs for the designware controller
<ssvb> oliv3r: ok, now it looks like it should be
<jelle> oh now I see it seems to be in the imx but not sure if it's the same http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt?v=3.15
<oliv3r> in the future, when i'm working on some asm on the BROM, i'll see if i can find the code responsible in the a10 brom
<oliv3r> ssvb: i missed your comment, but quite likly yes :)
<oliv3r> i did grep for #40 though and came up empty
<oliv3r> ssvb: ah let me read the rest of your dump :)
<oliv3r> ssvb: i guess it won't hurt to do a new dump of the BROM and see if there are changes, and hopefully a version identifier
<oliv3r> to bad hno doesn't idle here anymore, as he extracted the initial BROM
Worf has joined #linux-sunxi
<ssvb> oliv3r: this stuff is also a gray area, the boot ROM code is definitely copyrighted and we need to be careful when dealing with it
<oliv3r> ssvb: BUT the BROM is in GPL violation :)
<ssvb> oliv3r: is it?
<oliv3r> ssvb: they incorperated GPL code into the BROM
<oliv3r> yeah
<oliv3r> and hence the BROM is poisoned
afaerber_ has joined #linux-sunxi
<oliv3r> anyway, we can't change the BROM anyway, so it's merly a documentation excersize, 'cleanrooming' it so to speak, write down what happens and leave it a tthat
<oliv3r> but yeah, i agree, very gray it is
<ssvb> we are not trying to reimplement the BROM, so we are reasonably safe
<oliv3r> ssvb: i'm looking at your dump and incidentally, ffff521c is pretty much where load_from_mmc just returns to the main loop
<ssvb> all this is done merely for interoperability, which is perfectly legal unless I'm mistaken
<oliv3r> ssvb: so the A10 brom might not do this as you say
<oliv3r> ssvb: ianal :p
<ssvb> if you check the irc logs, I mentioned earlier that the BROM probably had more than one revision in A10
<ssvb> all my A10 devices do support this boot media identifier at the 0x28 offset in the SPL header
<oliv3r> ssvb: i wonder what A10 hno then had
<ssvb> it would be very interesting to find somebody with an ancient A10 to do some tests on it
<oliv3r> would be nice if we could identify some version field in the brom header of sorts
<oliv3r> i might have an early cubieboard or olimex board
<oliv3r> with the SID set to 000000
<oliv3r> so it might be one of those very early boards
<MoeIcenowy> I'm trying to get 4.7-rc3 kernel with a33 full otg
<MoeIcenowy> I backported some patches from jwrdegoede/linux-sunxi sunxi-wip
<oliv3r> ssvb: can we get this info from /dev/mem from linux or is it u-boot only?
<ssvb> oliv3r: the A10 DRAM controller initialization code already has to deal with the reversed reset bit, depending on the A10 revision
<jelle> MoeIcenowy: it worked on my a33 tablet btw
<ssvb> oliv3r: http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-sunxi/dram_sun4i.c;h=f7b4915037cd3eec58d7b45cff636133945d28f8;hb=HEAD#l72
<MoeIcenowy> these patches can make full otg work well on 4.6
<jelle> MoeIcenowy: also I saw a silead dts bindings in hans his branch
<oliv3r> ssvb: ah that's right
<MoeIcenowy> but on 4.7 it cannot work
<MoeIcenowy> [ 16.349324] sun4i-usb-phy 1c19400.phy: Err requesting vbus-det-irq: -22
<oliv3r> ssvb: so that bit can be used to decide wether we can rely on the bit (on old boards)
<MoeIcenowy> but i think a33 should use vbus-power-supply rather than vbus-det-gpio
<ssvb> oliv3r: we can also fill the data at the 0x28 offset in the SPL header with some special pattern instead of 0
<ssvb> oliv3r: and of the BROM does not support the boot device type reporting feature, then this magic value will remain at the offset 0x28 and the SPL will know that we can't rely on it
<GeneralStupid> actually it looks like uboot ignores my scr file
<KotCzarny> old uboot, bad uboot
<GeneralStupid> is there a way to write uboot debug informations to fat ?
<ssvb> oliv3r: it still would be very interesting to find an ancient A10 and run tests on it
<GeneralStupid> KotCzarny: its the uboot from armbian, i guess it should work for me :D
<GeneralStupid> KotCzarny: it supports bootz, so what do i need more?
<KotCzarny> GeneralStupid: do you use serial console as debug?
<oliv3r> ssvb: yeah i'll check my parts drawer at home :)
<oliv3r> btw, i'll hold the patch back for now until i can check a nand board that i can access the sram from
<KotCzarny> GeneralStupid: compiling uboot is quick and easy, just try it?
<MoeIcenowy> jelle: will jwrdegoede appear here?
<GeneralStupid> KotCzarny: no ... my serial console adapter is 300 km away... i would like to fix it without if possible
<jelle> MoeIcenowy: you mean on irc?
<oliv3r> ssvb: btw, to answer your SPI question :p
<MoeIcenowy> jelle: yes
<oliv3r> i talked to olimex at the time, to see if we could get a board with easy access to the pins
<KotCzarny> GeneralStupid: which soc it is? h3 or a20?
<GeneralStupid> h3
<oliv3r> ssvb: i figured we should be able to solder a SPI flash to a lime board without nand, but then time ran out
<jelle> MoeIcenowy: nick would be hansg, but I don't seen him often on irc
<jelle> MoeIcenowy: better to just mail him I guess
<KotCzarny> GeneralStupid: then it should work, did you compile your boot.scr after editing?
reinforce has joined #linux-sunxi
<oliv3r> ssvb: i started to document the BROM just to see which spi ports would be checked etc
<KotCzarny> mkimage -C none -A arm -T script -d boot.cmd boot.scr etc
<GeneralStupid> KotCzarny: yes -.-
<GeneralStupid> compile my boot.scr ? Wait what :D
<oliv3r> ssvb: but as I said, i ran out of time to explore this further. i did get really excited to hear about your progress though :)
<GeneralStupid> i thought i have to mkimage my boot.cmd to boot.scr -.-
<GeneralStupid> thats not everything?
<KotCzarny> yeah
<ssvb> oliv3r: it would be great if Olimex could make an A20-OLinuXino-LIME2-SPI variant of the board :)
<oliv3r> well the problem with SPI flash is that it usually is very small (or expensive)
afaerber_ is now known as afaerber
<oliv3r> ssvb: how are you conducting your SPI experiments and how far are you? full boot right?
<KotCzarny> GeneralStupid: im using it on my oranges without the problem, what exactly is not working for you?
<GeneralStupid> KotCzarny: its not booting zImage
<KotCzarny> then probably its some kernel problem
<oliv3r> ah nice one :)
<GeneralStupid> KotCzarny: he is falling back to the old "loboris" uImage
<oliv3r> ssvb: they exposed the NAND SPI0 pins?
<KotCzarny> GeneralStupid: paste your boot.cmd
<oliv3r> or does it work with any spi0 bus?
enrico_ has joined #linux-sunxi
<GeneralStupid> KotCzarny: its exactly the kernel i used with armbian without problems. modules are there too, and i guess if its a kernel problem i should get display messages
<oliv3r> ssvb: ah the board probably doesn't have nand :)
<ssvb> oliv3r: yes, they have no NAND and expose the PC0-PC3 pins on the expansion header
<oliv3r> nice :)
<oliv3r> but you can fully boot allready, right?
<KotCzarny> GeneralStupid: quick idea, do you have more than 1 sbc?
<GeneralStupid> KotCzarny: http://paste.debian.net/738577/
<GeneralStupid> KotCzarny: sbc?
<KotCzarny> single board computer :P
<GeneralStupid> KotCzarny: yes
<KotCzarny> essentialyy sunxi/anything board
<KotCzarny> then you can use it as a serial on the other end :P
<KotCzarny> just connect tx--rx rx--tx gnd--gnd :P
<GeneralStupid> they are in use -.-
<KotCzarny> are they physically available/handy ?
<ssvb> oliv3r: yes, we can boot from SPI after https://patchwork.ozlabs.org/patch/631501 is applied
<KotCzarny> just connect 3 wires and you have serial console
<oliv3r> ssvb: awesome
<MoeIcenowy> jelle, wens: If I want to contribute a dts file, can it have some stub code for some devices without mainlined driver?
<oliv3r> oh wow that's like 5 days ago :)
<MoeIcenowy> for example, I enable mmc1 for a wifi card not mainlined
<GeneralStupid> KotCzarny: impossible now. Maybe in the evening -.- Did you see something very wrong on that file?
<MoeIcenowy> (but it have a driver that can be compiled and running on mainline
<KotCzarny> is there such thing as mmc 0:0 ?
<oliv3r> in the allwinner boot0 code, was there a method to interrupt booting and force the u-boot console to activate?
<oliv3r> boot0/boot1/u-boot
apritzel has joined #linux-sunxi
<KotCzarny> also, double check if you are putting files on /dev/mmcblk0,because you might have it as a separate partition and mounted somehwere else
<GeneralStupid> KotCzarny: boot is on /dev/mmcblk0p1
<GeneralStupid> root is on ...p2
<KotCzarny> yes, and when you are copying zImage where it goes?
<GeneralStupid> boot is mounted into /media/boot/
<KotCzarny> and if you copy zImage there its booting old kernel anyway?
<GeneralStupid> i have uImage and zImage in one folder. and thats (i read it yesterday) uboots standard behaviour . if nothing works he tries to boot a uImage from a fat boot device
<KotCzarny> never observed it
<jelle> MoeIcenowy: not sure how that works, but shouldn't there first be a driver mainlined
<GeneralStupid> i think i would never observe it unless it works ...
<KotCzarny> its the boot.cmd i use
<KotCzarny> i select which kernel to load via existence of dummy file (0kc46, 0kc46wens etc)
<KotCzarny> try renaming that uImage to uImage-fallback too
<GeneralStupid> that load mmc, whats the difference to "fatload" ?
<KotCzarny> i guess its whats the name suggests, no fs detection
<GeneralStupid> i guess its not using boot.scr file -.-
<KotCzarny> want my uboot as a quick test?
<GeneralStupid> KotCzarny: why not ? :D
<jrg> KotCzarny: interrupts offload trick?
<KotCzarny> unless your armbian does it already
<KotCzarny> cat /proc/interrupts to see if there is anything going on cpus 1-3
<GeneralStupid> armbian should schedule that for you
premoboss has joined #linux-sunxi
<KotCzarny> apply with:
<KotCzarny> dd if=/dev/zero of=${card} bs=1024 seek=8 count=1016
<KotCzarny> dd if=${ub} of=${card} bs=1024 seek=8
<GeneralStupid> i miss i386 :)
<GeneralStupid> KotCzarny: okay, wait a minute please :)
<GeneralStupid> KotCzarny: what is the normal workflow to get a new uboot version running?
<KotCzarny> GeneralStupid: what for? i compile on devices
<KotCzarny> GeneralStupid: git clone, make, dd
<GeneralStupid> KotCzarny: ok, done. why dd?
<GeneralStupid> i just copied the bin file and loaded in scr file -.-
<KotCzarny> and how are you going to write the binary on the card?
<KotCzarny> uboot is raw blocks starting from 8th kbyte of the mmc
<KotCzarny> well, spl is first i think, still
<GeneralStupid> KotCzarny: but script.bin is not really uboot? ...
<KotCzarny> script.bin is just a grub.conf to grub
<GeneralStupid> -.-
<GeneralStupid> KotCzarny: maybe THAT explains everything
<KotCzarny> soo. apparently you are using loboris OLD uboot ;)
<GeneralStupid> output file in dd is /dev/mmblk0 i guess? because that is not written in any partition, right?
<KotCzarny> yes
<KotCzarny> raw device
<GeneralStupid> what is $ub ?
<KotCzarny> ub=u-boot-sunxi-with-spl.bin in my script
<GeneralStupid> -.-
<GeneralStupid> of course
<GeneralStupid> KotCzarny: ok its booting, thats good, i think
<KotCzarny> :)
pstef has quit [Ping timeout: 260 seconds]
<GeneralStupid> ok now i have the old kernel with no hardware support -.-
<GeneralStupid> wrong device -.- aww
<GeneralStupid> no iam missing my hardware -.-
<KotCzarny> want my zimage too?
<KotCzarny> or just use armbian's one
jrg has quit [Ping timeout: 276 seconds]
<GeneralStupid> "could not open moddep file"
<KotCzarny> moddep?
<KotCzarny> but if it is what i think do: depmod -a
<GeneralStupid> yes, me too :D
<GeneralStupid> i hope keyboard works. ..
<KotCzarny> if you didnt compile usb as a module .. ;)
<GeneralStupid> KotCzarny: oh my... i copied it but tonight i installed an old image... so there are no modules
<GeneralStupid> KotCzarny: fuck
<KotCzarny> thats why i made so many branches in my boot.cmd, to boot selected fallback kernel without much writing to the card, even with windoze
<GeneralStupid> yes, really a nice idea :D
jrg has joined #linux-sunxi
<KotCzarny> GeneralStupid: put the card in usb adapter, insert into other sbc, fix menu/copy modules, done
<GeneralStupid> KotCzarny: i already fixed it thank you :D
<KotCzarny> :)
<GeneralStupid> KotCzarny: if you are using the armbian kernel too
<GeneralStupid> KotCzarny: did they compile software (dm) into it?
<KotCzarny> yes, but recompiled it to my needs
<MoeIcenowy> jelle: when sdio is enabled
<MoeIcenowy> the card can be probed with a id
<MoeIcenowy> like usb id
<GeneralStupid> KotCzarny: that android kernel is fine for me :D
<KotCzarny> what is the module name?
<KotCzarny> ./md/dm-raid.ko ?
<KotCzarny> you dont want android kernel
<GeneralStupid> raid1
<KotCzarny> armbian is much more bugfixeshy
<KotCzarny> .112 > .39
<GeneralStupid> KotCzarny: i guess that armbian is android?
<KotCzarny> nope
<GeneralStupid> ohh :D
<GeneralStupid> ok
<KotCzarny> uses the kernel source from bsp, but recompiled, patched to .112 and fixed here and there
<GeneralStupid> sounds like a lot of work :D
<KotCzarny> well, recently they switched to some other bsp source, still, better than the one that comes from allwinner/xunlong
<KotCzarny> GeneralStupid: its all automated in armbian's build script
<KotCzarny> just set some variables and run
<MoeIcenowy> why in drivers/pinctrl/sunxi/pinctrl-sun8i-a{2,3}3.c PC14-16 is described as "nand" rather than "nand0"?
tkaiser has joined #linux-sunxi
<wens> because there's only one nand controller?
<MoeIcenowy> wens: but PC01-13 is "nand0"
<MoeIcenowy> I can now only consider this as a bug
<MoeIcenowy> I've now succeeded in reading NAND chip id on a33
<MoeIcenowy> however "sunxi_nand 1c03000.nand: ECC init failed: -22"
<wens> MoeIcenowy: datasheet says nand_XXX
premoboss has quit [Quit: Sto andando via]
<MoeIcenowy> wens: should we set them to all "nand" or all "nand0"?
<MoeIcenowy> My local code set them to all "nand0" to make pinctrls on linux-sunxi.org/Mainline_NAND_Howto to work
<wens> MoeIcenowy: follow the datasheet
<wens> we only fix up names such as twi -> i2c, owa -> spdif
<wens> anyway, names/pins will vary across SoCs
<ssvb> tkaiser: I have updated the script for processing the DRAM reliability data, now it generates something like this - https://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit_.28automated_statistical_analysis.29
<wens> keep that in mind when porting stuff onto later SoCs
montjoie has quit [Ping timeout: 240 seconds]
<ssvb> tkaiser: does this information look clear/reasonable to you?
<tkaiser> ssvb: Nope, I scratched my head already this morning :) To be honest, I have to look into later in more detail
montjoie has joined #linux-sunxi
<KotCzarny> ssvb: most people didnt have statistical math courses, so it needs explanation or being more straightforward
<GeneralStupid> tkaiser: thanks. but thats great...
<ssvb> tkaiser, KotCzarny: ok, I just wanted to ask for some feedback and maybe clarify some things
<KotCzarny> ssvb: tbh gnuplot was more understandable for me (i might've misunderstood it too, though)
<KotCzarny> simple 'probability of the board to survive' would be the best imo
<ssvb> KotCzarny: the table already contains the same data as the old gnuplot pictures
<ssvb> KotCzarny: but we can bring the pictures back if necessary
<tkaiser> KotCzarny: There's a histogram on the right
<KotCzarny> tkaiser: that histogram is something else
<KotCzarny> its just results chart
<KotCzarny> earlier there was a nice gnuplot of the data from the second column (or third)
<tkaiser> ssvb: I fear the whole section is only of use for you and maybe a few others, the average user doesn't care and the testers just want to know what to adjust where afterwards
<ssvb> KotCzarny: yes, it was based on the data from the second column
<KotCzarny> ssvb, i think it was a third, because it was nonzero at 624 etc
<KotCzarny> also it starts growing big, so maybe move whole thing to subpage and only include a summary paragraph via wiki paragraph include
<tkaiser> I second that.
<KotCzarny> that way device's page will stay readable, have important information and you can go wild on the subpage
<tkaiser> I've sent a few people to the wiki just to get the reaction: WTF?! TL;DR
<ssvb> tkaiser: basically, the first column is the experimental data (how many boards have in fact failed in real tests)
<KotCzarny> first column is clock speed
<KotCzarny> :)
<KotCzarny> unless you count from 0
<KotCzarny> ;)
<ssvb> tkaiser: the second is trying to do the theoretical approximation assuming that the distribution is really Gaussian (the bell shaped curve)
<ssvb> tkaiser: and the third is the "worst case" estimate, just in case if the actual distribution is not Gaussian but something more fancy
<ssvb> tkaiser: the real probability may be something between the numbers in the second and the third columns, just in case if we have a somewhat distorted Gaussian distribution
<KotCzarny> ssvb: distorted by crappy PSUs
<tkaiser> ssvb: So not even 624 MHz can be considered 'safe' :(
<ssvb> KotCzarny: oh, I'm counting the columns with the failure percents
<KotCzarny> maybe we need a column in results table named 'PSU used'
<ssvb> tkaiser: well, we have a theoretical prediction for having 0.4 % failures at 624 MHz, and this was exactly the same before
IgorPec has joined #linux-sunxi
<ssvb> tkaiser: it's up to us to decide if it is "safe" enough or not
<tkaiser> ssvb: I'm pretty fine with 624 MHz for all H3 boards and a provided 'test image' for people who think they would benefit from higher DRAM clocks.
<tkaiser> ssvb: But at the same time I fail to understand why we (linux-sunxi community) then have settings like 480 MHz for Cubieboard 2?
<KotCzarny> different ram modules/controller?
<tkaiser> KotCzarny: 480 there is like 768 with H3
<tkaiser> CB2 is A20
<tkaiser> Or A10 -- don't know.
<KotCzarny> DDR3-1333H DDR3-1600K on cubie2
<ssvb> tkaiser: are you asking me why we are using potentially unsafe settings for Cubieboard 2?
<KotCzarny> a20
<tkaiser> ssvb: Exactly :)
<ssvb> tkaiser: that's because nobody cares
<KotCzarny> i guess cubietech tested their stuff to be able to achieve that
<oliv3r> KotCzarny: they tested it on a few boards and then shipped it :)
<ssvb> tkaiser: I did suggest to run some tests in the past, but Hans de Goede sabotaged this
<KotCzarny> :)
<KotCzarny> marsboards also use 480
<KotCzarny> maybe bananas/oranges were so much inferior
<ssvb> tkaiser: and since Hans de Goede is the nominal maintainer for the Cubieboard 2 board, ensuring reliability is his responsibility after all
<KotCzarny> pcduinos use 480 too
<KotCzarny> olimex the same
<KotCzarny> so its just bananas/oranges with 432 by default
<ssvb> tkaiser: I only verified that 480 MHz DRAM clock speed was working fine on *my* Cubieboard 2 (while I still had this board), but mileage may vary
<ssvb> KotCzarny: pcduino boards use 360 MHz DRAM clock speed now - http://git.denx.de/?p=u-boot.git;a=commit;h=974936a80feaa431e6a36a96e693cdf399bd91dc
<KotCzarny> hehe
<KotCzarny> but thats for a10?
<KotCzarny> i was talking about a20s
<ssvb> I don't have any a20 pcduino boards
<ssvb> again, it's the maintainer's responsibility
<ssvb> if the maintainer wants to ship crap to the end users, nobody can can really stop him
<KotCzarny> question is, what value should be used on devices pages
<tkaiser> Well, the distro people could. Or could at least try to encourage some users to test so that some awareness for bad settings might increase.
<wens> KotCzarny: probably the one from the fex file? that's likely what you get from the vendor
<ssvb> KotCzarny: I believe that it is taken from the vendor's fex file, and then adjusted if necessary
<KotCzarny> vendors (especially chinese) ship software by copypaste
<wens> KotCzarny: software is probably not their expertise
<ssvb> yes, sometimes they are just copy/pasting from the other boards, and sometimes deliberately overclocking hardware to look good in the marketing materials
<KotCzarny> i think sunxi wiki should note what is the source of that value (vendor or user tests)
<KotCzarny> and discourage unstable ones
<ssvb> tkaiser: yes, driving this activity by the distro maintainers may work too
<KotCzarny> Memory type matters. It has been found that board with DDR3 memory tend to overheat much more than boards with DDR3L memory. At the time of writing, Xunlong Orange Pi boards are all based on DDR3L memory, but Banana Pi M2+ and NanoPi M1 boards are fitted with DDR3 memory instead
<KotCzarny> nice comment if anyone wonders why the heck some boards overheat like crazy
<KotCzarny> tkaise, consider doing banana m2 test with heatsinks on dram?
<tkaiser> KotCzarny: Wrong/outdated info. Where did you find it so I can correct it?
<KotCzarny> ie. it might lower board (and cpu in the consequence too)
<KotCzarny> pt 6
<tkaiser> Merde, so I'll have to ask Jean-Luc to correct it
<tkaiser> Since OPi One/Lite also use DDR3 and not DDR3L and do not overheat that much
<KotCzarny> tkaiser, i wonder how much doing tests with differnt dram speed (ie. 600 vs 672) would affect soc temp
<KotCzarny> if at all
<KotCzarny> because having lower dram speed will make cpu stall more usually
<KotCzarny> so it should be a limamemtestr and not cpuburn
<tkaiser> Post #4
<KotCzarny> tkaiser: im away from my boards now, and no way to reboot them in case of a hang
<tkaiser> KotCzarny: I won't do any further testing since I learned to hate that spinning cube ;)
<KotCzarny> hehe
<KotCzarny> ssvb: make a special edition with tkaiser's profile pic instead of lovecube
<tkaiser> ssvb: I'm thinking about that providing also test images for A20 boards. But not now, maybe in a few weeks
<KotCzarny> ssvb: another idea, fps counter?
Gerwin_J has joined #linux-sunxi
formruga has quit [Read error: Connection reset by peer]
<jrg> KotCzarny: sorry. where was that interrupts trick again?
<KotCzarny> jrg, always at my user page
<jrg> where is your user page? :)
<jrg> ok
<jrg> the external interrupts one?
<KotCzarny> see 'hacks' paragraph
<jrg> ah ok
<jrg> thats just a script?
<KotCzarny> yup
<KotCzarny> no need to reboot to test
<KotCzarny> but as i said
<KotCzarny> cat /proc/interrupts
<KotCzarny> and see if things are scattered over cpus
<KotCzarny> if you know you will be using lots of eth, you can put gmac on cpu3 and rest on 0-2
<jrg> seems like they are
<wens> does irqbalance help?
<KotCzarny> wens, is irqbalance working in legacy?
<KotCzarny> um
<KotCzarny> jrg
<wens> KotCzarny: no idea
<KotCzarny> all interrupts are on cpu0
<wens> KotCzarny: it's just installed by default on ubuntu
<KotCzarny> mov gmac0 to 2 and mmc to 3
<KotCzarny> *move
<KotCzarny> then recheck those samba tests
<KotCzarny> and if you are using stock armbian then they are either not scattering irqs by default or i dont know
<jrg> ah i see. dont want to do it now. im a bit busy. but ill try ot later and tell you how it goes.
<KotCzarny> igorpec, tkaiser ^
<jrg> i am
<jrg> stock that is
<KotCzarny> jrg, just run my script
<jrg> 5.14
<KotCzarny> then do some tests and compare
<jrg> ok
<jrg> if i disappear...
<jrg> lol
<KotCzarny> unlikely
dearfibonacci_ has joined #linux-sunxi
<jrg> im guess as root?
<KotCzarny> yes
<jrg> ah ok
<KotCzarny> wens, is that userland thing?
<jrg> i can see gmac0 hitting cpu3
<jrg> let me try it
<wens> KotCzarny: yeah, it's a daemon that supposedly balances irq affinity for you
<jrg> oh. cpu2 is where t went
<KotCzarny> wens, good to know, though never tried it, static rc.local script is good enough for me
<KotCzarny> jrg: its bitmask 1==cpu0, 2==cpu1, 4==cpu2, 8==cpu3
dearfibonacci has quit [Ping timeout: 240 seconds]
<tkaiser> wens: irqbalanced on ARM in default install does nothing except wasting ressources and eating up all RAM :)
<MoeIcenowy> bbrezillon: you have H27UCG8T2E datasheet?
<tkaiser> But there's a fixed version around (that no distro uses AFAIK): https://github.com/dv1/irqbalanced
<jrg> doesnt seem to have improved performance
<tkaiser> jrg: This IRQ stuff has some great effect on some platforms (eg. ODROID-C1 and eth0 and usb1 sharing the same IRQ: horrible performance)
<tkaiser> jrg: With other kernels / on other platforms it's not that important (but still helps)
<KotCzarny> tkaiser, if helps, why his armbian 5.14 didnt setup it?
<KotCzarny> see his paste
<jrg> KotCzarny: doesnt seem like moving it to cpu2 helped much. still seeing 10-15MB/s over cifs
<KotCzarny> jrg, how much you get when copying something to /dev/null ?
<KotCzarny> (from cifs)
<jrg> not sure... havent checked that just yet
<KotCzarny> tkaiser, he uses his opi as a client
<KotCzarny> not as a server (i think)
<jrg> but im sure thay i should be getting more than 10-15 wherever i send it
<jrg> yah. it is a client
<tkaiser> jrg: And maybe replace armhwinfo with https://github.com/igorpecovnik/lib/blob/master/scripts/armhwinfo
<jrg> connecting to a fnas box
<KotCzarny> jrg, hint: install bwm-ng
<KotCzarny> or bwm, depends on distro
<tkaiser> KotCzarny: Ok, am away if we're talking about performance problems with crappy CIFS client in 3.4.x kernel
<KotCzarny> tkaiser: still, why 5.14 didnt reshedule interrupts on his box?
<tkaiser> jrg: General advice: Test network and FS individually, then together. Everything else is a waste of time. So use iperf
<jrg> heh
<jrg> network working fine
<tkaiser> KotCzarny: It does, no idea why it doesn't in his installation (also I don't care at all)
<jrg> i get 100MB/s on other boxes
<jrg> 50MB over ac to my mbp
<tkaiser> jrg: Fine, then it's crappy CIFS client and you know the reason.
<jrg> lol
<tkaiser> jrg: Wait for mainline support and stop whining ;)
<jrg> it toos out at 20MB on the opi
<jrg> tops
<jrg> lol
<KotCzarny> jrg, does that nas box support nfs too?
<jrg> not whining. i dont need the bandwidth THAT much.. just curious why it was going 25% of its speed
<jrg> yes
<tkaiser> KotCzarny: Unbelievable, exact the same discussion as 2 weeks ago.
<KotCzarny> mount, test, see if you get differnt results
<KotCzarny> tkaiser: lol
<jrg> :)
<tkaiser> KotCzarny: NFS is crap in a heterogenous environment
<jrg> ill try nfs in a bit
<jrg> i already have an nfs mount
<jrg> mounted
<jrg> for btc
<KotCzarny> tkaiser: my windoze boxes are just toys, but i use nfs on them too if i want to access shared files
<jrg> windows still has sfu?
<jrg> smb is t bad when it works
<KotCzarny> yeah. when it works.
<jrg> id rather use it because im using the fnas box as an ad dc
<KotCzarny> but sometimes it fails even with same os version
<jrg> so the pi auths against t using winbind then auto mounts home dirs
<tkaiser> To be honest: The most recent CIFS/SMB dialects are great. But that's so off-topic here...
<jrg> using mount.cifs and pam_mount
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<jrg> lol
<KotCzarny> jrg: i think win7 pro/ulti/ent versions have nfs built in, just enable them in software
<jrg> id rather not use nfs :) the goal is to use smb for everything.. its working fine other than lacking speed on the opi
<KotCzarny> k, still, for checking you can do some tests with nfs
<KotCzarny> then you will know where to look further
<jrg> i will in a few
<bbrezillon> MoeIcenowy: I have access to it, but it's under NDA
kas has joined #linux-sunxi
<kas> Hi, how fix this? " lima-memtester: /tmp/lima-memtester/lima-memtester.c:42: fb_unblank_thread: Assertion `fd != -1' failed."
tkaiser has joined #linux-sunxi
<tkaiser> jrg: Forget about this NFS stuff. As already suggested: Try out mainline: This image here works (minus one USB port and one led): http://linux-sunxi.org/Banana_Pi_M2%2B#OS_images
cnxsoft has quit [Read error: Connection reset by peer]
<KotCzarny> tkaiser, um, what about ths?
<tkaiser> jrg: And I won't repeat this a 3rd time.
<KotCzarny> also, he has opi+2e
<tkaiser> KotCzarny: Doesn't matter on OPi 2E Plus. Clockspeed in this image is 816 MHz and that fine with Oranges (but bad for Banana)
<tkaiser> BPi M2+ is an overheating version of OPi Plus 2E (minus one USB port, minus one led)
<tkaiser> That's not that hard to understand, isn't it?
cnxsoft has joined #linux-sunxi
<tkaiser> Every f*cking pin mapping is identical so everything works (minus...)
<KotCzarny> hehe
formruga has joined #linux-sunxi
<jrg> an overheating version lol
massi has quit [Read error: Connection reset by peer]
<KotCzarny> hot version
massi has joined #linux-sunxi
<jrg> tkaiser: this would involve wiping whats already installed?
<KotCzarny> jrg, you need more sd cards
<tkaiser> jrg: Nope, just use a spare SD card (4GB)
<jrg> when i get home ill test it out
<tkaiser> jrg: In Armbian forum someone wanted to use his OPi as AppleTalk device. Not possible with this 3.4.x BSP kernel. Switching to mainline kernel --> everything works perfectly now (and this must've been a very early version of montjoie's driver since this has happened months ago)
<kas> :(
<KotCzarny> mali dp[56]xx
<plaes> just display engine
<kas> Guys, any1 know how fix this: lima-memtester: /tmp/lima-memtester/lima-memtester.c:42: fb_unblank_thread: Assertion `fd != -1' failed." ?
<KotCzarny> ssvb ^
<kas> haha
<kas> thx
<KotCzarny> kas, also, run as root maybe?
<kas> to samo
<KotCzarny> stick to english
<tkaiser> kas: Which board, which kernel?
<kas> okay
<kas> 3.4.109-sun7i
<kas> my own board, based on olimex/awsom
<KotCzarny> do you have display at all?
<kas> no..
<KotCzarny> i mean, /dev/fb0 ?
<kas> nope
<plaes> there's your issue
<KotCzarny> limamemtester runs as graphical app (xorg one to be exact) to maximize mem bandwidth usage
<kas> previously i used memtester only, thanks for help
<KotCzarny> you have to stress mem in some other way to check if its stable then
<kas> ok
IgorPec has quit [Ping timeout: 272 seconds]
Worf has quit [Quit: Konversation terminated!]
megi has joined #linux-sunxi
dearfibonacci_ has quit [Quit: Leaving]
<MoeIcenowy> bbrezillon: ah-oh
JohnDoe3 has joined #linux-sunxi
<MoeIcenowy> bbrezillon: can the patch at http://lists.infradead.org/pipermail/linux-mtd/2016-June/067848.html use on this chip?
juri_ has quit [Ping timeout: 250 seconds]
<MoeIcenowy> current 4.7-rc3 cannot detect the oobsize successfully
JohnDoe_71Rus has quit [Ping timeout: 244 seconds]
<bbrezillon> yep, it should
<ssvb> KotCzarny: there is no dependency on xorg in lima-memtester
<KotCzarny> ssvb, hmm, i think i was running it in x, my memory might be playing tricks. still needs /dev/fb0 ?
<ssvb> kas: you can try to build the kernel from this branch - https://github.com/ssvb/linux-sunxi/commits/20151206-embedded-lima-memtester
<tkaiser> ssvb: He has an A20 device
<ssvb> kas: just use the "sun7i_lima_memtester_defconfig" to build it
<tkaiser> ssvb: Oh, nice.
<kas> thanks
<ssvb> tkaiser: that's a different branch (for A10/A13/A20)
<MoeIcenowy> bbrezillon: is these patches in a git repo?
<ssvb> kas: it has embedded initramfs, so you just can temporarily replace your current kernel and boot it
<tkaiser> ssvb: Ah, now I see it (the missing '-h3')
<kas> okok
<ssvb> the test will start automatically and report the results on the UART serial console, there will be also a spinning textured cube demo running (but you will not see it without a connected hdmi monitor)
<ssvb> tkaiser: yes, we had the FEL based DRAM test for A10/A13/A20/H3 available from the very start, it was not Orange Pi PC specific :)
<ssvb> tkaiser: I still did not have time for debugging it on opi+2e though
<kas> ok, i want use lima with a10 dram calibration tools
<tkaiser> ssvb: No worries. And I knew it, just got confused since I already searched in your repo for an A20 branch (but overlooked it)
naibmra has joined #linux-sunxi
<kas> is this possible with embedded lima-memtester
naibmra has quit [Client Quit]
<ssvb> kas: yes, it is possible with the same kernel, but the initramfs needs to be disabled
<ssvb> kas: but first try to check what which dram clock speeds work reliable with your current dram settings
<kas> ok ;)
<kas> ssvb: I fixed this, script.bin -> disp_init_enable = 1
<KotCzarny> kes, you did say its your own board, what does it mean?
<kas> Custom desing for building automation
<jonkerj> Some of you are working hard on NAND-support. My board (H3 Opi+) has eMMC, but the schematic suggest there is something NAND-y going on between SOC and memory chip. Does this mean that the memory could be interfaced both NAND and eMMC?
<KotCzarny> nice, built locally or in china?
<kas> locally
<KotCzarny> kas, so no plans for super cheap boards from .eu ?
kaspter has quit [Ping timeout: 276 seconds]
<kas> we change soc, freescale or smth
<kas> maybe in future
<wens> jonkerj: the design is you can choose either nand or emmc, but not both
<wens> the pins are shared
<jonkerj> of course, but in theory, I could use low-level NAND access instead of eMMC on this board?
<wens> and you can layout a board that can use either emmc or nand in the same area, though with different pads of course
<wens> maybe
<MoeIcenowy> bbrezillon: thanks
<MoeIcenowy> but after applying the patch
<MoeIcenowy> the nand doesn't work properly either now
<MoeIcenowy> (but the oobsize is correctly set to 1664 rather than 224
<oliv3r> ssvb: !!! i found a working nand based board :) it uses the old 32bytes u-boot header, but lo en behold :)
<ssvb> oliv3r: 0x01 at the offset 0x28, as expected
<NiteHawk> bingo :)
<plaes> o_O
apritzel has quit [Ping timeout: 244 seconds]
<MoeIcenowy> bbrezillon: now it seems that eraseblocks after 240 are all consider badblock...
Mr__Anderson has joined #linux-sunxi
<bbrezillon> you need to scrub the NAND if you were previously using Allwinner's libnand
<bbrezillon> if you have support for the NAND device in u-boot, you can use nand scrub.chip
<MoeIcenowy> bbrezillon: how to scrub it under linux?
<MoeIcenowy> and how to backup the factory badblock table?
<bbrezillon> it's not supported
<bbrezillon> (I mean, the BBT backup)
reev has quit [Ping timeout: 264 seconds]
<MoeIcenowy> thus how to scrub it?
<MoeIcenowy> use mtd-utils?
<MoeIcenowy> (and will livesuit regenerate bbt?)
<bbrezillon> to scrub the NAND under Linux you'll have to hack into the nand_base.c file to remove the blockisbad check, and then use flash_erase -N
Mr__Anderson has quit [Remote host closed the connection]
<MoeIcenowy> bbrezillon: oh maybe I should now work on uboot nand support
<bbrezillon> The branch I pointed yesterday should work out of the box
<MoeIcenowy> bbrezillon: maybe I should first add the sun8iw5 nfc patch
<MoeIcenowy> (It supports ahb reset, necessary for sun8iw5 to drive nfc correctly
<bbrezillon> yep, probably. BTW, what did you do to make it work
<bbrezillon> ?
<MoeIcenowy> just add ahb reset
<MoeIcenowy> :-)
<MoeIcenowy> and dt work
<MoeIcenowy> bbrezillon: will livesuit regenerate bbt for sunxi?
Inode has quit [Ping timeout: 250 seconds]
IgorPec9 has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
souther has quit [Ping timeout: 258 seconds]
souther has joined #linux-sunxi
<MoeIcenowy> bbrezillon: thx I get now a mtd device.
nove has joined #linux-sunxi
lennyraposo has joined #linux-sunxi
<bbrezillon> MoeIcenowy: I'm not even sure livesuit store an on-flash-bbt or even care about factory bad blocks
<bbrezillon> but when they write data on the NAND they do not account for the randomization step occuring on the bad block marker
<MoeIcenowy> bbrezillon: is there any drivers for SLC mode?
<MoeIcenowy> s/drivers/patches/
kas has quit [Ping timeout: 250 seconds]
<bbrezillon> SLC mode is supported in the CHIP nextthing/4.4/next branch
<bbrezillon> MoeIcenowy: ^
<bbrezillon> but there's no patches
apritzel has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
<MoeIcenowy> bbrezillon: I'll cherry-pick something
* MoeIcenowy expecting a disaster after getting CHIP
<bbrezillon> MoeIcenowy: why that?
<MoeIcenowy> bbrezillon: can only get system installed on nand
JohnDoe3 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
<oliv3r> bbrezillon: hey Boris! how are things in nand land :)
<MoeIcenowy> bbrezillon: is ubi on mlc still unstable?
<bbrezillon> yes
IgorPec9 has quit [Ping timeout: 260 seconds]
<bbrezillon> we're working on that too => http://thread.gmane.org/gmane.linux.drivers.mtd/67412
<bbrezillon> MoeIcenowy: ^
zuikis has joined #linux-sunxi
<bbrezillon> oliv3r: we keep progressing
IgorPec9 has joined #linux-sunxi
massi has quit [Read error: Connection reset by peer]
<MoeIcenowy> bbrezillon: how can I send nand patches for a33?
<bbrezillon> MoeIcenowy: is it the first you're submitting kernel patches?
<MoeIcenowy> bbrezillon: yes
<MoeIcenowy> (it's only two simple patches for reset lines
<bbrezillon> then reading that is a good start ^
<MoeIcenowy> (but they're based on torvalds/linux/tree/master
<MoeIcenowy> should I rebase them to sunxi-next or linux-next?
<wens> bbrezillon: it says you're on vacation?
<bbrezillon> that exactly what we want, or based on 4.7-rc1
<MoeIcenowy> what is that exactly wanted? rebase?
<wens> bbrezillon: oh, sorry, i thought the author of the series was you
<bbrezillon> no, basing your changes on top of Linus' master branch or the last -rc
<bbrezillon> MoeIcenowy: ^
<bbrezillon> wens: which series?
<wens> bbrezillon: ubi mlc
<bbrezillon> I wrote part of it
<bbrezillon> but I didn't send the patches myself
IgorPec9 has quit [Ping timeout: 246 seconds]
IgorPec10 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec10 has quit [Ping timeout: 240 seconds]
<megi> hi, does someone understand AXI/ATB clocks on H3? I have trouble explaining why https://github.com/megous/u-boot/commit/85dddd9bbbd2e57aad1718579e552bd936716866 prevents lockups when changing PLL1 frequency later during the boot in the kernel
<megi> datasheet states that "Clock output of PLL_CPUX is used only for CPUX, and the frequency factor can be dynamically modified for DVFS"
<megi> yet the diagram looks like it is used for ATB and AXI via some divider
apritzel has quit [Ping timeout: 244 seconds]
p1u3sch1 has quit [Ping timeout: 272 seconds]
apritzel has joined #linux-sunxi
<megi> divider values are configured in u-boot, and if I increase the values to max, I prevent lockups when PLL_CPUX is modified in kernel (i put pintks around the register change, and it locks up exactly during the change, without this patch)
<megi> it seems that something gets overclocked, via CPUX frequency change
<megi> in other words, will u-boot maintainer accept my patch with "hey, it prevents lockups but i don't know why" explanation? :D
<ssvb> megi: what is the original and what is the new clock frequency when it deadlocks?
p1u3sch1 has joined #linux-sunxi
<megi> original is what is set in u-boot
<ssvb> either way, it's best to first figure out what is wrong
<ssvb> if the BSP kernel is able to work correctly and do DVFS things after booting with the same bootloader, then your code is probably doing something wrong
apritzel has quit [Ping timeout: 244 seconds]
<megi> it's probably not my code, I just set up the operating points in dts
<megi> cpu clock is managed by sunx-clk
<ssvb> looks like it might be fun to debug
<oliv3r> bbrezillon: did you ever get the problem confirmed about corrupted nand, even in slc mode? i just found 1 of the 3 boards i used for NAND and it was still intakt, (i had a failure rate of 2/3 back then)
<megi> I don't remember what the new frequency was, but it could have possibly been lower, because the original was set to 1.3GHz and the new one get's set by thermal-zone
lamer14658332975 has joined #linux-sunxi
<ssvb> megi: is the voltage also getting changed?
<megi> no, I tested it without voltage scaling
tkaiser has quit [Ping timeout: 240 seconds]
<megi> I did the testing a few months ago, but I remember isolating it just to the PLL_CPUX register change, with all else equal
<wens> AXI is probably related to the memory / bus interface of the cpu
<wens> clocking it too high might not work
<ssvb> megi: anyway, it's best to cross-check everything against the BSP kernel, compare the AXI divisor settings and everything else
<megi> also it might be, that the bsp kernel touches the ATB/AXI divider setup in the kernel too so even if u-boot sets up something not stable, the kernel fixes it
<megi> yeah, I'll try checking what exactly BSP kernel does with relevant registers during boot
<bbrezillon> oliv3r: I don't remember seeing a corruption when operating in SLC mode, but I can't say it will never happen :-)
<ssvb> megi: isn't the arisc core responsible for the DVFS job on H3 though?
<megi> not necessarily
<megi> you can successfully do dvfs without it
lamer14658332975 has quit [Ping timeout: 244 seconds]
<ssvb> so far it looks like you can't ;)
<megi> it works for me
<megi> with the patch
<megi> but it might make it harder to debug what the bsp kernel does...
<ssvb> that's what I mean
<megi> is there a way to access the registers from userspace? like using /dev/mem or something?
<megi> I'm thinking of just dumping the registers while the kernel is running on various frequencies
<ssvb> yes, try devmem2
cptG_ has joined #linux-sunxi
<megi> ah, cool :)
<ssvb> it might be necessary to toggle some kernel option to allow it to work though, but this is simple
<megi> thanks
cptG has quit [Ping timeout: 250 seconds]
<oliv3r> bbrezillon: i'll see if ihave a corrupted board and will try to get a dump from it if that helps at all
<MoeIcenowy> bbrezillon: ubifs now do not support 4MByte eraseblock?
<MoeIcenowy> "mkfs.ubifs /dev/ubi0_0" gets "Error: too large LEB size 4161536, maximum is 2097152"
<bbrezillon> MoeIcenowy: yes, we have a patch for that one as well, though if you use SLC mode you'll have 2M pages
orly_owl has quit [Ping timeout: 244 seconds]
<megi> aha! :)
<megi> ssvb: I got the difference
<ssvb> megi: great! what was it?
<megi> CPUX_AXI_CFG_REG at 0x01C20050 has value 0x00020202 on bsp kernel, which means AXI_DIV_3 and ATB_DIV_4, u-boot sets ATB_DIV_2
<megi> so the ATB clock on mainline gets twice the frequency
<MoeIcenowy> bbrezillon: but the SLC mode commits are difficult to cherry-pick
caog has quit [Ping timeout: 244 seconds]
orly_owl has joined #linux-sunxi
Inode has joined #linux-sunxi
apritzel has joined #linux-sunxi
<megi> ssvb: I used my patched u-boot, with original u-boot the dividers stay the same
<ssvb> megi: does fixing only the ATB divisor help to avoid deadlocks?
<TheLinuxBug> anyone have a link for Lubuntu_1404_For_OrangePi_Plus2E_v0_8_0.img.xz that isn't baidu - I would love to download it but I can't get more than 5kb/sec
<KotCzarny> you dont want it
<TheLinuxBug> hmm
<TheLinuxBug> it worse than armbian
<TheLinuxBug> ?
<KotCzarny> how should i say it
<TheLinuxBug> I am apauled by their Android release
<TheLinuxBug> so nothing would suprise me at this point
<KotCzarny> armbian is the best thing you can get for sunxi boards
<KotCzarny> and manufacturer images are the worst thing you can get
<TheLinuxBug> That Android release is the biggest pile of horse manure I think I have ever dealt with regarding Android
<KotCzarny> their linux images are just random grabs from the internet
<KotCzarny> just to fill their download pages
<KotCzarny> and to claim that 'they have software'
<TheLinuxBug> I actually was going to use this for a media center for my sister until I realized how total crap that android release is
<TheLinuxBug> ended up giving her my Odroid C2 and ordering a new one
<KotCzarny> you can still use armbian for that
<TheLinuxBug> it was not worth it to have her call me all the tmie asking about apps etc
<TheLinuxBug> Odroid C2 just works
<TheLinuxBug> and hardkernel produces a beautiful Android image
<KotCzarny> you know why you pay for those chinese boards so little?
<TheLinuxBug> If I were anywhere near any of them I would offer to buy coffee, thats how much a dream it is compared ro the orang Pi
<TheLinuxBug> Oragne Pi Plus 2E
book` has quit [Ping timeout: 240 seconds]
<TheLinuxBug> well
<TheLinuxBug> its depressing
<KotCzarny> not really
<TheLinuxBug> because it COULD be an awesome board for that
<KotCzarny> just grab hard work armbian folks did to make things work
<TheLinuxBug> if only someone spent a few minutes to think when they built the SDK
<TheLinuxBug> yeah but my sister who isn't a computer nerd isn't gonna understand using Armbian, thats the point of Android
<TheLinuxBug> if that would have suited the purpose and I thought she could handle it, then I would have taken that route
<TheLinuxBug> unfortunately not so much
<KotCzarny> why are you saying about 'lubuntu' then?
<TheLinuxBug> I was just gonna look at it on the board now and see how crappy it was lol
<TheLinuxBug> before I tossed it in the bin of 'maybe I will play with again someday' and go back to working with my RPi3
<KotCzarny> board is nice, software is nonexistent
<TheLinuxBug> and oder me a new odroid c2
<KotCzarny> but armbian fills that hole
Seppoz has quit [Remote host closed the connection]
<KotCzarny> still, you can grab any similar board, move script.bin and have a working os
<KotCzarny> well, not move, but replace some magic things
<TheLinuxBug> KotCzarny: don't get me wrong, sunxi does wonderful work and I am sure it makes a half decent workstation, but thats not what I wanted to use it for.. so for now it doesn't have a real use for me as I spent 36 hours messing with Android and such to find just an abysmal piece of crap that no one even spent time to care about. Kinda removed for me the attraction it once had.
<KotCzarny> see above, beauty of soc is that differences are small enough to swap images
<TheLinuxBug> if you can find/get me easy steps to make one of the Android images that is worth a crap to work, ill send you $20 on paypal. For me though my time is to valuable to even look at that board again for a few weeks, I honestly about through it at the wall after I realized the shit kernel they installed on that android release.
<KotCzarny> tbh i havent bothered with android as i wanted them for linux only
<KotCzarny> for a quickie you can just try android images for other h3 board
<TheLinuxBug> I actually just tried one that was supposed to be for OPi PC
ganbold has quit [Remote host closed the connection]
<TheLinuxBug> with no luck
<TheLinuxBug> uboot seems different
<TheLinuxBug> doesn't even try to boot the sdcard
jernej has joined #linux-sunxi
<KotCzarny> maybe it detects wrong mmc device or something
<TheLinuxBug> KotCzarny: My A10's and my BPi M1 are my main work horses because of SATA and I use them for several things around here, but without SATA or a usable android image at least right now that OrangPi Plus 2E board doesn't really garner much interest atm, plus im so frustrated with it att his point I could happily go a few weeks without thinking about it again :Z
juri_ has joined #linux-sunxi
<KotCzarny> try android for opi plus
<TheLinuxBug> god
<TheLinuxBug> any chance you have a link that not Baidu
<TheLinuxBug> ohh wait
<TheLinuxBug> amazing
<KotCzarny> google drive?
<TheLinuxBug> google actually works
* TheLinuxBug faints
<jrg> lol
<TheLinuxBug> yeah all their other images I have tried to download they didn't even bother to take the time to upload it to google
<TheLinuxBug> thankfully this one they did
<jrg> why are they even using google drive for stuff like this?
<jrg> you'd think they'd host it somewhere
<KotCzarny> jrg: they do, using gdrive as a host, hehe
<jrg> lol
<jrg> well I'm just saying it isn't like they're using up a ton of space. you'd think they'd have it hosted under their domain name with a direct link
<KotCzarny> TheLinuxBug: keep in mind things might not work because wifi chip is different a bit
<TheLinuxBug> ya
<TheLinuxBug> well
<TheLinuxBug> anything at this point is a step in the right direction
<KotCzarny> but you will at least see if its as broken as the latest release
<jrg> TheLinuxBug: I'm using my opi+2e as a micro server
<jrg> works great so far with Armbian other than samba being a bit slow
<jrg> well... cifs
<KotCzarny> jrg: hosting costs moneys
<jrg> KotCzarny: they don't pay for google drive?
<KotCzarny> most likely not
<jrg> how Chinese :)
<TheLinuxBug> skipped the card again and booted from emmc
<TheLinuxBug> so again uboot or something needs changed
<KotCzarny> TheLinuxBug: did you use phoeanixflash to create the image?
<jrg> TheLinuxBug: it did?? I want mine to do that
<jrg> does it still show the SD?
<TheLinuxBug> er no cause it was a .img, I figure it raw
<KotCzarny> nope
<TheLinuxBug> eww I have PhoenixCard :(
<KotCzarny> read their instructions
<TheLinuxBug> don't even think I have a card reader thats compat
* TheLinuxBug goes and cries in a corner in the fetal position
<KotCzarny> hehe
<jrg> TF card?
<KotCzarny> microsd
<KotCzarny> in short
<KotCzarny> transflash
<jrg> oh
<jrg> thought it was a special sd sized card
<KotCzarny> dont know why they invent two names for it. probably moneys
<jrg> like those wii discs
<jrg> SD = Sandisk doesnt it?
<KotCzarny> nope
<KotCzarny> secure disk
<TheLinuxBug> well originally full sized card were called TF cards then they made the smaller ones and needed to have a fancy naming scheme for them
<KotCzarny> or something
<KotCzarny> secure digital
<jrg> KotCzarny: i fiured it was Sandisk Secure Disk (tm)
<TheLinuxBug> Sandisk wishes
<jrg> haha
<TheLinuxBug> they would be making bank if that were true
<TheLinuxBug> ;p
<jrg> theres a secure disk association?
<KotCzarny> and here is short tf history
<jrg> as an improvement over mmc?
* jrg scratches head
<jrg> doesnt emmc go like
<jrg> 300MB/s?
<KotCzarny> megabyte or megabit?
mossroy has joined #linux-sunxi
<jrg> oh. theoretical max speed of mmc vs sd is the same
<jrg> US$1,000/year, excepting SPI-mode only use.
<jrg> wow
<KotCzarny> moneys.
<jrg> thats for SD
<jrg> what a racket
<jrg> too bad SD doesnt go nearly as fast as it is rated
<jrg> well. its max speed. plus doesnt it hate io?
<KotCzarny> doesnt matter, for us its controller limited
<jrg> yeah. which usually seems usb
<jrg> which im guessing is some type or royalty / licensing sidestep
<jrg> of
<KotCzarny> also, you should be more interested in 512B or 4kB random io speed
<jrg> thats what the freenas box is for
<KotCzarny> sure, but os must wait if you write something, swap for example, or must read some lib
<KotCzarny> etc
<jrg> the orange pi is great after i figured out what was causing the samba issue
<jrg> armbian puts 128MB of swap into ram doesnt it?
<KotCzarny> dont know, but i do the same
<KotCzarny> linux requires few megs of swap to not to go crazy
apritzel has quit [Ping timeout: 244 seconds]
<jrg> why the fk is that blinking? lol
<KotCzarny> hmm?
enrico_ has quit [Quit: Bye]
Netlynx has joined #linux-sunxi
maz has quit [Quit: Leaving]
apritzel1 has quit [Ping timeout: 244 seconds]
megi has quit [Quit: megi]
ricardocrudo has quit [Remote host closed the connection]
book` has joined #linux-sunxi
paulk-nyan-big has joined #linux-sunxi
<montjoie> raaah I have done NAPI for RX but get only 280/380mbit/s
<KotCzarny> do it for tx then too?
<montjoie> I try
<KotCzarny> add some logs what is stalling too? timing for packets?
akaizen_ has quit [Read error: No route to host]
akaizen has joined #linux-sunxi
maz_ has joined #linux-sunxi
maz_ has quit [Ping timeout: 264 seconds]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
Amit_t_ has quit [Quit: Page closed]
afaerber has quit [Quit: Ex-Chat]
vagrantc has joined #linux-sunxi
<KotCzarny> yes, i have one bpi-m1
<KotCzarny> um, wrong chan
Netlynx has quit [Quit: Leaving]
lamer14658332975 has joined #linux-sunxi
Netlynx has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
Netlynx has quit [Client Quit]
paulk-nyan-big has quit [Quit: Leaving]
IgorPec has quit [Ping timeout: 250 seconds]
zuikis has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
iamfrankenstein1 has quit [Ping timeout: 252 seconds]
Mr__Anderson has joined #linux-sunxi
nove has quit [Ping timeout: 260 seconds]
iaglium has quit [Ping timeout: 272 seconds]
nove has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
lamer14658332975 has quit [Quit: jIRCii - http://www.oldschoolirc.com]
tkaiser has joined #linux-sunxi
<tkaiser> TheLinuxBug: Why do you waste your time with this 'official' Android build? You find in Orange Pi forums a few Android ROMs for H3 TV boxes.
<tkaiser> TheLinuxBug: Then grab fex file from Armbian, read through the link I posted a few days ago how to overwrite sys_config.fex stuff and you're done.
<tkaiser> I try to keep every fex we use at Armbian compatible with the old u-boot 2011.09 all the other Linux images or Android ROMs are using (except of led definitions). So it should just work
<tkaiser> At least for H3 devices.
xcasex has quit [Ping timeout: 260 seconds]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<TheLinuxBug> tkaiser: mostly because it already on the eMMc and my goal would be to run this from eMMc and not a SDcard.
xcasex has joined #linux-sunxi
<TheLinuxBug> tkaiser: but obviously that is the direction I will have to go if I want anything usable. It is mostly disappointing to me they would even release those Android images as they are utter crap and the person who made them has to know that.
jstein has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser> TheLinuxBug: I don't know Android at all so can't say that much. But by following some threads over there at the forums half a year ago I got the impression that there exist a few pretty good ROMs from TV box vendors.
<tkaiser> TheLinuxBug: That should work on all H3 devices... but know that I thought about it again: Most probably neither Wi-Fi nor (Gbit) Ethernet will be working since the aging Android kernel neither supports the new 8189FTV chip and external GbE PHY (the latter to be confirmed)
paulk-nyan-big has joined #linux-sunxi
mossroy has quit [Quit: Quitte]
<TheLinuxBug> yeah thats probably likely, tbh if I had more time for the project overall (which I think I have expired my current time for that) I would probably get the SDK and try to build my own kernel etc. Unfortunately I just don't have the time for it atm, so was kinda hoping for something exitent to work. Obviously the board works well with Arbian, can Igor and the people who work on that are #1 in my book ;p but unfortunately...
<TheLinuxBug> there does not exist an equally good team of people making a decent Android dist
<TheLinuxBug> existent*
<TheLinuxBug> Armbian (eesh the spelling mistakes are just rolling off my fingers today)
tkaiser has quit [Ping timeout: 250 seconds]
mosterta has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
tkaiser has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 244 seconds]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
reinforce has quit [Quit: Leaving.]
Gerwin_J has joined #linux-sunxi
piotaras has joined #linux-sunxi
<piotaras> Hi everyone
Mr__Anderson has quit [Remote host closed the connection]
paulk-nyan-big has quit [Quit: Leaving]
Shirasaka-Hazumi has quit [Ping timeout: 258 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
Shirasaka-Hazumi has quit [Ping timeout: 272 seconds]
jstein has quit [Remote host closed the connection]
Shirasaka-Hazumi has joined #linux-sunxi
Macer has quit [Ping timeout: 252 seconds]
lemonzest has quit [Quit: Leaving]
nove has quit [Quit: nove]
Macer has joined #linux-sunxi
piotaras has quit [Quit: Page closed]
piotaras has joined #linux-sunxi
piotaras has quit [Remote host closed the connection]
indy has quit [Ping timeout: 244 seconds]
indy has joined #linux-sunxi
<lennyraposo> hey longsleep
<lennyraposo> are you about mate
tlwoerner has quit [Ping timeout: 240 seconds]
<lennyraposo> ssvb are you about?
<ssvb> lennyraposo: yes, somehow
<lennyraposo> ya
<lennyraposo> allwinner is messed up
<lennyraposo> here is amessage I just got from them through tllim
<lennyraposo> Allwinner current working on 64 Mali driver for us and there encounter an issue as follow due to current system don't have xorg. They need to compile an xorg with backtrace open. Thanks on the assistance.
<lennyraposo> [   880.946] (EE) 
<lennyraposo> [   880.946] (EE) Backtrace:
<lennyraposo> [   880.947] (EE) 
<lennyraposo> [   880.947] (EE) 0: /usr/bin/X (xorg_backtrace+0x5c) [0x55909ca75c]
<lennyraposo> [   880.947] (EE) Bus error at address 0x7f7875600c
<lennyraposo> [   880.947] (EE) 
<lennyraposo> Fatal server error:
<lennyraposo> [   880.947] (EE) Caught signal 7 (Bus error). Server aborting
<lennyraposo> [   880.947] (EE) 
<lennyraposo> [   880.947] (EE) 
<lennyraposo> all they need is the xorg dbg packages
<lennyraposo> or am I missing something?
paulk-nyan-big has joined #linux-sunxi
<ssvb> lennyraposo: yes, it looks like they have just have not installed some dbg packages
<lennyraposo> ok so I am not crazy
<lennyraposo> lol
<lennyraposo> good
<lennyraposo> perhaps I should forward how they can do it ;)
<ssvb> lennyraposo: maybe they are just looking for an excuse to delay the mali blob delivery yet again?
<lennyraposo> I think so
<lennyraposo> they have both the ubuntu and debian images from myself and longsleep
<lennyraposo> and I know both work as they should
ganbold has joined #linux-sunxi
fdcx has quit [Ping timeout: 276 seconds]
mosterta has quit [Ping timeout: 250 seconds]
fdcx has joined #linux-sunxi