Re: CVS: blob/include/blob sa1100.h,1.2,1.3

[Erik M. <J.A...@it...>]

On Thu, Jul 25, 2002 at 10:30:03AM -0700, Christopher Hoover wrote:
> Update of /cvsroot/blob/blob/include/blob
> In directory usw-pr-cvs1:/tmp/cvs-serv26723
> 
> Modified Files:
> 	sa1100.h 
> Log Message:

> our own sa1100.h (created from linux-2.5.26-rmk1); safe to include in
> assembly now (define __ASSEMBLY__); does not conflict with memsetup.h

No. The memsetup.h argument doesn't hold, sa1100.h and memsetup.h were
never meant to be used together. memsetup.h was written for
memsetup-sa1110.S with the idea in mind that a cleaned up version of
memsetup-sa1100.S could use the same include file. In retrospect
memsetup.h should have been named memsetup-sa11x0.h.

We don't even need sa1100.h in assembly. The Digital people thought
it would be cool to be able to use the same include file in C and
assembly, but they were plain wrong. You don't *want* C includes in
assembly simply because assembly has a programming style that
completely differs from C.

SA-1100.h defines MDCNFG & friends as absolute values, but the assembly
memsetup code needs offsets relative to the memory controller base
register so we have to define it ourselves anyway. If we use MDCNFG
defined as in SA-1100.h, we need lots of code to reach exactly the same
goal and we loose a lot in clarity and readability:

        /* Set up the SDRAM */
        ldr     r0, MEM_REG_BASE
        adr     r1, MEMORY_CONFIG

        ldr     r2, [r1, #MDCNFG ]
        str     r2, [r0, #MDCNFG ]

        ldr     r2, [r1, #MDCAS00 ]
        str     r2, [r0, #MDCAS00 ]

Would become:

        /* Set up the SDRAM */
	adr	r1, MEMORY_CONFIG

	ldr	r0, MDCNFG
	ldr	r2, [r1, 0x00]
	str	r2, [r0]

	ldr	r0, MDCAS0
	ldr	r2, [r1, 0x04]
	STR	r2, [r0]

I'd rather see the elegancy of the first version; having a specially
edited sa1100.h makes things worse.


Now about the kernel include file problem:

Yes, we have problems with changing include files in the kernel, but
I'd rather solve this problem the Right Way [tm]. Stefan, Russ, and I
have discussed this a while ago on IRC, and the way to solve this issue
goes like this: take a set of include files from a stable kernel
version (2.4.18-rmk7 or so, not a moving target like 2.5.x), put those
include files into the blob source tree and stay with that. Don't put
the kernel include files in include/ , but in linux-include/ . Normal
users get the known stable kernel headers from linux-include/ , but the
hackers among us can still override that with the --with-linux-prefix
configure flag. Using unmodified kernel headers has other advantages:
reduced chance on errors due to editing, and drop-in updates. All this
boils down to the same thing: better long term maintainability.

Please back out your patches, they try to solve a non-existent problem.


Erik

PS: the #blob IRC channel moved from OPN to OFTC. See www.oftc.net for
  an IRC server near you, or just point your IRC client to irc.oftc.net.

-- 
J.A.K. (Erik) Mouw
Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/