[U-Boot-Users] nomen est omen: i.MX or mc9329 ?

[U-Boot-Users] nomen est omen: i.MX or mc9329 ?

[Steven Scholz]

Hi there,

how will we call the Motorola i.MX processors in future?

Will it be "imx", "i.MX", "iMX" or MC9328MX{1,21,L}?


Should we call the eval board "mx1ads" oder "M93281ADS" as Motorola does and 
as it is printed on it?

How are the plans for linux-2.6 port?
We should keep it consistent...

Thanks a million!

Steven

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Robert Schwebel]

On Sun, Jun 27, 2004 at 01:25:40PM +0200, Steven Scholz wrote:
> how will we call the Motorola i.MX processors in future?
> 
> Will it be "imx", "i.MX", "iMX" or MC9328MX{1,21,L}?

The original 2.4 Linux port was mx1ads which is definitely wrong: it is
the name of the Motorola development board. Following the scheme of the
other architectures and platforms I would vote for imx. 

> Should we call the eval board "mx1ads" oder "M93281ADS" as Motorola does 
> and as it is printed on it?

mx1ads would be fine for me. 

> How are the plans for linux-2.6 port?
> We should keep it consistent...

I'll post our patch in five minutes...

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Steven Scholz]

Robert Schwebel wrote:
> On Sun, Jun 27, 2004 at 01:25:40PM +0200, Steven Scholz wrote:
> 
>>how will we call the Motorola i.MX processors in future?
>>
>>Will it be "imx", "i.MX", "iMX" or MC9328MX{1,21,L}?
> 
> The original 2.4 Linux port was mx1ads which is definitely wrong: it is
> the name of the Motorola development board. Following the scheme of the
> other architectures and platforms I would vote for imx. 

Following the scheme of the other architectures and platforms _and_ speaking 
as a hardware developer I would vote for MC9328MX...
Or at least "iMX".

>>Should we call the eval board "mx1ads" oder "M93281ADS" as Motorola does 
>>and as it is printed on it?
> 
> 
> mx1ads would be fine for me. 

(see above) M93281ADS.

Anyone else? ;-)

Steven

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[llandre]

>>>how will we call the Motorola i.MX processors in future?
>>>
>>>Will it be "imx", "i.MX", "iMX" or MC9328MX{1,21,L}?
>>The original 2.4 Linux port was mx1ads which is definitely wrong: it is
>>the name of the Motorola development board. Following the scheme of the
>>other architectures and platforms I would vote for imx.
>
>Following the scheme of the other architectures and platforms _and_ 
>speaking as a hardware developer I would vote for MC9328MX...
>Or at least "iMX".

I vote for MC9328MX{1,21,L}.


>>>Should we call the eval board "mx1ads" oder "M93281ADS" as Motorola does 
>>>and as it is printed on it?
>>
>>mx1ads would be fine for me.
>
>(see above) M93281ADS.

I think the best solution is to keep the name printed on the PCB 
(M9328MX1ADS / M9328MXLADS).



Regards,

llandre

DAVE Electronics System House - R&D Department
www.dave-tech.it 

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Robert Schwebel]

On Mon, Jun 28, 2004 at 09:19:13AM +0200, llandre wrote:
> >>>how will we call the Motorola i.MX processors in future?
> >>>
> >>>Will it be "imx", "i.MX", "iMX" or MC9328MX{1,21,L}?
> >>The original 2.4 Linux port was mx1ads which is definitely wrong: it is
> >>the name of the Motorola development board. Following the scheme of the
> >>other architectures and platforms I would vote for imx.
> >
> >Following the scheme of the other architectures and platforms _and_ 
> >speaking as a hardware developer I would vote for MC9328MX...
> >Or at least "iMX".
> 
> I vote for MC9328MX{1,21,L}.

Stop - we have to differentiate between the "machine type" (which is
imx) and the _implementation_ (which could be something like M9328MXL)
and the "board" (M83281ADS). 

What about this: 

	"machine type" (arch/arm/mach-xxx in Linux nomenclature): imx
	"implementation" (asm/arm/arch-xxx/yyy.h): MC9328MXL
	"board": M83281ADS

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Steven Scholz]

Robert Schwebel wrote:

> On Mon, Jun 28, 2004 at 09:19:13AM +0200, llandre wrote:
> 
>>>>>how will we call the Motorola i.MX processors in future?
>>>>>
>>>>>Will it be "imx", "i.MX", "iMX" or MC9328MX{1,21,L}?
>>>>
>>>>The original 2.4 Linux port was mx1ads which is definitely wrong: it is
>>>>the name of the Motorola development board. Following the scheme of the
>>>>other architectures and platforms I would vote for imx.
>>>
>>>Following the scheme of the other architectures and platforms _and_ 
>>>speaking as a hardware developer I would vote for MC9328MX...
>>>Or at least "iMX".
>>
>>I vote for MC9328MX{1,21,L}.
> 
> 
> Stop - we have to differentiate between the "machine type" (which is
> imx) and the _implementation_ (which could be something like M9328MXL)
> and the "board" (M83281ADS). 
> 
> What about this: 
> 
> 	"machine type" (arch/arm/mach-xxx in Linux nomenclature): imx
> 	"implementation" (asm/arm/arch-xxx/yyy.h): MC9328MXL
> 	"board": M83281ADS

Hmm. I was talking about the cpu/ directory in U-Boot...

Altough the MC9328 has an ARM9 core I think we should create a new 
cpu/mc9328 (or cpu/iMX) directory and put the driver code for integrated 
peripherals (as UARTs etc.) into that directory.
This is done for loads of other CPUs. Just search for '*serial*' or '*fec*' 
in cpu/.

As for Linux I think you're right. But we don't have mach-xxx nor arch-xxx 
in U-Boot, do we?

--
Steven

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Wolfgang Denk]

In message <20040628092036.GB13868@pengutronix.de> you wrote:
> 
> What about this: 
> 
> 	"machine type" (arch/arm/mach-xxx in Linux nomenclature): imx
> 	"implementation" (asm/arm/arch-xxx/yyy.h): MC9328MXL
> 	"board": M83281ADS

In U-Boot we just split in "cpu" and "board". 

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
All he had was nothing, but that was something, and now it  had  been
taken away.                             - Terry Pratchett, _Sourcery_

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Robert Schwebel]

On Mon, Jun 28, 2004 at 11:35:01AM +0200, Wolfgang Denk wrote:
> In U-Boot we just split in "cpu" and "board". 

Which is no good idea. CPU is ARM920T and each and every board copies
everything it needs from other boards.

Is there any activity to work on a "next generation u-boot" which avoids
all the design glitches we currently have? It's nearly impossible to
restructure things in a tree which is supposed to be production code. I
think of things like config frontend, everybody-is-alowed-to-add-tons-
of-trailing-whitespace-if-he-is-not-robert, layered drivers which hold
their pointers to the hardware in structures instead of 1001 ifdefs etc. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Wolfgang Denk]

In message <20040628105102.GB14287@pengutronix.de> you wrote:
> On Mon, Jun 28, 2004 at 11:35:01AM +0200, Wolfgang Denk wrote:
> > In U-Boot we just split in "cpu" and "board". 
> 
> Which is no good idea. CPU is ARM920T and each and every board copies
> everything it needs from other boards.

Feel free to make a suggestion how to deal with this in a better way.

> Is there any activity to work on a "next generation u-boot" which avoids
> all the design glitches we currently have? It's nearly impossible to

Maybe as a first step we should start collecting such design glitches?

> restructure things in a tree which is supposed to be production code. I
> think of things like config frontend, everybody-is-alowed-to-add-tons-
> of-trailing-whitespace-if-he-is-not-robert, layered drivers which hold
> their pointers to the hardware in structures instead of 1001 ifdefs etc. 

Re config frontend: is there any new stuff  available  that  I  don't
   know  of?  We had this discusssion a couple of times before, but I
   haven't seen any working code or  implementation  example  yet.  I
   cannot make comments on things I have never seen.

Re everybody-is-alowed-to-add-tons-of-trailing-whitespace-if-he-is-not-robert:
   I can understand that you feel frustrated, as you hold the  record
   of  having patches rejected because of violating the Coding Style.
   To make it clear: there are no  exceptions  from  the  rules.  The
   coding  style applies to everybody. For small patches I may decide
   to perform the cleanup myself, especially  for  people  submitting
   their first few patches. This is mostly to encourage them to go on
   contributing  their work back to the community. From netheads like
   you I expect a little more. OK, everybody can miss a thing here or
   there. But your patches violate the Coding Style in a density that
   I can only call ignorance. I am not  in  the  mood  to  accept  an
   attitude  like  "it  is difficult to audit this patch for trailing
   whitespace as the patch context contains that  much"  -  there  is
   only  a single file in the CVS which contains trailing while space
   (and this  is  the  automatically  generated  include/bmp_logo.h).
   Sorry - the context is clean, so please cleanup your patch, too.

Re layered drivers:
   Please feel free to submit patches.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
As far as we know, our computer has never had an undetected error.
		                                           -- Weisert

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Robert Schwebel]

On Mon, Jun 28, 2004 at 01:37:36PM +0200, Wolfgang Denk wrote:
> Feel free to make a suggestion how to deal with this in a better way.

IMHO the ARM way of structuring systems is pretty good, but that would
mean a larger restructuring which surely cannot be done in a production
environment. 

> Maybe as a first step we should start collecting such design glitches?

I tried to...

> Re config frontend: is there any new stuff  available  that  I  don't
>    know  of?  We had this discusssion a couple of times before, but I
>    haven't seen any working code or  implementation  example  yet.  I
>    cannot make comments on things I have never seen.

I have something, I'll update it to recent CVS and post a patch. 

> Re everybody-is-alowed-to-add-tons-of-trailing-whitespace-if-he-is-not-robert:

It would help a lot if you could put your standard sed instructions into
the README or some script; I just found out that even the variant from
the vim FAQ I was using misses things that your script finds. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Wolfgang Denk]

In message <20040628123828.GA5739@pengutronix.de> you wrote:
> 
> IMHO the ARM way of structuring systems is pretty good, but that would
> mean a larger restructuring which surely cannot be done in a production
> environment. 

Which "ARM way of structuring systems"  are  you  referring  to?  The
Linux  code?  How  would you translate this into the U-Boot directory
structure?

Why do you think such a change cannot be performed in the current CVS
tree? We have "official" release, and  between  releases  we  can  do
nearly everything.

> It would help a lot if you could put your standard sed instructions into
> the README or some script; I just found out that even the variant from
> the vim FAQ I was using misses things that your script finds. 

Actually I'm typing these things on the fly. But point taken.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Research is what I'm doing when I don't know what I'm doing.
                                                 -- Wernher von Braun

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Steven Scholz]

Wolfgang Denk wrote:

> In message <20040628123828.GA5739@pengutronix.de> you wrote:
> 
>>It would help a lot if you could put your standard sed instructions into
>>the README or some script; I just found out that even the variant from
>>the vim FAQ I was using misses things that your script finds. 
> 
> 
> Actually I'm typing these things on the fly. But point taken.

Or provide a script tools/find_bad_coding_style.sh ... ;-)

Steven

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Steven Scholz]

Robert Schwebel wrote:

> On Mon, Jun 28, 2004 at 11:35:01AM +0200, Wolfgang Denk wrote:
> 
>>In U-Boot we just split in "cpu" and "board". 
> 
> 
> Which is no good idea. CPU is ARM920T and each and every board copies
> everything it needs from other boards.

But still we should add it this way right now to get it into CVS a.s.a.p. so 
other people can test your patch and contribute to it. Following "release 
early, release often" policy.

I know it is "no good idea" (TM). But it's the same for the AT91RM9200 - 
which is ARM9 too.

We could clean up and reconstruct later when we know how to do it right.

BTW: Does your patch remove the iMX stuff already in CVS?
      Or should Wolfgang delete this patch:

	* Patch by Ming-Len Wu, 09 Jun 2004:
	  Add suppport for MC9328 (Dargonball) CPU and Motorola MX1ADS board

      after/before applying yours?

Steven

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Robert Schwebel]

On Mon, Jun 28, 2004 at 02:14:34PM +0200, Steven Scholz wrote:
> But still we should add it this way right now to get it into CVS a.s.a.p. 
> so other people can test your patch and contribute to it. Following 
> "release early, release often" policy.

Ack. 

> I know it is "no good idea" (TM). But it's the same for the AT91RM9200 - 
> which is ARM9 too.
> 
> We could clean up and reconstruct later when we know how to do it right.

It's probably time for one of these famous hacking weekends at some
place where we have net, barbecue stuff and some cold beer ;) 

> BTW: Does your patch remove the iMX stuff already in CVS?
>      Or should Wolfgang delete this patch:
> 
> 	* Patch by Ming-Len Wu, 09 Jun 2004:
> 	  Add suppport for MC9328 (Dargonball) CPU and Motorola MX1ADS board
> 
>      after/before applying yours?

Sascha, can you have a look at this? I'm currently a little bit
handicaped while sitting behind some strange corporate firewall... 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Sascha Hauer]

Hi,

> > BTW: Does your patch remove the iMX stuff already in CVS?
> >      Or should Wolfgang delete this patch:
> > 
> > 	* Patch by Ming-Len Wu, 09 Jun 2004:
> > 	  Add suppport for MC9328 (Dargonball) CPU and Motorola MX1ADS board
> > 
> >      after/before applying yours?
> 
> Sascha, can you have a look at this? I'm currently a little bit
> handicaped while sitting behind some strange corporate firewall... 
> 

Yes, the patch removes Ming-Len Wu's patch. I already got a patch from
Ming-Len Wu which adds mx1ads support in our way. It is working on our
mx1ads board. I already posted a patch to this list. Download it at

http://www.pengutronix.de/software/u-boot/u-boot-imx1-20040628-1.diff

Sascha

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[llandre]

>Stop - we have to differentiate between the "machine type" (which is
>imx) and the _implementation_ (which could be something like M9328MXL)
>and the "board" (M83281ADS).
>
>What about this:
>
>         "machine type" (arch/arm/mach-xxx in Linux nomenclature): imx
>         "implementation" (asm/arm/arch-xxx/yyy.h): MC9328MXL
>         "board": M83281ADS

For me everything is ok but the board name. I never saw that name before.
On my board I can read:

MOTOROLA
M9328MX1ADS/M9328MXLADS
Ver 2.0

Do you really have that name on your PCB?



llandre

DAVE Electronics System House - R&D Department
www.dave-tech.it 

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[Steven Scholz]

llandre wrote:

> 
>> Stop - we have to differentiate between the "machine type" (which is
>> imx) and the _implementation_ (which could be something like M9328MXL)
>> and the "board" (M83281ADS).
>>
>> What about this:
>>
>>         "machine type" (arch/arm/mach-xxx in Linux nomenclature): imx
>>         "implementation" (asm/arm/arch-xxx/yyy.h): MC9328MXL
>>         "board": M83281ADS
> 
> 
> For me everything is ok but the board name. I never saw that name before.
> On my board I can read:
> 
> MOTOROLA
> M9328MX1ADS/M9328MXLADS
> Ver 2.0
> 
> Do you really have that name on your PCB?

Arhg!

I just noticed: While the chip is called MC9328MX1 the eval board has 
actually M9328MX1ADS printed on it (which is the order code). Note the 
missing 'C' ...

Steven

[U-Boot-Users] Re: nomen est omen: i.MX or mc9329 ?

[llandre]

>>For me everything is ok but the board name. I never saw that name before.
>>On my board I can read:
>>MOTOROLA
>>M9328MX1ADS/M9328MXLADS
>>Ver 2.0
>>Do you really have that name on your PCB?
>
>Arhg!
>
>I just noticed: While the chip is called MC9328MX1 the eval board has 
>actually M9328MX1ADS printed on it (which is the order code). Note the 
>missing 'C' ...

It seems marketroids enjoy complicating the simple things ...


llandre

DAVE Electronics System House - R&D Department
www.dave-tech.it