Looks good to me.

Can confirm it works with and without the bootloader adjustments.

These changes look good. I can confirm that this works.

I think we can name reserved regions, looking for a reserved-memory child node for the bootloader may be a good idea. If someone already has reserved-memory but it's for a non-bootloader purpose I think this will break.

I can confirm this boots on our RISC-V platform.

Use exit.

I haven't tested this, yet, either. It looks good though.

Looks good to me. Thanks for the cleanup!

Looks good to me. Thanks for this patch Mitchell!

Hi Ruslan,

Why cpu_check_mmu() does not work for you?

There's nothing harmful in this check long term, but from what I can tell, the reason we do that check is specific to the FU540 which, in principal, in my opinion, shouldn't be in the base kernel.

• Silence warning if PLATFORM isn't set
• Remove unnecessary headers in mp_machdep.c

Thanks for taking the time to think about it @mhorne and @philip! It's important to have these discussions. More flexibility doesn't necessarily equal "better".

One thing I think is unclear is how OpenSBI will fare when we start to see more platforms emerge. They provide a space for vendor-specific SBI extensions, and make it "easy" to port to new platforms, but we will have to see if vendors actually go for that. I think some of our kernel architecture for RISC-V will be driven by how well the SBI is adopted.

Yeah, I'm also really curious about how SBI is going to be implemented by vendors and it will undoubtedly drive our kernel development in regards to platform specificity moving forward. I'd probably prefer to see most of those "hacks" taken care of in SBI but it's not quite clear whether that's the case today.

agree with you in the general case, we don't want platform specific hacks scattered around the kernel, it's better to keep them in one location. I believe that "mmu-type" is intended to be a standard property in all RISC-V device trees going forward, and we could reliably check it for all platforms. See: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/riscv/cpus.yaml

Yeah, there's nothing necessarily harmful in this check from what I can tell. And as I said, at Axiado it's not harming us, but as Philip pointed out:

Currently the default RISC-V platform smells a lot like FU540.

It's more the principal that concerns me here rather than the direct impact of this specific check. I understand that you agree with this as well.

In D23877#525950, @mhorne wrote:

Okay, I'm not totally opposed to this interface, but I would like to better understand the motivation behind adopting it before we do so.
Does this solve a problem for some proprietary core? As I see it, this doesn't change anything for the FU540.

The arm directory is littered with these platform files, and this seems to be out of necessity due to the variety and inconsistency of standards that exists in its hardware. arm64 seems to have avoided the need for this interface so far, and I wonder if we can do the same. The Linux RISC-V world seems to be pushing hard for OpenSBI and keeping platform abstractions at the firmware level. We don't have to follow what Linux does, but I think we ought to be thoughtful in what we choose to do here. Thoughts?

In D21998#480535, @philip wrote:

While you're at it, it would be helpful to fix the dated arm-specific comments in subr_devmap.c. ;-)

Fix the header order (alphabetical)