<premoboss>
tuxillo, recompiled linux 4.9 (on x86). bzImage is 2871KB and i disable quite all (also usb, wireless, all network cards, audio, video, etc). even in on arm there are different hardware, to strip more than 2MB seems to be very hard.
<tuxillo>
hmmm
<tuxillo>
yeah dunno then
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 258 seconds]
<tuxillo>
i'm going to leave the opi0 running overnight
<tuxillo>
on this 6000mAh battery and see what happens
LargePrime has quit [Ping timeout: 272 seconds]
interrobangd has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
LargePrime has joined #linux-sunxi
nOOb__ has joined #linux-sunxi
LargePrime has quit [Ping timeout: 246 seconds]
nOOb__ has quit [Ping timeout: 256 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 245 seconds]
nOOb__ has joined #linux-sunxi
GrimKriegor has quit [Read error: Connection reset by peer]
nOOb__ has quit [Ping timeout: 256 seconds]
GrimKriegor has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.4]
vagrantc has quit [Quit: leaving]
ErwinH has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
ErwinH has quit [Ping timeout: 256 seconds]
nOOb__ has joined #linux-sunxi
nOOb__ has quit [Ping timeout: 272 seconds]
nOOb__ has joined #linux-sunxi
victhor has quit [Remote host closed the connection]
nOOb__ has quit [Ping timeout: 245 seconds]
florianH has quit [Quit: Connection closed for inactivity]
victhor has joined #linux-sunxi
<willmore>
My 802.11ac wifi gets >40MB/s. But, that's a real wifi chip on a real bus. :)
<willmore>
tuxillo, I bet it'll survive.
<willmore>
IIRC, mine drew 100-150mA while idle-ish. So, 12 hours of that is only 1.2-1.8Ah. Unless your battery is junk, you'll be fine. Now, if you run ssvb's cpuburn overnight then you might have an issue. :)
orly_owl has quit [Ping timeout: 248 seconds]
LargePrime has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
laj has joined #linux-sunxi
<dgp>
It should be noted that the driver for the wifi on the opiz currently sets the "operational mode" for the wifi to low power and might be that that causes it to be slow at reacting to traffic coming at it from the network
tgaz has quit [Ping timeout: 248 seconds]
<dgp>
but the wifi works pretty well for me on mainline and you paid $7 bucks for the board and haven't done anything but whinge etc.. ;p
LargePrime has quit [Ping timeout: 246 seconds]
orly_owl has joined #linux-sunxi
tgaz has joined #linux-sunxi
<willmore>
dgp, well said.
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 245 seconds]
LargePrime has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
victhor has quit [Ping timeout: 272 seconds]
apritzel has quit [Ping timeout: 248 seconds]
uwe_ has quit [Ping timeout: 256 seconds]
ninolein has quit [Ping timeout: 245 seconds]
Andy-D has quit [Ping timeout: 260 seconds]
ninolein has joined #linux-sunxi
fire219 has quit [Ping timeout: 272 seconds]
uwe_ has joined #linux-sunxi
fire219 has joined #linux-sunxi
dgp has quit [Remote host closed the connection]
BenG83 has quit [Ping timeout: 245 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
leviathanch has joined #linux-sunxi
leviathanch_ has joined #linux-sunxi
fire219 has quit [Ping timeout: 246 seconds]
leviathanch has quit [Ping timeout: 258 seconds]
leviathanch_ has quit [Remote host closed the connection]
fire219 has joined #linux-sunxi
dgp has joined #linux-sunxi
leviathanch has joined #linux-sunxi
fire219 has quit [Ping timeout: 248 seconds]
fire219 has joined #linux-sunxi
pg12 has quit [Ping timeout: 246 seconds]
leviathanch has quit [Remote host closed the connection]
pg12 has joined #linux-sunxi
leviathanch has joined #linux-sunxi
fire219 has quit [Ping timeout: 248 seconds]
fire219 has joined #linux-sunxi
deskwizard has quit [Ping timeout: 248 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 245 seconds]
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
ganbold has quit [Ping timeout: 256 seconds]
IgorPec has joined #linux-sunxi
ganbold has joined #linux-sunxi
foxx has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 258 seconds]
TheSeven has quit [Ping timeout: 245 seconds]
TheSeven has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
FrostyBytes has joined #linux-sunxi
a1d3s has joined #linux-sunxi
<a1d3s>
good morning
terra854 has joined #linux-sunxi
JohnDoe3 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 246 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 246 seconds]
paulk-collins has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
IgorPec3 has joined #linux-sunxi
mossroy has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 245 seconds]
msevwork has joined #linux-sunxi
afaerber has joined #linux-sunxi
willmore has quit [Ping timeout: 268 seconds]
ErwinH has joined #linux-sunxi
willmore has joined #linux-sunxi
havoc_ has quit [Remote host closed the connection]
ErwinH has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Read error: Connection reset by peer]
ErwinH has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
IgorPec3 has quit [Ping timeout: 272 seconds]
paulk-collins has quit [Remote host closed the connection]
DullTube has joined #linux-sunxi
massi has joined #linux-sunxi
gzamboni has joined #linux-sunxi
giomba has joined #linux-sunxi
<tuxillo>
willmore: 8h up and the battery still shows 3 leds indicating it's above 66% full
<tuxillo>
dgp: sure, I understand that. but this low power setting would cause an active ssh connection to be dropped?
<tuxillo>
well I don't think so
florianH has joined #linux-sunxi
<dgp>
tuxillo: you base that assumption on ...
<tuxillo>
you said it's set on low power mode by the driver
<tuxillo>
right?
<dgp>
And why do you think that wouldn't cause something that could cause an ssh session to drop?
<tuxillo>
there is activity in the interface, why would it drop it because of a low power setting?
<dgp>
I know why I think it might, I'm wondering you think it wouldn't
<tuxillo>
a device would go to sleep mode when not being used, right?
<tuxillo>
maybe that logic is flawed
<dgp>
low power mode in this case probably means the chip doesn't listen for data all of the time and periodically wakes up instead
<dgp>
which could very well cause packets to get dropped
<tuxillo>
the next question would be if that behaviour can be changed
<dgp>
if these people that have SSH issues know how to dump wifi traffic properly then it's something that can be looked into
<beeble>
pcap or it didn't happen
<tuxillo>
well I was talking about my case, I don't know if anybody else is having the same
<dgp>
tuxillo: So the sample size is one.. you need to dump the traffic (the wifi traffic not just the packets) and see what happens around the disconnect
<tuxillo>
alright
<dgp>
it might be totally unrelated to the driver
<tuxillo>
i can also go and disable power management with iwconfig
<dgp>
tuxillo: are you running the legacy kernel driver?
<tuxillo>
whatever that comes with raspbian
<dgp>
the legacy driver constantly tells the chip it can go to sleep when it sees there is nothing to transmit and that probably causes a lot of problems
* dgp
ripped all that stuff out
<tuxillo>
well disabling power management with iwconfig didn't work
<tuxillo>
ssh connection is sluggish
<dgp>
what does uname -a say?
<tuxillo>
Linux orangepizero 3.4.113-sun8i #50 SMP PREEMPT Mon Nov 14 08:41:55 CET 2016 armv7l GNU/Linux
<dgp>
Ok, no ones going to fix the driver on old crappy kernels. It works well enough on mainline and I think mainline images for the pi zero are coming
<tuxillo>
hehe
<tuxillo>
you are referring to armbian or anything else?
<dgp>
Some of the armbian guys have added my fork of the xradio driver into their mainline build
<tuxillo>
I see :)
<tuxillo>
those post are really recent
interrobangd has quit [Quit: Leaving]
<dgp>
I'm sure there will be images you can just download and use eventually. But really if you want perfect wifi don't try a board with a weird undocumented chip :)
<MoeIcenowy>
dgp: do your fork support device tree mac now?
foxx has quit [Ping timeout: 248 seconds]
<dgp>
MoeIcenowy: yes, u-boot even inserts mac addresses based on the SID data so they are constant
<tuxillo>
dgp: don't get me wrong, I don't want perfect wifi. however if I am 50cm far from the router I would expect I don't have 500ms delay in my ssh connections
<tuxillo>
:)
fkluknav has joined #linux-sunxi
<wens>
too much buffering?
<dgp>
wens: I think it's probably partly the interrupts and the original driver only using waiting local traffic to decide if the chip should go to sleep or not
<tuxillo>
i'm going to try the kernels instructions for the opi0
<tuxillo>
and see what I get
Worf has joined #linux-sunxi
Worf has quit [Client Quit]
<tuxillo>
in any case the wifi connection is a plus, it's not my end goal
<dgp>
tuxillo: you can have it as a client and an access point with the mainline driver.. which is really handy for setting up headless machines :)
<tuxillo>
my goal is creating a solar powered setup with either the opi0 or a nanopi neo (which didn't arrive yet btw)
<tuxillo>
I got 9h uptime with 33% of a 6000mAh battery, I am pretty happy about that
<tuxillo>
and that is without any power tweaking
<dgp>
tuxillo: are you going to use an external ADC to monitor it?
Worf has joined #linux-sunxi
<tuxillo>
I don't know yet
<tuxillo>
I don't even know how I will setup anything yet, I have to research and learn a lot
<beeble>
just out of curiosity. what should the setup do at the end?
<tuxillo>
the next step is finding a usb 3g modem which is supported well and doesn't consume a ton of power
<dgp>
3g is fun. I think the first thing you'll hit is the board resetting as soon as you turn the modem on ;)
<tuxillo>
beeble: it won't don anything specific. it's just an can-do exercise
<tuxillo>
nice
<tuxillo>
too much power?
<dgp>
tuxillo: you can get old 3g mini-pci cards (actually usb) and a mini-pci to usb carrier cheap off ebay that'll work
<tuxillo>
really?
<dgp>
tuxillo: in-rush current. I had to add huge caps to the board (GR Peach) I was using a 3g modem on and that has a decent power supply
<tuxillo>
ok
<dgp>
tuxillo: look for mc8355 on ebay. They are $10, probably ripped out of old laptops
<tuxillo>
ok
<dgp>
those are good because they have the firmware onboard so you don't need to mess around trying to find the right one
<tuxillo>
what about the mpci to usb?
<jelle>
depends on what you want, might want to look at lora
<dgp>
"usb mini pci" should give a bunch of them
<tuxillo>
yeah sure, i was asking for a specific recommendation, something you know works well :)
<tuxillo>
beeble: that is exactly to fit the wwan minipci in?
<tuxillo>
wow
<tuxillo>
i mean, i would have thought this was a hack more than anything else
<beeble>
tuxillo: yes,i use them during development to test minipci cards. just be sure to check you minipcie wan card is actually a usb card and not a pcie
<dgp>
yeah, you need that, a 3g card and then a set of antennas.
popolon has joined #linux-sunxi
foxx has joined #linux-sunxi
<ErwinH>
Got my PC2 booting from SD with u-boot from apritzel
<jonkerj>
ErwinH: I am working on a fully automated (ie hands-off) voltage calibrator, targeted at h3 but very generic
<jonkerj>
from what I read here, you may be doing more or less the same
<ErwinH>
Yep, I'm doing it for the H5.
<jonkerj>
my goal is to create a piece of software that runs on any sunxi board, goes through a series of tests, and produces a sensible set of operating points
reinforce has joined #linux-sunxi
<ErwinH>
I'm simply running the tests and gather the outputs. Based on that output I create a sane DVFS table.
<jonkerj>
sounds more or less the same
<tuxillo>
dgp: I think the final setup is not going to be pretty :P
<jonkerj>
still need to connect the dots, I think I have 90% of the required parts (wrappers) in Python
<jonkerj>
ie, wrappers around thermal, cpufreq, operating points and regulator to have some software component make intelligent decision (= bisect search)
<jonkerj>
what do you use to impose load on your H5, given a certain frequency/voltage?
<jonkerj>
if I put too much load on my H3, thermal kicks in and changes the voltage. If I put no load, the test is not really meaningful
<ErwinH>
I disable any form of throttling and set everything by hand.
<ErwinH>
Using peekpoke and i2cset
<jonkerj>
and by disabling you mean changing the cooling-device/thermal zone in DT?
<ErwinH>
Then I start a test (xhpl) and monitor the temperature to make sure it doesn't overheat to much ( over the 95C )
<jonkerj>
ah
<ErwinH>
Make sure the cpufreq-dt isn't loaded and the i2c-bus is available. (disabling the sy8106a driver)
<jonkerj>
I am leaning towards reboot loops using 'fdt set' commands in a uboot script
fire219 has quit [Ping timeout: 256 seconds]
<ErwinH>
Is an option, but you risk a kernel panic because of a voltage which is too low, from which you can't recover without altering the dtb/fdt
<ErwinH>
But the peekpoke / i2cset is just way quicker
<ErwinH>
But if it doesn't have an sy8106a you probably can't use it.
leviathanch has quit [Ping timeout: 248 seconds]
<ErwinH>
jonkerj: What will you be using to test the stability of the SoC?
arete74 has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser>
tuxillo: https://img.armbian.com/ -- there's a 'nightly next' build which contains dpg's XR819 mainline driver (though already outdated since added as a patch 6 days ago).
<jonkerj>
ErwinH: 'stress' for 10 minutes without crashing
<ErwinH>
Does that ensure you that there isn't any datacorruption?
<tuxillo>
instead of using the whole nightly
<jonkerj>
ErwinH: of course not
<jonkerj>
but you never can
<tkaiser>
tuxillo: No idea, this is WiP and I'm not up to date what works where (eg. kernel repos up to date). Using the nightly build you get what you want and can then update the usual way.
<tuxillo>
hm, ok thanks
<tkaiser>
jonkerj: xhpl goes in that direction. Reporting data corruption as a result of undervoltage at a specific DVFS OPP.
<jonkerj>
k, I can look at that
<ErwinH>
That's the reason I use xhpl :)
<jonkerj>
in the end, the way I 'test' in my framework is just a matter of firing off a binary
<jonkerj>
changing that is pretty easy
<jonkerj>
and about crashing and recovering: first line of defense would be the WD, but I assume this will crash too. I have a bit luxerous setup with a remote controllable relay
<jonkerj>
so I personally can recover, although not fully automatic (yet)
<ErwinH>
And there is another issue. stability at different temperatures. The lower the temp the less voltage is needed for the soc to be stable.
<jonkerj>
yeah, I was afraid about that
<ErwinH>
Or, the higher the temperature the higher the voltage.
<jonkerj>
the boards are stuffed in my utility closet which approximates outside temperature
<jonkerj>
so I should repeat anything I do in summer
<ErwinH>
Which isn't a big issue for the higher speeds, but when throttling starts the temperature is high but the freq is tested at a lower temp.
<jonkerj>
I've heard rumours that the sy8106a is sensitive to board input voltage as well
<jonkerj>
so that my calibration result is not independent of input voltage
<ErwinH>
So dropping from 1200MHz @ 1.3V which is stable to 1000MHz @ 1.1V which is also tested stable at 70C but might not be so stable at 80 or 90C.
<jonkerj>
so we need dvdfs instead of dvfs :-)
<tkaiser>
jonkerj: Sources for that? I only experienced that behaviour on the SY8113 equipped boards.
<jonkerj>
tkaiser: unfortunately not
<jonkerj>
may have read it here or on a forum
<jonkerj>
could be based on an observation with an underpowered PSU
<tkaiser>
jonkerj: Should be confirmed by measuring test points. I powered OPi PC with 4.5V up to 5.5V and everything (expect USB and HDMI of course) worked flawlessly.
<jonkerj>
could, I will not worry about that then :-)
<tkaiser>
ErwinH: Based on your tests how far away are you from the 'recommended settings' based on comments in fex file?
<tkaiser>
Thinking about the necessary safety headroom (eg. adding 40mV to each DVFS operating point)
<ErwinH>
There is some improvement, but the biggest improvement is the added points.
<tkaiser>
ErwinH: Those added points are then used when throttling starts? I have to admit that I'm only familiar with legacy kernel here :(
<tkaiser>
Did only a short test with megi's patches and mainline kernel and had to observe that cpufreq jumped between 816 and 1200 MHz on an OPi One and never used the possible 1008 MHz in between.
<tuxillo>
so almost 12h uptime and the battery has > 33% battery, not sure exactly how much because it only has 3 led indicating capacity
victhor has joined #linux-sunxi
leviathanch has joined #linux-sunxi
<KotCzarny>
willmore: i think i have gotten ~20MB/s with realtek 8188eus dongle on opipc once
fire219 has quit [Ping timeout: 248 seconds]
<ErwinH>
tkaiser: I'm not 100% sure, but I believe they do. But I'll be running some tests later today to validate those findings, and compare the xhpl benchmark between the original dvfs settings to my settings.
fire219 has joined #linux-sunxi
<tuxillo>
dgp, beeble: I have found an Pci-e WWAN to USB in Aliexpress, just 7,85eur
<tuxillo>
will order 2 ofc
<tkaiser>
ErwinH: Looking forward to it. When we (Armbian) played around with dvfs/cpufreq settings for H3 devices adding as much operating points as possible was at least the most important step to improve performance as soon as throttling jumped in.
<tkaiser>
ErwinH: And for this the cpuminer mode was convenient since khash/s gives a direct impression :)
<KotCzarny>
tuxillo: it will work only with wwan cards that are already using usb part of pci-e
<tuxillo>
how do I check that?
<KotCzarny>
specs?
<ErwinH>
On the other hand, xhpl will show a better comparison between the different dvfs-tables.
<KotCzarny>
but i think most of them do
<KotCzarny>
you can probably differentiate by checking lsusb and lspci in laptop with your card inserted
<tkaiser>
ErwinH: Sure but this was just to check efficiency of the whole setup (behaviour of throttling/cpufreq code). As soon as more operating points were available the MHz steps weren't that large as before *and* also khash/s increased.
xes has quit [Ping timeout: 258 seconds]
xes has joined #linux-sunxi
xes has quit [Remote host closed the connection]
fire219 has quit [Ping timeout: 248 seconds]
fire219 has joined #linux-sunxi
<tuxillo>
KotCzarny: dgp recommended one from ebay, mc8355. i guess he already counted with that
<Wizzup>
Weird, I guess alibaba is lying (not that weird)
<MoeIcenowy>
if it have HDMI
mossroy has quit [Quit: Leaving]
<MoeIcenowy>
it may be A31s
<Wizzup>
Ah, it does list A33/A31s
<KotCzarny>
in description its:
<KotCzarny>
ATM 7029B quad core
<Wizzup>
Huh... alibaba...
<KotCzarny>
maybe you select model somewhere
<MoeIcenowy>
it's silly to believe everything on alibaba
<KotCzarny>
well, they usually copy paste and only update parts of the text
TheSeven has quit [Ping timeout: 245 seconds]
TheSeven has joined #linux-sunxi
<tkaiser>
Wizzup: they mention ATM7029, A31 and A33. ATM7029 is an Actions Semi SoC now sold also as S500. So this is just boilerplate madness ;)
<tkaiser>
Also fun to search for H5 TV boxes on Alibaba. You find some but in the description it's always S905(X).
<MoeIcenowy>
it
<MoeIcenowy>
it's something called SEO ;-)
<Wizzup>
MoeIcenowy: I realise it may be silly, I was just searching for some allwinner tablets with hdmi (sound some a10 ones), and then this popped up
<Wizzup>
thanks for the help all
<Wizzup>
Most other places don't really have A10 tablets anymore
ErwinH has quit [Read error: Connection reset by peer]
ErwinH has joined #linux-sunxi
fire219 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<plaes>
hum.. what happened to lists.infreaded ?
deskwizard has joined #linux-sunxi
apritzel has quit [Ping timeout: 256 seconds]
<willmore>
KotCzarny, that's really good performance for a dongle.
<plaes>
ok, back
cosm has quit [Remote host closed the connection]
victhor has quit [Ping timeout: 258 seconds]
fire219 has quit [Ping timeout: 248 seconds]
premoboss has quit [Ping timeout: 258 seconds]
fire219 has joined #linux-sunxi
lemonzest has joined #linux-sunxi
DullTube has quit [Quit: Leaving]
premoboss has joined #linux-sunxi
Pepe has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
afaerber has quit [Quit: Leaving]
foxx has quit [Ping timeout: 248 seconds]
Mr__Anderson has quit [Quit: Leaving.]
cosm has joined #linux-sunxi
afaerber has joined #linux-sunxi
fire219 has quit [Ping timeout: 256 seconds]
fire219 has joined #linux-sunxi
afaerber has quit [Ping timeout: 245 seconds]
afaerber has joined #linux-sunxi
fkluknav has quit [Ping timeout: 272 seconds]
fire219 has quit [Ping timeout: 248 seconds]
msevwork has quit [Quit: Leaving]
IgorPec has quit [Ping timeout: 258 seconds]
fire219 has joined #linux-sunxi
fkluknav has joined #linux-sunxi
xes has joined #linux-sunxi
<ErwinH>
tkaiser: Using the performance governor I achieve a 10% improvement over the settings from allwinner, but throttling kicks in hard, which doesn't seem correct.
perr has joined #linux-sunxi
apritzel has joined #linux-sunxi
<ErwinH>
apritzel: I applied (and altered) the patches for FIT support and u-boot is booting perfectly!
<apritzel>
ErwinH: I am about to preparing them for a post
<MoeIcenowy>
apritzel: is there any perfect document to build FIT-based A64/H5 boot image?
<ErwinH>
But I simply overwritten common/spl/spl_fit.c, altered board/sunxi/board.c to fit my needs and of course changed the defconfig.
<apritzel>
MoeIcenowy: FIT support and H5 support are orthogonal, and atm I don't have a combined tree
<MoeIcenowy>
maybe I should at first dig out why DE2 on A64 do not work :-(
cosm has quit [Remote host closed the connection]
<apritzel>
MoeIcenowy: maybe even fix it :-D
<MoeIcenowy>
after digging out "why" of course I will fix it ;-)
<MoeIcenowy>
but it seems that jernej's code needs really some refactor for merging...
cosm has joined #linux-sunxi
foxx has joined #linux-sunxi
my123 has quit [Ping timeout: 248 seconds]
<montjoie>
MoeIcenowy: I see yo have a V3 SoC, could you test(activate in DT) sun4i-ss on it ?
<montjoie>
according to datasheet it got one
IgorPec has joined #linux-sunxi
<MoeIcenowy>
not V3 but V3s.
<MoeIcenowy>
but I will try
<montjoie>
V3s I should say
<montjoie>
I read the datasheet you pointed yesterday
ErwinH has quit [Remote host closed the connection]
foxx has quit [Ping timeout: 272 seconds]
my123 has joined #linux-sunxi
my123 has quit [Changing host]
my123 has joined #linux-sunxi
fkluknav has quit [Ping timeout: 256 seconds]
perr has quit [Quit: Leaving]
alexxy has quit [Ping timeout: 265 seconds]
fkluknav has joined #linux-sunxi
<zoobab>
will resend an email for the fosdem dinner
<zoobab>
if you are interested, tell me so
ErwinH has joined #linux-sunxi
<premoboss>
hi, i a, playng with nanopi-NEO (daily version ubunto xenial, kernel 4.9.0). I installed and works, but i want to test uart, so i must play with dtb... i converted into dts (human readable) but is quite different from fex file i am used to. I wanto to activate UART2 and UART1. i see there are some entries as uart@0 and uart1/2, but there are no flag to say user it or not use it. there are some manual around that teach how
<premoboss>
to play with dtb/dts file for nanopineo?
ErwinH has quit [Ping timeout: 245 seconds]
apritzel has quit [Ping timeout: 272 seconds]
ErwinH has joined #linux-sunxi
<beeble>
premoboss: the essential part is status = "okay" or status = "disabled" that would match to your enable flag
ErwinH has quit [Ping timeout: 240 seconds]
<premoboss>
beeble, it means that dts is incomprete because that "status = " line is missed. i fount a doc that explan sintax of dts, i will study it.
<beeble>
premoboss: can you pastebin your dts?
<premoboss>
wait
<premoboss>
pastebin.com/BYtPkamw
<beeble>
premoboss: Line 634
<beeble>
and 648
<premoboss>
wait
<beeble>
these are the sections for uart1 and 2
<beeble>
both are disabled
<premoboss>
ah-... i loot to uart section, not to serial section :-(
<premoboss>
loot/look
<premoboss>
so it enough to switch to okay istead of disabled?
<beeble>
the uart sections above is the pin definition
<premoboss>
ah yes.
<beeble>
no
<premoboss>
mmm i am confused.
<premoboss>
uart section assign phisical pins, ok.
<premoboss>
serial section care about enable/disabled
<beeble>
you have to enable it with status = "okay" but also add the reference to the pin definition in the serial section
<beeble>
pinctrl-names = "default"; and pinctrl-0 = <referenceofpins>
<premoboss>
beeble,. do you have a configuration set that work for sure that i can study?
<beeble>
0x0000003b for uart1 0x0000003d for uart2
scelestic has quit [Read error: Connection reset by peer]
<beeble>
you can see the reference as phandle in the uart pin sections
<beeble>
no, i don't own that hardware. just looked at your dts
<premoboss>
ok
scelestic has joined #linux-sunxi
<beeble>
since it's converted from a binary it's a lot more confusing then the real source version
<beeble>
usually you would use names for the references and not these numbers. also it's more then one file merged into one
<beeble>
so if you want to learn that stuff it would be better to look into the source instead using the blobs
alexxy has joined #linux-sunxi
<premoboss>
is the original dts source presen into linux kernel source files?
<beeble>
yes in the arch/arm/boot/dts/ directory
<beeble>
but no idea what your binary is based on
<premoboss>
i found it, is named sun8i-h3-nanopi-neo.dts. but it is little, it seems it is used only to import other configuration files
<premoboss>
tkaiser, do you meand i must patch the existing sun8i-h3-nanopi-neo.dts adding that you post? or is enoug to wait next release or armbian?
<premoboss>
i use nanopineo, not nanopiair
<tkaiser>
premoboss: This patch adds dvfs (and WiFi). So in case you want to use it you should apply it too if you do a manual compilation of the DT file.
<apritzel>
KotCzarny: yeah, I remembered those, thanks for the nick
<apritzel>
but he also mentions: "UART do not work higher than 2.nnMbps , I tried with minicom (check by oscilloscope)"
<KotCzarny>
nah, he later says minicom sucked his balls
<KotCzarny>
and was a reason of instability
<KotCzarny>
check the second link
<apritzel>
mmh, possibly
<beeble>
just as a sidenote. rockchip has its uart running at 1500000 baud as default
<KotCzarny>
1.5Mbit < 12.5Mbit
<beeble>
you need a newer picocom then available in jessie to support that baudrate :)
<apritzel>
beeble: that's what we get already with the current setup
Amit_T_ has joined #linux-sunxi
<apritzel>
beeble: which is mostly due to that ancient and broken way of setting the baudrate in Linux, isn't it?
fkluknav has joined #linux-sunxi
<beeble>
KotCzarny: absolutely, just was the first time i have seen a devboard using such a high baudrate by default.
<apritzel>
because it used to use constants to describe certain standard baudrates, and communicating arbitrary baudrates is using a different API
<KotCzarny>
beeble: does it change power draw when unused or doesnt matter?
<beeble>
KotCzarny: haven't checked. also it's a bit hard to verify, since someone has to generate the characters or at least receive them. so the cores will not be idle and change the results
<KotCzarny>
well i meant in the idle/closed uart
<apritzel>
beeble: can't we use DMA for sending a loop of some characters?
fkluknav has quit [Ping timeout: 246 seconds]
<beeble>
apritzel: thats a lot of effort for something i wasn't interessted to begin with :)
<apritzel>
beeble: sure ;-)
<apritzel>
does anybody know what the default baud rate tolerance is for UARTs?
<apritzel>
was that 1%?
<beeble>
KotCzarny: i would think the difference will be neglectable. but i will try to think about it the next time i do some testing and let you know
<apritzel>
15 Mbps seems to be a good compromise: PERIPH0(2x) = 1200 MHz / 5 = 240 MHz / 16 = 15 Mbps max baud rate, with exact hits on 1.5 and 3 Mbps and only 0.16% deviation from 115200
<apritzel>
dgp: indeed, using LibreOffice and a "sharp eye"
tgaz has joined #linux-sunxi
<dgp>
Is there a reason for wanting to use UART instead of SPI or something?
victhor has joined #linux-sunxi
<apritzel>
dgp: Bluetooth
<dgp>
feeding data to a bluetooth module with a UART interface?
<KotCzarny>
more like communicating
<apritzel>
dgp: yes, that's exactly what many Bluetooth chips do
<KotCzarny>
using standard protocol/design
<apritzel>
especially those chips used on most Allwinner boards
<dgp>
crazy. SPI would be so much better at the expense of one more line
tgaz has quit [Ping timeout: 245 seconds]
giomba has left #linux-sunxi [#linux-sunxi]
<MoeIcenowy>
especially bluetooth module bundled with sdio wifi ;-)
giomba has joined #linux-sunxi
<KotCzarny>
why alsa mixer control is named 'power amplifier' and not 'Master' or 'PCM' ?
<MoeIcenowy>
e.g. Ampak ones and Realtek ones
<KotCzarny>
*grumble*
<MoeIcenowy>
apritzel: I think you have never tried to driver rtl8723bs of Pine64 up, right?
<MoeIcenowy>
or you just have no such module?
tgaz has joined #linux-sunxi
<beeble>
dgp: since i support someone with his spi connection at the moment and running as always in the issue of having to explain the different spi modes. i understand that someone goes with uart :)
<apritzel>
MoeIcenowy: Bluetooth worked, with this one dodgy user space driver instead of the standard one
<MoeIcenowy>
yes...
<apritzel>
MoeIcenowy: but I never tried WiFi
<MoeIcenowy>
ah-oh
<MoeIcenowy>
what I most wanted is wi-fi ;-)
<apritzel>
sure
<dgp>
beeble: Try all of them until one works is the usual way of doing it ;)
<MoeIcenowy>
now I used a mt7601u dongle to get Pine64 connected
<apritzel>
I just checked BT because it looked like a low hanging fruit ;-)
tgaz has quit [Ping timeout: 248 seconds]
<MoeIcenowy>
with DLDO4 enabled?
ErwinH has joined #linux-sunxi
<beeble>
dgp: don't see the code, just receive scope screenshots :)
<beeble>
but this time it was easy
<beeble>
all 0x55 instead of 0xAA
tgaz has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
ErwinH has quit [Ping timeout: 240 seconds]
deskwizard has quit [Ping timeout: 248 seconds]
massi has quit [Quit: Leaving]
tgaz has quit [Ping timeout: 248 seconds]
tgaz has joined #linux-sunxi
<dgp>
waveforms are a lot more useful than "it don't work, it's your fault, fix it" :)