sifive / freedom-metal

Bare Metal Compatibility Library for the Freedom Platform
Other
154 stars 47 forks source link

[ESAT-400] Add Mallard-specific CPU driver to program the TwinJet prefetcher #421

Closed zongbox closed 2 years ago

zongbox commented 3 years ago

Add HWPF support. This patch not only supports HWPF, but also creates an initial function for secondary harts. HWPF CSRs are per-harts, each harts should initialize them by themselves. In addition, we improve the METAL_CPU_GET_CSR/METAL_CPU_SET_CSR macros to support CSRs using CSR numbers, it can support using #define macro names of CSR numbers and accessing newly added CSRs even if toolchain does not recognize newly addes CSRs by name.

zongbox commented 3 years ago

This PR is very confusing. in freedom metal you have 2 level. first is the "metal driver", second is generic (functionnal) driver. for example you have uart part into src/drivers directory (mainly the access of the registry of a block IP, for example __metal_driver_sifive_uart0_putc). One part into src/ (where you have upper level API, for example metal_uart_putc. I did not see something equivalent in your proposal.

Thank you for clarifying that :) Apart from the rule as you mentioned, the thought in this patch is that the HWPF is for per-CPU as we can see that hwpf-xxx properties are in the CPU nodes, and it seems to me that the stuff in src/drivers might be for peripheral such as soc { node in DTS, hence I had no add something in src/drivers, the PMP and cache seems to be also implemented by that way. I'm afraid that I'm misunderstanding. Please correct me and let me know if we might as well change that. Thanks.

zongbox commented 3 years ago

Changed in v2:

paul-walmsley-sifive commented 3 years ago

Just left a comment in the other PR. Is there any way to enable this as part of a Mallard CPU "driver", such that if the DT string "sifive,mallard0" is present, then the prefetcher code is used ?

zongbox commented 3 years ago

Changed in v3:

zongbox commented 3 years ago

There is a new commit in master branch, it will cause the conflict with this PR, so I rebase code on top of master, and re-push again.

paul-walmsley-sifive commented 3 years ago

Hi @e-puerto, looks like you still have some remaining runresolved review comments on this patch, according to Github. Could you take a quick look and see if these patches are OK to merge, or if there are still significant issues that need to be fixed? If there are no high priority issues to fix, would like to get these merged by the end of the week