[U-Boot-Users] UNCACHED_SDRAM macro issue

[U-Boot-Users] UNCACHED_SDRAM macro issue

[Luigi 'Comio' Mantellini]

Hi list,

I'm working on the porting of u-boot (1.3.1 from git) to a mips based
SoC. The port seems to work fine unless the UNCACHED_SDRAM macro (used
by do_bootm_linux).

Using the version from commit de9a738faa7c2f47286119c3bfebc3dfbfe7d86d
(that maps the addresses on KSEG1 instead on physical addresses) the
linux kernel is not able to start, while changing the macro to a
PHYSADDR(a) (how was before the commit) the linux kernel starts without
any problem.

In order to make my system bootable I changed the macro UNCACHED_SDRAM
from:

#define UNCACHED_SDRAM(a) KSEG1ADDR(a)

to

#define UNCACHED_SDRAM(a) PHYSADDR(a) (how defined before the commit
de9a738...)

What I need to change on my board specific u-boot in order to use the
KSEG1 address space?

thanks a lot

luigi



-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
 Ind. Dial Face   Email: luigi.mantellini at idf-hit.com

[U-Boot-Users] UNCACHED_SDRAM macro issue

[Shinya Kuribayashi]

Luigi 'Comio' Mantellini wrote:
> I'm working on the porting of u-boot (1.3.1 from git) to a mips based
> SoC. The port seems to work fine unless the UNCACHED_SDRAM macro (used
> by do_bootm_linux).
> 
> Using the version from commit de9a738faa7c2f47286119c3bfebc3dfbfe7d86d
> (that maps the addresses on KSEG1 instead on physical addresses) the
> linux kernel is not able to start, while changing the macro to a
> PHYSADDR(a) (how was before the commit) the linux kernel starts without
> any problem.
> 
> In order to make my system bootable I changed the macro UNCACHED_SDRAM
> from:
> 
> #define UNCACHED_SDRAM(a) KSEG1ADDR(a)
> 
> to
> 
> #define UNCACHED_SDRAM(a) PHYSADDR(a) (how defined before the commit
> de9a738...)

So it seems Alchemy-based SoC. if so,

> What I need to change on my board specific u-boot in order to use the
> KSEG1 address space?

what do you mean "in order to use the KSEG1 address space?" I'm not
familiar with Au1XXX, but you might need CONFIG_AU1X00 in your board
config. Some URLs added[1][2].

  Shinya

[1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32316/focus=32372
[2] http://www.linux-mips.org/wiki/Alchemy

[U-Boot-Users] UNCACHED_SDRAM macro issue

[Luigi 'Comio' Mantellini]

Hi Shinya,

see inline.

On gio, 2008-02-14 at 12:55 +0900, Shinya Kuribayashi wrote:
> Luigi 'Comio' Mantellini wrote:
...
> 
> So it seems Alchemy-based SoC. if so,
> 

No. I'm working on a SoC that uses a IP core from MIPS (mips4kec). The
mips core should be (formally) a standard mips core.

> > What I need to change on my board specific u-boot in order to use the
> > KSEG1 address space?
> 
> what do you mean "in order to use the KSEG1 address space?" I'm not
> familiar with Au1XXX, but you might need CONFIG_AU1X00 in your board
> config. Some URLs added[1][2].
> 

The CONFIG_AU1X00 doesn't work for me. from datasheet there aren't
differences between my SoC and the standalone mips4kec. This is the
memory map how depicted by the datasheet:

0x00000000--0x7fffffff KUser - Cached / Mapped
0x80000000--0x9fffffff KSEG0 - Cached / Unmapped
0xA0000000--0x9fffffff KSEG1 - Uncached / Unmapped
....

I think that on my application the UNCACHED_SDRAM should map the address
on KSEG1 (how it is now) but this simply doesn't work. Instead, using
the PHYSADDR(a) macro... the kernel is able to start.

I suspect that there are issues on cache management. Can be? 

Thanks a lot,

luigi

>   Shinya
> 
> [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32316/focus=32372
> [2] http://www.linux-mips.org/wiki/Alchemy
-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
 Ind. Dial Face   Email: luigi.mantellini at idf-hit.com

[U-Boot-Users] UNCACHED_SDRAM macro issue

[Shinya Kuribayashi]

Luigi 'Comio' Mantellini wrote:
>> So it seems Alchemy-based SoC. if so,
>>
> 
> No. I'm working on a SoC that uses a IP core from MIPS (mips4kec). The
> mips core should be (formally) a standard mips core.
> 
>>> What I need to change on my board specific u-boot in order to use the
>>> KSEG1 address space?
>> what do you mean "in order to use the KSEG1 address space?" I'm not
>> familiar with Au1XXX, but you might need CONFIG_AU1X00 in your board
>> config. Some URLs added[1][2].
>>
> 
> The CONFIG_AU1X00 doesn't work for me. from datasheet there aren't
> differences between my SoC and the standalone mips4kec. This is the
> memory map how depicted by the datasheet:
> 
> 0x00000000--0x7fffffff KUser - Cached / Mapped
> 0x80000000--0x9fffffff KSEG0 - Cached / Unmapped
> 0xA0000000--0x9fffffff KSEG1 - Uncached / Unmapped
> ....

Then I'm confused. Physical address map of your SoC will be helpful.
Where is the SDRAM mapped to?

> I think that on my application the UNCACHED_SDRAM should map the address
> on KSEG1 (how it is now) but this simply doesn't work. Instead, using
> the PHYSADDR(a) macro... the kernel is able to start.
> 
> I suspect that there are issues on cache management. Can be? 

IMHO it's not related to cache.

  Shinya

[U-Boot-Users] UNCACHED_SDRAM macro issue

[Shinya Kuribayashi]

Shinya Kuribayashi wrote:
>> I think that on my application the UNCACHED_SDRAM should map the address
>> on KSEG1 (how it is now) but this simply doesn't work. Instead, using
>> the PHYSADDR(a) macro... the kernel is able to start.
>>
>> I suspect that there are issues on cache management. Can be? 
> 
> IMHO it's not related to cache.

How do you set ERL and EXL bits? Please try to clear them at the
STATUS register initialization like:

 reset:
        <snip>

        /* STATUS register */
        mfc0    k0, CP0_STATUS
-       li      k1, ~ST0_IE
+       li      k1, ~(ST0_ERL | ST0_EXL | ST0_IE)
        and     k0, k1
        mtc0    k0, CP0_STATUS

ERL and EXL disable exceptions. Due to this spec, we are in danger
of overlooking something critical. If this change brings in new
exception(s), please fix the causes of them first. Hope this helps.

  Shinya

[U-Boot-Users] UNCACHED_SDRAM macro issue

[Shinya Kuribayashi]

Shinya Kuribayashi wrote:
> Shinya Kuribayashi wrote:
>>> I think that on my application the UNCACHED_SDRAM should map the address
>>> on KSEG1 (how it is now) but this simply doesn't work. Instead, using
>>> the PHYSADDR(a) macro... the kernel is able to start.
>>>
>>> I suspect that there are issues on cache management. Can be? 
>> IMHO it's not related to cache.
> 
> How do you set ERL and EXL bits? Please try to clear them at the
> STATUS register initialization like:
> 
>  reset:
>         <snip>
> 
>         /* STATUS register */
>         mfc0    k0, CP0_STATUS
> -       li      k1, ~ST0_IE
> +       li      k1, ~(ST0_ERL | ST0_EXL | ST0_IE)
>         and     k0, k1
>         mtc0    k0, CP0_STATUS
> 
> ERL and EXL disable exceptions. Due to this spec, we are in danger
> of overlooking something critical. If this change brings in new
> exception(s), please fix the causes of them first. Hope this helps.

Err, sorry for confusing example. Here's the right one:

diff --git a/cpu/mips/start.S b/cpu/mips/start.S
index c92b162..02797f7 100644
--- a/cpu/mips/start.S
+++ b/cpu/mips/start.S
@@ -211,14 +211,20 @@ reset:
 	mtc0	zero, CP0_WATCHLO
 	mtc0	zero, CP0_WATCHHI
 
+	/* Inhibit deffered WATCH exception */
+	mfc0	k0, CP0_CAUSE
+	li	k1, ~(1UL << 22)	# CP0.Cause.WP = 0
+	and     k0, k0, k1
+	mtc0	k0, CP0_CAUSE
+
 	/* STATUS register */
 #ifdef  CONFIG_TB0229
 	li	k0, ST0_CU0
 #else
 	mfc0	k0, CP0_STATUS
 #endif
-	li	k1, ~ST0_IE
-	and	k0, k1
+	ori	k0, (ST0_ERL | ST0_EXL | ST0_IE)
+	xori	k0, (ST0_ERL | ST0_EXL)
 	mtc0	k0, CP0_STATUS
 
 	/* CAUSE register */

Again, it's highy recommended to make sure U-Boot works fine under
interrupts enabled (CP0.Status.IE=1), before digging into UNCACHED_
SDRAM problem.

  Shinya

[U-Boot-Users] UNCACHED_SDRAM macro issue

[Luigi 'Comio' Mantellini]

Hi Shinya,

Thanks for your support and your code patches.
I'm waiting for a Lauterbach trace32 to debug deeply the code and
understand better the behaviour.
I'll send you my feedback next week.

Best regards,

luigi


On sab, 2008-02-16 at 18:06 +0900, Shinya Kuribayashi wrote:

> Shinya Kuribayashi wrote:
> > Shinya Kuribayashi wrote:
> >>> I think that on my application the UNCACHED_SDRAM should map the address
> >>> on KSEG1 (how it is now) but this simply doesn't work. Instead, using
> >>> the PHYSADDR(a) macro... the kernel is able to start.
> >>>
> >>> I suspect that there are issues on cache management. Can be? 
> >> IMHO it's not related to cache.
> > 
> > How do you set ERL and EXL bits? Please try to clear them at the
> > STATUS register initialization like:
> > 
> >  reset:
> >         <snip>
> > 
> >         /* STATUS register */
> >         mfc0    k0, CP0_STATUS
> > -       li      k1, ~ST0_IE
> > +       li      k1, ~(ST0_ERL | ST0_EXL | ST0_IE)
> >         and     k0, k1
> >         mtc0    k0, CP0_STATUS
> > 
> > ERL and EXL disable exceptions. Due to this spec, we are in danger
> > of overlooking something critical. If this change brings in new
> > exception(s), please fix the causes of them first. Hope this helps.
> 
> Err, sorry for confusing example. Here's the right one:
> 
> diff --git a/cpu/mips/start.S b/cpu/mips/start.S
> index c92b162..02797f7 100644
> --- a/cpu/mips/start.S
> +++ b/cpu/mips/start.S
> @@ -211,14 +211,20 @@ reset:
>  	mtc0	zero, CP0_WATCHLO
>  	mtc0	zero, CP0_WATCHHI
>  
> +	/* Inhibit deffered WATCH exception */
> +	mfc0	k0, CP0_CAUSE
> +	li	k1, ~(1UL << 22)	# CP0.Cause.WP = 0
> +	and     k0, k0, k1
> +	mtc0	k0, CP0_CAUSE
> +
>  	/* STATUS register */
>  #ifdef  CONFIG_TB0229
>  	li	k0, ST0_CU0
>  #else
>  	mfc0	k0, CP0_STATUS
>  #endif
> -	li	k1, ~ST0_IE
> -	and	k0, k1
> +	ori	k0, (ST0_ERL | ST0_EXL | ST0_IE)
> +	xori	k0, (ST0_ERL | ST0_EXL)
>  	mtc0	k0, CP0_STATUS
>  
>  	/* CAUSE register */
> 
> Again, it's highy recommended to make sure U-Boot works fine under
> interrupts enabled (CP0.Status.IE=1), before digging into UNCACHED_
> SDRAM problem.
> 
>   Shinya
> 

Industrie Dial Face S.p.A.
Luigi Mantellini
R&D - Software
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI), Italy
Tel.:   +39 02 5167 2813
Fax:    +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080216/0165b4f9/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idf_logo.gif
Type: image/gif
Size: 4122 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080216/0165b4f9/attachment.gif 

[U-Boot-Users] UNCACHED_SDRAM macro issue

[Luigi 'Comio' Mantellini]

Hi Shinya,

I found the error... but it's not an u-boot issue. I'm using a (old)
customized linux 2.6.10 (from my vendor) that also adds the 0xa0000000
offset to the pointers passed by u-boot, assuming that address is
expressed in termos of physical address. I corrected the linux code
masking and (after) addind the segment.

Thanks a lot for your help.


luigi


On sab, 2008-02-16 at 18:06 +0900, Shinya Kuribayashi wrote:

> Shinya Kuribayashi wrote:
> > Shinya Kuribayashi wrote:
> >>> I think that on my application the UNCACHED_SDRAM should map the address
> >>> on KSEG1 (how it is now) but this simply doesn't work. Instead, using
> >>> the PHYSADDR(a) macro... the kernel is able to start.
> >>>
> >>> I suspect that there are issues on cache management. Can be? 
> >> IMHO it's not related to cache.
> > 
> > How do you set ERL and EXL bits? Please try to clear them at the
> > STATUS register initialization like:
> > 
> >  reset:
> >         <snip>
> > 
> >         /* STATUS register */
> >         mfc0    k0, CP0_STATUS
> > -       li      k1, ~ST0_IE
> > +       li      k1, ~(ST0_ERL | ST0_EXL | ST0_IE)
> >         and     k0, k1
> >         mtc0    k0, CP0_STATUS
> > 
> > ERL and EXL disable exceptions. Due to this spec, we are in danger
> > of overlooking something critical. If this change brings in new
> > exception(s), please fix the causes of them first. Hope this helps.
> 
> Err, sorry for confusing example. Here's the right one:
> 
> diff --git a/cpu/mips/start.S b/cpu/mips/start.S
> index c92b162..02797f7 100644
> --- a/cpu/mips/start.S
> +++ b/cpu/mips/start.S
> @@ -211,14 +211,20 @@ reset:
>  	mtc0	zero, CP0_WATCHLO
>  	mtc0	zero, CP0_WATCHHI
>  
> +	/* Inhibit deffered WATCH exception */
> +	mfc0	k0, CP0_CAUSE
> +	li	k1, ~(1UL << 22)	# CP0.Cause.WP = 0
> +	and     k0, k0, k1
> +	mtc0	k0, CP0_CAUSE
> +
>  	/* STATUS register */
>  #ifdef  CONFIG_TB0229
>  	li	k0, ST0_CU0
>  #else
>  	mfc0	k0, CP0_STATUS
>  #endif
> -	li	k1, ~ST0_IE
> -	and	k0, k1
> +	ori	k0, (ST0_ERL | ST0_EXL | ST0_IE)
> +	xori	k0, (ST0_ERL | ST0_EXL)
>  	mtc0	k0, CP0_STATUS
>  
>  	/* CAUSE register */
> 
> Again, it's highy recommended to make sure U-Boot works fine under
> interrupts enabled (CP0.Status.IE=1), before digging into UNCACHED_
> SDRAM problem.
> 
>   Shinya
> 

Industrie Dial Face S.p.A.
Luigi Mantellini
R&D - Software
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI), Italy
Tel.:   +39 02 5167 2813
Fax:    +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com
GPG fingerprint: 3DD1 7B71 FBDF 6376
1B4A
                 B003 175F E979 907E
1650
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080228/0b332f66/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idf_logo.gif
Type: image/gif
Size: 4122 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080228/0b332f66/attachment.gif 

[U-Boot-Users] UNCACHED_SDRAM macro issue

[Shinya Kuribayashi]

Hi Luigi,

Luigi 'Comio' Mantellini wrote:
> Hi Shinya,
> 
> I found the error... but it's not an u-boot issue. I'm using a (old)
> customized linux 2.6.10 (from my vendor) that also adds the 0xa0000000
> offset to the pointers passed by u-boot, assuming that address is
> expressed in termos of physical address. I corrected the linux code
> masking and (after) addind the segment.

I appricate your letting me know about that.

Thanks,

  Shinya