Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bugzc has quit [Ping timeout: 252 seconds]
Da_Coynul has joined #linux-sunxi
avph has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Da_Coynul has joined #linux-sunxi
Xal1u5 has quit [Ping timeout: 260 seconds]
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
premoboss has quit [Ping timeout: 245 seconds]
premoboss has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
bugzc has joined #linux-sunxi
ninolein has quit [Ping timeout: 245 seconds]
ninolein has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
Axl_z has joined #linux-sunxi
terra854 has joined #linux-sunxi
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
pg12 has quit [Ping timeout: 268 seconds]
pg12_ has joined #linux-sunxi
IgorPec has joined #linux-sunxi
repka has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
premoboss has quit [Ping timeout: 244 seconds]
Gerwin_J has joined #linux-sunxi
foxx_ has joined #linux-sunxi
TheSeven has quit [Ping timeout: 245 seconds]
[7] has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 268 seconds]
jernej has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
gianMOD has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
Putti has quit [Quit: Leaving]
reinforce has joined #linux-sunxi
KotCzarny has joined #linux-sunxi
<KotCzarny>
nope. brctl didnt change anything.
<KotCzarny>
well, it did change something, now i dont even see packets on eth0
<KotCzarny>
:)
vagrantc has joined #linux-sunxi
DullTube has joined #linux-sunxi
gzamboni has joined #linux-sunxi
lkcl has quit [Ping timeout: 265 seconds]
jernej has quit [Ping timeout: 252 seconds]
vagrantc has quit [Quit: leaving]
tkaiser has joined #linux-sunxi
<tkaiser>
Nice, the next round of Allwinner BSP (3.10.65 kernel for R40 -- from 'Tina SDK 20161011') did not appear below tinalinux repo but here: https://github.com/BPI-SINOVOIP/BPI-M2U-bsp
<plaes>
ouch
<tkaiser>
apritzel: BTW: Spotted yesterday that Theobroma sent a PR to longsleep's kernel repo so it seems '4.x' is a copy&paste error since they're busy working on 3.10 for their A64 SoM.
<beeble>
it's a mix. we do support 4.x but not fully featured. it's mainly mainline yet and we will do more work on 4.x later on after we shipped 3.10 to customers who need the 3d acceleration
<tkaiser>
beeble: Thanks, so most importantly you did not get another BSP variant from Allwinner with version 4.x? :)
<beeble>
no
<beeble>
after all it's allwinner :)
<beeble>
their communication get worse and worse by time
<tkaiser>
More Aarch64 stuff from Allwinner to come: In u-boot sources there's sun50iwNp1 with N being 1, 2, 3 and 6.
<tkaiser>
CPU type is 'armv7' and not 'armv8' but I would suspect that's the usual 'copy&paste gone wrong' again?
<beeble>
probably the same dies again in different packages
<tkaiser>
beeble: Yeah, and with different GPU configs and count of other IP blocks (USB and so on)
<wens>
beeble: sorry to here about communication issues :(
<beeble>
by the count of different variants they seem to have in the pipeline i could guess they will have the same die and just bond fewer of the ip blocks out
<beeble>
wens: you learn to live with it :)
lemonzest has joined #linux-sunxi
<KotCzarny>
fun note, legacy kernel oopses during boot with internal usb wifi adapter malfunctioning
<KotCzarny>
fortunatelly quick fix is to disable proper usb controller
<tkaiser>
KotCzarny: Still playing with Crapboard R1?
<KotCzarny>
tkaiser, yeah, i was curious if mainline fixes it at least little bit
<KotCzarny>
but without swconfig support i dont know how the heck its bound to be configured
<KotCzarny>
most obvious brctl configuration didnt work
<KotCzarny>
booted legacy just to check if its working at all because all those cable changes, and yeah, legacy works
<tkaiser>
KotCzarny: Simply use it in the only mode that really works: dumb switch without trying to route
<KotCzarny>
nope, it doesnt work
<KotCzarny>
hehe
<KotCzarny>
that's the bad part, i cant get it to even see/repond to any packet
<KotCzarny>
*respond
leviathanch has joined #linux-sunxi
<KotCzarny>
i suspect it has to be autoconfigured depending on interface status, and/or bridge/vlan config. but im apparently doing something wrong
eduardas_m has joined #linux-sunxi
lkcl has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<wens>
tkaiser: arch/arm/mach-sunxi/Kconfig might have comments explaining the codenames?
Mr__Anderson has joined #linux-sunxi
<tkaiser>
wens: Not that much I fear. For example MoeIcenowy spotted sun8iw10 back in July as B100 (back then on Allwinner's website, but now gone).
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
eduardas_m has quit [Ping timeout: 268 seconds]
gianMOD has joined #linux-sunxi
<beeble>
KotCzarny: which broadcom switch do you have?
<KotCzarny>
b53125
<KotCzarny>
bcm53125
<KotCzarny>
it's a dumb switch included on lamobo-r1
<KotCzarny>
by any chance you have some experience with dsa and configuring such things?
Mr__Anderson has quit [Remote host closed the connection]
<beeble>
a bit, mostly marvell ones but did a little bit with bcm a while ago
<KotCzarny>
cool, do you have any scripts handy?
dr1337 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<beeble>
let me check once i'm in the office. mobile phones and searching for code does not that well as i thought
<KotCzarny>
:)
<beeble>
+match. even typing sucks :)
<KotCzarny>
i have all day, i would be much obliged for any help
arete74 has joined #linux-sunxi
<beeble>
what kernel do you have. as far as i can see now dsa is supported in 4.8
<KotCzarny>
4.9.0-rc3
<beeble>
and one more stupid question. do your external ethernet ports have leds? do you have link when you plug in a cable?
<KotCzarny>
yes, kernel autonegotiates links ok
<KotCzarny>
see things change in /sys/
<KotCzarny>
also light up
<KotCzarny>
*lights light up
<beeble>
thats great, means the switch isnoutbof reset and mdio is working
<KotCzarny>
yup, kernel sees the ports of the switch, its just the config part im failing at
<KotCzarny>
tkaiser, yesh, that much i know, swconfig is not used anymore and they have to be configured automagically with default linux network commands
eduardas_m has joined #linux-sunxi
<KotCzarny>
but they arent, that's why im looking for someone with experience with dsa and/or bridge/vlans
<beeble>
if the switch ports are already visibile in linux via dsa, then you should be able to just youse brctrl
<beeble>
use
<KotCzarny>
beeble, tried it, everything seems to go ok, but no packets are seen/forwarded
<KotCzarny>
might be a bug in b53 driver on lamobo-r1 after all
gianMOD has quit [Remote host closed the connection]
bugzc has quit [Ping timeout: 260 seconds]
<tkaiser>
wens: Looking at arch/arm64/boot/dts/sun50iw*p1.dtsi H5 must be either 2, 3 or 6 (Mali 450)
<KotCzarny>
port8 is supposed to be bound to a20, but how can i monitor it? eth0?
<beeble>
ok will have to come back to you later on that
Nacho_ has quit [Ping timeout: 245 seconds]
<KotCzarny>
also, quick question, i should be able to see packets on those separated interfaces that dsa creates? (lan1 etc)
<KotCzarny>
even without any config?
gianMOD has joined #linux-sunxi
<beeble>
they will inly get forwarded to the port with a sane config. otherwise the switch will drop them or just forward them to another port
<KotCzarny>
its the default one from mainline kernel
<beeble>
seems fine so far. i would think that if you bring your eth0 up, then create a bridge lan and adding lan1 and so on to it and afterwards ifconfig lan up should work
<beeble>
at least thats the stuff i do on my setup
<KotCzarny>
ok, that's what i've done before, but i have questions :)
<KotCzarny>
eth0 is apparently cpu (port8) bound
<KotCzarny>
shall i include it in lan bridge?
<beeble>
no
<beeble>
the port is already defined cpu attached via the dsa
<beeble>
adding it to the bridge will mess things up iirc
<KotCzarny>
then: brctl addbr lan; brctl addif lan lan1; brctl addif lan lan2 should be all thats needed to packet being forwarded/seen?
<beeble>
think so
<beeble>
btw you can add more then one interface in a single brctrl add line
<KotCzarny>
hum. now it worked. o.O
<KotCzarny>
at last forwarding between ports
<beeble>
maybe you added eth0 before or forgot to up your interface. thats a common pitfall
<KotCzarny>
how to make the device itself being seen too? ifconfig lan 192.168.111.111 etc?
<beeble>
yes
<KotCzarny>
then this part is not working
<KotCzarny>
on lamobo i see: 09:49:42.476490 ARP, Request who-has 192.168.111.5 tell 192.168.111.111, length 28
<tkaiser>
KotCzarny: In case you get it working can you please drop a note on the aforementioned github issue in Igor's repo? More than a note (mini tutorial) would be even more great ;)
<KotCzarny>
so somehow lamobo isnt getting that packet back
<plaes>
I was able to re-attach the plastic locker thingy on the pcb-side connector
IgorPec has joined #linux-sunxi
repka_ has quit [Quit: Leaving]
<pcduino>
better get the soldering iron out ;)
<plaes>
I did
<plaes>
but the fpc-side connector was broken
<pcduino>
they can be a pain to replace
Axl_z has quit [Ping timeout: 250 seconds]
<beeble>
you should also order a hot air station on aliexpress next time :)
<plaes>
I have
<jelle>
I would still try to get my money back
<beeble>
plaes: if you are still in buyersprotection you can open a dispute on aliexpress. works quite good. but first you should just contact the seller. often they will send you a replacement
<beeble>
most of the time they will try real hard to get no bad feedback
<pcduino>
they would still refund after ripping it apart and attacking it with an iron? :S
<pcduino>
or did it fall out the box :P
<beeble>
they never asked to send it back anyway
<jelle>
I had that with dealextreme
<jelle>
never asked me to send it back
<KotCzarny>
my bet is that someone opened it badly, then returned, and they've sent it without checking again
<beeble>
so your first picture of it broken should be more then enough
<plaes>
but yeah.. I wanted a tablet, not a devboard :)
<wens>
crap... jffs2 oops on an asus router :(
<beeble>
KotCzarny: had a look at my configs. i don't do anything other then what i have already told you. will asked a colleague at lunch if he knows anything since he worked with a bcm a few weeks back
<KotCzarny>
beeble: as i said, it might be a bug in b53 code, for now i've disabled arp on lan bridge and at least it forwards packets ok, didnt find the trick to make icmp/tcp work though
<KotCzarny>
(when lamobo is sending or receinving connection, and not only forwarding)
reinforce has quit [Quit: Leaving.]
foxx_ has joined #linux-sunxi
dr1337 has joined #linux-sunxi
<KotCzarny>
beeble: care to paste these scripts anyway? also, can you check if you are toggling anything in /sys or /proc or via iptables?
<beeble>
KotCzarny: https://gist.github.com/anonymous/a690ba9f14f01937419201e5fbce1b5e for the second part I would have to find the hardware in the basement. that was a project a few years ago and everything is already packed away. no service contract from the customer so no running support for it
<IgorPec>
wens: I am strugling to boot Cubieboard4 with your latest submission but failing at Starting kernel ... using your sun9i-gmac-wifi branch
<KotCzarny>
thx
utente_ has joined #linux-sunxi
utente_ has quit [Client Quit]
<wens>
IgorPec: try enabling earlycon?
<wens>
add earlycon=uart,mmio32,0x07000000 to your bootargs
<IgorPec>
are there any special loading addresses? I'll try asap
<wens>
you mean for the kernel?
<wens>
just use u-boot's settings ${kernel_addr_r} and ${fdt_addr_r}
Da_Coynul has joined #linux-sunxi
<IgorPec>
i did use defaults ... ok. let me do some more experiments.
apritzel has quit [Read error: Connection reset by peer]
whaf has quit [Quit: Leaving.]
apritzel has joined #linux-sunxi
<KotCzarny>
beeble: thing is, it would be nice to even configure single port as working (ie. without bridge). but apparently it's getting stuck in the same way (ie. lamobo asks for .5 arp, i see it's responding, but it's apparently dropped somewhere before it reaches lan4 port
eduardas_m has quit [Quit: Leaving]
eduardas_m has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dh1tw has joined #linux-sunxi
Axl_ has joined #linux-sunxi
<KotCzarny>
wens, did you ever had bpi-r1 working with mainline? (bcm53125 wise)
Amit_T has joined #linux-sunxi
fl_0 has quit [Ping timeout: 250 seconds]
<wens>
KotCzarny: i didn't program the switch, was just using eth0, ethernet was unstable
<KotCzarny>
but dts part was done by you
<KotCzarny>
and as i know nothing about dts, are you sure its 100% correct? (regarding bcm53125 being dumb and wired to eth0)
<KotCzarny>
im trying to understand where and why packets get dropped (ie. lamobo see traffic ok, but any responses go through eth0 instead of configured/assigned ports
fl_0 has joined #linux-sunxi
<KotCzarny>
well, they should go through eth0 because that's where cpu port is connected, but somehow dont get back onto the switch
<KotCzarny>
or just get dropped by the switch instead of being sent via assigned port(s)
mhlavink has quit [Ping timeout: 268 seconds]
nashpa has quit [Ping timeout: 268 seconds]
alexvf has joined #linux-sunxi
<alexvf>
hi all, is a bug in linux-sunxi 3.4 branch disp module worth to report?
<plaes>
you can try, but not really ;)
<alexvf>
i should imagine
<plaes>
and try out mainline
<alexvf>
what is the state of display subsystem in mainline? i know there was progress but i don't know if video acceletation is fully functional (i believe H264 is not supported for example)
mhlavink has joined #linux-sunxi
<plaes>
there's WIP patchset
gianMOD has quit [Remote host closed the connection]
<plaes>
that works with A13
<alexvf>
hmmm, i need for A20
IgorPec has quit [Ping timeout: 265 seconds]
<alexvf>
by the way, the bug is in sprites code
<alexvf>
i don't know if that is used in mainline at all, but if it is inspired in 3.4 code it may matter
<alexvf>
i will report the bug in github and let the maintainers decide if it is worth or not
<pcduino>
A20 lvds not working in mainline
<alexvf>
pcduino: ok, thanks
<pcduino>
I have been trying to configure the device tree but no sucess yet
The_Loko has joined #linux-sunxi
lkcl has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 268 seconds]
Nacho_ has joined #linux-sunxi
IgorPec has joined #linux-sunxi
lkcl has quit [Ping timeout: 256 seconds]
KotCzarny has joined #linux-sunxi
<KotCzarny>
meh.
<rellla>
plaes: tomorrow i can tell, if sunxi-cedrus works for A20, too...
<plaes>
:)
<KotCzarny>
oh, wow, power surge fixed stuck onboard wifi
<KotCzarny>
(even power cycles werent enough earlier)
<KotCzarny>
this whole electronics thing is pure magic (and static electricity)
<pcduino>
haha
<pcduino>
my board failed to boot like 6 times so I tested another board and all worked
<pcduino>
went back to the first one and it worked
<KotCzarny>
yup. this kind if thing
<pcduino>
I have had these problems before when using 1A psu but not with a 2A one
<KotCzarny>
i wonder what they mean by 'poe power supply option'
<KotCzarny>
did they wire network jack to the board power pins?
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<pcduino>
cheap
eduardas_m has quit [Ping timeout: 260 seconds]
gianMOD has joined #linux-sunxi
<pcduino>
how do they make it so cheap :/
<KotCzarny>
location, location, location
<KotCzarny>
and probably one man job
<KotCzarny>
or some serious allwinner discount
<pcduino>
slave labour
Amit_T has quit [Ping timeout: 245 seconds]
<pcduino>
they will be the new free gift with a magazine
<KotCzarny>
what magazine?
<pcduino>
ah I mean that is what could happen next
<KotCzarny>
:)
<KotCzarny>
nah, shipping is still half of the price
eduardas_m has joined #linux-sunxi
<willmore>
Plus, the memory amount is unclear. 512 has a lot more useability than 256.
<pcduino>
the orange pi one has 2 x 256
<pcduino>
still only $9.99
<pcduino>
could spend more the on the microsd card :)
<KotCzarny>
it's really about the size and poe capability (whatever it is)
Putti has joined #linux-sunxi
tkaiser has joined #linux-sunxi
Amit_T has joined #linux-sunxi
lkcl has joined #linux-sunxi
<tkaiser>
KotCzarny: On OPi Zero Ethernet pins 4/5 (DC+) and 7/8 (DC-) are routed to 4 solder pads. So maybe the 'PoE option' is soldering 2 resistors. Just look at the picture of the lower PCB side on Aliexpress
<KotCzarny>
might be that
<KotCzarny>
because it would be insane to let them be routed by default (for unexpecting users)
perr has quit [Ping timeout: 250 seconds]
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
<buZz>
tkaiser: sounds like fake-poe
<buZz>
great way to kill some switches
station has quit [Quit: Leaving]
<tkaiser>
buZz: I would call it 'passive PoE' -- we use this quite a lot. The most challenging part was finding cheap PoE injectors with more than a few ports
<pcduino>
a decent poe switch should be protected
DullTube has quit [Quit: Leaving]
<buZz>
yeah, decent ones should be
<buZz>
but using 'fake poe' means you cant afford decent ones
Leepty has quit [Remote host closed the connection]
gaby has quit [Quit: leaving]
gaby has joined #linux-sunxi
<tkaiser>
buZz: Do a web search for POE-PAN8 or POE-PAN16 to get the idea. And sure, people will buy an SBC for $7 and then add a 802.3af/at compliant pile of hardware for 3 times more money ;)
<pcduino>
is the H3 SOC anywhere close to stable on mainline? I see most of the mainlining effort is WIP
<KotCzarny>
pcduino, nope, even for 4.10 its nope
<buZz>
tkaiser: i have even seen arduino shield with proper PoE
Leepty has joined #linux-sunxi
<KotCzarny>
pieces and patches are floating around, but getting there is still a long way
<buZz>
so i'm not suprised quickly anymore
<pcduino>
tempted to buy one anyway
<tkaiser>
buZz: What was the price tag of this PoE shield?
<buZz>
>50
<KotCzarny>
:)
ganbold has quit [Ping timeout: 265 seconds]
<willmore>
pcduino, agreed. Some people like the smaller size and the built in wireless.
foxx_ has quit [Ping timeout: 260 seconds]
<wens>
KotCzarny: bcm53125 is programmed via mdio, so it is not dumb
<KotCzarny>
wens, dumb in the sense in default state there is no wan/lan split
<wens>
KotCzarny: just that the reset defaults are to act as a dumb switch
<wens>
right
<wens>
well you need some software to configure it, which i haven't figured out yet
<KotCzarny>
not anymore
ganbold has joined #linux-sunxi
<KotCzarny>
dsa introduced in 4.8 removed that possibility
<wens>
KotCzarny: i figured i let some other people figure out the userspace stuff while i keep porting other drivers :)
<KotCzarny>
and migrated b53 onto it
<KotCzarny>
so in theory you just use iputils2 to setup the thing
<wens>
pcduino: what do you need for h3?
<KotCzarny>
but in practice something eats packets originating from it
<wens>
KotCzarny: wonder if openwrt would be ported onto it?
<KotCzarny>
might be that cpu port doesnt get all vlans?
<KotCzarny>
if openwrt uses mainline, they will have no choice
<wens>
maybe?
<KotCzarny>
well, the choice would be disabling mainline drivers and patching the old ones back in
<wens>
or maybe the cpu port gets vlan tagged packets?
<KotCzarny>
they show up on eth0, but not on lan bridge
<KotCzarny>
which means they dont go onto specified ports
<KotCzarny>
that's why i asked if dts is correct
<wens>
KotCzarny: well i wasn't the one that added the bcm53125 :|
<wens>
but iirc the description matches the dts matches the schematic
<KotCzarny>
for now it's either bug in b53 driver or my inability to set things correctly
<KotCzarny>
would it be possible to have cpu port visible separately from eth0? would that even make sense?
<tkaiser>
pcduino: We used megi's branches before (also containing ths/dvfs/cpufreq support) but that seems to be broken currently (just look through the history of sun8i.conf above)
nashpa has joined #linux-sunxi
perr has quit [Remote host closed the connection]
<beeble>
KotCzarny: do you need the lan separation oder would be a dumb switch good enough?
<beeble>
aeh
<beeble>
or
<KotCzarny>
i need one port to be isolated and 4 ports joined
<KotCzarny>
ie. wan + 4lan (+1cpu)
<beeble>
ok, so classic wan/lan configuration
<KotCzarny>
ie. wan, 4lan (+1cpu)
<beeble>
anyways maybe you could try it anyway. there seems to be a eeprom on the board. that eeprom would hold the switch configuration
<KotCzarny>
try what?
<beeble>
so maybe some setting is breaking the mainline driver
<pcduino>
tkaiser: thanks will buy one and try it out
<beeble>
so if you would short something like the dataline then it wouldn't be able to load the config and have only default reset values
<KotCzarny>
you mean something in the line of init=/bin/bash ?
<beeble>
no electrical
<beeble>
U20
<KotCzarny>
thing is, switch resets with every boot (dont even need to be power cycled)
<beeble>
yes
<beeble>
but it will load the values from the eeprom, so we want to block that
<KotCzarny>
and by default it should forward all packets, on mainline, dsa sets it to separated ports though
<tkaiser>
beeble: Does this mean by writing to the eeprom the switch could be brought up in a state where not all 7 ports are interconnected at layer 2?
lkcl has quit [Ping timeout: 245 seconds]
<beeble>
tkaiser: yes
Ultrasauce has quit [Remote host closed the connection]
<beeble>
and you wouldn't populate the eeprom if you don't need to set any registers. so they probably do something
<nove>
beeble: hi, you are in some way related to those theobroma A64 module? i see you earlier talking about "after we shipped 3.10 to customers who need the 3d acceleration"
lkcl has joined #linux-sunxi
<beeble>
so shorting pin 1 and 2 on u20 should block any communication. maybe this helps. maybe it does nothing :)
Ultrasauce has joined #linux-sunxi
<beeble>
nove: yes i am
<nove>
beeble: ok, that is nice.
<KotCzarny>
eheh, shorting would be doable if it wasnt a bga package
<nove>
beeble: boot0 has no issues (to my aware), but is not need to use has there is already (almost) uboot spl support
gianMOD has joined #linux-sunxi
premoboss has quit [Ping timeout: 256 seconds]
<beeble>
nove: no i'm not aware of that. but graphics stuff is done by a colleague. have to check with him.
<nove>
beeble: there is also the fact that the userspace mali libraries (the ones that pine64 got from allwinner) have not a clear EULA that allows redistribution
pekka10 has joined #linux-sunxi
<nove>
this is something that was and is frequent discussed here
foxx_ has joined #linux-sunxi
<oliv3r>
ssvb: but 452 on my 'bad' board (that crashest the most easiest, does indeed crash after an hour or so
<beeble>
will tell him that too. I'm a hardware guy, so most of the time i'm only working a little bit on the bootloader
<ssvb>
oliv3r: do you mean that you can crash your 'worst' board with a high ambient temperature at 456 dram clock, but not at lower temperatures?
<beeble>
nove: also i'm not as an official representative here. i can't speak for the company. just as a disclaimer :)
<wens>
beeble: being here even if in an unofficial capacity is nice enough :)
<ssvb>
beeble: btw, a very nice job on the a80 spl and dram support! I particularly like the fact that you actually checked the existing documentation for similar dram controllers
<ssvb>
beeble: jemk was doing some experiments with a80 spl & dram too, but if I remember correctly, he could reproduce some sort of reliability problems
<oliv3r>
ssvb: one board was very suspecious, board 6, which was crashing very quickly at 480 already, so i lowered the clock to 456, which was stable at room temperature. putting it in a heated chamber with an ambient temperature of 55-60 degree's made it crash within an hour or so
<oliv3r>
ssvb: i lwered the freq. of board 6 to 432, and raised the ambient temperature, well i'm trying to raise it to 65 degree's; not sure if i can reach 70
<oliv3r>
allwinner states in their datasheet an operating temperature of 70C
<KotCzarny>
60C is quite high
<oliv3r>
of course this neglects humidity
<oliv3r>
which is rather low due to natural causes, i don't have a proper heated climate control chamber
<KotCzarny>
at which temp plastics begin to melt?
<oliv3r>
just an ultimaker 2 with a heated bed, all wrapped up in cartboard and my vest :p
<oliv3r>
PLA becomes soft at 68, but regular plastics get way warmer
<KotCzarny>
put a plant inside for humidity? ;)
<oliv3r>
ABS i thin gets soft at 90 or 110
<oliv3r>
KotCzarny: lol
<oliv3r>
i may have to reflash the software to allow higher bed temperatures
<alexvf>
ssvb: yes, i know you guys are prioritizing mainline. I just wanted to know if my report was accurate since i think you are familiar with that code.
<alexvf>
ssvb: I think it is just an errata and it should read pre_node instead of node in the aforementioned line but i'm not sure since i don't fully understand all the code
<beeble>
the package must sustain ambient temps of over 200 degrees due the reflow capability. (even if specified for only short duration)
<alexvf>
ssvb: i am testing and it fixes my usecase but i am afraid of breaking anything else
<beeble>
so the silicon will die before the package
IgorPec has quit [Ping timeout: 265 seconds]
<ssvb>
oliv3r: did you notice any changes in the a10-meminfo report between the low and high ambient temperatures on this problematic board?
<ssvb>
oliv3r: the calibrated dram_zq value is particularly interesting
<KotCzarny>
oliv3r, another test would be checking if putting problematic boards outside (~10C) would affect stability in any way
<willmore>
oliv3r, what is the max bed temp?
<ssvb>
oliv3r: I think that 70 is the specified ambient temperature limit, while something like 125 is the temperature limit for the SoC
<ssvb>
oliv3r: still please get these a10-meminfo reports, because there may be one more test to do
<alexvf>
ssvb: actually, i just realized i put the wrong line in the github issue, it is 649 :(, sorry about that
<ssvb>
oliv3r: I mean, you can bypass the zq calibration step and program zq directly, by using 'good' settings from the low ambient temperature setup
<ssvb>
alexvf: it was a very long time ago and I don't remember the exact details, also I have no time to spend on 3.4 kernel at the moment, sorry
<alexvf>
ssvb: no problem man, thank you anyway
<alexvf>
i will probably issue a pull request soon
<alexvf>
although maybe noone will care ;)
<oliv3r>
ssvb: i haven't seen any difference on any board, yet
<oliv3r>
i'll do some extra runs, where ambient and board are hot, various bootloader freqs. and a10-meminfo parameters
<oliv3r>
and then repeat it, for the same board, when it is completly cold
<ssvb>
oliv3r: do you have the logs somewhere?
<oliv3r>
willmore: i modified my firmware to get upto 135C :)
<oliv3r>
ssvb: boot logs or a10-meminfo logs?
<oliv3r>
ssvb: yeah i've put them in my spreadsheet, i'll upload it again with the latest data
<oliv3r>
and when i'm doing the dram_zq tests, i'll log those as well
<ssvb>
alexvf: you can try to contact armbian people, maybe they could be interested in your fix
<alexvf>
ok
<oliv3r>
ssvb: the 125C limit is the ambient storage limit
<oliv3r>
ssvb: ok we'll talk more when i get that far
<oliv3r>
gonna leave this board overnight now
<oliv3r>
432 MHz seems very stable so far
<oliv3r>
but
codekipper has quit [Quit: Page closed]
<oliv3r>
i haven't checked hdmi output yet
<oliv3r>
only have serial console in this setup
<ssvb>
oliv3r: 125 is also a typical junction temperature limit, as mentioned by the datasheets of newer Allwinner SoCs and other devices
<oliv3r>
but the memtester output it still all ok
<oliv3r>
ssvb: yeah 125 is quite standard
lkcl has quit [Ping timeout: 250 seconds]
<oliv3r>
i am monitoring and logging sunxi_tp_temp
<oliv3r>
73.5 C right now
<ssvb>
the temperature sensor is considered to be unreliable on a20
<KotCzarny>
as long its not under ambient temp.. it's working.. somehow ;)
<oliv3r>
ssvb: i know, but it is a reasonable reference
<KotCzarny>
hm, funny, if i set ip to the eth0, but leave lan1 down, i can communicate with lamobo. why the heck it passes packets on the DOWNed interface.. o.o
Gerwin_J has joined #linux-sunxi
orly_owl has quit [Ping timeout: 260 seconds]
orly_owl_ is now known as orly_owl
orly_owl has quit [Changing host]
orly_owl has joined #linux-sunxi
premoboss has joined #linux-sunxi
<rellla>
oliv3r: _k_ondome :p
<KotCzarny>
oh, more barfs. without switch configuration, with upped and configured eth0, and downed lanX ports devices can communicate with themselves o.O
<KotCzarny>
while this could be nice when one wants to use this dumb switch in lan only mode and with mainline
<KotCzarny>
it really is dumb
orly_owl has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
<oliv3r>
rellla: but i'm sure you remember the commercial!
<oliv3r>
so whenever i see or hear the name tina, that's what comes up
<rellla>
omg
<KotCzarny>
one could make it into android loading screen ;)
<KotCzarny>
s/android/tina/
lkcl has joined #linux-sunxi
<oliv3r>
Tina, was kosten die kondome! 4.4
<plaes>
4.99
<plaes>
err.. 3.99
<TheLinuxBug>
LOL
<KotCzarny>
no, only 3.10!
<KotCzarny>
it's on the promotion
popolon has joined #linux-sunxi
<oliv3r>
nein, 2.99, sie sind im sonderangebot!
Nuck-TH has joined #linux-sunxi
<nove>
the 0.11 extra is the tax for the "license issues" privilege
<KotCzarny>
and shipping&handling
<oliv3r>
are we having anything sunxi done at fosdem this year?
<oliv3r>
i'm likley going to be there at the ultimaker booth
<Nuck-TH>
yesterday i suspected, that cubietruck can boot mainline from microSD with SD adapter because of it's low class(4)
<Nuck-TH>
but now i tested adapter with microSD class 10 - it boots without errors. seems like problems of particular cards.
<Nuck-TH>
funny that both "good" and "bad" card are Transcend :)
IgorPec has joined #linux-sunxi
<Nuck-TH>
but once again, strange that 3.4.x can boot fine from "bad" cards
<ssvb>
Nuck-TH: at which stage does it fail?
jernej has joined #linux-sunxi
<Nuck-TH>
ssvb: i do not exactly know(not kernel developer), but seems like card init by kernel, since it mounts rootfs shortly afterwards(on boot with "good" card)
<tkaiser>
apritzel: For 'some hundred MBs' it might be worth checking to load also kernel+initrd through FEL and then use kernel's USB mass storage gadget mode. With H3 it's then around 20 MB/s.
<apritzel>
ssvb: thanks!
<apritzel>
tkaiser: yeah, was thinking about that as well
gianMOD has quit [Remote host closed the connection]
<Nuck-TH>
huh, from 3.16 to 4.7... that will be a long story :(
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<apritzel>
Nuck-TH: in that case I'd bisect over the kernel releases first
vagrantc has joined #linux-sunxi
<ssvb>
tkaiser: the DFU support in U-Boot makes the kernel part unnecessary, and less moving parts means better reliability
<ssvb>
tkaiser: 20 MB/s sounds nice though, we should check it again and maybe fix the U-Boot implementation
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
<ssvb>
well, the point is that if the kernel is much faster, then there is a performance bug in U-Boot :-)
<tkaiser>
ssvb: But it would be great if this sort of stuff would fit into SPI flash, such a payload (providing eMMC as mass storage device) would be great also.
<tkaiser>
ssvb: But IIRC you said that special eMMC boot partitions could also be used for such a 'basic firmware'?
<ssvb>
yes, assuming that the BROM can boot from it
<KotCzarny>
tkaiser, got any cheat sheet for iperf3 ?
<ssvb>
I might have missed something really trivial, but I did not succeed doing this when I tried some quick tests some time ago
<ssvb>
but yes, eventually we can have a much better eMMC support
<tkaiser>
KotCzarny: 'iperf3 -s' vs. 'iperf3 -c x.x.x.x' on the other host?
<beeble>
brom does something with mmc boot partition. but not the stuff i would expect
<beeble>
but to analyze that i would have to sniff the communication and i was not looking forward to do that soon
<apritzel>
beeble: did you look into the disassembly already?
<ssvb>
or inspect the BROM code, which I also partially did
paulk-collins has joined #linux-sunxi
<beeble>
apritzel: only for verifiying the bootflow
<ssvb>
but I haven't spent much time on the eMMC boot problem yet
<ssvb>
beeble: if you find some clues about booting from the eMMC boot partition, please be sure to share this information
<Nuck-TH>
isn't emmc works like sd cards?
<beeble>
didn't spent to much time on it during low priority. would definitly be a nice to have, but for now users just have to not delete the entire emmc if they want to have a booting system :)
<beeble>
(without sd or fel fallback)
<beeble>
Nuck-TH: similar
<beeble>
Nuck-TH: so you have more features in a standardized way that are missing from sd card. like boot partitions, trim operations, device health and so on
<beeble>
depending on the version
<ssvb>
we may also try to dump the BROM and run it under QEMU or some other emulator, while tracing all the accesses to the hardware registers
<ssvb>
that's going to be fun, but may need a bit more time
<beeble>
not sure if this would be faster then reading the assembly :)
<ssvb>
exactly
<ssvb>
in the short term, just reading assembly needs less time
<ssvb>
but in the long term, a tracing emulator may prove to be useful when dealing with different SoC families and also libdram blobs
<beeble>
but without having line captures it only helps so much if you don't have a full ip core documentation and do no which flags it have activated
<beeble>
would still involve some trial and error
<apritzel>
ssvb: the problem with the emulation would be that for useful results you would also need to emulate the hardware behaviour, because the code depends on that
<ssvb>
apritzel: exactly
<apritzel>
ssvb: writing a DRAM controller emulation is nasty enough, but gets really interesting when you don't have documentation ;-)
<ssvb>
and it's not the problem, but just one of the things to implement
<ssvb>
apritzel: we do have some sort of documentation
<jemk>
nove started some qemu based tracer, but i don't know whats the current state
premoboss has quit [Quit: Sto andando via]
<beeble>
the pine guys could have spent the extra few cents for a reset button
<KotCzarny>
haven't seen reset button on any board
<beeble>
with the money they got from not sending my two ordered they could have bought a few hundreds
foxx_ has joined #linux-sunxi
EduRenesto has joined #linux-sunxi
<vagrantc>
they shipped reset buttons with mine ... just takes a bit of soldering ... :|
apritzel has quit [Read error: Connection reset by peer]
<vagrantc>
or were those power buttons?
apritzel has joined #linux-sunxi
<apritzel>
they were nasty to solder for me, though, since the ground plane sucked all the heat
<tkaiser>
vagrantc: You could use the button for either or. But nothing already soldered on the board (same with custom led that could've saved countless Pain64 users)
<tkaiser>
apritzel: Do you think about flashing to BPi M64's eMMC?
<apritzel>
(because they don't use soldering pads with thermal relief)
<apritzel>
tkaiser: yes
<apritzel>
but also more in general
Amit_T has quit [Ping timeout: 260 seconds]
<beeble>
apritzel: don't forget to enable mmc commands or have an FEL uboot ready. :)
<apritzel>
beeble: that works fine for me, in fact I can easily FEL boot and then flash via Ethernet in U-Boot
<apritzel>
"enable mmc commands" sounds like a BSP U-Boot issue, don't even know how to _disable_ them in upstream U-Boot ;-)
tkaiser has quit [Ping timeout: 260 seconds]
enrico__ has quit [Quit: Bye]
Nuck-TH has quit []
Amit_T has joined #linux-sunxi
foxx_ has quit [Ping timeout: 256 seconds]
apritzel has quit [Ping timeout: 256 seconds]
Amit_T has quit [Client Quit]
<KotCzarny>
oh, wow, i've managed to hang the board just by using make menuconfig :>
<KotCzarny>
might be some oom situation ;)
<mdsrv>
dont say
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
FergusL has joined #linux-sunxi
foxx_ has joined #linux-sunxi
Xal1u5 has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
tsuggs has joined #linux-sunxi
<beeble>
apropos oom, agraf what are you using as compile server hardware nowadays? (if you can share that information)
<montjoie>
beeble: related info, see willy tarreau slides from kernel recipes on compilation cluster (it speak about allwinner also)
IgorPec has quit [Ping timeout: 268 seconds]
<KotCzarny>
ok, what to do after patching the kernel and menuconfig doesnt show particular new option?
<KotCzarny>
(if anything beside clean/distclean)
<jelle>
oh ELCE videos are onliine
Gerwin_J has quit [Quit: Gerwin_J]
<beeble>
hehe, have to reduce the font size to see all talks in the menu on the kernel-recipes site
<beeble>
should upgrade my screen resolution
<KotCzarny>
or stack monitors vertically?
<jelle>
=)
leviathanch has quit [Remote host closed the connection]
mzki has quit [Ping timeout: 260 seconds]
netlynx has quit [Quit: Ex-Chat]
mzki has joined #linux-sunxi
Axl_ has quit []
<beeble>
montjoie: interessting read. and very usable for kernel builds. but if you go into distro packages i would think that IO would be the bottleneck in such a setup. the emmc is to space constraint and if you use nfs then io speed will killing you
<beeble>
s/killing/kill
tkaiser has joined #linux-sunxi
jstein has quit [Read error: Connection reset by peer]
The_Loko has quit [Quit: Leaving]
<EduRenesto>
people
<KotCzarny>
and bots
<EduRenesto>
pfc
<EduRenesto>
s/pfc/ofc
<EduRenesto>
i've compiled uboot and the kernel for my random device
<EduRenesto>
that brazilian a10 tablet
<EduRenesto>
made the sdcard and stuff
<EduRenesto>
but the display doesnt turn on
<EduRenesto>
the soc gets hot, that means something is running
<EduRenesto>
i'm using the display section from the script.bin i pulled from the stock android
<EduRenesto>
what could it be?
tkaiser has quit [Ping timeout: 260 seconds]
<KotCzarny>
anything from failed boot to incompatible driver/options
<KotCzarny>
uart would greatly help
<EduRenesto>
i know
<EduRenesto>
but i cant find any pads on the board
<KotCzarny>
it might be hidden as a test points
<EduRenesto>
there are a lot of small dots on the board
<agraf>
beeble: uh, not sure i understand the question
<agraf>
beeble: ah, i read it again, i think now i do :)
<agraf>
beeble: we have 2 different build farms - one for internal code (IBS), one for external code (OBS)
<agraf>
beeble: I'm not sure how much I can disclose about IBS, but we basically build on everything we have available there - build jobs manage to trigger bugs quite nicely
<agraf>
beeble: OBS runs on Arndale, X-Gene 1 and Seattle hardware today
<agraf>
beeble: and we just got 3 new ThunderX systems this week that are getting put into racks to extend OBS :)
<agraf>
beeble: 3x ThunderX with 800GB NVMe disks each to get rid of our I/O bottlenecks :)
<agraf>
beeble: I'm certainly anxious to see how they're going to perform
<beeble>
agraf: thanks. that sounds nice.
<beeble>
i wanted to start a build right bevor leaving to benchmark kernelbuildtime on a apm merlin with a standard ssd. but it was already occupied, so have to delay this to tomorrow
<beeble>
agraf: would be interessting to hear how the thunderx performes. hope that ddr will not be a bottleneck there
<agraf>
beeble: yeah, for kernels and u-boot I finally made the switch to cross compilation
<agraf>
beeble: all those x86 systems are just so much faster than any arm system you can buy :)
<beeble>
for kernels i will stick to x86 too. the benchmark was just to have something to compare and kernel is quiet easy
<beeble>
but doing stuff like qt is native a lot less pain
<beeble>
don't even want to find out how to crosscomple with qtmake
<agraf>
heh :) yes
<agraf>
I come from the other direction
<agraf>
to me cross compilation was always completely alien
<agraf>
I wouldn't even start to think of compiling qt with a cross compiler
<KotCzarny>
:>
<KotCzarny>
there are people compiling whole distros
<mripard>
beeble: agraf: isn't what buildsystems are used for?
<agraf>
beeble: as an example, if you're interested in build time comparisons
<agraf>
beeble: bear in mind that all build hardware is heavily overcommitted though - IIRC we're running 3 build jobs in parallel on each X-Gene1 system for example
<agraf>
mripard: sure you can, I just don't want to go through the pain of maintaining it :)
<agraf>
mripard: we already had enough trouble getting a rpi armv6 distribution to build *correctly*
<beeble>
mripard: a lot of distributions do not support nativ crosscompile. so you have to do the legwork of patching to work with crosscompile yourself
<agraf>
mripard: because a good chunk of packages was enabling code optimization depending on the build host, so running builds on armv7 hardware enabled neon
<agraf>
mripard: so we're actually building all of the armv6 distro using qemu user emulation on x86 today
<beeble>
buildroot and openwrt are good examples where the community does a lot of work to get it working
apritzel has joined #linux-sunxi
<mripard>
beeble: which is kind of my point, if the community does all the work already, just use it, someone already went through the trouble of making it work
<mripard>
but it's different if your work is to build a distro I guess :)
<agraf>
yes, also a "general purpose distro" has a much wider range of packages than openwrt for example
gianMOD has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 260 seconds]
<beeble>
mripard: if i build a dedicated device i'm using buildroot or openwrt. but there are some packages we have to provide as rpm or debs and sometimes even partial distrorebuilds with other toolchains
<beeble>
so there you a stuck to their buildystem if you don't want to reinvent the wheel
<agraf>
beeble: yup, in your case, just use obs :)
<agraf>
beeble: I've even heard of people who rebuilt CentOS with it! ;)
paulk-collins has joined #linux-sunxi
<rah>
[ 0.082601] SMP: Total of 4 processors activated (192.00 BogoMIPS).
<agraf>
beeble: search for "armv8.2" in that text ;)
yann-kaelig has quit [Quit: Leaving]
<apritzel>
beeble: but I agree: you can do much better with taking a stock core and throw bad-ass peripherals to it
<agraf>
apritzel: in build results, but yes, depends on what you do :)
<beeble>
apritzel: or you wanted to be the first aarch64 silicon and now have to live with you k6 core :)
<apritzel>
agraf: of course depends on the rest of the system, if you starve for memory or I/O an fancy core doesn't help
<agraf>
apritzel: sure, but keep in mind where they're coming from
<agraf>
apritzel: if you used to build network chips that were able to fit most of their working set in L1, you obviously have issues when you're compared to a Xeon ;)
<agraf>
apritzel: but that's the same with all of the 1st gen aarch64 chips out there
<apritzel>
agraf: sure, I just wanted to relax your expectation
<agraf>
apritzel: they're all horrible
tkaiser has joined #linux-sunxi
<agraf>
apritzel: from everything servery you can buy today, the 2014 x-gene 1 is still the fastest
<agraf>
apritzel: that's just plain embarrasing
<apritzel>
the make -j50 result on that first Thunder was quite good - for an ARM box ;-)
<agraf>
apritzel: by-core comparison :)
<beeble>
and that one cant't compete with an 2012 e3 in most cases
<apritzel>
until I compared this to the result on my bog standard core I7 :-(
<agraf>
yup
<apritzel>
but as you pointed out with you ThunderX2 link: there is almost the next box around the corner
<agraf>
not quite, but yes :)
<apritzel>
this will run circles around what's there today
<apritzel>
sounds familiar from my years at AMD ;-)
<apritzel>
hope dies last
<beeble>
i'm still not sure if this "moar cores" strategy will help
<apritzel>
beeble: no, but it's easy to build
<apritzel>
and easy to sell
<beeble>
now you can wait after cache miss on even more cores for a long time :)
<apritzel>
beeble: but for that you add threads!
<apritzel>
;-)
<beeble>
i'm curious to see how the marvell parts will perform as a network soc
EduRenesto has quit [Quit: Page closed]
<beeble>
due the more flexibel serdes mux they could be quite nice general purpose chips
<apritzel>
beeble: given that Marvell seems to know how to integrate capable I/O, that sounds indeed promising
<apritzel>
they seem to rule a good part of the NAS market with really old cores
<beeble>
their ethernet and sata ip works very well and the cpu teams know how to integrate it. also it looks more streamlined now, maybe the different business units stopped competing internally and start talking :)
<apritzel>
beeble: so the exact opposite of Allwinner? ;-)
<beeble>
hehe
<beeble>
i think allwinner is still trying to figure out what they should do after the tablet market is saturated. so now the just try the buckshot approach
vagrantc has quit [Quit: leaving]
<apritzel>
they try to sell their chips to Austrian companies ...
<beeble>
that sounds desperate :)
<apritzel>
;-)
<beeble>
and it would be nice if they would try that
<beeble>
maybe china can annex autria. they rebuild our cities anyhow, so they could save some time
<beeble>
btw apritzel, philipp may sent you a patch request this week. i had a build today and it seems to work stable. but haven't tested it a lot yet but tried to boot it on pine64 and it worked
<beeble>
s/patch/pull
<apritzel>
beeble: cheers, looking forward to it!
KotCzarny has quit [Ping timeout: 268 seconds]
dr1337 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gianMOD has quit [Remote host closed the connection]
Da_Coynul has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Da_Coynul has joined #linux-sunxi
<ssvb>
agraf: regarding "running builds on armv7 hardware enabled neon" - there is nothing wrong with this, as long as neon support gets detected at runtime
<agraf>
ssvb: yeah, it didn't for something iirc
<ssvb>
I just remember that the raspberry pi people had explicitly disabled neon support in pixman for their raspbian distro, just because they were afraid of it
<ssvb>
and naturally, their very first raspbian builds for the raspberry pi2 had it disabled too :-)
<ssvb>
they had to be explicitly notified that this code works on both armv6 and armv7 by default out of the box
Xal1u5 has quit [Ping timeout: 260 seconds]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<ssvb>
so whenever I see some distro person complaining about having to disable neon in something, I just wonder if there actually was any real problem in the first place
p_rossak has quit [Ping timeout: 260 seconds]
p_rossak has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Ping timeout: 268 seconds]
<agraf>
ssvb: yes, the first distro we built definitely didn't run :)
<ssvb>
agraf: was this reported upstream and eventually fixed?
<agraf>
ssvb: it's a few years ago and I don't even remember the package we had problems with
<agraf>
ssvb: and tbh I don't care much about the armv6 target these days anymore :)