<montjoie> we use wood with hole, board are up, cable go down via holes
<montjoie> board are not the problem, wire attached to them are


<mossroy> BTW I'd like to thank montjoie and/or anybody that helped adding crypto support for Allwinner CPUs on mainline linux
<montjoie> exactly the same algo before, still dont understand why they persist on keeping DES/3DES
<gediz0x539> montjoie: https://i.imgur.com/RgqxsKE.png
<smaeul> montjoie: yes there is a crypto engine
<montjoie> MoeIcenowy: does there is at least a crypto hw ? no interest for me without it
<montjoie> no problem I will register
<montjoie> still under NDA ?


<montjoie> and I am not sure that rng-tools use the crypto_rng, ( for be honest I know no tool using it)
<montjoie> tuxd3v: sun8i-ce provides a prng yes, (trng is present but only working on h6)


<montjoie> thanks for the information


<montjoie> for my interest, crypto hw, they are never good
<bauen1> montjoie: i also haven't found anything better than the "press release", and that after experimenting with the h6 / a64 i'm not expecting anything too "good" / "interesting" tbh
<montjoie> I didnt see any crypto details, sad:(


<montjoie> the 0x80 is used twice perhaps it need a define
<montjoie> why not send it to mailing list for review ?


<montjoie> neller123: 3.10.65 is so old and insecure...


<montjoie> I pray it will include a(another) crypto engine


<apritzel> montjoie: actually private email only: the Pine64-LTS SD card operation seems to be broken since 5.12-rc1
<montjoie> apritzel: which problem reported on list ?
<montjoie> I see hardware sdcard switcher, but never tested them
<apritzel> montjoie: in theory: yes, but how do you test SD card boot, and also the card detect switch? ;-)
<montjoie> I tried to test uboot on chip via fel, but failed
<montjoie> with proper setup you could skip sdcard change (tftp, fel) but that need time
<montjoie> try to found a cellar:)
<montjoie> I need to motive to plug the cubie4 to have an a80 tested
<montjoie> buZz: we have already a not so bad collection in kernelci, what is sunchips ?
<buZz> montjoie: incl sunchips? :D
<montjoie> hard to have the complete sunxi collection
<apritzel> montjoie: but thanks for the offer
<apritzel> montjoie: and the DT change merged was explicitly only for the LTS (and the SOPine)
<apritzel> montjoie_: well, this is apparently one of the differences
<montjoie_> apritzel: sorry got no one in any lab, does it is very different from other pine64 ?


<montjoie> sure I will add reported-by
<montjoie> do you send a fix or I ?
<montjoie> wens: yes
<wens> montjoie: these Kconfig symbols aren't defined: https://github.com/torvalds/linux/blob/master/drivers/crypto/allwinner/Kconfig#L74


<montjoie> only hardware rng provides /dev/hwrng
<montjoie> pjuck: normal it is not a hwrng but a prng
<montjoie> from user space, speed is worse
<montjoie> pjuck: it is an offloader, not accelerator


<montjoie> (french classic) the difference between good and bad rng is that a good rng produces random, a bad rng produce random also but it is a bad random
<montjoie> perhaps we could use as a rng:)
<montjoie> do you have benched it ? perhaps it is too slow:)
<montjoie> perhaps
<montjoie> it still could be used as "some block encryption"
<montjoie> mripard: I will update wiki for EMCE status with mailing list link


<montjoie> mripard: please push the code, I will read what I missed to do
<montjoie> mripard: please push the code, I will read what I missed to do
<mripard> montjoie: yeah :/
<mripard> montjoie: yeah :/
<montjoie> mripard: it seems you have made more progress then me, and the conclusion is bad:(
<montjoie> mripard: it seems you have made more progress then me, and the conclusion is bad:(
<montjoie> mripard: yes I work on it
<montjoie> mripard: yes I work on it
<mripard> montjoie: it looks like you've been working on the H6 EMCE as well (and I missed that somehow)
<mripard> montjoie: it looks like you've been working on the H6 EMCE as well (and I missed that somehow)


<montjoie> it is backup
<montjoie> it is backup
<montjoie> it is backup


<karlp> montjoie: cp210x can be programmed with custom ids...
<MoeIcenowy> montjoie: how about CH340?
<montjoie> and they die more often
<montjoie> MoeIcenowy: we have some pl2303, cpxxxx but first they lack serial IDs
<MoeIcenowy> montjoie: how about others?
<montjoie> in our kernelCI experience, FTDI are more reliable


<montjoie> I need to check them
<montjoie> yes I see it, lot of patch dont apply on backport
<wens> montjoie: did you want "crypto: sun4i-ss - IV register does not work on A10 and A13" backported? gregkh sent notices saying backports didn't apply directly for < 5.4


<prefixcactus> montjoie: thanks
<montjoie> so the probe is defered
<montjoie> prefixcactus: include/linux/errno.h:#define EPROBE_DEFER 517


<montjoie> I seek this log in my board farm, no evidence yet


<montjoie> ullbeking: I am for CI testing, but that's offtopic


<montjoie> ah i believed it was vanilla stable
<montjoie> I launched a build to test
<montjoie> tuxd3v: on which bboard ?


<montjoie> fun my olinuxino-a20 boot only when lot of debug output is enabled


<montjoie> no, it means I really need to finish the "try to boot any sunxi patch from mailing list" to prevent this
<montjoie> he he what a good day, 2 bisected problem
<smaeul> montjoie: interesting. I don't have any A83T board, but I don't get that error on Pine H64, which has a shared NMI
<montjoie> now time to bisect "WARNING: CPU: 0 PID: 51 at drivers/thermal/thermal_core.c:549 thermal_zone_device_update+0x134/0x154"
<montjoie> ah ah the guilty is "ARM: dts: sunxi: Move wakeup-capable IRQs to r_intc", will send report


<montjoie> yes, bisect in progress
<montjoie> I hit irq: type mismatch, failed to map hwirq-0 for interrupt-controller@1f00c00! on a83t


<montjoie> cubieboard2 bring me here (and temperature)


<montjoie> hello, on qemu cubieboard, booting lead to https://pastebin.com/pw6r1w2Q, any idea on how to fix this ?


<montjoie> could you rmmod xts && modprbe xts... just in case
<montjoie> I am puzzled, i dont see anything
<montjoie> holri1: could you paste the full /proc/crypto ?
<montjoie> does some aes exists in /proc/crypto ?
<montjoie> does the problem persist on reboot ?
<montjoie> holri1: does this is a custom kernel ? strange that I dont see any AES_ARMxxx
<montjoie> holri1: could you modprobe tcrypt and see what it print ? (if it print more)
<montjoie> I am puzzled by "tcrypt: one or more tests failed!" without any test printed
<montjoie> please paste full .config also
<montjoie> holri1: this is not full dmesg, perhaps something happen before.
<montjoie> please post full dmesg
<montjoie> and AES ?
<montjoie> zgrep XTS /proc/config.gz
<montjoie> holri1: verify your kernel has XTS support


<montjoie> the base rootfs is a minimal buildroot with tool for CI
<montjoie> Ashleee: it is not production, it is CI, I build arm64_defconfig+crypto than boot via network
<montjoie> my nanopineoplus2 has 512M of RAM, kernel is 30M ramdisk is 400+M, what could go wrong ?
<montjoie> +not
<montjoie> Ashleee: in uboot I copy image,dtb,ramdisk via TFTP in memory, so I should do overwrite anything before linux start
<montjoie> but for testing I enable a bit more modules, and boom
<montjoie> arm64 kernel get bigger, but by chance we are just below limit
<montjoie> I got this also on non-sunxi boards
<montjoie> if I decrease load address, it is the Image which will overwrite ramdisk
<montjoie> KotCzarny: I got TFTP error: trying to overwrite reserved memory...
<montjoie> too many modules
<montjoie> uboot fail to load ramdisk in memory
<montjoie> arm64_defconfig is too big for some board
<montjoie> just in case people are interested, I have created a sunxi64_defconfig https://github.com/montjoie/linux/commit/ef84543e60df1407b68a1f8f65f27c02354400ce


<tuxd3v> montjoie, many thanks, probably it could be some tests option that get enabled, next time I will to a menuconfig, I will check that too
<montjoie> tuxd3v: my opi1+ is working fine on next/5.10
<montjoie> tuxd3v: only choice bisect, but I will check my opi1+


<montjoie> apritzel unfortunatly only for emmc(smhc2)
<apritzel> montjoie: is EMCE for SMHC2 (eMMC) only? or does it work on the other controllers (SD card) as well?
<apritzel> montjoie: and yeah, most modern SD cards are "high capacity"
<apritzel> montjoie: nice!
<montjoie> I found the last trick and EMCE seems working now
<montjoie> apritzel: thanks, it seems that my eMMc is in sector mode
<apritzel> montjoie: old SD card use byte addresses, "newer" card (SDHC, SDXC) use sector addresses
<montjoie> hellow, how to now if an eMMC is working in sector or byte mode ? My question is needed for EMCE (usermanual page 517)


<montjoie> hé hé hé hé, ebiggers sent a patch for supporting mmc hardware encryption, this will help using EMCE on H6


<montjoie> linkmauve: I use both LE/BE buildroot, but by use I mean "CI test", in real production I use nothing
<montjoie> linkmauve: I use buildroot
<linkmauve> montjoie, whici userland did you end up using?
<MoeIcenowy> montjoie: yes, in sun8i_ths_calibrate it just passes void* to u16*
<montjoie> problably it miss some cpu_to_xx32
<MoeIcenowy> montjoie: I assume something is wrong about the thermal sensor calibration
<montjoie> apart this very hot temperature
<montjoie> anyway sunxi arm64 works well in BE (no visible failure)
<montjoie> apritzel: it is just for testing
<apritzel> (for some versions of "fine", as montjoie discovered)


<apritzel> montjoie: do you actually use a BE system? Or is that just for testing?
<apritzel> montjoie: amazed you got that far with a BE kernel ;-)
<montjoie> I forgot to said, that i got this with BigEndian kernel
<montjoie> for a system just booted
<montjoie> that's a bit hot
<montjoie> I got this on my pineH64 thermal thermal_zone0: critical temperature reached (152 C), shutting down


<montjoie> anyway, their BSP is so wrong about their own hardware....


<montjoie> my example was for hash, for RSA they mixed bytes/words
<montjoie> since on H6, they changed how to store them (like for hash, it is the length in "bits"...)
<montjoie> and seriously I was forced to code a failretry which increase all (->len) to find how store them
<montjoie> it works but H6 decided to drop what previous SoC did, and key is not stored in key anymore
<apritzel> montjoie: what's the news? ;-)
<montjoie> but seriously, allwinner people have some sanity problem
<montjoie> brute force ended, H6 RSA seems working
<montjoie> a ha ha ah ah CE is always giving me data len error on H6 for RSA, so lets start a brute force of all possible len
<libv> montjoie: pure bisect is indeed not the answer, and it is not fun, but not impossible
<libv> montjoie: i went through something similar for the fosdem video-hw changes


<apritzel> montjoie: just bisect over the ~150000 commits ;-)
<montjoie> same driver works well on 5.0, fail on 5.10
<montjoie> pfff something external to my driver made sun8i-ce RSA unreliable...
<montjoie> mripard: will resend in that case
<gediz0x539> montjoie: oh, okay then. thanks.
<mripard> montjoie: I wasn't cc'd on that defconfig patch
<montjoie> gediz0x539: on A13 you have the sun4i-ss PRNG
<montjoie> wens: it is both for testing and for being smart with users
<wens> montjoie: I take it you want this enabled so it gets tested through kernelci?


<montjoie> wens: mripard: any though on https://lore.kernel.org/patchwork/patch/1338614/ ?


<montjoie> jernej: seems ok
<montjoie> jernej: let me build&boot
<jernej> montjoie: Can you confirm that 5.9.11 has fixed regulator issue? it works on my R40 board


<montjoie> someone already send hwspinlock in the past. I was sure it was merged already


<montjoie> pdu fault finaly. so reseting uart was the trick
<montjoie> disconnecting all wires, still nothing
<montjoie> like I burned it
<montjoie> but now I retry nothing
<montjoie> apritzel it has worked and uboot appears
<apritzel> montjoie: also try the Windows way: just retry
<apritzel> montjoie: or disconnect the serial wires during the reset
<apritzel> montjoie: sometimes some stray voltage from somewhere prevents proper reset/ FEL entry
<apritzel> montjoie: and are you in FEL mode properly?
<apritzel> montjoie: Does "sunxi-fel -v -p ver" say something?
<montjoie> any idea on what happen ?
<montjoie> hello I try to flash chip via fel and I get "usb_bulk_send() ERROR -7: Operation timed out"


<montjoie> such bit was found on sata:)
<montjoie> apritzel: I didnt expect anything, always interesting to check what they do (I pray for a magical bit which speedx10)
<apritzel> montjoie: understood, but do you expect it to be so much different from, say the H6?
<montjoie> apritzel: no crypto driver for CE (even if present in DT)
<apritzel> montjoie: removed crypto from the DT, you mean? Because it's still in the manual ...
<montjoie> fun they removed crypto
<montjoie> megi: the a13 in kernelci works perfectly, do you use a custom config or sunxi_defconfig ?


<pgreco> montjoie: thanks!
<montjoie> pgreco: I have just tested the patch and it works, I will answer
<pgreco> montjoie: This is what I tested (and worked) https://lkml.org/lkml/2020/10/24/69
<montjoie> h it seems I need to check my spam directory
<montjoie> probably I could sent a new email thread as CC changed during inverstigation
<montjoie> pgreco: nobody answered my email thread


<pgreco> montjoie: around? wrt reverting aea6cb99703e17019e025aa71643b4d3e0a24413
<montjoie> but with a private backup libv became a spof for the wiki life
<montjoie> for me you wanted to do public backup, but if only private backup is wanted, encrypt the whole is easier
<montjoie> willmore: password are probably in the wiki DB, so if you want to backup the whole DB, you need to check that.
<willmore> That's what I was thinking. But from montjoie's comments, I thought it might be used to encrypt different parts of the data with different passwords, which is confusing.


<willmore> montjoie, I'm not sure what the password DB has to do with backups.
<montjoie> or just do a accountless backup
<montjoie> KotCzarny: it is why I ask for password hashing, it "could" help sharing the DB.
<montjoie> libv: willmore: does password are hashed in the DB ? A first step could be to generate a tar.gz availlable in a vhost restricted by IP/password


<montjoie> but on sunxi_defconfig, realtek PHY is not present, do you think it is worth adding it ?
<montjoie> mripard: next time kci will detect them earlier, I work on adding network test
<mripard> montjoie: jernej: wens: Thanks a lot for the PHY-delay fallout fixes btw


<montjoie> oh yes, generic phy...seems sunxi_defconfig dont bring realtek phy, but arm64 does
<montjoie> perhaps I need to recheck if it is "stable"
<montjoie> no, just no change, it works
<montjoie> jernej: without your patch ethernet works, same happend on bpim3, does it is normal ?
<montjoie> jernej: my problem appears only on next, ethernet do not work due to axp not probed
<montjoie> jernej: did you hit my problem with regulator on m2 ultra while testing rgmii-id ?


<montjoie> and since kernelCi does not test network (yet) it remains hidden
<montjoie> it end in 53 possible bad commit
<montjoie> willmore: I hit a range of crash (unrelated) so lot of skip
<willmore> montjoie, 100 steps? How many commits? Isn't it log2(commits)*2+1?
<montjoie> thanks
<tuxd3v> montjoie, yes the 2.5v is enabled in the Ethernet by a signal ( PD6 )
<montjoie> tuxd3v: and it is enabled via PD6 ?
<tuxd3v> montjoie, the 2.5 volts are provided by a fixed regulator and this regulator is powered by vcc-5v
<montjoie> still bisecting R40 issue... more than 100 steps/boots now, that's pain
<montjoie> or perhaps the 2.5V is not from PMIC ?
<montjoie> tuxd3v: unfortunaly the dt change it seems not enough for opi1+, ATF does not set anythong to 2.5V


<montjoie> my goal is uboot network for now
<tuxd3v> montjoie, you need to apply megi patch's for kernel 5.9.x
<montjoie> I will try
<tuxd3v> montjoie, no uboot tests, only kernel
<montjoie> tuxd3v: do you have tested this change on uboot ?
<montjoie> wow still bisecting, more 50 steps...
<montjoie> pfff bisecting lead to lot of kpanic boots
<montjoie> this prevent at least network to start
<montjoie> on linux-next I got lot of "Error applying setting, reverse things back" on R40, anyone hit that ?


<montjoie> false error, MACPWR is well set...
<montjoie> I found that on opi1+, sunxi_name_to_gpio(MACPWR) return -22
<montjoie> anyone enabled uboot network in opi1+ ? probably I miss something but cannot find what
<montjoie> but it fail with "Could not get PHY for ethernet"
<montjoie> does someone have some hint to enable uboot network opi1+, I tried syncdtb,add CONFIG_SUN8I_EMAC=y and CONFIG_MACPWR="PD6"


<montjoie> it seems pineh64 model A hit the problem
<montjoie> time to use network test on kernelci to detect it!


<montjoie> cryptocell support chacha, CE not
<montjoie> example: the allwinner CryptoEngine support CFB (cryptocell not)
<montjoie> bauen1: I have read quickly cryptocell driver, and seeking cryptocell specs, I saw some difference withh allwinner
<bauen1> montjoie: thanks that is good to know, do you have any source for that information ?
<montjoie> bauen1: no allwinner use their own IP and not compatible with cryptocell


<willmore> Yeah, montjoie, not finding any cp210x here at all. Lots of ch340 and pl2303.
<montjoie> money can be better spent
<montjoie> asdf28: 3.4 is evily too old stay away of it
<montjoie> a


<montjoie> It seems I have only some pl2303/ch340.. not cp210x (or it was the dead ones)


<karlp> montjoie: cp210x ships with 000001 as the serial by default, but you can just send a ctrl req to set your own serial and save in eeprom: https://github.com/karlp/mixed-cygnals/
<montjoie> for having a serialID, I found some FTDI at 5€ in my memory
<montjoie> except the very cheap does not have serialID, which is very helpfull when you have lot of devices
<montjoie> if you are stingy like me, you find some on aliexpress for a very few €
<montjoie> but a serial is very helpfull
<montjoie> you can hardcode tftp commands in boot.cmd
<montjoie> feel the heat of the net!
<montjoie> it will save your time (and card reader)
<montjoie> anyway it is resurected and booting!
<montjoie> Appart opi3, only the sun8i-a83t-allwinner-h8homlet-v2 does nto have network, but since it remains only a few in the world, it is not worth the work
<montjoie> anyway, I have some USB net dongle for bypassing that
<montjoie> megi: thanks for the PR link
<montjoie> some regulator for PHY probably is missing
<montjoie> no network in uboot
<montjoie> when dev/testing, remove sdcard, put on cardread, mount write umount, remove from cardreader reput card is VERY annoying
<montjoie> (nearly all, I see you opi3)
<montjoie> asdf28: all sunxi can
<montjoie> if you plan to do lot of test try tftp
<montjoie> asdf28: the sunxi_defconfig should be sufficient to boot
<montjoie> bisecting boot will be the fast path, but that 5.7 KO 5.8 OK 5.9 KO seems strange
<asdf28> montjoie: it's a banana pi m1
<montjoie> asdf28: which bananapi version ?


<montjoie> ...related to #sunxi, if you know good chip for current monitoring I am interested, I need to monitor my sunxi zoo power usage
<montjoie> I have nothing to say


<wens> montjoie: it's not the pull up/down, but the active high / low, i.e. whether high or low indicates a card present, that matters
<montjoie> I have a hacked v2020.04 uboot which work (USBnet working) and that sufficient to CI it
<montjoie> anyway, this is a so rare board, that more work on is useless
<montjoie> on your commit you added 'CONFIG_MMC0_CD_PIN="PF6"' and removing it fixed the issue on v2016
<montjoie> in fact I set cd_pin to -1 for let it work on v2020.04
<montjoie> in uboot, inverting the sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP); to DOWN is not sufficient
<montjoie> does it is possible that I have a different h8_homlet_devboard with cd-inverted... seems yes
<montjoie> wens: I bisected my h8_homlet_devboard to your "sunxi: h8_homlet_v2: Enable USB Kconfig options in defconfig" :D


<montjoie> now try to made ethernet works...
<montjoie> wens: cd-inverted did the trick! thanks
<montjoie> how to change it ?
<wens> montjoie: just a guess. if the card detect gpio polarity is wrong, then it won't do card detection, because it only tries to detect a card if card detection indicates a card is inserted
<montjoie> I need to found what made uboot 2016.03 and 2020.10 not
<montjoie> I fear other problem like regulator
<montjoie> clementp[m]1: I dont see any hack like that in the uboot version which boot it
<clementp[m]1> montjoie: just got recent issue with eMMC for LE users. https://github.com/LibreELEC/LibreELEC.tv/pull/4564/files
<montjoie> just no card detection
<montjoie> I have added debug, the host is correctly probed
<montjoie> how to know ? how to test ?
<wens> montjoie: inverted CD polarity?
<montjoie> wens: any idea on why mmc0 does not show up https://pastebin.com/yPH6DAh5
<montjoie> it boots but mmc0 does not appears
<montjoie> wens: 2016.03 booted!
<montjoie> if you have a know uboot revision which works,but that's not urgent, I wanted to add easily another a83t for boots
<montjoie> hello anyone with the collector h8_homlet_v2 ? I got "MMC: no card present/spl: mmc init failed with error: -123" with recent uboot