<montjoie>
wens: I have already the patch you said:(
2016-11-05
<montjoie>
and so the rest of the system fail without pinctrl (at least I found a bug in sun8i-emac)
<montjoie>
mripard: wens, with DEBUG_TEST_DRIVER_REMOVE, the pinctrl fail do be reprobed http://www.mpaste.com/p/ymVvxMX any idea ?
2016-11-04
<montjoie>
doing RSA like AES:)
<montjoie>
yes I looked at it, but they clearly didnt test their code
<wens>
montjoie: it won't work, given we boot the H3 with PSCI enabled, so linux is in non-secure world
<montjoie>
I try to play also with the Secure CE, but didnt work (need to learn more about trustzone)
<montjoie>
yes it is better than SS, but with a enormous lack of information
<montjoie>
and clearly the output is not random
<montjoie>
nothing
<montjoie>
it didnt work, the 16Mhz OSC register is RO
<montjoie>
I will try dump the memory and check it against default values
<wens>
montjoie: allwinner is not known for providing complete docs
<wens>
montjoie: it probably does
<montjoie>
Needing to cross read user manual for Crypto Engine is a pain
<montjoie>
according to A83T user manual about TRNG
<montjoie>
I need it to enable OSC16Mhz for CE TRNG
<montjoie>
does H3 have really R_PCRM ? I see it in memory map but nothing in user manual
2016-11-03
<montjoie>
the H3 TRNG get 100%failure on rngtest:(
2016-11-02
<beeble>
montjoie: interessting read. and very usable for kernel builds. but if you go into distro packages i would think that IO would be the bottleneck in such a setup. the emmc is to space constraint and if you use nfs then io speed will killing you
<montjoie>
beeble: related info, see willy tarreau slides from kernel recipes on compilation cluster (it speak about allwinner also)
<montjoie_>
gQnbold I will update the sun8i-ce-experimental branch
<ganbold>
montjoie_: can you share H3 PRNG related codes?
2016-10-23
<montjoie>
oh already packaged on gentoo
<montjoie>
thanks I will read
<montjoie>
hum, TRNG 100%failure with the same speed
<montjoie>
39Mbits/s
<montjoie>
the randomness seems good, now I try the TRNG
<montjoie>
H3 PRNG done:)
<scream>
montjoie, I trust you with my chinese ARM board :D
<montjoie>
I can release my dtb/uImage but you need to trust me to not insert backdoor:)
<montjoie>
scream: you can cross compile also
<montjoie>
jonkerj: one bug is fixed, other things are doc/comment/minor
<montjoie>
but fixes could be simplier found by diffing v4 and v5
<montjoie>
I could have two branches one with fixes , the other squashed
<apritzel>
that's the natural thing to do in montjoie's situation: first you make fix patches on top, then before posting squash them in the original patches
<montjoie>
using the proper readl() reverse all bytes order
<montjoie>
does anyone know why sunxi-sid use ioread32be ? the data is not big endian
2016-10-20
<montjoie>
terra854: use apritzel git repo
<MoeIcenowy>
montjoie: what's this?
<rellla>
montjoie: nice thing, the challenge. sadly i'm standing at #5 due to lack of time :(
<netchip>
montjoie: seems cool
<montjoie>
netchip: for a begin, try eudyptula challenge
<montjoie>
for my part, clearly RSA was never tested
<montjoie>
and doing RSA in 3.4 knowing that all API for doing it was included in 4.8...
<montjoie>
they do RSA like AES in crypto, no more better example of ugly BSP
2016-10-19
<montjoie>
ok
<montjoie>
explaining API by API
<montjoie>
thanks, but I searched some more like ldd3 or kernelnewbies
<ElBarto>
montjoie: but usually I just read the sources and learn from that when I don't know stuff
<ElBarto>
montjoie: the developer handbook is what you need
<montjoie>
ElBarto: do you have a link for learning kernel dev for xBSD ?
<montjoie>
gmail spam...
<montjoie>
oups I didnt see any comment
<montjoie>
mripard: you do not have made any comment on my dt sid patch
2016-10-18
<montjoie>
igraltist: hwrng patch just sent
2016-10-17
<montjoie>
but I need to sent it, DMA is so so slow that I prefer hwrng come first
<montjoie>
but test are also welcome:)
<montjoie>
no the problem is that if I send a day the patch for enabling DMA, I have a problem on how to handle the lock
<igraltist>
montjoie: ok thx
<montjoie>
igraltist: no I need to sent the patch for review
<igraltist>
montjoie: do u know if the hwrng should work for cubietruck on 4.4?
<montjoie>
I will push v5 soon
<montjoie>
Da_Coynul resolved in "latest" v4 (get it from mailing list)
<Da_Coynul>
montjoie: could you take a look at this kernel panic I captured yesterday: http://pastebin.com/WQ7hgzEb (sun8i_emac seems to be involved)
<montjoie>
so yes just upgrading uboot will fix that
<montjoie>
I have badly read it
<NiteHawk>
montjoie: that's what the mentioned commit already does. it replaces sid[3] with a crc32 value generated over 12 bytes starting at sid[1], i.e. considers sid[1] to sid[3] when doing so. i'd expect Da_Conyul to get different resulting MAC addresses with v2016.09+ (unfortunately he left)
<montjoie>
NiteHawk: sid[2] surely. perhaps adding sid 1 2 3 and crc the result
<NiteHawk>
montjoie: but including sid[1] and sid[2] into the CRC generation surely helps?
<montjoie>
NiteHawk: I think the commit will not solve the problem since sid[3] is not enought random
<montjoie>
its me
<montjoie>
Da_Coynul could you try uboot v2016.09 ?
2016-10-16
<montjoie>
I believe to remember someone has already said yes
<montjoie>
ssvb: does 2016.05 has your patch ?
<montjoie>
Da_Coynul which uboot versiob give you mac collison ?
<montjoie>
I will update the wiki and will try to find a way to enhance uboot for gen better MAC address
<montjoie>
thanks Da_Coynul
<Da_Coynul>
montjoie: using devmem2 (thanks jonker) the sid for OPI PC #1 is 2004620 34344314 503A04CE 8000000
<Da_Coynul>
montjoie: nothing in dmesg about sid
<jonkerj>
montjoie: maybe you should have him 'devmem2' the SID-dump
<montjoie>
Da_Coynul and NVMEM_SUNXI_SID ? no sid message in dmesg ?
2016-10-15
<Da_Coynul>
montjoie: CONFIG_NVMEM=y
<montjoie>
Da_Coynul do you have NVMEM in config ?
<montjoie>
and so hexdump -C /sys/devices/platform/soc/1c14200.eeprom/sunxi-sid0/nvmem doesnt work ?
<montjoie_>
compile error or not enabled ?
<montjoie_>
Da_Coynul do you have sunxi_sid driver compiled ?
<Da_Coynul>
montjoie: I applied your SID patch and I now have the /sys/devices/platform/soc/1c14200.eeprom directory but it does not contain /sunxi-sid0/nvmem
2016-10-14
<montjoie>
for adding sunx-sid
<montjoie>
but of opipc you need the DT patch I sent on mailing list
<montjoie>
Da_Coynul: with hexdump
<Da_Coynul>
montjoie: is it possible to dump the SID with hexdump or do I have to dump from u-boot or fel mode?
2016-10-13
<Da_Coynul>
montjoie: I will work on that later today
<montjoie>
Da_Coynul could you dump your sid values for your opipc with same mac ?
2016-10-12
<montjoie>
jonkerj: commit link done:)
<montjoie>
I regen all
<montjoie>
just found it:)
<montjoie>
for the moment I didnt find a way to find the link with the commit id to some https://git.kernel.org/cgit/
<montjoie>
following a discution about the fact it was hard to follow "work around sunxi", I started a bot who read ML (kernel@vger and linux-arm-kernel for the moment) and seek all discutions/patch about sunxi
2016-10-08
<montjoie>
those which have same mac addr
<montjoie>
Da_Coynul could you dump the content of the sid of your both opipc ?
2016-10-05
<montjoie>
nothing, I think its a bug
<enrico_>
montjoie: i recompiled the kernel without sun4i-ss and it works, do i need something compiled in kernel for sun4i-ss? or in u-boot? u-boot is 2016.07
<montjoie>
seems recent e2fsprogs
<montjoie>
enrico_: do you know from which package comes e4crypt ?
<montjoie>
I will try it
<enrico_>
montjoie: uhm i don't know what algo ext4 use by default, i just followed the usual setup (e4crypt add_key etc..)
<montjoie>
enrico_: which algo do you use ?
<montjoie>
I will send the patch for enabling sid in H3 in DT
2016-10-04
<montjoie>
so no need to warn/info anything
<montjoie>
KotCzarny: since I will remove the ethernet0 alias, all user will have a random mac, so no problem
<montjoie>
only one board = no problem
<montjoie>
KotCzarny: the problem will be found only if the user doesnt have chance like Da_Coynul
<Da_Coynul>
KotCzarny: regular users won't blame montjoie's driver - they will just say OPI is garbage and doesn't work.
<montjoie>
whithotu alias macaddr is random
<montjoie>
KotCzarny: it simplier to remove alias in DT until uboot is fixed
<KotCzarny>
instead of saying 'montjoie, your driver doesnt work correctly'
<montjoie>
apritzel: yes
<montjoie>
it was my first intention but I think it s a bad idea to put a work around in driver
<montjoie>
I will remove aliases ethernet in DT for the moment
<montjoie>
so not enought random
<montjoie>
jonkerj: tkaiser so it seems that lots of opipc have all three last digit at 0 in sid[3]
<montjoie>
uboot incoreclty set last three number to 0
<montjoie>
Da_Coynul: what is yoru mac address ?
<montjoie>
but I have only one opipc so didnt see it
<montjoie>
Da_Coynul: I got the same in fact
<tkaiser>
jonkerj: I would think the problem reported by Da_Coynul yesterday is related to an outdated u-boot version. Montjoie's sun8i-emac-wip-v4 together with u-boot 2016.09 should work (his older versions calculated a random MAC at every boot).
<jonkerj>
montjoie: I believe someone here said Hans is working/worked on a patch improving randomness of sid to mac on h3
<tkaiser>
montjoie: I know but I would assume it's the same issue?
<montjoie>
The 3 last digit from MAC addr is always 0, any idea why uboot doesnt change it ?
2016-10-03
<Da_Coynul>
montjoie: I am not setting MAC address in DT as far as I know. The kernel built from your sun8i-emac-wip-v2 branch works, and the one built from your sun8i-emac-wip-v4 branch gives the same MAC address to both OPIs.
<montjoie>
nikre: only the wiki
<montjoie>
thanks . Since the driver stop all phy/clk when netdevice is close, so pm_suspend will have little to do
<mripard>
montjoie: I was confirming that they're not the same
<montjoie>
so I have misunderstood your previous "no"
<montjoie>
I think I haved missed something, you just said "suspend might be called during the device operations" but just after you said "which is called only to the suspend the device when it's not used"
<montjoie>
mripard: so suspend and runtime_suspend is not the same
<mripard>
montjoie: I wanted you to implement runtime suspend, which is called only to the suspend the device when it's not used
<montjoie>
mripard: thanks, I will postpone pm patch until I found a good testplan
<miasma>
montjoie: some of the sunxi stuff depend on other options that are crucial. e.g. on my banana pi I needed some extcon and usb nop to enable the sunxi ethernet
<mripard>
montjoie: but it cannot be called on the Allwinner SoCs since we don't support system-wide suspend at the moment
<mripard>
montjoie: suspend might be called during the device operations
<montjoie>
miasma: you could grep for SUNXI strings to add
<miasma>
montjoie: yes, but it installs too much stuff if you try to achieve a minimal kernel
<montjoie>
for the CONFIG you should take the sunxi_def_config
<montjoie>
miasma: you could get the latest driver from my github
<montjoie>
mripard: could you please confirm that suspend wil never be called when the device is used, because all other network driver do "napi/phy" stuff you said I need to remove
<miasma>
montjoie: i might try patching 4.8 sources for my personal use then. would the patch i saw on the mailing list work out of the box
<montjoie>
I believed that is was orthogonal, uncessary to each other
<mripard>
montjoie: to make it useful you'll need some runtime_resume and runtime_suspend hooks
<montjoie>
but pm_runtime is checked
<montjoie>
and it is why I sent them as RFC
<montjoie>
only suspend/resume wasnt tested
<montjoie>
what I miss for make it working ? since with it I see /sys/devices/platform/soc/1c30000.ethernet/power/runtime_status with the ood status
<montjoie>
mripard: so I dont understand, do I need to send the pm_runtime patch or not ? (since it's you that call for it in v3)
<montjoie>
sorry
<montjoie>
i think you spoke about the suspend/resume
<montjoie>
yes just counters
<mripard>
montjoie: runtime pm doesn't do anything.
<montjoie>
but pm_runtime work
<montjoie>
mripard: I just said that:) (dropping suspend/resume)
<mripard>
montjoie: I told you already, but this is dead, untested code
<montjoie>
I dropped the resume/sspend, and since Da_Coynul problem is finaly pm unrelated I will keep pm_runtime
<apritzel>
montjoie: and can't you just drop the PM stuff for now if that is still buggy?
<apritzel>
montjoie: why should 4.10 be difficult?
<montjoie>
miasma: I will send it tomorow, but think 4.10 will be difficult
<montjoie>
+have
<montjoie>
Da_Coynul, do you MAC address set in DT ?
<montjoie>
Da_Coynul: impossible to have duplicate MAC, since the driver generate a random one, except if set in DT
<KotCzarny>
montjoie, maybe your driver should warn users that mac was generated on h3 and similar socs?
<Da_Coynul>
montjoie: I think I figured out the problem. I am getting duplicate MAC addresses on both of my OPIs. The MAC address collision is causing the dropped packets.
2016-10-02
<Da_Coynul>
montjoie: sure, no problem.
<montjoie>
Da_Coynul: let it work 24h and confirm me tomorow that it worked without it
<Da_Coynul>
montjoie: v4 without pm_runtime patch seems to be working OK.
<montjoie>
Da_Coynul: could you try V4 without the pm_runtime patch ?
<montjoie>
nothing strange, but low value of all counter
<montjoie>
yes
<Da_Coynul>
montjoie: v2 works, v3 does not.
<montjoie>
Da_Coynul: with v2 it works ? (and v3 ?)
<Da_Coynul>
montjoie: I had to revert both OPI PCs back to v2 of your sun8i emac driver because of problem I told you about yesterday.
<tkaiser>
montjoie: if you want to get the Pine64+ up and running in shortest time to test against I strongly recommend using longsleep's Xenial image as a start (BSP kernel but who cares -- at least you need just 2 tweaks to ensure to get 940 Mbits/sec in any case).
<tkaiser>
montjoie: That's great but maybe you're affected by the GbE issue. Green or red led?
<montjoie>
I believed that + is for one with 2G RAM
<tkaiser>
Sure, TL Lim sent out 3 more to me yesterday. I just thought why loosing more time and since montjoie's driver is used for A64 anyway?
<montjoie>
tkaiser: thanks but I just checked, and i got the one with GbE so a pine64+
<tkaiser>
montjoie: IMO it would make a lot of sense if you possess at least one Pine64+. Care to share your address details with TL Lim? I would then ask him to send out 2 Pine64+ (to increase chances you get one that is not affected by the 'GbE issue').
<tkaiser>
montjoie: :( With a Pine64+ it would work with approriate settings
<montjoie>
tkaiser: pine64 classic
<tkaiser>
montjoie: And BTW: the numbers I got are excellent. Will test later with a GbE devices in parallel, then it get's interesting since single-threaded limitations do not apply any more then.
<tkaiser>
montjoie: Do you have a Pine64+ lying around?
<montjoie>
and i need to find a 900mo/s capable network adapter
<montjoie>
tkaiser: but no more kernel panic:)
<tkaiser>
montjoie: Tried it with 'Enterprise network' settings (1MB instead of 128K blocksize) and your driver again. Testing with LanTest against Netatalk: 59MB/s write to OPi Plus, 82MB/s read. Writes are still bottlenecked by single-threaded afpd process. Interpretation of results: http://www.helios.de/web/EN/support/TI/157.html
<montjoie>
tkaiser: yes for perf bench
<montjoie>
I will read the doc, perhaps it could be usefull
<tkaiser>
montjoie: How?
<montjoie>
tkaiser: do you have tried the inkernel PKTGEN ?
<tkaiser>
montjoie: Anyway: I get pretty stable 880 MBits/sec when sending from H3 to client with iperf3 -- in this mode iperf3 is the bottleneck and maxes out 1 CPU core (single-threaded stuff)
<montjoie>
sun8i-emac have already ETOOMANYMAGICBIT