Pepe has quit [Read error: Connection reset by peer]
Pepe has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
Pepe has quit [Read error: Connection reset by peer]
Pepe has joined #linux-sunxi
leviathancn has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
Mr__Anderson has quit [Ping timeout: 268 seconds]
Gerwin_J has joined #linux-sunxi
wzyy2 has quit [Ping timeout: 240 seconds]
Mr__Anderson has joined #linux-sunxi
Andy-D has joined #linux-sunxi
vickycq has quit [Ping timeout: 240 seconds]
cnxsoft1 has joined #linux-sunxi
<Wizzup>
for the pine64 special usb-a male to usb-a male cable, do I connect the 5v as well?
cnxsoft has quit [Ping timeout: 240 seconds]
cnxsoft1 is now known as cnxsoft
<NiteHawk>
Wizzup: yes. pre-made cables do, and i think the +5v is needed to have the pine port detect / go into OTG mode
<Wizzup>
I'm making it now
popolon has joined #linux-sunxi
<NiteHawk>
(Note that this won't power the pine, it's just needed to prevent the port from being treated as a standard 'host' one. You still need to supply power to the Pine via PWR micro usb, or GPIO pins.)
f0xx has quit [Ping timeout: 268 seconds]
LargePrime has quit [Ping timeout: 268 seconds]
vickycq has joined #linux-sunxi
LargePrime has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<Wizzup>
ack
Andy-D has quit [Ping timeout: 268 seconds]
<MoeIcenowy>
NiteHawk: no there's no any detect.
<Wizzup>
NiteHawk: works
<Wizzup>
MoeIcenowy: so should I cut the 5v wire now? ;)
<MoeIcenowy>
5v do not affect
Gerwin_J has quit [Quit: Gerwin_J]
<Wizzup>
MoeIcenowy: as in, don't want to connect vcc to vcc, but it seems to work, so ...
Gerwin_J has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
ErwinH has joined #linux-sunxi
f0xx has joined #linux-sunxi
fl_0 has quit [Ping timeout: 260 seconds]
fl_0 has joined #linux-sunxi
ErwinH has quit [Remote host closed the connection]
<MoeIcenowy>
montjoie: ping
<MoeIcenowy>
can you read the backlog I wrote on ~15:00 UTC?
<MoeIcenowy>
about dwmac-sun8i on V3s
<MoeIcenowy>
no PHY is probed (V3s supports and only supports integrated PHY
ErwinH has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
ErwinH has quit [Ping timeout: 255 seconds]
<montjoie>
MoeIcenowy: which compatible dt do you use
<MoeIcenowy>
h3
<MoeIcenowy>
only H3 compatible supports internal PHY
<montjoie>
could you paste dmesg ?
<montjoie>
no user manual for v3s ?
wzyy2 has quit [Ping timeout: 260 seconds]
<MoeIcenowy>
there is.
<MoeIcenowy>
the user manual is in datasheet
ErwinH has joined #linux-sunxi
<montjoie>
in DT, what address is set for phy ? (try 0)
LargePrime has quit [Ping timeout: 268 seconds]
<MoeIcenowy>
I'm rearranging R40 patchset now, may test it several minutes later
<wens>
iirc, the address programmed in the syscon has to match
<wens>
though maybe you could make the driver probe the address found in the DT into the syscon :p
<MoeIcenowy>
the register is at 0x30 according to the DT.
<MoeIcenowy>
(syscon EPHY configuration register
<wens>
MoeIcenowy: montjoie means the "register" property in the phy node under dwmac, not the syscon
<montjoie>
yes reg = <1>;
<montjoie>
0 is for PHY DHCP:)
<muvlon>
is it time to make a wiki page for the R40 yet?
klarrt has joined #linux-sunxi
<wens>
probably yes
<muvlon>
I don't have a bpi m2 ultra yet, so I can only scrape info off the net
<tkaiser>
jelle: Has PMIC + battery support. That's the only interesting feature. Everything else is more or less the same as NanoPi Air (A33 vs. H3 though)
<jelle>
oh that's nice
<tkaiser>
jelle: And LCD/TS support like Olimex' A33 board.
<MoeIcenowy>
the LCD is unfortunately MIPI-DSI
<wens>
probably same as a83t
<wens>
bpi does have rgb/dsi dual interface lcd panels
<montjoie>
MoeIcenowy: yes the init phy is done when netdev is "opened"
<montjoie>
MoeIcenowy: so it works now ?
<MoeIcenowy>
now it's sun8i-dwmac 1c30000.ethernet eth0: Could not attach to PHY
<MoeIcenowy>
do not work.
<MoeIcenowy>
but the BUS_CLK_EPHY is passed
<MoeIcenowy>
maybe I should set phy's reg back?
<montjoie>
you could try
ErwinH has joined #linux-sunxi
<MoeIcenowy>
still Could not attach to PHY.
<techping>
http://linux-sunxi.org/Mainline_U-Boot said that H3 EMAC Ethernet uboot support is working in progress,is it means H3 uboot don't support the ethernet?
aballier has quit [Ping timeout: 260 seconds]
<MoeIcenowy>
techping: some boards supports
ErwinH has quit [Ping timeout: 268 seconds]
<techping>
MoeIcenowy:some H3 boards support?
<MoeIcenowy>
at least I think so
<jelle>
techping: worked on my orange pi one/pc and nanopi neo
<techping>
My Orange Pi Zero's U-Boot said 'No ethernet found'
<jelle>
well zero is h2 :P
<techping>
yes
<techping>
it's similar ,right?
<MoeIcenowy>
techping: which version?
<techping>
the newest
<swabbles>
apritzel: SPI driver also works on Pine64+ (using your sunxi64-beta branch + my patches)
<MoeIcenowy>
I think 2017.03 have opi zero's ethernet support added by apritzel
* jelle
keeps looking for arch/arm/boot/dts in u-boot
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
BenG83_PB has quit [Remote host closed the connection]
ErwinH has quit [Ping timeout: 260 seconds]
BenG83_PB has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
<rellla>
sry o_o
Da_Coynul has joined #linux-sunxi
<paulk-collins>
hi
<paulk-collins>
is there any cpufreq scaling support for h3 with mainline linux?
<paulk-collins>
as far as I could see, that was done with the help of the axp, which is not there on h3
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<paulk-collins>
ah looks like it's WIP
<willmore>
paulk-collins, I think it's still in -next. What does the mainlining status matrix say?
<paulk-collins>
willmore, it says WIP
<beeble>
willmore: still doing your dual io spi stuff?
<willmore>
beeble, I'm clearing out space in my office for it. :)
<willmore>
It's a bit crowded in there right now.
<beeble>
willmore: just as heads up. we have some code working and will have patches soon
<willmore>
beeble, if you want a guinea pig...
<willmore>
Hmm, I wonder if I have a logic analyzer that'll understand dual-SPI. I bet they don't do that. I may have to code something up for sigrok.
Da_Coynul has joined #linux-sunxi
<willmore>
err, pulseview.
<beeble>
without optimization we get about 1.5 times the speed of single io
<beeble>
tested with 1mb nor flash reads
nemunaire has quit [Quit: quit]
<willmore>
beeble, that's great. How big of transfers are you using?
<willmore>
What SoC was this with? Did you have to do anything special for the wiring?
<beeble>
fifo limit i guess. can't check the code now as i'm already home
<beeble>
a64
<beeble>
no special wiring required
<beeble>
in dual mode miso and mosi gets bidirectional
<willmore>
Okay, so 64 byte transfers--which probably include some command overhead, etc. That's not bad.
<beeble>
yeah, quite some overhead in uboot
<beeble>
ah, and you can only do reads in dual mode. so no benefits for writes
<willmore>
Meh, writes take so long to do, the transfer part of it isn't a big deal.
<beeble>
for flash yes
<willmore>
Yep. I guess if you were using an SPI SRAM..
<beeble>
but if you would configure a fpga for example higher write speeds would be nice
<willmore>
Sure.
<willmore>
Did you mess with the clock speed any or leave it at the default 6MHz?
<beeble>
i only measured the clock in relation to the clocking changes we did. no real testing on transfer speeds
<beeble>
but 50mhz clock rate is no issue
<willmore>
Very nice. This is starting to sound more practical.
<beeble>
at higher speeds i only tested it with my scope decoding. no real device attached
<willmore>
I guess the scope doesn't need to be able to decode dual-SPI anyway. Since all of the protocol happens at single wire mode and just bulk data transfers happen in dual mode.
<beeble>
the only thing on the a64 is, you lose most of the benefits of higher transfer rates in the time it takes the BROM to load the spl from nor in the first place :)
<beeble>
right
<willmore>
Darn Amdahl!
<willmore>
How long does that take?
<willmore>
Do we need to look into a dual stage booter? Some little stub that gets loaded by the BROM and that stub just knows how to load the next chunk at a faster speed?
komunista has quit [Quit: Leaving.]
<beeble>
have not timed it yet. but it checkes the sdcard and emmc first. and that takes some time you can feel
<beeble>
we already have a dual stage loader
<willmore>
True. I assume those have to timeout.
<willmore>
The SPL itself, you mean?
<willmore>
BROM->SPL->uBoot->kernel
<beeble>
even if present the check of the eGON header takes a lot of time it seems
<willmore>
Oh, well. Not much we can do about the BROM
<beeble>
yes. brom loads the 32kbytes of spl. that one loads the uboot second stage (and dtb and atf if you have the full stack) and that one loads the rest
<apritzel>
beeble: "a lot of time" sounds really awful, you should really put this into perspective
<beeble>
at least as long as you don't burn any fuses. you should be able to limit the bootsource to spi
<willmore>
So, you're saying that the time from powerup to the 32K of SPL being done reading is a long time?
<Wizzup>
apritzel: btw, with the pine64 dts I was able to get u-boot to run on the A64 OLinuXino w/ swabbles
<beeble>
apritzel: will measure it for real numbers. but at first i thought we had a software issue until i noticed it realy takes that long to load the spl
<beeble>
ok i should put it into perspective. long is about a seconds. so depends on your definition of long :)
<willmore>
beeble, is this with a board with a uSD slot and a card (without a header) in it?
<apritzel>
well, it's less than a second for me here
<willmore>
Just wondering what the speed difference is between uSD present and not.
<willmore>
One second is pretty quick.
<apritzel>
the SPL boots almost instantaneously, then you see it load U-Boot and ATF for about half a second
<willmore>
Oh, that's plenty fast.
<beeble>
apritzel: a second is long if you are talking about optimizing loading a payload at factor 1.5
<beeble>
it's just not instant on
<apritzel>
instant what?
<apritzel>
U-Boot?
<beeble>
no spl exececution
<apritzel>
seriously: I don't get what the issue here, really
<willmore>
beeble is just bemoaning Ahmdals law.
<beeble>
it's no real issue
<apritzel>
loading Linux takes much longer anyway
<apritzel>
the longest delay is the 2 second timeout in U-Boot for me
<willmore>
If we're going to suck a kernel over that SPI, +/- 1 second isn't going to be noticiable.
<beeble>
it's just to put willmores expection for higher spi transfer speeds into relation
<willmore>
Understood here.
<beeble>
so that there is no real benefit of doing dual io reads
<willmore>
beeble, for the kernel there is.
<apritzel>
beeble: but the SPL and BROM load pretty conservatively anyway
scream has quit [Remote host closed the connection]
<apritzel>
is it 3 MHz SPI clock?
<willmore>
6, IIRC.
<apritzel>
most flash chips can do much faster
<willmore>
But the SoC and the SPI chips claim they can do 100MHz. ;) In a perfect world...
<apritzel>
so yeah, just set the clock to something higher in the SPL
<willmore>
If we just use something more reasonable like 50MHz and get the 1.5x speedup from the dual-SPI, then kernel loads become way more reasonable.
* apritzel
wasn't aware that all problems with the A64 are apparently solved already so that we can now spend time on shaving off 100 ms on boot times ;-)
<beeble>
as i said. its not an issue. just that you lose some time at the start
<willmore>
Now you understand!
<beeble>
apritzel: not the reason we are doing it :)
<apritzel>
so for the kernel it's noticeable, though not too bad
<beeble>
just enhancing the spi driver
<apritzel>
but most boards will come with 2MB only anyway, so no kernel in SPI ...
<willmore>
apritzel, true. But some of us are crazy and will put other chips on boards.
<beeble>
at least i don't see a benefit in it. as we have pleanty of emmc thats also faster
<willmore>
maybe one of those silly NAND SPI flash chips that's large enough for a filesystem on it, too....
<apritzel>
and which SPI driver are we talking about, seriously?
<willmore>
uboot
<apritzel>
we should get that upstream first before caring about performance improvements
<beeble>
apritzel: patches incoming
<apritzel>
I am afraid the (unwritten) rules of Open Source projects say that the first poster wins
<apritzel>
so feel free to comment and review swabbles's and Wizzup's driver
vishnup has joined #linux-sunxi
<beeble>
will have too
<beeble>
at least we have dm as a benefit. even if i still get the feeling dm is a bit hated on the list...
<apritzel>
beeble: you haven't met the real DM opponents yet ;-)
<beeble>
hope i can avoid that encounter :)
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<beeble>
my d20 throws are mostly misses
The_Loko has quit [Quit: Leaving]
Da_Coynul has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
BenG83_PB has quit [Quit: Leaving]
BenG83_PB has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]