<Ntemis>
i have been hammering my pi pc and looks stable as rock
<miasma>
do those settings improve perf or is it just increasing frequency and increasing latency?
<Ntemis>
yeap performance is better
<miasma>
ok
<Ntemis>
i get 3-4fps more in 3d games
<Ntemis>
and system feels more snappy
<Ntemis>
overall
<Ntemis>
finally i did it yay
<apritzel>
I still don't get it: from the 24 entries in that table only 5 had issues with 672 MHz, so you are excited that you are hit a rough 19/24 probability?
terra854 has joined #linux-sunxi
<ssvb>
apritzel: well, I kinda suggested how to deal with overclocker crazies a long time ago: we can just store the DRAM and CPU "speed grade" info in the SPL header
<ssvb>
apritzel: we can have it safe by default, but certain supplementary tools could run stress test the hardware and adjust this header (while still keeping a bit of headroom for safety reasons)
<ssvb>
apritzel: and yeah, some people are really upset and make a lot of noise about not pushing specifically *their* hardware to limits with the *default* settings just because some other devices can't handle it safely
<apritzel>
ssvb: I am still looking for the smiley in the "oh yes they are" line above ;-)
<miasma>
why can't they just buy faster boards
<ssvb>
apritzel: in fact it's not so fun, they tend to be rather persistent and try to advertise their "improved" distro images and other crap to the other unsuspecting users
<apritzel>
ssvb: I know, and am worried too
<apritzel>
I am still puzzled that the parameters in question are from an OpiPC_2_
<ssvb>
it might be probably okay
<ssvb>
for example, the parameters from a10 could be used on a20 and the other way around
<apritzel>
I still rather have some confidence about it: why are those values better?
<apritzel>
I can easily believe that the AW values are not good
<ssvb>
I think that the values from fex are even not used at all
<ssvb>
only the dram clock speed changes and the rest is likely kept from the bootloader
<ssvb>
but considering that there is this arisc blob, we can't be completely sure in anything
<apritzel>
I have no clue about fex, but boot0 picks exactly those values from the beginning of itself
<apritzel>
(that's where I copied them from for the libdram blob)
<apritzel>
which is all based on work from that ssvb guy ;-)
<ssvb>
my understanding is that there is some allwinner tool, which takes settings from the fex text file and writes them to the boot0 header
<ssvb>
so yes, they are not completely useless in the fex file, but the bootloader and kernel are not reading them directly from there
<Ntemis>
for the record am not an overclocker crazie am just trying to use the board the way is meant to be used by factory
<ssvb>
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck
<miasma>
there might be some market potential for a rice^Wgentoo distro for allwinner boards :) maybe with builtin system service support for 16x2 lcd screens showing the memory and cpu timing parameters :)
<Ntemis>
ssvb: u are just being pesimistic here
<apritzel>
Ntemis: you sure mean realistic?
<Ntemis>
no way hose
<Ntemis>
:)
<apritzel>
miasma: yeah, and the memory timings are re-trained every 30 seconds to accommodate for the changed temperature
<miasma>
^_^
<Ntemis>
i have nothing to proof here
<Ntemis>
if you want test the settings is that simple
<Ntemis>
gnight gents
Ntemis has quit [Remote host closed the connection]
<miasma>
apritzel: tbh, i've seen some talks from memory bus designers and I think they're considering something like that next. the drams don't work optimally atm
<ssvb>
well, that's how it works
<ssvb>
a fast zq calibration is run during the dram refresh cycles
<ssvb>
to accommodate for the changed temperature
<ssvb>
that's a real thing
<apritzel>
oh, btw: The BPi-M64 booted Ubuntu 16.04 from eMMC
<ssvb>
very nice
<MoeIcenowy>
apritzel: with mripard's hack?
<miasma>
ssvb: i don't remember the details, but i think the idea was to have some kind of table of hw properties in the memory modules (for different temperatures and voltages) and the system would adjust the memory dynamically based on the load
<apritzel>
MoeIcenowy: yeah
<miasma>
ssvb: but maybe something like that already exists in lpddr4
Rhiannon has joined #linux-sunxi
<apritzel>
feels a bit like a trick still: "Look Ma, it boots without an SD card!"
Colani1200 has joined #linux-sunxi
<Rhiannon>
Question: The Sunxi community is an open source software community dedicated to providing open source operating system support for Allwinner SoC based devices.
<Rhiannon>
Would supporting FreeRTOS for Allwinner SoC be part of what the community is doing ?
Colani1210 has quit [Ping timeout: 244 seconds]
<Rhiannon>
...or is this irrelevant?
bugzc has joined #linux-sunxi
<apritzel>
Rhiannon: isn't it linux-sunxi, actually?
<ssvb>
Rhiannon: feel free to add the information about running FreeRTOS on Allwinner devices to the linux-sunxi wiki
<apritzel>
Rhiannon: ;-)
<apritzel>
but in general people here are open to different OSes
<apritzel>
Rhiannon: Go figure, sometimes even BSD people are seen here! ;-)
<Rhiannon>
@ssvb, I see thx.
<Rhiannon>
open-minded community :-)
<ssvb>
it is not exactly restricted to Linux only
perr has joined #linux-sunxi
<Rhiannon>
Was not sure, this is why I asked.
<ssvb>
just Linux is the most popular free OS for this hardware
<miasma>
does it make much sense to run freertos on allwinner devices? they have quite lot of resources
<Rhiannon>
@miasma: I would say yes, for learning purpose.
<miasma>
ok
<apritzel>
miasma: if you are after the second "r" ....
<apritzel>
"rt", actually
<MoeIcenowy>
someone may really need a FreeRTOS on sunxi
<Rhiannon>
I think looking at/writing a driver for FreeRTOS is less demanding then for u-boot, and of course Linux, in terms of prerequisites.
<ssvb>
maybe you can even run an RTOS and Linux simultaneously (on different cores)
<beeble>
someone could port freertos to openrisc :)
<Rhiannon>
You are right, and somebody probably already did that.
<beeble>
ok, there is already a or1k port
<apritzel>
has anyone tried Jailhouse on Allwinner devices?
<Rhiannon>
Starting learning programming hardware with Linux when you don't know anything is some kind of 'Why Johnny can't light a LED' problem: see http://www.salon.com/2006/09/14/basic_2/
<beeble>
i had kvm running, but thats nothing special i think
<beeble>
wens: isn't living in your timezone not a little fuzzy anyway?
<wens>
MoeIcenowy: you slept for like 4 hours?
<MoeIcenowy>
In fact, 0
<wens>
beeble: how so?
<MoeIcenowy>
because of depression :-(
<beeble>
wens: there is only one in the whole country right?
<beeble>
could be wrong :)
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<wens>
beeble: uh, i think so
<wens>
beeble: i'm on the wrong side of the straight for that
<wens>
MoeIcenowy: no offense
apritzel has quit [Ping timeout: 246 seconds]
<MoeIcenowy>
wens: I don't care this
<wens>
:)
<MoeIcenowy>
just now testing some OpenGL-based games on my Q8 tablet
<MoeIcenowy>
one of the games failed to load all textures because of the 512MB RAM ;-)
<wens>
beeble: even singapore is UTC+8 though
<beeble>
read the wilipedia article and still not sure how this is handled irl. do working hours shift with the location?
<MoeIcenowy>
I think I should now work on A33's LVDS support
<wens>
plaes: ^
<wens>
MoeIcenowy: plaes has some LVDS patches
<MoeIcenowy>
yes
<MoeIcenowy>
I remembered his is for A10
Rhiannon has quit [Quit: Page closed]
<wens>
it should be the same... the tcon hasn't changed at all
<wens>
only difference in later SoCs i think is that they realized you can't use both channels in the same tcon at the same time
<wens>
so they gutted one of the channels
<MoeIcenowy>
seems that only A33 come with legacy DE and a single-channel TCON...
<wens>
the second channel is useless since it only outputs to the tv encoder or hdmi
<wens>
mipi dsi is tied to the first channel i think
<beeble>
after reading some other articles it confirms that people are just living by local time and don't care about beijing time. and because i found it on the internet this must be true
<wens>
lol
<MoeIcenowy>
beeble: see the real timezone
<MoeIcenowy>
people in GMT+6~GMT+10 still uses Beijing time
<MoeIcenowy>
but people in GMT+5- will prefer local time (but with Beijing time as wall clock time)
<beeble>
i can understand that concept, i have set all my pcs to utc :)
<wens>
MoeIcenowy: confirmed a23 also needs mipi ldo en fix
<wens>
though the CCU decided that pll-mipi should do 3.6 GHz, which is crazy...
ninolein has quit [Ping timeout: 256 seconds]
ninolein has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
pg12_ has quit [Ping timeout: 265 seconds]
pg12 has joined #linux-sunxi
<MoeIcenowy>
wens: when can you test A31?
deskwizard has quit [Remote host closed the connection]
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
Putti has quit [Ping timeout: 244 seconds]
lkcl has quit [Ping timeout: 260 seconds]
kaspter has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
lkcl has joined #linux-sunxi
leviathanch has joined #linux-sunxi
reinforce has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
gumblex has joined #linux-sunxi
ericxdu has quit [Read error: Connection reset by peer]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
ericxdu has joined #linux-sunxi
<wens>
MoeIcenowy: looks good
<wens>
time to do some patches
Gerwin_J has quit [Quit: Gerwin_J]
perr has quit [Quit: Leaving]
<MoeIcenowy>
wens: does pll-mipi fix makes your a23 drm driver work?
<wens>
yes
<MoeIcenowy>
oh that's the point :-)
<MoeIcenowy>
after you testing A31, I will make the CCU fix v2, and then you can push your drm patchset :-)
<wens>
why a v2?
<MoeIcenowy>
v1 contains only A33
<wens>
i already did patches for a23 and a31 :)
<wens>
did them as part of the test
<MoeIcenowy>
ok :-)
<wens>
and i should push the a31 fix asap, otherwise some vga resolutions don't work
<MoeIcenowy>
you tried this?
<wens>
yup
<wens>
1280x720 doesn't work otherwise
bobryan has quit [Ping timeout: 245 seconds]
<MoeIcenowy>
then I think you can squash all the 3 fixes to one patch
<MoeIcenowy>
the 3 similar SoCs suffer from the same problem
<MoeIcenowy>
(or at least one patchset
<wens>
sending them separately is ok i think
bobryan has joined #linux-sunxi
bobryan has joined #linux-sunxi
bobryan has quit [Changing host]
<wens>
sure they are related, but there's no dependecy
<wens>
* dependency
<MoeIcenowy>
thus my patch"set" will have only A33, and your will have A31/23
<wens>
sure
kivutar_ has quit [Ping timeout: 260 seconds]
kivutar has joined #linux-sunxi
kivutar has quit [Ping timeout: 260 seconds]
petr has quit [Ping timeout: 250 seconds]
kivutar has joined #linux-sunxi
petr has joined #linux-sunxi
msevwork has joined #linux-sunxi
kivutar has quit [Ping timeout: 260 seconds]
kivutar has joined #linux-sunxi
Putti has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
f0xx has joined #linux-sunxi
tkaiser has joined #linux-sunxi
Putti has quit [Ping timeout: 244 seconds]
massi has joined #linux-sunxi
<tkaiser>
longsleep: Did you hold a SoPine in your hands?
<longsleep>
tkaiser: yes i have one
<tkaiser>
longsleep: And where do you insert it? ;)
<longsleep>
tkaiser: it came with a adapter board :)
<terra854>
tkaiser: longsleep: SoPine?
<tkaiser>
longsleep: Ah, ok. For one module or more of them?
<longsleep>
tkaiser: one module
<tkaiser>
longsleep: That's boring
<longsleep>
tkaiser: yeah, its same size as the normal pine board with the slot instead of ram and soc
<tkaiser>
longsleep: ok, makes sense to develop stuff
<longsleep>
tkaiser: yeah, it works well with the normal images when using the compatible boot0 with covers the changed RAM
<tkaiser>
longsleep: IIRC vishnu added support for this DRAM type already to mainline u-boot (BPi M3)
<tkaiser>
longsleep: Would be interesting if they develop a baseboard where more than 4 modules can be inserted. With a switch IC on the board to interconnect the SoMs
<longsleep>
tkaiser: i doubt that, i guess they want this to be done by third parties
<tkaiser>
For this board 3/0 doesn't seem to be the best choice (high retransmit count). But I'll test with another one and will then collect results later.
<longsleep>
tkaiser: yay that is so much fun
<longsleep>
tkaiser: did you try it with the patch i applied in that branch?
<tkaiser>
longsleep: Real fun was the same test with OPi PC 2: Since I tested 256 times exactly same settings ;)
<tkaiser>
longsleep: Seems H5 BSP kernel in it's current state reads tx/rx-delay from sys_config.fex and ignores the DT settings I applied ;)
<longsleep>
joy
<longsleep>
how does the kernel get the fex file?
<tkaiser>
longsleep: Nope, ignored the patch so far and test with 'original' settings. But on 2 boards that are 'known to work'
<msevwork>
has anyone tried to put a small patch antenna on the wifi enabled orange pi boards :D
<tkaiser>
longsleep: That's the question I wanted to ask you ;) When you started with A64 BSP stuff one of the first things was to empty the fex file, right?
<longsleep>
does the h5 u-boot apply the fex stuff on top of the device tree it passes to the kernel or what?
Gerwin_J has joined #linux-sunxi
<longsleep>
tkaiser: yes, the fex file is not used by the a64 u-boot except for getting the u-boot accepted by boot0
<tkaiser>
longsleep: No idea but something like that might happen. At least all 8*32 different DT settings were gracefully ignored :)
<longsleep>
tkaiser: it might well be that the h5 u-boot does not have a device tree and loads the settings from fex and then applies them to the fdt before booting the kernel
<longsleep>
tkaiser: but i dindt have any time to look at the h5 bsp
<tkaiser>
msevwork: I destroyed Wi-Fi on OPi Zero when trying to test different antennas. But why worry? Xunlong sends a small and sufficient antenna with every Wi-Fi capable OPi out.
<jelle>
tkaiser: hmm how did you destroy it? too much current?
<tkaiser>
longsleep: No worries, it seems Xunlong pays someone for this work so he should do this stuff. I only want to give some hints.
<msevwork>
tkaiser did you test maximum range?
<msevwork>
for example i'd like to mount one outside my house
<msevwork>
for sprinkler controller purposes
<tkaiser>
jelle: No idea, but afterwards driver doesn't find the module on SDIO bus
<longsleep>
solar powered OPi Zero with a BBU to last the night would be awesome, anyone tried something like that here?
<tkaiser>
msevwork: I can't test any more. Period. Ask in Armbian forum. Wi-Fi currently works only with legacy kernel so there you might find answers. Latest Armbian image brings everything up automatically so you might get help there from OPi Zero owners
<msevwork>
tkaiser, not related to opi zero
<tkaiser>
longsleep: Sure
<msevwork>
also interested in other wifi enabled orange boards
<msevwork>
did you by any chance test any of those how far they reach?
<longsleep>
tkaiser: how large does the solar panel to be to provide enough power for 24/7 uptime?
<jelle>
doesn't the reach really vary per user (since walls might be different etc.)
<tkaiser>
msevwork: This here is more a dev channel. And I hate 2.4 GHz based Wi-Fi since in my area it's close to unusable. Any more questions?
<msevwork>
nope not currently
<msevwork>
:)
<tkaiser>
longsleep: The key to success is the power bank in between. Has to support charging while providing power to device and more importantly should start to provide power without the press of a button.
<silviop>
Suppose i have fully working tablet with mainstream kernel(4.9)/uboot (all working lcd/touch/PMU ecc ecc) is porting android possible for a normal user ?
Wizzup has quit [Remote host closed the connection]
<longsleep>
tkaiser: ah good point, that should be even doable with consumer stuff
<MoeIcenowy>
silviop: I did this kind of thing on Cubieboard1
<silviop>
You are not a normal user
<tkaiser>
longsleep: It depends, I read a lot of reviews where this is not the case. The power bank I used for these tests does it. And then it's simply solar panel <--> power bank <--> device and you're done.
<jelle>
tkaiser: but don't you want to have the board now when the battery is almost empty?
<msevwork>
someone already asked on the forums :)
<tkaiser>
jelle: 'now'?
<jelle>
tkaiser: *know
<jelle>
tkaiser: so you can power down the board when the battery is almost drained
<tkaiser>
jelle: Sure, that's why H3 isn't that great here. A33/R16 with PMIC would be the better choice since there PMIC can control voltage.
<KotCzarny>
or even better make board sleep and wake on timer?
<tkaiser>
jelle: So simply use overlayfs or something like that and ignore unsafe shutdown. And to be honest: I tried pretty hard to get SD card / fs corruption and never suceeded. This seems to be a Raspberry Pi 'feature'
matthias_bgg has quit [Ping timeout: 260 seconds]
<tkaiser>
jelle: Seriously: I test a lot new SD card images. And for a month or two I always pulled the plug. Not a single problem with FS corruption.
<jelle>
tkaiser: oh woah
huawei has quit [Ping timeout: 256 seconds]
<jelle>
I expected sd cards to be more 'crap'
<tkaiser>
jelle: Maybe related to Armbian default settings. 600 seconds commit interval. Reduces risk a lot obviously. You sometimes miss latest changes though...
<jelle>
aha
<silviop>
I have cubieboard1 (and 2) what android version did you port ?
<tkaiser>
jelle: But you're right. Boards with PMIC support would be the better choice since they can measure battery voltage/capacity. But I tried this with Olimex Lime A10 just to realize that this board doesn't get below 1W idle consumption. And OPi Zero can get as low as 400 mW when you disable unneeded stuff
huawei has joined #linux-sunxi
<tkaiser>
jelle: Maybe due to A10 being Cortex-A8, maybe since Olimex has more sophisticated stuff on their boards. Don't know
<jelle>
tkaiser: hmm haven't measured the C.H.I.P. power usage yet
Wizzup has joined #linux-sunxi
<jelle>
but I expect it to be ok, since it's made to be used with it
<msevwork>
actually I have another question, is it possible to add some sort of usb-ethernet adapter to the orange pi lite to get ethernet functionality?
<tkaiser>
jelle: But for this IoT stuff R16 boards with PMIC support would be the better choice since battery control. And CHIP's consumption isn't that great either (Cortex-A8)
<jelle>
tkaiser: exactly what I am going to do :)
<tkaiser>
msevwork: Sure. And you can also use USB Ethernet gadget mode for low distances. Faster than Fast Ethernet.
<jelle>
aren't the network pins exposed somewhere on the orange pi lite?
<tkaiser>
jelle: Nope
<tkaiser>
msevwork: With mainline kernel and an $6.50 Realtek GbE dongle OPi Lite as NAS exceeds 25 MB/s when serving from USB disk
<jelle>
mripard: yup that's really the benefit of the c.h.i.p. everything has been thought of :)
<tkaiser>
mripard: That's great
<tkaiser>
mripard: This should work with sun4i too?
<mripard>
tkaiser: yes
<mripard>
we only tested it on A20 though
<mripard>
but I don't expect any major differences
<tkaiser>
mripard: So my A10 Lime hasn't go to the bin ;)
<jelle>
lol
<mripard>
so for now, our PM is close to non-existent, but we'll work on improving things
<MoeIcenowy>
mripard: wow! suspend!
<mripard>
idle
<mripard>
actually
<mripard>
but it's called suspend in PSCI
<KotCzarny>
reminds me of HALT in pentiums ;)
<MoeIcenowy>
ah-oh
<wens>
KotCzarny: WFI is already supported with the generic ARM cpuidle driver
<mripard>
suspend will be much more tedious to implement, because we need to go over all the drivers and implement the functions to suspend and restore the device state properly
<mripard>
which is also a reason why I've been asking for the pm_runtime hooks for a couple of monthes, having it makes things much more easier and will result in power savings anyway
matthias_bgg has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #linux-sunxi
<jonkerj>
just out of curiousity: why are you working on PSCI/suspend in u-boot, and not in linux?
<jonkerj>
is it easier to develop, so you can later port it to linux?
<mripard>
so, the rationale was that PSCI already supports cpuidlee
<wens>
KotCzarny: did you get your lamobo-r1 working?
<mripard>
so if we had to support it for the A7 cores, we would have gone with PSCI
rah has quit [Ping timeout: 250 seconds]
<KotCzarny>
wens: by using older patch, the new dsa system is not working well enough for b53125
<mripard>
but since the code is so similar between the A20 and the A10 / A13
<mripard>
it makes no sense to duplicate it
<KotCzarny>
but: Linux lamobo 4.9.0-rc3 #9 SMP Thu Nov 3 19:35:15 CET 2016 armv7l GNU/Linux
<KotCzarny>
so i can wait now more safely for the proper driver now ;)
<mripard>
so, PSCI for everyone
wookey has quit [Ping timeout: 250 seconds]
rah has joined #linux-sunxi
wookey has joined #linux-sunxi
bugzc has quit [Ping timeout: 260 seconds]
Colani1200 has quit [Ping timeout: 245 seconds]
<wens>
KotCzarny: i'm using it in what i think was called "failed" mode
<wens>
as in the switch was just brought up, and passes all traffic
<wens>
and then just use eth0
<wens>
but that sucks :(
<KotCzarny>
wens, a bit. if you want i can dig up patches im using (from armbian)
<wens>
KotCzarny: that uses the old vendor driver, right?
<KotCzarny>
yes, swconfig
<KotCzarny>
but if you dont have a need for so called 'wan' port, it doesnt matter
jbrown has quit [Ping timeout: 246 seconds]
<KotCzarny>
in a way this switch isnt going to get any better unless you add tiny eeprom (u21 afair), so it would rememeber last config
<KotCzarny>
so no matter which linux driver you are using (apart from maintenance)
<KotCzarny>
are you good with soldering? ;)
<wens>
nope
<wens>
KotCzarny: btw, what marking does your board have? mine says Lamobo R1-SD_V3
<KotCzarny>
hmm, im away from home atm
BuddyZhang1 has joined #linux-sunxi
BuddyZhang1 has quit [Client Quit]
BuddyZhang1 has joined #linux-sunxi
fkluknav has joined #linux-sunxi
jbrown has joined #linux-sunxi
msevwork has quit [Quit: Leaving]
Putti has quit [Ping timeout: 248 seconds]
<premoboss>
hi, i need to use 485 serial line on nanopi neo (as 232 with only RX and TX it work well, but now i need cts and rts signals). i use armbian kernel 3.4.112. i modified script.bin activating uart_rts = port:PA02<2><1><default><default> and uart_cts = port:PA03<2><1><default><default>. uart_type = 4. converted into script.bin and replaced the original one. i have no another 485 device at the moment to test with, so I reboot, st
<premoboss>
art minicom on uart2, then i test with oscilloscope cts/rts pins and press randomically on keyboard to generate data flow but nothing happens, no change of status i can see on both rts/cts (at least one shound works). where is my fault? maybe it is needed to recompile kernel to activate some parameters? maybe minicom need to be aware tro user 485 mode? i see on minicom configuration and hardware flow control is enabled. no oh
<premoboss>
er idea i have, some hel here?
<mdsrv>
join cts and rts together
<mdsrv>
then test
<mdsrv>
look for null modem configuration
<mdsrv>
also be sure u r using a proper device file
<premoboss>
mdsrv, thansk, one question: what do you mean with "device file"? maybe the /dev/ttyS2?
vagrantc has joined #linux-sunxi
Putti has joined #linux-sunxi
<premoboss>
it, S1 receive) does not work. this is strange to me because if S2 is really 485 mode enabled, it should use cts/rts
<premoboss>
no, loopback does not work (tct-.rts adn tx-tx). i did another test: i use both /dev/ttyS1 and /dev/ttyS2 on 2 different minicom istances, (and also join tx and rx viceversa) and in 232 configuration thay can talk each other properly. then i modified script.bin to activate 485 mode on /dev/ttyS2. reboot. now in the same test configuration, S1 (232) can trasmit to S2 (485) and S2 receive correctly data. but viceversa (S2 transm
vagrantc has quit [Quit: leaving]
gianMOD has joined #linux-sunxi
gianMOD has quit [Client Quit]
gumblex has quit [Quit: Bye.]
issalig has joined #linux-sunxi
Putti has quit [Ping timeout: 268 seconds]
issalig has quit [Quit: Page closed]
gumblex has joined #linux-sunxi
<tkaiser>
longsleep: The stuff you're currently running on your Pine64s... would this also run on Amlogic? S912?
mzki has joined #linux-sunxi
Putti has joined #linux-sunxi
<hramrach>
KotCzarny: espressobin has 1 SATA and 1 USB3
<hramrach>
not that impressive
<KotCzarny>
hramrach: add one minipcie slot you can probably use for another sata
<KotCzarny>
(unless its crippled usb only version)
<hramrach>
those boards are really ahrd to get
<jelle>
but do you get a free espresso?
<hramrach>
nope
ErwinH has quit [Ping timeout: 260 seconds]
<hramrach>
so probably better getting proper NAS with drive bays included
<KotCzarny>
also. what's impressive is actual data throughput (compared to other arm solutions in similar pricing)
<jelle>
hramrach: how is mainline support?
<hramrach>
no idea about ESPRESSObin
<jelle>
". Theinitial kernel is 4.4 and the device has mainline kernel support."
<hramrach>
the CPU in NAS542 has also mainline support but there is no alternate rom so far
<tkaiser>
KotCzarny: the MiniPCIe there is really PCIe only. So no simple switch but mPCIe cards with 2 SATA ports and an own controller exist
<hramrach>
also it's not marvell so it's better to look up the benchmarks. Both NAS542 and the mPCIe SATA
<KotCzarny>
tkaiser, would msata ssd work/boot from that slot?
<terra854>
tkaiser: Just wondering though, what does <0x9e 0xb 0x3 0x6 0xffffffff 0xffffffff 0x0> mean?
<tkaiser>
KotCzarny: Nope, unlike ARMADA 38x you can't do SERDES voodoo there and choose between SATA and PCIe. It's PCIe. So not one SATA but up to two SATA ports using the right controller in the slot
Gerwin_J has quit [Quit: Gerwin_J]
<KotCzarny>
tkaiser, asking specifically about msata because it would minimize cable clutter
diego__ has joined #linux-sunxi
<tkaiser>
terra854: Compare with the fex links I sent yesterday. Regarding '0xb 0x3': that's PL03. L is the 12th letter in the alphabet so it's 11 (0xb -- a is 0, b is 1, l is 11) and 0x3 is 3
<tkaiser>
KotCzarny: Still no. No SATA means no mSATA.
diego_r has quit [Ping timeout: 252 seconds]
<KotCzarny>
there are mpci ssd too, though they are more tricky to get to work, hum.
<tkaiser>
KotCzarny: When I searched around I realized that there _were_ mPCIe SSDs.
<KotCzarny>
hehe
<KotCzarny>
old eee pcs shouldnt be too pricy nowadays for part scrape
<KotCzarny>
still, there is a matter of getting it to work
<terra854>
tkaiser: So where is the A64's power key located at? PL03?
<tkaiser>
KotCzarny: Sure, old and slow hardware is the way to go when it's about misusing the mPCIe slot. ;)
<hramrach>
The off-the-shelf NAS solutions are probably less powerful than ESPRESSObin
<hramrach>
but they come with 4xsata
<KotCzarny>
tkaiser, its more about minimizing cable clutter while still having better-than-sd rootfs
<tkaiser>
terra854: Neither know nor care. What's written in schematics.
<hramrach>
it may very well be comparable
<KotCzarny>
hramrach: do they have 2 gbit ports (at least) ?
<hramrach>
that too. some ofthem
<tkaiser>
hramrach: What do you need 4 SATA ports for?
<hramrach>
thechnically nothing
<KotCzarny>
1 sata for rootfs, 2 sata for raid? 1 sata for plug'n'play fun
<hramrach>
2 ShouldBeEnoughForEverybody
<tkaiser>
KotCzarny: RAID? Seriously? Under your bed or where?
<hramrach>
so basically for drive replacement
<hramrach>
raid 1 sounds like good idea for NAS
<KotCzarny>
tkaiser, sure, as if usb-raid being state-of-the-art solution
<hramrach>
hm, DNS-340L has 4 drive bays, 2xglan, and 1xUSB3
<tkaiser>
hramrach: raid 1 sounds like braindead since it's only about 'business continuity'. Nothing the average dev board user should have to care of.
<hramrach>
unless you are actually using it as NAS
<KotCzarny>
hramrach: and the price tag?
<hramrach>
which is what the Marvel chips end up in quite often
<hramrach>
depends on location I guess
<hramrach>
I see the price in something that's about as useful as rupees
<KotCzarny>
seems out of production already
<tkaiser>
still braindead as hell. It doesn't protect you for the usual sources of data loss/corruption. But this whole discussion is way too useless and especially pretty off-topic here. Use a good FS, do snapshots, send the snapshots to a connected USB 2.0 disk and you do more good then any raid 1 joke ever can.
<hramrach>
KotCzarny: so they probably respin a new one with new letter
<KotCzarny>
for that price you can have clearfog board
<KotCzarny>
even clearfog pro version
<hramrach>
KotCzarny: yes, you can. That has no SATA to start with and no drive bays
speakman has joined #linux-sunxi
speakman has joined #linux-sunxi
speakman has quit [Changing host]
<KotCzarny>
adding 2 minipci boards would bump sata count to 4
<hramrach>
tha's not $200 then
<hramrach>
and still no drive bays
<KotCzarny>
just slap it into some rack or itx pc case?
<longsleep>
tkaiser: depends on the Kernel - if mainline then certainly yes
<longsleep>
tkaiser: its nothing special, i just need namespaces, containers and hyp for armhf and arm64 :)
<longsleep>
tkaiser: so it seems like the s912 also uses Kernel 3.14 which i will not touch as it is EOL
<tkaiser>
longsleep: ok, just thought about this since S912 is 8 core and devices with 3GB DDR4 become available (neither cheap nor small, TV boxes ;) )
<tkaiser>
hramrach: If you think about RAID you might also think about reliability? If so then it would be a good idea to care about data integrity also? If so you end up with eMMC memory being needed (no eMMC, no automatic scrub) and then you end up with a HP Microserver and ZFS or btrfs on it.
<longsleep>
tkaiser: well, the community for amlogic socs is not as awesome as the sunxi community :)
<hramrach>
tkaiser: also how is emmc connected to automatic scrub?
<tkaiser>
hramrach: You get way more for your money than all the 4 port NAS boxes give you (only the highend variants come with ECC -- not eMMC, silly me)
<tkaiser>
longsleep: True, you would've to rely on this 3.something now. There's a thread in Armbian forum I don't follow but it seems they already got Linux somehow running on S912
<longsleep>
tkaiser: well amlogic released the android sdk for it afaik
<hramrach>
hm, the microserver is about the same price as the DNS-340L
<tkaiser>
hramrach: Check prices of used N54L, with a modified BIOS you get 6 SATA ports. And using FreeNAS even Aunt Tilly can deal with it
<tkaiser>
hramrach: ECC vs. crappy. I'll never understand why all the people so keen on RAID simply give a sh*t about data integrity
<hramrach>
and given there is HP behind it it is probably better server
<beeble>
a hp microserver also comes with ilo
<hramrach>
hm, but it's slightly more expensive without the pricy ECC ram
<hramrach>
tkaiser: well, memory corruption tends to be less common than drives dying
<KotCzarny>
not in the low-prices world
<KotCzarny>
;)
<hramrach>
given it costs about as much as the microserver it's not low-price
<KotCzarny>
im talking about allwinner here
<tkaiser>
hramrach: that's what backup's for. Don't confuse data security with availability. And please let us stop this off-topic stuff now. One final word: Explore the possibilities of btrfs with mainline kernel, do snapshots, send them to another disk (connected to the same machine or through VPN on another continent). Way better than stupid RAID 1
<hramrach>
problem with that is availability due to occasional btrfs corruption
<hramrach>
that's still a thing
<tkaiser>
Even the cheapest Allwinner SBC with mainline kernel + btrfs does a better job than any expensive NAS box relying on ext4 and this RAID BS
<hramrach>
as much or even more so than AW memory corruption
<longsleep>
tkaiser: is there any sunxi kernel which works reasonably well with somewhat recent btrfs version?
* longsleep
prefers zfs as its easy to get the latest version
<tkaiser>
longsleep: I wouldn't try that. But I read the fixes from version to version so I'm already scared to use 4.4 with btrfs ;)
BuddyZhang1 has quit [Quit: Page closed]
<hramrach>
I am already scared to use git tip with btrfs
<longsleep>
tkaiser: yes thats what i mean, btrfs might be fine but only with kernels 4.4 and later imho
<longsleep>
and zfs is really easy to get now that ubuntu ships dkms packages
diego__ has quit [Remote host closed the connection]
diego__ has joined #linux-sunxi
<tkaiser>
hramrach: You run in troubles with btrfs/ZFS as soon as you can't trust data. In memory corruption. That's why ECC DRAM is recommended and required if you want to run automatic scrubs.
<tkaiser>
hramrach: We collect ECC errors in a monitoring system. Even servers that showed not a single bit flip during burn-in (72 hours usually) report a correctable 1 bit error every few weeks.
<hramrach>
nice
<tkaiser>
hramrach: Without ECC you won't even notice. But some data might get corrupted. So if you care about your data stay away from those crappy x-bay NAS boxes and get stuff for adults. Still the cheapest way is such a HP Micro
<hramrach>
yes, it's somewhat more expensive than the ARM NAS but it's better hardware for sure
<hramrach>
hm, and the NAS boxes are alsready using DDR3 so you probably cannot say they use slow, safe and stupid technology
<hramrach>
when you get into probablility you will find you can expect all your disks are corrupted given their size and that probably appies to ram as well
<hramrach>
chaos ftw ;-)
<tkaiser>
hramrach: That's why use ECC memory and end to end data integrity. Checksums in zfs/btrfs. It's 2016, if you care about data integrity then do it and stop complaining ;) And both fs support snapshots and sending them to a remote disk/location. Using this intelligently and you need no traditional backup any more.
<tkaiser>
But it's still way too off-topic _here_
<hramrach>
<- offtopic man
premoboss has quit [Ping timeout: 246 seconds]
<jski>
in what senerio would sem_trywait be the better solution to sem_wait?
gumblex has quit [Ping timeout: 245 seconds]
gumblex has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
<terra854>
tkaiser: So how do I test the patch out to see if it works?
<montjoie>
a83t clock is set as WIP, but I cannot see who work on it
<wens>
montjoie: last attempt was from vishnu, iirc that was the old style clocks
<montjoie>
it dont work on it now ?
<montjoie>
-it +he
<wens>
don't know
gumblex has quit [Remote host closed the connection]
<wens>
i fear the soc may not see any progress soon
<montjoie>
wens: do you know the complexity of doing it ?
gumblex has joined #linux-sunxi
<montjoie>
at least for putting it in "job todo"
Mr__Anderson has joined #linux-sunxi
paulk-minnie has joined #linux-sunxi
<wens>
well, it's very similar to the a80, which i'm going to have to do
<wens>
most different thing is it has a new clock type
<montjoie>
in fact it is written in "core stuff"
<wens>
it is, because without clocks you really can't support anything
Mr__Anderson has quit [Ping timeout: 248 seconds]
<montjoie>
and it seems that jfmoine work on clk-ng for a83t
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<wens>
montjoie: he has his own version
<wens>
which is not sunxi-ng :|
<montjoie>
the title said sunxi-ng but no answer on his patchset
gumblex has quit [Read error: Connection reset by peer]
perr has joined #linux-sunxi
gumblex has joined #linux-sunxi
<wens>
i don't know
<wens>
fyi i won't have any time to work on stuff next week
<wens>
travelling for work
Ntemis has quit [Remote host closed the connection]
gumblex has quit [Read error: Connection reset by peer]
gumblex has joined #linux-sunxi
silviop has quit [Remote host closed the connection]
cnxsoft has quit [Remote host closed the connection]
ErwinH has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
IgorPec has joined #linux-sunxi
LargePrime has joined #linux-sunxi
Putti has joined #linux-sunxi
<LargePrime>
tkaiser, i see you posting on cnx-software. I wish to bug you about a kodi box recommendation.
<LargePrime>
of course if anyone else feels motivated to give feedback, feel free...
<LargePrime>
i will be afk, so please ping if you reply. Thanks
Putti has quit [Ping timeout: 252 seconds]
Gerwin_J has joined #linux-sunxi
gumblex has quit [Ping timeout: 245 seconds]
hramrach has quit [Quit: WeeChat 1.5]
<tkaiser>
LargePrime: Me? I've not the slightest idea, I use sunxi devices mostly headless. And Kodi is here off-topic anyway
<LargePrime>
tkaiser, you seem well informed of the state of software support for many chipsets.
<LargePrime>
as well as many pit falls of them
<tkaiser>
LargePrime: Headless means 'no display', I would assume Kodi means display? Never used it and not interested :)
dgp has joined #linux-sunxi
<LargePrime>
certainly tkaiser, but could you suggest a well supported box, that you might guess has the capacity to run a head, and kodi?
<KotCzarny>
doesnt kodi have a list of 'supported devices' ?
<KotCzarny>
just take one that they deem worthy and dont worry about anything else
<LargePrime>
KotCzarny, they do. but there understanding of linux support is very limited
<jelle>
libreelec is much nicer
<KotCzarny>
but you are interested in kodi primarily, and making it work on 'unsupported' device by them could be pita
<LargePrime>
i am not interested in kodi primarily KotCzarny. i just have that as a preference. i am primarily interested in good linux support
<jelle>
we have a mainline support matrix for that
<KotCzarny>
allwinner a20/h3 isnt bad choice for now
<jelle>
but kodi means graphics which brings issues
<LargePrime>
i was looking at olimes a20 lime 2
<KotCzarny>
but keep in mind kodi guys hate allwinner, so expect rough ride
<LargePrime>
ya, it seemed the graphics was a bit weak
<LargePrime>
i guess i can wait for the new olimex board
<jelle>
I've used an imx6 box for a long time since someone was making an libreelec image
perr has quit [Quit: Leaving]
<LargePrime>
and how was it jelle
<jelle>
well it worked, doesn't do x265
<LargePrime>
run android, or linux?
<jelle>
Linux
<jelle>
LargePrime: look up libreelec..
<LargePrime>
so it would not do software x265
mzki has quit [Ping timeout: 240 seconds]
<jelle>
obviously
<LargePrime>
libreelec seem perfect
mzki has joined #linux-sunxi
<dgp>
Is anyone actively looking at the xr819 driver (orange pi zero wifi) for mainline? I know of icenowy's changes to make it compile but it doesn't actually work.. I can get the firmware to load almost everytime now but it seems to stop responding after that
<LargePrime>
jelle, would you have a hardware recommendation to run libreelec?
<terra854>
tkaiser: So how do I test the patch out to see if it works?
<jelle>
LargePrime: no, I'm now using an amlogic S905X box but don't know how long that will be maintained as a libreelec-fork. Maybe an odroid-c2?
reinforce has quit [Quit: Leaving.]
Gerwin_J has quit [Quit: Gerwin_J]
<vpeter>
jelle: there are few amlogic developers who are working hard to support different systems based on those chips.
<vpeter>
Once supported - always supported :D
<jelle>
vpeter: yup I know, but you'll still have the mali issue
arossdotme has quit [Ping timeout: 260 seconds]
premoboss has joined #linux-sunxi
<tkaiser>
terra854: It's reported that the switch works in Android 5.1 to wake up the board? So why not burning that image and reading out DT contents there? There should be a .dtb lying around and you can access /proc/device-tree there. Also I have no idea to which pin the power button is connected. Did you look into schematics?
<terra854>
tkaiser: I don't really understand how to read that kind of schematics
whaf has quit [Quit: Leaving.]
<tkaiser>
terra854: I do not even know where to find them. Anyway, then this remains one of the Pain64 mysteries, stuff that is most probably just settings is supposed to never work with Linux ;)
<LargePrime>
jelle, for my edification, what is the mali issue? no open driver for mali?
<tkaiser>
terra854: Any to be clear: I'm not that much interested in this, I just thought I try to give ja a hint since you asked some days ago whether that (suspend) could work with Pine64 too
<jelle>
LargePrime: mali the gpu
<LargePrime>
also thank you for the c2 recommendation
<jelle>
LargePrime: I'm not recommending it
* jelle
doesn't have one
<LargePrime>
i gues then, thanks for the hanging pointer to the c2?
<terra854>
tkaiser: Never mind, I'll ask the guys at Pine64 on this