12:28 <linusw__> ardb: some platforms have TCM/SRAM on-chip memory, do you know if someone toyed with the idea to move computing intensive kernel code such as cryptos into these memories?

12:29 <linusw__> I thought about it long ago when I implemented TCM support but all I ever saw people load was to sideload algorithms into them from userspace.

12:29 <ardb> linusw__: i worked on a system in the past where we used it for DMA

12:29 <ardb> which was non-coherent so the SRAM was much faster

12:30 <ardb> for CPU intensive stuff it doesn't make a great deal of difference unless you are concerned about confidentiality

12:30 <ardb> (i.e., sniffing the DRAM signal lines)

12:31 <linusw__> hm that would be a pretty good reason to use it actually

12:32 <linusw__> yeah it will probably not speed up much if you already have l2cache which will be just as fast +/- overhead

12:33 <linusw__> for SRAM... if the system has actual TCM memory that is as fast as l1cache, which is really fast. But I hear people don't make them much anymore.

12:44 <ardb> yeah the system i implemented this on was a NXP arm9

12:44 <ardb> and this was 10+ years ago

12:50 <arnd> linusw__: I remember looking through a kernel tree for a Quantenna SoC that this

12:51 <arnd> This was a slow ARC CPU, not ARM, but the idea was the same: they must have manually profiled the kernel to see which functions were in the hot path for packet forwarding and moved them into ITCM at link time to improve performance of their routers

12:52 <linusw__> the reason I asked was because I added proper support for the SRAM in ux500 and it has 640K of SRAM, quite a lot, so was thinking why we kind of need a mechanism to just put that into the generic memory pool

12:52 <linusw__> Because we are using like ... 1K of it.

12:52 <robmur01> enough to run all of MS-DOS! :D

12:53 <linusw__> hehe

12:53 <arnd> linusw__: geertu mentioned the RZ/A1 the other day, this even has 9MB (iirc) of SRAM, which means you can either run it entirely from SRAM, or you use a larger external DRAM and the SRAM gets wasted

12:53 <linusw__> we have a DT attribute "pool" but it doesn't mean "global pool" instead "local pool you can use if you request it specially"

13:01 <arnd> linusw__: a low-effort method to move code into sram might be have a way to have an entire loadable module allocated from sram instead of using vmalloc, using a new flag to the finit_module() syscall

21:18 <marex> does any of you have any hint on SD cards with 'cache' support ?

21:19 <marex> I can literally find ONE such card in a bag of cards of all sorts -- Kingston CANVAS Go! Plus

21:19 <marex> $ find /sys -name ssr -exec grep -o '^.\{45\}[4567cdef]' {} \;

21:19 <marex> that should be a quick check to detect the cards -- checks all card SSR register bit 330

21:20 <marex> if you have any hit on that, I'd really love to know which SD card model that is

21:20 <marex> (and if that card works for you on linux 5.15.y or newer)