Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
vagrantc has quit [Quit: leaving]
zyliwax has quit [Quit: leaving]
Putti has quit [Ping timeout: 260 seconds]
aalm has quit [Ping timeout: 256 seconds]
aalm has joined #linux-sunxi
PhotoJim has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
anarsoul|2 has quit [Ping timeout: 240 seconds]
GrimKriegor has quit [Ping timeout: 260 seconds]
GrimKriegor has joined #linux-sunxi
scream has quit [Remote host closed the connection]
igraltis1 has joined #linux-sunxi
igraltist has quit [Ping timeout: 264 seconds]
igraltis1 has quit [Ping timeout: 256 seconds]
xes has joined #linux-sunxi
anarsoul has joined #linux-sunxi
igraltist has joined #linux-sunxi
return0e has quit [Ping timeout: 276 seconds]
return0e has joined #linux-sunxi
chomwitt has quit [Ping timeout: 276 seconds]
imcsk8_ has quit [Read error: Connection reset by peer]
imcsk8 has joined #linux-sunxi
lurchi_ is now known as lurchi__
nuuuciano has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
adj__ has quit [Remote host closed the connection]
adj__ has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-sunxi
PhotoJim has quit [Ping timeout: 276 seconds]
victhor has quit [Remote host closed the connection]
cnxsoft1 has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-sunxi
PhotoJim has joined #linux-sunxi
xes has quit [Remote host closed the connection]
dddddd has quit [Remote host closed the connection]
PhotoJim has quit [Ping timeout: 276 seconds]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Changing host]
cnxsoft has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 240 seconds]
nuuuciano has joined #linux-sunxi
PhotoJim has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
TheSeven has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
diego_r has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 256 seconds]
TheSeven has joined #linux-sunxi
swiftgeek has joined #linux-sunxi
<swiftgeek> anyone crimping ipex/u.fl connectors?
TheSeven has quit [Ping timeout: 240 seconds]
[7] has joined #linux-sunxi
f0xx has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
qeed has quit [Quit: Leaving]
hanni76 has joined #linux-sunxi
netlynx has joined #linux-sunxi
montjoie has joined #linux-sunxi
zumbi_ is now known as zumbi
_whitelogger has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has joined #linux-sunxi
xerpi has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.3, revision: git-7269-g7689d8b21, build type: debug, sources date: 20160102, built on: 2018-03-04 22:12:09 UTC git-7269-g7689d8b21 http://www.kvirc.net/]
Gerwin_J has joined #linux-sunxi
nuuuciano_ has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 260 seconds]
megi has joined #linux-sunxi
clemens3 has joined #linux-sunxi
<t3st3r> swiftgeek> well, it neither sunxi nor fully libre, BUT I've just stumbled on THAT!!! https://github.com/seemoo-lab/mobisys2018_nexmon_software_defined_radio
<swiftgeek> t3st3r: i will try to not facepalm too hard
<t3st3r> at least its "sdio" things and "sdr" (wow, I haven't even thought they could THAT)
<swiftgeek> this is spectral stuff
<swiftgeek> oh but pretty decent in performance, interesting
<t3st3r> from what I see it allows one to synthesize arbitrary signal or so
<swiftgeek> t3st3r: well that's why i said spectral
<swiftgeek> t3st3r: you use that to 1. certify device 2. find bess channel for link on both sides
<swiftgeek> *best
<swiftgeek> but i never saw anyone trying to recreate 802.11 frame from it, that's fun xD
<swiftgeek> t3st3r: any idea what they have recreated ?
<swiftgeek> 802.11b/g/n ?
<t3st3r> well, from what I remember, many devices are implemented like that - high speed ADC/DAC and I/Q to radio frontend, but most things do not allow one to touch ADC/DAC directly.
<swiftgeek> t3st3r: ofc they allow
<swiftgeek> you wouldn't be able to certify device XD
<t3st3r> why do you have to touch ADC/DAC directly to certify?
<swiftgeek> how else you are going to do it
leviathan has joined #linux-sunxi
<swiftgeek> i guess you could bake some test routine into chip but that would be mad
<t3st3r> in ath9k it seems there is some special mode for continious emission and so on, but it does not looks like if it deals with i/q samples or so
<swiftgeek> t3st3r: every chip i know of has that feature one way or the other :P
<swiftgeek> it's not always exposed to the user but it's always there for certification
<swiftgeek> so FCC knows that in worst possible scenario the device isn't jamming something important outside of ISM
<t3st3r> ath9k looks more or less like hardware automation, but it internally got ADC/DAC things. Since most things doing RF that way.
<t3st3r> they can't know it for sure in case of ADC+DAC :)
<swiftgeek> well they can since you are driving it directly
<t3st3r> most constraints are calibrations/firmware/etc and one can get well beyond that stuff
<swiftgeek> and with that you bypass firmware and software calibrations
<swiftgeek> which is what matters for fcc
<swiftgeek> it's a bit like absolute maximum ratings ^^
<t3st3r> I can imagine one can well exceed what FCC willing to tolerate by re-programming freq synth and soing arbitrary modulations using DAC directly.
<swiftgeek> t3st3r: this is why you have filters on analog frontend
<t3st3r> I can imagine there are "analog" filters to get rid of out of band emissions, but they would only be anyhow efficient for freqs far away of target ones.
<swiftgeek> xD
<swiftgeek> (SAW filters were there )
<t3st3r> ahh I see, they seems to be desoldered...
<swiftgeek> t3st3r: it's similar to assuming pi=5 for simplification of calculations xD
<t3st3r> fortunately for FCC most users aren't going THAT far :)
Putti has joined #linux-sunxi
fkluknav has joined #linux-sunxi
IgorPec has quit [Ping timeout: 264 seconds]
pmpp has quit [Ping timeout: 240 seconds]
fkluknav has quit [Ping timeout: 240 seconds]
afaerber has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
freemangordon has quit [Ping timeout: 276 seconds]
freemangordon has joined #linux-sunxi
victhor has joined #linux-sunxi
kaspter has joined #linux-sunxi
reinforce has joined #linux-sunxi
dddddd has joined #linux-sunxi
aalm has quit [Ping timeout: 256 seconds]
elros_ has joined #linux-sunxi
<miasma> what do you think about stating the status of board availability (e.g. discontinued) on the device wiki pages?
<miasma> there are quite many now that are not manufactured anymore
reinforce has quit [Quit: Leaving.]
<BenG83> miasma, maybe better to have that on the board table? for sake of keeping that up to date
<BenG83> otoh the board table is not complete
<miasma> what's missing
Putti has quit [Remote host closed the connection]
<[7]> anyone around who could help me figure out the clocking of an H3 chip running with a mainline kernel?
<[7]> I have the impression that my kernel doesn't even know which CPU frequency it's running at and just inherits whatever u-boot set up
<[7]> how much of that can be configured through the device tree, and how?
<BenG83> what does your clock tree say?
<BenG83> cat /sys/kernel/debug/clk_summary
<BenG83> H3 cpufreq/thermal driver is still work in progress
<BenG83> so it is probably fixed to some value from u-boot config
<BenG83> embed-3d is working on that
<[7]> BenG83: very helpful file indeed... https://paste.ee/p/YaSeI
<[7]> heh that mmc0_sample looks like a typo somehow - but no idea where it's coming from, apparently not from the device tree
<BenG83> so it's set to 1008Mhz
<BenG83> btw there is a small tool to measure cpu frequency exactly from willy tarreau
<[7]> I'm currently less interested in the CPU clocking (although getting some ondemand scaling working there would be nice) than in getting the AHB/APB clocks set up right to get reasonable SPI speed
<[7]> so from what this looks like, the AHB-side clock of the SPI is already okay, it's just the "module" clock that should be coming from somewhere else
<BenG83> yeah seems like it's just clocked from the XTAL
<[7]> btw, ehere does this summary file come from? is it read back from hardware control regs or just based on some internal assumptions of the kernel based on the device tree?
<[7]> where*
<BenG83> I guess from the clock-ng framework
<BenG83> probably what is in the registers
<[7]> is it possible to configure these clocks (e.g. CPU, AHB, ...) in the device tree?
<BenG83> should be
<BenG83> the ccu node
<[7]> there's a lot of stuff in Documentation/devicetree/bindings/clock/sunxi.txt but I haven't quite figured out what actually applies to H3 and how it needs to be configured
<BenG83> maybe it's also configured from the SPI node?
<BenG83> if you request a max speed that is >24Mhz?
<BenG83> what is the limit on H3?
<[7]> I'd think 100MHz bus clock, which requires a 200MHz mod clock
<[7]> as far as I can tell there's no "intelligence" in the system that choses a fitting clock, it just takes whatever it gets as mod clk and then tries its best to reach the requested output clock
<BenG83> clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>;
<[7]> yeah, that's referring to the CCU clock gates, but how do I tell it which source clock should be selected on the MUX right before that gate?
<[7]> the relevant hw register is there: http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf page 114-115
<[7]> I'm just wondering how to actually get something in there through the device tree / clock framework
<wens> you tell it what frequency you want, it does its best to fulfill it
<[7]> yeah but where do I tell it that?
<wens> from the spi driver
<wens> clk config is not available to userspace
<[7]> the SPI driver is dumb in that regard
<wens> then you should teach the SPI driver to be smarter :)
<[7]> hmm...
<BenG83> I think it's actually the spi device driver that requests a certain clock speed
<BenG83> not the SPI node itself
<BenG83> like I have a SPI flash node
<BenG83> and that has a speed property
<[7]> it seems to ignore that
iamfrankenstein has joined #linux-sunxi
<wens> the spi host driver does call clk_set_rate
<BenG83> like this for example
<[7]> yes, that's what I have (other than that I have 40MHz clock in there)
<[7]> anyway, it seems like a ton of clocking relationships is still defined in kernel code somewhere? it seems to know a *lot* more than what's actually in the device tree
<BenG83> I guess clk_summary is just the state of the CCU
<BenG83> and whatever is in those registers after reset as a default if it isnt set from devicetree
<[7]> hmmm... just realized that on 4.16-rc6 the whole mtd node for the flash is missing as well
<BenG83> what board?
<[7]> orange pi zero
<[7]> but with a custom device tree
<[7]> that used to work on 4.15 though...
<BenG83> is the spi flash mounted by default?
<BenG83> I think my zero doesnt actually have one on the PCB
<[7]> the newer ones do
<BenG83> ah ok
<[7]> the older ones only had it on the 512MB model
<ElBarto> iirc it was optional
<ElBarto> I'm pretty sure that my 512MB one doesn't have spi populated
<BenG83> I use the SPI flash on the SOPine and there it works ok
<BenG83> but I think at 24Mhz atm
<BenG83> but to load u-boot that's not too bad
<BenG83> if you load a kernel image from flash that maybe a bit slow
<BenG83> afaik the SPI flash driver for u-boot is not upstream anyways
<[7]> yeah but that part I've figured out already ;)
<[7]> IIUC this should work in linux if I just specify compatible="jedec,spi-nor";?
<BenG83> look at my spi example from my Rock64 above
<[7]> yeah, I also had a couple other chip names in there, but IIUC those are just ignored anyway
<BenG83> the basic read/write commands are mostly the same across those spi flash devices
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
<BenG83> but some of the higher performance read/write commands need device specific handling
<[7]> the driver seems to be identifying the chip based on interrogating its ID, not based on the aliases in the DT
<BenG83> I guess the device specific compatible is mostly to add quirks to the driver if necessary
<BenG83> should something come up in the future
LargePrime has joined #linux-sunxi
<[7]> comments in the driver suggest that it's legacy, but people seem to keep using it for some reason
<[7]> so if I wanted to change the CPU/DRAM clock, how would I do that through the DT?
<[7]> and how would I get runtime DVFS / cpufreq working?
<BenG83> you need to grab one of the wip branches for DVFS
<BenG83> and the thermal driver
<BenG83> then you can add opps to the dts
<BenG83> and thermal zones
<BenG83> not sure how much of it works for H3 already
<BenG83> embed3 is away for exams and his thesis work afaik
<BenG83> maybe shoot him a mail
<[7]> and if I want to configure static values, is that already working in 4.16?
<BenG83> I think you need to go via u-boot atm
<BenG83> the clock should be in the config
<[7]> yeah, I have a custom u-boot anyway, I had just hoped to be able to change it without having to reflash the bootloader
<[7]> and I don't think u-boot can pick it from the environment - this is possibly even done in SPL already
<BenG83> 591 clock_set_pll1(CONFIG_SYS_CLK_FREQ);
<BenG83> 591 clock_set_pll1(CONFIG_SYS_CLK_FREQ);
<BenG83> oops
<BenG83> http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=e08e22f30c0ade2256f69a15e3b7f1db01159677;hb=f95ab1fb6e37f0601f397091bb011edf7a98b890
<[7]> heh, now it somehow selects 75MHz SPI peripherals speed if I request 40MHz
<[7]> i.e. effectively runs at 37.5
<[7]> but at least it's setting something
<BenG83> I guess you need to enable clock debugging to see how it arrives at that conclusion
<BenG83> I got turned off from using SPI on Linux SoC pretty quick
<[7]> SPI requests 80, which it can't achieve
<[7]> it could very well go for 200 though and use the SPI's fractional divider
<BenG83> as soon as you have some devices on the bus with multiple chip selects and IRQs
<BenG83> it gets pretty messy
<BenG83> so I usually just add a MCU to handle SPI and I2C stuff
<BenG83> like the sensor hub in phones
<[7]> so this 37.5MHz is an artifact of the SPI driver being dumb again ;)
<[7]> I2C isn't too bad, and for SPI I'm just dedicating a controller to every peripheral
<BenG83> I2C gets tricky again once data ready IRQs are invovled
<BenG83> same problem as SPI
<[7]> none of them here ;)
<[7]> just the CPU polling stuff
<[7]> but I don't see why data ready IRQs would really be a problem?
<BenG83> if you have a kernel side driver that handles it all in one it's ok
<BenG83> if you do stuff from userspace I find it quite a mess
<[7]> if it isn't terribly latency-critical it should just work fine from userspace, I've done that before (on other SoCs)
<BenG83> I was trying to port a flight controller for a UAV from a Cortex-M4 to a Linux SoC
<BenG83> but that isn't really a good use case since everything has to happen well below 1ms
<[7]> heh if you want to do that on a linux soc then that's probably a case for xenomai or something lika that
<[7]> like*
<[7]> but the cortex-m may be the better solution for the realtime part in the first place
<BenG83> we make open source hardware for UAVs
<BenG83> that is the current board
<BenG83> (I usually only do hardware stuff)
<BenG83> it uses two Cortex-M4 that are coupled with a dual port SRAM
<[7]> wow, HUGE stm32s...
<BenG83> the big board-to-board connector is for some extension board with a SoC running Linux
<BenG83> to do some higher level control stuff
<[7]> redundant system with those stm32s?
<BenG83> there are tons of interfaces sensors/actors
<[7]> or just more grunt?
<BenG83> on M4 runs flight control
<BenG83> the other is for user stuff
<BenG83> so you can do some higher level control tasks
<BenG83> older hardware had just a single ARM7
<BenG83> but I guess we are getting to far OT now :P
<BenG83> tl;dr flying with normal Linux is tricky
<[7]> interesting stuff though! :)
<BenG83> the new SoC with AI accelerators are interesting for optical control
<BenG83> another idea is to run Linux on some cores and an RTOS on one ARM core
<[7]> ...or virtualize it with xenomai or something similar
<BenG83> flying usually happens in a control loop running somewhere between 200 to 1000Hz
<BenG83> read all the sensors, update fusion filters, update controller, output actor data
<BenG83> that happens in less than 1ms
<[7]> if all RT code is triggered by IRQs (or highres timers) then that should work quite well
<BenG83> some stuff like compass, barometer and gps updates are way slower
<BenG83> 10-100Hz
<[7]> the problem in the linux environment is contention for locks, which can in turn be waiting for slow I/O
<BenG83> only the attitude control really needs to run at high speed
<BenG83> we use a loosely coupled system so the <1ms is not guaranteed
<BenG83> but it doesnt fall out of the sky at 2ms either
<[7]> well, look into these linux RT virtualization frameworks, they're designed exactly for this kind of thing
<[7]> easy communication with higher-level control within normal linux userspace, but fast response times to HW events
cnxsoft has quit [Remote host closed the connection]
<BenG83> upside of using a Linux SoC running at GHz speed is that you don't have to optimize the fusion filters too much
<BenG83> you can more or less go directly from Matlab to code
<miasma> BenG83: when you said that the table of boards is missing some boards, did you have something specific in mind? i could add them
<BenG83> on the ARM7 with 60Mhz it was all assembly with fixed point arithmetic
reinforce has joined #linux-sunxi
IgorPec has joined #linux-sunxi
qeed has joined #linux-sunxi
Putti has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
reinforce has quit [Quit: Leaving.]
aalm has joined #linux-sunxi
Putti has quit [Ping timeout: 246 seconds]
lurchi_ is now known as lurchi__
Putti has joined #linux-sunxi
lurchi__ is now known as lurchi_
Putti has quit [Ping timeout: 264 seconds]
jstein has quit [Remote host closed the connection]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
xerpi has quit [Quit: Leaving]
jstein has quit [Read error: Connection reset by peer]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
lurchi_ is now known as lurchi__
IgorPec has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
lurchi__ is now known as lurchi_
fkluknav has joined #linux-sunxi
black_ink has joined #linux-sunxi
aalm has quit [Ping timeout: 240 seconds]
BenG83 has quit [Ping timeout: 276 seconds]
yann|work has joined #linux-sunxi
BenG83 has joined #linux-sunxi
yann|work has quit [Ping timeout: 260 seconds]
nuuuciano_ has quit [Ping timeout: 268 seconds]
nuuuciano_ has joined #linux-sunxi
reinforce has joined #linux-sunxi
Putti has joined #linux-sunxi
hlauer has joined #linux-sunxi
lurchi_ is now known as lurchi__
fkluknav has quit [Quit: Leaving]
Ntemis has joined #linux-sunxi
aalm has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
<swiftgeek> t3st3r: do you have personal experience with it?
montjoie has quit [Quit: leaving]
nuuuciano__ has joined #linux-sunxi
nuuuciano_ has quit [Ping timeout: 268 seconds]
<swiftgeek> t3st3r: oh now i get it xD
<swiftgeek> t3st3r: nexmon is the framework that makes patching of fw possible, and the thing you linked builds on top of that
<swiftgeek> t3st3r: thanks
<swiftgeek> this is pretty amazing then
hanni76 has quit [Quit: Leaving]
black_ink has quit [Ping timeout: 265 seconds]
f0xx has quit [Ping timeout: 240 seconds]
reinforce has quit [Quit: Leaving.]
fkluknav has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
leviathan has quit [Remote host closed the connection]
matthias_bgg has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
fkluknav has quit [Ping timeout: 240 seconds]
<hlauer> hi, I have a Banana M2Ultra running with 4.15 stable - can/should I link the crude patches and userspace stuff
<hlauer> lying on bitbucket to the wiki ?
<hlauer> Of course, this is original work from wens and icenovy - only somehow hacket to get the thing working...
<hlauer> s/hacket/hacked
xerpi has joined #linux-sunxi
xerpi has quit [Remote host closed the connection]
xerpi has joined #linux-sunxi
nuuuciano__ has quit [Ping timeout: 240 seconds]
jstein has quit [Remote host closed the connection]
Ntemis has quit [Remote host closed the connection]
<[7]> hmm has anyone had success with highspeed SPI on sunxi (or even h3 specifically?)
<[7]> above 50MHz I'm starting to see bit shifting even with just a simple loopback wire
nuuuciano has joined #linux-sunxi
<BenG83> [7] does H3 have programmable drive strength GPIOs?
<BenG83> from my experience with RK3328 and SPI at 50MHz the signal integrity looked pretty bad on my scope
<[7]> yes, and setting it from 20mA to 40mA doesn't seem to have an effect, it still starts acting up slightly above 50MHz
<BenG83> maybe needs some termination
<[7]> I don't have a scope that can handle these speeds, but touching the pins with probes or fingers doesn't seem to affect it, so I'm kinda puzzled
<[7]> 100 ohms to 3.3V or GND don't seem to affect it in any way either
<[7]> 100MHz keeps failing, 50MHz keeps working
<BenG83> there is a reason eMMC uses 1.8V above 50MHz on those SoC :)
chomwitt has joined #linux-sunxi
<[7]> I don't get why the cliff seems to be that sharp around that frequency - it looks more like propagation delays inside the chip to me
Putti has quit [Remote host closed the connection]
Putti has joined #linux-sunxi
elros_ has quit [Remote host closed the connection]
Putti has quit [Ping timeout: 240 seconds]
xes has joined #linux-sunxi
<[7]> there are 3 bits in the datasheed which are badly documented but sound related: SDM, SDC and RPSM
<[7]> other than screwing up slower speed transfers they don't seem to have any effect though
<BenG83> [7] does the H3 datasheet have AC stats for the GPIO pins?
<BenG83> wrt rise/fall times etc
<[7]> nothing useful
<[7]> 5pF capacitance and trigger thresholds at 0.3/0.7*VCC_IO, that's about all that 's specified
<[7]> drive strength is supposedly configurable from 10mA to 40mA in 10mA steps