Products > Embedded Computing

[solved] Linux: maximum bootable kernel size in PPC/32bit

<< < (7/8) > >>

DiTBho:

--- Quote from: nctnico on September 27, 2021, 12:50:40 am ---Alternatively it is possible that the kernel overwrites itself and may need more space allocated for itself.

--- End quote ---

Yes, it is possible, just as it is possible that during the boot sequence, just before jumping into kexec(), something goes wrong and the code that has to manage the flat device tree only sees 16 Mbytes at boot, which is enough with linkaddr = 0x0080.0000, but not enough with 0x0090.0000, and in this case that code for some weird reason can't map more ram(1).

That weird reason seems specific to ppc40x, a PPC750 doesn't exhibit this problem, but ... it's my speculation, and the code (assembly) is different.

It's funny, because if the code passes the point of no return kexec (), then it correctly sees 256MB of ram.

I mean, with linkaddr = 0x0080.0000 and a 7.5MB sized kernel, it works fine and "/proc/mem" correctly reports (256-8) MB available to the user


(1) it should arise some machine_exception at this point, but ... I cannot easily track it down because I don't have a jtag debugger. I need to hack the exception tables in order to put there something like a call to my "early_puts" so I can see something on the serial monitor, otherwise the machine simply silently dies without any clue.

DiTBho:
Solved  ;D ;D ;D

I asked to a PPC40x expert and we found an error in the TLB pre-initialization.
Rather PPC40x-specific.

Monkeh:
It wasn't something to do with systemd? The mind boggles.

DiTBho:

--- Quote from: Monkeh on September 27, 2021, 04:14:21 pm ---It wasn't something to do with systemd? The mind boggles.

--- End quote ---

LOL  :D

brucehoult:

--- Quote from: DiTBho on September 27, 2021, 04:00:40 pm ---Solved  ;D ;D ;D

I asked to a PPC40x expert and we found an error in the TLB pre-initialization.
Rather PPC40x-specific.

--- End quote ---

Can you explain it exactly?

In RISC-V land we used to get a fairly steady stream of people whose toy OS works fine on QEMU but fails on real hardware when they try to switch from Machine mode to Supervisor (or User) mode because QEMU was more lenient about PMP [1] initialization (if you didn't initialize PMP then it assumed you don't have one). A few months ago QEMU changed so that just like on most real hardware there is a PMP and you must initialize it. So now people's things that used to work on QEMU suddenly don't. But it's a whole lot easier to debug it there than have real hardware that silently dies.


[1] Physical Memory Protection. A hardware unit that provides RWX protection for typically 16 memory ranges without address translation. Even small microcontrollers usually have it if they provide User mode. At reset Machine mode can access everything and Supervisor and User mode can access nothing. On Linux (etc) machines it lets Machine mode lock even the Linux kernel(s) out of certain memory ranges. It works on physical addresses, not virtual addresses like the TLB (if you have one).

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version