<wens>
I have this one and tested it with a bpi-m1-plus, though I used patch cables, not plugging it on directly
Hao_ has joined #linux-sunxi
<igraltist>
wens: l,
kaspter1 has joined #linux-sunxi
<igraltist>
ok already ordered before :d
<igraltist>
i think an opi zero would now fit
kaspter has quit [Read error: Connection reset by peer]
kaspter1 is now known as kaspter
<igraltist>
its just playing for music nothing more
<wens>
it's the standard rpi header
<wens>
you probably want something that can serve as a master MCLK
<wens>
otherwise the SoC's audio PLL doesn't deliver the correct clock rate for playback at the correct speed
* willmore
listens in
<willmore>
So, the audio playback board with the CODEC on it (D/A) generates the master clock and the SoC is a slave (of sorts)? I did not know that, but it makes complete sense.
<wens>
willmore: with I2S the host interface supports being either master or slave
<wens>
(well, ours does anyway)
<wens>
but in general, with I2S one device serves as the master syncing all the other devices
<willmore>
Cool. I have some interest in a high speed high bit depth A/D and D/A board, but trusing the SoC to generate a stable clock seemed like a bad idea--I need a very accurate and stable clock for the project. This makes it much simpler.
<igraltist>
i will see when it arrive. first an opipc will be the host
<willmore>
Thanks for the education, wens.
<wens>
willmore: you will want to check if the codec you're using supports master mode though, and that it has a stable crystal :)
<wens>
dates for next year's FOSDEM are out
<willmore>
I will be synthasizing the frequency from a GPS stabalized 10MHz ovenized oscillator. The frequency will be fine. :) I'll check the codec as well. Nothing crazy, just 192/24--it's for signal processing, not human audio.
<wens>
hmm, I've been playing with GPS receivers a few weeks ago
<willmore>
The freq source will be an HP Z3801A, if you are familiar with them.
<willmore>
I want to use a direction conversion receiver to capture the VLF time signals from all over the world.
<willmore>
The hope is that I could make a fairly low cost (minus the z3801a) USB device that lets any machine it's plugged into have accurate time anywhere on earth--with some limitations.
<willmore>
I'm only using that frequency source in prototyping to remove sources of error. I wouldn't expect others to use it.
<willmore>
wens, what were you using them for?
vagrantc has quit [Quit: leaving]
Hao_ has quit [Ping timeout: 240 seconds]
<wens>
willmore: trying out ntp w/ GPS / PPS
<wens>
jitter with PPS is incredibly low
<wens>
VLF time signals. there are only a few of them left, right? and you need a big ass antenna
Hao_ has joined #linux-sunxi
pmpp has quit [Quit: No Ping reply in 180 seconds.]
pmpp has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
<wens>
igraltist: I just realized I can't plug mine in, because I have huge heatsinks on the chips
<beeble>
willmore: what stability are you trying to achieve? 10mhz 0.1ppm you could get in a fairly common tcxo for 10 usd or less in quantities of 1
TheSeven has quit [Ping timeout: 255 seconds]
TheSeven has joined #linux-sunxi
ganbold has joined #linux-sunxi
reinforce has joined #linux-sunxi
reinforce has quit [Client Quit]
<igraltist>
wens: maybe there is some adapter for the pinns
<igraltist>
iam not sure how i will do a case for it
lurchi_ has joined #linux-sunxi
TheSeven has quit [Ping timeout: 246 seconds]
TheSeven has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
SP7RT has joined #linux-sunxi
IgorPec has joined #linux-sunxi
SP7RT has quit [Ping timeout: 240 seconds]
Andy-D__ has quit [Quit: Alive/Dead]
<wens>
I suppose you could make some kind of extension, and get longer fasteners
<MoeIcenowy>
P.S. Sinovoip people told me that they added a enable GPIO for vcc5v0
<MoeIcenowy>
which I will add in next version of DT patches
<MoeIcenowy>
oh it's still not on this version of schematic
<MoeIcenowy>
(the GPIO used is PH23)
<MoeIcenowy>
It's said that the GPIO is used on newer BPi M2 Ultra and all BPi M2 Berry
<MoeIcenowy>
and I verified that on my Berry it's needed to get vcc5v0 to work
<tkaiser>
MoeIcenowy: The 'new' schematic is still dated Friday, July 29, 2016, it seems it the same the provided a year ago but this time they chose to not let the component values be scrapped.
<MoeIcenowy>
;-)
<tkaiser>
Same document, different PDF export, wrong contents
<tkaiser>
MoeIcenowy: We did a lot of testing with H3 boards. Then decided to roll out these settings waiting for complaints.
<MoeIcenowy>
but still no complaints yet? ;-)
<MoeIcenowy>
According to my experiments the Armbian DVFS table can make my OPi One/Zero to reach 960MHz while with AW table it can only reach 816MHz
<tkaiser>
In March 2016 when I made a huge mistake (OPi One always on 1.1V but allowed to clock up to 1200 MHz) we got some.
<MoeIcenowy>
(1.3V will easily overheat the boards, and only works as some "boost speed"
<tkaiser>
But I don't think this is a proof these settings really work everywhere since usually users stop using stuff that doesn't work instead of complaining about undervoltage
<MoeIcenowy>
so maybe I should go back to AW DVFS table now for next version of H3 mainline DVFS patchset?
<MoeIcenowy>
to be honest Armbian DVFS table performs fine on my devices
<MoeIcenowy>
even with the cpuburn-a7 + cpuburn-ljt-stress-test
<MoeIcenowy>
on my OPi PC
<MoeIcenowy>
(I don't dare to do this stress test on One/Zero as they will overheat on the highest temperature
<tkaiser>
Based on the count of downloads and how many people these settings use I still think they're fine.
<tkaiser>
But these R40 settings match those Armbian uses on the H3 boards with the more primitive voltage regulator.
<tkaiser>
912 MHz at 1.1V, 1200 MHz at 1.3V
<wens>
MoeIcenowy: if you send it, you should have tested it yourself
<MoeIcenowy>
wens: of course they works fine on my boards
<MoeIcenowy>
but I'm not sure whether it works on others' boards
<wens>
we should probably provide a conservative set by defeault, then override it with tested/optimized settings for each board
<MoeIcenowy>
oh so the default can be set to the AW DVFS talbe
<MoeIcenowy>
table *
<tkaiser>
There are some thousand users out there using them and I'm not aware of a single complaint yet. But that's with legacy kernel only so testing these settings with mainline is mandatory of course.
<MoeIcenowy>
diego71: the mali blob doesn't say this things
<diego71>
ops
ganbold has joined #linux-sunxi
fkluknav has quit [Ping timeout: 240 seconds]
aidin has quit [Remote host closed the connection]
aidin has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
aidin has quit [Ping timeout: 248 seconds]
chlorine has joined #linux-sunxi
aidin has joined #linux-sunxi
Hao_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 248 seconds]
<MoeIcenowy>
oh it's also not DRAM issue...
fkluknav has joined #linux-sunxi
<montjoie>
thanks ElBarto, instructions ok!
aidin has quit [Remote host closed the connection]
<montjoie>
just it seems we rely on a old ATF fork
<ElBarto>
yeah
aidin has joined #linux-sunxi
<ElBarto>
I don't know if Andre plan to merge this work on the ARM one
Hao_ has quit [Ping timeout: 240 seconds]
aidin has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
I tried to set the predivider of GPU clock to 8, and the fps of es2gears_x11 goes to 2 from 4
<MoeIcenowy>
oh my kernel doesn't enable DEVFREQ, is it going to be an issue/
<MoeIcenowy>
?
<MoeIcenowy>
(but I think it should not be an issue as on A64 it works properly
Hao_ has joined #linux-sunxi
chlorine has joined #linux-sunxi
Hao_ has quit [Ping timeout: 255 seconds]
<willmore>
wens, if you want to do trivial decode on the time signals you need a pretty small antenna. I want to do some more complex decoding and I'm hoping to need very little antenna at all. No, to transmit, you need huge antennas! There are a half dozen such transmitters around the world.
chlorine has quit [Remote host closed the connection]
<willmore>
beeble, I don't know yet what stability I will need. I can always trade signal processing gain for lower frequency stability. I don't have enough data to make that tradeoff at this point.
chlorine_ has joined #linux-sunxi
JohnDoe_71Rus has quit [Remote host closed the connection]
yann-kaelig has quit [Quit: Leaving]
BenG83 has quit [Ping timeout: 240 seconds]
yann-kaelig has joined #linux-sunxi
Hao_ has joined #linux-sunxi
fkluknav has quit [Ping timeout: 240 seconds]
chlorine_ has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
Hao_ has quit [Ping timeout: 255 seconds]
Hao_ has joined #linux-sunxi
Hao_ has quit [Ping timeout: 246 seconds]
fkluknav has joined #linux-sunxi
Hao_ has joined #linux-sunxi
<MoeIcenowy>
I'm feeling that the FPS of the Mali-450 is restricted, as different scenes in glmark2-es2 all results 4 fps
Hao_ has quit [Ping timeout: 248 seconds]
Hao_ has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine_ has quit [Ping timeout: 240 seconds]
BenG83 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
tgaz has quit [Ping timeout: 248 seconds]
fixmeer has quit [Ping timeout: 248 seconds]
buZz has quit [Ping timeout: 255 seconds]
tgaz has joined #linux-sunxi
mic-e[m] has quit [Ping timeout: 246 seconds]
ch40s[m] has quit [Ping timeout: 246 seconds]
olerem has quit [Ping timeout: 246 seconds]
aidin has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
fkluknav has quit [Ping timeout: 248 seconds]
lurchi_ has quit [Ping timeout: 248 seconds]
Ke has quit [Ping timeout: 248 seconds]
jemk has quit [Ping timeout: 246 seconds]
Hao_ has quit [Ping timeout: 240 seconds]
qeed has quit [Ping timeout: 248 seconds]
camh has quit [Ping timeout: 260 seconds]
buZz has joined #linux-sunxi
jemk has joined #linux-sunxi
souther has quit [Remote host closed the connection]
dave0x6d has quit [Quit: Connection closed for inactivity]
IgorPec has quit [Ping timeout: 240 seconds]
LargePrime has quit [Ping timeout: 240 seconds]
LargePrime has joined #linux-sunxi
kr_eten has joined #linux-sunxi
<kr_eten>
Hello people, I am tinkering with the GPIO of A20 (olinuxino micro) - does anyone know what are "Multi-Driving register" - it is part of the PIO register in the A20
SP7RT has quit [Ping timeout: 240 seconds]
<chrisf__>
montjoie: crypto engine in the H5 now doing AES256 correctly - thanks for your help.
<montjoie>
chrisf__: now bench it:)
<montjoie>
and cry
<montjoie>
I will setup mine tonight, perhaps good surprise vs H3 numbers...
<KotCzarny>
compare with aes in cpu ext too
<montjoie>
I cry even when comparing with aes generic
<montjoie>
my heart will suffer if I compare with optimized algs
a|3x has joined #linux-sunxi
<montjoie>
the only way to be better is perhaps that the 4 parallel stream are not really/badly used
<montjoie>
I need to find a way to verify that
<KotCzarny>
hack the openssl to use it, as a bonus there will be real gain for users somewhere
<montjoie>
on A83T any AES > 1024bytes timeout and made any further AES timeout
<montjoie>
but why!!!
fkluknav has quit [Ping timeout: 240 seconds]
LargePrime has quit [Ping timeout: 255 seconds]
chlorine_ has joined #linux-sunxi
<montjoie>
Was happy when TLS module goes in kernel, but it use only GCM, an alg that CE does not support...
<montjoie>
instead they add (and remove) random blockmode
chlorine has quit [Ping timeout: 255 seconds]
<chrisf__>
montjoie: hahaha. Not worried about throughput for my application. Just don't want the CPU load.
<montjoie>
very curious to see what they will add/remove in H6
<KotCzarny>
bugs, lots of bugs
<willmore>
montjoie, plus the H5 has the AES acceleration instructions, so it does several times better than the H3 because of that as well.
fkluknav has joined #linux-sunxi
<montjoie>
will see:(
<KotCzarny>
would be nice to have some programmable dsp for creating own algos
aidin has joined #linux-sunxi
jernej has joined #linux-sunxi
chlorine_ has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
LargePrime has joined #linux-sunxi
<willmore>
montjoie, from 'cryptsetup benchmark' on an H3: aes-cbc 128b 15.5 MiB/s 10.9 MiB/s
<willmore>
Then from an H5 with AES instructions: aes-cbc 128b 239.8 MiB/s 296.1 MiB/s
<montjoie>
for fun, I will launch a request to allwinner "remove DES/3DES(lol) add GCM"
<montjoie>
ouch
* willmore
would vote for that
<willmore>
openssl is even worse
<willmore>
from "openssl speed -elapsed -evp aes-128-cbc":
<ElBarto>
willmore: from what I've seen 'openssl speed' doesn't use the aes instruction
<willmore>
ElBarto, if you build it to use them, it does.
<willmore>
IIRC, the policy had been not to use them by default as some processors hadn't implemented them properly as to avoid cache timing issues, etc. So, they were fast, but insecure.
<willmore>
My understanding is that ARM didn't make that mistake--or at least that's what I've been lead to believe.
<ElBarto>
willmore: not for the speed command
<willmore>
ElBarto, see the "--evp"?
<jernej>
MoeIcenowy: If it is any interest to you, HDMI CEC is fully working with mainline H3 HDMI driver
<ElBarto>
willmore: I'll check again the sources, maybe it was patched in the ones for FreeBSD
<ElBarto>
openssl:Error: '--evp' is an invalid command.
<ElBarto>
bah
<willmore>
ElBarto, sorry, one -
<ElBarto>
willmore: anyway both numbers series do not change a lot
<ElBarto>
oh sorry
<willmore>
No, I mistyped it here and my only copied my mistake.
<ElBarto>
what checking H3 vs H5 without EVP :)
<willmore>
The H3 does not change.
<ElBarto>
yeah sure
<willmore>
The H5 non-evp results are above^^^^
<willmore>
I ran both to make sure. :)
<KotCzarny>
willmore: governor set to performance?
<miasma>
willmore: do you happen to have numbers for aes-xts 256/512b?
pepee has joined #linux-sunxi
<miasma>
for h3/h5
<MoeIcenowy>
jernej: where?
<MoeIcenowy>
(although CEC is not of my interest
<willmore>
KotCzarny, not sure. Shouldn't make much difference for a cpu bound task--unless it's set to powersave. Can't imagine Armbian would do that by default.
<willmore>
miasma, via what program? I'd be glad to generate them.
<KotCzarny>
ondemand one is pretty bad on allwinner
<jernej>
MoeIcenowy: with my default branch (h3_hdmi_v1), since it doesn't need anything special. I just added PHY CEC register initialization to 0 just to be sure
<jernej>
MoeIcenowy: dw_hdmi cec driver was merged few days ago
<miasma>
the h5 numbers are decent for NAS use
<willmore>
miasma, yes, but not as good as I would have expected.
<MoeIcenowy>
it's dw?
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
<miasma>
willmore: those numbers don't include hw acceleration for aes?
<miasma>
or crypto modules
<jernej>
MoeIcenowy: yes, part of dw_hdmi controller
<willmore>
miasma, IIRC, those are all single threads, so expect up to 4x as much for workloads that thread.
<MoeIcenowy>
oh I thought it part of custom PHY...
<MoeIcenowy>
P.S. I think you'd better name the compatible "allwinner,sun8i-h3-dw-hdmi", not "allwinner,h3-dw-hdmi"
<willmore>
miasma, only AES software instructions. Not using the hardware crypto unit.
<MoeIcenowy>
place sunXi before the real chip name is a tradition of sunxi compatible strings ;-)
<jernej>
there is just one special register which fortunatelly doesn't do any harm
<jernej>
ok, tnx
<jernej>
will do
<miasma>
willmore: still looking forwart to h5 based nas boards with integrated (usb-based) dual-eth/sata :)
<miasma>
typo day
<willmore>
miasma, that would be the H6 you want.
<jernej>
MoeIcenowy: btw, did you find the bug which causes pink column on high resolutions? If not, I can take a look now
<miasma>
willmore: perhaps, but ~240-260 MB/s is already fast enough for a single disk
<MoeIcenowy>
still not...
<MoeIcenowy>
as the high resolution screen is not mine :-(
<KotCzarny>
add overheads, transfers, and it will be 1/5 of that
<MoeIcenowy>
I only own the 1024x600 screen :-(
<jernej>
ok
SP7RT has joined #linux-sunxi
<willmore>
miasma, yes, but the USB2 on the H5 isn't fast enough. Now, the USB3 and PCI-E on the H6 is fast enough.
<MoeIcenowy>
P.S. if you read the backlog, I solved mali-450 on H5 ;-)
<miasma>
willmore: fast enough for what? depends on your needs :)
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
<willmore>
To get enough data to/from storage to saturate that GigE connector. And a second one on PCI-E, maybe. :)
<jernej>
MoeIcenowy: yes, I saw that. Great! :)
<jernej>
btw, did you use latest linux-next?
<willmore>
MoeIcenowy, is it as fast as you had hoped. :)
<MoeIcenowy>
jernej: nope I cherry-picked some patches on 4.13-rc
<jernej>
since there are some fixes for fractional clocks
<MoeIcenowy>
it's not clock issue ;-)
<MoeIcenowy>
but driver issue
<jernej>
yeah, but you used 297 MHz at beginning
<MoeIcenowy>
yes, it's the default of PLL_GPU
SP7RT has quit [Ping timeout: 246 seconds]
<jernej>
I had issues with 1080p resolution and later I found out that fractional mode wasn't really turned on but instead old frequency (set before switching to fractional mode)
IgorPec has joined #linux-sunxi
<jernej>
so, if 297MHz is set by default, you had luck
<jernej>
anyway, you probably use 384 MHz?
<jernej>
for PLL_GPU
<MoeIcenowy>
CCU is weak ;-)
<MoeIcenowy>
I need to make more fixes to stabily use 384MHz ;-)
chlorine_ has quit [Ping timeout: 248 seconds]
<jernej>
does your anx6345 driver work?
msimpson has quit [Quit: Leaving]
<MoeIcenowy>
jernej: yes, but I don't dare to upstream it now...
<MoeIcenowy>
maybe I will never have the bravery to upstream it...
<jernej>
why?
<MoeIcenowy>
I have even not read the datasheet of it
<jernej>
well, there are a lot of reverse engineered driver in kernel
<jernej>
and anything can be fixed
<MoeIcenowy>
maybe you can look at that driver in my sunxi64 branches ;-)
<jernej>
I will, but a bit later
dev1990 has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
jstein has quit [Remote host closed the connection]
aidin has joined #linux-sunxi
aidin has quit [Ping timeout: 248 seconds]
leviathan_ has joined #linux-sunxi
fkluknav has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
oh the Mali-450 driver seems to have too many problems now -- when trying to run gnome-shell with it, it's complaining many "GL error: Out of memory"
<MoeIcenowy>
and the picture is broken
SP7RT has joined #linux-sunxi
fkluknav has joined #linux-sunxi
chrisf__ has quit [Ping timeout: 255 seconds]
<jernej>
did you enable cma in kernel config and add enough memory?
specing has quit [Ping timeout: 255 seconds]
pepee- has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
pepee has quit [Disconnected by services]
pepee- is now known as pepee
specing has joined #linux-sunxi
<MoeIcenowy>
jernej: of course
<MoeIcenowy>
and I added a cma device node in dt
<MoeIcenowy>
but even if I adjust the pool to 512MiB the same problem is still here
<MoeIcenowy>
and the CMA is in fact not so used
<jernej>
afaik, cma node is not necesary
<MoeIcenowy>
yes, and I also enabled CMA in kernel of course
<jernej>
no idea then
<MoeIcenowy>
now enabled the debug output of the driver, and it says PP page fault
scream has joined #linux-sunxi
<jernej>
maybe is the driver issue?
<jernej>
did you try one from Xunlong?
<MoeIcenowy>
oh still not...
<MoeIcenowy>
to try it I think I should re-adapt r5p1...
<jernej>
afaik, as long as kernel version >= user space version it is ok
<MoeIcenowy>
nope
<MoeIcenowy>
it requires accurate match
<jernej>
at least some folks are using mali driver that way on Rockchip RK3288 platform
<jernej>
and it works
<MoeIcenowy>
maybe midgard changed
yann|work has quit [Ping timeout: 248 seconds]
gzamboni has joined #linux-sunxi
<MoeIcenowy>
jernej: do you have the r5p1 blob now?
<montjoie>
I have near the same config than my A64
<beeble>
just guessing stuff as i don't own a h5 device
<beeble>
your atf is known to work with mainline?
lkcl has quit [Ping timeout: 240 seconds]
foxx_ has quit [Ping timeout: 240 seconds]
<montjoie>
I used the board/sunxi/README.sunxi64 from uboot (with apritzel ATF)
<beeble>
just for you to verify => setenv bootargs you could also try => setenv bootargs "console=ttyS0,115200n8 earlycon=uart,mmio32,0x1c28000 earlyprintk
kr_eten has quit [Remote host closed the connection]
<beeble>
and build atf with debug on
SP7RT_ has quit [Ping timeout: 246 seconds]
lkcl has joined #linux-sunxi
SP7RT has joined #linux-sunxi
yann-kaelig has quit [Quit: Leaving]
uwe__ has joined #linux-sunxi
lkcl has quit [Ping timeout: 246 seconds]
uwe_ has quit [Ping timeout: 240 seconds]
<montjoie>
I will try
jbrown has quit [Ping timeout: 240 seconds]
<willmore>
montjoie, do you still need a boot.cmd?
jbrown has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorine has quit [Read error: Connection reset by peer]
<montjoie>
good question, I can do without it ?
<KotCzarny>
urandom is funny, 16kB and not a single 0x00
lkcl has joined #linux-sunxi
<diego71>
KotCzarny: on my PC I got plenty of 0x00
<KotCzarny>
my orange must be weird
<diego71>
you can use dieharder to check the randomness
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
jstein has quit [Read error: Connection reset by peer]
<KotCzarny>
humm, is there a way to dynamically map new fb device onto tty ?
<KotCzarny>
ie. i have /dev/fb8 which i would want to use as a terminal
scream has quit [Remote host closed the connection]
<KotCzarny>
4x6 font is still legible. though only half of the screen is used
SP7RT_ has joined #linux-sunxi
<willmore>
pepee, it is a separate chip. I was refering to the wifi SoC--it's got a CPU of it's own and everything.
SP7RT has quit [Ping timeout: 246 seconds]
<pepee>
willmore, what do you mean, perf is bad even with the separate chip?
<willmore>
pepee, the xr819 runs a firmware that is a black box. The processor on the OpiZ talks to the code running on the xr819. The driver is based on code found in repos from Allwinner old kernels and adapted to modern kernels.
<willmore>
There is no documentation for the xr819.
<willmore>
That the driver works at all is amazing.
<willmore>
If you plug in a USB Wifi chip with a good chipset on it that supports AP mode, you will have much better luck than using the on board xr819.
<KotCzarny>
yup. that's the expected speed of ap6212 and xr819 ;)
<KotCzarny>
well, in client mode it sometimes reaches 2.5MB/s
<divis1969>
I'm wondering is something already exist for A83T ?
<willmore>
pepee, do like I did and just disable the radio entirely. Pretend it's not there. ;)
Ntemis has quit [Remote host closed the connection]
<pepee>
I guess I'll have to do that
<willmore>
As tkaiser says, it's okay for light IoT use, but I wouldn't want to treat it like a NAS.
<willmore>
clone hardware like that wifi is very hard to get supported. The driver for the chip it's cloned from may not work because the clone may not be good enough--it will have its own bugs and may not duplicate the original exactly.
<pepee>
for my use cases, it's better to buy routers than mini-pcs...
<pepee>
sadly, routers are expensive too, which is something I just don't understand
<willmore>
And, it's even less likely to ever get documentation for it as that would point out clearly that it was a clone and that'll lead to a lawsuit...
<willmore>
pepee, what are you trying to accomplish?
<willmore>
I know of a lot of cheap Wifi routers that run OpenWRT just fine. Those will have AP level hardware that's stable.
<pepee>
have small, cheap linux machines to do different things
<willmore>
AP use is specific enough that you generally want hardware made just for that.
<pepee>
also, I may want to start some commercial projects in the future
<willmore>
Good luck. :)
<pepee>
yeah, I know about openwrt, I love it
<willmore>
Cheap 802.11n AP boards that can run OpenWRT are $10 or so. Better ones can be had if you get them used/refurbished.
<pepee>
it's the reason I don't understand everything related to ARM... MIPS is completely open, yet a failure. meanwhile, ARM SoCs are powerful, but... the whole platform mostly sucks
leviathan_ has quit [Read error: Connection reset by peer]
<pepee>
stupid ARM
<willmore>
MIPS is owned by one company and that IP has been passed around as companies get aquired or sold. It's a mess to even track down who owns the rights at any one time.
<willmore>
So, little development has gone into making it faster and better.
<pepee>
yeah, it's sad
<willmore>
ARM on the other hand is used all over, but the cheap chips are always going to be from companies that cut corners.
<willmore>
If you want documentation and support you have to buy the more expensive chips--NXP, etc.
uwe__ is now known as uwe_
<kilobyte>
KotCzarny: your font is way too big for such a resolution; you may want https://angband.pl/font/tinyfont.html (although I haven't yet succeeded in putting it in a ttf container)
<KotCzarny>
kilobyte: i need 8x6 font, got one? (i've found 4x6, but linux console is not working well with it)
<kilobyte>
nope; there might be one around but at such an aspect ratio it's quite unlikely
<kilobyte>
I thought most fb* consoles work well with non-8 horizontal sizes?
<KotCzarny>
kilobyte: checkout the tomthumb font (it's 4x6)
<KotCzarny>
fbtft apparently doesnt like fonts smaller than 8 (it just doesnt take all available space)
SP7RT_ has quit [Ping timeout: 240 seconds]
<kilobyte>
so is mine; that one uses 2 levels, mine 4 which improves readability a lot on such a small size
_hp197 has joined #linux-sunxi
<pepee>
willmore, what i wanted to do is to have a small website running in the opi zero, that people could access locally from their phones, through the wifi
<pepee>
also, this thread made me understand the situation regarding the driver... that even if it's the same(?) as some other wifi chip, there is no documentation
<kilobyte>
on EGA/VGA drawing stuff not aligned to 8 pixels horizontally was insane, but it's surprising for that limitation to be still with us
<pepee>
btw, being the same driver... shouldn't they release, as it's GPLd code?