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
Quoted 3 lines · Steven Scholz
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.
Quoted 2 lines
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.
Quoted 2 lines
How are the plans for linux-2.6 port?
We should keep it consistent...
I'll post our patch in five minutes...
Robert
Signature · 5 lines
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-4Quoted 9 lines · Robert Schwebel
Quoted 3 lines · Steven Scholz
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".
Quoted 5 lines
Quoted 2 lines
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
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
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}.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 7 lines · llandre
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 3 lines
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
Signature · 5 lines
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-4Quoted 21 lines · Robert Schwebel
Quoted 8 lines · llandre
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 3 lines
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).
Quoted 5 lines
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
Quoted 6 lines · In message <[email protected]> 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
Signature · 4 lines
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_
Quoted 1 line · Wolfgang Denk
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
Signature · 5 lines
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-4Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 1 line · Wolfgang Denk
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.
Quoted 2 lines
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?
Quoted 4 lines
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
Signature · 4 lines
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
Quoted 1 line · Wolfgang Denk
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.
Quoted 1 line
Maybe as a first step we should start collecting such design glitches?
I tried to...
Quoted 4 lines
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.
Quoted 1 line
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
Signature · 5 lines
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-4Quoted 4 lines · In message <[email protected]> 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.
Quoted 3 lines
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
Signature · 4 lines
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 BraunQuoted 8 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> 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
Quoted 7 lines · Robert Schwebel
Quoted 1 line · Wolfgang Denk
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
Quoted 3 lines · Steven Scholz
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.
Quoted 4 lines
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 ;)
Quoted 7 lines
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 boardafter/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
Signature · 5 lines
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-4Hi,
Quoted 11 lines
Quoted 7 lines
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 boardafter/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
Quoted 9 lines
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
Quoted 12 lines · llandre
Quoted 10 lines
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
Quoted 8 lines
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.0Do 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
Quoted 7 lines
Quoted 6 lines
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?
Quoted 5 lines
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