Re: MIPS MMU state in early bootstrap stage (Fwd: Re: CVS commit: src/sys/dev/hpc)

Nick tells us that mips kernel is in directly-mapped kseg0
(like sh3's P1).

Thanks,
rin

On 2018/09/18 20:26, Rin Okuyama wrote:
> Hi,
> 
> Recently I fixed crash for hpcmips, where malloc() fails during attach
> of the console keyboard. I applied hack for hpcsh by uwe, in which
> const variables are overwritten by using __UNCONST(). uwe and I guess
> that this hack works (and malloc fails) because this is done before
> MMU is enabled, and kernel is directly mapped. Is this true?
> 
> Thanks,
> rin
> -------- Forwarded Message --------
> Date: Tue, 18 Sep 2018 13:35:45 +0300
> From: Valery Ushakov <[email protected]>
> To: Rin Okuyama <[email protected]>
> Cc: [email protected]
> Subject: Re: CVS commit: src/sys/dev/hpc
> 
> On Tue, Sep 18, 2018 at 18:52:34 +0900, Rin Okuyama wrote:
> 
>> On 2018/09/18 18:21, Valery Ushakov wrote:
>> > On Tue, Sep 18, 2018 at 12:17:41 +0900, Rin Okuyama wrote:
>> >> > > @@ -278,8 +279,10 @@ hpckbd_keymap_setup(struct hpckbd_core *
>> > > >         * XXX The way this is done is really wrong.  The __UNCONST()
>> > > >         * is a hint as to what is wrong.  This actually ends up modifying
>> > > >         * initialized data which is marked "const".
>> > > > +     *
>> > > >         * The reason we get away with it here is that on sh3 kernel
>> > > > -     * is directly mapped.
>> > > > +     * is directly mapped. For mips, read-only data is mapped
>> > > > +     * read/write at the moment.
>> > > >         */
>> >> Is this distinction necessary?  My guess would be that on mips the
>> > reason it works is exactly the same: the kernel is directly mapped
>> > i.e. we bypass MMU for these accesses.
>> >> If that's indeed the case, the "at the moment" part of the comment
>> > would be misleading, as there's no other moment in the future where it
>> > becomes false.
>> >> Please, can you clarify?
>>
>> Sorry for ambiguous expression. I'm not a mips guy and I should
>> confirm this before commit. This function is called before
>> pmap_bootstrap(). Does this mean that your argument is true?
>> If so, I will update the comment.
> 
> I think sh3 (the hardware) mostly copied mips memory organization, so
> I *guess* our kernel works more or less the same on both in this
> regard.  So I pmap_bootstrap will later set up the MMU for things like
> malloc, but - I *guess* - the kernel itself still remains directly
> mapped (va == pa, no MMU translation or permission checks).
> 
> But I know nothing about mips :)
> 
> -uwe
> 
>