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
popolon has quit [Quit: WeeChat 1.4]
cptG has quit [Ping timeout: 252 seconds]
whaf has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ornitorrincos has quit [Quit: ZNC 1.6.3 - http://znc.in]
ornitorrincos has joined #linux-sunxi
ornitorrincos has joined #linux-sunxi
ornitorrincos has quit [Changing host]
laj has joined #linux-sunxi
dh1tw has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mattwj2002 has joined #linux-sunxi
mattwj2002 has left #linux-sunxi [#linux-sunxi]
station has quit [Ping timeout: 250 seconds]
vagrantc has quit [Quit: leaving]
station has joined #linux-sunxi
kaspter has joined #linux-sunxi
Colani1210 has joined #linux-sunxi
Colani1200 has quit [Ping timeout: 265 seconds]
tsuggs has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-sunxi
<wens> mripard: vblank timeout for fbcon on my a23 tablet: https://wens.tw/drm-a23.txt
yann-kaelig has quit [Quit: Leaving]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<AneoX> Please, help! ( My board with A20 soc, sunxi-kernel, successfully boots from SD card. But when solder emmc, u-boot boots well, 52mhz 4bit, but kernel stucks with mmc0: error -110 whilst initialising MMC card. Kernel doesnt try to switch freq and bus width, strange. http://pastebin.com/9L9YYPfv Please, help!
<AneoX> I have tried with marsboard, solder emmc to sdc0 lines, and it works, with same u-boot and kernel. Works well, switch freq and bus width to 52mhz and 4-bit
<AneoX> my board boots SD at 50mhz, but problem with emmc.
dr1337 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dr1337 has joined #linux-sunxi
ninolein has quit [Ping timeout: 260 seconds]
ninolein has joined #linux-sunxi
dr1337 has quit [Ping timeout: 265 seconds]
robogoat has quit [Ping timeout: 250 seconds]
_whitelogger has joined #linux-sunxi
bugzc has quit [Read error: Connection reset by peer]
bugzc has joined #linux-sunxi
<MoeIcenowy> wens: when you get the issue is earlier than me
<MoeIcenowy> is your fbcon ok?
<MoeIcenowy> mripard: https://pastebin.anthonos.org/view/91768eb9 a full dmesg
<MoeIcenowy> what I did is systemctl start lightdm, then touch another point, then systemctl restart lightdm (the bug is triggered), then systemctl stop lightdm (the panel got blank, the backlight is even shutdown)
kaspter has quit [Remote host closed the connection]
p_rossak_ has joined #linux-sunxi
p_rossak has quit [Ping timeout: 244 seconds]
pg12 has quit [Ping timeout: 244 seconds]
pg12 has joined #linux-sunxi
jrg has quit [Ping timeout: 260 seconds]
jrg has joined #linux-sunxi
jrg has quit [Ping timeout: 260 seconds]
jrg has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
leviathanch has joined #linux-sunxi
clonak_ has joined #linux-sunxi
clonak has quit [Ping timeout: 240 seconds]
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
laj has quit [Quit: Page closed]
Gerwin_J has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
avph has quit [Ping timeout: 250 seconds]
reinforce has joined #linux-sunxi
merbanan has quit [Ping timeout: 244 seconds]
avph has joined #linux-sunxi
alexxy has joined #linux-sunxi
merbanan has joined #linux-sunxi
chomwitt has quit [Ping timeout: 268 seconds]
leviathanch has quit [Remote host closed the connection]
iamfrankenstein has joined #linux-sunxi
<wens> MoeIcenowy: no, it's dead
f0xx has joined #linux-sunxi
stk is now known as stk_py
stk_py is now known as stk
cnxsoft has quit [Ping timeout: 252 seconds]
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe71rus has joined #linux-sunxi
JohnDoe71rus has quit [Client Quit]
JohnDoe_71Rus has joined #linux-sunxi
ikmaak has quit [Ping timeout: 260 seconds]
ikmaak has joined #linux-sunxi
DullTube has joined #linux-sunxi
nixdork has quit [Quit: EliteBNC free bnc service - http://elitebnc.org/]
nixdork has joined #linux-sunxi
yann has quit [Ping timeout: 260 seconds]
<MoeIcenowy> wens: do you have any idea on this?
petr has quit [Ping timeout: 250 seconds]
petr has joined #linux-sunxi
massi has joined #linux-sunxi
<mripard> wens: MoeIcenowy: those seem to be different bugs
<jemk> tb
<mripard> wens: I think you're simply not getting any interrupts from the TCON
eduardas_m has joined #linux-sunxi
<mripard> MoeIcenowy: and it seems like yours is that you don't get any interrupts when you re-enable the pipeline
Putti has quit [Ping timeout: 260 seconds]
<wens> mripard: yup, /proc/interrupts shows 0 for tcon
<wens> but the interrupt number in the DT is correct
<wens> i might have to park this as i don't have the time to dig into it
<wens> really hope it's not broken hardware :/
jrg has quit [Ping timeout: 250 seconds]
<MoeIcenowy> mripard: another issue, if I shut down X, the tcon is shut down, but I still need the fb for fbcon
jrg has joined #linux-sunxi
<mripard> wens: I don't know :/ or the interrupt setup is a bit different on the A23
<mripard> but I don't think it is
<mripard> MoeIcenowy: that's weird, that definitely used to work
<mripard> you probably want to look at the commits in the fbdev emulation layer
<mripard> they tend to merge weird changes like that on a regular basis
<MoeIcenowy> maybe weird changes are from me :-(
<MoeIcenowy> I'm trying A33 GPU, and it works
kido has quit [Ping timeout: 250 seconds]
jrg has quit [Ping timeout: 265 seconds]
<MoeIcenowy> and some bonus commits by net147 may hurt the work (they're for fbdev, as he has a r3p2 port to current mainline...)
<mripard> the A33 GPU works with NTC's blob and the driver I host
<MoeIcenowy> mripard: yes, but I used the driver hosted by Net147
<MoeIcenowy> I got it running
<MoeIcenowy> but NTC's blob seems to be a MP1 blob...
jrg has joined #linux-sunxi
<MoeIcenowy> will NTC do any R16 boards?
<mripard> MoeIcenowy: afaik the blobs are the same
<MoeIcenowy> but in es2info the return is Mali-400 MP, not Mali-400 MP2
<MoeIcenowy> afaik MP2 blob can suit MP1, but MP1 blob can only make use of one core of MP2
gianMOD has joined #linux-sunxi
tkaiser has joined #linux-sunxi
yann has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<MoeIcenowy> mripard: did you find my fbcon shutdown issue in my dmesg?
<MoeIcenowy> (it's trigger in the dmesg
<MoeIcenowy> about line 3150 (of course I mean the full version)
bugzc has quit [Ping timeout: 260 seconds]
Leepty has joined #linux-sunxi
maz has joined #linux-sunxi
<mripard> I don't have that line, it stops at 3478
<MoeIcenowy> I mean https://pastebin.anthonos.org/view/91768eb9 this one
<MoeIcenowy> oh seems that I made something wrong sorry
<MoeIcenowy> oh I didn't make faults, it's because the line number cannot be searched in the browser
<MoeIcenowy> 3150 is less than 3748 :-)
<MoeIcenowy> mripard: the fbcon lost issue seems to be related to your armsoc ddx fork
<MoeIcenowy> use modesetting can prevent it
<MoeIcenowy> (but the screen still hang because of the first bug (vblank int one)
yann has quit [Ping timeout: 244 seconds]
<mripard> MoeIcenowy: without the hardware and patches, I can't really help you but give you directions and ideas
<mripard> and there's really something that seems to be wrong when you re-enable the interrupts, as you don't seem to get any once you restart it
leio has quit [Ping timeout: 250 seconds]
Putti has joined #linux-sunxi
gianMOD has quit [Read error: No route to host]
gianMOD has joined #linux-sunxi
yann has joined #linux-sunxi
apritzel has joined #linux-sunxi
florianH has joined #linux-sunxi
p_rossak_ has quit [Remote host closed the connection]
p_rossak has joined #linux-sunxi
<apritzel> NiteHawk: ssvb: How do I read the SoC ID (not SID)? I see that sunxi-fel uses a FEL command for that, but how do I read it from firmware?
<apritzel> is there a register in some (undocumented) SRAM registers?
<wens> apritzel: see sunxi_get_sram_id() in u-boot's arch/arm/mach-sunxi/cpu_info.c
<wens> I think there's a wiki page too, but i can't remember the page name
Worf has joined #linux-sunxi
<apritzel> wens: thanks! that looks promising ...
<apritzel> I need to differentiate the A64 from the H5, naive /me hopes that they sport a different SoC ID ...
<wens> the register isn't "undocumented", just not so obvious
<wens> you could also look for some pattern in the SID e-fuses
<apritzel> wens: yeah, that was plan B, indeed it looks like the first bits are the same for a SoC
<apritzel> but this SoC ID seems to be used for that purpose, so I'd prefer that
<wens> hehe, as i said, not so obvious
Worf_ has joined #linux-sunxi
Worf has quit [Read error: Connection reset by peer]
<NiteHawk> apritzel: you might also want to have a look at the soc family detection code in https://github.com/linux-sunxi/sunxi-tools/blob/master/uart0-helloworld-sdboot.c
popolon has joined #linux-sunxi
<NiteHawk> apritzel: sunxi-fel get's its "SoC ID" as part of BROM version information, which is kind of a "black box" reply to a specific FEL request (AW_FEL_VERSION)
<apritzel> NiteHawk: I saw that FEL request command, yes
matthias_bgg_ has joined #linux-sunxi
Putti has quit [Ping timeout: 260 seconds]
<apritzel> jemk: as, thanks for the link
<apritzel> jemk: I found that register in the A64 manual, but it's pretty silent about the upper bits
matthias_bgg_ has quit [Client Quit]
<montjoie> wens: I have already the patch you said:(
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
leio has joined #linux-sunxi
<wens> as both mripard and i mentioned, it should not be possible for the device to be removed
<wens> maybe it's a bug in the test :|
gianMOD has quit [Ping timeout: 244 seconds]
<montjoie> certainly
<montjoie> I will try a patch
gianMOD has joined #linux-sunxi
<Net147> mripard: is it expected that the mouse cursor lags with xf86-video-armsoc due to drmModeSetPlane blocking until vblank?
<montjoie> mripard: wens what do you think about https://paste.pound-python.org/show/1lWrrBfhg00Zoy07sydl/
paulk-minnie has joined #linux-sunxi
scream has joined #linux-sunxi
<tkaiser> apritzel: Good news, H5 SDK is somehow released
<apritzel> tkaiser: as some huge code drop tarball? With a user manual?
<paulk-minnie> how many GPL violations?
<tkaiser> apritzel: Sure, it's a splitted .gz archive +7 GB in size and currently it sits somewhere on Baidu. Fortunately zoobab offered help so with some luck it will be available below filez.zoobab.com tomorrow.
<tkaiser> Contents unknown yet, we'll see tomorrow ;)
<tkaiser> I didn't even try to download, got mad yesterday trying to get a 200 MB file from Baidu. BTW: 'H2 SDK' is 5GB in size
<apritzel> tkaiser: I guess we'll be quicker then by assuming that's an A64 with two more USB controllers and no AXP PMIC
<apritzel> tkaiser: size matters !!!1!1!
<tkaiser> apritzel: ;) Yeah, I also believe H5 should be somewhat similar to A64 with improvements regarding USB ports, GPU and video engine. At least that's my hope and I also hope that the majority of these 7 GB are just a smelly Android 5.1
paulk-minnie has quit [Ping timeout: 265 seconds]
<tkaiser> Or maybe Android 5.1 + 6.0 -- whatever. BTW: Another comment scared me almost more: https://github.com/tinalinux/linux-3.4/issues/1#issuecomment-257210599
<tkaiser> Different Allwinner business units, different code drop styles. At least is 'Team Tina' already on Github
paulk-minnie has joined #linux-sunxi
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #linux-sunxi
lkcl has joined #linux-sunxi
paulk-minnie has quit [Ping timeout: 250 seconds]
avph has quit [Ping timeout: 260 seconds]
alexxy has quit [Ping timeout: 252 seconds]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
alexxy has joined #linux-sunxi
avph has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<miasma> does the sdk come with all build tools or why is it so big
<apritzel> miasma: not only that, some also contain the object files ;-)
<miasma> oh dear
Putti has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
gianMOD has joined #linux-sunxi
mzki has joined #linux-sunxi
<zoobab> @apritzel could you test my pine64.img with TFTPboot support?
AneoX has quit [Ping timeout: 260 seconds]
The_Loko has joined #linux-sunxi
Worf_ is now known as Worf
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
chomwitt has joined #linux-sunxi
<apritzel> zoobab: will do tonight. Does it work for you?
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
<apritzel> oh, NiteHawk, btw: have you considered looking for "arm-*-gcc" in all $PATH directories to find an ARM cross compiler?
<apritzel> NiteHawk: I hacked up a quick shell script yesterday, that worked like a charm
<wens> miasma: it's probably an android drop, those are really big
<apritzel> NiteHawk: something like IFS=:; for path in $PATH; do [ $(ls $path/arm-*-gcc 2>/dev/null | wc -l) -eq 0 ] && continue; echo $path/arm-*-gcc; done
DullTube has quit [Quit: Leaving]
<miasma> wens: my whole distro + all development tools for numerous languages is less than 4 GB (xz compressed) :)
<miasma> but i only develop with c,c++,java,scala,haskell,python
cnxsoft has quit [Quit: cnxsoft]
<wens> miasma: does that include the .git directories?
<beeble> miasma: a full mirror of aosp is about 107gb
<wens> aosp is crazy big :/
<beeble> this includes brillo and stuff. so "pure" android is smaller
<beeble> but still about 60 iirc
<NiteHawk> apritzel: interesting concept. my current line of thought was revolving around "autoconf", since i reckon that the 'static' makefile / shell script approaches might reach their limits - e.g. when testing for the presence of os-specific header files, etc.
<apritzel> NiteHawk: autoconf sounds good, but creates its own set of problems, I guess
<apritzel> NiteHawk: also won't help you with this particular issue
<NiteHawk> apritzel: it does, to a limited degree - as long as we can avoid automake (that's where insanity lurks) :D
<NiteHawk> apritzel: it would help with a reasonable set of defaults (i.e. toolchain prefixes). if that fails, the user could still use the standard override that "./configure --host=..." offers
<apritzel> NiteHawk: but the autotools cross semantics is different here, since it applies to the application you are about to compile
<NiteHawk> nevertheless, that arm-*-gcc search is a neat idea. i'll keep that in mind :)
<apritzel> NiteHawk: If I got this correctly, you want to cross compile the ARM snippets that get downloaded to the board, right?
<apritzel> but sunxi-fel (for instance) would still be a x86 binary, for instance
<NiteHawk> apritzel: right. that's why we distinguish "tools" and "target-tools" (with autotools introducing yet another, subtly different concept of "--target" :P)
<apritzel> mmh, isn't --target meant for compilers only? Using it for this purpose is a bit of a stretch then, I think ...
<NiteHawk> yes, they have this slightly "weird" concept of a 'canadian' toolchain, where you would (cross-build) a compiler that runs on a "--host" different from your "--build" machine, and produces binaries for yet another "--target" architecture
<NiteHawk> so i figured we'd stick with "--build" (-> tools) and "--host" (-> target-tools) terminology
<NiteHawk> most users would only want "tools" (or possibly "misc") anyway, which means no cross-compiling gets involved. we also can't rely on the presence of a suitable cross-compiler (e.g. for the CI tests)
<deskwizard> I'm sorry to bother you guys, I just aint sure of the answer, and before I dive into the deep end, I want to know if its pointless... No LVDS love with mainline for A20, right?
afaerber has quit [Quit: Ex-Chat]
IgorPec has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
<apritzel> NiteHawk: this canadian toolchain is actually useful: I bootstrapped the ("native") Slackware compilers for aarch64 with this ;-)
scream has quit [Remote host closed the connection]
<apritzel> NiteHawk: so you have --build=x86 --host=aarch64 --target=aarch64
afaerber has joined #linux-sunxi
lkcl has joined #linux-sunxi
afaerber has quit [Ping timeout: 260 seconds]
afaerber has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
Worf has quit [Quit: Konversation terminated!]
whaf has quit [Read error: Connection reset by peer]
whaf has joined #linux-sunxi
eduardas_m has quit [Ping timeout: 260 seconds]
eduardas_m has joined #linux-sunxi
<miasma> wens: no, of course not
florianH has quit [Ping timeout: 250 seconds]
steev has quit [Ping timeout: 250 seconds]
lvrp16 has quit [Ping timeout: 250 seconds]
ojn has quit [Ping timeout: 250 seconds]
Tartarus has quit [Ping timeout: 250 seconds]
doppo has quit [Ping timeout: 250 seconds]
afaerber has quit [Ping timeout: 250 seconds]
zerotri has quit [Ping timeout: 250 seconds]
havoc_ has quit [Ping timeout: 250 seconds]
longsleep has quit [Ping timeout: 250 seconds]
longsleep has joined #linux-sunxi
steev has joined #linux-sunxi
zerotri has joined #linux-sunxi
Tartarus has joined #linux-sunxi
ojn has joined #linux-sunxi
florianH has joined #linux-sunxi
doppo has joined #linux-sunxi
lvrp16 has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
afaerber has joined #linux-sunxi
havoc_ has joined #linux-sunxi
bamvor has quit [Ping timeout: 260 seconds]
reinforce has joined #linux-sunxi
eduardas_m has quit [Ping timeout: 250 seconds]
bamvor has joined #linux-sunxi
<oliv3r> anybody familiar how u-boot hands the MAC address to a 3.4 based kernel?
<oliv3r> what i know/checked so far, u-boot creates a mac address and puts it in the environment. it also writes it to the GMAC_ADDR_HI and GMAC_ADDR_LO registers
<oliv3r> when doing a md and printenv in u-boot i see the correct values; but going to 3.4 linux on armbian, i'm getting something completly else. doing a devmem confirms these changed values
<alexvf> oliv3r: don't know if it is of much help but iirc gmac driver sets a random mac
<oliv3r> i think the gmac driver (in 3.4) sets the mac based on serial number
<oliv3r> alexvf: not entirely, but goo point
<oliv3r> i know we use that as a fallback in u-boot, generate mac based on serial
<oliv3r> but it's quite possible that 3.4 does that by default
<oliv3r> [ 2.240076] gmac: use mac address from chipid
<oliv3r> there it is
<oliv3r> so i think 3.4 completly ignores mainline
<oliv3r> erm what u-boot tells it to do
<alexvf> i don't know, maybe it was done on purpose due to a buggy allwinner u-boot?
<oliv3r> i'm sure allwinner never even conciderd this use case :)
<oliv3r> but it's okay
<Wizzup> anyone seen ssvb recently?
<oliv3r> friday i thin
<Wizzup> I thought he was usually lways on (at least his irc client)
<oliv3r> true
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
jernej has joined #linux-sunxi
<Wizzup> Anyway I spoke to olimex yesterday, about spi flash on the lime2, figured he'd be interested
<Wizzup> I'll see if I can email him
<apritzel> Wizzup: anything interesting on the SPI flash front?
* apritzel wonders if someone makes a small plug-type SPI flash gadget to put on the Pine64 headers
<MoeIcenowy> apritzel: Pine64 headers are not generic at all
<MoeIcenowy> but maybe there some vendors produce SPI flash with 2.54" pins that can be directly wired without soldering
<MoeIcenowy> I must honestly admit that I cannot do soldering :-(
<apritzel> MoeIcenowy: the "Pi2 headers" are the same across most boards, especially in respect to the SPI pins
<oliv3r> tkaizer what kernel are you using with armbian?
<MoeIcenowy> Is the bootable SPI on the headers?
<apritzel> MoeIcenowy: try it, it's not hard, lots of tutorials out there
<apritzel> MoeIcenowy: yes, at least on the Pine64
<oliv3r> tkaizer or rather, where are the kernel sources for armbian's 3.4.112-sun7i
<MoeIcenowy> hooary :-) I will try to search one on taobao
<apritzel> MoeIcenowy: not on every Allwinner board, though, some expose SPI1
<apritzel> this has 2.5mm solder pads, I soldered some headers on it and connected wires to the respective pins on the Pine64
<apritzel> works like a charm
<MoeIcenowy> apritzel: recently, I bought a case of arduino accessories to use on my sunxi boards :-)
yann has quit [Ping timeout: 250 seconds]
<MoeIcenowy> (Most of them uses SPI or I2C
<MoeIcenowy> on taobao even the kind of SPI Flash board of Arduino is even difficult to be found :-(
tkaiser has joined #linux-sunxi
<beeble> MoeIcenowy: where do you live? I should have some soic 8 adapters laying around and a box full of nor flash
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy> beeble: Canton.
<beeble> so if shipping doesn't kill me i send you one
<MoeIcenowy> beeble: not needed
<MoeIcenowy> I found the taobao link of the LC Flsah Memory Module
<beeble> ok
<MoeIcenowy> apritzel: do you want to make a "BIOS" for Pine64? :-)
<apritzel> MoeIcenowy: yes, that's the plan
<apritzel> (minus the bad things of BIOSes, of course)
<apritzel> like being closed source and possibly stealing CPU cycles
premoboss has joined #linux-sunxi
deskwizard_ has joined #linux-sunxi
<MoeIcenowy> apritzel: no such RPi SPI Flash modules
gianMOD has quit [Ping timeout: 256 seconds]
<apritzel> not sure they can boot from SPI flash (I don't think so)
<MoeIcenowy> Yes
<MoeIcenowy> so no reason to make such modules
<apritzel> TLLim could make some
<apritzel> or add a SPI flash to some accessory module
<MoeIcenowy> but maybe some linux-sunxi related vendors can make "Allwinner development boards BIOS modules"
deskwizard has quit [Quit: Leaving]
deskwizard_ has quit [Client Quit]
<apritzel> Olimex seems to do those kind of things, even if there isn't a big market
matthias_bgg has quit [Quit: Leaving]
deskwizard has joined #linux-sunxi
<beeble> or just have the spi flash by default on board *lazyselfpromotion*
deskwizard has quit [Client Quit]
<apritzel> beeble: of course this is the best solution
<MoeIcenowy> maybe we can try to persue someone for such a market ;-)
<MoeIcenowy> First we should first sort out boards with SPI0 on GPIO headers
<apritzel> MoeIcenowy: OrangePi did it for their recent H5 board (in case you missed that)
<MoeIcenowy> when will them be for sale
deskwizard has joined #linux-sunxi
<apritzel> now
<apritzel> MoeIcenowy: where have you been on Friday?
<apritzel> ;-)
<MoeIcenowy> Friday... forgot to start pidgin
<MoeIcenowy> you know, I use ZNC
<MoeIcenowy> oh I see the H5 board!
<MoeIcenowy> "The drunk board"
<apritzel> indeed ;-)
<MoeIcenowy> on PC2 there's a SPI?
<MoeIcenowy> s/SPI/& Flash/
<apritzel> MoeIcenowy: yes, 8 Mbit = 1 MB
<MoeIcenowy> What can be placed in 1MB?
<MoeIcenowy> I think the answer is a U-Boot with a bootmenu
<apritzel> SPL, ATF, U-Boot
<apritzel> and ... a DT !!11!!1
<apritzel> also UEFI variables
<apritzel> that's where it gets really useful
<MoeIcenowy> do U-Boot support UEFI variables now?
<apritzel> not yet, I think
<apritzel> but you just need to annoy agraf, I guess ;-)
<MoeIcenowy> For my last trial, the answer is no
<apritzel> MoeIcenowy: also ssvb wanted to have some test apps or some menus in there
<MoeIcenowy> For a U-Boot attached boot menu
<apritzel> so that people see something when they just power on the board
<MoeIcenowy> my Nokia N900's U-Boot have one
<MoeIcenowy> it can choose where to load the kernel (NAND, eMMC, SD Card)
<apritzel> also it could do some OTG service (DFU, fastboot, mass-storage) or TFTP boot
<apritzel> so you could just connect Ethernet and power and boot that sucker
<MoeIcenowy> sounds good
<MoeIcenowy> but only for boards without eMMC ;-)
<MoeIcenowy> eMMC ones will not boot SPI Flash until the eMMC's boot0 is broken
<apritzel> if you don't write the eGON magic on the eMMC
<apritzel> "broken" could here just mean: has never been written
<apritzel> same with SD card, just format a normal SD card and it would still boot from SPI flash
<apritzel> but you can always override this with a "magic" SD card
<apritzel> for instance to update the SPI flash
<MoeIcenowy> oh H2+ ones also online!
<MoeIcenowy> buy, buy, buy! :-)
<MoeIcenowy> This Icenowy started to burn her debit card before the Chinese "11.11" start :-)
<MoeIcenowy> OPi Zero seems to have a SOIC8 pad... maybe also prepared for a SPI NOR?
<MoeIcenowy> zoobab: ping, can you get H2+ SDK?
<NiteHawk> apritzel: find `echo $PATH | sed -e 's/:/ /g'` -executable -name 'arm*-gcc'
<apritzel> NiteHawk: that's what I love about UNIX: n people find at least n+1 ways to solve an issue ;-)
<MoeIcenowy> my one debit card refused to pay the bill as the amount it not enough :-)
<NiteHawk> apritzel: ;)
<apritzel> MoeIcenowy: lol
<MoeIcenowy> apritzel: can I use your such sentence somewhere else
<tkaiser> MoeIcenowy: The H2+ SDK is BS :) Same with H5 one
<MoeIcenowy> So I can use the SDK to build both H2+ and H5?
jstein_ has joined #linux-sunxi
<tkaiser> Zero chip documentation. One large android dir and one large lichee dir. In case of H5 seems even more outdated than the stuff available on Github
<tkaiser> MoeIcenowy: No, separate tarballs.
<MoeIcenowy> H5 tarballs are available?
<tkaiser> Yeah, we got two Baidu links this morning. I'm not professional 'Baidu from Europe downloader' and got close to 5 MB/s in the end ;)
<tkaiser> s/not/now/
<MoeIcenowy> tkaiser: could you please post the links?
<MoeIcenowy> I'm in China :-)
jstein_ is now known as jstein
<MoeIcenowy> only H5 board seems to be on sale is PC2, and only H2+ board is Zero ...
<tkaiser> MoeIcenowy: Check your gmail account (still don't know whether we are allowed to post this stuff publicly)
iamfrankenstein has quit [Quit: iamfrankenstein]
vagrantc has joined #linux-sunxi
<MoeIcenowy> Got it
<tkaiser> But anyway: H2+ mirror is here http://filez.zoobab.com/allwinner/sdk/h2/201609022/ (but it seems only stuff of interest is firmware blobs and driver for Allwinner's Wi-Fi module used on OPi Zero)
deskwizard has quit [Remote host closed the connection]
<MoeIcenowy> Oh Allwinner now produces Wi-Fi module...
<MoeIcenowy> Interesting
<MoeIcenowy> tkaiser: your 5MB/s score is much better than me :-)
deskwizard has joined #linux-sunxi
<tkaiser> MoeIcenowy: I used a downloader with 10 parallel sessions. Regarding Wi-Fi: http://certifications.prod.wi-fi.org/pdf/certificate/public/download?cid=WFA61880
<MoeIcenowy> any one here got really a H2/H5 board?
bugzc has joined #linux-sunxi
<MoeIcenowy> Without any problems I can get mine in Nov 9 around 11:00 am in UTC+8
<tkaiser> MoeIcenowy: Seems Steven shipped some of the out on Friday. At least Igor reported he got already a DHL notification. So he should hold both in his hands tomorrow.
deskwizard has quit [Client Quit]
<MoeIcenowy> but I think Yuantong Express from Shenzhen to Canton can beat all the logistics services to pass the customs :-)
mrnuke has quit [Ping timeout: 245 seconds]
chomwitt has quit [Ping timeout: 260 seconds]
<miasma> MoeIcenowy: btw if you can't solder spi, there are some sockets for spi chips that can be connected to gpio with dupont wires, iirc
<miasma> not pretty but handy for prototyping
JohnDoe_71Rus has quit [Ping timeout: 252 seconds]
JohnDoe_71Rus has joined #linux-sunxi
deskwizard has joined #linux-sunxi
<IgorPec> tkaiser: so H2+ stuff is pointless to download ?
<tkaiser> IgorPec: According to zoobab it's only 4.9GB 'android': http://filez.zoobab.com/allwinner/h2/201609022/
<IgorPec> oh. what about wifi driver / fw ?
<tkaiser> IgorPec: According to Jernej included. Obviously I've no idea about the contents :)
<tkaiser> H5 download is 14GB 'android' and 3.2 GB 'lichee' containing 3.10.65 kernel sources
yann-kaelig has quit [Quit: Leaving]
<IgorPec> got it ... i'll take a look later on.
<tkaiser> IgorPec: Allwinner firmware blob contained in Broadcom directory: http://filez.zoobab.com/allwinner/h2/201609022/android/hardware/broadcom/wlan/bcmdhd/firmware/
<tkaiser> everything as expected ;)
kaspter has joined #linux-sunxi
<IgorPec> :) yes.
<MoeIcenowy> H2+ has only Android SDK...
<miasma> tkaiser: btw how did you find out the pinouts here https://linux-sunxi.org/Xunlong_Orange_Pi_2 -- i can't figure out how the schematics describe the connections between cpu pins and gpio pins.
<miasma> oops, it was codekipper's edit :)
<tkaiser> miasma: Yes, I'm as good in reading schematics as with soldering: pretty bad
<miasma> ok :)
<miasma> well someone more experienced can fix the tables I added some day :)
<MoeIcenowy> apritzel: I checked the pinout of opi2 gpio, and found also SPI0 exported
alexvf has quit [Quit: Page closed]
zerotri has quit [Ping timeout: 260 seconds]
vagrantc has quit [Quit: leaving]
apritzel has quit [Ping timeout: 250 seconds]
iamfrankenstein has joined #linux-sunxi
f0xx has quit [Ping timeout: 244 seconds]
zerotri has joined #linux-sunxi
<KotCzarny> hmm, is it possible to have named colors in wiki? ie. unsupported = black;
<NiteHawk> KotCzarny: what context - for formatting via CSS (<div> / <span>)?
<KotCzarny> in wiki table
<KotCzarny> right now in linux mainlining effort for example "background: yellow;"
<KotCzarny> wouldnt it be meaningful to have background: support-impossible; etc?
kaspter has quit [Ping timeout: 256 seconds]
<NiteHawk> i'll have to look into that - haven't done much table-formatting in wiki so far, i think there are some templates that were meant to address specific table's formatting
<MoeIcenowy> oh yes the SOIC8 pad behind Orange Pi Zero is *really* SPI Flash slot
<NiteHawk> KotCzarny: "background: yellow;" looks pretty much standard HTML - there's a set of predefined color names
<tkaiser> MoeIcenowy: Did you spotted schematics in our wiki already? :)
<MoeIcenowy> ?
<MoeIcenowy> no
<MoeIcenowy> I know this by see the official description to the pad - "Spi Flash (optional)"
leviathanch has joined #linux-sunxi
<tkaiser> ;)
<Wizzup> but can it boot from it?
<tkaiser> Wizzup: That's the only reason it's there.
<Wizzup> I'd hope so
<MoeIcenowy> tkaiser: agree
<KotCzarny> or some secret non volatile storage
<Wizzup> tkaiser: I am aware of that page, but not of the oraneg pi zero layout
<tkaiser> Wizzup: There's a wiki and there already schematics are linked/uploaded and there is written 'SPI NOR flash' ;)
<MoeIcenowy> But... How can Android work on such a board :-(
<Wizzup> tkaiser: :)
massi has quit [Quit: Leaving]
<tkaiser> MoeIcenowy: Do you really care about Android?
<KotCzarny> MoeIcenowy: its for spl+uboot, android doesnt have to know about it
<Wizzup> hopefully the new LIME2's will have it too
<MoeIcenowy> tkaiser: nope.
<MoeIcenowy> But it have only Android images now
premoboss has quit [Ping timeout: 256 seconds]
<tkaiser> MoeIcenowy: Nope, it has nothing. The Android image is for Orange Pi PC Plus
<KotCzarny> lol
<MoeIcenowy> They sold a board with zero support!
<tkaiser> MoeIcenowy: It's even called so
<KotCzarny> MoeIcenowy: otoh its first to the market ;)
<MoeIcenowy> Oh I got highly laugh at 02:51 am, and my roommates are now considering I as a fool :-)
<MoeIcenowy> but we can first implement sunxi-tools support for it
afaerber has quit [Quit: Ex-Chat]
<tkaiser> MoeIcenowy: I still hope that H2+ is just a stripped down H3. Even if I found in lichee/brandy/build.sh this: 'PLATFORM="sun8iw3p1"'
<MoeIcenowy> it have lichee brandy?
<MoeIcenowy> you told me that it have only android
<tkaiser> Yeah, wrong information, sorry
<MoeIcenowy> oh
<MoeIcenowy> maybe he's still uploading
<MoeIcenowy> if it's a sun8iw3p1 I will get glad :-)
<tkaiser> Should be finished, at least I downloaded the whole thing and let it now index on my laptop
<tkaiser> MoeIcenowy: That would be A23?!
<MoeIcenowy> w3p1 is A23.
<MoeIcenowy> yes
<MoeIcenowy> let's check the kernel drivers
<tkaiser> So let's hope it's w7p1 instead ;)
<MoeIcenowy> I'm checking the temperature driver
dh1tw has joined #linux-sunxi
<MoeIcenowy> I have hacked A23/33 thermal controller
<MoeIcenowy> oh it's the general driver
<MoeIcenowy> cannot got chip info from it
<MoeIcenowy> if it's a full unpack, it cannot be w3p1.
<MoeIcenowy> it may be w6/7/8
lkcl has quit [Ping timeout: 244 seconds]
<MoeIcenowy> as we know 6/7
<MoeIcenowy> it's 8.
<NiteHawk> KotCzarny: using wiki templates might be an option (at least to keep the styles consistent), so e.g. instead of 'style="background: black; color: white;" | support impossible' you'd write e.g. '{{status/unsupported|support impossible}}'
<KotCzarny> i might do it, assuming others deem it worthy
iamfrankenstein has quit [Ping timeout: 260 seconds]
stachhu has joined #linux-sunxi
yann has joined #linux-sunxi
<MoeIcenowy> http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/drivers/net/wireless/xradio/ oh seems that at least aw didn't try to close xradio driver
afaerber has joined #linux-sunxi
<NiteHawk> KotCzarny: if the wiki admins (Turl?) are willing to allow custom CSS (there's even a mediawiki extension i think), using specialized "style" names could become feasible too
|Jeroen| has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
<KotCzarny> isnt it binary blob?
<MoeIcenowy> yes
<MoeIcenowy> it is
<MoeIcenowy> what the f**k
<NiteHawk> libdram business as usual...
<MoeIcenowy> and seems that aw even got tired of embedding a HDMI controller in sun8iw8
<MoeIcenowy> but added a driver for the EP952 HDMI controller
lkcl has joined #linux-sunxi
<MoeIcenowy> (of course they're not related to Orange Pi 0
<MoeIcenowy> opi0 have only tvout
<MoeIcenowy> and I don't think it's a good interface for such IoT-targeted board's display
leviathanch has quit [Read error: Connection reset by peer]
<MoeIcenowy> but I found a good usage of opi0 -- solder a 16MB+ Flash on it, and then port an OpenWRT :-)
deskwizard has quit [Quit: Leaving]
lkcl has quit [Ping timeout: 260 seconds]
leviathanch has joined #linux-sunxi
<tkaiser> MoeIcenowy: There's a lot more to with this thingie. But anyway, there's still some hope that H2+ is just a crippled H3 (sharing same number) and 8iw8 is V3x instead: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1091
deskwizard has joined #linux-sunxi
deskwizard has quit [Client Quit]
deskwizard has joined #linux-sunxi
<MoeIcenowy> interesting will check it
<MoeIcenowy> maybe it's the reason for providing OPiPC image
<tkaiser> MoeIcenowy: Based on 'product brief' H2+ could be a H3 without Gbit Ethernet MAC and 4k display capabilities.
<MoeIcenowy> (in fact they're providing OPiPC image everywhere that can boot
mhlavink is now known as mhlavink_away
<MoeIcenowy> MoeIcenowy: I will get the SoC ID after getting the board
<MoeIcenowy> Oh I got silly... replied myself
<MoeIcenowy> If SoC ID say it's a H3 I will believe it's H3-
iamfrankenstein has quit [Read error: Connection reset by peer]
<tkaiser> jernej: Nice, different chipid but same family.
<MoeIcenowy> Nice
iamfrankenstein has joined #linux-sunxi
<MoeIcenowy> maybe mainline support can be bootstrapped very fastly
iamfrankenstein has quit [Read error: Connection reset by peer]
<tkaiser> If Igor is able to boot an usual H3 image tomorrow on OPi Zero we should know. Hardware seems to be not that different compared to NanoPi NEO.
lkcl has joined #linux-sunxi
<MoeIcenowy> tkaiser: I ordered a H3 now
<tkaiser> MoeIcenowy: H3? H2+?
<MoeIcenowy> H2+.
<MoeIcenowy> sorry
vagrantc has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dh1tw has joined #linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
leviathanch has quit [Remote host closed the connection]
montjoie has quit [Ping timeout: 252 seconds]
montjoie has joined #linux-sunxi
nove has joined #linux-sunxi
<nove> history is been rewritten => https://news.ycombinator.com/item?id=12893669
<nove> where it says the license issues circus was around the mali driver
<nove> that is new
Nyuutwo has quit [Ping timeout: 268 seconds]
<KotCzarny> isnt it pine64 era? whole mali for everything etc
<nove> KotCzarny: no, the circus was in september of 2014, and spring of 2015
<nove> it happened in our maillist, so everyone can see for themselfs the logs
dh1tw has quit [Write error: Broken pipe]
Nyuutwo has joined #linux-sunxi
<KotCzarny> people are stupid. always were, always will be. somehow human evolution favoured stupidity with brutality
jstein has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
vagrantc has quit [Quit: leaving]
netlynx has quit [Quit: Ex-Chat]
reinforce has quit [Quit: Leaving.]
<rellla> libv: congrats, best friend is back :p
iamfrankenstein has joined #linux-sunxi
<libv> rellla: it's truly amazing
<rellla> nove: i wonder, how you always find those links ;)
<libv> but the internet is like an american presidential election
<libv> campaign
<libv> just throw shit, some of it will always stick
mrnuke has joined #linux-sunxi
gianMOD has joined #linux-sunxi
iamfrankenstein has quit [Client Quit]
vagrantc has joined #linux-sunxi
<rellla> libv: I personally hope i gets wednesday soon. Though i'm not american...
<nove> rellla: this one was by chance
iamfrankenstein has joined #linux-sunxi
|Jeroen| has quit [Quit: dada]
AneoX has joined #linux-sunxi
<AneoX> Hi guys! Maybe somebody has interest. Changing CMD line pullup resistor from 10k(as mentioned in datasheet) to 8.2k, allow sunxi - kernel to boot properly from eMMC on A20
<AneoX> anybody knows, why i have error on modprobe mali (invalid argument), if enable debugfs in kernel hacking part of sunxi kernel config? Thx
<KotCzarny> is cma enabled?
<AneoX> no
<AneoX> should i enable cma only with debugfs or always?
<KotCzarny> if you want mali i guess
<KotCzarny> anyway, sleepy time
<AneoX> but mali worked fine without debugfs, anyway thx, i will try
IgorPec has quit [Ping timeout: 260 seconds]
<jrg> I haven't used my opi+2e lately. I should find something to do with it.
<jrg> too bad there isn't an openelec for it.
<jernej> jrg, how do you know that there isn't?
<jrg> oh my. lol.
<jrg> I'll have to take a look at that. wonder how well the IR would work. I know on a rpi I just had to wire up 3 gpio pins to an IR sensor to use my MCE remote.
<miasma> i wonder how the new mainline cec framework works with stuff like kodi
<tkaiser> jrg: And what's the problem? That you have to desolder the IR receiver on OPi Plus 2E first to wire up GPIO pins?
<jrg> no. not a problem. i used jumper wires for it.
<jrg> oh... i forgot.. opi+2e has its own ir receiver doesn't it?
<tkaiser> jrg: But there is IR already onboard? And jernej backported IR driver from mainline kernel since the one from Allwinner's BSP totally sucked.
<miasma> what's the problem with Xunlong Orange Pi Mini 2 - is it really still unsupported
<tkaiser> jrg: Sure, you deal here with a sunxi board and not Raspberries ;)
<jrg> yah i know. i just forgot the opi had an ir on it already heh... it has been collecting dust. it worked great as a shell box tbh.. i had a very nice setup on it.. but then i went back to using jails on fnas because i needed a bit more power
<miasma> yea
<miasma> is the page up to date
<tkaiser> miasma: Nope
<tkaiser> Should be merged with OPi 2 since the 'Mini 2' is 2 minus Wi-Fi
gianMOD has quit [Remote host closed the connection]
<tkaiser> Oh dear, the page for the 2 is also outdated like hell. Most of the pages for the more unpopular H3 devices suffer from this problem.
* vagrantc suspects the moment a page is up-to-date some new incompatible variant board with a confusingly similar name will be released
<tkaiser> miasma: An OPi 2 is more or less an OPi Plus minus eMMC and with Fast instead of GBit Ethernet.
apritzel has joined #linux-sunxi
<miasma> tkaiser: yea, i can probably infer that information from the boards' similarity although some kind of explicitly written bloodline of the devices would help :) i was thinking of cleaning up the wiki a bit, but i'm not sure what would be good.
<tkaiser> Ah, and also fortunately missing the crappy USB-to-SATA bridge!
<miasma> :)
<tkaiser> Maybe just redirecting the 'sunxi support' section to active wiki pages (OPi PC)?
<miasma> tkaiser, i was thinking of filling the this section https://linux-sunxi.org/H3#Mainline_status and referring to that from all h3 device pages
<tkaiser> miasma: IMO a good idea now that at least most Xunlong boards are already properly supported.
chomwitt has joined #linux-sunxi
<apritzel> uh oh, can someone confirm that the Orange Pi PC 2 (with the H5 and SPI NOR flash) lacks a FEL / U-Boot button?
<apritzel> the schematic shows one, but I can't find any on the pictures of the board
<apritzel> that is a bit nasty, since a messed SPI flash would deny FEL boot then
<apritzel> (unless one uses the FEL redirector on an SD card)
<jernej> apritzel: there is no uboot button even on the schematic, just a pull up
<jernej> resistor
<jernej> same goes for recovery button
<apritzel> jernej: oh right, was distracted by that "key" label
<apritzel> (and I shouldn'
<apritzel> t look at it at 125% only ;-)
<apritzel> jernej: so thanks for that heads up
<jernej> np :)
<apritzel> should I should dig out my SPL code to convert any GPIO into a "FEL button"
ssvb has joined #linux-sunxi
<ssvb> apritzel: hopefully with the http://lists.denx.de/pipermail/u-boot/2016-June/256723.html patch applied, the chances to mess up the bootloader in the SPI flash would be greatly reduced
<Wizzup> hiya
dh1tw has joined #linux-sunxi
<Wizzup> ssvb: I spoke with Olimex on sunday, and hope that I may have convinced them to do make another LIME2 version with SPI flash on a more accessible place
<ssvb> apritzel: but yes, if somebody messes it up nevertheless, some gymnastics with a special SD card would be required
avph has quit [Ping timeout: 260 seconds]
<apritzel> NiteHawk: ssvb: I can just confirm that reading the SoC ID on the A64 works as on the other SoCs: set bit 15 in 0x01c00024, then read it from the upper 16 bits
<ssvb> Wizzup: very nice, so there is still hope for A20 hardware too
<ssvb> apritzel: yes, we already know this
paulk-collins has quit [Quit: Leaving]
<Wizzup> ssvb: I really hope so :-)
<apritzel> ssvb: couldn't find anything about it, just the FEL request in sunxi-fel
<ssvb> A weird thing is that A80 uses a different address for this particular register, which kinda defeats the purpose
<ssvb> hopefully they will never make this mistake again
<apritzel> sounds like genuine AW ;-)
avph has joined #linux-sunxi
<apritzel> (only authentic with a little twist here and there)
<ssvb> apritzel: do you already have some H5 based board?
<apritzel> ssvb: not yet, but I figured I start looking at hacking ATF already ;-)
<apritzel> replace the RSB code with the respective SY8106 I2C routines
<apritzel> or rather not replace, but switch at runtime (based on the SoC ID, for instance)
<ssvb> can the ATF just get this information from the SPL?
<ssvb> I mean, you can't make decisions just based on the SoC type alone
<jrg> tkaiser: going to have to look at how to get this onto the opi+2e. wonder if anybody has had good results with openelec on it. will be interesting to try. if it works that would be awesome.
<apritzel> ssvb: AFAIK this is AWs intention: the A64 goes with the AXP803, the H5 without it
<ssvb> apritzel: if I understand it correctly, H5 is similar to H3
<ssvb> and H3 had two different types of CPU core voltage setup
<apritzel> ssvb: anyway: that's just a heuristic: eventually I see whether there is an AXP on the RSB or not
<ssvb> one based on I2C (a flexible voltage configuration) and another based on simple GPIO (just two voltage states)
<ssvb> Orange Pi PC vs. Orange Pi One
<apritzel> ssvb: and how would the SPL know? because it is configured for one SoC?
<ssvb> yes, we have the SPL header and it can contain some information
<ssvb> the dtb blob name (a unique board specific string identifier) is just one of them
<apritzel> I was wondering if just having one SPL for these very similar SoCs would be feasible
<apritzel> I expect the H5 being like the A64, just with two more USB host controllers and no AXP
<apritzel> and possibly other minor differences
AneoX has quit [Ping timeout: 260 seconds]
<ssvb> if we have some built-in storage space for the firmware, then the runtime detection is not necessary
<apritzel> would be interesting to see which MMC controller type they have, the A64 one or the H3 one
<apritzel> ssvb: true
<apritzel> but if those differences can be derived from the SoC ID, then even better, I think
<ssvb> the problem is that they can't
<ssvb> for example, the Pine64 and Pine64+ differentiation can be also done using just circumstantial evidences (the RAM size)
<apritzel> so we have one SPL (because USB and HS400 don't matter for that), then try to detect a board and select the right DT from the FIT
<ssvb> but none of these methods is universally reliable
<apritzel> true, but it doesn't need to be
<ssvb> we don't need to have one SPL
<apritzel> because we don't need to support every theoretical board, just the ones that we, well, support ;-)
<ssvb> it's just a single config file for U-Boot
<ssvb> somebody can easily make it for each board and confirm that it works
<apritzel> sure, I just want to try it anyway
<apritzel> because atm the only difference is in the DTs, which the SPL doesn't use anyways
<ssvb> about "detect a board and select the right DT from the FIT"
<ssvb> the http://lists.denx.de/pipermail/u-boot/2016-June/256723.html patch solves exactly this problem
<ssvb> you look at a special address in the SPL header and get the right dtb name from there
<ssvb> if there is no dtb name string, then you can resort to a guesswork
<apritzel> which requires that you have written it into the SPL at compile time, right?
<ssvb> yes
<ssvb> but you don't really need to do anything special, just compile U-Boot for the Orange Pi PC 2 board (use the right defconfig) and you will have this string there
<apritzel> well, I will give it a try anyway, if it turns out that it doesn't work, we just go back to your solution
<apritzel> ssvb: the problem is that atm I have two config files: one for 32-bit SPL, one for U-Boot proper
<apritzel> right know I can happily live with one SPL config
<ssvb> well, this needs to be improved to make it more user friendly
<apritzel> having two files for each board sounds a bit involved
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<ssvb> nah, we just need one
<vagrantc> the more boards that can boot with a single image the better, at least with my Debian hat on
<apritzel> ssvb: now that people seem to pick up that SPI flash idea, lets go on a new mission:
* vagrantc was happy to consolidate all wandboard variants into a single build
<apritzel> OTP ROM, flashed by the bo
<apritzel> _board_ vendor
<ssvb> yeah, I'm already on this mission since a while ago :)
<apritzel> ssvb: I see that your approach is really neat if the SPL would be stable (as in very rarely updated)
<ssvb> vagrantc: the idea is that the boards are already going to have a usable bootloader out of the box, and your debian image would not need to provide one in the long run
<apritzel> then it could just stay in the first 32KB of the SPI flash
<apritzel> ssvb: yeah, I really find it insane that _Linux distros_ provide firmware for random boards
<ssvb> vagrantc: debian does not ship PC BIOS updates to the end users on x86 hardware, or does it?
<apritzel> also it's not just Debian: agraf is one the same mission for SuSE, Fedora as well AFAIK
<apritzel> at the very least they shouldn't have separate efforts: there could be _one_ repository with Allwinner firmware, for instance
<apritzel> with source _and_ binaries, so that Jon Average can just download the right .bin file and flash it
The_Loko has quit [Quit: Leaving]
<apritzel> or download an SD image with all of them and the right one will be determined at runtime
<apritzel> ssvb: now it's time to post your patch link again :-p
<vagrantc> ssvb: if there's a viable PC BIOS update that's wholly free software, i don't see any fundamental reason why debian wouldn't/shouldn't ship it
<apritzel> vagrantc: still that's a bit against the idea of an OS, which runs on a variety of hardware without explicitly having to support each and every machine
<apritzel> vagrantc: that simply doesn't scale
<apritzel> it could be packaged for interested (read: paranoid) parties to rebuild and reflash
<vagrantc> apritzel: it's a scratch your itch scenario with debian
<ssvb> vagrantc: nobody forbids debian to ship the firmware, but the point is that the board manufacturer preferably should already have something pre-installed out of the box
<apritzel> but you wouldn't require it, instead you just rely on standard firmware interface to get you to a grub, for instance
<vagrantc> sure, that'd be ideal
<vagrantc> as long as the end-user has the choice of updating
cptG has joined #linux-sunxi
nove has quit [Ping timeout: 245 seconds]
<apritzel> vagrantc: sure, but that's a different issue
<vagrantc> in the meantime, there are a number of boards that don't include sufficient firmware to boot debian, and have free firmware available, that some crazy fool is willing to work on :)