* IXP4xx support
@ 2010-02-06 21:00 Krzysztof Halasa
2010-02-07 10:50 ` Marc Kleine-Budde
0 siblings, 1 reply; 6+ messages in thread
From: Krzysztof Halasa @ 2010-02-06 21:00 UTC (permalink / raw)
To: barebox
Hi,
I'm thinking about adding Barebox support for a certain platform using
IXP425 (ARM, usually big-endian) CPU. This means the startup code
(trivial, already got it working in little-endian mode), drivers for
hardware Queue Manager, Network Processing Engines and built-in Ethernet
interfaces (all of them easy to port from Linux).
This also means supporting the NOR flash: the CPU has 16-bit, always
big-endian, "value-preserving" EXP bus for connecting such devices. In
LE mode the address has to be XORed with 2, and if it's byte-oriented
data (i.e. not a command/response), it has to be byte-swapped. Only
16-bit writes can be made.
Doing the above in the flash driver would complicate things a lot. The
drivers currently use plain pointers to access the flash. I'm thinking
about moving the low-level access (R/W) routines to arch code (with a
generic defaults), and calling them via the NOR flash platform struct
(which doesn't do anything useful ATM).
The above would also permit supporting flashes which can't be mapped in
normal CPU address space. It would be a bit slower, though.
Opinions?
--
Krzysztof Halasa
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IXP4xx support
2010-02-06 21:00 IXP4xx support Krzysztof Halasa
@ 2010-02-07 10:50 ` Marc Kleine-Budde
2010-02-07 18:44 ` Flash drivers, was: " Krzysztof Halasa
2010-02-08 13:40 ` Sascha Hauer
0 siblings, 2 replies; 6+ messages in thread
From: Marc Kleine-Budde @ 2010-02-07 10:50 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: barebox
[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]
Krzysztof Halasa wrote:
> I'm thinking about adding Barebox support for a certain platform using
> IXP425 (ARM, usually big-endian) CPU. This means the startup code
> (trivial, already got it working in little-endian mode), drivers for
> hardware Queue Manager, Network Processing Engines and built-in Ethernet
> interfaces (all of them easy to port from Linux).
>
> This also means supporting the NOR flash: the CPU has 16-bit, always
> big-endian, "value-preserving" EXP bus for connecting such devices. In
> LE mode the address has to be XORed with 2, and if it's byte-oriented
> data (i.e. not a command/response), it has to be byte-swapped. Only
> 16-bit writes can be made.
>
> Doing the above in the flash driver would complicate things a lot. The
> drivers currently use plain pointers to access the flash. I'm thinking
> about moving the low-level access (R/W) routines to arch code (with a
> generic defaults), and calling them via the NOR flash platform struct
> (which doesn't do anything useful ATM).
have a look at the current uboot cfi flash driver. They have read/write
functions to access the flash. By default they are macros to IIRC
__raw_read,write.
From the first look, the driver looks much cleaner than the "old" one
used in barebox (modulo my bugfix from last week).
Maybe the current uboot driver should be ported to barebox before
starting improving the old one.
> The above would also permit supporting flashes which can't be mapped in
> normal CPU address space. It would be a bit slower, though.
Sure, the access macros can be mapped to something complete different.
Cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Flash drivers, was: IXP4xx support
2010-02-07 10:50 ` Marc Kleine-Budde
@ 2010-02-07 18:44 ` Krzysztof Halasa
2010-02-08 10:06 ` Sascha Hauer
2010-02-08 13:40 ` Sascha Hauer
1 sibling, 1 reply; 6+ messages in thread
From: Krzysztof Halasa @ 2010-02-07 18:44 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: barebox
I also wonder, why are there two NOR flash drivers, old and new?
Another thing, the drivers seem to support various configurations like
4*16 bit (4 physical flash chips in parallel). Does any currently
supported platform use anything like that? Or maybe all platforms use
1*8 or 16-bit config and the extra code is unneeded complexity?
--
Krzysztof Halasa
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Flash drivers, was: IXP4xx support
2010-02-07 18:44 ` Flash drivers, was: " Krzysztof Halasa
@ 2010-02-08 10:06 ` Sascha Hauer
2010-02-11 22:29 ` Krzysztof Halasa
0 siblings, 1 reply; 6+ messages in thread
From: Sascha Hauer @ 2010-02-08 10:06 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: barebox
On Sun, Feb 07, 2010 at 07:44:05PM +0100, Krzysztof Halasa wrote:
> I also wonder, why are there two NOR flash drivers, old and new?
I started working on the U-Boot flash driver and started making
the different Flash chips (AMD, Intel) and bus widths optional in order
to get the driver smaller. I didn't really get ready with it and
checked it in as a second driver. Sorry for the confusion, I should
have made a seperate branch from it.
>
> Another thing, the drivers seem to support various configurations like
> 4*16 bit (4 physical flash chips in parallel). Does any currently
> supported platform use anything like that? Or maybe all platforms use
> 1*8 or 16-bit config and the extra code is unneeded complexity?
I have seen all bus widths from 8bit to 64bit on my boards. Not all
of them are supported in barebox, but it's not a good idea to remove
support for it.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IXP4xx support
2010-02-07 10:50 ` Marc Kleine-Budde
2010-02-07 18:44 ` Flash drivers, was: " Krzysztof Halasa
@ 2010-02-08 13:40 ` Sascha Hauer
1 sibling, 0 replies; 6+ messages in thread
From: Sascha Hauer @ 2010-02-08 13:40 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: barebox, Krzysztof Halasa
On Sun, Feb 07, 2010 at 11:50:22AM +0100, Marc Kleine-Budde wrote:
> Krzysztof Halasa wrote:
> > I'm thinking about adding Barebox support for a certain platform using
> > IXP425 (ARM, usually big-endian) CPU. This means the startup code
> > (trivial, already got it working in little-endian mode), drivers for
> > hardware Queue Manager, Network Processing Engines and built-in Ethernet
> > interfaces (all of them easy to port from Linux).
> >
> > This also means supporting the NOR flash: the CPU has 16-bit, always
> > big-endian, "value-preserving" EXP bus for connecting such devices. In
> > LE mode the address has to be XORed with 2, and if it's byte-oriented
> > data (i.e. not a command/response), it has to be byte-swapped. Only
> > 16-bit writes can be made.
> >
> > Doing the above in the flash driver would complicate things a lot. The
> > drivers currently use plain pointers to access the flash. I'm thinking
> > about moving the low-level access (R/W) routines to arch code (with a
> > generic defaults), and calling them via the NOR flash platform struct
> > (which doesn't do anything useful ATM).
>
> have a look at the current uboot cfi flash driver. They have read/write
> functions to access the flash. By default they are macros to IIRC
> __raw_read,write.
>
> From the first look, the driver looks much cleaner than the "old" one
> used in barebox (modulo my bugfix from last week).
It seems it still has the same driver under the hood.
I suggest to remove the "old" driver in favor for the cfi_flash_new
driver so that this ongoing confusion ends and Krzysztof has some base
to work on. I think the flash accesses can be ported from U-Boot if
necessary.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-02-11 22:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-06 21:00 IXP4xx support Krzysztof Halasa
2010-02-07 10:50 ` Marc Kleine-Budde
2010-02-07 18:44 ` Flash drivers, was: " Krzysztof Halasa
2010-02-08 10:06 ` Sascha Hauer
2010-02-11 22:29 ` Krzysztof Halasa
2010-02-08 13:40 ` Sascha Hauer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox