[U-Boot-Users] nomen est omen: i.MX or mc9329 ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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": M83281ADSFor 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
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
participants (6)
-
llandre -
Robert Schwebel -
Robert Schwebel -
Sascha Hauer -
Steven Scholz -
Wolfgang Denk