<vagrantc>
oh, didn't know github exposed keys that way
<vagrantc>
smaeul: thanks.
Mangy_Dog has quit [Remote host closed the connection]
<vagrantc>
how can i detect if crust is running?
<vagrantc>
tried suspending the pinebook, but no keys seemed to wake it up and the power key seemed to hard-reset it.
<smaeul>
vagrantc: TF-A will print the message "PSCI: Suspend is available via SCPI" during boot
<smaeul>
and /sys/power/mem_sleep will contain the "deep" option
<smaeul>
both the power button and the lid switch should wake the pinebook up. since the keyboard is USB, it will not
<vagrantc>
cat /sys/power/mem_sleep
<vagrantc>
s2idle [deep]
<vagrantc>
really should reconfigure this to have a serial console ... or maybe i should try on a pine64+
<smaeul>
if the pinebook reboots immediately when you wake it, that sounds like missing the clock patches. you can try booting with `clk_ignore_unused`
<vagrantc>
oh, yeah, definitely nothing else is patched
<smaeul>
what is your kernel version?
<vagrantc>
5.10
<vagrantc>
could probably try 5.12 without a lot of work
<vagrantc>
5.10.40, to be more specific
<smaeul>
yeah you need at least 5.12 to not break Linux's RSB controller driver after a suspend/resume cycle
<vagrantc>
oh, ok
<vagrantc>
so the clk_ignore_unused is moot?
<smaeul>
if you use 5.12 and clk_ignore_unused suspend/resume should work without patches
<vagrantc>
ok!
<vagrantc>
thanks for your help!
<smaeul>
the only functioning wakeup source will be the PMIC (so: charger insertion or power button). the lid switch would work with v5.13
<vagrantc>
with or without clk_ignore_unused?
<smaeul>
clk_ignore_unused will always be needed for the forseeable future unless you patch Linux
<vagrantc>
got it
tuxd3v has quit [Ping timeout: 480 seconds]
tuxd3v has joined #linux-sunxi
<vagrantc>
no luck so far ... hrm.
<vagrantc>
no, actually, it successfully resumes, just the LCD doesn't come back
<warpme_>
interesting is that i can watch video on h616 with ffmpeg decoding to gl output. but ui is still all black
choozy has joined #linux-sunxi
<warpme_>
also i.e. i can launch xterm in x11 rendering via gl glamour on x616 g31 - but there is interesting issue with cursor plane.. see http://warped.inet2.org/h616.mov
<jernej>
warpme_; there is no cursor plane, unless you added some hack to driver
<apritzel>
can somebody tell me what the sense in a PRNG in hardware is?
<tuxd3v>
its a lower version of a TRNG
<apritzel>
lower? I know what a PRNG is, I am wondering if it is useful to have it as a hardware device
<tuxd3v>
well its better than nothing :)
<apritzel>
tuxd3v: ??? AFAIK there is a superb PRNG in the kernel
<tuxd3v>
sun8i-SS should bring PRNG support, and I have it activated..
<tuxd3v>
but it gives error on 5.10.41
<apritzel>
I understand this, but I wonder if it is really useful
<tuxd3v>
its better than not having it and relying in /dev/urandom
<apritzel>
why? I seriously doubt this
<tuxd3v>
urandom is competly in the processor
<tuxd3v>
PRNG offloads that
<apritzel>
offloads?
<tuxd3v>
the entropy generation
<apritzel>
I understand that people *believe* "having something in hardware" is better, but I wonder if this is really true
<apritzel>
the CPU cores run at a GHz, back-to-back MMIO is limited to about 5 million reads per second
<apritzel>
unless the security engine is connected via a faster bus
<tuxd3v>
yet is enough to generate entropy, its not Ideal for a high sppeed device but with cortex a7 prng is ok, better than nothing..
<tuxd3v>
now my point is why it doesn't work :/
<apritzel>
I would say a PRNG does not generate entropy
<apritzel>
a TRNG does
<tuxd3v>
I have:
<tuxd3v>
CONFIG_CRYPTO_DEV_SUN8I_CE_PRNG=y
<tuxd3v>
CONFIG_CRYPTO_DEV_SUN8I_CE_TRNG=y
<tuxd3v>
so it should have at least PRNG
<apritzel>
tuxd3v: I get that you have problems, but I wonder why you care?
<tuxd3v>
I care because I wanted it weorking :)
<tuxd3v>
working*
<apritzel>
but why?
<apritzel>
do you really trust a PRNG implemented by Allwinner?
<tuxd3v>
I don't really trust a PRNG
<tuxd3v>
but I trust it enough, for the processing power cpu has..
<apritzel>
you can trust the one implemented in the kernel, which has been checked many times
<tuxd3v>
if they were cortex a72 I would rewuire a TRNG
<tuxd3v>
require
<tuxd3v>
but for cortex A7 is good enough
<apritzel>
I don't understand what this has to do with the CPU
<apritzel>
if you need real entropy, a TRNG gives that to you
<apritzel>
to seed the in-kernel PRNG
<tuxd3v>
what it the in kernel solution you talk about what is the config?
<tuxd3v>
/dev/urandom
<apritzel>
the normal in-kernel PRNG, exposed via /dev/urandom
<apritzel>
which is a state of the art software PRNG, checked with scrutiny by many people
<tuxd3v>
yes but it used more cpu
<apritzel>
that's the question I have: do you *really* gain something by using the hardware?
<apritzel>
I understand that people *hope* for that, but I wonder if someone has looked at this and benchmarked this
<tuxd3v>
if a device has PRNG or preferably TRNG I will try to use it :)
<apritzel>
I hope you know what you are doing ...
<apritzel>
there are examples of things going horribly wrong due to flawed PRNG implementations, and those were software one which could be analysed
<apritzel>
so I wonder if any perceived performance benefit of a hardware PRNG really outweighs the risk of having a accidentally or even deliberately broken hardware PRNG
<jakllsch>
aren't PRNGs broken by definition?
<apritzel>
jakllsch: not really if you know what to expect *and* you reseed them regularly
<apritzel>
ah, the sun8i PRNG apparently uses DMA, so it might indeed be much faster
<apritzel>
tuxd3v: I am still wondering why you need that many random numbers that it would matter
<apritzel>
are you doing Monte Carlo simulations?
<tuxd3v>
sun8i-ce 1c15000.crypto: TRNG not supported
<apritzel>
tuxd3v: was your device the FriendlyARM NanoPi Air? The one were you saw the Bluetooth problem?
<tuxd3v>
yes it is :)
<tuxd3v>
the bluetooth problem is completely solved, with your discovery.. ;)
<apritzel>
tuxd3v: well, I wouldn't say "solved", we just hacked around this
<tuxd3v>
indeed. but it works always :)
<apritzel>
I just writing an email to the list, to tap into the crowd wisdom and get a proper fix
<tuxd3v>
it was a good work, that unlocked Bluetooth in lots and lots of devices, even thought is a workaround.. but now bluetooth just works out-of-the-box :)
chewitt has joined #linux-sunxi
<apritzel>
well, "out of the box" is not true: you need to either define this Kconfig symbol and revert that commit or something
<apritzel>
so out-of-the-box kernels will still fail
<tuxd3v>
yeah, its true that you need that kconfig option..but at least we have a option, before we didn't knew about that, and I have spoken to a lot of people with same bluetooth problems in a plethora of boards..
<apritzel>
well, mail sent, lets see ...
Danct12 has quit [Quit: Quitting]
<tuxd3v>
nanopi NEO plus2, is another device were I notice the problem, but there are a lot..
<tuxd3v>
in bananapi m2 zero, it sometimes work sometimes not...it will be my next check, using CONFIG_SERIAL_8250_16550A_VARIANTS in a kernel for it, so see if it solves, but I am sure it will..
Danct12 has joined #linux-sunxi
pentabarf has joined #linux-sunxi
Daaanct12 has joined #linux-sunxi
Danct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Ping timeout: 480 seconds]
ats_ has joined #linux-sunxi
ats has quit [Ping timeout: 480 seconds]
pentabarf has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
ats_ has quit []
Danct12 has joined #linux-sunxi
ats has joined #linux-sunxi
vagrantc has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
Daanct12 has quit [Remote host closed the connection]
<apritzel>
vagrantc: very nice! What's after U-Boot? some generic Debian (installer)?
<vagrantc>
apritzel: so far i've just booted an OS, no installer
<vagrantc>
and Guix System ... working on Debian now
<apritzel>
vagrantc: btw: I have some U-Boot patch to differentiate between Pine64-LTS and Pinebook, in one SPL/U-Boot proper image
<apritzel>
vagrantc: what is your layout for the SPLs? which one is at which offset?
<vagrantc>
apritzel: ah, that would be nice!
<vagrantc>
apritzel: i used the "defaults", except for 2112 for the rockchip TPL/SPL ...
<vagrantc>
apritzel: so pinebook SPL at 16, u-boot.itb at 80 (i *think*), pinebook-pro-rk3399 TPL/SPL at 2112 and u-boot.itb at 16384
<vagrantc>
apritzel: i presume your combined image would also work for pine64+ ?
<apritzel>
Pine64+ uses a different DRAM, which is a bit more tricky
<vagrantc>
ah
<apritzel>
it actually allows a safe detection, since you can try both LPDDR3 and DDR3, and then know which board you have
<vagrantc>
apritzel: those patches likely upstreamable?
<apritzel>
so the Pinebook vs Pine64-LTS detection is pretty small, and we have similar detection already (for the different Pinephone models)
<apritzel>
the problem with the dual DRAM is that it needs more code, which breaks the SPL limit, I think
<smaeul>
crazy idea: get around the 32k size limit on A64 by switching everyone to TOC0
<apritzel>
smaeul: you mean secretly, but upstreaming a patch that burns the fuse? ;-)
<apritzel>
smaeul: but actually there are less drastic solutions: either use a 32-bit SPL, or bite the TPL bullet
<apritzel>
(or squeeze the SPL really hard to get some more bytes from it)
<smaeul>
not secretly, no. just that the secure mode is well-characterized enough that it's "a possible solution" and not "you will brick your board!!!111!!"
<smaeul>
but now that you mention it, you could embed an eGON fuse-burner image at 128K inside a TOC0 at 8K and the user wouldn't know the difference
<apritzel>
smaeul: cheeky!
<apritzel>
smaeul: but a more practical hack would be to support both secure and non-secure boards in one image with this method
<smaeul>
something like putting code in the eGON to load the TOC0 from disk, and putting the DRAM init in TOC0?
<smaeul>
so effectively a TPL that gets skipped by secure systems? that could work
<apritzel>
smaeul: well, I was more thinking of a single board image, so the size of the eGON SPL wouldn't be a problem.
<apritzel>
and then both SPLs look at the same sector to find the FIT image, so U-Boot proper is shared
<apritzel>
I am not sure how useful those multiple board images really are, in practice, as they would only be able to cover a very small subset of boards
<apritzel>
unless we use a menu selection in the SPL, so a user would pick her board from a list
<smaeul>
oh, I thought we were still trying to get around the size limit
tuxd3v has quit [Quit: Leaving]
<smaeul>
yeah, if you're using today's u-boot-spl.bin, all you have to do is call mkimage twice
<apritzel>
smaeul: so your "poor man's TPL" idea is quite interesting, I might have a look if this is less hacky than the other ones
<smaeul>
s/call mkimage twice/& and change one Kconfig option for the offset/
tuxd3v has joined #linux-sunxi
<apritzel>
details ;-) I got what you mean, actually tried that once already, to boot a single image on both my fuse-burnt Pine64+ and a normal one
<apritzel>
multiple board images would make sense if they can cover all boards from one vendor
<smaeul>
apritzel: if we can convince vendors to program a board ID into the fuses, or have users do it, a single image could work on any board
<apritzel>
smaeul: mmh, interesting idea! Do you have a "map" of freely available fuses?
<apritzel>
I was trying Pine64 as this single vendor once, but the different load offset of the SPL for the H6 spoils an easy solution