<disctanger>
apritzel: Thanks for your support. Talking of reporing a bug. I could not find usb_ep_autoconfig() methods implementation (definition) Do you happen to know where is it located? I am thinking of doing some debugging and probably then get into reporting.
<disctanger>
apritzel: If i make sure that there's bug i wonder where should i report it. To Armbian developers? Sunxi reviewing mailing list? Upstream Linux kernel? The reason is i never reported this kind of (low level) stuffs before. This PineCube project is my first hardware + software dev project.
bauen1_ has joined #linux-sunxi
bauen1 has quit [Read error: Connection reset by peer]
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
disctanger: please report issues as upstream as you can - if you are somewhat convinced that's it's a real problem and not some setup issue
<apritzel>
disctanger: do you have some kind of source code cross referencing tool installed? Either as part of your editor, or the old UNIXy tools like cscope or ctags
<apritzel>
you would need that to chase down functions in the kernel
<apritzel>
I could tell you where usb_ep_autoconfig() is, but then you would see that it's more or less a wrapper ;-)
<apritzel>
and in this case I would report it to linux-usb@vger.kernel.org and linux-sunxi@lists.linux.dev (after some more investigation to confirm it's a genuine problem)
<disctanger>
apritzel: Noted well about reporting. And thanks a lot for your kind directions regarding how to proceed with investigation. Answer to your question: I think i don't have/know source code cross referencing tools for now. I think VSCode, IntelliJ editors does not have those by default.
<apritzel>
I think they do, that's the whole point of those fancy editors, IIUC
<disctanger>
I will take a look at "cscope" or "ctags" tools. I am new to kernel related business :D
<apritzel>
if you are using VSCode, just find out how this works there
<apritzel>
I wouldn't bother with cscope/ctags unless you are using emacs or vi
<disctanger>
:D
<disctanger>
Sure i will
ftg has joined #linux-sunxi
<disctanger>
For now i am thinking the problem i have is related to set up and minor missconfigurations
<disctanger>
therefore i will investigate the issue further and if i cannot resolve slowly get deeper
<apritzel>
to be sure, with "source code referencing" I mean the ability to find the definition of a function. AFAIK in those "fancy editors" this is as easy as hovering the mouse over the function name
<disctanger>
Oh okay then. I think i have bunch of those tools for other languages but not for C or C++. I will find similar ones for Kernel development
<apritzel>
I would add pr_info() in the call chain, to see what the exact issue is that functions returns with NULL
<disctanger>
I think i will have to add pr_info() into function recompile the kernel install it to my device and retest right?
<disctanger>
or is there somekind of hot reload function in kernel development?
rajkosto has quit [Read error: Connection reset by peer]
disctanger has quit [Remote host closed the connection]
adjtm has quit [Remote host closed the connection]
adjtm has joined #linux-sunxi
JoaoSchim has joined #linux-sunxi
Danct12 has joined #linux-sunxi
adjtm has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
disctanger has joined #linux-sunxi
<apritzel>
disctanger: no, not really. So recompiling it is
disctanger has quit [Remote host closed the connection]
JohnDoe_71Rus has quit []
bauen1_ has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
adjtm is now known as Guest750
adjtm has joined #linux-sunxi
Guest750 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
JoaoSchim has quit [Ping timeout: 480 seconds]
hexdump01 has quit [Ping timeout: 480 seconds]
apritzel_ has joined #linux-sunxi
Danct12 has quit [Quit: Quitting]
apritzel_ has quit [Ping timeout: 480 seconds]
adjtm has quit [Quit: Leaving]
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
JohnDoe_71Rus has quit []
apritzel_ has joined #linux-sunxi
apritzel_ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
<machinehum>
Making quite decent progress reverse engineering Allwinner's BOOT0
<machinehum>
Ghidra is really nice
<bauen1>
apritzel: thanks for the advice about sd-card / usb, seems that the usb can do 21mb/s read, not sure about write, but the encryption doesn't seem to be a problem, because the system is dying from 100% iowait spikes, not high cpu (unless linux counts encryption under iowait ?)
<bauen1>
sd-card seems like a similar picture at 23.5mb/s (dd causes ~20% iowait)
<bauen1>
looks like write to the encrypted ext4 on the usb is what kills it, a nice 100%iowait but somehow still manages 10mb/s
<apritzel>
bauen1: I believe USB storage takes more CPU time in general, because the USB buffers/blocks are smaller
<bauen1>
apritzel: didn't seem like it mattered, at least for read, using a benchmark of `dd if=/dev/X of=/dev/null bs=1M count=1024 status=progress`, sd-card had very consistent 20% iowait, while usb had some spikes of 20% iowait (so seemed to be better on the cpu)
<bauen1>
err, no, iowait is how long the cpu is waiting, so you're right
<apritzel>
"our" SD card version (3.3V only) of the MMC protocol limits us to 25 MB/s max theoretical bandwidth, so 23.5MB/s in practice is probably as close as you can get
<apritzel>
btw. the H616 and V5 allow switching PortF voltage, so we can switch to higher SD transfer modes
<apritzel>
bauen1: if your USB device can only read 21 MB/s, that's quite slow
<apritzel>
bauen1: typically if they already read that slow, they are even slower when writing, so maybe that's the bottleneck?
<apritzel>
bauen1: what's the encryption, exactly? whatever Debian uses?
<bauen1>
apritzel: yeah, just the debian default
<bauen1>
aes-xts-plain64 sector size 512
<bauen1>
i have another usb-device that easiyl reaches 31mb/s read, so i should probably try that
<apritzel>
if it's AES, it should run using the ARMv8 CPU instructions, there should be little bottleneck there
<bauen1>
yeah oh wow, the other USB i have seems to be able to sustain, managing to only to up at 75% iowait or at 31% system cpu
<bauen1>
guess i'm reinstalling lol
<bauen1>
just to make sure for the pine64-lts both usb ports are 2.0
<apritzel>
bauen1: yes, Allwinner is seriously stuck in the past in this regard
<apritzel>
actually the eMMC is the fastest storage interface on the A64. If you have an eMMC module, you are in for a treat, I get 120MB/s out of it
<smaeul>
not if you consider that Ethernet is full duplex :P
<apritzel>
smaeul: well, yeah, if you count Ethernet as storage ;-)
<smaeul>
I store my OS in the c l o u d
<apritzel>
but I guess network protocols eat most of that slight edge ...
<apritzel>
smaeul: very clever! is that a private cloud, running on a BananaPi? ;-)
<smaeul>
I would be curious to benchmark something like ATAoE with jumbo frames
<apritzel>
I knew you would suggest that ;-)
ftg has quit [Ping timeout: 480 seconds]
<apritzel>
bauen1: "cryptsetup benchmark" gives me ~250MB/s for any AES algorithm, in contrast to the 23-40MB/s for serpent/twofish (on an A64)
rajkosto has joined #linux-sunxi
<smaeul>
Is there anyone with an A31 board who could check the r_uart baud rate? I'm trying to verify the divider table in drivers/clk/sunxi/clk-sun6i-apb0.c and I don't have an A31 board.
<aggi>
apritzel: those ~250MB/s come at a price... it's some type of SIMD paraellization, with higher CPU/bandwidth utilization of the system
<aggi>
otherwise, AES is among the low-efficient ciphers like any other of the typical non-military ones
<aggi>
a good cipher design: does not require SIMD/paralellization and remains fast and efficient while it is not prone to any known-plaintext attack even in ECB mode of operation
<apritzel>
aggi: sure, but meanwhile everyone else uses existing and well-tested AES-XTS ;-) - which is hardware accelerated *in the CPU* (which beats device based acceleration, I'd assume)
<aggi>
apritzel: i implemented something different, for use with low-power a53, without any acceleration
<aggi>
although i disguise the entire in-kernel crypto-api of linux
<apritzel>
disguise?
<aggi>
with an LFSR and some non-primitive recursion added to it (which is both very efficient and very safe), i hit the data-rates of "accelerated" AES, and didn't need an SIMD
<aggi>
reject, i remain sceptical about the entire linux in-kernel crypto-api
<aggi>
that's why, i removed the entire crypto-api from kernel, and implemented a transformation against loopdev (which sadly had some other regressions and problems)
<aggi>
it was only interesting to see, how a proven cipher design without any "acceleration" at all competes against accelerated AES
<aggi>
on cortex a53
<aggi>
a good cipher design doesn't need any other block mode than ECB i might add, although "experts" disagree
<aggi>
the problem with many ciphers is, those operate with byte-wise permutations (8bit), although data-bus is 16bit/32bit wide
<aggi>
i implemented bit-wise permutation on 32bit datatypes, with some non-primitive recursion against known-plaintext cribs
<aggi>
limited to 32bit datatypes for portability reasons, and those 32bit datatypes tend to utilize the 32bit databus better than bytewise permutation
<aggi>
i tink it was NATO who specified LFSR for their line-scrambler with MIL-STD-188, although NATO missed the rationale of non-primitive recursion in conjunction
<apritzel>
cyrozap: still on the nasty FEL issue: linking the 10.3 compiled dram_sun50i_h616.o into an otherwise 12.3 compiled SPL works, and the other way around breaks, so it's something in there