<apritzel>
MoeIcenowy: eventually yes, but it has no hurry
wzyy2 has joined #linux-sunxi
xes has quit [Quit: WeeChat 1.6]
lkcl has quit [Ping timeout: 260 seconds]
xes has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 258 seconds]
<apritzel>
yeah, cpufreq works with SCPI now on the Pine64, anyone with known good operation points?
<MoeIcenowy>
fex ones are at least usable.
<lurchi__>
apritzel: github pointers to try?
<apritzel>
lurchi__: not yet, it just started to work ;-)
<lurchi__>
apritzel: thanks anyway, if you have somethink to test, ping me ;-)
<apritzel>
(after having wasted two hours without realising that even for 408 MHz 0.9V is too low)
<lurchi__>
;-)
<apritzel>
boy, this ondemand governor is really trigger happy
kaspter has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
vishnup has quit [Ping timeout: 268 seconds]
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 258 seconds]
<apritzel>
does anyone know where to best measure VDD-CPUX on the Pine64?
<beng83_Z2>
L2/L3 maybe should be good to locate
<beng83_Z2>
the pair of coils for dcdc2/3
<apritzel>
beng83_Z2: indeed ...
kaspter has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<apritzel>
beng83_Z2: thanks, that works and is easy enough to reach
<beng83_Z2>
I think its he pair next to he wifi
<apritzel>
beng83_Z2: yeah, found it, close to the pins 36/37 and 43/44
jailbox has quit [Ping timeout: 246 seconds]
<apritzel>
note to self: don't mix MHz and Hz in the code ;-)
sgteem has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
sgteem_ has quit [Ping timeout: 258 seconds]
ninolein has quit [Ping timeout: 264 seconds]
kaspter has joined #linux-sunxi
victhor has quit [Ping timeout: 246 seconds]
apritzel has quit [Quit: Leaving.]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<wens>
montjoie: maybe the multi queue patches just merged?
kaspter has quit [Remote host closed the connection]
Putti has quit [Ping timeout: 240 seconds]
Putti has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
reev has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
Putti has quit [Ping timeout: 240 seconds]
Putti has joined #linux-sunxi
pg12 has quit [Ping timeout: 264 seconds]
pg12_ has joined #linux-sunxi
jailbox has joined #linux-sunxi
specing has quit [Ping timeout: 240 seconds]
terra854 has joined #linux-sunxi
sunshavi has quit [Ping timeout: 240 seconds]
specing has joined #linux-sunxi
IgorPec has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
freemangordon has joined #linux-sunxi
<montjoie>
wens: certainly
<montjoie>
lol, breaked also on meson
<montjoie>
seems lack of testing
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 256 seconds]
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
foxx has joined #linux-sunxi
chlorine has quit [Ping timeout: 264 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
f0xx has joined #linux-sunxi
reinforce has joined #linux-sunxi
kaspter has joined #linux-sunxi
f0xx has quit [Ping timeout: 256 seconds]
<wens>
it's not the first time this has happened :|
<KotCzarny>
;)
muvlon has quit [Ping timeout: 258 seconds]
jernej has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has joined #linux-sunxi
muvlon has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 268 seconds]
DullTube has joined #linux-sunxi
lkcl has joined #linux-sunxi
IgorPec has joined #linux-sunxi
chlorine has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
chlorine has quit [Ping timeout: 258 seconds]
mcan_ has quit [Ping timeout: 264 seconds]
mcan has joined #linux-sunxi
florianH has joined #linux-sunxi
foxx has quit [Ping timeout: 260 seconds]
alex__ has joined #linux-sunxi
<alex__>
montjoie: sun7i-dwmac is also affected in linux-next. It freezes my cubietruck after a random time.
<alex__>
montjoie: does your bisect produce any result?
<montjoie>
need to start it to produce result:)
<montjoie>
I think I found the issue
massi has joined #linux-sunxi
maz has quit [Ping timeout: 256 seconds]
maz has joined #linux-sunxi
swiftgeek has quit [Ping timeout: 240 seconds]
engideavr has joined #linux-sunxi
chlorine has joined #linux-sunxi
<montjoie>
rx_queues_to_use/tx_queues_to_use is not set, but I still loosing network
chlorine has quit [Ping timeout: 264 seconds]
mzki has joined #linux-sunxi
<MoeIcenowy>
linux-next is just something for the brave people to test ;-)
chlorine has joined #linux-sunxi
<montjoie>
I have no choice, stmmac is a moving target
boycottg00gle has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
boycottg00gle has quit [Remote host closed the connection]
chlorine_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
<alex__>
what happens when the axp20x module will be unloaded? does it kill all the voltages?
<plaes>
alex__: you can try ;)
<KotCzarny>
or read the code
<alex__>
I think the kernel unloads the module, before my disk is powered down, when I hsutdown or reboot. So the disk goes to emergency power loss.
Worf has joined #linux-sunxi
<alex__>
in axp20x-regulator.c there is only a probe but no remove or shutdown. So it's in undefined state?
<plaes>
or it doesn't do anything on removal
tkaiser has joined #linux-sunxi
<alex__>
i'll try it what happens when I compile the axp driver directly into the kernel and not as a module.
<rellla>
tkaiser: well done :)
<tkaiser>
apritzel: Are you still searching for DVFS operation points for Pine64?
<tkaiser>
rellla: Author of Make magazine is in contact with me, hope to place an article explaining linux-sunxi a bit there in the next months.
<MoeIcenowy>
alex__: it's HIGHLY RECOMMENDED to built-in axp20x driver
<MoeIcenowy>
tkaiser: wow
<tkaiser>
rellla: I've written for Heise myself (iX magazine) and I think I still have a valid 'Autorenvereinbarung' ;)
chlorine_ has quit [Remote host closed the connection]
<rellla>
tkaiser: good approach. problem of Heise aren't the articles itself. problem are the many people that write comments, without the proper knowledge.
<KotCzarny>
so the internet's usual ;)
<tkaiser>
rellla: true
<rellla>
which in turn can be derived from a linux-sunxi problem, which should make us think about how to make the community work more popular...
<rellla>
therefore: fullack for a linux-sunxi article!
Ntemis has joined #linux-sunxi
<tkaiser>
rellla: Let's wait and see. I'm thinking about DT overlays as starting point since that's a real problem currently only community can solve: https://forum.armbian.com/index.php?/topic/3787-testers-wanted-sunxi-device-tree-overlays/
<jelle>
tkaiser: how are they applied?
<jelle>
in u-boot?
<tkaiser>
jelle: yep, but just read through explanation and readme in Mikhail's githup repo.
<jelle>
yup doing that now
enrico__ has joined #linux-sunxi
lamer14900909539 has joined #linux-sunxi
lamer14900909539 has quit [Client Quit]
aballier has quit [Quit: leaving]
tkaiser has quit [Ping timeout: 264 seconds]
aballier has joined #linux-sunxi
fkluknav has joined #linux-sunxi
enrico__ has quit [Ping timeout: 258 seconds]
apritzel has joined #linux-sunxi
<apritzel>
tkaiser: A64 operating points> yes, I consider them an implementation detail, but if there are known good values, I am happy to take them
<apritzel>
KotCzarny: which chip "makers" do you expect to list in the *linux-sunxi* Wiki?
<KotCzarny>
all of them
<KotCzarny>
it will be PR page
<KotCzarny>
samsung, rockchip, broadcom
<KotCzarny>
anyone knowledgeable in rockchip land to add a soc or two?
swiftgeek has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
<rellla>
KotCzarny: #linux-rockchip ...
<KotCzarny>
rellla, would be better for someone from linux-sunxi that's also in linux-rockchip
<montjoie>
ah ah ah my colortable will spread the world
<KotCzarny>
:)
<jelle>
KotCzarny: amlogic is also WIP
<jelle>
S905X, S905 but no idea how
<KotCzarny>
would be nice to add socs from rpi1/2/3
<KotCzarny>
i lack knowledge of that area though
<wens>
KotCzarny: for rockchip you can start with rk3288 and rk3399
<wens>
the chromebook socs
<KotCzarny>
added, if you know what is the status of particular fields, feel free to update
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: .]
<wens>
rk3288 is more or less completely supported
<plaes>
ls
<KotCzarny>
irc: ls: command not found
<plaes>
I know, I know :(
sunshavi has joined #linux-sunxi
r1mikey has joined #linux-sunxi
<MoeIcenowy>
KotCzarny: I suggest you add CPU Core into this comparsion table
<KotCzarny>
huh?
<KotCzarny>
you mean psci?
<MoeIcenowy>
nope
<MoeIcenowy>
just the core the SoC uses
<MoeIcenowy>
as old SoCs are going to have better support, but are also going to use old cores
<MoeIcenowy>
P.S. for different SoC BSP means different
<MoeIcenowy>
for some SoCs BSP will contain bootloader source (e.g. Allwinner A10/13/20, iMX)
<KotCzarny>
but that field would be informational or status of support?
<MoeIcenowy>
for some BSP won't contain it (e.g. Qcom)
chlorine_ has quit [Remote host closed the connection]
<Ke>
to be honest, the concept of BSP is not favourable to open source
<Ke>
it means that you have no intention of writing code good enough to be upstreamed
<KotCzarny>
not quite knowing what you mean by 'cpu core', for example for A20: 2xA7 ?
<Ke>
or open enough
<plaes>
yeah.. it's just a dump
<MoeIcenowy>
KotCzarny: oh it should not be added
<MoeIcenowy>
but instead maybe something like announcing year will be helpful
<KotCzarny>
ke: what if bsp would be actually decent code with good licensing?
<MoeIcenowy>
A20 is now well-supported by community, but now it's quite old
<Ke>
it would still be bad
<Ke>
upstream or gtfo
<KotCzarny>
good code would be easy to upstream, i wanted to show bsp quality of the makers too
chlorine_ has joined #linux-sunxi
<Ke>
yeah, more data is better than less
<Ke>
I would hope that the concept of BSP would die
<KotCzarny>
what year a20 hit the market?
<MoeIcenowy>
Ke: but current upstream merging speed cannot still be faster than production
<Ke>
MoeIcenowy: yes
<KotCzarny>
found it. 2012.12
<Ke>
and I would guess that OEMs might even prefer older LTS kernels
<apritzel>
MoeIcenowy: doesn't need to be "faster", if people would start early enough
<MoeIcenowy>
apritzel: yes, rockchip seems to be early enough now ;-)
<apritzel>
MoeIcenowy: see the RK3399, it's about to hit the market now
<apritzel>
MoeIcenowy: exactly
<Ke>
=o)
<MoeIcenowy>
but they still need to provide a modified 4.4
<Ke>
I hear rockchip is not outright hostile towards complete liberation either
<apritzel>
Ke: which might be influenced by some search engine company basing their products on it ;-)
<Ke>
yup
<wens>
announce date is useless unless upstream efforts follow soon
<MoeIcenowy>
P.S. some SoCs feature another problem -- boot from a non-ARM core
<MoeIcenowy>
e.g. bcm283x, qcom guys
<KotCzarny>
MoeIcenowy: booting from different core is not a problem if there are no blobs, right?
<MoeIcenowy>
KotCzarny: however this usually means blobs.
<Ke>
isn't bcm283x on it's way towards complete liberation now?
<MoeIcenowy>
(also x86 is now also suffering from this -- Intel "Management" Engine
<Ke>
or the boot process
<MoeIcenowy>
Ke: but still too far.
<MoeIcenowy>
qcoms are most evil in this area: not only they boot from a blob, they will also check the signature of the blob
r1mikey has quit [Remote host closed the connection]
afaerber has joined #linux-sunxi
<libv>
Ke: rpi foundation stated that they were working towards a free bootloader around the time that they released (actual) source code for the gpu (unlike their first big bullshit statement)
<libv>
this was like 3 years ago
<libv>
and nothing happened
chlorine_ has quit [Remote host closed the connection]
<libv>
the rpi REing community now is making some progress
<Ke>
yup
<Ke>
right now the big drawback on the soc is slow peripheral connectivity anyway
<Ke>
still, it is a very popular system
<MoeIcenowy>
rpi is not a good piece of hardware
<MoeIcenowy>
it's popular just because it's popular.
<jelle>
well and plenty of software and projects around it
<Ke>
videocore driver is also nice
<MoeIcenowy>
yes
<Ke>
I believe that rk3399 cpu cores are actually good enough for desktop graphics for my purposes
<KotCzarny>
vhs wasnt great piece of technology either, but was cheap and popular
<MoeIcenowy>
3rd party GPU core makers are mean
<MoeIcenowy>
I've heard from Loongson that Vivante is not going to even make them a working X11 GLES driver (the Loongson-2H SoC design used Vivante GC cores)
chlorine has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
r1mikey has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
<Ke>
if only you could get rockchip SoC with vivante
chlorine has joined #linux-sunxi
chomwitt1 has joined #linux-sunxi
<apritzel>
Ke: take the RK3399 and connect a PCIe graphics card :-D
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
fkluknav has quit [Ping timeout: 264 seconds]
<plaes>
o_O
<willmore>
m-PCI-E to 16x PCI-E adapter needed.
<KotCzarny>
and real mpcie port, not the crippled usb one
<willmore>
Still waiting for a mini-ITX form factor ARM board. ;)
<willmore>
KotCzarny, clearly.
victhor has joined #linux-sunxi
<wens>
weren't the tegra development boards close?
<willmore>
close? As in to mini-ITX? In size maybe, but not in component layout.
<willmore>
Needs to ship with an ATX back panel insert. :)
<KotCzarny>
make a generic motherboard that's just passthrough for various ports?
<KotCzarny>
and flexible mount holes too
<willmore>
Interesing.
<willmore>
If we had a standard high speed/low speed pinout. ;)
<willmore>
Sort of a carrier MB
<KotCzarny>
make it modular
<KotCzarny>
ie. superset of features that user can connect just the one he/she has
<willmore>
So the little SBC could stay little, but those who wanted a big old mini-ITX could have that.
perr has joined #linux-sunxi
<willmore>
ATX power supply control, etc.?
<KotCzarny>
pico-itx?
<willmore>
Too bad they put the high speed I/O connectors on the wrong side of the board on the 96 boards spec.
<KotCzarny>
thats why you want passthrough ports, so you can route them correctly
<willmore>
mini-ITX is as small as it pays to go. What's pico used for?
<willmore>
Isn't that just shorter?
<willmore>
You have to be as wide as the back pannel + PCI-E slot.
<KotCzarny>
pico-itx is a brand of atx compatible psu
<willmore>
Pico-itx is too small and non-standard.
<Ke>
there was that one Asus server board that people were interested in that had full pcie
<willmore>
mini-ITX is the smallest that fits in normal cheap cases.
<Ke>
8 armv8 cores at 2.4GHz
<willmore>
There are 24, 32, 48, and 64 core monster server boards, too, but they're a bit out of scope here. :)
<Ke>
certainly, though many people here care about high end libre
<KotCzarny>
willmore, then as i've said, motherboard with cable routes to the standard passthrough panel
<willmore>
The connectors for the 96 boards layout are what we need, but they put them on the top so that they can only connect to a *smaller* board. We need them on the bottom so they can connect to a bigger board.
<willmore>
KotCzarny, I'm not sure what you mean by passthrough ports.
<KotCzarny>
willmore, imagine being able to put opipc2 on that board
<willmore>
k
alexvf has quit [Ping timeout: 260 seconds]
<KotCzarny>
and connecting opi ports to the mobo ports in the case
<KotCzarny>
with right-angle cables it wouldnt even be that bad
<willmore>
Right, but I want to do that through a set of high speed connectors, not a bunch of short A-A USB cables and junk.
<KotCzarny>
what connectors? hdmi? usb? eth?
<KotCzarny>
does it have any other high speed ones?
<willmore>
PCI-E
<montjoie>
KotCzarny: exactly what I tryto do with old IDE rack, "ethernet, uart and power thougth it"
<montjoie>
one rack, one board
<KotCzarny>
:)
<KotCzarny>
willmore, some minipcie extender ?
<willmore>
I was thinking that the carrier board would have a full sized PCI-E (or at their option mini-PCI-E) slot and the signals would be passed through from the SBC over a high speed connector.
<willmore>
Sort of like the Tegra modules work.
<KotCzarny>
unless you have the slot on the bottom you would still need some flat cable
<Ke>
or attach rpi to PCIe and use as gpu!!!!!
* willmore
sighs
chlorine has quit [Remote host closed the connection]
<willmore>
KotCzarny, the SBC would just have a pair (or however many are needed) of high speed connectors on its bottom side which would mate with connectors on the carrier. The carrier would then route the signals to the PCI-E connector, the USB ports, the ethernet jack, the HDMI jack....
chlorine has joined #linux-sunxi
<KotCzarny>
that would require either a standard, or doing it for specific board
<willmore>
It's a dream that will never happen, but...
<willmore>
Yes, a standard.
fkluknav has joined #linux-sunxi
<willmore>
A useful one, unlike the 96 boards standards.
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
lkcl has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine_ has joined #linux-sunxi
<KotCzarny>
is board size affecting final price notably? (for <50usd boards)
<MoeIcenowy>
you mean more small more expensive or more big more expensive?
tkaiser has joined #linux-sunxi
<KotCzarny>
big -> more material/less boards per batch etc -> bigger price?
<KotCzarny>
and i'm curious how much bigger price
<MoeIcenowy>
P.S. Pine64 seems to be the biggest A64 board
<willmore>
For the board carrying the SoC, they layout is critical and the board material/construction may be more expensive.
<MoeIcenowy>
but it's quite cheap
<willmore>
I.E. more layers, etc.
<MoeIcenowy>
it's easily shown if you compare Pine64+ 2GiB with BPi M64 or compare Pine64+ 1GiB with OPi Win
<terra854>
So 2017.05 can initialize all the devices (smp, ethernet, mmc, etc.) on A64?
<apritzel>
terra854: this is already possible for quite a while
<apritzel>
terra854: well, not SMP, but the rest at least
<apritzel>
terra854: but yes, 2017.05 should give you the full experience
<terra854>
Nice
<apritzel>
terra854: btw: you were asking for EFI yesterday
<apritzel>
I am not aware of anyone working on an EDK2 port
<terra854>
Oh...
<apritzel>
but: Microsoft seems to have an UEFI firmware ready
<apritzel>
and:
<apritzel>
U-Boot can do EFI loading these days as well
<apritzel>
so we are very close to load stock arm64 installers from U-Boot
<apritzel>
I think that works already for OpenSuSE
<terra854>
So it can load any efi app (e.g. grub.efi)?
<apritzel>
I tried Debian the other day, and it just didn't work because they put grub on the second partition
<apritzel>
terra854: yes
<apritzel>
manual loading works already
<apritzel>
fatload mmc 0 0x43000000 bootaa64.efi
<apritzel>
bootefi 0x43000000
<apritzel>
or so
<terra854>
And can the new uboot load the A6y4 3.10.x BSP kernel?
<terra854>
A64*
<apritzel>
<connection lost>
cnxsoft has quit [Quit: cnxsoft]
<terra854>
?
r1mikey has joined #linux-sunxi
<apritzel>
any minute spend on that kernel is lost time
r1mikey has quit [Remote host closed the connection]
<apritzel>
we have simplefb already with mainline
<apritzel>
and I think proper gfx support is around the corner already
<MoeIcenowy>
terra854: I think it may need some changes to load 3.10.x
<MoeIcenowy>
in ATF
<terra854>
simplefb over HDMI?
<apritzel>
terra854: yes
<apritzel>
MoeIcenowy: not "some changes", but ugly and wrong hacks
<MoeIcenowy>
P.S. the EDK2 port by AW/MS is a 32-bit port
<MoeIcenowy>
it
IgorPec has quit [Ping timeout: 260 seconds]
<apritzel>
MoeIcenowy: seriously?
<MoeIcenowy>
apritzel: yes
<apritzel>
oh dear!
<MoeIcenowy>
Windows 10 IoT do not have any 64-bit version.
<apritzel>
MoeIcenowy: good to know, so I don't need to waste time on this then ...
<MoeIcenowy>
on RPi3, DragonBoard 410c the EFI implementations are also 32-bit
<terra854>
So the 10 IoT for the Pine is 32-bit?
<MoeIcenowy>
terra854: Windows 10 IoT are all 32-bit
<agraf>
some things are just so wrong :)
* terra854
wonders why Microsoft is not taking advantage of aarch64...
<tkaiser>
agraf: Talking about Windows here?
<apritzel>
MoeIcenowy: the Theobroma guys have some patch to emulate the arisc functionality in (our) ATF, but I won't push this ;-)
<MoeIcenowy>
;-)
<agraf>
tkaiser: no, the whole windows iot thing is a mystery to me (and anyone I know at MS)
<agraf>
tkaiser: it looks like they're trying to do all the possible mistakes we did in the linux world again :)
<agraf>
tkaiser: similar to how Intel tries to redo everything bad with their embedded division too
<MoeIcenowy>
terra854: they just simply do not have mature AArch64 kernel when they are making Windows 10 IoT.
DullTube has quit [Quit: Leaving]
<MoeIcenowy>
and now they simply don't want to upgrade to AArch64
chlorine_ has quit [Remote host closed the connection]
<terra854>
and to think that they are working on an aarch64 port...
<MoeIcenowy>
terra854: it's not the IoT version
<terra854>
Yeah, but it can be adapted for it
<tkaiser>
agraf: Maybe just the 'large corporation' syndrome... Anyway, not interesting at all when looking from a practical point of view.
<agraf>
tkaiser: i agree, and am puzzled :)
<MoeIcenowy>
P.S. I will soon try out jernej's dm_video patches
<MoeIcenowy>
as it may enable us to use EFI GOP
<apritzel>
MoeIcenowy: sounds good!
<MoeIcenowy>
with GOP we can possibly run a GRUB2 with gfxterm ;-)
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
<MoeIcenowy>
but for A64 currently we have too many floating patchsets
<MoeIcenowy>
P.S. the EFI function of 32-bit U-Boot is broken, due to the internal PSCI implementation is not compatible to it :-(
<MoeIcenowy>
for A64 at least we have now the following patchsets: 1. SPL FIT support 2. DM Video support 3. LPDDR3 support
<agraf>
MoeIcenowy: what exactly is broken?
<apritzel>
MoeIcenowy: I know, its' fun, isn't it?
<MoeIcenowy>
agraf: when booting with EFI the PSCI nodes cannot be properly set
<MoeIcenowy>
and the kernel will refuse to boot properly
<MoeIcenowy>
if I set some environment variables, it can boot, but with SMP
<MoeIcenowy>
on A10/A13 it's OK, as there's no SMP and no PSCI
pg12_ has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
apritzel: it's not fun if you must assemble patchsets into your final u-boot
<apritzel>
MoeIcenowy: I know
<agraf>
MoeIcenowy: ah, so you're using ATF on 32bit?
<apritzel>
forgot the smiley ;-)
<MoeIcenowy>
agraf: no.
<MoeIcenowy>
I'm using the internal PSCI implementation
pg12 has joined #linux-sunxi
<agraf>
MoeIcenowy: I thought pretty much all 32bit ARM targets use spin tables
<agraf>
MoeIcenowy: interesting :)
<MoeIcenowy>
agraf: nope at least sunxi do not use spin tables
<MoeIcenowy>
sunxi never use spin tables.
<agraf>
MoeIcenowy: well, using PSCI makes a lot of sense, I just never realized that anyone did it on 32bit ;)
<MoeIcenowy>
in current u-boot 32-bit internal SSCI users are more than 64-bit
<agraf>
MoeIcenowy: so I'm still puzzled why adding PSCI nodes fails for you with the EFI boot path
<MoeIcenowy>
s/SSCI/PSCI
<MoeIcenowy>
agraf: do you have any SMP 32-bit sunxi boards?
<agraf>
MoeIcenowy: the dt patching paths should be pretty much identical
<agraf>
MoeIcenowy: phew, I try to have as few 32bit boards as possible
<apritzel>
agraf: don't you have a BananaPi or Cubietruck?
<agraf>
apritzel: not me, someone in the office does i think
<MoeIcenowy>
but I think there's also smp bringing up code for A20 in kernel
<apritzel>
MoeIcenowy: let's not go there.
<MoeIcenowy>
oh nope, only A31 and A23
<apritzel>
sounds like a U-Boot/EFI bug to me, so let's just fix it
<agraf>
MoeIcenowy: yeah, no need to hack up the kernel
<MoeIcenowy>
apritzel: yes, for arm64 now it's refused to add such codes
<agraf>
MoeIcenowy: so really all we need is to advertise PSCI inside the device tree
<agraf>
MoeIcenowy: and if that's already working for bootz, there's just some really simple bug if it doesn't work for bootefi
<apritzel>
but we do this already
<MoeIcenowy>
yes, but sometimes the kernel just silently die if booted via bootefi
<MoeIcenowy>
die after efistub
<agraf>
MoeIcenowy: the 32bit one or the 64bit one?
<MoeIcenowy>
P.S. upstream GRUB seems to have a problem -- it cannot take device tree blob from bootefi argument, and always needs you to feed a new one, which have neither PSCI info nor EFI info
<MoeIcenowy>
agraf: 32
<MoeIcenowy>
I think for 64-bit the EFI works well, as we used ATF
<MoeIcenowy>
maybe we should go #u-boot for this discussion?
<agraf>
MoeIcenowy: 32bit grub efi is broken, yes. we have a workaround in our grub package, but the upstream patches to combine arm64 and arm in grub are pending and are just waiting for the upstream release to happen until they land
<MoeIcenowy>
agraf: do you have any links to this patch?
<agraf>
MoeIcenowy: so the most common reason for things to fail with efi boot is missing memory reservations
<MoeIcenowy>
this seems reasonable
<agraf>
MoeIcenowy: since I've never stumbled across the PSCI stubs in 32bit, there's a good chance we just don't reserve the memory where it's located
<agraf>
MoeIcenowy: and so linux tries to make use of that ram, overwriting code it later on calls
<apritzel>
agraf: the U-Boot PSCI code sits in SRAM
<apritzel>
as for most CPU errata out there: they are quite rare to actually cause trouble, but of course you can't rely on it, that's why you have to fix them anyway
JohnDoe_71Rus has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
IgorPec has joined #linux-sunxi
<MoeIcenowy>
apritzel: you are making me not sleeping well
BenG83_ has quit [Quit: Leaving]
<MoeIcenowy>
apritzel: should erratum 835769 also get workarounded for A64?
r1mikey has quit [Remote host closed the connection]
<apritzel>
MoeIcenowy: This one is fixed in the A64
<apritzel>
(it's an A53 r0p4 and REVIDR bit 7 is set)
IgorPec has quit [Ping timeout: 256 seconds]
<MoeIcenowy>
so there's different r0p4s?
<apritzel>
yes
<MoeIcenowy>
some with 835769 fixed, some no?
<apritzel>
indeed, depends on the REVIDR
<MoeIcenowy>
oh... and H5 also have a r0p4 with different REVIDR...
r1mikey has joined #linux-sunxi
<apritzel>
exactly, it has bit 8 set as well, so 843419 is also fixed
reinforce has quit [Quit: Leaving.]
dave0x6d has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
<TheLinuxBug>
Nah, luckily in the project KotCzarny and I have been working on we are using new u-boot :)
<TheLinuxBug>
and yeah I found it finally on igors github just after I asked
<TheLinuxBug>
finally ran across it
<tkaiser>
TheLinuxBug: Ok, then maybe just the led parameters should remain original. But I don't care that much. I only try to take care to import original fex first and then make the usual 'Armbian fixes' in a 2nd commit.
IgorPec has quit [Ping timeout: 260 seconds]
<TheLinuxBug>
well
<TheLinuxBug>
looks like it worked, will know in a minute
<TheLinuxBug>
:)
<Seppoz>
FYI 0012-patch-3.4.106-107.patch screws up the splash screen
Andy-D has quit [Ping timeout: 240 seconds]
<Seppoz>
where do i see existing targets in mainline uboot