perr has quit [Read error: Connection reset by peer]
foxx_ has joined #linux-sunxi
kronicd_ has joined #linux-sunxi
kronicd has quit [Ping timeout: 250 seconds]
reinforce has joined #linux-sunxi
jernej has joined #linux-sunxi
foxx_ has quit [Ping timeout: 276 seconds]
dearfibonacci has joined #linux-sunxi
foxx_ has joined #linux-sunxi
foxx__ has joined #linux-sunxi
foxx_ has quit [Ping timeout: 244 seconds]
dearfibonacci has quit [Ping timeout: 276 seconds]
dearfibonacci has joined #linux-sunxi
foxx__ is now known as foxx_
clonak_ has joined #linux-sunxi
clonak has quit [Ping timeout: 260 seconds]
|Jeroen| has joined #linux-sunxi
massi has joined #linux-sunxi
ikmaak has joined #linux-sunxi
nashpa has quit [Ping timeout: 244 seconds]
nashpa has joined #linux-sunxi
apritzel has joined #linux-sunxi
ganbold has quit [Ping timeout: 240 seconds]
ganbold has joined #linux-sunxi
OverCR has joined #linux-sunxi
popolon has joined #linux-sunxi
<libv>
ssvb: i would argue that one is safe in the european union, that european law is above whatever bullshit this non-european company is trying to force upon us.
TheSeven has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
<KotCzarny>
hehe
<KotCzarny>
especially 'nobenchmarks!' ;)
Mr__Anderson has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
apritzel has joined #linux-sunxi
ikmaak has quit [Ping timeout: 244 seconds]
premoboss has joined #linux-sunxi
fl_0 has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
fl_0 has joined #linux-sunxi
dearfibonacci has quit [Ping timeout: 264 seconds]
florianH has joined #linux-sunxi
mzki has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
lemonzest has joined #linux-sunxi
dearfibonacci has joined #linux-sunxi
enrico_ has joined #linux-sunxi
perr has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 244 seconds]
Worf has joined #linux-sunxi
Worf has quit [Client Quit]
apritzel1 has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 244 seconds]
foxx_ has quit [Ping timeout: 260 seconds]
<ssvb>
libv: my understanding is that nobody forces anyone to use these blobs, so if somebody does not agree with EULA then they just should avoid using them
<ssvb>
libv: and that's why they also have explicitly closed the EU law loophole, before they mentioned it directly, the EU law applied by default
keh has quit [Quit: = ""]
<ssvb>
libv: I believe that for the reverse engineering purposes (even without disassembling, but just using tracing and logging from the kernel driver), it's still best to pick the blob version with the least restrictive EULA
<ssvb>
libv: oh, and the most important thing are the binary shaders, and whether we are allowed to redistribute and analyze them
jernej has quit [Ping timeout: 260 seconds]
<libv>
there are even less restrictions on the results of a proprietary program.
foxx_ has joined #linux-sunxi
|Jeroen| has quit [Quit: dada]
<foxx_>
apritzel: your fixes work fine. was able to pass checksum checks while writing onto sd directly. thanks
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 265 seconds]
jernej has joined #linux-sunxi
<rellla>
hey jernej
<jernej>
hey
<rellla>
i'm not sure if i'm right with my statements when i talk about your openelec fork in the various forums?
<jernej>
well, if you say that it uses allwinner code, then you are right
<rellla>
it uses the media-codec thing, right?
<jernej>
yes, closed sourced
<rellla>
everything closed source?
<jernej>
basically same design as open source media-codec thing
<jernej>
I tought to use media-codec at beginning, but then I received binaries from Xunlong, which have more codecs implemented
<ssvb>
none of the boards can be exactly the same, there are always some minor differences and imperfections when they are manufactured
<ssvb>
this also applies to processors in general, some may work at higher clock frequencies than the others, some may tolerate lower voltages than the others
robogoat has quit [Ping timeout: 276 seconds]
<ssvb>
but not everyone is lucky to have a perfectly overclockable processor
zerotri has quit [Read error: Connection reset by peer]
lvrp16 has quit [Read error: Connection reset by peer]
nihcas has quit [Read error: Connection reset by peer]
steev has quit [Write error: Connection reset by peer]
Tartarus has quit [Read error: Connection reset by peer]
cnxsoft has quit [Quit: cnxsoft]
<ssvb>
well, this was just some stupid rant
FergusL has quit [Ping timeout: 250 seconds]
<ssvb>
the dude is just complaining for the sake of complaining
dearfibonacci has quit [Quit: Leaving]
fdcx has joined #linux-sunxi
steev has joined #linux-sunxi
arnd has joined #linux-sunxi
<ssvb>
MoeIcenowy: still I'm still not sure if the 672MHz DRAM clock frequency is perfectly stable on all Pine64 boards, at least not until we run some stress tests with it
<ssvb>
maybe foxx_ could just try to reduce the DRAM clock speed and see if that helps
zerotri has joined #linux-sunxi
lvrp16 has joined #linux-sunxi
nihcas has joined #linux-sunxi
<fire219>
Pine QA is awful. it's part of how the boards are so damn cheap (aside from the $5 SoC, of course)
<fire219>
i haven't seen a single board that isn't seriously bowed in the middle, and my first board was DOA with what i can only conclude is bad soldering under either the SoC or RAM (boot0 bitches out over a RAM init error)
Tartarus has joined #linux-sunxi
[Awaxx] has joined #linux-sunxi
<fire219>
at least they're more than willing to replace dead boards
OverCR has quit [Ping timeout: 244 seconds]
OverCR has joined #linux-sunxi
<lvrp16>
the problem is that the board is too big and they used the cheapest PCB
<lvrp16>
the m64 boards by banana pi are much higher quality
ojn has quit [Ping timeout: 250 seconds]
ojn has joined #linux-sunxi
<ssvb>
lvrp16: any news from Xunlong about their A64 board?
<lvrp16>
h5 ;)
<lvrp16>
in a week
<ssvb>
hmm
<lvrp16>
i just got back yesterday on a 3 week tripe
<lvrp16>
going back to china on the 24th
<lvrp16>
i tried to see if huawei people would allow outside sale of kirin 955
<lvrp16>
but was sadly rejected
<ssvb>
is there any information about the differences between a64 and h5?
<ssvb>
I guess, if h5 at least has more usb controllers, then it would be a nice improvement
premoboss has quit [Ping timeout: 244 seconds]
<lvrp16>
ssvb: faster gpu if i recall correctly
<lvrp16>
hdmi 2.0?
<lvrp16>
i discussed it with an allwinner engineer 3 weeks ago so my memory is a little faint
<lvrp16>
still the mali 4xx gen though
<lvrp16>
arm should just open source the entire mali 4xx gen firmware
<MoeIcenowy>
yes
<MoeIcenowy>
but arm won't do it...
<lvrp16>
it would be cool ti implement some opencl functionality
<lvrp16>
that way these SBCs can be used for computer vision
<lvrp16>
and convolutional neural network problems
premoboss has joined #linux-sunxi
<MoeIcenowy>
mali 4xx is born weak...
<foxx_>
ssvb: via uboot?
xenoxaos has quit [Ping timeout: 250 seconds]
<ssvb>
foxx_: you can adjust the dram clock frequency in the boot0 header, just search for the field with 0x02A0 (672MHz) in the beginning of it and replace with something like 600
<ssvb>
foxx_: the checksum naturally needs to be corrected too
<foxx_>
ssvb: what about CONFIG_DRAM_CLK? should it also be changed?
xenoxaos has joined #linux-sunxi
<ssvb>
foxx_: it is currently not used for anything on Pine64
<ssvb>
foxx_: it is just a dummy placeholder value at the moment
<apritzel>
I am tempted to expose this as an SCPI regulator
<apritzel>
since the WiFi is optional
<apritzel>
and people could potentially hook up other things there
<MoeIcenowy>
yes...
<apritzel>
this code could enable the two GPIOs then as well, for instance
perr has quit [Quit: Leaving]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein2 has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein2 is now known as iamfrankenstein
<foxx_>
ssvb: sadly I cannot find 02A0 sequence in my boot0
jernej has joined #linux-sunxi
<ssvb>
foxx_: ARM is (usually) little endian
<foxx_>
ssvb: same for A002
<apritzel>
foxx_: offset 0x38 in the boot0.img
Dodger78 has joined #linux-sunxi
<apritzel>
(the one that starts with that eGON signature)
<foxx_>
damn
<foxx_>
thanks
<foxx_>
my hex editor goes crazy
<apritzel>
foxx_: btw: you could test that "-c" feature of boot0img to calculate the checksum on the way
<foxx_>
apritzel: i saw that option, thanks
<apritzel>
it's more meant for the parts that boot0 _is loading_, but works on boot0 itself as well
<foxx_>
ok, downclocked to 416mhz (it was the easiest way) - now i can keep ssh to the box at least for a couple of minutes
<foxx_>
after that it disconnects
<foxx_>
mii-tool says it re-negotiates link layer
<ssvb>
foxx_: a valid clock speed must be a multiple of 24, and decreasing it too much is not always a good idea
<ssvb>
but it is still interesting that the hardware seems to work somewhat better
<foxx_>
it's hard to say it works better... it works differently
<foxx_>
will try to patch for multiple of 24
<ssvb>
foxx_: you can try to also downclock the CPU, but I'm not sure how it works with boot0 now
Gerwin_J has quit [Quit: Gerwin_J]
reinforce has quit [Quit: Leaving.]
<ssvb>
foxx_: basically, if you have strange board-specific reliability issues, trying more conservative CPU and DRAM clock speeds is always a good idea
<KotCzarny>
ssvb: maybe he should just return it as 'broken' for a replacement?
massi has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
<ssvb>
KotCzarny: yes, this is also a valid solution :)
<foxx_>
KotCzarny: i live in wrong country to struggle with rma
<foxx_>
easier to try to replace realtek phy
<KotCzarny>
foxx: maybe just write email to vendor?
p1u3sch1 has quit [Ping timeout: 260 seconds]
<KotCzarny>
and hope they will feel generous
<foxx_>
i'll play around dram first :)
<KotCzarny>
why not both? ;)
<foxx_>
indeed
<KotCzarny>
btw. is it broken with android image too?
<foxx_>
i didn't check. good idea
Dodger78 has quit [Ping timeout: 244 seconds]
p1u3sch1 has joined #linux-sunxi
Dodger78 has joined #linux-sunxi
ndtuldstodsxss has joined #linux-sunxi
BenG83 has joined #linux-sunxi
<foxx_>
downclocked to 648MHz, no difference from 672MHz
ndtuldstodsxss has quit [Remote host closed the connection]
enrico_ has quit [Quit: Bye]
<ssvb>
foxx_: 648MHz is just a single step down from 672MHz and may be not enough, trying ~600MHz is a lot more interesting
<ssvb>
foxx_: still in your case it looks like the DRAM setup alone is unlikely to be (the only) problem
Wizzup has quit [Ping timeout: 276 seconds]
Wizzup has joined #linux-sunxi
jemk has quit [Ping timeout: 260 seconds]
jemk has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser>
foxx_: Do you power the board through Micro USB?
mossroy has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
Mr__Anderson has quit [Remote host closed the connection]
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
tkaiser has quit [Ping timeout: 260 seconds]
reinforce has joined #linux-sunxi
<foxx_>
ssvb: looks like you're right about dram. i'll try different steppings anyway. but when i try to set 600mhz it rejects to boot and considers 160mhz dram clock
tkaiser has joined #linux-sunxi
<foxx_>
tkaiser: yes, via micro usb
premoboss has quit [Ping timeout: 258 seconds]
fdcx has quit [Ping timeout: 250 seconds]
Gerwin_J has joined #linux-sunxi
fdcx has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
JohnDoe_71Rus has quit [Read error: No route to host]
apritzel has quit [Ping timeout: 244 seconds]
GatoMiador2 has joined #linux-sunxi
tsuggs has joined #linux-sunxi
premoboss has joined #linux-sunxi
fdcx has quit [Ping timeout: 240 seconds]
GatoMiador2 has left #linux-sunxi [#linux-sunxi]
<longsleep>
The sunxi-drm driver either has a memory leak for cma or it does not release its memory so its still usable continues afterwards
<longsleep>
Anyone can offer insight how to "view" whats allocated with cma?
<longsleep>
i Would rather avoid having to boot with cma=256M :/
Gerwin_J has joined #linux-sunxi
<ssvb>
longsleep: maybe add a few debugging prints?
<longsleep>
ssvb: yes sure, i was more hoping for some userspace tool which prints something useful :)
fdcx has joined #linux-sunxi
premoboss has quit [Ping timeout: 276 seconds]
<tkaiser>
foxx_: In case you did not already try to check/exchange USB cable between PSU and board. Or use Euler connector to power the board.
<ssvb>
tkaiser: if I understand it correctly, foxx_ has two boards and already tried to swap the cable & psu between the working one and the failing one
<ssvb>
but yes, a weak psu and/or a high resistance usb cable is still a possibility, because the boards just may have different tolerances to adverse conditions
<tkaiser>
ssvb: _If_ he also exchanged the cable then it's a different story.
<tkaiser>
ssvb: I had to deal way to often with cases where PSUs have been exchanged but the (crappy) cable in between remained the same. And there are so many crappy USB cables around
<ssvb>
tkaiser: that's a good point
Gerwin_J has quit [Quit: Gerwin_J]
<ssvb>
tkaiser: regarding this stuff, probably the pmic can be configured a bit better, because according to the specs it can accept a rather low voltage as the input (was it 3.6V?)
<ssvb>
tkaiser: now apritzel has a working rsb code and can configure the pmic
<tkaiser>
ssvb: Pine64? IIRC you spoke of 3.7V in the past but I might be wrong. Anyway: Devices that need more than 10mA and use Micro USB for DC-IN are crap :)
<ssvb>
well, I did not look up the spec right now, so it's probably 3.7V
<ssvb>
but the Li-Ion battery is also a crappy power source with variable voltage, and the pmic has to deal with this crap gracefully
<ssvb>
maybe some of the configuration knobs in the pmic are set too paranoid and are shutting down the device prematurely?
BenG83 is now known as Xalius
<tkaiser>
ssvb: Agreed. But to be honest: I only tested this with AXP209 so far and there it works great (torturing a Lime2 a while ago). And I would think that settings/driver for AXP209 are more mature than those for AXP803 (?)
<tkaiser>
ssvb: Based on support requests in Armbian forums most problems are related to insufficent power supply (temporary undervoltage being responsible for freezes if you're lucky or weird random behaviour if not)
<tkaiser>
2nd source of problems: Crappy SD cards
<ssvb>
also it is maybe a good idea to check how the Ethernet PHY is powered up in Pine64
<Xalius>
I think apritzel fixed that in the ATF, switch on SW1 output to power the PHY
<tkaiser>
ssvb: If it's Pine64+ / RTL8211E then this PHY needs a huge amount of power
<foxx_>
tkaiser: Pine64+ / RTL8211E
<foxx_>
already changed cables and power sources
<ssvb>
foxx_: what is the mA rating of you power source?
<foxx_>
2A
<tkaiser>
foxx_: If I were you I would try to power the board through Euler connector with Dupont jumper wires. Just to ensure that it's no power problem.
<foxx_>
the plans are: 1) to try bsp-enabled distro 2) try to measure voltages on board
<foxx_>
tkaiser: also an option. currently i don't know how to do that, but alternative power source is good idea, will check datasheets
<tkaiser>
The Micro USB connector has so tiny contacts and sooooooo much problems are related to this connector that I simply would try to avoid it.
<KotCzarny>
um
<KotCzarny>
isnt 'huge amounts of power' suggesting load?
<KotCzarny>
in idle it should work nevertheless
<tkaiser>
foxx_: check linux-sunxi wiki, powering should be explained there
<tkaiser>
KotCzarny: Depends on the board in question.
<foxx_>
KotCzarny: I cannot say whether the load is the reason of disconnects or not anyway
<tkaiser>
ssvb: That's not fair! :)
<KotCzarny>
foxx: killcores and check? got any usb meter maybe?
<ssvb>
if the cpuburn program instantly deadlocks, then the power supply and the usb cable are not very good
<KotCzarny>
foxx: also, are both boards identical in config?
<foxx_>
KotCzarny: 1:1 identical
<foxx_>
if dd don't lie
<tkaiser>
foxx_: Try cpuburn-a53 with longsleep's Ubuntu image. But it might shutdown both boards when powered through Micro USB :)
<foxx_>
the boards run ok under the load, so i'm unsure it's related to power source
keh has joined #linux-sunxi
<foxx_>
I mean, both boards performed some gentoo ebuilds already, no other issues were identified
<ssvb>
tkaiser: well, fair or not, it's best to ensure that the board survives under a heavy stress test, because then it's likely to be able to handle normal loads too
<KotCzarny>
visually check the eth port, quality of soldering, anything unusual (like crooked elements, etc)
<foxx_>
already did it
<ssvb>
tkaiser: and if it's too heavy, then the CPU clock frequency can be limited a bit
<foxx_>
found one potential bad soldering or maybe small flux leak near rtl8211
<ssvb>
foxx_: gentoo ebuilds are a relatively light workload
<foxx_>
ssvb: emerging gcc with -j5 is not enough?
<KotCzarny>
nope
<ssvb>
foxx_: they are nothing like multithreaded multimedia transcoding or a dedicaded cpuburn
<foxx_>
ok, then its time to run cpuburn as a separate test
tkaiser has quit [Read error: Connection reset by peer]
<foxx_>
now dd-ing android image onto sdcard just to ensure this is definitely hw issue
<foxx_>
or power issue, or anything else
<KotCzarny>
i bet on hw problem
tkaiser has joined #linux-sunxi
iamfrankenstein1 has quit [Ping timeout: 240 seconds]
<tkaiser>
ssvb: Do you know anything comparable to cpuburn-a7 for RPi Zero (or any of the RPis using the ARMv6 SoC)?
<tkaiser>
Goal is to put as much load on the CPU core as possible
<ssvb>
tkaiser: I haven't tried to implement it, but the power consumption is expected to be rather low for ARM11
<ssvb>
it's a single core running at a low clock frequency and has no NEON
<tkaiser>
ssvb: Ok, then I skip this test and focus on more realistic 'real world' workloads
<tkaiser>
Have been able to get a RPi Zero for less than 30 Euros!
<ssvb>
wow, only ~6 times more expensive than advertised!
<tkaiser>
ssvb: And it only took a few months. Still had to order from UK since the cheapest available offer in Germany was 40Û (useless 'starter kit' as usual)
<KotCzarny>
o.O
<KotCzarny>
and to think i managed to grab opipc for 8.5usd
<tkaiser>
Well, RPi Zero this time wasn't that expensive. And it's good this board has been not in stock or way too expensive before since the only use case I have is 'HW accelerated video encoding'.
<tkaiser>
Now ordered the new variant with CSI camera connector. The special cable needed costs as much as the board. And shipping to my country costs more.
<tkaiser>
But since we're at Armbian are preparing low power settings for the new H3 board (Nano Pi NEO and NanoPi Air) I want to ensure that we can get these H3 board as low as RPi Zero when it's about consumption
<ssvb>
tkaiser: does it matter much?
<tkaiser>
ssvb: Well, I'm investigating how H3 power consumption can be lowered. And the approach is interesting if you compare with RPi.
<tkaiser>
Since when you limit a H3 board to RPi Zero (or A/A+/B/B+) level then it really consumes less. DRAM clock at 264 MHz, single CPU core at 912 MHz helps a lot
<ssvb>
I don't see much sense unless you are powering it from a rechargeable battery or a solar panel :-)
apritzel has joined #linux-sunxi
<tkaiser>
ssvb: Well, the use case is 'IoT device' and power calculations if you want to use a bunch of these boards. Please keep in mind that the small Orange and NanoPi are really cheap unlike RPis. So you might want to power 20 of these with a 5V/5A PSU (through PoE ;) )
* vagrantc
sees plenty of use case for battery and/or solar powered boards
<tkaiser>
People start to replace Arduinos and stuff like that with fully blown Linux boards. And H3 boards become dirt-cheap
<ssvb>
tkaiser: wouldn't using something based on Cortex-M be better for IoT?
<ssvb>
or Arduinos, if they are good enough for the job
<tkaiser>
ssvb: I will answer this question as soon as the RPi Zero arrives. People reported they got consumption with this board as low as 80mA/5V. I managed the same with an Orange Pi Lite. But I don't trust in my measurements (using AXP209 and a Banana Pro as PSU) so I have to compare with RPi Zero
<tkaiser>
Being able to use a board that consumes not that much (below RPi Zero level) that can unlock more than RPi 2 performance when needed... is nice IMO
Mr__Anderson has joined #linux-sunxi
<foxx_>
tkaiser: what performance do you expect from IoT thing?
<tkaiser>
foxx_: None :)
<foxx_>
so the goal is just low power consumption?
<tkaiser>
foxx_: more or less. Half a year ago Orange Pi boards were blamed for heating up like hell and being inefficient. Then we started to check what's relevant and now it seems these little beasts are also suitable for low power useage. And still being able to unlock full performance simply by adjusting settings from user space.
<ssvb>
tkaiser: a Cortex-M4 board blinking one LED consumes ~20mA from 5V here (but my power meter is way too inaccurate)
<tkaiser>
ssvb: My measurement setup is also too inaccurate. But a single core Cortex-A7 (H3 ;) ) has been reported consuming as less as 80mA when idling around with nearly everything disabled.
Gerwin_J has joined #linux-sunxi
<ssvb>
tkaiser: it might be fun to do a similar LED blinking power consumption test with the OpenRISC core in Orange Pi PC :-)
<ssvb>
tkaiser: of course, with the ARM core shut down
<tkaiser>
ssvb: I already talked about that potential Allwinner SoC use case: Shutdown ARM cores and let AR100 do the job :)
<tkaiser>
KotCzarny: The OpenRISC core runs in parallel and currently with legacy kernel takes over when H3 is sent to 'deep sleep' (no PMIC --> AR100 controls everything)
<KotCzarny>
tkaiser, but both can be ran at the same time?
<KotCzarny>
(with careful resource splitting)
<tkaiser>
They run at the same time and do different stuff
<foxx_>
once upon a time I had an idea to automate my home by myself with some kind of dev board like pine/rpi/bbb/wtf. even solder some schematics to control power lines via gpio. the more ideas to come, the more powerful board I was needed...
<tkaiser>
With mainline kernel AR100 can run totally independent (and I would believe ssvb has not just one use case for this on his desk)
Mr__Anderson1 has joined #linux-sunxi
<foxx_>
for instance, motion detection
<ssvb>
tkaiser: regarding the use of AXP209 for measuring the current, I had a very old patch for the 3.4 kernel which increased the sampling rate and did averaging in the kernel
<KotCzarny>
foxx: got any nice selflocking relays source?
<tkaiser>
foxx_: PIR sensor or 'motion' makes the difference ;)
Mr__Anderson has quit [Ping timeout: 258 seconds]
<foxx_>
KotCzarny: my powerline schematics were based on optopairs+simistors
<foxx_>
tkaiser: no PIR, real motion detection from camera source for security reasons
<ssvb>
tkaiser: that was before the cheap power meters became available on ebay and aliexpress :-)
<tkaiser>
ssvb: Thanks, will check that. But since I want to measure the effect of different cpufreq settings having the 'race to idle' concept in mind I really need average consumption values that are based on 30 and 60 minutes (or even 24 h and run for a week -- normally I lack patience but this use case is special)
Mr__Anderson has joined #linux-sunxi
Mr__Anderson1 has quit [Ping timeout: 258 seconds]
<ssvb>
tkaiser: then you need an external power meter, because running something on the board itself disrupts the measurements
<ssvb>
tkaiser: as for the ar100, I have an unpublished sunxi-tools branch with special support for ar100 since like half a year ago
<ssvb>
tkaiser: one difficulty is that it's a solution looking for a problem :-)
<ssvb>
I also tried to compile and run the CoreMark benchmark on AR100 a week ago (as an example of a "bigger" application), but have encountered some troubles which need debugging
<tkaiser>
ssvb: Problems for AR100 based solutions will come ;) And regarding my measurement setup: I try to measure consumption of a H3 board (OPi Lite in this case) and use two other boards: Banana Pro as moniotoring PSU and an Orange Pi PC where serial console is connected to so it does not influence power measurements. Weird setup but since I have too much boards lying around it's not problem
Gerwin_J has quit [Quit: Gerwin_J]
<tkaiser>
ssvb: Do you have a rough estimate in which performance region this OpenRISC core is playing?
<KotCzarny>
atari 65xe
<KotCzarny>
;)
<ssvb>
tkaiser: if I manage to run CoreMark (in a way that it generates correct results), I'll push the resulting score to http://www.eembc.org/coremark/index.php :-)
<tkaiser>
ssvb: Well, think about. These dirt-cheap H3 boards when running only on AR100 with reduced clocks consumes less than 0.4 (according to my power meter ;) ) Tinkerers would love to get a data logger running at this consumption level being able to wake up 4 ARM cores each running at 1.3GHz on demand :)
<apritzel>
tkaiser: yeah, I was always thinking that that arisc should run some realtime OS, possibly alongside Linux
<apritzel>
maybe something like that BeagleBone PRU
<apritzel>
which many people seem to like
<ssvb>
apritzel: that's a very good point, maybe we should look at the BeagleBone PRU use cases and see if we can do the same
<tkaiser>
apritzel: ssvb: If I understood correctly with the current mainline A64 implementation AR100 can be used absolutely independant from the ARM cores?
<ssvb>
tkaiser: it depends on the SCPI implementation, but apritzel can probably explain better
foxx_ has quit [Ping timeout: 276 seconds]
<ssvb>
if we don't need the OpenRISC core to relay the mailbox messages, then the OpenRISC core can run completely independently from the Linux OS running on ARM
jernej has quit [Ping timeout: 240 seconds]
<apritzel>
ssvb, tkaiser: yes, I want to keep the OpenRISC free, if possible
reinforce has quit [Quit: Leaving.]
<apritzel>
if the arisc proves to be overly useful as management processor, we can provide two versions: one with the arisc being a management processor supporting Linux (for server use cases, for instance), the other with the arisc being free for the user
<apritzel>
and the DT advertises what's implemented
<tkaiser>
Uh lala, I'm somewhat impressed by PRU and DT overlay stuff possible with the BeagleBones.
Mr__Anderson has quit [Remote host closed the connection]
physis has joined #linux-sunxi
OverCR has quit [Quit: Leaving.]
paulk-collins has quit [Quit: Leaving]
mossroy has quit [Quit: Leaving]
robogoat has joined #linux-sunxi
physis has quit [Remote host closed the connection]
Gerwin_J has joined #linux-sunxi
physis has joined #linux-sunxi
physis has quit [Ping timeout: 250 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
al1o has joined #linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
Xalius has quit [Quit: Leaving]
premoboss has joined #linux-sunxi
MXfive has joined #linux-sunxi
MXfive has quit [Read error: Connection reset by peer]
yann|work has quit [Ping timeout: 244 seconds]
fdcx has quit [Ping timeout: 244 seconds]
nove has joined #linux-sunxi
fdcx has joined #linux-sunxi
<nove>
longsleep: please don't forget to give a word to inform your users of the "license-issues" that exist in the images that you are distributing (this here also includes lennyraposo), please do inform, should only for in the case of one user thinking that is all ok, using in a product, and then having problems by being asked to comply with the gpl, and then that uninformed user accuse this community as a facade to give excuses to continue violating gpl
<nove>
longsleep, lennyraposo, the issue of libhdmi blob that links with gpl licensed kms/drm driver is still (to my aware) not resolved
<nove>
i know this is a pain, and is good to be kindly and discuss this gpl violations in private
physis has joined #linux-sunxi
<nove>
but from my experience, in this linux-sunxi community which initialy avoided to publicize the cedarx-license-issues (as a way to not scare), only what we got, was ignoring our reverse-engeenering work for a 100% open-source driver, and instead there was a choice for the continue use of the cedarx-license-issues-library
<nove>
for this reason, i don't see what everyone wins, by being quietly about the existence of gpl violations
Michal has quit [Ping timeout: 260 seconds]
<nove>
if we call ourselves an open-source community, we can not ignore issues or "fool" technical clueless users by keeping them uninformed
<nove>
and that is what the wiki is for, to collect any information about sunxi
<lennyraposo>
I will get Jet from AllWinner to address that matter asap
<lennyraposo>
libhdmi
<nove>
lennyraposo: please, and thanks
<lennyraposo>
could have sworn I saw a license in the latest sources package for libhdmi