pulser has quit [Remote host closed the connection]
pulser has joined #linux-sunxi
mripard has quit [Ping timeout: 244 seconds]
mripard has joined #linux-sunxi
gzamboni has quit [Ping timeout: 246 seconds]
gzamboni has joined #linux-sunxi
[Awaxx] has quit [Ping timeout: 244 seconds]
zumbi has quit [Ping timeout: 244 seconds]
zumbi has joined #linux-sunxi
Err has quit [Ping timeout: 256 seconds]
[Awaxx] has joined #linux-sunxi
Err has joined #linux-sunxi
valkyr1e has quit [Ping timeout: 256 seconds]
valkyr1e has joined #linux-sunxi
terra854 has joined #linux-sunxi
gzamboni has quit [Ping timeout: 248 seconds]
gzamboni has joined #linux-sunxi
FergusL has quit [Ping timeout: 260 seconds]
montjoie has quit [Ping timeout: 260 seconds]
montjoie has joined #linux-sunxi
<miasma>
so is it ok to run the kernel for h3 devices with thumb instructions? trying to figure out why i started getting these kernel fails (line 312) http://pastebin.ca/3740739
BuddyZhang1 has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 246 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
<dgp_>
miasma: I have a thumb2 kernel at it seems to work fine
dlan has joined #linux-sunxi
<willmore>
miasma, that says it's in THUMB mode when it dies, not THUMB2 which is what armv7 should support, no? I could be confused and it might not be saying precisely the right thing.
<dgp_>
thumb and thumb2 aren't different execution states are they?
<[7]>
they aren't, indeed
<[7]>
just different feature sets of the thumb instruction set, which one you have depends on the CPU type
* willmore
makes note
ninolein_ has quit [Ping timeout: 258 seconds]
ninolein has joined #linux-sunxi
LargePrime has quit [Ping timeout: 250 seconds]
LargePrime has joined #linux-sunxi
cosm has quit [Remote host closed the connection]
cosm has joined #linux-sunxi
techn has quit [Ping timeout: 244 seconds]
techn has joined #linux-sunxi
deskwizard has joined #linux-sunxi
VargaD has quit [Ping timeout: 252 seconds]
MoeIcenowy has quit [Ping timeout: 250 seconds]
VargaD has joined #linux-sunxi
pg12 has quit [Ping timeout: 246 seconds]
pg12 has joined #linux-sunxi
BuddyZhang1 has quit [Ping timeout: 260 seconds]
terra854 has quit [Quit: Connection closed for inactivity]
dgp_ has quit [Remote host closed the connection]
lkcl has quit [Ping timeout: 256 seconds]
perr has joined #linux-sunxi
CuteIcenowy has joined #linux-sunxi
<CuteIcenowy>
jernej: how much progress have you made to mainline H3 U-Boot HDMI?
jernej has quit [Ping timeout: 244 seconds]
<CuteIcenowy>
ah-oh
<KotCzarny>
your nickname got changed
<CuteIcenowy>
you will find the IP also changed
<CuteIcenowy>
as MoeIcenowy is on my ZNC
<CuteIcenowy>
and my VPS seems to met some problem
<KotCzarny>
ahm, must be something in the air
<miasma>
willmore: there are at least three kernel options I was suspecting for the problems (thumbee, thumb-2 and neon in kernel mode), but they all seem to work on another board. i guess my old opi pc board is just dead
<KotCzarny>
miasma: try lowering dram and changing power source?
<miasma>
KotCzarny: so is the dram freq setting in the u-boot-sunxi-with-spl.bin file? how do i know what setting is loaded
<KotCzarny>
mainline or legacy?
<miasma>
mainline
<KotCzarny>
can you check if you have /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq ?
<miasma>
nope
dgp has joined #linux-sunxi
<miasma>
KotCzarny: there's some kernel config switch for that? i think i based my config on sunxi_defconfig, but i don't remember disabling anything memory related
<KotCzarny>
it might be still set by uboot. hmm.
<KotCzarny>
(but im trying to find how to change it in mainline kernel)
<miasma>
i don't exactly understand the process. u-boot generates a dtb file but it won't ever boot. i always need to use the one that comes with the kernel
<miasma>
i got the impression earlier that u-boot sets that and the kernel won't touch it
<KotCzarny>
it shouldnt, but in legacy apparently there was a module for checking/changing dram speed
<miasma>
i tried setting it to 528 MHz but it didn't have any effect
<miasma>
after rebooting the board few times, it didn't work at all anymore. it hanged while displaying the u-boot status texts, like the line with dram: (without displaying the amount)
<KotCzarny>
well, if you have spare sd card you can always try armbian image for your board
montjoie has quit [Quit: Lost terminal]
<miasma>
unfortunately this board has a broken sd card slot :S i still haven't sorted it out. gotta see if xunlong will do something about it http://pastebin.ca/3740781
<miasma>
luckily I can boot via fel :P
* dgp
has wifi working on the orange pi zero with mainline kernel :D
<CuteIcenowy>
dgp: how did you do it?!
<KotCzarny>
miasma: there is a possibility the board is faulty in more than one are then
<dgp>
I left you a message on the issue I opened on github
<CuteIcenowy>
dgp: I tried this... but failed
<miasma>
KotCzarny: yea, i think the old v1.2 board is quite dead. the new one just has a broken sd slot. otherwise it works
montjoie has joined #linux-sunxi
<dgp>
CuteIcenowy: you can try my rough fork if you want.. I might have fixed something else by mistake ;)
<ssvb>
miasma: but you can use a devmem2 tool even now to read the relevant hardware registers and figure out the current DRAM clock speed on a running system
<KotCzarny>
a64, h5, h2+, a83t
<ssvb>
miasma just has opi pc
<ssvb>
KotCzarny: sure! but we need to add one SoC at a time to make any progress with it
<KotCzarny>
uhum
iamfrankenstein1 has quit [Read error: Connection reset by peer]
<miasma>
ssvb: ok thanks, i'll look at it
deskwizard has quit [Ping timeout: 256 seconds]
chomwitt has quit [Ping timeout: 258 seconds]
willmore has quit [Ping timeout: 245 seconds]
f0xx has joined #linux-sunxi
willmore has joined #linux-sunxi
dr1337 has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
dr1337 has quit [Ping timeout: 260 seconds]
Amit_T has joined #linux-sunxi
putti_ has quit [Ping timeout: 245 seconds]
diego_r has joined #linux-sunxi
diego_r has quit [Client Quit]
diego_r has joined #linux-sunxi
<tuxillo>
hi
<mripard>
CuteIcenowy: I'm not sure I get what you were asking about the mali clocks
whaf has quit [Quit: Leaving.]
fkluknav has joined #linux-sunxi
whaf has joined #linux-sunxi
florianH has joined #linux-sunxi
paulk-minnie has joined #linux-sunxi
massi has joined #linux-sunxi
Leepty has joined #linux-sunxi
<CuteIcenowy>
freemangordon: I am an owner of two A33 tablets
putti_ has joined #linux-sunxi
MoeIcenowy has joined #linux-sunxi
CuteIcenowy has quit [Quit: Leaving.]
<MoeIcenowy>
mripard: I am asking that how is the clock frequency being set in your semi-mainline sunxi-mali driver
foxx_ has joined #linux-sunxi
f0xx has quit [Ping timeout: 258 seconds]
<MoeIcenowy>
dgp: you got the point
<MoeIcenowy>
it seems to be really the key
<scelestic>
should ths be working on megous' mainline kernel and an orange pi plus2 (h3)? I get this error while booting and cannot find any ths in /sys "thermal thermal_zone0: failed to read out thermal zone (-16)"
LargePrime has quit [Ping timeout: 245 seconds]
paulk-minnie has quit [Remote host closed the connection]
<dgp>
MoeIcenowy: do you have it working now? With your mac address change it's working really well for me
<MoeIcenowy>
I used it's mod param macaddr=
perr has joined #linux-sunxi
perr has joined #linux-sunxi
perr has quit [Changing host]
<dgp>
I didn't realise it had that.. I couldn't get dhcp to work, I pull your repo just in case and it magically started working :)
LargePrime has joined #linux-sunxi
scream has joined #linux-sunxi
petr has quit [Ping timeout: 256 seconds]
<montjoie>
A83T PRNG work
<montjoie>
now trying TRNG
Worf has joined #linux-sunxi
petr_ has joined #linux-sunxi
fkluknav has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
<tkaiser>
dgp: Some DHCP servers refuse to assign an address to purely random MAC addresses. So you might run into the same issue again ;)
<dgp>
tkaiser: I think it was because the mac address was the same as the wired ethernet. I manually gave it an ip address but it stopped working when I unplugged the cable so packets must have been going there
<MoeIcenowy>
dgp: humorous
<MoeIcenowy>
try macaddr= param
<MoeIcenowy>
I wrote "options xradio_wlan macaddr=xx" > /etc/modprobe.d/xradio.conf
<dgp>
I want to get SPI flash working too.. I'll probably put the mac address in there
mzki has joined #linux-sunxi
<tkaiser>
dgp: I would prefer MAC addressed based on SID on OPi Zero though
<dgp>
tkaiser: SID is an OTP id in the chip?
<MoeIcenowy>
Can U-Boot now generate two different MACs for two ethernet aliases in dt?
<MoeIcenowy>
dgp: yes
<dgp>
That's a good solution
<MoeIcenowy>
for mainline EMACs SID is used
<MoeIcenowy>
by letting U-Boot read SID, and write a MAC to device tree before booting
<mripard>
MoeIcenowy: ah, yes, sorry. Through the DT with assigned-rates
Ntemis has joined #linux-sunxi
<tkaiser>
MoeIcenowy: IIRC jernej used the same for RT8189FTV (and incremented by 1 to get a different MAC address for Ethernet and Wi-Fi)
<MoeIcenowy>
I think Hans de Goede may have did related work
<tkaiser>
Yes, maybe it was him instead.
<dgp>
I'll buy him a pi zero if he wants to clean up the wifi driver ;)
<KotCzarny>
he actually disowned sunxi-uboot maintainership due to lack of time
putti_ has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
opi zero is so cheap that I think in some area its price is cheaper than ship :-)
<dgp>
I bought 5 for that reason
<jelle>
but it's not avaliable :p
<scelestic>
lol
DullTube has joined #linux-sunxi
<MoeIcenowy>
even in China the ship fare is 1/6 of the board price
<dgp>
The pi zero is cheaper than the cortex m3 wifi module my company use in a product.. pretty insane
lkcl has joined #linux-sunxi
<tkaiser>
Some routers will refuse to give a DHCP lease when the MAC is locally administered
<MoeIcenowy>
how to judge whether a MAC is "locally administered" ?
<tkaiser>
MoeIcenowy: 'Universally administered and locally administered addresses are distinguished by setting the second-least-significant bit of the first octet of the address'
<MoeIcenowy>
will U-Boot generate a universally administered address?
<tkaiser>
MoeIcenowy: The first 3 octets have to be considered. We could use 'DC:44:6D' and combine it with 3 random bits. Or make the latter depend on SID.
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-sunxi
bugzc has quit [Ping timeout: 260 seconds]
<MoeIcenowy>
The MAC generation code of xradio_wlan have macaddr[0] &= 0xFC; ...
<tkaiser>
Hmm... IMO we should use Allwinner's prefix here, then get SID through u-boot and use Ethernet MAC address + 1 for Wi-Fi
<tkaiser>
Just to prevent the mess with Pine64 right now. Everyone thinks A64 Ethernet is broken when using more than one board since Pine Inc people provided OS images with MAC address defined in uEnv.txt (being the same on all installations then)
smashr_ has joined #linux-sunxi
<MoeIcenowy>
there's also a problem, the license of firmware
<smashr_>
I've just compiled armbian with a different kernel but the kernel is not packed into /boot :( do I need to make more adjustments thant change the kernel repo?
<tkaiser>
MoeIcenowy: Not redistributable?
<tkaiser>
smashr_: Check output/debs/ directory
<MoeIcenowy>
tkaiser: no clear license
<tkaiser>
MoeIcenowy: Surprise! ;)
<smashr_>
tkaiser: looing good linux-image-4.9.0-sun8i_5.20_armhf.deb, linux-headers-4.9.0-sun8i_5.20_armhf.deb, ...
<tkaiser>
smashr_: Version 5.20 doesn't look that good ;) But these .debs can now be installed using dpkg -i
<smashr_>
i'm building a whole sd image and the kernel is missing there
<tkaiser>
MoeIcenowy: What do you think regarding a quick fix for now regarding MAC address? Using DC:44:6D and only randomizing the last three octets?
<tkaiser>
smashr_: Then obviously something went wrong, better ask in Armbian forum and prepare build log: PROGRESS_LOG_TO_FILE=yes
<MoeIcenowy>
bbrezillon: Can I safely use UBI of Linux 4.9 on a MLC now?
<MoeIcenowy>
(a MLC which is like CHIP's
yann-kaelig has joined #linux-sunxi
<MoeIcenowy>
I read "UBI gets ready for MLC NAND support" on phoronix
<mripard>
stop reading phoronix :)
<mripard>
no, it's not ready
<bbrezillon>
MoeIcenowy: hm, no
<mripard>
some preliminary patches have been merged iirc, but definitely not all of the m
<bbrezillon>
I'll post some patches soon, I can Cc you if you want
libv has quit [Ping timeout: 252 seconds]
<MoeIcenowy>
mripard: ;-)
libv_ has quit [Ping timeout: 260 seconds]
libv has joined #linux-sunxi
<MoeIcenowy>
To be honest, I did some experiments on my MLC (when testing A33 NAND device tree node)
<MoeIcenowy>
although I do not dare to store anything real on it
<MoeIcenowy>
bbrezillon: is the nand chip id patch merged?
perr has quit [Remote host closed the connection]
<zoobab>
@tkaiser was reading some bad reviews about gigabit performances on pine64
putti_ has joined #linux-sunxi
ErwinH has joined #linux-sunxi
smashr_ has quit [Quit: Page closed]
terra854 has quit [Quit: Connection closed for inactivity]
leviathanch has joined #linux-sunxi
FergusL has joined #linux-sunxi
dan1 has joined #linux-sunxi
dan1 is now known as dan0_0
<dan0_0>
Any recommendations on USB to Sata bridges?
<KotCzarny>
has to have uasp and trim support at least
<dan0_0>
I've got a bunch of 1TB SSHD's that I was thinking of wirirng up to an orangepi pc, or getting a new opi pc 2 cause gige
<dan0_0>
Yeah, figured needed UASP
<dan0_0>
idk if it actually needs trim, I think that is handled by the drive's firmware, the 8GB flash cache is transparent to the OS afaict
<dan0_0>
at least I see no way to interact with it on Win 8.1, or on Debian
<KotCzarny>
if you use sshd then not necessarily, but if you ever think of ssd, its nice to have
<dan0_0>
yeah, defs
<KotCzarny>
also, would assure you, you are getting something more recent
<dan0_0>
just don't see an SSD in the cards due to USB and all
<dan0_0>
mmm
<KotCzarny>
lower power, quiet etc
<KotCzarny>
so still has its uses
<dan0_0>
yea
f0xx has joined #linux-sunxi
leviathanch has quit [Read error: Connection reset by peer]
leviathanch has joined #linux-sunxi
foxx_ has quit [Ping timeout: 258 seconds]
fkluknav has joined #linux-sunxi
putti_ has quit [Ping timeout: 265 seconds]
<tuxillo>
!seen apritzel
<tuxillo>
hmm not bot.
<tuxillo>
anybody knows by when he uses to be around?
tkaiser has joined #linux-sunxi
<KotCzarny>
- on irc via server sinisalo.freenode.net (Mon Nov 21 11:32:24 2016)
<KotCzarny>
so you missed him by 1.5h
<KotCzarny>
and i think he is in .eu time zone
<tuxillo>
i'm in .eu timezone
<tkaiser>
zoobab: What are you referring to? Some Pine64+ are defective but if you happen to get a working board, GbE performance is fine.
<tuxillo>
it's 1pm CET
<bbrezillon>
MoeIcenowy: nope :-/
<tkaiser>
zoobab: To me it looks like the ideal combination of TX/RX delay is 2/0. With these settings I get iperf3 reports above 900 Mbits/sec in both directions: https://github.com/igorpecovnik/lib/issues/546
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
<dan0_0>
tkaiser: hey, what is the USB to ethernet bridge you keep recommending on the armbian forums?
<dan0_0>
I always see ya throwing shade on what Xunlong and others choose for USB to Sata adapaters, quite entertaining IMO :)
<KotCzarny>
that's because its easy to do. gl830 is pure crap
<tuxillo>
for building sunxi-tools, specifically target-tools, does it require newlib?
<KotCzarny>
have you checked it for reliability? ie. with external thermometer etc?
<jelle>
dan0_0: what thoughts?
<ErwinH>
Not yet, haven't got my IR-thermometer here, but will bring it tomorrow.
<KotCzarny>
i think on a20 readout requires some math for correctness
<KotCzarny>
and 40C for h3 soc is a bit low
gumblex has quit [Ping timeout: 245 seconds]
<dan0_0>
jelle: just curious if it'll see much mainline kernel support like A10/A20/H3 has seen
<KotCzarny>
especially for opi1
<ErwinH>
uptime: 16 min, idling.
<jelle>
dan0_0: same day sure
<jelle>
*some
<dan0_0>
Yeah, some day I'll get a blobless phone from Samsung with an unlocked bootloader, but probably not any time soon :P
<hramrach>
I have an Opi but not an IR thermometer
<hramrach>
some cheap one so probably Opi1
hojnikb has joined #linux-sunxi
<ErwinH>
I'm currently compiling for OPi Zero, let's see if it'll work on that one as well.
putti_ has joined #linux-sunxi
<tkaiser>
ErwinH: I also use megi's branch, ths/thermal stuff worked fine with his 4.6 and 4.7 branches but when tested with 4.9 everything works (cpufreq scaling) but _no_ thermal readouts. And BTW: temperature value is fine when idling.
<hojnikb>
tkaiser: any luck with h5 dvfs stuff ?
<scelestic>
tkaiser: i think i can confirm that, i used a mainline kernel (torvalds tree) and i noticed the heatsink i put on it got quite warm and is was way cooler with megi's tree
<ErwinH>
I'm not using megi's branch, but the montjoie's sun8i-emac-wip-v5 branch, with just the 2 commits I linked.
gumblex has joined #linux-sunxi
<tkaiser>
hojnikb: Nope, why? I don't have a H5 device any more ;)
<hojnikb>
tkaiser: just wondering, i'm expecting delivery within days :D
<KotCzarny>
congratulations, boy, girl or a robot?
<scelestic>
lol
<tkaiser>
hoijnikb: At the moment you have to watch https://github.com/OrangePiLibra/OrangePi_H5SDK for changes. Until these basic issues are resolved (voltage regulation and GbE issue) not that much can be provided.
<dan0_0>
So could I put an inexpensive JMS567 like http://r.ebay.com/zd0i2Z onto these drives and hook say 4 of them up to an OrangePi PC, or aOpi+ 2E?
<KotCzarny>
yup
<KotCzarny>
though opipc has 3 usb ports
<dan0_0>
Would the OTG port be able to support a drive if I used Armbian?
<dan0_0>
eh, I'm counting the OTG port, which is a questionable decision at best on my part
<KotCzarny>
i wouldnt trust otg controller for bulk
<dan0_0>
Yeah, any clue if it supports it though?
<dan0_0>
I have some very worthless data to throw on this SBC, and the more space the merrier. Ideally I'd fill a good chunk of my home gige line 24/7, but that is a bit too hopeful I realize
<KotCzarny>
just buy one bigger drive?
<dan0_0>
tkaiser: have you tried anything this janky? Powering & pushing data to 4x 1TB SSHDs on an Opi+ 2E?
<dan0_0>
eh, I get the drives for free
<dan0_0>
I have 2 dozen of them
<KotCzarny>
o.O
<dan0_0>
yeah
<dan0_0>
we swap them out for 1TB 850 Pros cause we get those for $200 and my coworker can't stand spinning rust at all
<jelle>
are you serious?
<dan0_0>
yes
<dgp>
I trust SSDs less to be honest
<dgp>
They don't start to fail they just totally give up
<dan0_0>
sure, but its out of my hands, and the coin dispenser definitely works much faster with a SSD
gumblex has quit [Ping timeout: 245 seconds]
gumblex has joined #linux-sunxi
<dan0_0>
the point of sale we use does replication on every station, so data loss isn't a biggie either
<dan0_0>
Anyway, anyone tried usb-otg on an H3 based board to do UASP?
<KotCzarny>
looks like you will be first
merbanan has quit [Ping timeout: 260 seconds]
<dan0_0>
lok
<dan0_0>
*lolk
afaerber has joined #linux-sunxi
<dgp>
If it works on a normal x86 machine and the USB controller on the h3 isn't total garbage I don't see why it wouldn't work :)
<tkaiser>
dan0_0: Sure, works. Why shouldn't it? It's a bit slower on the OTG port.
<dan0_0>
I'll let ya know when I either catch the board on fire from too much power draw, or get terrible I/O
<dan0_0>
tkaiser: how much slower?
<dan0_0>
like 40MB/s read vs 35MB/s read on OTG?
<KotCzarny>
beard on fire, heh
<dan0_0>
lol, working on growing one of those, no shave November and anll
<tkaiser>
dan0_0: Usually not with desktop/notebook disks, they want to spinup as soon as there's power provided. So attach some gear to the GPIO pins and use transistors/MOSFETs
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<hojnikb>
KotCzarny: >>>congratulations, boy, girl or a robot hahah, almost fell of a chair :D
<dan0_0>
yeah, kinda like a USB condom, but to inject power
<dan0_0>
huh
IgorPec has joined #linux-sunxi
<dan0_0>
so these draw 2.7w at peak, 2.2w average, and 0.9w at idle
<dan0_0>
per Seagate
<dan0_0>
so 4x 2.7w is 10.8w or 2A and change
<dan0_0>
and the Opi takes around 0.5w minimum, if not more
<dan0_0>
so 3A power supply *if* this even works
<tkaiser>
dan0_0: Is use here JMS567 enclosures which have also a small barrel plug. Necessary when I test with my 'killer SSD' (kills most boards simply by connecting it due to insane high peak power requirements)
<dan0_0>
lol, what SSD is that
IgorPec has quit [Client Quit]
<tkaiser>
Samsung OEM, I took it from a customer since they tried to something really silly: RAID-1 made of two identical SSD
<tkaiser>
ErwinH: Good to know. Out of curiosity: Did you build the kernel stand-alone or using Armbian's build script. I'm asking since maybe we have a patch lying around that is the real problem.
<ErwinH>
I used Armbian's build script.
lkcl has quit [Read error: Connection reset by peer]
<ErwinH>
Editted lib/config/sources/sun8i.conf to use https://github.com/megous/linux/ , branch:orange-pi-4.9. Only had to enable kernel_config to build the Thermal drivers as a module.
<tkaiser>
ErwinH: Nice! Did you already play around with https://github.com/fifteenhex/xradio ? In case you get it working you could send the config changes and the driver as .patch as a pull request :)
<dgp>
ErwinH: I would be interested to see what your temp readings are. I see 40c when the chip is skin burning hot
leviathanch has quit [Read error: Connection reset by peer]
<dgp>
MoeIcenowy: how are you doing the power and reset control? with an always on regulator and pwrseq?
<dan0_0>
Btw, what do y'all think of the RTL8189FTV (opi lite) vs XR819 (opi zero). Is one significantly superior, or are they about the same/non-notable?
<dgp>
XR819 driver looks like a mess but it does seem to work. RTL8189FTV has mainlined drivers doesn't it?
<hramrach>
yes, I can see how doing integrity checks when you have RAM bitflips can cause failure whereas not doing the checks just potentially stores the flipped bit somewhere
<dan0_0>
So I hooked 3 phones and a tablet up to my Opi+ 2e, the killawatt has it at 14w. Base load with no devices is 2w
<dan0_0>
Theoretically that means I should have the power budget for 4x drives sucking down 11w at startup
<dan0_0>
I'm using the "3A" charger I bought from Xunlong with this board, and it seems to actually do at least 2.8A
<dan0_0>
need more power hungry devices to really push it to the max
<hramrach>
tkaiser: on how many 'systems' do you run btrfs?
<dgp>
You might need a scope to see if it'll really work. Like one of the rails might sag badly when all the drives come on and then you'll get a random crash sometime later
<hramrach>
from what I hear around the reliability is just not there. btrfs failing is as much a concern as bits flipping randomly in non-ecc memory
<tkaiser>
hramrach: Only on a few H3 devices (me being a ZFS fanboy), but I always use it when testing to get data corruption reported early. So a slightly different use case ;)
<dan0_0>
mmm, my friend has a scope, and I know he also has a few USB condoms that show wattage, votage & aperage
<dan0_0>
*voltage
<dan0_0>
I guess I'll nag him when I get back to Seattle
<dan0_0>
I kinda wanna get a dummy load for USB
<KotCzarny>
seriously guys, those are cheap DEV boards
<dan0_0>
just so I can see how far I can push power supplies and SBCs
<KotCzarny>
not meant for production usage
<dan0_0>
KotCzarny: lol, I'm sorry to tell you I have a few in prod as paging servers
leviathanch has quit [Remote host closed the connection]
<tkaiser>
KotCzarny: We replaced a few 40 TB NAS boxes with H3 boards. Using a crude mixture of mdraid and btrfs and compression. Works great ;)
<KotCzarny>
:)
<dan0_0>
tkaiser: I have some glorified python scripts that need/use/target systems running systemd, on Armbian can I just apt install systemd to upgrade off sysvinit on 5.20?
<KotCzarny>
still, product is sold to different audience, no guarantee of any kind ;)
<dan0_0>
do they still host 40TB worth of spinning rust?
<dan0_0>
lol
<tkaiser>
dan0_0: Are there Armbian images around without systemd?
<KotCzarny>
armbian uses systemd by default
<dan0_0>
my customers call me on the rare occasion they stop working. Only the oldest one has ever generated issues
<dan0_0>
orly?
<KotCzarny>
usually its the other way around
<dan0_0>
I think I'm tired
<KotCzarny>
yup. jessie at least
reinforce has quit [Quit: Leaving.]
<KotCzarny>
not going to brag about evilness of systemd again, though
<dan0_0>
yeah, I thought I read something about it using sysvinit on the forum, never bothered to verify & treated that as gospel
<tkaiser>
dan0_0: The 40 TB were the result of 'full server syncs' that took ages. We then simply used one virtual machine at the central location to do the rsync stuff there to various btrfs subvolumes (snapshots) and then only send the needed data to the H3 boxes (btrfs send/receive, great since efficient and fast). Works pretty well so far
<dan0_0>
KotCzarny: its lovely, it keeps my janky ass scripts alive
* dan0_0
♥ systemd
<dan0_0>
At one point my janky scripts died every 32 calls, systemd covered up my screwup! Cust. never even knew
<KotCzarny>
its not an excuse to write proper software ;)
<dan0_0>
lol, just saying it made things much easier when I was just learning python
<dan0_0>
tkaiser: thx, now I have to go mail a few mSD cards out to custs with Armbian :(
<dan0_0>
get them off that lovely Xunlong Debian
<KotCzarny>
lol
xes has joined #linux-sunxi
<KotCzarny>
poor customers
<dan0_0>
KotCzarny: They don't know the difference!
<dan0_0>
I did bother to fix the fex file so most of them won't overheat either
<tkaiser>
xes: Did you try sunxi-wp instead of sunxi_wp?
<dan0_0>
So, the Xunlong 3A power adapter can definitely do over its rated 3A, I just saw it do 15.8w on booting a Opi 2e with 4 power slurping devices attached, which is 3.16A
<dan0_0>
the OEM Samsung charger capped out at 9.8w, slightly under what its rated at (2.1A)
<xes>
KotCzarny: there are those cheap usb relay modules that could be managed also by Lede to trigger the power button... if you don't care about a few wires :)
fl_0 has quit [Quit: STRG + Q]
<KotCzarny>
xes, i've ordered few bistable relays for my boards, to ease resetting ;)
lkcl has quit [Read error: Connection reset by peer]
lkcl has joined #linux-sunxi
lamer14797418691 has joined #linux-sunxi
terra854 has joined #linux-sunxi
Worf has quit [Quit: Konversation terminated!]
lamer14797418691 has quit [Client Quit]
fl_0 has joined #linux-sunxi
<hramrach>
regarding idle power .. it makes sense to downclock when on battery .. maybe, sometimes .. ENODATA
tkaiser has quit [Ping timeout: 265 seconds]
<KotCzarny>
tkaiser managet to get down to ~0.5W with H3
<KotCzarny>
*managed
tkaiser has joined #linux-sunxi
<KotCzarny>
which is nice, because you can upclock without resetting
<hramrach>
there is that deep sleep these chips have when the CPU is off and RAM is on refresh with the bus off
<KotCzarny>
nah, it was idle os without going into deep sleep
<KotCzarny>
just turning off unused parts/cpus and downclocking cpu/dram
gumblex has quit [Quit: Bye.]
<wens>
argh, exhausting day
<KotCzarny>
there is a possibility to use openrisc core to fully powerdown soc, but someone has to write software for it, yet
whaf has joined #linux-sunxi
<wens>
tkaiser: we can't we allwinner's mac prefix
<wens>
use *
<tkaiser>
wens: Why?
<xes>
idle os? never. Sometimes i downclok it when it is too close to 70 degrees ;)
<xes>
tkaiser: nope, module is not there
<wens>
tkaiser: the owner is supposed to hand out unique mac addresses, so they don't repeat
<wens>
tkaiser: we are not the owner
<tkaiser>
wens: How did the original version of the driver implemented that? Using Allwinner prefix only together with a stored address somewhere (EEPROM, efuse)?
<wens>
tkaiser: no idea, i did not look at the original driver
<wens>
actually i have no clue what driver you are referring to
<wens>
the comment above it says "TODO: read from product ID"
<dan0_0>
KotCzarny: does the openrisc core require specially compiled software?
<KotCzarny>
dan0_0: yes. its different architecture
<dan0_0>
figures, so what use would it be? Run a RTOS set to wake the board up at a certain time, or when something comes in over eithernet or wifi?
<dan0_0>
or could you shove a full kernel onto it?
<MoeIcenowy>
tkaiser: the original patch uses file storage to make non-volatile MAC...
<KotCzarny>
you have (slow) access to everything. cant shove anything big because of slowness
<KotCzarny>
also, it has no mmu
<MoeIcenowy>
which I removed in my repo
<dan0_0>
KotCzarny: Huh, so would it be reasonable to run kernel 4.9 on it if it was OC'ed?
JohnDoe_71Rus has joined #linux-sunxi
<KotCzarny>
um. think DOS
<KotCzarny>
single app that does some predefined tasks
<tkaiser>
wens: MoeIcenowy: Still the problem which address then to choose. When we switch to locally administered addresses we could use x2-xx-xx-xx-xx-xx, x6-xx-xx-xx-xx-xx, xA-xx-xx-xx-xx-xx or xE-xx-xx-xx-xx-xx
<dan0_0>
ah
<dan0_0>
how low does power usage get?
<KotCzarny>
no one checked yet
<dan0_0>
is it like intel's power gating where the whole A7 chunk of the SOC goes dark?
<dan0_0>
mmm
<KotCzarny>
i would think so
<tkaiser>
dan0_0: You could check if you're still using Xunlong Debian image. Simply send the board to suspend and measure.
<dan0_0>
tkaiser: how?
<dan0_0>
I can throw that image on a board
<KotCzarny>
echo sleep >/sys/power/state ?
<dan0_0>
ah
<KotCzarny>
(or something similar)
<dan0_0>
tkaiser: last one I did with that image was a few months back thankfully
<dan0_0>
glad all I need to do is just mail some mSD cards with the next bills I mail out
<wens>
tkaiser: locally administered random addresses (or based on chip id) are ok i guess
<tkaiser>
dan0_0: No idea, there's a sysfs node somewhere. I discoverd it by accident one of the few times I tested Armbian with display connected. There was a 'suspend' button or something like that
<dan0_0>
huh
<tkaiser>
wens: ok, but at least we should take care that the first octet is not totally random.
<dan0_0>
Btw, how bad of an idea is it to run a Point of Sale on an Opi+ 2e? I've finished this semi-integrated work so it doesn't handle any credit card data, and ansibilized the installation of it
<dan0_0>
Kinda wanna see how janky I can go
<wens>
tkaiser: why? making sure the locally administered bit is set should be enough, shouldn't it?
<tkaiser>
wens: Yeah, that was what I meant.
<wens>
:)
<wens>
also, about the rtl8189ftv driver, hans mentioned he had no intention to mainline it, or even get it into staging
<tkaiser>
wens: In these 8189 drivers RealTek vendor MAC prefix is used: 00:e0:4c: ;)
TheLinuxBug has quit [Ping timeout: 248 seconds]
<wens>
i thought that had an eeprom to store a programmed mac address?
<tkaiser>
Hmm... MAC addresses of both wlan0 and wlan1 on Pine64 (BSP kernel) are also not 'sane'
<miasma>
should the serial link work without any problems @ 115200 bps? i sometimes get corrupted data with ascii changing into binary garbage. also it seems that h3 boards sometimes just stop responding via the uart even though you can ssh into them? at least the usb serial module doesn't flash any lights after a while so I'm assuming that it somehow just decides to stop communicating
<miasma>
KotCzarny: yes, but is it common? how do people deal with it
<KotCzarny>
i just replug usb-serial dongle
<miasma>
what about the situation when communication totally stops? the board is still alive, but i can't get any serial data through. unplugging / restarting minicom won't have any effect
The_Loko has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<KotCzarny>
you can try resetting usb host
<miasma>
on the pc?
<KotCzarny>
i assume you are using usb dongle? or direct serial?
<miasma>
usb dongle
<KotCzarny>
then where the usb host is
leviathanch has quit [Remote host closed the connection]
<KotCzarny>
resetting connection parameters maybe (on both sides)
IgorPec has quit [Ping timeout: 256 seconds]
deskwizard has quit [Ping timeout: 245 seconds]
cptG_ has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
Ntemis has joined #linux-sunxi
cptG has quit [Ping timeout: 265 seconds]
ErwinH has quit [Ping timeout: 260 seconds]
IgorPec has joined #linux-sunxi
Andy-D has joined #linux-sunxi
massi has quit [Read error: Connection reset by peer]
phipli has joined #linux-sunxi
netlynx has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
phipli has quit [Ping timeout: 250 seconds]
fkluknav has quit [Ping timeout: 256 seconds]
tkaiser has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 248 seconds]
iamfrankenstein1 is now known as iamfrankenstein
iamfrankenstein has quit [Quit: iamfrankenstein]
netlynx has quit [Quit: Ex-Chat]
OtakuNekoP has joined #linux-sunxi
OtakuNekoP has quit [Remote host closed the connection]
f0xx has quit [Ping timeout: 240 seconds]
OtakuNekoP has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
<tuxillo>
hmm, uart0-helloworld-sdboot can't be used for aarch64 right?
terra854 has quit [Quit: Connection closed for inactivity]
<NiteHawk>
tuxillo: i'm pretty sure i've used it on the pine64. it depends on which mode the BROM comes up in - i think so far all A64 SoCs were in AArch32 initially
<tuxillo>
but then you can't build an aarch64 binary, you have to make a 32-bit one
<ssvb>
tuxillo: the Allwinner A64 SoC used by the Pine64 board initially boots in the 32-bit mode, so uart0-helloworld-sdboot has to use 32-bit code too
<NiteHawk>
http://linux-sunxi.org/Arm64#Boot_modes - as i said, the SoC initially comes up in AArch32 mode, but there are ways of switching to AArch64 mode later. For the Pine64 this is done with a "warm reset" (RMR request)
<tuxillo>
yeah but I'd like to run my own 64-bit code directly by using FEL as apritzel recommended to do
<tuxillo>
NiteHawk: yeah, he told me how to do that too
<ssvb>
beware that once you are in the 64-bit mode, you can't use FEL commands anymore
<ssvb>
that's a one way ticket
<NiteHawk>
tuxillo: well then you "know the drill" already? upload your 64-bit code and do a reset64 command
<tuxillo>
he explained it yes, but I have never done it
<ssvb>
well, then you know what to do
<ssvb>
how many people do you need to tell you this information until you actually try it? ;-)
<tuxillo>
i just got the cable today
<tuxillo>
and I hadn't had much time until now
<NiteHawk>
apritzel has implemented Pine64 firmware (ATF) with this method, it should be around on his Github account - you might want to study that in more detail (i'm not familiar with it)
<ElBarto>
little OT question, do you guys know the status of dts overlay in dtc ?
<NiteHawk>
ssvb: i've been experimenting with "memmove" logic (for a more 'generic' copy operation) using 32-bit words where possible. but the code currently still expects the base addresses (dst, src) to be word-aligned. would you expect such a "memmove" to deal with arbitrary addresses?
<ssvb>
NiteHawk: a properly optimized memmove would use aligned memory accesses for performance reasons anyway
<ssvb>
NiteHawk: maybe we can even snatch some already existing implementation
<NiteHawk>
ssvb: hmmm... it couldn't if the user passes in address parameters that are misaligned? not necessarily with respect to word boundaries, but inbetween each other
<tuxillo>
hmm, is it normal that the pine64 stays on even when I remove the power cable and only the usb male-to-male cable is connected?
<NiteHawk>
but yes, looking for existing implementations is certainly reasonabke
<ssvb>
yes, you are right, the leading and trailing chunks are probably using byte reads in the existing memcpy/memmove implementations
<ssvb>
we might need to modify this
<ssvb>
but do we really need this memmove functionality for anything practical yet?
<NiteHawk>
ssvb: no, we don't. it might be a future option for the sunxi-pio utility / fel-gpio script, but then we're dealing with SoC<->host transfers, which the readl/writel functions should handle gracefully
matthias_bgg_ has joined #linux-sunxi
<ssvb>
NiteHawk: I already asked this on the github tracker, why wouldn't we just incorporate this sunxi-pio functionality into the sunxi-fel tool?
<NiteHawk>
tuxillo: mine doesn't seem do that, if PWR is disconnected, the led goes off - and it won't come up when just connecting the OTG
premoboss has quit [Read error: No route to host]
<tuxillo>
no I mean, I have the power and OTG connected. if I pull the power the led is still red
<ssvb>
tuxillo: what about the UART cable? it may be leaking power too
<tuxillo>
yeah, that is definitely leaking
<tuxillo>
only with the uart plugged there is a dim red light
<tuxillo>
I must say I have tested the uart and it works
<tuxillo>
despite the leakage
phipli has quit [Ping timeout: 252 seconds]
apritzel has joined #linux-sunxi
premoboss has joined #linux-sunxi
<apritzel>
ssvb: this "one way ticket" thing isn't exactly right: I once managed to switch to AA64, print something on the UART and then switch back to AA32 and return to FEL
phipli has joined #linux-sunxi
<tuxillo>
apritzel: hey
<apritzel>
ssvb: it doesn't work with the SPL though, atm
<apritzel>
tuxillo: hi
<NiteHawk>
apritzel: but you certainly have to be careful / avoid quite some pitfalls when doing that?
<apritzel>
NiteHawk: that's probably the reason it breaks atm with the complete SPL
<apritzel>
NiteHawk: though I am back in AA32 already, but then get a 64-bit register dump
<apritzel>
NiteHawk: so apparently U-Boot's exception handler is still around
<ssvb>
FEL definitely uses its own exception handlers and will not work if they break
<tuxillo>
the EXP pins don't work for whatever reason. I am trying a sdcard with u-boot on it
<apritzel>
tuxillo: they work perfectly for me: pin 7, 8 and 9
<apritzel>
close to the SD card slot
<apritzel>
tuxillo: first rule if serial doesn't work: swap TX and RX ;-)
<apritzel>
ssvb: I have this in AA32 code in the SPL
<apritzel>
btw: any reason you dump SCTLR twice?
<ssvb>
apritzel: hmm, that's a good catch
<tuxillo>
apritzel: no, the ones close to the sdcard are the 30s
Mr__Anderson has quit [Ping timeout: 246 seconds]
<tuxillo>
apritzel: UART works there but the problem is that there is some sort of power leak
<apritzel>
tuxillo: ??? Are you looking at a Pine64?
<ssvb>
apritzel: I tried to save and restore the system registers in the same way as U-Boot was doing this, and U-Boot probably accessed SCTLR twice with a bit different comment :-)
<apritzel>
tuxillo: I see a power leak on the "Euler bus" pins
<apritzel>
ssvb: yeah, I was thinking so
<apritzel>
ssvb: no big deal anyway
gpgreen has joined #linux-sunxi
<apritzel>
ssvb: my hunch is that it's due to the fact that there is more than one VBAR in ARMv8
<tuxillo>
apritzel: yeah, I'm using the euler connector
<tuxillo>
:D
<apritzel>
ssvb: I think the SPL set's up VBAR_EL3, which should map to MVBAR
<apritzel>
tuxillo: just use the pins one the EXP connector, they have an extra FET to avoid leakage
<tkaiser>
tuxillo: So why not moving to the EXP header nearby?
<tuxillo>
because I should be sleeping I think =)
<tuxillo>
yeah, EXP connect works like a charm, no leakage
<apritzel>
tuxillo: that's actually the transistor a bit above, but between the two header sets
<tkaiser>
apritzel: Will do. Tomorrow. Pine64 loves daylight ;)
<apritzel>
tkaiser: I always wanted to do so, but never got around it
<NiteHawk>
ssvb: entirely unrelated - was there a particular reason why you selected ruby for the objdump->.h translation (fel-to-spl-thunk)? it looks like something that e.g. awk should suffice for
<NiteHawk>
i'm just curious, not going to embark on a language crusade here ;) but yes, (g)awk seems to be readily available, and a full-grown ruby feels a bit overkill for this task
<apritzel>
tuxillo: $ make uart0-helloworld-sdboot.sunxi
<NiteHawk>
s/if/are/
<ssvb>
apritzel: a proper way would be to actually build depend on a 32-bit arm crosscompiler, but distributions are doing an awful job packaging it
<tuxillo>
apritzel: let me try. i was trying gmake target-tools
<ssvb>
apritzel: and we have exactly the same problem with the 32-bit SPL build in U-Boot
<tuxillo>
apritzel: fails because there is no mksunxiboot
<NiteHawk>
yes, that's part of U-Boot :P
<apritzel>
tuxillo: if you have the U-Boot sources around: it's in tools
Mr__Anderson has joined #linux-sunxi
<tuxillo>
let me see
<apritzel>
(in the tools/ directory, I meant)
<ssvb>
tuxillo: hmm, no stdio.h header in dragonfly?
premoboss has quit [Read error: Connection reset by peer]
<tuxillo>
apritzel: that is definitely not going to compile in dfly
<tuxillo>
ssvb: sure there is
<apritzel>
ssvb: yeah, I have now a script that iterates $PATH to find something that matches "arm-*-gcc"
<tkaiser>
NiteHawk: Nope, my main build host (with the many USB ports ;) ) runs with ESXi at a customer's site since a while. And I failed to order the specs violating USB cable for Pine64 and Beelink X2 multiple times.
<ssvb>
tuxillo: are you not comfortable enough with git to update the commit message?
<tuxillo>
ssvb: I am trying to find out why the defined was along with NetBSD
<NiteHawk>
I suspect that older BSDs did not have those (POSIX?-)compliant function names in their endian.h, which is probably why those additional #defines were introduced
<tuxillo>
apritzel: it seems u-boot heavily depends on linux kernel includes
<apritzel>
tuxillo: have you tried: $ make -C tools mksunxiboot
<tuxillo>
apritzel: no, but I don't think it will work
<apritzel>
tuxillo: it's an easy, but neat little userland tool
<tuxillo>
isn't asm/arch/spl.h a linux define?
<tuxillo>
yeah it complains it can't find it
<apritzel>
tuxillo: spl.h is from U-boot
<tuxillo>
ah
<apritzel>
tuxillo: yeah, it's a bit nasty: the tool is quite old and originally from an external source
<apritzel>
Allwinner, in fact ;-)
<apritzel>
but Tom Cubie, at least
<apritzel>
tuxillo: just remove that include and fix up what the compiler complains about
<tuxillo>
yeah, on that already
<apritzel>
ssvb: NiteHawk: any chance we can move a cleaned up version mksunxiboot into sunxi-tools?
<apritzel>
a portable one?
<apritzel>
ssvb: or make a Ruby version of it? :-P
<NiteHawk>
:D
<NiteHawk>
i'll pick Lua for that ;)
yann-kaelig has joined #linux-sunxi
<ssvb>
apritzel: I believe it's fine in U-Boot, as long as it gets installed as a part of the standard U-Boot tools package
<NiteHawk>
the thing is that we *do* want it up to date with U-Boot sources, so we'd need something that can be kept in sync reasonably simple
yann-kaelig has quit [Remote host closed the connection]
<ssvb>
having to maintain two copies of the same tool is not great
iamfrankenstein has quit [Read error: Connection reset by peer]
<tuxillo>
apritzel: god forgive me for what I had to do xD
<tuxillo>
tools/mksunxiboot: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libexec/ld-elf.so.2, for DragonFly 4.0.703, not stripped
<apritzel>
tuxillo: don't look back ;-)
iamfrankenstein has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
<apritzel>
tuxillo: btw, do you have something like a "u-boot-tools" in your dfly repo or ports?
OtakuNekoP has quit [Remote host closed the connection]
<apritzel>
tuxillo: is there some easy to use image of DragonFly which I can just put into a VM?
|Jeroen| has quit [Remote host closed the connection]
<ssvb>
tkaiser: how did you find it?
<tkaiser>
ssvb: I'm in touch with one moderator from Pine64 forum and he was quite surprised that the SoM already exists. Since they were told by TL Lim they get informed first.
<tuxillo>
apritzel: we dont't have any u-boot package in dports. but it exist in freebsd ports so I guess it's just a matter of fixing the build
<tkaiser>
ssvb: Lurking through longsleep's github repo.
<apritzel>
ssvb: didn't know about the announcement as well
<tkaiser>
ssvb: And then a simple google search for sopine
afaerber has quit [Quit: Ex-Chat]
<apritzel>
though I have it since August ;-)
<tuxillo>
brb
camh has quit [Ping timeout: 244 seconds]
<beeble>
apritzel: since you seem to be interested in such things. apm got bought today. we could take bets how long they will continue to make cpus :)
<apritzel>
beeble: interesting, though they claim that the CPU business will be sold again
iamfrankenstein has quit [Quit: iamfrankenstein]
iamfrankenstein1 is now known as iamfrankenstein
<beeble>
to whoever is willing to buy them...
<apritzel>
beeble: yeah, Intel ;-)
florianH has quit [Quit: Connection closed for inactivity]
<tuxillo>
apritzel: works
<tuxillo>
Hello from Allwinner A64!
<tuxillo>
Returning back to FEL.
<apritzel>
tuxillo: see? Now you are in ...
<tuxillo>
this is cool, but now I need to do it on aarch64 :)
camh has joined #linux-sunxi
<apritzel>
tuxillo: I am just about to send you an example ...