OSK5912 cpu_is_omap5912() FALSE

OSK5912 cpu_is_omap5912() FALSE

[Smith, Stephen]

OSK5912/Linux 2.6.13

 

There is a discrepancy in cpu.h and what my OSK5912 reflects.

 

cpu.h reflects:

IS_OMAP_TYPE(5912, 0x1611)

 

Here is my data from boot, which reflects the correct values:

OMAP_DIE_ID_0: 0xbfd20610

OMAP_DIE_ID_1: 0x8e059089 DIE_REV: 2

OMAP_PRODUCTION_ID_0: 0x00aaaafc

OMAP_PRODUCTION_ID_1: 0x00016cbe JTAG_ID: 0x6cbe

OMAP32_ID_0: 0x03320500

OMAP32_ID_1: 0x2b65f02f

JTAG_ID: 0xb65f DIE_REV: 2

OMAP162123 revision 2 handled as 16xx id: 8e059089bfd20610

 

 

Is arch-omap/cpu.h wrong, or is there something more here?  With

code as it was patched, cpu_is_omap5912() fails.  Sign of problem

is the inability to reboot the board (# reboot).  I can fix by

changing cpu.h to:

 

IS_OMAP_TYPE(5912, 0x1621)

 

I don't want to blindly change because I do not know history of OMAP5912

and it is possible some previous rev had id'ed as 1611.

It could also be fixed by adding another type check to arch_reset(), but

that may include 1621 types that do not require or want workaround.

 

Any insight would be appreciated.

 

Thanks,

Stephen

Re: OSK5912 cpu_is_omap5912() FALSE

[Tony Lindgren]

* Smith, Stephen <smsmith@ti.com> [060202 15:14]:
> OSK5912/Linux 2.6.13
> 
>  
> 
> There is a discrepancy in cpu.h and what my OSK5912 reflects.
> 
>  
> 
> cpu.h reflects:
> 
> IS_OMAP_TYPE(5912, 0x1611)
> 
>  
> 
> Here is my data from boot, which reflects the correct values:
> 
> OMAP_DIE_ID_0: 0xbfd20610
> 
> OMAP_DIE_ID_1: 0x8e059089 DIE_REV: 2
> 
> OMAP_PRODUCTION_ID_0: 0x00aaaafc
> 
> OMAP_PRODUCTION_ID_1: 0x00016cbe JTAG_ID: 0x6cbe
> 
> OMAP32_ID_0: 0x03320500
> 
> OMAP32_ID_1: 0x2b65f02f
> 
> JTAG_ID: 0xb65f DIE_REV: 2
> 
> OMAP162123 revision 2 handled as 16xx id: 8e059089bfd20610
> 
>  
> 
>  
> 
> Is arch-omap/cpu.h wrong, or is there something more here?  With
> 
> code as it was patched, cpu_is_omap5912() fails.  Sign of problem
> 
> is the inability to reboot the board (# reboot).  I can fix by
> 
> changing cpu.h to:
> 
>  
> 
> IS_OMAP_TYPE(5912, 0x1621)
> 
>  
> 
> I don't want to blindly change because I do not know history of OMAP5912
> 
> and it is possible some previous rev had id'ed as 1611.
> 
> It could also be fixed by adding another type check to arch_reset(), but
> 
> that may include 1621 types that do not require or want workaround.

We should really get rid of cpu_is_omap5912() and just use
cpu_is_omap16xx().

If 1710 is excluded, we should use something like:

(cpu_is_omap16xx() && !cpu_is_omap1710())

In some cases we may need to test for machine_is_omap_osk() instead.

Tony

RE: OSK5912 cpu_is_omap5912() FALSE

[Hunter, Jon]

Hi Stephen, 

> -----Original Message-----
> From: 
> linux-omap-open-source-bounces+jon-hunter=ti.com@linux.omap.co
> m 
> [mailto:linux-omap-open-source-bounces+jon-hunter=ti.com@linux
> .omap.com] On Behalf Of Smith, Stephen
> Sent: Thursday, February 02, 2006 5:14 PM
> To: linux-omap-open-source@linux.omap.com
> Subject: OSK5912 cpu_is_omap5912() FALSE
> 
> OSK5912/Linux 2.6.13
> 
>  
> 
> There is a discrepancy in cpu.h and what my OSK5912 reflects.
> 
>  
> 
> cpu.h reflects:
> 
> IS_OMAP_TYPE(5912, 0x1611)
> 
>  
> 
> Here is my data from boot, which reflects the correct values:
> 
> OMAP_DIE_ID_0: 0xbfd20610
> 
> OMAP_DIE_ID_1: 0x8e059089 DIE_REV: 2
> 
> OMAP_PRODUCTION_ID_0: 0x00aaaafc
> 
> OMAP_PRODUCTION_ID_1: 0x00016cbe JTAG_ID: 0x6cbe
> 
> OMAP32_ID_0: 0x03320500
> 
> OMAP32_ID_1: 0x2b65f02f
> 
> JTAG_ID: 0xb65f DIE_REV: 2
> 
> OMAP162123 revision 2 handled as 16xx id: 8e059089bfd20610
> 
>  
> 
>  
> 
> Is arch-omap/cpu.h wrong, or is there something more here?  With
> 
> code as it was patched, cpu_is_omap5912() fails.  Sign of problem
> 
> is the inability to reboot the board (# reboot).  I can fix by
> 
> changing cpu.h to:
> 
>  
> 
> IS_OMAP_TYPE(5912, 0x1621)
> 
>  
> 
> I don't want to blindly change because I do not know history 
> of OMAP5912
> 
> and it is possible some previous rev had id'ed as 1611.
> 
> It could also be fixed by adding another type check to 
> arch_reset(), but
> 
> that may include 1621 types that do not require or want workaround.
> 
>  
> 
> Any insight would be appreciated.


The initial 5912 devices were based on the 1611 devices. However, the
production version of the 5912 is based on the 1621. From a
user/functional perspective there is not much difference between the
devices. There were a lot of silicon issues that were fixed and
performance improvements made. 

It appears that you have the production 5912 silicon and so 1621 makes
sense. 

Regards,
Jon