On Thu, Feb 2, 2023 at 9:01 PM Alexandre Ghiti
wrote:
> Hi Frank,
>
> On Wed, Feb 1, 2023 at 4:49 PM Frank Chang wrote:
> >
> > On Tue, Jan 31, 2023 at 10:36 PM Alexandre Ghiti
> wrote:
> >>
> >> Currently, the max satp mode is set with the only constraint that it
> must be
> >> implemented in
Hi Frank,
On Wed, Feb 1, 2023 at 4:49 PM Frank Chang wrote:
>
> On Tue, Jan 31, 2023 at 10:36 PM Alexandre Ghiti
> wrote:
>>
>> Currently, the max satp mode is set with the only constraint that it must be
>> implemented in QEMU, i.e. set in valid_vm_1_10_[32|64].
>>
>> But we actually need to
On Tue, Jan 31, 2023 at 10:36 PM Alexandre Ghiti
wrote:
> Currently, the max satp mode is set with the only constraint that it must
> be
> implemented in QEMU, i.e. set in valid_vm_1_10_[32|64].
>
> But we actually need to add another level of constraint: what the hw is
> actually capable of,
On Tue, Jan 31, 2023 at 10:41 PM Alexandre Ghiti wrote:
>
> Currently, the max satp mode is set with the only constraint that it must be
> implemented in QEMU, i.e. set in valid_vm_1_10_[32|64].
>
> But we actually need to add another level of constraint: what the hw is
> actually capable of,
Currently, the max satp mode is set with the only constraint that it must be
implemented in QEMU, i.e. set in valid_vm_1_10_[32|64].
But we actually need to add another level of constraint: what the hw is
actually capable of, because currently, a linux booting on a sifive-u54
boots in sv57 mode
