<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 ?
2021-04-24
<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)
2021-04-19
<montjoie>
thanks for the information
2021-04-16
<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:(
2021-04-14
<montjoie>
the 0x80 is used twice perhaps it need a define
<montjoie>
why not send it to mailing list for review ?
2021-04-13
<montjoie>
neller123: 3.10.65 is so old and insecure...
2021-04-08
<montjoie>
I pray it will include a(another) crypto engine
2021-03-30
<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>
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
2021-03-24
<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)
2021-03-16
<montjoie>
it is backup
<montjoie>
it is backup
<montjoie>
it is backup
2021-03-12
<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
2021-03-05
<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
<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.
2020-10-30
<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
2020-10-26
<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
2020-10-25
<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 ?
2020-10-21
<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
2020-10-20
<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 ?
2020-10-19
<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"
2020-10-18
<montjoie>
it seems pineh64 model A hit the problem
<montjoie>
time to use network test on kernelci to detect it!
2020-10-11
<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
2020-10-10
<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
2020-10-09
<montjoie>
It seems I have only some pl2303/ch340.. not cp210x (or it was the dead ones)
2020-10-08
<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 ?
2020-10-04
<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
2020-09-30
<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
2020-09-28
<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