- User Since
- Sep 9 2019, 5:17 PM (140 w, 4 d)
Nov 6 2020
Oct 13 2020
Oct 5 2020
Looks good to me.
Oct 2 2020
Sep 23 2020
Aug 18 2020
Aug 17 2020
Jun 6 2020
Can confirm it works with and without the bootloader adjustments.
Apr 15 2020
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.
Apr 2 2020
Mar 30 2020
Mar 24 2020
I haven't tested this, yet, either. It looks good though.
Mar 23 2020
Looks good to me. Thanks for the cleanup!
Mar 22 2020
Looks good to me. Thanks for this patch Mitchell!
Mar 20 2020
Mar 12 2020
Mar 9 2020
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.
Mar 5 2020
- Silence warning if PLATFORM isn't set
- Remove unnecessary headers in mp_machdep.c
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.
Mar 2 2020
Feb 29 2020
Feb 28 2020
Oct 15 2019
Oct 12 2019
Oct 10 2019
Fix the header order (alphabetical)