Subject: errata 2.3.39

From: S A McConnell <[email-masked]>
Date: Thu, 02 Mar 2000 08:52:09 -0600

I have ben studying the ARM 2.3.39 code and have these questions and
comments.

Any other thoughts?

head-armv.S, setup.c, proc-arm6,7.S:
  Why does the system use dynamic detection of processor id's and
  architectures? The code would be simpler and faster if configuration
was
  used to specify those values. Making it no longer necessary to loop
through
  these lists. (SAM)

  If the lists are still needed should the lists in head-armv.S and
setup.c be
  collapsed into one list?

head-armv.S:
  Uses magic numbers in __lookup_processor_type '#36' and in
  __lookup_architecture_type '16'. Should these be replaced with
calculated
  constant definitions? Where should they be defined? (procinfo.h, ???)
(SAM)

  The macro 'inituart' is defined but never referenced. Should it be
moved to
  debug-armv.S?

setup.c:

  setup_processor() - The 'for loop' is repeating what was just done in
  __entry in head-armv.S. It appears to be impossible to make the "CPU
  configuration botched..." message be emitted. (SAM)

S A McConnell

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]
++        Please use [email-masked] for           ++
++                        kernel-related discussions.                      ++

---

From: Philip Blundell <[email-masked]>
Date: Thu, 02 Mar 2000 18:44:11 +0000

>  used to specify those values. Making it no longer necessary to loop

Speed is not a big deal for startup code that is only executed once.  It's 
useful to be able to run the same kernel on more than one machine and CPU 
type.

>  If the lists are still needed should the lists in head-armv.S and

Yes, very probably.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 2 Mar 2000 19:14:46 +0000 (GMT)

S A McConnell writes:
>   was used to specify those values. Making it no longer necessary to
>   loop through these lists.

What's the point in making a lookup which only happens once fast?  The
lists are needed to cope with kernels which can run on multiple
architectures.  (eg, it is possible to compile one kernel for EBSA285,
CATS and NetWinder machines and have it work on all of these).  Also,
some architectures may have different processors contained within.
(eg, RiscPC may be fitted with ARM6, ARM7 or StrongARM).

Without the dynamic detection, you'd probably end up with a total of
around 30 kernels only able to run on a specifically configured
machine.

>   setup.c be collapsed into one list?

Yes and no.  The processor and architecture lists must be independent.
I think you're thinking of the architecture lists more.

>   calculated constant definitions? Where should they be defined?
>   (procinfo.h, ???)

The '16' is defined as the entry type of an assembly generated table
(contained within the same file and indeed within close proximity) -
there is absolutely no need to do anything different.  Anyone modifing
the code should realise what this is doing.

The '36' is commented as a sizeof (struct).  Since sizeof() is a C thing,
it doesn't work in assembler.

>   moved to debug-armv.S?

I don't have this.

>   configuration botched..." message be emitted.

Correct, but with one difference.  The one in head-armv.S is running in
a different memory space, accessing the data via a physical address,
whereas the one in setup.c is using virtual addresses.

It is possible to use the assembler version and convert the address, so
this could be done.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |