Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
ErwinH has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
Mr__Anderson has quit [Quit: Leaving.]
<fatius> apritzel: FYI, linux-next fixed it for me.
ErwinH has quit [Ping timeout: 252 seconds]
BenG83 has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
paulk-collins has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
Wizzup has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
interrobangd has quit [Ping timeout: 255 seconds]
ErwinH has quit [Ping timeout: 252 seconds]
ErwinH has joined #linux-sunxi
<willmore> Yay
vishnup has joined #linux-sunxi
ErwinH has quit [Ping timeout: 258 seconds]
jstein has quit [Ping timeout: 260 seconds]
olerem has quit [Ping timeout: 248 seconds]
jernej has quit [Ping timeout: 256 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
marcan has quit [Ping timeout: 252 seconds]
marcan has joined #linux-sunxi
GrimKriegor has joined #linux-sunxi
GrimKriegor has quit [Read error: Connection reset by peer]
GrimKriegor has joined #linux-sunxi
vishnup has quit [Ping timeout: 240 seconds]
GrimKriegor_ has joined #linux-sunxi
GrimKriegor has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
terra854 has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Wizzup has joined #linux-sunxi
apritzel has quit [Quit: Leaving.]
ErwinH has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
lkcl has quit [Ping timeout: 258 seconds]
ninolein has quit [Ping timeout: 245 seconds]
ninolein has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
vagrantc has quit [Quit: leaving]
dr1337 has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
meridion has quit [Ping timeout: 240 seconds]
Wizzup has quit [Ping timeout: 240 seconds]
fatius has quit [Remote host closed the connection]
SJRvanSchaik has quit [Ping timeout: 240 seconds]
SJRvanSchaik has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
ErwinH has joined #linux-sunxi
berkutta_ has joined #linux-sunxi
berkutta has quit [Ping timeout: 272 seconds]
ErwinH has quit [Ping timeout: 240 seconds]
alsy has quit [Read error: Connection reset by peer]
terra854 has quit [Quit: Connection closed for inactivity]
IgorPec has joined #linux-sunxi
ErwinH has joined #linux-sunxi
pg12 has quit [Ping timeout: 245 seconds]
ErwinH has quit [Ping timeout: 240 seconds]
pg12 has joined #linux-sunxi
ErwinH has joined #linux-sunxi
f0xx has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
victhor has quit [Ping timeout: 252 seconds]
ErwinH has joined #linux-sunxi
lkcl has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
terra854 has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
scream has joined #linux-sunxi
<montjoie> raaah stmmac load on pine64, but never call open
<montjoie> it detect only half the device without error
cnxsoft has quit [Remote host closed the connection]
<wens> just thought of a talk topic we could do as a community: "identifying and supporting "X-compatible" hardware blocks"
<wens> such as the designware stuff, and the new wifi chip from allwinner
jernej has joined #linux-sunxi
lynxis has quit [Ping timeout: 260 seconds]
<KotCzarny> plot twist: arm cores are from designware too
<KotCzarny> bigger plot twist: designware owns arm
<KotCzarny> biggest plot twist: allwinner owns designware
scream has quit [Remote host closed the connection]
<wens> huh
cnxsoft has joined #linux-sunxi
ErwinH has joined #linux-sunxi
freemangordon has quit [Remote host closed the connection]
freemangordon has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
jernej has quit [Ping timeout: 240 seconds]
<beeble> KotCzarny: showerthoughts?
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 256 seconds]
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
ErwinH has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<KotCzarny> beeble: nah, just got up
msevwork has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
ErwinH has joined #linux-sunxi
<beeble> ah, same timezone as me. thought you are living somewhere else
<KotCzarny> yeah. .eu
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
Wizzup has joined #linux-sunxi
massi has joined #linux-sunxi
AneoX__ has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
AneoX_ has quit [Ping timeout: 245 seconds]
terra854 has joined #linux-sunxi
florianH has joined #linux-sunxi
reinforce has joined #linux-sunxi
kristina has joined #linux-sunxi
<kristina> hi, a few questions, do allwinner SoCs generally not enforce a chain of trust for booting EL3 stuff?
<kristina> (looking at sun50i specifically)
BenG83 has quit [Ping timeout: 240 seconds]
<kristina> and is there an open spl, from quick reading it seems that emif/sdram init code is still proprietary, similiar to intel fsp.
<Kosaka-Honoka> there's now open sdram init code developing and usable
<kristina> oh, as part of uboot? can someone link me the fork of uboot that supports that?
<kristina> is there any documentation for features like trustzone protection controllers or anything?
<kristina> or at least register maps.
qschulz_ has joined #linux-sunxi
qschulz_ is now known as qschulz
<tuxillo> hi
leviathan_ has joined #linux-sunxi
<kristina> Kosaka-Honoka: does the h5 emif code also work on a64?
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 255 seconds]
<Kosaka-Honoka> kristina: plz look at the commit history ;-)
<Kosaka-Honoka> at first the A64 support is added
<Kosaka-Honoka> then H5
leviathan_ has quit [Remote host closed the connection]
Andy-D has quit [Ping timeout: 245 seconds]
<kristina> is the sun50i trustzone controller documented anywhere?
bonbons has joined #linux-sunxi
<montjoie> kristina: you can read the datasheet, SMC and SMTA is documented
matthias_bgg has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
leviathan_ has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
<kristina> also, this seems weird, how does sun50i switch to ARM64 state?
<kristina> since bootrom starts in aarch32.
<kristina> does it soft reset the cores?
<kristina> i'm looking at the trusted fw atm and it looks like it's doing something along those lines.
leviathan_ has quit [Remote host closed the connection]
jstein has joined #linux-sunxi
LargePrime has quit [Ping timeout: 240 seconds]
enrico__ has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 240 seconds]
AneoX__ has quit [Ping timeout: 248 seconds]
leviathan_ has joined #linux-sunxi
leviathan_ has quit [Remote host closed the connection]
<kristina> oh it warm resets the core using RMR.
<montjoie> yeah pine64 booted with stmmac
<plaes> kristina: o/ you're the person working on raspi alternative fw?
<kristina> are there any docs for efuses on sun50i?
<kristina> or any other interesting features that are not in the user manual.
<plaes> kristina: we sadly have only u-boot code dumps :(
<kristina> plaes: yes that would be me :P
<plaes> great work :)
<kristina> got a Pine64 because it has proper trustzone peripherals and support.
<kristina> so there isn't any source of information on the efuses on A64?
<plaes> apritzel knows better, because he is the one who's been playing with arm64
<plaes> you might want to shoot email to list and CC him
<kristina> oh.
<kristina> when i said A64 i meant sun50i but typing sun50i every time is annoying because it's a weird thing to type out.
terra854 has quit [Quit: Connection closed for inactivity]
<ErwinH> Finaly, got my H5 booting from SD-card with FIT and open dram.
<kristina> rpi has a much simpler EMIF controller than sunxi ones, https://github.com/christinaa/rpi-open-firmware/blob/master/sdram.c
<kristina> very easy to initialize and configure.
<plaes> ddr2?
<kristina> LPDDR2 yes.
<kristina> you can look at the code, it does stuff like MR register reads/writes to query ram size etc.
BenG83 has joined #linux-sunxi
<montjoie> ouch sun8i-stmmac perf:( (450 vs 756 and 140 vs 500)
<kristina> what's sun8i-stmmac?
<plaes> ethernet
<montjoie> the ethernet driver for A64/H3/A83T/H5/etc...
<montjoie> glued to stmmac
<kristina> is there a bare metal driver for hdmi/framebuffer somewhere?
<plaes> kristina: u-boot sources
<kristina> oh neat.
bugzc has quit [Ping timeout: 245 seconds]
<kristina> sunxi_display.c?
f0xx has joined #linux-sunxi
libv has quit [Ping timeout: 240 seconds]
libv has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 240 seconds]
lkcl has quit [Ping timeout: 240 seconds]
fkluknav has joined #linux-sunxi
lkcl has joined #linux-sunxi
LargePrime has joined #linux-sunxi
meridion has joined #linux-sunxi
speakman_ has quit [Ping timeout: 256 seconds]
paulk-blaze has joined #linux-sunxi
terra854 has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 240 seconds]
libv has quit [Ping timeout: 256 seconds]
libv has joined #linux-sunxi
paulk-blaze has quit [Remote host closed the connection]
paulk-blaze has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: .]
paulk-blaze has quit [Remote host closed the connection]
paulk-blaze has joined #linux-sunxi
Nyuutwo has quit [Quit: No Ping reply in 180 seconds.]
[Awaxx] has quit [Ping timeout: 258 seconds]
Nyuutwo has joined #linux-sunxi
[Awaxx] has joined #linux-sunxi
paulk-blaze has quit [Remote host closed the connection]
paulk-blaze has joined #linux-sunxi
vishnup has joined #linux-sunxi
zumbi has quit [Ping timeout: 245 seconds]
zumbi has joined #linux-sunxi
<montjoie> apritzel, if you want to test
<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.
<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_L1_NONALLOCATING(x) ((void*)(((unsigned)(x)&~0xc0000000)|0x40000000)) /
<kristina> #define ALIAS_DIRECT(x) ((void*)(((unsigned)(x)&~0xc0000000)|0xc0000000)) // uncached
<kristina> so go figure
<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
<beeble> maybe v2 :)
speakman has joined #linux-sunxi
speakman has joined #linux-sunxi
speakman has quit [Changing host]
<kristina> beeble: you should try burning random fuses :D
<beeble> 2^fusenumbers
<kristina> 2^fuseNumbersThatWouldBrickYourBoard
<kristina> beeble: did AW not provide docs about fuses since you sourced their chips?
<ssvb> kristina: AFAIK, the same libmali blobs work on different SoCs, at least they could be swapped between Allwinner and Samsung Exynos chips
<ssvb> kristina: but it's just usually forbidden by EULA, so you have legal problems rather than technical
<beeble> kristina: you get pretty much the same stuff that you see leaked on the net
<Kosaka-Honoka> but for r6p0 the EULA is eased
fkluknav has quit [Ping timeout: 252 seconds]
<kristina> beeble: do you need to pay separate for security features/documentation?
<kristina> and sign separate NDAs?
<beeble> usually they tell you to go to one of their oems
<ssvb> kristina: as for the lima driver, it has been extremely useful as a stress test for the DRAM reliability - https://github.com/ssvb/lima-memtester/
<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> ssvb: ah did that bug never get fixed?
<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> alright, you said bad shape, my bad.
<ssvb> yes, the shader compiler
<ssvb> and btw, this channel is logged - https://irclog.whitequark.org/linux-sunxi/2017-01-17#18647765;
<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 :-)
<libv> hah
<libv> what happened to mali being a high priority project.
<libv> it's high time i kick some fsf ass
<kristina> yeah sadly i never written a line of GLSL in my life so i'm hardly qualified to write opengles drivers.
<libv> as those wankers also were nowhere to be seen when i was fighting for proper C code for ati display hw
<ssvb> kristina: BTW, it's great that you give proper credit to the people you based your work on - https://irclog.whitequark.org/linux-sunxi/2017-01-17#18648233;
<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 ?
popolon has quit [Quit: WeeChat 1.4]
mnr has joined #linux-sunxi
<libv> jbrown: it also triggered a lot of interest in cheap devel boards
<KotCzarny> libv: interest was always there, just no hw
<libv> could be, but it was like the iphone for the smartphone market
<KotCzarny> iphone is reverse of cheap
<libv> indeed, but it did blow that market open
enrico__ has quit [Quit: Bye]
<Kosaka-Honoka> tkaiser: have you used mainline u-boot with bsp kernel on H3?
<Kosaka-Honoka> can disp2 work in such a situation?
<Kosaka-Honoka> (oh I am just MoeIcenowy ;-)
<ssvb> Kosaka-Honoka: the BSP kernel works fine with the mainline U-Boot on H3, unless something has changed recently
<Kosaka-Honoka> what changed recently?
ErwinH has joined #linux-sunxi
<Kosaka-Honoka> recently on V3s bsp kernel+mainline u-boot combination met some problem
<Kosaka-Honoka> with mainline u-boot bsp kernel cannot use display
<ssvb> have you checked https://linux-sunxi.org/Xunlong_Orange_Pi_PC#Sunxi.2FLegacy_Kernel ?
<ssvb> this has worked fine for ages
<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?
<tkaiser> Speaking about H3 of course
ErwinH has quit [Ping timeout: 240 seconds]
<ssvb> Kosaka-Honoka: is your new irc nick inspired by https://myanimelist.net/character/46171/Honoka_Kousaka ? are you going to keep it this way?
lkcl has joined #linux-sunxi
massi has quit [Quit: Leaving]
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
tkaiser has quit [Ping timeout: 240 seconds]
|Jeroen| has joined #linux-sunxi
ninolein has joined #linux-sunxi
bugzc has joined #linux-sunxi
f0xx has joined #linux-sunxi
LargePrime has quit [Read error: Connection reset by peer]
LargePrime has joined #linux-sunxi
LargePrime has quit [Ping timeout: 255 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 248 seconds]
terra854 has quit [Quit: Connection closed for inactivity]
LargePrime has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
vagrantc has quit [Quit: leaving]
leviathan_ has quit [Remote host closed the connection]
fkluknav has quit [Ping timeout: 240 seconds]
ninolein has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
LargePrime has quit [Read error: Connection reset by peer]
lemonzest has quit [Quit: Leaving]
ErwinH has joined #linux-sunxi
kivutar has quit [Ping timeout: 258 seconds]
ErwinH has quit [Ping timeout: 240 seconds]
LargePrime has joined #linux-sunxi
mnr has quit [Quit: leaving]
LargePrime has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
ErwinH_ has joined #linux-sunxi
<apritzel> tkaiser: Re: deleting OrangePi Plus 2 page: I was wondering the same at the weekend
<apritzel> and regarding the different defconfig: that was one observation from a user: switching to that defconfig brought Ethernet to life
<apritzel> but I totally agree that defconfig and DT should be the same for the two boards
ErwinH_ has quit [Ping timeout: 240 seconds]
|Jeroen| has quit [Quit: dada]
kivutar has joined #linux-sunxi
ninolein has joined #linux-sunxi
lkcl has quit [Ping timeout: 256 seconds]
LargePrime has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
reinforce has quit [Quit: Leaving.]
<apritzel> ssvb: didn't you once mention a possibility to improve FEL transfer speed on the A64?
<apritzel> ssvb: was that by setting some clock to a higher rate?
<apritzel> ssvb: I tried AHB2 to 300 MHz, but that didn't change anything
<apritzel> ssvb: before that I put AHB1 back to 200 MHz, which improved it from 400 KB/s to 500 KB/s
yann-kaelig has quit [Quit: Leaving]
<ssvb> apritzel: I tried to do some quick tests on A64, but did not get any noticeable transfer speed improvement - https://linux-sunxi.org/FEL/USBBoot#SoC_support_status
<ssvb> the 500MB/s speed on A64 is similar to what we have on A31 (I don't know what is limiting it there)
<ssvb> it did not look like enabling MMU and write combining was providing any speed benefits on A64
<apritzel> ssvb: OK, thanks a lot, so no low hanging fruit here ;-)
<apritzel> ssvb: does the H3 give around 500KB/s without the MMU as well? The 910 w/ MMU sound tempting ...
<apritzel> s/910/960/
<ssvb> maybe even much lower
raknaz[m] has joined #linux-sunxi
<ssvb> apritzel: this commit message has the information about FEL transfer speeds on H3 - https://github.com/linux-sunxi/sunxi-tools/commit/c32eeb88ff6d90f7b0c4cc64ee0719b2f944aa80
<apritzel> ssvb: ah thanks, I was trying to check the Wiki history, but the data for H3 came in with the first version of the table
<ssvb> I would guess that without the MMU enabled, the FEL transfer speed on H3 would be ~190KB/s just like on A83T
<NiteHawk> should be relatively easy to check - simply comment out the .mmu_tt.addr in soc_info.c?
<apritzel> NiteHawk: was just looking into this, yes ;-)
<apritzel> oh btw: does anyone know of a simple userland tool to wait for an USB device to appear?
<beeble> bash + lsusb
<beeble> check for vid pid
<NiteHawk> udev rule?
<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. ;)
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 248 seconds]
ErwinH has joined #linux-sunxi
vishnup has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]