<tkaiser>
Also the other fex values differ but those are for legacy u-boot anyway. Can anyone explain to me the consequences of exchanging x3b3bfb with 0x3b3bf9 in mainline u-boot? Does it matter (at all)?
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #linux-sunxi
fl_0 has joined #linux-sunxi
lamer14899180955 has joined #linux-sunxi
lamer14899180955 has quit [Client Quit]
tkaiser has quit [Ping timeout: 240 seconds]
jernej has joined #linux-sunxi
tkaiser has joined #linux-sunxi
rwmjones has quit [Ping timeout: 255 seconds]
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
lemonzest has joined #linux-sunxi
rwmjones has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
scream has quit [Ping timeout: 256 seconds]
Pepe has quit [Ping timeout: 258 seconds]
fkluknav has quit [Ping timeout: 258 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-7099-gca80ee628, build type: debug, sources date: 20160102, built on: 2017-03-12 14:49:35 UTC git-7099-gca80ee628 http://www.kvirc.net/]
scream has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: .]
|Jeroen| has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 260 seconds]
jernej has quit [Ping timeout: 240 seconds]
Pepes has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
foxx has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
fkluknav has joined #linux-sunxi
sunshavi has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
heffer_ has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
heffer has joined #linux-sunxi
jernej has quit [Ping timeout: 260 seconds]
|Jeroen| has joined #linux-sunxi
jrg has quit [Quit: Fear is the mind killer.]
p_rossak has quit [Remote host closed the connection]
jrg has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
mzki has quit [Ping timeout: 268 seconds]
jrg has quit [Client Quit]
<MoeIcenowy>
musb mysteriously refuse to work on my H3/H5 boards now...
jrg has joined #linux-sunxi
mzki has joined #linux-sunxi
jrg has quit [Quit: Fear is the mind killer.]
jrg has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
jrg has quit [Quit: Fear is the mind killer.]
jrg has joined #linux-sunxi
p_rossak has joined #linux-sunxi
r1mikey has joined #linux-sunxi
victhor has joined #linux-sunxi
chomwitt has joined #linux-sunxi
r1mikey has quit [Quit: Leaving...]
<ssvb>
tkaiser: just the reliability and the top clock speed may be different after adjusting these settings
cnxsoft has quit [Quit: cnxsoft]
IgorPec has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
something strange happened: if I boot via FEL musb can work; if I boot via SD it cannot
<tkaiser>
ssvb: Thank you. 'Top speed' will be 408 MHz by default so I don't expect reliability issues. In case Xunlong sends out a dev sample I will give it a try with higher clockspeeds of course using lima-memtester.
massi has joined #linux-sunxi
apritzel has joined #linux-sunxi
<MoeIcenowy>
oh PHYCTL is missing for H3...
massi has quit [Remote host closed the connection]
Ntemis has joined #linux-sunxi
<ssvb>
MoeIcenowy: yes, FEL boot obviously relies on musb, so it should be already at least partially initialized by the BROM
<ssvb>
tkaiser: I think that jemk compared the DRAM controller HW register dumps between boot0 and U-Boot SPL earlier
<ssvb>
tkaiser: do you mean that Xunlong has changed the H3 DRAM config recently (or some time ago)?
<MoeIcenowy>
ssvb: yes PHYCTL is already configured by BROM.
<MoeIcenowy>
and unfortunately the PHYCTL value is missing in H3 config struct of phy-sun4i-usb
wzyy2 has quit [Ping timeout: 260 seconds]
wzyy2 has joined #linux-sunxi
|Jeroen| has quit [Quit: dada]
lamer14899353385 has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
<wens>
the phy driver has not been merged
<MoeIcenowy>
wens: I will contain H3 MUSB PHY fix in v3.
<willmore>
I guess I'll try armbin as it is to get an idea how this looks and wait for the 3/4 part to come through later?
<MoeIcenowy>
I think you can
<willmore>
Okay, that'll let me get started sooner.
<willmore>
I'll just need to write up a program to do some huge transfers and see if they ever stall. We would expect them to at this point, but the latency values might be useful for tuning that 3/4 value.
<willmore>
I'll load the SoC up with different workloads--memory heavy, processor heavy, low clocks, etc.
[7] has quit [Ping timeout: 260 seconds]
<willmore>
See how it varies under those different loads.
<willmore>
I'll have to see what my max clock speed will be. My scope has only 100MHz of BW, so 32MHz seems reasonable. Anything higher becomes electrically difficult to run off of a header anyway.
<willmore>
So, it's only good for an on board device with well laid out PCB traces.
<willmore>
Thanks, MoeIcenowy !
TheSeven has joined #linux-sunxi
cptG has joined #linux-sunxi
<willmore>
Looks like the spi-test program in the kernel may do what I need.
cptG_ has quit [Ping timeout: 264 seconds]
apritzel has quit [Ping timeout: 246 seconds]
xes has quit [Quit: WeeChat 1.6]
LargePrime has joined #linux-sunxi
leviathan has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 268 seconds]
foxx has joined #linux-sunxi
<ssvb>
NiteHawk: are you around?
deskwizard has quit [Read error: Connection reset by peer]
deskwizard has joined #linux-sunxi
lamer14899413462 has joined #linux-sunxi
lurchi__ is now known as lurchi_
tkaiser has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
lamer14899413462 has quit [Ping timeout: 240 seconds]
lemonzest has joined #linux-sunxi
techping has quit [Remote host closed the connection]
foxx has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 240 seconds]
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
leviathan has quit [Ping timeout: 240 seconds]
leviathan has joined #linux-sunxi
lkcl has joined #linux-sunxi
multi_io has quit [Ping timeout: 240 seconds]
multi_io has joined #linux-sunxi
yann-kaelig has quit [Ping timeout: 240 seconds]
r1mikey has quit [Remote host closed the connection]
<MoeIcenowy>
montjoie: could you first send out sun8i-stmmac device tree binding (without send out driver itself now)?
<MoeIcenowy>
I'm trying to model Pine64+ RTL8211E hack in device tree.
r1mikey has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
r1mikey has quit [Client Quit]
wzyy2 has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
<MoeIcenowy>
apritzel: I'm trying to mainline the PIne64+ PHY GbE hack
quinward has quit [Quit: WeeChat 1.5]
netlynx has quit [Quit: Ex-Chat]
<apritzel>
MoeIcenowy: oh, I have some patch already ...
<apritzel>
just didn't get around to test it
<apritzel>
and it didn't work, really
<apritzel>
let me post it somewhere, just a sec ....
<MoeIcenowy>
I did a device tree property now
<MoeIcenowy>
and I will soon send out patches to one of my friends
<MoeIcenowy>
fortunately (unfortunately?) he got a broken board
<apritzel>
yes, I did a DT property too
lurchi_ is now known as lurchi__
terra854 has quit [Quit: Connection closed for inactivity]
jernej has quit [Remote host closed the connection]
reinforce has quit [Quit: Leaving.]
scream has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
xes has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
Ntemis has quit [Remote host closed the connection]
<willmore>
I have managed to overcome most of my stupidity and I now have working SPI on my Orange Pi One running mainline.
<willmore>
So, yay!
<willmore>
Signals look good and it even looks passable to 100MHz. If someone made a well laid out board and put it on the GPIO header, I would expect that you would have good signal integrity.
<willmore>
Of course, it doesn't look all that great with my 100MHz BW scope, long probes, and lashed on connections.
<willmore>
I need to go look at the clock gen and see if there is a way to generate frequencies other than 100MHz/N where N is an natural number.
<willmore>
100MHz to 50MHz to 33.3MHz are pretty big steps.
<willmore>
Also, I haven't monitored the SPI on many boards. Is it normal practice to round *up* the requested clock speed? If I ask for 100..51MHz I get 100. If I ask for 50..34 I get 50. Etc.
<willmore>
I would have expected it to be a 'floor' instead of a 'ceiling' function.
<willmore>
MoeIcenowy, it doesn't appear that your patch nor one like it is in the current 'mainline' Armbian kernel. The spi test program refused to do large transfers, so it must have been getting an error from the driver.
<willmore>
I'll keep poking at it. I have a 320x240 LCD display that I want to try on it. The Rpi boards can't do very fast SPI so it never got to very good frame rates on them. I'd like to try it on a board that can actually *do* 33.3MHz. Maybe even overclock to 50 and see how that works. ;)
<willmore>
Oh, yeah, need to get the loose SPI-NOR chips hooked to it as well.
<BenG83>
how does it handle multiple chipselects? do you have to do that manually regarding DMA transfers?
<BenG83>
on most of my work projects I have one SPI bus with 4-5 devices on it like ADCs or DACs that do DMA transfers once set up
<willmore>
BenG83, there is only one hardware CS.
<BenG83>
and the NXP CortexM4s we use can control multiple GPIOs as chipselects
<BenG83>
ok
<willmore>
So, you'd have to use GPIO as CS or some clever mux with the hardware CS pin and some other selects. Maybe a 74HC128?
<BenG83>
I used a shift register before
<BenG83>
with identical SPI slaves
<BenG83>
so each transfer would just read the next device :)
<willmore>
That's pretty ghetto.
<willmore>
BenG83, for chipsets like these, SPI is generally dedicated to a particular function. If you can handle shared access and slower rates, they go I2C. If you can't handle shared access, they often will dedicate an I2C.
<willmore>
SPI is getting harder and harder to find on SoCs like these.
<willmore>
The ODORID C2 doesn't have *any* SPI.
<BenG83>
yeah I think I would mostly just add a smaller MCU to handle all the SPI and I2C things
<willmore>
That's exactly it.
<BenG83>
like the sensor hub most phones have
<willmore>
yep.
<willmore>
That makes sense from a power standpoint.
<willmore>
No point in waking an A53 to fiddle with some SPI/I2C when you can have a little uC do it for fractions of a uA
<BenG83>
I think on those ´big´ SoC it´s mostly about SPI memory devices
<willmore>
I'm not sure about that.
<BenG83>
not a string of sensors
<willmore>
I'm guessing there are fewer and fewer devices that they need to hook to the main SoC that need SPI level bandwidth.
<willmore>
I2C is twice as pin efficient and can be multiplexed.
<BenG83>
yeah
<willmore>
The BW between little and big devices is getting so large that SPI just isn't needed.
<BenG83>
most of the SPI devices I use have clock speeds beten 0.5 and 5Mhz
<BenG83>
ADCs, DACs, MEMs sensors
<willmore>
GigE, HDMI, LCD on one side and touch screens, acceleromteres, etc. on the toher.
<willmore>
And those can get stuffed onto a sensor uC like you said.
<willmore>
Where the main processor can get a huge dump of data whenever it feels like waking up.
<willmore>
Or take an IRQ if the sensor hub detects something important.
<BenG83>
yeah
<willmore>
Even then, the definition of 'important' can be pretty high level: "I think we're being dropped"
<BenG83>
so you basically just use the SPI on the Linxu SoC to read out the sensor hub
<willmore>
So, don't get too comfortable with having SPI ports ;(
<willmore>
And there are probably better ways to do it than SPI even.
<willmore>
Isn't there a 4Mb/s version of I2C?
<BenG83>
if high speed I2C would see wider adopion
<willmore>
:)
<willmore>
jinx
<BenG83>
but I havent seen many devices :)
<willmore>
Back in my day, 400KHz was fast--and we liked it!
<BenG83>
has all the hardware revs for the last 10 years
lamer14899413462 has joined #linux-sunxi
<willmore>
Cool. So, not a 'fly by night' operation. :)
<BenG83>
heh
<BenG83>
I would want to try to fly a copter with leechiPi
lurchi__ has quit [Ping timeout: 260 seconds]
<BenG83>
*LicheePI
<BenG83>
running NGOS bare metal on a V3s would be cool
<willmore>
Good luck! I get nervous trying to do hard real time on things with caches and MMUs.
<BenG83>
we have a loosely coupled system
<BenG83>
but NGOS runs with 1kHz
<BenG83>
we do everything in 1ms
<BenG83>
read sensors, RC
<BenG83>
prefilter
<BenG83>
update all Kalman fusion filters
<BenG83>
update control
<BenG83>
update output
<BenG83>
repeat
<BenG83>
but you can fly down to 200Hz
<BenG83>
I would be interesting to see the statistics on a Linux SoC running at 1Ghz vs bare metal on a CortexM4 running at 200Mhz
<BenG83>
we gained a lot from switching to CortexM4 from ARM7TDMI-S alone by floating point support
<BenG83>
before that it was all fixed point math
leviathan has quit [Read error: Connection reset by peer]
quinward has joined #linux-sunxi
<lamer14899413462>
BenG83: I don't understand that much but remembered this could be interesting: https://forum.armbian.com/index.php?/topic/1901-patch-for-quick-interrupt-handling-on-the-h3-fast-gpio/
<willmore>
BenG83, I would think that certain functions would need lower latency--flight stability requires more BW than navigation, etc. But, I'm not that level of hardware engineer.
<BenG83>
the attitude control uses ACC and Gyros plus compass and runs with 10Khz sampling rate that gets filtered to 1kHz
<BenG83>
that is the most critical thing
<BenG83>
then there is altitude control that fuses ACC Z acceleration with barometer with GPS
<BenG83>
much slower at 10Hz
<BenG83>
and the position filter operates at 5Hz
<BenG83>
latency is an issue indeed
<apritzel>
BenG83: ethical flying? for "attitude" control I guess you need much more compute power ;-)
<BenG83>
:)
<BenG83>
lol
<BenG83>
I was Embedded World this week and apparently there are now radar sensors for less than 140$
<BenG83>
to do altitude control in the 50-300m range
<BenG83>
terrain following yay
<BenG83>
*at
<BenG83>
on our old flightcontrollers we use a board we made with Olimex
<BenG83>
that socket should we easily adaptable to LicheePi
<BenG83>
*be
laj has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
hanetzer_work has joined #linux-sunxi
<hanetzer_work>
eyo o/
lemonzest has joined #linux-sunxi
lurchi__ is now known as lurchi_
Mr__Anderson has quit [Remote host closed the connection]
bonbons has quit [Quit: Leaving]
<buZz>
eh, V3s has 64MB ram max? :D
<apritzel>
buZz: yes, why?
<buZz>
so very little
<apritzel>
all DRAM is on-die (or at least in the same package), and it has no external DRAM pins
<apritzel>
buZz: if that is too little for you: it's not like Allwinner doesn't have other SoCs ...
Ntemis has joined #linux-sunxi
<buZz>
nah i was just looking at what that licheepi thing was
hanetzer_work has left #linux-sunxi [#linux-sunxi]
<BenG83>
currently we are flying with 512kB :)
<BenG83>
64MB is more than enough :)
<buZz>
:P
<BenG83>
correction, 192kB
<buZz>
all depends what you wanna do, but i see them running X11 in the examples :P
<BenG83>
yeah I think that demo is a bit unfortunate
<BenG83>
I had trouble running anything with X on 128MB years ago with AVR32
<buZz>
yeah as barebones platform it really makes sense i guess
<BenG83>
I would use LicheePi mostly to add some high level functions like display or networking to a project that does otherwise non computational things
<BenG83>
like a small fronted, internet of terrible things type stuff
<BenG83>
a lot easier than to do those things on a baremetal Cortex with lwIP and crude display libraries
Nacho has quit [Remote host closed the connection]