14:32 <apalos> sjg1: around?

14:32 <sjg1> apalos: Yes, hi

14:32 <apalos> i've sent a new version of that mmu patches

14:33 <apalos> Do you understand why I cant use cpu_ops

14:33 <apalos> because it would be cleaner, but we need to sort out when that thing gets called first

14:37 <sjg1> Could you make the extra output an option to meminfo, so it only displays the plain memory map by default?

14:37 <sjg1> It seems that at least the printing could be done with a CPU op?

14:37 <apalos> printing maybe but I'd like to make a change in the whole DM logic, because that's what been stopping us from using it in various places

14:38 <apalos> For the printing, what peopler usually refer as the 'memory map'

14:38 <apalos> is what meminfo prints with my patches on top, so I really think it's better to keep it

14:38 <apalos> I moved the print around as you asked so it only prints with that option enabled

14:39 <apalos> as for printing, I think we are doing a bit too much, cpu_ops is not about printing the mmu memory map....

14:39 <apalos> It should be just cpu_ops

14:39 <apalos> On the cpu_ops themselves now though

14:39 <apalos> I posted a branch which impelments the *same* functionality using cpu_ops

14:40 <apalos> But it works on 5 boards if we someone compiles with U-Boot DTs, and 0 boards if someone usese the upstream DT

14:40 <apalos> For things that are *not* really drivers, like the cpu

14:40 <apalos> Why cant we have the DM ignore the DT match if it doesnt find any and install regardless?

14:40 <apalos> that would make it instantly usable

14:51 <apalos> well not ingore, it can still match if it finds something, but for certain things that dont need drviers like the cpu, install default ops if there's no match

15:10 <sjg1> apalos: If Tom is happy I don't mind what you do

15:10 <sjg1> For CPU if you don't have a DT node how will you know which CPU type it is?

15:12 <apalos> you are compiling for a very specific architecture

15:12 <apalos> most of the arm cpu are the same cache wise, so is x86 so is risc-v

15:15 <apalos> but that's ok, I'll wait for Tom to see if he is ok or not

15:15 <qschulz> marex: had a random thought about your TF-A in kernel fit setup. Considering we can pass an FDT to TF-A and that U-Boot and the kernel can have a different FDT, I was wondering if there was a chance we could load the kernel FDT+FDTO from the kernel fit and pass it to TF-A, and then continue to boot

15:15 <qschulz> have no usecase for it though, so take this as a brain dump :)

15:16 <qschulz> (would also be an issue on Rockchip because upstream kernel DTB are now gaining symbols by default whenever they have a overlay that cna be applied and they won't fit into the space allocated by TF-A for the FDT anymore :)

17:18 <Tartarus> Yes, I'm not really sure that drivers/cpu/cpu-uclass.c and related is the right path for the feature. The uclass seems to be about providing some per-vendor descriptive information and this is an architectural feature that exists, or not. If we *really* needed some runtime checking I'm sure there's some bits to check