<plaes>
montjoie: last commit, you can now remove Ethernet Phy from the todo :P
paulk-blaze has quit [Remote host closed the connection]
<montjoie>
:)
<jonkerj>
stmmac is the new name for emac?
yann-kaelig has joined #linux-sunxi
<montjoie>
jonkerj: sun8i-emac is in fact a modified dwmac and so the driver become a glue to the mainline stmmac driver
<montjoie>
plaes: fix uploaded
<jonkerj>
ah, so less, more reuse
<jonkerj>
montjoie: did you manage to find the cause of the MMC error when running very recent kernel?
<jonkerj>
MMC clock errors
* plaes
had those too...
<montjoie>
jonkerj: bisected to a mripard commit in pinctrl BUT the last two kernel produce kernel crash and not mmc timeout
paulk-blaze has joined #linux-sunxi
<willmore>
montjoie, now do you port the improvements from the emac driver to the stmmac driver?
<willmore>
Wonderful work, BTW. It's great to see this level of reuse.
<montjoie>
willmore: I need to, on pine64 the perf of stmmac is awful
<willmore>
I hope that gets the level of appreciation that it deserves--too many "just write it from scratch and ignore existing drivers" in the ARM world.
<willmore>
I saw. :(
<willmore>
Especially since you got blindsided by the whole "plot twist, emac is stmmac" thing.
libv_ has joined #linux-sunxi
<montjoie>
since chain_mode is an optionnal argument, perhaps nobody use it and so bad perf
<willmore>
Maybe it's broken?
libv has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<KotCzarny>
montjoie: maybe do the other thing, ie port stmmac to your driver?
<willmore>
Easier to get a whole new (and maybe redundant) driver into the kernel than a rewrite of an existing driver to support a new device.
<montjoie>
KotCzarny: there are a dozen of glue to stmmac, porting them without hardware should be hard
libv_ has quit [Ping timeout: 248 seconds]
<willmore>
And irresponsible.
<willmore>
And unlikely to ever get merged.
Ntemis has joined #linux-sunxi
sunxi_fan has quit [Ping timeout: 260 seconds]
<KotCzarny>
drivers get updated when better/fixed
lemonzest has joined #linux-sunxi
libv has joined #linux-sunxi
<willmore>
I think montjoie is on the right path. Get the existing driver to support the new hardware. Then improve that driver to make all hardware work better.
<KotCzarny>
what if existing driver is worse than new one?
<KotCzarny>
otoh it might be slow because of some failsafes/chip bugs
hramrach has quit [Ping timeout: 248 seconds]
<willmore>
KotCzarny, exactly. It might have bug fixes in it that we haven't yet run into--or maybe they're fixes for other chips and we don't need them.
<willmore>
But, that all can be tuned with time.
<willmore>
Better to have an accepted driver support our hardware *now* and make it work better later.
<willmore>
Unless montjoie feels that the framework of the driver will never allow full performance. Then there's room for arguement.
paulk-blaze has quit [Remote host closed the connection]
<willmore>
montjoie, do all existing drivers use ring buffer mode instead of chain mode? chain mode is popular in Intel NICs, IIRC.
vishnup has quit [Ping timeout: 245 seconds]
<montjoie>
all stmmac driver use non-chainmode
sunxi_fan has joined #linux-sunxi
hramrach has joined #linux-sunxi
<willmore>
So they just pingpong two buffers for gigE? That seems like a performance limiter.
<willmore>
There seem to be a lot of tuneable parameters in the stmmac driver.
<willmore>
montjoie, what generation of GMAC is on these chips?
paulk-blaze has joined #linux-sunxi
<montjoie>
these ?
<montjoie>
you means all other glued driver in stmmac dir ?
<willmore>
montjoie, I was think of the the H3/H5/A64
<montjoie>
dont know
<willmore>
Okay.
<montjoie>
ETOOHACKEDBYALLWINNER
<willmore>
I wonder if the driver will give that info up with an ethtool query. :)
<willmore>
LOL
libv has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Remote host closed the connection]
<montjoie>
it try to read sysnopsys_id
<montjoie>
and get 0
cnxsoft has joined #linux-sunxi
<montjoie>
so perhaps not a gmac4
<montjoie>
but I need to recheck
<willmore>
What do ethtool -S and -d give?
<montjoie>
nothing that can help to identify for -S
<montjoie>
and -d just segfault:D
<willmore>
well then
<montjoie>
perhaps some function are missing:)
<willmore>
Or not working.
cnxsoft has quit [Remote host closed the connection]
<willmore>
Because of scrambling?
<montjoie>
yeah still some gaps I need to fullfill
<willmore>
Understood.
<willmore>
montjoie, good luck!
<montjoie>
the hard work is done
<willmore>
*highfive*
paulk-blaze has quit [Remote host closed the connection]
f0xx has quit [Ping timeout: 248 seconds]
libv has joined #linux-sunxi
LargePrime has quit [Read error: Connection reset by peer]
paulk-blaze has joined #linux-sunxi
apritzel has joined #linux-sunxi
msevwork has quit [Quit: Leaving]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 252 seconds]
lis82 has joined #linux-sunxi
<apritzel>
kristina: hi, the A64 seems to have a TrustZone controller which looks like the ARM TZ380 to me
<apritzel>
kristina: which is not named as this in the documentation, but the register description seems the same
<kristina>
apritzel: doesn't the TRM also outline their own TZ stuff or is that pretty much what they're documenting?
<kristina>
oh.
<kristina>
i was about to say.
<apritzel>
kristina: yeah, welcome to AW ;-)
<apritzel>
also there is a secure peripheral controller, which allows to switch peripherals between secure and non-secure
<apritzel>
though this does not work as expected
<apritzel>
our best guess is that this depends on some "secure eFuse" setting to be effective
<kristina>
i bought myself a pine64 board, will probably port 64 bit xnu to it.
BenG83 has quit [Quit: Leaving]
libv_ has quit [Ping timeout: 240 seconds]
<lis82>
hi all, anyone have a schematic for A31 tablets? i'm looking for onda v972 exactly.
<apritzel>
kristina: have fun with that ;-)
<kristina>
apritzel: do you know if the orisc coprocessor can be used as a general purpose coprocessor?
<apritzel>
kristina: from all we know: yes
<kristina>
neat.
<apritzel>
kristina: there is some example code somewhere how to load and execute your own code
<apritzel>
kristina: it seems to be pretty independent
<apritzel>
kristina: though the isolation might not be right without the security features
<kristina>
apritzel: as far as at least securing ram regions do tzpcs work as expected?
<apritzel>
kristina: at the moment you can write to the "secure" SRAM A2 from Linux, for instance, which is supposed to hold the ARISC program
<apritzel>
kristina: I haven't checked, really, but the TZ only covers DRAM
<apritzel>
which the ARISC can access, but apparently not very fast
<kristina>
ah i see, so DRAM protections work but peripherals all act as non-secure?
<apritzel>
might be, I haven't checked
<kristina>
biggest concern is the timer.
lynxis has joined #linux-sunxi
<apritzel>
for now we don't use DRAM protection
<apritzel>
kristina: that's the problem: in the moment all peripherals seem to be accessible from non-secure world as well
<apritzel>
only exception is the GIC
<apritzel>
the AW architecture seems to hint at the idea, that the ARISC is always in secure world, and thus cannot be tampered with from non-secure
<apritzel>
there is a set of peripherals which look like they are designated to the ARISC
<apritzel>
and thus are secure, though atm they are not protected
<kristina>
but you can still access its sram with axprot[1] or w/e set to high?
<kristina>
seems odd.
LargePrime has joined #linux-sunxi
<apritzel>
I can read and write to SRAM A2 from U-Boot running in EL2
<apritzel>
SRAM A2 is marked as "secure only" in the documentation
<apritzel>
so my hunch is that these "always secure" or "switchable secure" peripherals still have a global enable switch
<apritzel>
which apparently is turned on when the system boots with some magic secure eFuse set
<apritzel>
I have a Remix Mini PC, which has a very similar H64 CPU
<kristina>
i'll be very sad if it turns out securing DRAM requires that as well.
<apritzel>
kristina: indeed
libv has joined #linux-sunxi
<apritzel>
this Remix Mini PC observes the security settings
<apritzel>
apparently because it has the secure eFuse burned
<apritzel>
but: there is no documentation about that, also it seems to be a one-way decision, so you will probably really brick your board :-(
<kristina>
well i don't think pine64 even exposes the pin needed to burn efuses.
<kristina>
so you need to do some bga rework :s
<kristina>
apritzel: well i figured the bootrom would be checking the fuses versus them being hardwired into some HW logic.
<kristina>
ie, checking if security is enabled and then sigchecking boot0 for example.
<apritzel>
there seem to be _two_ BROMs, one secure, one nonsecure
<kristina>
i wouldn't outrule the possibility of bootrom doing something to enable security, in which case you could replicate that.
<apritzel>
it looks like they are mapped to the same address
<kristina>
unless it's a write once kind of thing.
<apritzel>
kristina: one would hope that it's like you say, but I am afraid it's really a write-once thing: you burn the eFuse and that's it
<kristina>
what i meant it, bootrom checks the fuse, if the fuse isn't set, it writes to some mmio that security isn't enabled and that can no longer be overriden without a cold reboot.
<apritzel>
maybe worth to disassemble the (visible) BROM and check for that
<kristina>
hardware i worked with/on used that kind of scheme.
<apritzel>
possibly
<kristina>
with peripherals that could be permamently disabled until a cold reboot.
<apritzel>
I was afraid that it's like this: secure BROM starts, checks the eFuse, disables security if not set and continues in non-secure BROM
<kristina>
even if you knew the fuse, you can't burn fuses without some BGA rework unless the board vendor actually exposed the pin.
<kristina>
according to the wiki.
<apritzel>
but also there is no documentation about it
<apritzel>
afaik the Wiki documents our best knowledge on that subject ;-)
<kristina>
apritzel: could you dump the fuse array on the one that does observe security settings and compare?
<apritzel>
kristina: well, currently I am trapped in non-secure world, and it really seems to work there ;-)
<kristina>
hm shit, i mostly bought this board to play around with tz stuff.
<apritzel>
I can't even switch to AArch64, because I am started in non-secure Aarch32 EL1
<kristina>
would be dissapointing to find out it can't even do secure RAM.
<apritzel>
kristina: well, maybe the TZ 380 works, because Allwinner uses it in their firmware
<apritzel>
(which doesn't mean too much, honestly ;-)
<apritzel>
kristina: and I think it's worth to check the BROM disassembly for anything touching security related stuff
<apritzel>
kristina: AW puts ATF in the beginning of DRAM, probably for that purpose
f0xx has joined #linux-sunxi
<kristina>
apritzel: do you know secure boot works on those devices?
<apritzel>
kristina: not really, it's all just guesses
<kristina>
i would assume efuse array contained a hash of the certificate but it seems to small to contain something that would be cryptographically secure.
<Kosaka-Honoka>
apritzel: you cannot fully access SID on Remix Mini?
<apritzel>
kristina: that's one of those guesses, yes
<apritzel>
kristina: I think together with that enable efuse you burn some kind of public key in there as well
<kristina>
ah.
<kristina>
well in general the approach is to burn the hash of the certificate.
<apritzel>
kristina: and BROM verifies your very first code loaded (boot0) against taht
<apritzel>
kristina: yeah, or that
<kristina>
and then you supply the certificate with your SPL image as well as a signature.
<apritzel>
kristina: tbh I don't have much experience with those "secure boot" things
<kristina>
apritzel: it's possible that SID just has a register that enables or disables peripheral security.
<Kosaka-Honoka>
apritzel: can Secure BROM be read out?
<Kosaka-Honoka>
or it's fully in secure world?
<kristina>
well you start in secure world.
<apritzel>
Kosaka-Honoka: I think so, as the documentation puts in the same address as the non-secure ROM
<kristina>
(as far as i understand, boot0 starts in el3)
<apritzel>
kristina: the BROM and boot0 start in AArch32 monitor mode
<kristina>
apritzel: what would even be the point of an insecure bootrom? the device will start in secure mode regardless wouldn't it?
<kristina>
doesn't ARM start in secure supervisor mode?
<apritzel>
kristina: which is very similar to monitor mode, yes
mpmc has quit [Ping timeout: 245 seconds]
<kristina>
iirc ARM always starts in secure SVC, monitor is a special mode.
<kristina>
monitor is like a gateway mode between secure/insecure world.
<apritzel>
kristina: I think those two can easily be switched between
<kristina>
well yeah secure svc can enter monitor mode and monitor can enter secure svc.
<kristina>
catch is secure svc can't cleanly exit secure mode.
<apritzel>
indeed, so for practical reasons I tend to treat the same ;-)
<apritzel>
also it's a bit more confusion since this is ARMv8
<kristina>
i find it weird that the cpu config registers actually expose shit like GICDISABLE as registers
<apritzel>
the spec says the core starts in highest privilege mode, with AA32/AA64 being determined by a pin
<kristina>
while most SoCs will have that stuff hardwired
<kristina>
yeah.
<apritzel>
(this applies to ARM Cortex, actually)
mpmc has joined #linux-sunxi
<apritzel>
but anyway: on the Pine64 we indeed start in SVC, with NS cleared
<kristina>
wait what.
<apritzel>
on the Remix Mini NS is set already
<kristina>
oh right NS cleared
<kristina>
misread that.
popolon has joined #linux-sunxi
<apritzel>
yeah, I love this "NS bit" semantic as well ;-)
<kristina>
apritzel: well it depends, on pine don't you gain control of the chain of trust much earlier than on remix?
<apritzel>
yes
<apritzel>
that statement was for practical purposes, really
<kristina>
the only difference is probably bootrom sigchecking the next stage.
libv has quit [Ping timeout: 258 seconds]
<kristina>
i hate how the datasheet is clearly redacted.
<kristina>
err, user guide.
<apritzel>
more precise: your own code starts with NS bit cleared/set on the Pine64/RemixMini, respectively
<Kosaka-Honoka>
maybe it's SBROM which clears NS bit
<kristina>
apritzel: i was playing with rpi and there the async bridge forces ARM's AxPROT[1] to high on all outgoing bus transactions :(
libv has joined #linux-sunxi
<apritzel>
kristina: that's a shame
<kristina>
yeah.
<apritzel>
kristina: but maybe this is a programmable behaviour there as well?
<kristina>
nope, the arm_control block suggests that there was intended functionality for it but it doesn't seem to be implemented.
<Kosaka-Honoka>
apritzel: I think more precisely the problem you met on Remix Mini is that you cannot inject not signed code into secure world
<Kosaka-Honoka>
but I think the checksum algorithm in boot0 is naive that we can create checksum collsion in ATF binary?
<kristina>
apritzel: which is why i'm sort of diverting my hobby project attention from my open source VPU fw for rpi to something else, since the hardware is honestly total shit.
<willmore>
Kosaka-Honoka, depeding on the signature they use.
* willmore
gives kristina a cookie.
<apritzel>
kristina: then coming to AW might not have been the wisest decision ;-)
<kristina>
oh?
* willmore
winces
<Kosaka-Honoka>
rpi is some bit shit ;-)
<Kosaka-Honoka>
what I most hate is the USB controller
<Kosaka-Honoka>
but coming to AW is the cheapest decision for ARMv7/8 ;-)
<kristina>
well rpi3 has armv8
<willmore>
ODROID C2?
<Kosaka-Honoka>
well orange pi pc2 is still more cheap than rpi3 ;-)
<kristina>
ewwww signed bootloader.
<kristina>
into the trash it goes.
<Kosaka-Honoka>
and the USB ports is all dedicated on opipc2 ;-)
<kristina>
nvidia jetson tx1 is actually really good.
<apritzel>
kristina: let's put it that way: AW makes very cheap SoCs that do what they are intended to do in the markets that AW wants to see them
<Kosaka-Honoka>
not the shared one on rpi3 ;-)
matthias_bgg has quit [Ping timeout: 240 seconds]
<Kosaka-Honoka>
but some guys at an IRC channel called #linux-sunxi try to abuse the chips to the zones that AW do not market to ;-)
<apritzel>
kristina: which translates into: they might not do what _you_ want ;-)
<apritzel>
Kosaka-Honoka: exactly
<kristina>
on tegra you actually have well documented tz stuff and dev boards like jetson come with all security fuses cleared and you're free to burn your own key if you want, even.
<apritzel>
kristina: sure, but tegra is a different story, also much more expensive
<apritzel>
AW: it's cheap and you get what you pay for ...
<willmore>
What's got a signed bootloader?
<kristina>
apritzel: well still, sun50i has a working GIC and doesn't force axprot[1] to high so that's a start.
<kristina>
bcm2709 is "we could take a week or so to integrate the GIC with our interrupt controller or we could force GICDISABLE to high and call it a day"
<Kosaka-Honoka>
the final story is that on H3/A64/H5 development boards which do not have the Secure Boot feature enabled, you cannot use TrustZone Peripheral Controller ;-)
<apritzel>
kristina: yeah, the missing GIC is the main reason I don't care about RPis
<Kosaka-Honoka>
rpi do not use GIC?!
<Kosaka-Honoka>
what the ****
<willmore>
Just to make sure I'm following along, that's the Generic Interrupt Controller?
<kristina>
apritzel: oh also, on rpi, "secure" sdram that's not accessible from the vpu is somehow accessible from arm as long as it's mapped via iommu so go figure.
<Kosaka-Honoka>
apritzel: so I think rpi cannot use virtualization, right?
<willmore>
I thought the VPU was god?
<kristina>
it can.
<kristina>
willmore: yes.
<kristina>
this is a vpu firmware :P
<apritzel>
Kosaka-Honoka: virtualization works, it's just that both Xen and KVM rely on the virtual GIC features for efficient interrupt virtualization
<willmore>
But you can lcok it out of DRAM that the ARM cores can still access?
<Kosaka-Honoka>
apritzel: so no virtualization implementation is available on bcm2836/7?
<kristina>
VPU has TZPCs basically (TZ is the wrong term here since it's not ARM) that let you protect chunks of RAM.
<kristina>
VPU has secure and insecure modes.
<apritzel>
Kosaka-Honoka: so you can run KVM, but loose quite some performance, especially since a missing VGIC means you can't really use the virtual arch timer as well
<kristina>
that set axprot[1] correctly
<kristina>
ARM sits behind an IOMMU
<apritzel>
Kosaka-Honoka: so the whole GIC gets emulated in userland (QEMU)
<willmore>
kristina, so the VPU starts secure, sets up the IOMMU to allow the ARM core acces to certain memory and then goes insecure and looses access to that?
<apritzel>
Kosaka-Honoka: I think you can't run it on Xen at all, since it doesn't emulate the GIC CPU interface
JohnDoe_71Rus has joined #linux-sunxi
KB3VGW has left #linux-sunxi ["Leaving"]
<Kosaka-Honoka>
I now do not have any BCM ARM SoCs at all ;-)
<kristina>
willmore: firmware can liberally switch between secure/insecure modes, they're mostly for applications/end users.
<kristina>
RPi firmware doens't make use of secure mode that much.
<Kosaka-Honoka>
my rpi3 is given to one friend, and I got a FPGA board (EP4CE22) back ;-)
<willmore>
Kosaka-Honoka, good trade
<willmore>
Also a good trade--pet rock
<kristina>
VPU's SDRAM security is basically enforced by the cache controller of the VPU
<kristina>
instead of SDRAM itself ...
<kristina>
while SDRAM controller doesn't give two shits about axprot[1]
<willmore>
Interesting.
<montjoie>
so anybody here tried optee on AW stuff ?
<willmore>
Thery really did do it their own special way.
<Kosaka-Honoka>
kristina: is the reason why rpis are always at most 1GB memory that the memory is mounted on VPU at 0xc0000000?
<kristina>
Kosaka-Honoka: it's because the system bus on the VPU cannot address more than 1 GB
<kristina>
and ARM is tied to that bastard version of AXI
<willmore>
Of course, 'doing it their own special way' is par for the course. It's confusing when someone actually adheres to the spec.
<kristina>
to start off the bus is 32 bit
<kristina>
sdram controller is 32 bit
<kristina>
err
<kristina>
bus isn't 32 bit actually
paulk-blaze has quit [Quit: Leaving]
<willmore>
"Go read the ARM docs." "No, I want your user guide on how you did it." "No, go read the ARM docs!" "No, really, I need to know how you did it!" "GO READ THE ARM DOCS!"
matthias_bgg has joined #linux-sunxi
<kristina>
bus is 31 bit, i think vpu can only address 30 bits of memory, arm can only address 31 bits of memory because the bus is 31 bit.
<kristina>
for complicated reasons mostly because cpu and vpu on bcm2708 shared a l2 cache.
<kristina>
vpu uses upper bits of the address to determine cache attributes.
<willmore>
Oh, yeah, tiled GPU, sorry, was wondering what crazy person would cache the GPU...
<kristina>
and ram and mmio is mirrored 4 times
<kristina>
the bus is 30 bit
<kristina>
just that upper bits have no effect
<kristina>
wait i'm talking rubbish, uhhh.
<kristina>
not mirrored per se
<kristina>
across the 4gb address space
<willmore>
ARM26 anyone?
<kristina>
top bits define cache stuff
<kristina>
you cannot physically have more than 1GB of ram
<willmore>
write through, write combining?
<kristina>
because you have a 30 bit bus.
<Kosaka-Honoka>
willmore: I thought of "For details about GIC, please refer to the GIC PL400 technical reference manual and ARM GIC Architecture Specification V2.0." -- Chapter 4.9. GIC, Allwinner V3s Datasheet V1.0, page 146 ;-)
<willmore>
Kosaka-Honoka, rare bits of sanity...
<kristina>
#define ALIAS_NORMAL(x) ((void*)(((unsigned)(x)&~0xc0000000)|0x00000000)) // normal cached data (uses main 128K L2 cache)
<kristina>
#define ALIAS_L1L2_NONALLOCATING_READ(x) ((void*)(((unsigned)(x)&~0xc0000000)|0x80000000)) // cache coherent but non-allocating in L1 and L2
<willmore>
That seems to put a nail in a 2GB rpi.
<kristina>
apritzel: did you RE the necessary changes for emif init for A64/H5?
<apritzel>
kristina: what's emif: do you mean the DRAM controller?
<kristina>
since iirc you no longer need libdram.
<kristina>
external memory interface
<kristina>
yeah.
jstein has quit [Read error: Connection reset by peer]
<apritzel>
kristina: the A64 bits have landed in latest U-Boot master branch, the H5 bits are on the list
<apritzel>
kristina: so yeah, I boot all my boards without proprietary software (except BROM, of course) for weeks now
<kristina>
apritzel: yeah but i'm asking if you RE'd them (and based rest on older code provided by AW for sun8i) or did AW actually provide some sort of spec finally?
<apritzel>
kristina: ah, so it was indeed reverse engineering, though based on previous code and comparing register dumps between SoCs
<apritzel>
kristina: and most of the hard stuff was done by jemk
<kristina>
you still need libmali though unless you have access to it and time to figure out how to configure libmali that's configured for a completely different SoC with AW's SoC.
<apritzel>
kristina: usually I tend to turn away from the channel once those four letters appear in that order ;-)
<kristina>
since i found the hard way that if you have the Mali DDK and you build it, it won't actually work unless you configure the userland blob correctly for the target board.
<apritzel>
kristina: read: I don't care about graphics at all, usually, and even if then not about MALI
<kristina>
apritzel: well i'm already preemptively dissapointed with Pine64 :(
<kristina>
broken trustzone :(
<apritzel>
kristina: please don't give up so quickly ..
<apritzel>
kristina: apparently you are only the second or third person to actually care about that ;-)
<kristina>
apritzel: is trusted watchdog timer secure at least?
<Kosaka-Honoka>
libv had did some RE on libMali
<Kosaka-Honoka>
(yes I mean Lima
<kristina>
lima's been dead for ages.
<apritzel>
kristina: sorry to disappoint you on that, but the "secure timer" seems to be as secure as the "secure SRAM" ...
<Kosaka-Honoka>
its techlogical docs still exist
<kristina>
apritzel: ah dang it.
<kristina>
do you know if pine64 exposes the fuse burning pin?
<apritzel>
kristina: but I haven't given up hope on there still being a "enable security bit" somewhere
<apritzel>
kristina: VDD_EFUSE is connected, but that's for reading, I suppose
<kristina>
oh.
<apritzel>
VDD_EFUSEBP is not
<kristina>
is VDD_EFUSEBP the write one?
<apritzel>
we can only guess that the later is needed for writing
<apritzel>
kristina: no documention, remember?
<beeble>
i exposed vddbp, but i have no clue what voltage it requires
<apritzel>
beeble: rumour has it that it's something "normal" (2.5V or 3.3V)
<beeble>
it could also be 1.8 or 1.5 :)
ErwinH has quit [Remote host closed the connection]
<apritzel>
beeble: well, I meant not 12V ;-)
<kristina>
beeble: how did you expose it? bga rework?
<beeble>
i have some ldos on the axp803 left. so i can easily put a wire there
<apritzel>
kristina: beeble makes his own boards ;-)
<kristina>
ah.
<beeble>
but until i have some fuse burn code i have no interest in doing the work
<ssvb>
kristina: we wouldn't be able to properly reverse engineer the DRAM controller without it
<ssvb>
kristina: because we needed some sort of a "reliability" measurement tool to check how different DRAM controller configuration knobs affect its behavior
enrico__ has quit [Remote host closed the connection]
enrico__ has joined #linux-sunxi
<kristina>
ssvb: also didn't someone write an almost working shader compiler?
<kristina>
i do wonder what happened to lima, from what i've seen it seems that it's in a limbo state where new contributors are scared off and existing ones don't do a lot.
<ssvb>
yes, it's in a rather bad shape, and cwabbott never bothered to provide any sort of documentation or work on a test suite
<ssvb>
lima just needs money
<ssvb>
or alternatively motivated and skilled people willing to work on it for free :-)
<ssvb>
you can check the vc4 driver progress just to get an idea about how much work may be required
scream has joined #linux-sunxi
<ssvb>
not to mention that they have full broadcom support and sponsorship
ErwinH has joined #linux-sunxi
<kristina>
ssvb: well VPU stuff wasn't supported by Broadcom.
<ssvb>
but VPU is not needed for 3D, right?
<kristina>
and yet now we have a full toolchain for it, pretty much complete ISA documentation and a firmware that kind of works except when it doesn't.
fkluknav has joined #linux-sunxi
<kristina>
it's not needed for 3D but at the start it was literally a black box.
<kristina>
from there a few people in their spare time actually worked out the ISA.
<ssvb>
yeah, this sounds very similar to the lima project challenges
<kristina>
well no it's not a black box though.
<kristina>
you can RE libMali.
<kristina>
at the start you couldn't RE the RPi firmware because it was a totally different ISA.
<ssvb>
yet your VPU toolchain and firmware have very little practical utility at the moment, just like lima
<ssvb>
or I misunderstand something?
<kristina>
we can boot linux :P
ErwinH has quit [Ping timeout: 240 seconds]
<kristina>
soon we'll have enough for it to work in headless mode once we work out wtf is wrong with USB PHY>
<kristina>
toolchain has massive practical applications.
<kristina>
you can run C/C++ code on the VC4 now.
ErwinH has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 258 seconds]
matthias_bgg has quit [Quit: Leaving]
ErwinH has quit [Ping timeout: 240 seconds]
f0xx has quit [Ping timeout: 255 seconds]
<libv>
ssvb: the fact of the matter is that the only open source gpu projects that went anywhere actually had support
<libv>
freedreno is rob clarks part parttime, part redhat time, and now codeaurora is getting paid to work on it
<libv>
vc4 is paid by broadcom (after i stuck my head out and revealed that their announcement was bullshit)
<libv>
etnaviv is because pengutronix managed to convince a customer to pay for it.
<Kosaka-Honoka>
there's now no vendor that still uses Mali Utgard and want to pay for Lima...
<libv>
Kosaka-Honoka: there never was.
<Kosaka-Honoka>
Exynos has never interest in this?
<libv>
and the one that was interested backed out for political reasons
<Kosaka-Honoka>
?
<Kosaka-Honoka>
political reasons?
<libv>
the head of arm mpd hates everything open source and is squarely against the lima driver
<libv>
many players who depend on the arm mali are not willing to take the risk
<Kosaka-Honoka>
Orz
<libv>
and it is quite amazing how i, yet again, managed to blow open a whole new area for open source graphics drivers, and i made sure that i get even more closed doors everywhere, get a lot of whining and complaining, while opening tons of doors for others
<Kosaka-Honoka>
3d drivers are so complex work that is difficult to be done as parttime
<libv>
nope
<libv>
it just takes time
<Kosaka-Honoka>
yes time
<libv>
and time costs money, in the end
<Kosaka-Honoka>
everyone is lack of time ;-)
<libv>
Kosaka-Honoka: part of the reason as to why i chose to RE a GPU is to prove the idiots wrong who spent years telling me that display is trivial compared to 3d
<libv>
not that i hadn't already proven them wrong on how to tackle the display situation to begin with.
<ssvb>
but display is really trivial
<libv>
if you have a wide enough variety of hardware.
<libv>
and test it thoroughly
<libv>
that's where display is difficult.
<libv>
the amount of hw variation in gpus is minimal
<ssvb>
well, the problem is that there are still no established APIs and interfaces which fully support all the necessary features
<libv>
don't tell me about that.
leviathan_ has joined #linux-sunxi
<libv>
having come up with structured display driver development and even the term modesetting itself...
<libv>
and having been blackballed at pretty much every company that does anything with display drivers...
<ssvb>
the hardware video decoders (cedrus) are also plagued by this, even to a larger extent
apritzel has left #linux-sunxi [#linux-sunxi]
<kristina>
libv: the VPU reverse engineering project wasn't funded by anyone.
<ssvb>
it's possible to drive the hardware, but it's difficult to fit the decoder into all the software frameworks
<kristina>
nor did we have the luxury of even being able to reverse engineer the actual binaries at first.
<libv>
kristina: the REing, no, free-electrons did turn up one day with a jobstudent to write the code
<kristina>
libv: huh? all of the VPU related stuff wasn't financed.
<kristina>
my LLVM port wasn't financed (though i'm very experienced with LLVM), Julian's toolchain wasn't financed etc.
<libv>
kristina: for sunxi cedrus?
<ssvb>
kristina: I'm not sure it is really something to be proud of
<kristina>
ssvb: what do you mean?
<libv>
or are you talking perchance of vc4?
<kristina>
yes VC4 VPU ISA.
<ssvb>
kristina: I mean that it would be best if you could be sponsored, together with lima, cedrus and all the other free software developers
<kristina>
mgottschlag, herman and phire did most of the initial ISA RE work.
nove has joined #linux-sunxi
<kristina>
the VC4 community then kind of died, then i revived it and now we made huge progress.
<kristina>
and libv you were wrong about it dying without BCM's support, it did die for like 2 months because i was busy, but now we have other interested contributors and i do stuff from time to time, we (well just me) actually understand how power management works on these chips etc.
<ssvb>
kristina: if you are doing something for free and are bragging about this, then it spoils the end users because they now expect to get everything without paying, together with full support and ass-wiping :-)
paulk-collins has joined #linux-sunxi
<kristina>
we do it because it's interesting.
<kristina>
me and julian have day jobs.
<ssvb>
I'm sure that you could do some free lima work too
<ssvb>
rather than complaining about it
<kristina>
i never complained, i just made a comparison, i think you were the one that complained.
<ssvb>
did I?
<ssvb>
I just explained what's going on
<ssvb>
so that you have realistic expectations
<kristina>
you complained that it's dead because of lack of funding, i compared it to our little VC4 community.
<ssvb>
I never said that it is dead
<kristina>
that has zero support from BCM.
<kristina>
aside from "don't release/make cracks for the codecs and we'll leave you be" from them.
<kristina>
i do what i find interesting, graphics isn't something i'm good at or that i find interesting.
Nyuutwo has joined #linux-sunxi
<kristina>
you could have just pasted that from your scrollback buffer :S
BenG83 has joined #linux-sunxi
<ssvb>
I'm sure that the lima shader compiler can be improved a lot, if somebody puts some work into it
<libv>
kristina: i just know that ever since i started working for SuSE, and when we freed ATI, i had no cycles left in my spare time to work on things
<libv>
in that spare time, i have to do other things, like cycling or playing with legos
<kristina>
ssvb: it could be, if someone was interested in doing so.
<kristina>
(or paid to)
<ssvb>
the biggest problem is that 3D drivers have little practical use in the GNu/Linux software stack
Andy-D has joined #linux-sunxi
<ssvb>
this alone kills all the motivation to do a lot of unpaid work
<kristina>
i didn't do anything because i care about free software.
<kristina>
i did it because it was interesting to me.
<kristina>
personally.
<kristina>
the QPU shit is paid by BCM, correct, libv.
jernej has joined #linux-sunxi
<ssvb>
all the interesting lima RE work is mostly done, only the boring part of implementing an actual GL driver remains :-)
<kristina>
ssvb: well the whole thing that led to an open source firmware is combined work of around 8 or so unpaid individuals.
<libv>
kristina: it happens, and kudos to you guys for keeping it up, but it has become extremely rare.
<libv>
mailing list activity on weekends is a good indicator
<libv>
in the early days, projects like xorg and even linux-sunxi had a lot of ml activity on the weekend
<libv>
this has changed.
vagrantc has joined #linux-sunxi
<kristina>
herman, phire, mgottschlag for reverse engineering a large subset of the ISA, herman for reverse engineering the rest once broadcom accidentally leaked a bunch of stuff in their source release, someone who did the ACK C compiler for VC4/me who did the LLVM backend and most of all Julian who did the most complete and amazing port of GCC including C++/C/asm as well as writing a testsuite, me who RE'd the initial DRAM initialization code as well as ARM bringup, and
<kristina>
later clock/power stuff, alyssa who worked on getting linux to boot without stock firmware.
<kristina>
libv: ah, i mostly advocate against using mailing lists.
<kristina>
ssvb: what's with linking web logs of this channel? :x
<kristina>
you could just copy and paste a line.
<kristina>
if you want to quote me.
<kristina>
oh right david given did the ack port.
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
<jbrown>
(hi!)
<kristina>
hi julian :D
ninolein has quit [Remote host closed the connection]
* jbrown
had been hanging around here & on the lima channel for years, it was about time I did something. Heh.
<kristina>
jbrown: but see, my point is, it is possible to get shit done without financial sponsorship.
<jbrown>
well yeah, depending on workload, motivation, and desire to have a "life"...
<kristina>
overall, the VC4 VPU related stuff is probably like $200k+ of unpaid work done by volunteers.
ErwinH has joined #linux-sunxi
<maz>
kristina: you definitely underestimate the cost of a good engineering team... ;-)
<libv>
quite.
<ssvb>
kristina: yeah, the lima project has proven this too, because it reached some important milestones without sponsorship
<jbrown>
the rpi thing was helped quite a lot by the BCM driver stack source drop, I think. Mali hasn't had that.
<jbrown>
(but maybe it doesn't need it)
<libv>
i was doing quite some of it while either bored at the winding down nokia, or jobless at home
<ssvb>
kristina: but the point is that this is not normal, and people prefer to be paid for their work
<libv>
connor did so (and amazingly so) as a highschool student bored with highschool
<kristina>
ssvb: i think that is wrong, people want rewards for their work, not always monetary.
<maz>
ssvb: depends. doing unpaid work has the advantage of doing exactly what you want, and not necessarily what you're told to do...
<libv>
kristina: i and my family, need to eat and have a roof over our heads
<maz>
ssvb: and as kristina puts it, there is more to life than just cash.
<ssvb>
kristina: unless they won a lottery, inherited a fortune or have a job which leaves enough free time for hobby projects (and the job contract does not forbid this) :-)
<libv>
and the time that i got some applause as a reward are long gone
<libv>
now people just whining and trash.
<libv>
s/whining/whine/
ErwinH has quit [Ping timeout: 252 seconds]
<libv>
and as said, lima closed a lot of doors for me, again.
<kristina>
libv: in fact a lot of my hobby work got me jobs at really great places.
<maz>
+1
<libv>
depends on the hobby work you did
<libv>
and yes, i did get the position at SuSE because egbert was the sole person to acknowledge my modesetting pioneering
* jbrown
guesses that the rpi may have cannibalised a lot of the interest in other systems
<jbrown>
by being cheap, linux-first & mostly working, despite the non-freeness that nobody cares about in practice
<jbrown>
oh well.
tkaiser has joined #linux-sunxi
<tkaiser>
The wiki page for Orange Pi Plus 2 is a real mess and got even worse with latest change (recommending to use the wrong defconfig for this board)
<tkaiser>
The only differences to OPi Plus are different PCB layout, twice the DRAM and eMMC. From the software perspective pretty identical to the Plus
<tkaiser>
Any objections against deleting this page or better make it a redirect to OPi Plus page pointing to #Variants ?
<Kosaka-Honoka>
machid and bootm_boot_mode is what I know.
lkcl has quit [Ping timeout: 240 seconds]
<Kosaka-Honoka>
the bsp kernel on v3s can boot, but cannot use fb
<ssvb>
well, on H3 it can
<tkaiser>
Kosaka-Honoka: no idea about display stuff. But at least it's reported that mainline u-boot + BSP kernel works. Otherwise Armbian forum would be blown up already
<ssvb>
Kosaka-Honoka: do you have some V3S instructions?
<apritzel>
I wrote something with libusb_hotplug_register_callback() yesterday
<apritzel>
neat little tool, gets ARRIVE and LEFT messages delivered from libusb
<apritzel>
and then launches the command given on the command line
<apritzel>
I was wondering if that would be worth integrating into sunxi-fel
<apritzel>
because that's how I use it: sit there until the FEL device appears and then start uploading
<NiteHawk>
interesting idea
<apritzel>
in the moment it's an extra tool (UNIX rules), but it's relatively simple and just using libusb, which we have anyway
<apritzel>
NiteHawk: together with the neat U-Boot environment feature that lets me bootstrap an eMMC / SPI flash board automatically
nove has quit [Quit: nove]
<apritzel>
I transfer SPL, ATF, U-Boot plus an image into DRAM and use "mmc write ..." to flash the image onto the board, then reboot
ErwinH has joined #linux-sunxi
<apritzel>
it's all on one (long) command line
<NiteHawk>
nice :)
<ssvb>
apritzel: I have an unfinished local "fel-sever" branch, which implements a daemon which serves the right U-Boot image depending on the SID value
<beeble>
while ! lsusb -d 0483:df11 > /dev/null
<beeble>
damn phone paste
<beeble>
so if you are not against scripting...
<NiteHawk>
lsusb -d sets exit code? cute.
nikre has joined #linux-sunxi
<nikre>
ls
<apritzel>
beeble: totally not, indeed it sounds good enough for that purpose
ErwinH has quit [Ping timeout: 240 seconds]
<apritzel>
ssvb: yeah, I was thinking about something as well
<nikre>
hey, can i use opi one armbian legacy on opi pc just changing the fex file? is there any other difference on the image files?
<apritzel>
ssvb: so are you waiting for USB devices to appear as well?
<apritzel>
ssvb: or is that attached to some udev rule?
<ssvb>
apritzel: yes, waiting via lubusb
<ssvb>
*libusb
ErwinH has joined #linux-sunxi
ErwinH_ has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
Ntemis has quit [Read error: Connection reset by peer]
bonbons has quit [Quit: Leaving]
ErwinH_ has quit [Ping timeout: 252 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
IgorPec has quit [Ping timeout: 248 seconds]
nikre has quit [Quit: Leaving]
paulk-collins has quit [Remote host closed the connection]
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
scream has quit [Remote host closed the connection]
GrimKriegor has joined #linux-sunxi
jernej has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
GrimKriegor_ has quit [Ping timeout: 255 seconds]
jernej has quit [Remote host closed the connection]
<willmore>
beeble, please put a sleep in that loop. ;)