<jernej>
ssvb: I discovered that during writing u-boot hdmi driver
<jernej>
and zador tried same thing on mali driver
<jernej>
he says it's working
<jernej>
but it was tested just on few boards
<ssvb>
still the patch is very messy
<jernej>
true
<ssvb>
it changes a lot of things, such as the irq numbers, etc.
<jernej>
I guess you'll be quicker if you just try to change that by yourself.
<jernej>
given that it already works on other H3 boards
<ssvb>
well, one of the things done by this patch is the removal of my old bus/phys addresses bugfix
<jernej>
this patch was never meant to be general. It needs to work only for H3
<ssvb>
and you are saying that this bugfix is in fact hardful now?
<ssvb>
*harmful
<jernej>
seems so
<ssvb>
the idea is that bit 30 in the address does not matter on boards with less than 2GB
leviathanch has joined #linux-sunxi
<ssvb>
but when we have 2GB, then we need to be very careful about how this is calculated
<ssvb>
the CPU accesses DRAM using 0x40000000 address as the base offset
<ssvb>
but the Mali accesses the DRAM using 0x00000000 as the base offset, that's why a correction is necessary
<ssvb>
at least that's how it worked on A20, maybe they have changed something on H3
<jernej>
maybe they rewire it? I really don't know the cause, as I'm not expert for memory, but I know, that this patch works
<jernej>
anyway, U-Boot driver code also doesn't use Mali
<jernej>
and it was similar problem
<jernej>
maybe it is Display Engine 2 issue?
<ssvb>
yes, the conversion between bus and physical addresses is a generic problem
<ssvb>
how does Display Engine 2 address memory?
<ssvb>
does it use the same addresses as the CPU or needs a 0x40000000 correction?
<jernej>
It works with same addresses
IgorPec has quit [Ping timeout: 256 seconds]
<jernej>
as CPU
<jernej>
it seems that all units works in this way
bugzc has joined #linux-sunxi
<ssvb>
OK, then bus and physical addresses are likely the same on H3, this makes it much easier and less error prone
<ssvb>
thanks, I'll try this fix
<ssvb>
it's just a single line change
<jernej>
ok, no problem
lemonzest has joined #linux-sunxi
jernej has quit [Ping timeout: 252 seconds]
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
premoboss has quit [Ping timeout: 256 seconds]
jstein has joined #linux-sunxi
gianMOD has joined #linux-sunxi
alexxei has quit [Ping timeout: 246 seconds]
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 240 seconds]
Mr__Anderson has joined #linux-sunxi
reinforce has joined #linux-sunxi
cptG_ is now known as cptG
alexxei has joined #linux-sunxi
<cptG>
hello! On mainline linux with A20, I have buzzing on the headphone jack when nothing is playing (few seconds delay from stop to buzz). It's fine if sth is playing on volume 0. I tried setting power/control from "auto" to "on" in sysfs but that didn't help. Any ideas what state the codec is entering to cause the buzzing and how to avoid it?
mzki has joined #linux-sunxi
alexxei has quit [Ping timeout: 244 seconds]
<cptG>
I can control the time-span from stop to buzz via cdc/pmdown_time but I can't turn off the behaviour completely...
paulk-collins has joined #linux-sunxi
jernej has joined #linux-sunxi
<KotCzarny>
cptg: usb interference noise?
<KotCzarny>
its just that audio path is crappy there
<cptG>
Hm. That would not explain the few seconds of non-buzzin I'm getting? The buzzing seems do happen when the device is in some sort of "power off" state.
<cptG>
...everything is fine when the device is in use, there's no buzzing even when the device is muted. But if whatever player is playing is stopped, the buzzing start after the milliseconds value configured in cdc/pmdown_time
leviathanch has quit [Read error: Connection reset by peer]
<cptG>
I can set that to 2147483647, which gives me 24 days of silence when no player is running inbetween, which should be fine I guess :)
<cptG>
well, the USB part *could* of course be the cause of the buzzing but that's not something I can fix I'm afraid. Disabling power management completely would work but so far I've had no luck with that.
premoboss has joined #linux-sunxi
<KotCzarny>
using i2c audio module could help, or spdif
Mr__Anderson has quit [Ping timeout: 250 seconds]
<cptG>
KotCzarny: hum. i2c and spdif are for external audio interfaces, right? Or is ist just another way to talk to the codec hardware?
<KotCzarny>
keep in mind when audio codec is closed/powered off, nothing gets amplified/gets on output
<KotCzarny>
you might also try hdmi audio out
<KotCzarny>
its digital and decoded outside/far from the board might help
Mr__Anderson has joined #linux-sunxi
<cptG>
hm... yeah, I had an USB sound card which worked fine but I wanted to explicitly get rid of that to free up an USB port.
<KotCzarny>
and i2s is just external audio card unrelated to anything onboard
<KotCzarny>
it connects via gpio pins, so usb is free
<cptG>
KotCzarny: OK, so I understood that correctly.
<KotCzarny>
keep in mind i2c != i2s
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
<cptG>
KotCzarny: yeah, that was a mistake, I always type i2c first :D
<cptG>
So spdif sounds good I guess - I'll get to keep my USB port and just need to get an spdif to anaolg converter.
<KotCzarny>
do you have any other device close to the board?
<cptG>
Until then: how can I make my value in cdc/pmdown_time permanent? I see no module parameters for sun4i_codec. Anything I can put into modprobe.d to control that value anyways? cdc.pmdown_time=foo?
<KotCzarny>
just add it to /etc/rc.local
<cptG>
KotCzarny: OK, got it. Thanks!
p_rossak has quit [Ping timeout: 244 seconds]
yann-kaelig has joined #linux-sunxi
Peet has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
bonbons has joined #linux-sunxi
Peet has quit [Ping timeout: 260 seconds]
<tkaiser>
ssvb: So how much SPI NOR flash should be soldered to boards to be useful? Just thinking about giving Xunlong/Steven some feedback (eg. solder pads for RTC battery backup)
alexxei has joined #linux-sunxi
iamfrankenstein has quit [Read error: Connection reset by peer]
iamfrankenstein has joined #linux-sunxi
<jernej>
MoeIcenowy: I checked disassembly and I'm almost sure this is some kind of gcc bug
<MoeIcenowy>
tkaiser: could you provide a successful dmesg?
<KotCzarny>
tkaiser, might be some static electricity?
<KotCzarny>
ie. let it cool for some hours unplugged from everything?
<MoeIcenowy>
as I do not want to test it by myself...
<MoeIcenowy>
(I do not have extra SD cards
<tkaiser>
MoeIcenowy: Somewhere here in between: http://sprunge.us/SZGF (Armbian collects dmesg output on startup and shutdown in a log to easy user support, search for 'wlan0')
<Dodger78_>
odroid xu4 supports it all on mainline kernel
<tkaiser>
IgorPec: Is Wi-Fi with OPi Zero working for you?
<KotCzarny>
are you really expecting them to max the bandwidth?
<tkaiser>
KotCzarny: USB3
<tkaiser>
+ UAS on XU4 rocks
<Dodger78_>
in times of gbit ethernet and SSDs , yes
<IgorPec>
tkaiser: i can see and connect , didn't do any other tests yett
<tkaiser>
IgorPec: Strange, for me it isn't working *any more* and I tested latest beta image and get the very same errors
<Dodger78_>
odroid xu4 even got HMP and everything supported , allwinner still cant deliver working SMP on mainline after more than 1 year
<IgorPec>
tha dhd patch was not ok, so blacklisting is needed
<tkaiser>
Dodger78_: Allwinner does nothing here.
<tkaiser>
IgorPec: Ah, ok
<KotCzarny>
Dodger78_: allwinner still uses linux 3.x, if it wasnt for linux-sunxi guys nothing newer would be available
<Dodger78_>
:-) yeah seems so . i will put A80 into the bin , will be my last allwinner device. what a pity after that nice cubietruck
<Dodger78_>
A20 is fully supported on mainline thanks to linux-sunxi
<KotCzarny>
h3 is quite complete too
<Dodger78_>
H3 is still A7 cores . its nothin than a refurbished cubietruck
afaerber has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
jernej has joined #linux-sunxi
<wens>
Dodger78_: a80 hmp with PSCI is close
cnxsoft has quit [Read error: Connection reset by peer]
<wens>
Dodger78_: if you want SMP through the kernel, i have patches for it, though PSCI is preferred, so those won't get merged
<wens>
Dodger78_: and about USB on cb4, usb2 is not merged for some stupid reasons
<wens>
Dodger78_: USB3 is a black box someone has to figure out
<Dodger78_>
@wens: i only need usb3
cnxsoft has joined #linux-sunxi
<Dodger78_>
@wens, so is there still work on a80 mainlining ?
<wens>
Dodger78_: i'm working on a80 mainlining
ptx0 is now known as kash
<wens>
since i have 2 boards and i would like them to work :)
kash is now known as d[^_^]b
<wens>
but i only do this in my free time, sometimes stealing cycles at work, so don't expect miracles :)
<Dodger78_>
me 2 ... im very sad about my a80 hardware . i bought it since cubietruck was so great but i wanted usb3 and the power of the a15 cores
<Dodger78_>
the board spend almost 2 years in my cupboard now
<wens>
yeah, i made those smp patches over a year ago :(
<Dodger78_>
:-!
bugzc has quit [Ping timeout: 260 seconds]
Dodger78_ has quit [Remote host closed the connection]
cnxsoft has quit [Quit: cnxsoft]
<tkaiser>
IgorPec: still doesn't work for me but maybe I just have a hardware problem. The PSU connected to Micro USB leads to an EHCI device connecting/disconnecting every 0.1 seconds.
<IgorPec>
ok, i'll check it
<tkaiser>
Maybe something went wrong when I attached a heatsink (using thermal glue, gotta check whether that one is conductive or not ;) )
<IgorPec>
image from beta download section, right?
<tkaiser>
IgorPec: Yes
<IgorPec>
ok, few minutes
<tkaiser>
IgorPec: Thank you
premoboss has quit [Remote host closed the connection]
<IgorPec>
tkaiser: works out of the box ... now some tests
<tkaiser>
IgorPec: If driver loads then it's already confirmed that I might have already damaged my board
<IgorPec>
Power Management:on
<IgorPec>
is this ok?
<tkaiser>
IgorPec: Yes
<IgorPec>
but is working very slow
<tkaiser>
IgorPec: h3consumption -w off && reboot
<tkaiser>
Or 'iwconfig wlan0 power off'
<tkaiser>
;)
<IgorPec>
iwconfi wlan0 power off
<IgorPec>
should do i thin
<tkaiser>
Sure but if you want to disable it permanently the above will lead to a network-manager hook disabling power-management when interface is brought up
<tkaiser>
IgorPec: h3consumption creates a simple script /etc/NetworkManager/dispatcher.d/99disable-power-management that does the job from then on
<IgorPec>
it works, that's all i can say out of this. let me try AP mode
<IgorPec>
or i can check later. i'll see if it will be still online in next hour. btw. 50cm away from router :)
<tkaiser>
IgorPec: Thank you, you could post armbianmonitor -u output for MoeIcenowy online. She asked for it a few hours ago for a working case
lkcl has quit [Ping timeout: 246 seconds]
gianMOD has joined #linux-sunxi
<IgorPec>
hmm, i did reboot and it didn't came up
<KotCzarny>
case of dying wlans ta doo doo doom.
<tkaiser>
IgorPec: do you have the 256 MB version? I experienced sometimes oom killer early in boot process leading to some failures
<IgorPec>
yes, just a moment ... seeking another serial console :)
premoboss has joined #linux-sunxi
<premoboss>
i need to use the 2 uart of nanopi neo. script.bin is the original one, if i edit it, (bin2fex) i see both uart are cofigured, but i f i try to test those TX with oscilloscope, o cans see chars caming out. any hints?
gianMOD has quit [Remote host closed the connection]
<tkaiser>
premoboss: Which script.bin is the original one?
<premoboss>
script.bin is a link to bin/nanopineo.bn
<premoboss>
i am using armbian 5.23 wuith kernel 4.8.3
<premoboss>
updated yesterday
<tkaiser>
premoboss: then you can forget about script.bin entirely :)
<premoboss>
ok, shann i go with dbs?
<premoboss>
dtb
<tkaiser>
yes, mainline kernel uses device tree instead.
iamfrankenstein has quit [Read error: Connection reset by peer]
<tkaiser>
premoboss: All this stuff on the GPIO headers is currently known to not work properly since we use Orange Pi One .dtb on the NEO with a small patch to enable usb1 and usb2 there
<premoboss>
dtb file point to dtb-4.8.3-sunxi
<premoboss>
ah, is it the why i cant find a proper dtb for nanopi neo.
<tkaiser>
premoboss: Armbian also does not really support mainline kernel on H3 boards, it's just a preview to get some feedback to forward to devs
<premoboss>
any chance to have he right one to enbable both uarts?
<premoboss>
on nanopineo, i mean
iamfrankenstein has joined #linux-sunxi
lkcl has joined #linux-sunxi
<IgorPec>
tkaiser: the board does not boot :)
<tkaiser>
premoboss: Sure, but I fear you're on your own here. Check wiki pages for pin-outs and come up with working settings :)
<tkaiser>
IgorPec: Great :)
<KotCzarny>
igorpec, lol, killer wifi
<KotCzarny>
or just very crappy firmware blob
<premoboss>
in other words, it is another stick up on the assole....
<IgorPec>
i am trying now with fresh start, diff sd card ...
<IgorPec>
diff psu i already did ... strange
<IgorPec>
i changed cabling on serial console since they were loosy
<tkaiser>
IgorPec: Mine boots, just checked Micro USB port and flashed new image through FEL mode.
<IgorPec>
other sd card boots here too
<IgorPec>
AP mode does not work out of the box
<tkaiser>
IgorPec: According to modinfo output only MAC address can be supplied to the driver. Maybe this missing .conf file is responsible for using the various modes?
<tkaiser>
IgorPec: Replacing the expensive 'german' PSU with a cheap chinese one solved this problem. Obviously noisy DC-IN leads to an unknown 'device' being detected on the OTG port approx 10 times per second :)
<IgorPec>
mine works fine. it's attached to chinese type PSU :)
<tkaiser>
IgorPec: Nice, replacing the USB cable (20AWG rated) with a crappy one also 'solves' the problem even with the noisy PSU :) So most users won't run into this since the cables most people use (24AWG or even worse) will filter noise.
<tkaiser>
IgorPec: And regarding Wi-Fi. After '[XRADIO] Bootloader complete' on your board '[XRADIO] Firmware completed.' is in dmesg output while on mine '[SBUS_ERR] xradio_indirect_read: Prefetch bit is not cleared.'
<tkaiser>
Seems like hardware?
<MoeIcenowy>
I will soon try legacy kernel Armbian on my board...
<|Jeroen|>
thanks for the tip, maby i must consider other devices then
<tkaiser>
|Jeroen|: the board itself with mainline kernel will consume a bit more than 1W when using Fast Ethernet. That's most probably less than the idle consumption of a crappy PSU
<KotCzarny>
make it live on air
<jelle>
nanopi neo also had a nice low power consumption :)
<|Jeroen|>
thats not much
<jelle>
KotCzarny: s/air/solar/g :D
<|Jeroen|>
but they have low ram ?
<KotCzarny>
bad region for solars ;)
<|Jeroen|>
i like atleast 1GH
<|Jeroen|>
B
<jelle>
KotCzarny: same here, don't live in the desert :p
<tkaiser>
|Jeroen|: 1GB to query sensors?
<jelle>
|Jeroen|: zero has 512 I think?
<KotCzarny>
it can also double for other taskss
<|Jeroen|>
well it does more then query sensors
<|Jeroen|>
runs a postgres db and webinterface
<terra854>
Just wondering, is the H5 better than the A64?
<|Jeroen|>
and i would like to run the postgrey on a ramdisk in the future
<|Jeroen|>
well its actualy running fine on a old pi1 atm, but wanted to switch it to the pine beceause i won then
<KotCzarny>
you can still sell them while they are hot
<KotCzarny>
;)
<|Jeroen|>
would be to costly to chip them from here
<|Jeroen|>
and i do like the idea of 64bit :p
<|Jeroen|>
not that i actualy mathers
<KotCzarny>
which part of it exactly has a use for you?
<|Jeroen|>
jus network and i2c
Pepe has joined #linux-sunxi
<KotCzarny>
you know that even a10/a20 fits in those criteria perfectly?
<|Jeroen|>
yeah but i have a A20 on a bananna pi and it ws crap
<|Jeroen|>
needed 2 psu's etc
<KotCzarny>
w00t?
<|Jeroen|>
yeah crapy chinese hardware
<KotCzarny>
why 2 psu?
<|Jeroen|>
its was on the wiki, otherwise it might not boot
<KotCzarny>
lol?
<|Jeroen|>
actualy i even blew one up
<KotCzarny>
[citation needed]
<|Jeroen|>
crap!!
<KotCzarny>
if you talk about needing 12V for 3.5" hdd, google: meanwell rd-65a
jernej has joined #linux-sunxi
<KotCzarny>
(i should do some photo documentation of my banana setup)
<tkaiser>
|Jeroen|: So PostgreSQL is broken by design?
<|Jeroen|>
nah sd cards are broken by design
<|Jeroen|>
run a postrges on a sd card and its breaks in a few months
iamfrankenstein has quit [Ping timeout: 245 seconds]
<tkaiser>
terra854: depends on what you're keen on whether H5 is better or not. Just look into the wiki
iamfrankenstein has joined #linux-sunxi
<tkaiser>
|Jeroen|: Exactly, so choose an A20 device with native SATA and run databases from an SSD
<jelle>
wonder when that new A20+ is released with native SATA :)
<|Jeroen|>
that would also be an option
<|Jeroen|>
i do have the banana pi with sata lying collecting dust
<|Jeroen|>
but i don't trust it
<tkaiser>
|Jeroen|: And BTW: postgresql devs aren't morons, so by adding a 'ramdisk' you just decrease both reliability and performance. BTW: SATA with A20 sucks somewhat when it's about sequential write speeds but that doesn't matter that much when it's about databases: https://forum.armbian.com/index.php/topic/1440-h3-devices-as-nas/?p=11423
<tkaiser>
jelle: R40, BananaPi M2 Ultra (or something like that). Already an aliexpress but moronic vendor provides no benchmark numbers for GbE and SATA
<|Jeroen|>
yeah i agree its not the best option
<jelle>
tkaiser: :D
<|Jeroen|>
thats why i now run the postgres on another server with disks
<jelle>
tkaiser: yeah exactly that R40
<|Jeroen|>
but i would prefer it all on one controller
<tkaiser>
|Jeroen|: your problems were related to crappy Micro USB used for DC-IN, simply power the board through SATA power and A20 runs pretty stable.
* jelle
notes this
<|Jeroen|>
nah, that board is going nowhere :p
<terra854>
tkaiser: Apparently H5 has a stronger GPU (Mali 450)
<terra854>
tkaiser: But i don't think it will matter due to blobs and licensing issues preventing us from using it
<tkaiser>
|Jeroen|: Banana Pi was always the best performing A20 device for me (GbE throughput). And it's pretty simple to get this sinovoip crap stable: Avoid Micro USB to power the boards and you're already done
<terra854>
tkaiser: Other than that, the CPUs are the same (4x Cortex A53)
<tkaiser>
terra854: For my use cases H5 has twice as much USB ports compared to A64, that's twice the IO bandwidth and allows for more use cases.
<|Jeroen|>
allwinner makes to many models :p
<tkaiser>
terra854: Also chances are great that OPi PC2 and 3 won't suck regarding Gigabit Ethernet.
<jelle>
I love how there is a H2 now
<jelle>
H3 => H2 :D
<Pepe>
Hello guys. I would like to know which board from Sunxi is better for Android?
cptG_ has joined #linux-sunxi
<jelle>
don't think many people use android here :)
<tkaiser>
Pepe: None
<Pepe>
Thanks. That's what I would like to know. :D
<terra854>
Pepe: Unless you are fine with Allwinner's provided crap
<Pepe>
Was just asking, but othe other side I was checking newly released Orange Pi PC2 which looks good, because mainline support is on the way. Still can't decide between it and Orange Pi Plus 2E
cptG has quit [Ping timeout: 245 seconds]
<tkaiser>
Pepe: None of Allwinner's current line up has a GPU that meets Android 7 requirements and when using Android it's essential to boot from storage showing high random IO performance (fsync). The average SD card out there horribly sucks here.
<tkaiser>
Pepe: H3 means Android 4.4 max. Good luck.
<Pepe>
I would be fine also with Android 6, but I joined this channel to directly ask you, because I see from CNXSoft that you're smart guy and you could help me, which you did about Android.
<KotCzarny>
pepe: forget about android from allwinner vendors, its broken, incomplete and no one really cares
<Pepe>
now I understood it, thanks.
<KotCzarny>
if you really want android, buy some branded tablet
netlynx has quit [Quit: Ex-Chat]
yann-kaelig has quit [Quit: Leaving]
gianMOD has joined #linux-sunxi
<KotCzarny>
or some ott box
<KotCzarny>
those might have a bit better support
<KotCzarny>
for me original bananas are stable, feature packed and best of all mainlined
<KotCzarny>
(that is, as long you use good distro, psu and cable)
<Pepe>
and for linux I cant decide between Pi PC2 (but waiting for 2 GB RAM) or Pi Plus 2E. Which would have better mainline support right now.
<KotCzarny>
h3 one, but h5 is very similar to h3
<KotCzarny>
so it might get same feature status as h3
<jonkerj>
until the emac patches reach mainline (my feeling is we're not far away) you will be needing some patches for H3
gianMOD has quit [Ping timeout: 260 seconds]
<jonkerj>
I am running not that many patches (emac + dvfs) on my h3 boards (orange pi plus, orange pi pc)
<jonkerj>
used to be a lot of patches, but most is mainlined now
<ssvb>
haha, I used exactly the same modification of uart0-helloworld for retrieving REVIDR, even the format of the output is roughly the same :-)
|Jeroen| has quit [Remote host closed the connection]
<apritzel>
;-)
<ssvb>
but yes, it makes sense to just integrate retrieving this information into the sunxi-fel tool
<apritzel>
right, I was thinking so
<NiteHawk>
apritzel: so far it's been mostly a "proof of concept" or having some 'baremetal' code running. but once you get the UART going, you can of course use it for diagnostic purposes - so yes, that makes sense
<apritzel>
ssvb: putting it into sunxi-fel tool would simplify new SoC bootstrapping, as we don't need to know how the UART works
<NiteHawk>
ah sorry, i mixed that up - thought you were referring to uart0-helloworld
<apritzel>
NiteHawk: actually both
<apritzel>
I think having some bare-metal hello world is useful
<apritzel>
because quite some people ask for it
<apritzel>
we could just point them to it
<apritzel>
another thing is new SoC bringup
<NiteHawk>
as far as "register-poking" is concerned, running scratch code through sunxi-fel is a viable route too :)
<apritzel>
so having this in sunxi-fel is better
<apritzel>
but another use case would be some socinfo binary, which could live on an SD card
<apritzel>
which dump this information on the UART
<apritzel>
plus a lot more
<apritzel>
it could check for a SPI flash, for instance, print its size, etc
vagrantc has joined #linux-sunxi
<apritzel>
this could be a precursor for some generic Allwinner firmware thingie
<apritzel>
the idea: having an SD card image which boots and programs the NOR flash
<apritzel>
this could be as generic as possible, loading the actual firmware image from SD
<apritzel>
so it detects the SoC, loads the proper image and writes it into the flash
mzki has quit [Ping timeout: 245 seconds]
<NiteHawk>
apritzel: obviously we have a number of different uses cases there, ranging from very basic tasks/diagnostics (porting to new SoC), over hw info and feature detection, up to "high level" tasks possibly requiring a function library. for the latter it might also be worth to check on u-boot's "baremetal" api?
<apritzel>
NiteHawk: yes, U-Boot sounds like a decent choice
<apritzel>
but:
<apritzel>
currently the SPL supports only one particular SoC (even board, possibly)
<apritzel>
because of #ifdef hell
<apritzel>
I wonder if we could either use the SPL, converting the #ifdefs into runtime socid dependent choices
<apritzel>
or work our way up from uart0-helloworld, possibly pulling in the MMC driver from U-Boot
<apritzel>
anyway, nothing for today, I was just curious whether anyone was looking into this already
<apritzel>
I guess that's going into the same direction as ssvb's sunxi-bootsetup thing
<NiteHawk>
ah, okay - so your focus would be more on an "universal" binary that would detect (and adapt to) SoCs at 'runtime'?
<apritzel>
NiteHawk: yes
nikre has joined #linux-sunxi
<apritzel>
the first real usecase would be a NOR flash utility
<apritzel>
just one image to rule them all
mzki has joined #linux-sunxi
<apritzel>
at least all which can be booted from NOR flash
dr1337_ has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
<apritzel>
anyway: back to my U-Boot patches ...
Ntemis has joined #linux-sunxi
<Ntemis>
hello
<Ntemis>
any devs around?
<willmore>
jelle, why would you want the A64 over the H5?
<Ntemis>
i was looking at some hw options and it seems orange pi pc and is using wrong and less memory freq
<Ntemis>
and in fex is set as mono but is dual channel 512+512
<tkaiser>
Ntemis: Maybe you should also consider the DRAM controller inside the SoC?
<tkaiser>
Ntemis: I don't know whether you've to support the software you're developing. In case you love bug reports about your software running unstable simply increase DRAM clockspeeds. Works 100 percent reliable to decrease reliability ;)
<Ntemis>
:)
<Ntemis>
turns pi's into a game console
<Ntemis>
is voltage fed ok? at 1.35v as it wants the ram
<Ntemis>
maybe less is given? am just asking for possible causes
<tkaiser>
Ntemis: You should test with lima-memtester since this applies already perfectly to your use case: making use of GPU acceleration. And then you'll see how far you get with DRAM clocked above 624 MHz if you've enough samples to test through.
<Ntemis>
because ram can do those speeds no sweat
<Ntemis>
what am thinking is no rams fault
<Ntemis>
is maybe either wrongly set up with wrong values or not given enough juice to perform
<apritzel>
Ntemis: I think what tkaiser wants to tell you: there is more than the actual DRAM chip to consider
<tkaiser>
Ntemis: Just use lima-memtester.
<apritzel>
thinks like stability of voltage supply, DRAM controller quality, PCB routing, actual DRAM silicon quality
<Ntemis>
i think problem lies in the first- stability of voltage supply
<Ntemis>
can it fed 1.35v stably
<tkaiser>
Ntemis: use a multimeter, there are test points IIRC
<Ntemis>
no one did it?
<tkaiser>
Ntemis: and after wasting a few days of your life you will end up there where linux-sunxi community currently is: Safe 624 MHz
<tkaiser>
Ntemis: Sure, all this already happened. Good luck doing it again ;)
<Ntemis>
hmm
<Ntemis>
i sure hope h5 gets a better design then
<ssvb>
tkaiser: and it would be the best case scenario
<apritzel>
Ntemis: what are you actually after: gaining 6.89% of theoretical DRAM bandwidth?
<Ntemis>
624 vs 800
<Ntemis>
in a dream world as it seems by tkaiser
<tkaiser>
Ntemis: The hypothetical 800 being result of a value printed in a spec sheet?
<ssvb>
tkaiser: a worse scenario would be Ntemis bumping the DRAM clock speed to 672MHz (or whatever), then making some SD card image of some distro and spreading it around ;-)
utente_ has quit [Ping timeout: 256 seconds]
<Ntemis>
if it was stable why not
<Ntemis>
but weird soc dram controller
<ssvb>
and of course people would think that they are doing the right things, but the allwinner hardware is crap
<Ntemis>
aha
<apritzel>
Ntemis: as tkaiser tells you: it's not stable
<Ntemis>
i hope h5 gets a better dram controller
<Ntemis>
do you guys know if it had an update
<apritzel>
I think there are rumours that those cheap SoCs get the DRAM chips from the bin ;-)
<Ntemis>
ahahaa
<apritzel>
(as in being sorted out by Samsung)
<tkaiser>
Ntemis: It might be on some boards but not on others. And it's not 'weird' but you're dealing here with ultra cheap hardware that needs sane defaults (that's what community does and not Allwinner)
<apritzel>
I am afraid this isn't so funny after all ...
<ssvb>
Ntemis: DRAM reliability heavily depends on the length and impedance matching of the traces between the SoC and DRAM on the PCB
<Ntemis>
amd talking about h5 getting a newer that sun9i generation dram controller
<ssvb>
that's the number one reason for memory corruption problems
<apritzel>
Ntemis: do you have any info on the H5 controller
<Ntemis>
no tkaiser has
<Ntemis>
:p
<apritzel>
because I am just stuck with libdram again for the H5 U-Boot
<ssvb>
lol
<Ntemis>
i see :(
<apritzel>
and Allwinner managed to change the boot0 loading scheme, so that boot0img doesn't work out of the box
<apritzel>
and I am not sure I want to waste my time in hacking this again
<Ntemis>
yeah i feel you
<ssvb>
welcome to the club
<Ntemis>
still the best hardware < money can buy
* ssvb
had exactly the same feeling about a64
<tkaiser>
Could there be something interesting on the provided Android image for H5?
<apritzel>
tkaiser: MoeIcenowy put the first 50MB somewhere
<Ntemis>
maybe a h3 port
<apritzel>
tkaiser: I extracted the DRAM parameters
jernej has quit [Ping timeout: 256 seconds]
<apritzel>
tkaiser: also the rest of that firmware stuff is there, but the layout is different from the A64 one
<apritzel>
so I have a libdram based U-Boot working, but it's not redistributable, unfortunately
<apritzel>
(though you can build it yourself)
<apritzel>
I will push something later tonight
<ssvb>
Ntemis: DRAM controllers used by Allwinner SoCs are actually decent (they are not designed by Allinnwer, but licensed), and I'm not sure what you are complaining about
<Ntemis>
am complaining that i cant use jedec specs on the soc
<Ntemis>
and thats a big fail
<ssvb>
if you do a shitty PCB routing, then neither the DRAM controller nor the DRAM chips are at fault
<Ntemis>
+1 one that one
<Ntemis>
shame though
<ssvb>
about jedec specs, do you mean that you would prefer to use 528MHz for DRAM?
<ssvb>
just to make it closer to the standard jedec bin
<Ntemis>
533
<Ntemis>
but no i wanted to go up because ram can do 800
<ssvb>
24mhz clock speed granularity, suck it up
<Ntemis>
<ssvb> Ntemis: DRAM controllers used by Allwinner SoCs are actually decent
<Ntemis>
the whole community suck it up at it seems
<ssvb>
what about the PCB routing quality is not clear for you?
<Ntemis>
fact?
<ssvb>
what fact?
<Ntemis>
that the routing is the fault here
<tkaiser>
Ntemis: How much does an Orange Pi One costs?
<tkaiser>
Ntemis: And it gets boring, before trying to overclock anything you should maybe become familiar with the basics. It's absolutely irrelevant what's written in specs here and there, what matters is reality. And expecting wonders with $10 devices is... somewhat strange
<Ntemis>
thats the issue here
<Ntemis>
looks like it only takes 1.2v
<Ntemis>
it needs a hardware mod
<Ntemis>
thanks for the prints
<Ntemis>
now is clear
<ssvb>
do you have a proof?
<Ntemis>
yes
<ssvb>
sorry, but seems like you are talking bullshit
<ssvb>
you can take the board and measure voltages yourself, there are some test points on it
<ssvb>
please do this before going on a speculation rampage here
<NiteHawk>
ssvb: are you okay with cherry-picking the revised 6457c36 and 8640291? (leaving aside the third commit for now) i'll also rebase the windows branch to get the new README in asap
<apritzel>
Ntemis: check page 7: Power
<apritzel>
Ntemis: welcome to the world of Allwinner based SoCs: the documentation does not always hold up to the promise ;-)
<Ntemis>
yeah
<Ntemis>
:D
<tkaiser>
Ntemis: please accept that you can measure these voltages, that people already did that and that there are some variations to take care of. And then you end up at 624 MHz
<tkaiser>
Ntemis: And please stop blaming everyone/everything around. This is el cheapo hardware and compromises are needed. It's OBVIOUS!
<apritzel>
you get what you pay for
<Ntemis>
what the...am not blaming anyone
<Ntemis>
i repsect your work guys
<Ntemis>
*respect
<tkaiser>
apritzel: Exactly. And your only chance is to deal with that and choose sane defaults. Or you get 'great feedback'
<tkaiser>
And to be honest: you get a lot for this little money you spend on H3 hardware
<Ntemis>
they could end up with a cheaper memory
<tkaiser>
(same with A64 and H5 now)
<Ntemis>
like a 1333
<tkaiser>
Ntemis: Since people then don't fool themselves thinking only about spec sheets?
<Ntemis>
oh well it worth a shot
<Ntemis>
thanks guys it was enlighting
<ssvb>
what kind of cheaper memory? DDR3-1333 is getting obsolete
<ssvb>
because, you know, the PC market wants higher speed chips
<Ntemis>
:)
<tkaiser>
Ntemis: You can be assured that there *IS* already the cheapest type of memory on these boards. Since it's all about *cheap* anyway
<ssvb>
that's why the arm devboard designers have no other choice, but are forced to use DDR3-1600 chips
<Ntemis>
those memories are used in a router
<Ntemis>
so i would call them cheap or unstable
<ssvb>
but it is not a problem, because these faster chips are also compatible with slower clock speeds too
<ssvb>
just check the specs of the ddr3 chips in question
<willmore>
Are the clocks for the DRAM on allwinner chips the transfer rate or the base clocks (1/2 the transfer rate)? I'm so used to the way the PC specs only the transfer rate and never the actual clocks.
<ssvb>
it's double data rate
<willmore>
Understood.
<ssvb>
when you see the MHz rating, it's the clock speed
<willmore>
Okay, so the transfer rate is 2x that. Good.
<Ntemis>
thats why i insisted on 667
<Ntemis>
because that would give us 1333
<willmore>
Which is not divisible by 24
<Ntemis>
nope but i didnt know that
<Ntemis>
at that time
<ssvb>
when you see the MT/s rating, that's the transfer speed (twice higher than MHz)
<willmore>
ssvb, understood.
<apritzel>
willmore: but it's 32-bit single channel only - in case you wanted to compare this to your 15 year old PC ;-)
<ssvb>
some people confuse MT/s and MHz
<willmore>
So, the next lower multiple from 667 is 648.
<willmore>
apritzel, Roger.
<willmore>
ssvb, completely agreed. They even spec transfer rates in MHz which just kills me.
<willmore>
I don't know how many times I've been driven half crazy by people who complain about latency increases on faster memory and how that will "kill performance".
<willmore>
Uhhh, if you multiple the cycle time (1/the clock speed) with the cycles you will often see that the actual latency--measured in seconds--is less with the faster memory.
<willmore>
Because: math
<ssvb>
latency is a tricky thing, it does not depend just on the dram timings
<ssvb>
because the dram controller is buffering the requests and can reorder them
<apritzel>
has anyone actually ever checked how much influence increased DRAM speed has on the whole system performance?
<apritzel>
apart from it crashing much faster :-D
<tkaiser>
BTW: Below 408 MHz DRAM clock on H3/H2+ it's 12 MHz steps. I don't know why this works but it works. With BSP kernel DRAM clockspeed can be set from userspace and I tested through 132-672 MHz a while ago
<apritzel>
I'd guess that it's not worth the trouble ...
<tkaiser>
apritzel: Did today a test with Orange Pi Zero and 408 MHz DRAM clockspeed and USB disk throughput. 1 MB/s less compared to 624 MHz.
<apritzel>
tkaiser: the DDR frequency is: (24 MHz * N * K) / M
<ssvb>
in fact you can ask exactly the same question about the CPU clock speed :-)
<ssvb>
has anyone actually ever checked how much influence increased CPU speed has on the whole system performance?
<ssvb>
apart from it crashing much faster :-D
<apritzel>
tkaiser: with all kind of constraints
<apritzel>
ssvb: sure, that would have been my next question ;-)
<apritzel>
I don't care so much about performance of those SBCs anyway, if I want something fast I use something else
<tkaiser>
apritzel: Exactly
<ssvb>
basically, fast DRAM is mostly needed for graphics
<apritzel>
ssvb: what is graphics? :-D
<ssvb>
because such things as scrolling are nothing else but simple memmove :-)
<ssvb>
if you speed up memmove, then you get more fps for scrolling
<ssvb>
well, these little boards can also run a somewhat usable linux desktop
<ssvb>
you can buy a Raspberry Pi board and check this yourself ;-)
<ssvb>
because children, education, learning, ...
<buZz>
i used a A20 as desktop for some time, quite snappy
<apritzel>
ssvb: I have some PIs and have been using them with X11
<apritzel>
ssvb: actually to read the A64 user manual last christmas ;-)
<vagrantc>
i hope you had a nice pipe of tobacco and a fireplace to go along with your seasonal reading
<apritzel>
ssvb: any my children always look at me with pity when I try some of those boards on them ;-)
<ssvb>
one of the worst performance killers for the linux desktop on these boards is the "ondemand" cpufreq governor
<apritzel>
and go back to their Lenovo's and tablets ...
<ssvb>
this ondemand thing does miracles and makes everything very laggy :-)
<apritzel>
vagrantc: I didn't read it aloud, if you meant that
<vagrantc>
apritzel: i hadn't but now i wish you had
<ssvb>
but of course, people attribute this slowness to "bad graphics drivers"
<ssvb>
just because graphics drivers are traditionally the number one thing to blame, nobody cares to run tests or benchmarks to figure out why their system is so slow
<apritzel>
vagrantc: though those manual contain a good share of fairy tale :-D
<apritzel>
ssvb: yeah, "performance" is a damn complex thing
<vagrantc>
and then the ghost of dram timing cast a curse...
<apritzel>
ssvb: people then try to compile with -O3 to improve things ...
<vagrantc>
moar speeds now!
<apritzel>
Once there were three little MMC controllers
<ssvb>
well, the performance critical code paths are implemented in assembly anyway
<apritzel>
one of them thought he was better (because of HS400)
<ssvb>
and the CPU with the help of the NEON unit can crunch more pixels than the DRAM controller is able to serve
<apritzel>
ssvb: don'
<apritzel>
t tell me ...
<tkaiser>
ssvb: Have you ever encountered the 'fantasy' cpufreq governor?
<apritzel>
tkaiser: is that the lost sibling of the "random" governor?
<tkaiser>
apritzel: No idea, but it was the active one on the first OS images for the 'real' Banana Pi. Showing lower scores when running on both CPU cores than on one. And everyone blamed the hardware back then.
<tkaiser>
apritzel: So results were somewhat predictable but not in the usual way ;)
<apritzel>
tkaiser: BogoMIPS has all the truth, you know ;-)
<Ntemis>
what enabling CONFIG_CPU_FREQ_GOV_AUTO_HOTPLUG does?
<Ntemis>
and switching to Slub is a good idea or not?
<Ntemis>
note that i already enabled performance gov as we are using the soc as a console for gaming
<Ntemis>
do i need CONFIG_CPU_FREQ_GOV_AUTO_HOTPLUG on performance gov?
<Ntemis>
anyone?
Mr__Anderson has quit [Remote host closed the connection]
<apritzel>
grep returns empty on that in 4.9-rc, so no clue ...
<tkaiser>
Ntemis: You're dealing with a smelly Android 3.4.x kernel no one here is interested in. Here mainlining happens that means writing stuff from scratch to overcome the Android kernel. So I fear you're on your own.
<tkaiser>
Ntemis: Instead of wasting time with this CPU stuff you might try out to get a newer Mali400 driver variant up and running. The one Armbian uses is quite old (3 or 4) and it might be possible to use 6.0. But I've to admit that I'm pretty much clueless regarding everything related to display.
<Ntemis>
is r4p0
<Ntemis>
i can update the driver but i need blobs that i dont have
<Ntemis>
and no where to be found either
<tkaiser>
Your use case could benefit from high memory bandwidth (not possible to increase values since you introduce instabilities then) and GPU performance. So I would focus on the latter and don't forget to benchmark regularly.