ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
vagrantc has quit [Quit: leaving]
ftg has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
adjtm has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
sunshavi_ has joined #linux-sunxi
sunshavi has quit [Ping timeout: 480 seconds]
adjtm is now known as Guest708
Guest708 has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
rajkosto has quit [Read error: No route to host]
cnxsoft has joined #linux-sunxi
adjtm has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
rajkosto has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
adjtm has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
adjtm is now known as Guest714
Guest714 has quit [Read error: Connection reset by peer]
adjtm has joined #linux-sunxi
apritzel has joined #linux-sunxi
adjtm has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
adjtm has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
montjoie has quit [Ping timeout: 480 seconds]
montjoie has joined #linux-sunxi
adjtm has quit [Remote host closed the connection]
adjtm has joined #linux-sunxi
adjtm has quit [Remote host closed the connection]
adjtm has joined #linux-sunxi
adjtm has quit [Remote host closed the connection]
adjtm has joined #linux-sunxi
bauen1 has joined #linux-sunxi
adjtm has quit [Remote host closed the connection]
adjtm has joined #linux-sunxi
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi
disctanger has joined #linux-sunxi
<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
<apritzel> 12.1, of course
aggi has quit [Quit: rebooting]
aggi has joined #linux-sunxi
sunshavi_ has quit [Ping timeout: 480 seconds]