8xx's IMMR can not be 0x12200000?

8xx's IMMR can not be 0x12200000?

[caokai]

     I am porting a custom mpc8xx board . using PPCBOOT + MontaVista
Linux 2.1(2.4.17).
     I found that if I set IMMR to 0x12200000 in PPCBOOT and Linux. The
linux kernel can startup,but  will stop in exece("/sbin/init").I use a
bdi2000 and found that it deadloop in do_page_fault.
     But if I set IMMR to 0xFF000000, the linux kernel can work good.
     I think this limitation must be somewhere in the
arch/ppc/kernel/head_8xx.S.right?

regards
caokai


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 8xx's IMMR can not be 0x12200000?

[Dan Malek]

caokai wrote:

>      But if I set IMMR to 0xFF000000, the linux kernel can work good.
>      I think this limitation must be somewhere in the
> arch/ppc/kernel/head_8xx.S.right?

It's a requirement to be mapped at a very high address like this for
the kernel to work properly.  This is due to the early memory mapping
required by the kernel to access devices in this space.  There is lots
of discussion about this if you search the e-mail archives and FAQs.

	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

WRITE_THRU on 8xx missing

[Joakim Tjernlund]

I am trying to create a cached memory mapping which is in WRITETHRU using ioremap().
But in the latest PPC kernel for a mpc8xx target there is no flag for WRITETHRU (_PAGE_WRITETHRU).

Why is it gone? Is there a replacement flag?
I want to use this mapping to do burst reads but single writes for a flash device.

 Joakim


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: WRITE_THRU on 8xx missing

[Joakim Tjernlund]

I just noticed that _PAGE_WRITETHRU is defined in the linuxppc_2_4 tree but not in
the linuxppc_2_4_devel tree, which is the one I am using :-(. Has this "function" been removed ,
never to return or is the devel tree in a flux now for mpc8xx?

If it has been removed, please reconsider adding it again. Now that burstable flash devices are
common and there is a flash based FS(JFFS2) in the kernel, I think there will be a need for
this functionality.

     Joakim

>
>
> I am trying to create a cached memory mapping which is in WRITETHRU using ioremap().
> But in the latest PPC kernel for a mpc8xx target there is no flag for WRITETHRU (_PAGE_WRITETHRU).
>
> Why is it gone? Is there a replacement flag?
> I want to use this mapping to do burst reads but single writes for a flash device.
>
>  Joakim
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: WRITE_THRU on 8xx missing

[Dan Malek]

Joakim Tjernlund wrote:

> I just noticed that _PAGE_WRITETHRU is defined in the linuxppc_2_4 tree but not in
> the linuxppc_2_4_devel tree, which is the one I am using :-(. Has this "function" been removed ,
> never to return or is the devel tree in a flux now for mpc8xx?

I don't know what we will do.  We always seems to be running out of control bits
in the PTE, so this is the first one to go if we need one for something else.
The writethrough mode is also a pain to support dynamically because it requires
special code in the tlb miss exception to load/clear bits in the PMD/L1 descriptor.
Adding this code nearly doubles the size of the exception handler, when you want
minimal instructions, for a feature (almost) no one uses.  At best, the writethrough
mode may return when I finish the large pages someday, and will be a special case
that covers a modulo 4M space on a 4M boundary (which I don't yet know how we
would allocate).

For burst flash, I suggest you read the archives for a discussion where you
double map the cache into a copyback mode space read and an uncached space
for write.  You will then invalidate during a write operation.  This would
maximize performance and require no VM or cache management changes.


>>I want to use this mapping to do burst reads but single writes for a flash device.

Are you sure writethough mode will do this?  I don't think it will as I believe
any cache enabled mode will burst.  To prevent burst you have to run with
caches disabled or have it inhibited in the memory controller.  Check it out.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: WRITE_THRU on 8xx missing

[Joakim Tjernlund]

>
> Joakim Tjernlund wrote:
>
> > I just noticed that _PAGE_WRITETHRU is defined in the linuxppc_2_4 tree but not in
> > the linuxppc_2_4_devel tree, which is the one I am using :-(. Has this "function" been removed ,
> > never to return or is the devel tree in a flux now for mpc8xx?
>
> I don't know what we will do.  We always seems to be running out of control bits
> in the PTE, so this is the first one to go if we need one for something else.
> The writethrough mode is also a pain to support dynamically because it requires
> special code in the tlb miss exception to load/clear bits in the PMD/L1 descriptor.
> Adding this code nearly doubles the size of the exception handler, when you want
> minimal instructions, for a feature (almost) no one uses.  At best, the writethrough
> mode may return when I finish the large pages someday, and will be a special case
> that covers a modulo 4M space on a 4M boundary (which I don't yet know how we
> would allocate).

I see, I can live with that. If you do impl. this
4M space on a 4M boundary is fine by me. My flashes are much bigger.

>
> For burst flash, I suggest you read the archives for a discussion where you
> double map the cache into a copyback mode space read and an uncached space
> for write.  You will then invalidate during a write operation.  This would
> maximize performance and require no VM or cache management changes.

Yes I known, but I was hoping to avoid that.

>
>
> >>I want to use this mapping to do burst reads but single writes for a flash device.
>
> Are you sure writethough mode will do this?  I don't think it will as I believe
> any cache enabled mode will burst.  To prevent burst you have to run with
> caches disabled or have it inhibited in the memory controller.  Check it out.

Well, the 860 User's Manual chapter 6.3 say so(In my opinion) and I asked Motorola
also and they confirmed that. If you think about it is the only way to operate since
the write needs to update the memory immediatly.

BTW, Motorola informs me that if you set the GUARD bit, I/O will be ordered. That way you can
avoid using mb() or wmb().

>
> Thanks.
>
   Thanks for your reply

           Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/