07:24 <linusw__> marex: :D

07:45 <javierm> marex, linusw__: it is indeed awesome info

07:52 <Xogium> linusw__: I just read your articles, they're great indeed

07:53 <geertu> tambarus: correct, cpu bringup does not use CFI FLASH, but makes the first pages of the FLASH inaccessible (BTW, I see wrong data with mtd-rom, too)

07:54 <Xogium> I don't understand lots of asm, but the explanations are more than good enough to get an idea ;)

07:54 <geertu> Probe deferral of CFI FLASH would not help, the FLASH is already probed after secondary CPU startup.

07:55 <geertu> The special mapping for the CPU startup code could be disabled after all cores have been bringed up. After that, FLASH becomes fully accessible.

07:57 <geertu> However, if CPU cores are offlines and onlined at run-time, the special mapping has to be reinstantiated temporarily again, thus any FLASH accesses must be prevented temporarily, too.

07:58 <geertu> I'm wondering if there are any other SMP SoCS that suffer from similar issues...

08:02 <geertu> TLDR: SMP bringup code relies on remapping the first page to the actual CPU startup code in RAM, breaking access to FLASH (or a MMIO device) at physical addresss zero.

08:02 <geertu> I guess the simplest "solution" is to disable in DT any device at address zero when SMP is used.

08:03 <ardb> geertu: but the booting CPU wouldn't access the flash at that point, right?

08:03 <geertu> ardb: No, it wouldn't

08:04 <geertu> But other CPUs might.

08:04 <ardb> so you could just map that page in the ID map page tables that are used to enable the MMU

08:04 <ardb> ehm never mibnd

08:04 <ardb> i guess this is not a MMU mapping but some special SoC control?

08:08 <geertu> ardb: Yes, configured through a special register

15:32 <phh> Hi. I would like to make a dma-heap based on another one, without needing to rewrite an allocator: I want to make a dma-heap that allocates over cma its buffer when needed, so when there is 0 allocation, it has nothing allocated, but as soon as there is 1 allocation on the heap, it allocates its constant size over cma (say 256MB). The goal is two fold: this is for DRM Secure Video Path, this heap would be always protected by trustzone from being accessed. Also

15:32 <phh> the memory would be pre-allocated, so when video codec moves from 240p to 2160p the memory allocations are guaranteed to succeed fast. I didn

15:33 <phh> I didn't find any framework in the Linux kernel to do anything close to that, but maybe I missed it?