<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>
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]
<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?
<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
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>
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 :-)
<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 ?
<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)"
<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]
<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
<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]
<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>
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
<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)?
<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>
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
<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 :)