Re: [U-Boot-Users] using a flat device tree to drive u-boot config

[Wolfgang Grandegger]

André Schwarz wrote:
> Ben Warren schrieb:
>> On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood <[EMAIL PROTECTED]> wrote:
>>> Ben Warren wrote:
 On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <[EMAIL PROTECTED]>
 wrote:
> I find a device tree much easier to figure out than a tangled mess of
> header
> files, #defines, and #ifdefs...
 In many ways, yes.  But are you an average Joe or a Linux kernel
 propellerhead?
>>> Is u-boot work normally done by average Joes, and does the average Joe
>>> really find the preprocessor mess more intuitive than a "propellerhead"?
>>>
>> You know what I mean.  Some people like yourself do this for a living,
>> and are involved day-to-day in its specification.  Of course it's
>> intuitive to you.  For most people, getting U-boot going is one stage
>> in the development process of software for an embedded device.  They
>> work on it for a few weeks or months, then on something completely
>> different.  A few months or years later, they come back to it.
> 
> You're absolutely right - just have a look at the vast lists of 
> maintainers/contributors ... they are "average Joes" like myself. 
> Realizing 2-3 projects each year should be possible without having to 
> re-learn from scratch.
> 
>>> While we're at it, let's re-write u-boot in Visual Basic. :-)
>> Uh, yeah.  I like the idea of a central repo for hardware info, and
>> the device tree concept is good.  My point is that the syntax, while
>> concise and exact, can be intimidating.  Just look at the amount of
>> traffic on the mailing lists of people that don't understand what all
>> the fields mean when specifying IRQs etc.  Anything we can do to make
>> it less so for noobies is a good thing for everybody.
>>
> 
> Please keep in mind that WDenk is always watching if code is slowing 
> things down or increasing size significantly. Improving things is very 
> good - but not at the cost of size and/or speed. Configuring a board 
> using a dtb usually needs far more code being present than needed.
> After all it's a bootloader and not another pseudo OS.
> 
> But don't get me wrong ! The device tree is a very nice and usefuly 
> thing ... for an OS.

There are customer request for a dynamically configurable U-Boot and the 
FDT is the right tool to provide the functionality. It has its price but 
U-Boot using a FDT blob for booting would also save some fixup code 
(required to boot Linux) and furthermore it would resolves some 
dependencies between hardcoded U-Boot and FDT defined addresses and ranges.

Wolfgang.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

[Wolfgang Grandegger]

Kumar Gala wrote:
> One topic that come up during OLS in discussions and u-boot BOF was  
> the idea of driving u-boot configuration from a device tree instead of  
> from "config.h".  I was wondering if anyone has actually looked at  
> doing this.

Last year I brought up the topic twice:

http://sourceforge.net/mailarchive/message.php?msg_name=46F384E6.5030603%40grandegger.com

> One question I have is how does (or should) u-boot identify where to  
> find the device tree.  I think the idea would be that this "area"  
> could be easily reflashed with a new blob to get a new configuration.

Yep, it's even feasible to flash more than one blob and select one 
somehow in the early boot phase.

Our main interest in using FDT for U-Boot is to make it dynamically 
configurable having just one image for various variants of the 
hardware. Replacing config.h completely seems overkill to me (and will 
not even be possible).

Wolfgang.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] mpc85xx: make the MxMR register in upmconfig as a parameter

[Wolfgang Grandegger]

Sebastian Siewior wrote:
> * Wolfgang Grandegger | 2008-07-15 13:28:40 [+0200]:
> 
>> Sebastian Siewior wrote:
>>> * Andy Fleming | 2008-07-14 19:27:08 [-0500]:
>>>
>>>> On Mon, Jul 14, 2008 at 5:54 AM, Sebastian Siewior
>>>> <[EMAIL PROTECTED]> wrote:
>>>>> The default value for the MxMR register is not always the right one.
>>>>> This patch adds the value of MxMR register as an additional
>>>>> parameter (plus a few defines instead of hex coded values).
>>>>>
>>>>> Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
>>>> I'm not convinced this is the right solution.  Anytime we put a
>>>> cpu-specific #ifdef for a function definition, we should think long
>>>> and hard about why.  Maybe instead of an argument, we should make
>>>> mxmr_mode a config value.  Also, unless I'm misreading this patch,
>>>> you've broken *every* board with this patch, since there's no change
>>>> to any of the invokers of upmconfig to supply the fourth argument.
>>> Other sollutions are fine with me :) I did not change any board specific
>>> code, because I did not find any users (with 85xx cpus). Still possible
>>> that I missed some
>> upmconfig was introduced with the socrates board but our internal 
>> version now also uses a configurable MXMR value. The TQM85xx boards and 
>> likely more should be converted as well.
> 
> Socrates uses upmconfig, TQM85xx uses its own implementation. Why
> TQM85xx boards? There is only one, isn't it?

The port for Socrates and TQM8548 have been developped concarently and I 
  was therefore not aware of an upmconfig for MPC85xx. TQM85xx modules 
use UPMC for CAN and the TQM8548 uses UPMB for NAND.

>>> If you prefer a define for this register the way we deal with BRx/ORx
>>> than I could send a patch that does this. What should be done in case
>>> the user is going to program UPMA but did not specify MAMR? The default
>>> value or build error? Since this value as well as the UPM tables depend
>>> very much on the hardware, the user should been told by his hardware
>>> guys what to do :)
>> I think upmconfig() should only touch the relevant bits of the MxMR 
>> register. For the TQM8548 NAND support (see board/tqc/tqm85xx/nand.c) I 
>> implemented it as Linux does:
>>
>>clrsetbits_be32(&lbc->mbmr, MxMR_MAD_MSK,
>>MxMR_OP_WARR | (addr & MxMR_MAD_MSK));
>>
>>out_be32 (&lbc->mdr, val);
>>
>>/* dummy access to perform write */
>>out_8 ((void __iomem *)CFG_NAND0_BASE, 0);
>>
>>clrbits_be32(&lbc->mbmr, MxMR_OP_WARR);
>>
> Okey, so you prefer to clear only MAD bits and MODE bits and leave
> everythign else untouched. And where should de define them? In
> cpu/mpc85xx/cpu_init.c right after the OR/BR settings?

For the time being, I prefer to keep upmconfig() compatible with the 
others similar implementation:

   $ find . -type f | xargs grep upmconfig
   ./mpc83xx/cpu.c:void upmconfig (uint upm, uint *table, uint size)
   ./mpc8260/cpu.c:void upmconfig (uint upm, uint * table, uint size)
   ./mpc8xx/cpu.c:void upmconfig (uint upm, uint * table, uint size)
   ./mpc85xx/cpu.c:void upmconfig (uint upm, uint * table, uint size)

mxmr should be defined in the platform specific code, as currently all 
boards using upmconfig() do, if necessary. If we unify them, we have 
more choices.

 > Why does Linux program UPMs? Isn't this one-time-setup?

See http://lxr.linux.no/linux+v2.6.26/drivers/mtd/nand/fsl_upm.c. A 
similar implementation exists for U-Boot in drivers/mtd/nand/fsl_upm.c,
which is used by the TQM8548, for example.

Wolfgang.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] mpc85xx: make the MxMR register in upmconfig as a parameter

[Wolfgang Grandegger]

Sebastian Siewior wrote:
> * Andy Fleming | 2008-07-14 19:27:08 [-0500]:
> 
>> On Mon, Jul 14, 2008 at 5:54 AM, Sebastian Siewior
>> <[EMAIL PROTECTED]> wrote:
>>> The default value for the MxMR register is not always the right one.
>>> This patch adds the value of MxMR register as an additional
>>> parameter (plus a few defines instead of hex coded values).
>>>
>>> Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
>>
>> I'm not convinced this is the right solution.  Anytime we put a
>> cpu-specific #ifdef for a function definition, we should think long
>> and hard about why.  Maybe instead of an argument, we should make
>> mxmr_mode a config value.  Also, unless I'm misreading this patch,
>> you've broken *every* board with this patch, since there's no change
>> to any of the invokers of upmconfig to supply the fourth argument.
> Other sollutions are fine with me :) I did not change any board specific
> code, because I did not find any users (with 85xx cpus). Still possible
> that I missed some

upmconfig was introduced with the socrates board but our internal 
version now also uses a configurable MXMR value. The TQM85xx boards and 
likely more should be converted as well.

> Another sollution might be to add upconfig_mxmr() and let upmconfig call
> that function with the default value however this sounds nasty.
> 
>> Could you also explain in greater detail what you are trying to do,
>> here?  My familiarity with the LBC code is fairly low.
> The MxMR register specifies the mode in which the UPM is used. I have to
> program two UPMs with different content of this register: in one case I
> have to set UWPL & GPL4 bits in the other case the default value would
> do).
> 
> If you prefer a define for this register the way we deal with BRx/ORx
> than I could send a patch that does this. What should be done in case
> the user is going to program UPMA but did not specify MAMR? The default
> value or build error? Since this value as well as the UPM tables depend
> very much on the hardware, the user should been told by his hardware
> guys what to do :)

I think upmconfig() should only touch the relevant bits of the MxMR 
register. For the TQM8548 NAND support (see board/tqc/tqm85xx/nand.c) I 
implemented it as Linux does:

 clrsetbits_be32(&lbc->mbmr, MxMR_MAD_MSK,
 MxMR_OP_WARR | (addr & MxMR_MAD_MSK));

 out_be32 (&lbc->mdr, val);

 /* dummy access to perform write */
 out_8 ((void __iomem *)CFG_NAND0_BASE, 0);

 clrbits_be32(&lbc->mbmr, MxMR_OP_WARR);


I could test the new patch on the TQM8548 and Socrates board.

BTW: upmconfig() should also work as is on the MPC83xx and MPC86xx, IIRC 
but it's not obvious where to put the code if we go for a more generic 
FSL UPM solution.

Wolfgang.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] mpc85xx: make the MxMR register in upmconfig as a parameter

[Wolfgang Grandegger]

Sebastian Siewior wrote:
> The default value for the MxMR register is not always the right one.
> This patch adds the value of MxMR register as an additional
> parameter (plus a few defines instead of hex coded values).
> 
> Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
> ---
>  cpu/mpc85xx/cpu.c |   17 +++--
>  include/common.h  |4 
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
> index 2373b4a..081e804 100644
> --- a/cpu/mpc85xx/cpu.c
> +++ b/cpu/mpc85xx/cpu.c
> @@ -314,16 +314,21 @@ int dma_xfer(void *dest, uint count, void *src) {
>   return dma_check();
>  }
>  #endif
> +
> +#define MXMR_OP_NORMAL   (0x)
> +#define MXMR_OP_WRITE(0x1000)
> +#define MXMR_OP_READ (0x2000)
> +#define MXMR_OP_RUN  (0x3000)

Please use the the corresponding definitions from 
"include/asm-ppc/fsl_lbc.h".


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] V3: mpc85xx set CCB:LBC ratio (CONFIG_LBC_CLOCK_RATIO)

[Wolfgang Grandegger]

John Ogness wrote:
> I've changed the patch so that it is less intrusive. It now simply
> adds the new function to the "init_sequence" if defined.
> 
> Signed-off-by: John Ogness <[EMAIL PROTECTED]>

Could you please send your patches inline next time to simplify 
reviewing? Thanks.

I have a general remark here. Currently, various 85xx boards setup the 
local bus in the board specific code called from checkboard(). Your 
set_lbc_clock_ratio() would be called earlier and is therefore unusable 
for these board. Nevertheless, the setting of the clock rate is just one 
thing to be done to setup the local bus properly but there are more 
including bug fixes. I would appreciate a generic function for that 
purpose to get rid of duplicated code.

Wolfgang.


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH v2 0/12] 85xx: various fixes for TQM85xx and support for TQM8548

[Wolfgang Grandegger]

Hi Andy,

Andy Fleming wrote:
> On Thu, Jun 5, 2008 at 6:11 AM, Wolfgang Grandegegr <[EMAIL PROTECTED]> wrote:
>> this is v2 of patches fixing various issues with TQM85xx modules and adding
>> support for TQM8548 modules from TQ Components GmbH (http://www.tqc.de).
>>
>> Note: The patches rely on "[PATCH v2] TQM: move TQM boards to board/tqc"
>>  sent a few minutes ago to this list.
>>
>> Wolfgang.
> 
> 
> BTW, I applied all of these while the window was open, I just never
> sent a  confirmation email.

OK, no problem.

> Thanks!

Thank you as well.

Wolfgang.


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] Add MVBC_P board

[Wolfgang Grandegger]

Andre Schwarz wrote:
> The MVBC_P is a MPC5200B based camera system with Intel Gigabit ethernet
> controller (using e1000) and custom Altera Cyclone-II FPGA on PCI.
> Please see doc/README.mvbc_p for details.

One general remark. Please use the in_*() and out_*() accessor functions
to access I/O space. This will make most of your asm("sync");
instructions obsolete.

Wolfgang.

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] e1000 problem @ current u-boot

[Wolfgang Grandegger]

Andre Schwarz wrote:
> Wolfgang,
> 
> of course I meant no offense - of course your patch is harmless.

No problem.

> The System (network camera) is running for nearly 2 years now.
> Last working version has been u-boot 1.2.x with a 2.6.19 kernel.
> 
> Since we've moved to the latest kernel we need a more recent u-boot.
> 
> This is what I did - and e1000 no longer works.
> 
> Of course I diff'ed the network stuff - no obvious changes at all.
> So I wonder if the problem is elsewhere and if e1000 is still working in
> general.

Have you read my previous mail? See below.

> Wolfgang Grandegger schrieb:
>> Andre Schwarz wrote:
>>> Wolfgang,
>>>
>>> as far as I can see on the list you sent the latest patches for the
>>> e1000 driver.
>> My patches just added some device ids,
>>
>>
>>> My e1000 (82541ER) stopped working on a MPC5200 based board with latest
>>> u-boot.
>>> I have a similar problem on another board ...
>>>
>>> Is your e1000 working properly on the latest u-boot ?
>> Yes, on a  MPC8548 board. I have not tested it on the MPC5200.
>>
>>> Do I need any additional defines or environment settings to get it
>>> working again ?
>>>
>>> Obviously it is - again :-[ - my fault or is related to my build system.
>> I think there are some known problems with PCI on boards with a
>> MPC5200 Rev. A processor, e.g. my EEPRO100 card does not work on it.
>> What exactly does not work?

More information could be useful.

Wolfgang.


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] e1000 problem @ current u-boot

[Wolfgang Grandegger]

Andre Schwarz wrote:
> Wolfgang,
> 
> as far as I can see on the list you sent the latest patches for the
> e1000 driver.

My patches just added some device ids,


> My e1000 (82541ER) stopped working on a MPC5200 based board with latest
> u-boot.
> I have a similar problem on another board ...
> 
> Is your e1000 working properly on the latest u-boot ?

Yes, on a  MPC8548 board. I have not tested it on the MPC5200.

> Do I need any additional defines or environment settings to get it
> working again ?
> 
> Obviously it is - again :-[ - my fault or is related to my build system.

I think there are some known problems with PCI on boards with a MPC5200 
Rev. A processor, e.g. my EEPRO100 card does not work on it. What 
exactly does not work?

Wolfgang.

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Please pull u-boot-mpc85xx.git (v2)

[Wolfgang Grandegger]

Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> are available in the git repository at:
>>
>>   git://www.denx.de/git/u-boot-mpc85xx.git master
>>
>>   A re-send, since I accidentally undid a bunch of changes before I sent the
>>   last pull request.  This one has been build-tested.
>>
>> Andy Fleming (1):
>>   socrates: Fix PCI clk fix patch
>>
>> Anton Vorontsov (2):
>>   83xx/85xx/86xx: factor out Freescale Localbus defines out of mpc83xx.h
>>   83xx/85xx: further localbus cleanups
>>
>> Becky Bruce (1):
>>   MPC85xx: Change traps.c to not reference non-addressable memory
>>
>> Kumar Gala (9):
>>   85xx: Only use PORPLLSR[DDR_Ratio] on platforms that define it
>>   85xx: expose cpu identification
>>   85xx: Add setting of cache props in the device tree.
>>   85xx: Remove unused and unconfigured memory test code.
>>   MPC8544DS: Update config.h
>>   85xx: remove dummy board_early_init_f
>>   FSL LAW: Keep track of LAW allocations
>>   85xx/86xx: Move to dynamic mgmt of LAWs
>>   FSL LAW: Add new interface to use the last free LAW
>>
>> Sergei Poselenov (7):
>>   Socrates: config file cleanup.
>>   Added the upmconfig() function for 85xx.
>>   Socrates: Added FPGA mapping. LAWs and TLBs cleanup.
>>   Socrates: added missed file with UPMA configuration data.
>>   NAND: Added support for 128-bit OOB, adapted
>>   Socrates: NAND support added. Changed the U-Boot base address and
>>   Socrates: Added FPGA base address update in FDT.
>>
>> Wolfgang Grandegger (16):
>>   83xx/85xx/86xx: add more MxMR local bus definitions
>>   TQM: move TQM boards to board/tqc
>>   PPC: add accessor macros to clear and set bits in one shot
>>   MPC85xx: Beautify boot output of L2 cache configuration
>>   NAND FSL UPM: driver re-write using the hwcontrol callback

I just realized that the related patch for the MPC8360ERDK got lost:

http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg06991.html

It is required to get that board working with the re-written FSL UPM
driver. Could someone pick it up, please.

Thanks,

Wolfgang.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH 1/2] 83xx/85xx/86xx: factor out Freescale Localbus defines out of mpc83xx.h

[Wolfgang Grandegger]

Anton Vorontsov wrote:
> On Wed, May 28, 2008 at 12:21:26PM -0500, Kim Phillips wrote:
>> On Wed, 28 May 2008 18:20:15 +0400
>> Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>>
>>> This patch moves Freescale Localbus defines out of mpc83xx.h, so we could
>>> use it on MPC85xx and MPC86xx processors.
>>>
>>> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
>>> ---
>>>  include/asm-ppc/fsl_lbc.h |  251 
>>> +
>>>  include/mpc83xx.h |  234 +-
>>>  include/mpc85xx.h |2 +
>>>  include/mpc86xx.h |2 +
>>>  4 files changed, 256 insertions(+), 233 deletions(-)
>>>  create mode 100644 include/asm-ppc/fsl_lbc.h
>>>
>> can we move the BRx_* and ORx_* left behind in mpc85xx.h also?
> 
> Yes, easily (because there is no single user).
> 
> The same is needed for mpc8xx.h and mpc8260.h (defines are almost
> the same, just few differences which needs some attention though).
> 
> But the bad news for mpc8xx and mpc8260 is that there are a lot of users
> of these defines. So this cleanup I'll leave for the "better times".
> 
> - - - -
> From: Anton Vorontsov <[EMAIL PROTECTED]>
> Subject: 83xx/85xx: further localbus cleanups
> 
> Merge mpc85xx.h's LBC defines to fsl_lbc.h. Also, adopt ACS names
> from mpc85xx.h, so ACS_0b10 renamed to ACS_DIV4, ACS_0b11 to ACS_DIV2.
> 
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
>  include/asm-ppc/fsl_lbc.h |   17 +++--
>  include/configs/MPC8315ERDB.h |2 +-
>  include/configs/MPC8349EMDS.h |2 +-
>  include/configs/MPC8349ITX.h  |4 ++--
>  include/configs/MPC8360EMDS.h |2 +-
>  include/configs/MPC8360ERDK.h |2 +-
>  include/configs/MPC837XEMDS.h |2 +-
>  include/configs/TQM834x.h |2 +-
>  include/mpc85xx.h |   35 ---
>  9 files changed, 23 insertions(+), 45 deletions(-)

What is the status of these two patches? It would be nice if we could
apply them quickly because some pending patches already rely on (or
conflict with) them.

Thanks,

Wolfgang.

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH v3 0/2] NAND FSL UPM driver update

[Wolfgang Grandegger]

The following lines got lost:

This is v3 of the patches for NAND FSL UPM driver update. They are
based on the following patches already sent to this list:

Wolfgang Grandegegr wrote:
>   [PATCH 1/2] 83xx/85xx/86xx: factor out Freescale Localbus defines out of 
> mpc83xx.h
>Re: [PATCH 1/2] 83xx/85xx/86xx: factor out Freescale Localbus defines out 
> of mpc83xx.h
>   [PATCH v2] PPC: add accessor macros to clear and set bits in one shot
>   [PATCH] 83xx/85xx/86xx: add more MxMR local bus definitions
> 
> Wolfgang.

Wolfgang.

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] TQM: move TQM boards to board/tqc

[Wolfgang Grandegger]

Andy Fleming wrote:
> On Mon, Jun 2, 2008 at 6:22 PM, Andy Fleming <[EMAIL PROTECTED]> wrote:
>> On Wed, May 28, 2008 at 12:53 PM,  <[EMAIL PROTECTED]> wrote:
>>> From: Wolfgang Grandegger <[EMAIL PROTECTED]>
>>>
>>> Move all TQM board directories to the vendor specific directory "tqc"
>>> for modules from TQ-Components GmbH (http://www.tqc.de).
>>>
>>> Note: this patch is too big for posting here and therefore I removed
>>> the hunks moving the files. I could provide the full patch on request.
>>>
>>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
>> I have no objections to this change.  However, if you want to post the
>> whole patch, you can generate it by passing "-M" to git-format-patch.
>> This will cause git to generate a patch which tells us the file was
>> moved, and git-am understands that, and does the right thing.
> 
> That is, *please* repost the patch with everything included.  Wolfgang
> can apply it directly, and then I can apply the other 12+ patches you
> sent which depend on it.

I just re-sent v2 of the patch created with the magic git-format-patch
option "-M".

Thanks,

Wolfgang.

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH v2] PPC: add accessor macros to clear and set bits in one shot

[Wolfgang Grandegger]

PPC: add accessor macros to clear and set bits in one shot

This patch adds macros from linux/include/asm-powerpc/io.h to clear and
set bits in one shot using the in_be32, out_be32, etc. accessor functions.
They are very handy to manipulate bits it I/O registers.

This patch is required for my forthcoming FSL NAND UPM driver re-write and
the support for the TQM8548 module.

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 include/asm-ppc/io.h |   36 
 1 file changed, 36 insertions(+)

Index: u-boot/include/asm-ppc/io.h
===
--- u-boot.orig/include/asm-ppc/io.h
+++ u-boot/include/asm-ppc/io.h
@@ -238,6 +238,42 @@ extern inline void out_be32(volatile uns
__asm__ __volatile__("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" 
(val));
 }
 
+/* Clear and set bits in one shot. These macros can be used to clear and
+ * set multiple bits in a register using a single call. These macros can
+ * also be used to set a multiple-bit bit pattern using a mask, by
+ * specifying the mask in the 'clear' parameter and the new bit pattern
+ * in the 'set' parameter.
+ */
+
+#define clrbits(type, addr, clear) \
+   out_##type((addr), in_##type(addr) & ~(clear))
+
+#define setbits(type, addr, set) \
+   out_##type((addr), in_##type(addr) | (set))
+
+#define clrsetbits(type, addr, clear, set) \
+   out_##type((addr), (in_##type(addr) & ~(clear)) | (set))
+
+#define clrbits_be32(addr, clear) clrbits(be32, addr, clear)
+#define setbits_be32(addr, set) setbits(be32, addr, set)
+#define clrsetbits_be32(addr, clear, set) clrsetbits(be32, addr, clear, set)
+
+#define clrbits_le32(addr, clear) clrbits(le32, addr, clear)
+#define setbits_le32(addr, set) setbits(le32, addr, set)
+#define clrsetbits_le32(addr, clear, set) clrsetbits(le32, addr, clear, set)
+
+#define clrbits_be16(addr, clear) clrbits(be16, addr, clear)
+#define setbits_be16(addr, set) setbits(be16, addr, set)
+#define clrsetbits_be16(addr, clear, set) clrsetbits(be16, addr, clear, set)
+
+#define clrbits_le16(addr, clear) clrbits(le16, addr, clear)
+#define setbits_le16(addr, set) setbits(le16, addr, set)
+#define clrsetbits_le16(addr, clear, set) clrsetbits(le16, addr, clear, set)
+
+#define clrbits_8(addr, clear) clrbits(8, addr, clear)
+#define setbits_8(addr, set) setbits(8, addr, set)
+#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+
 /*
  * Given a physical address and a length, return a virtual address
  * that can be used to access the memory range with the caching

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] PPC: add accessor macros to clear and set bits in one shot

[Wolfgang Grandegger]

Hi Detlev,

Detlev Zundel wrote:
> Hi Wolfgang,
> 
>> PPC: add accessor macros to clear and set bits in one shot
> 
> Although I think this is a good idea, I do not particularly like some
> details.
> 
>> This patch adds macros from linux/include/asm-powerpc/io.h to clear and
>> set bits in one shot using the in_be32, out_be32, etc. accessor functions.
>> They are very handy to manipulate bits it I/O registers.
>>
>> This patch is required for my forthcoming FSL NAND UPM driver re-write and
>> the support for the TQM8548 module.
>>
>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
>> ---
>>  include/asm-ppc/io.h |   28 
>>  1 file changed, 28 insertions(+)
>>
>> Index: u-boot/include/asm-ppc/io.h
>> ===
>> --- u-boot.orig/include/asm-ppc/io.h
>> +++ u-boot/include/asm-ppc/io.h
>> @@ -238,6 +238,34 @@ extern inline void out_be32(volatile uns
>>  __asm__ __volatile__("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" 
>> (val));
>>  }
>>  
>> +/* access ports */
>> +#define setbits32(_addr, _v) out_be32((_addr), in_be32(_addr) |  (_v))
>> +#define clrbits32(_addr, _v) out_be32((_addr), in_be32(_addr) & ~(_v))
>> +
>> +#define setbits16(_addr, _v) out_be16((_addr), in_be16(_addr) |  (_v))
>> +#define clrbits16(_addr, _v) out_be16((_addr), in_be16(_addr) & ~(_v))
> 
> Below are versions for _{be,le} which makes total sense to me, but the
> variants here miss the endianness, _implicitely_ doing big-endian
> transfers.  That is neither consistent, nor usable, i.e. how do I set a
> bit in a le-register?
> 
>> +
>> +#define setbits8(_addr, _v) out_8((_addr), in_8(_addr) |  (_v))
>> +#define clrbits8(_addr, _v) out_8((_addr), in_8(_addr) & ~(_v))
>> +
>> +/* Clear and set bits in one shot.  These macros can be used to clear and
>> + * set multiple bits in a register using a single read-modify-write.  These
>> + * macros can also be used to set a multiple-bit bit pattern using a mask,
>> + * by specifying the mask in the 'clear' parameter and the new bit pattern
>> + * in the 'set' parameter.
>> + */
>> +
>> +#define clrsetbits(type, addr, clear, set) \
>> +out_##type((addr), (in_##type(addr) & ~(clear)) | (set))
>> +
>> +#define clrsetbits_be32(addr, clear, set) clrsetbits(be32, addr, clear, set)
>> +#define clrsetbits_le32(addr, clear, set) clrsetbits(le32, addr, clear, set)
>> +
>> +#define clrsetbits_be16(addr, clear, set) clrsetbits(be16, addr, clear, set)
>> +#define clrsetbits_le16(addr, clear, set) clrsetbits(le32, addr, clear, set)
> 
> Error --

Ah, oh, I blindly copied that code from Linux include/asm-powerpc/io.h.
A revised patch addressing the above issues will follow.

Wolfgang.




-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH v2] NAND FSL UPM: driver re-write using the hwcontrol callback

[Wolfgang Grandegger]

NAND FSL UPM: driver re-write using the hwcontrol callback

This is a re-write of the NAND FSL UPM driver using the more universal
hwcontrol callback (instead of the cmdfunc callback). Here is a brief
list of furher modifications:

- For the time being, the UPM setup writing the UPM array has been
  removed from the driver and must now be done by the board specific
  code.

- The bus width definition in "struct fsl_upm_nand" is now in bits to
  comply with the corresponding Linux driver and 8, 16 and 32 bit
  accesses are supported.

- chip->dev_read is only set if fun->dev_ready != NULL, which is
  required for boards not connecting the R/B pin.

- A few issue have been fixed with MxMR bit manipulation like in the
  corresponding Linux driver.

Note: I think the "io_addr" field of "struct fsl_upm" could be removed
  as well, because the address is already determined by
  "nand->IO_ADDR_[RW]", but I'm not 100% sure.

This patch has been tested on a TQM8548 modules with the NAND chip
Micron MT29F8G08FABWP.

This patch is based on the following patches posted to this list a few
minutes ago:

  [PATCH] PPC: add accessor macros to clear and set bits in one shot
  [PATCH] 83xx/85xx/86xx: add more MxMR local bus definitions

In principle, the NAND driver of the TQM8272 should work with it as
well.

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
Acked-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
 drivers/mtd/nand/fsl_upm.c  |  128 +++-
 include/linux/mtd/fsl_upm.h |1 
 2 files changed, 46 insertions(+), 83 deletions(-)

Index: u-boot/drivers/mtd/nand/fsl_upm.c
===
--- u-boot.orig/drivers/mtd/nand/fsl_upm.c
+++ u-boot/drivers/mtd/nand/fsl_upm.c
@@ -20,112 +20,83 @@
 #include 
 #include 
 
-#define FSL_UPM_MxMR_OP_NO (0 << 28) /* normal operation */
-#define FSL_UPM_MxMR_OP_WA (1 << 28) /* write array */
-#define FSL_UPM_MxMR_OP_RA (2 << 28) /* read array */
-#define FSL_UPM_MxMR_OP_RP (3 << 28) /* run pattern */
+static int fsl_upm_in_pattern;
 
 static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
 {
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_RP | pat_offset);
+   clrsetbits_be32(upm->mxmr, MxMR_MAD_MSK, MxMR_OP_RUNP | pat_offset);
 }
 
 static void fsl_upm_end_pattern(struct fsl_upm *upm)
 {
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
-   while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
+   clrbits32(upm->mxmr, MxMR_OP_RUNP);
+
+   while (in_be32(upm->mxmr) & MxMR_OP_RUNP)
eieio();
 }
 
 static void fsl_upm_run_pattern(struct fsl_upm *upm, int width, u32 cmd)
 {
-   out_be32(upm->mar, cmd << (32 - width * 8));
-   out_8(upm->io_addr, 0x0);
-}
-
-static void fsl_upm_setup(struct fsl_upm *upm)
-{
-   int i;
-
-   /* write upm array */
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_WA);
-
-   for (i = 0; i < 64; i++) {
-   out_be32(upm->mdr, upm->array[i]);
+   out_be32(upm->mar, cmd << (32 - width));
+   switch (width) {
+   case 8:
out_8(upm->io_addr, 0x0);
+   break;
+   case 16:
+   out_be16(upm->io_addr, 0x0);
+   break;
+   case 32:
+   out_be32(upm->io_addr, 0x0);
+   break;
}
-
-   /* normal operation */
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
-   while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
-   eieio();
 }
 
-static void fun_cmdfunc(struct mtd_info *mtd, unsigned command, int column,
-   int page_addr)
+static void nand_hwcontrol (struct mtd_info *mtd, int cmd)
 {
struct nand_chip *chip = mtd->priv;
struct fsl_upm_nand *fun = chip->priv;
 
-   fsl_upm_start_pattern(&fun->upm, fun->upm_cmd_offset);
-
-   if (command == NAND_CMD_SEQIN) {
-   int readcmd;
-
-   if (column >= mtd->oobblock) {
-   /* OOB area */
-   column -= mtd->oobblock;
-   readcmd = NAND_CMD_READOOB;
-   } else if (column < 256) {
-   /* First 256 bytes --> READ0 */
-   readcmd = NAND_CMD_READ0;
-   } else {
-   column -= 256;
-   readcmd = NAND_CMD_READ1;
-   }
-   fsl_upm_run_pattern(&fun->upm, fun->width, readcmd);
+   switch (cmd) {
+   case NAND_CTL_SETCLE:
+   fsl_upm_start_pattern(&fun->upm, fun->upm_cmd_offset);
+   fsl_upm_in_pattern++;
+   break;
+   case NAND_CTL_SETALE:
+   fsl_upm_start_pattern(&fun->upm, fun->upm_addr_offset);
+  

Re: [U-Boot-Users] [PATCH] MPC85xx: Beatify boot output of L2 cache configuration

[Wolfgang Grandegger]

Andy Fleming wrote:
> On Wed, May 28, 2008 at 1:12 PM, Wolfgang Grandegger <[EMAIL PROTECTED]> 
> wrote:
>> The boot output is now aligned poperly with other boot output
>> lines, e.g.:
>>
>>  FLASH: 128 MB
>>  L2:512 KB enabled
>>
>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
> 
> A silly comment, but let's spell it "Beautify"

Of course, I didn't want to beatify this part of the code. New patch
will follow.

BTW: what is the correct way to send an updated version of a patch.
Should the subject be unchanged or is adding "v2" to [PATCH] preferred.

Wolfgang.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] 83xx/85xx/86xx: add more MxMR local bus definitions

[Wolfgang Grandegger]

Scott Wood wrote:
> On Mon, Jun 02, 2008 at 12:09:30PM +0200, Wolfgang Grandegger wrote:
>> 83xx/85xx/86xx: add more MxMR local bus definitions
>>
>> This patch adds more macro definitions for the UPM Machine Mode Registers
>> They are copied from "include/mpc82xx.h" to simplify the merge of all 8xxx
>> common local bus definitions into include/asm-ppc/fsl_lbc.h.
> 
> We should move them rather than copy, and then include asm/fsl_lbc.h from
> asm/mpc8260.h.

Moving FSL local bus definitions from asm/mpc8260.h to asm/fsl_lbc.h is
 a big change as Anton already pointed out in

http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg06587.html

and not only restricted to the  MxMR definitions.

Wolfgang.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] NAND FSL UPM: driver re-write using the hwcontrol callback

[Wolfgang Grandegger]

Stefan Roese wrote:
> On Monday 02 June 2008, Wolfgang Grandegger wrote:
>>>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
>>> Acked-by: Anton Vorontsov <[EMAIL PROTECTED]>
>> All 4 patches are maintained by different people. What is the fastest
>> way to get these patches in? Maybe Stefan could pick them up directly?
>
> No. I can't. Simply because it's not my responsibility anymore. :)

Ah, right, no I remember. At http://www.denx.de/wiki/UBoot/Custodians
and http://git.denx.de/?p=u-boot.git;a=forks you are still listed as the
owner of u-boot-nand-flash.git.

> Scott Wood is now the custodian for NAND FLASH stuff. So he will
probably pick
> it up. Scott?

That would be nice.

Wolfgang.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH v2] MPC8360ERDK: adapt NAND interface for the re-written FSL NAND UPM driver

[Wolfgang Grandegger]

MPC8360ERDK: adapt NAND interface for the re-written FSL NAND UPM driver

This patch is based on the following patch sent a few minutes ago:
"[PATCH] NAND FSL UPM: driver re-write using the hwcontrol callback"

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
Acked-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
 board/freescale/mpc8360erdk/nand.c |   24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

Index: u-boot/board/freescale/mpc8360erdk/nand.c
===
--- u-boot.orig/board/freescale/mpc8360erdk/nand.c
+++ u-boot/board/freescale/mpc8360erdk/nand.c
@@ -39,6 +39,24 @@ static const u32 upm_array[] = {
0xfc00, 0xfc00, 0xfc00, 0xfc01, /* Words 60 to 63 */
 };

+static void upm_setup(struct fsl_upm *upm)
+{
+   int i;
+
+   /* write upm array */
+   out_be32(upm->mxmr, MxMR_OP_WARR);
+
+   for (i = 0; i < 64; i++) {
+   out_be32(upm->mdr, upm_array[i]);
+   out_8(upm->io_addr, 0x0);
+   }
+
+   /* normal operation */
+   out_be32(upm->mxmr, MxMR_OP_NORM);
+   while (in_be32(upm->mxmr) != MxMR_OP_NORM)
+   eieio();
+}
+
 static int dev_ready(void)
 {
if (in_be32(&im->qepio.ioport[4].pdat) & 0x2000) {
@@ -52,10 +70,9 @@ static int dev_ready(void)

 static struct fsl_upm_nand fun = {
.upm = {
-   .array = upm_array,
.io_addr = (void *)CFG_NAND_BASE,
},
-   .width = 1,
+   .width = 8,
.upm_cmd_offset = 8,
.upm_addr_offset = 16,
.dev_ready = dev_ready,
@@ -68,5 +85,8 @@ int board_nand_init(struct nand_chip *na
fun.upm.mxmr = &im->lbus.mamr;
fun.upm.mdr = &im->lbus.mdr;
fun.upm.mar = &im->lbus.mar;
+
+   upm_setup(&fun.upm);
+
return fsl_upm_nand_init(nand, &fun);
 }

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] NAND FSL UPM: driver re-write using the hwcontrol callback

[Wolfgang Grandegger]

Anton Vorontsov wrote:
> On Mon, Jun 02, 2008 at 12:11:11PM +0200, Wolfgang Grandegger wrote:
>> NAND FSL UPM: driver re-write using the hwcontrol callback
>>
>> This is a re-write of the NAND FSL UPM driver using the more universal
>> hwcontrol callback (instead of the cmdfunc callback). Here is a brief
>> list of furher modifications:
>>
>> - For the time being, the UPM setup writing the UPM array has been
>>   removed from the driver and must now be done by the board specific
>>   code.
>>
>> - The bus width definition in "struct fsl_upm_nand" is now in bits to
>>   comply with the corresponding Linux driver.
>>
>> - chip->dev_read is only set if fun->dev_ready != NULL, which is
>>   required for boards not connecting the R/B pin.
>>
>> - A few issue have been fixed with MxMR bit manipulation like in the
>>   corresponding Linux driver.
>>
>> Note: I think the "io_addr" field of "struct fsl_upm" could be removed
>>   as well, because the address is already determined by
>>   "nand->IO_ADDR_[RW]", but I'm not 100% sure.
>>
>> This patch has been tested on a TQM8548 modules with the NAND chip
>> Micron MT29F8G08FABWP.
>>
>> This patch is based on the following patches posted to this list a few
>> minutes ago:
>>
>>   [PATCH] PPC: add accessor macros to clear and set bits in one shot
>>   [PATCH] 83xx/85xx/86xx: add more MxMR local bus definitions
>>
>> Anton, could you please verify if it works on your MPC8360ERDK board as
>> well. A patch will follow. In principle, the NAND driver of the TQM8272
>> should work with it as well.
> 
> Works great here (tested on MPC8360E-RDK). Thanks!

Great.

>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
> 
> Acked-by: Anton Vorontsov <[EMAIL PROTECTED]>

All 4 patches are maintained by different people. What is the fastest
way to get these patches in? Maybe Stefan could pick them up directly?

Wolfgang.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] MPC8360ERDK: adapt NAND interface for the re-written FSL NAND UPM driver

[Wolfgang Grandegger]

Anton Vorontsov wrote:
> On Mon, Jun 02, 2008 at 12:14:51PM +0200, Wolfgang Grandegger wrote:
>> MPC8360ERDK: adapt NAND interface for the re-written FSL NAND UPM driver
>>
>> This patch is based on the following patch sent a few minutes ago:
>> "[PATCH] NAND FSL UPM: driver re-write using the hwcontrol callback"
>> It is untested, of course. Anton, could you please give it a try.
>>
>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
> 
> Acked-by: Anton Vorontsov <[EMAIL PROTECTED]>
> 
> [...]
>> @@ -68,5 +89,9 @@ int board_nand_init(struct nand_chip *na
>>  fun.upm.mxmr = &im->lbus.mamr;
>>  fun.upm.mdr = &im->lbus.mdr;
>>  fun.upm.mar = &im->lbus.mar;
>> +
>> +if (!upm_setup_done)
> 
> Not sure if this is really needed for this board though, nobody will
> call this function more than once...

Right, also because io_addr is hard coded. I will remove it.

Wolfgang.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] MPC8360ERDK: adapt NAND interface for the re-written FSL NAND UPM driver

[Wolfgang Grandegger]

MPC8360ERDK: adapt NAND interface for the re-written FSL NAND UPM driver

This patch is based on the following patch sent a few minutes ago:
"[PATCH] NAND FSL UPM: driver re-write using the hwcontrol callback"
It is untested, of course. Anton, could you please give it a try.

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 board/freescale/mpc8360erdk/nand.c |   29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

Index: u-boot/board/freescale/mpc8360erdk/nand.c
===
--- u-boot.orig/board/freescale/mpc8360erdk/nand.c
+++ u-boot/board/freescale/mpc8360erdk/nand.c
@@ -39,6 +39,28 @@ static const u32 upm_array[] = {
0xfc00, 0xfc00, 0xfc00, 0xfc01, /* Words 60 to 63 */
 };
 
+static int upm_setup_done;
+
+static void upm_setup(struct fsl_upm *upm)
+{
+   int i;
+
+   /* write upm array */
+   out_be32(upm->mxmr, MxMR_OP_WARR);
+
+   for (i = 0; i < 64; i++) {
+   out_be32(upm->mdr, upm_array[i]);
+   out_8(upm->io_addr, 0x0);
+   }
+
+   /* normal operation */
+   out_be32(upm->mxmr, MxMR_OP_NORM);
+   while (in_be32(upm->mxmr) != MxMR_OP_NORM)
+   eieio();
+
+   upm_setup_done = 1;
+}
+
 static int dev_ready(void)
 {
if (in_be32(&im->qepio.ioport[4].pdat) & 0x2000) {
@@ -52,10 +74,9 @@ static int dev_ready(void)
 
 static struct fsl_upm_nand fun = {
.upm = {
-   .array = upm_array,
.io_addr = (void *)CFG_NAND_BASE,
},
-   .width = 1,
+   .width = 8,
.upm_cmd_offset = 8,
.upm_addr_offset = 16,
.dev_ready = dev_ready,
@@ -68,5 +89,9 @@ int board_nand_init(struct nand_chip *na
fun.upm.mxmr = &im->lbus.mamr;
fun.upm.mdr = &im->lbus.mdr;
fun.upm.mar = &im->lbus.mar;
+
+   if (!upm_setup_done)
+   upm_setup(&fun.upm);
+
return fsl_upm_nand_init(nand, &fun);
 }

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] NAND FSL UPM: driver re-write using the hwcontrol callback

[Wolfgang Grandegger]

NAND FSL UPM: driver re-write using the hwcontrol callback

This is a re-write of the NAND FSL UPM driver using the more universal
hwcontrol callback (instead of the cmdfunc callback). Here is a brief
list of furher modifications:

- For the time being, the UPM setup writing the UPM array has been
  removed from the driver and must now be done by the board specific
  code.

- The bus width definition in "struct fsl_upm_nand" is now in bits to
  comply with the corresponding Linux driver.

- chip->dev_read is only set if fun->dev_ready != NULL, which is
  required for boards not connecting the R/B pin.

- A few issue have been fixed with MxMR bit manipulation like in the
  corresponding Linux driver.

Note: I think the "io_addr" field of "struct fsl_upm" could be removed
  as well, because the address is already determined by
  "nand->IO_ADDR_[RW]", but I'm not 100% sure.

This patch has been tested on a TQM8548 modules with the NAND chip
Micron MT29F8G08FABWP.

This patch is based on the following patches posted to this list a few
minutes ago:

  [PATCH] PPC: add accessor macros to clear and set bits in one shot
  [PATCH] 83xx/85xx/86xx: add more MxMR local bus definitions

Anton, could you please verify if it works on your MPC8360ERDK board as
well. A patch will follow. In principle, the NAND driver of the TQM8272
should work with it as well.

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 drivers/mtd/nand/fsl_upm.c  |  133 +---
 include/linux/mtd/fsl_upm.h |1 
 2 files changed, 52 insertions(+), 82 deletions(-)

Index: u-boot/drivers/mtd/nand/fsl_upm.c
===
--- u-boot.orig/drivers/mtd/nand/fsl_upm.c
+++ u-boot/drivers/mtd/nand/fsl_upm.c
@@ -20,112 +20,89 @@
 #include 
 #include 
 
-#define FSL_UPM_MxMR_OP_NO (0 << 28) /* normal operation */
-#define FSL_UPM_MxMR_OP_WA (1 << 28) /* write array */
-#define FSL_UPM_MxMR_OP_RA (2 << 28) /* read array */
-#define FSL_UPM_MxMR_OP_RP (3 << 28) /* run pattern */
+static int fsl_upm_in_pattern;
 
 static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
 {
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_RP | pat_offset);
+   clrsetbits_be32(upm->mxmr, MxMR_MAD_MSK, MxMR_OP_RUNP | pat_offset);
 }
 
 static void fsl_upm_end_pattern(struct fsl_upm *upm)
 {
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
-   while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
+   clrbits32(upm->mxmr, MxMR_OP_RUNP);
+
+   while (in_be32(upm->mxmr) & MxMR_OP_RUNP)
eieio();
 }
 
 static void fsl_upm_run_pattern(struct fsl_upm *upm, int width, u32 cmd)
 {
-   out_be32(upm->mar, cmd << (32 - width * 8));
-   out_8(upm->io_addr, 0x0);
-}
-
-static void fsl_upm_setup(struct fsl_upm *upm)
-{
-   int i;
-
-   /* write upm array */
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_WA);
-
-   for (i = 0; i < 64; i++) {
-   out_be32(upm->mdr, upm->array[i]);
+   out_be32(upm->mar, cmd << (32 - width));
+   switch (width) {
+   case 8:
out_8(upm->io_addr, 0x0);
+   break;
+   case 16:
+   out_be16(upm->io_addr, 0x0);
+   break;
+   case 32:
+   out_be32(upm->io_addr, 0x0);
+   break;
}
-
-   /* normal operation */
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
-   while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
-   eieio();
 }
 
-static void fun_cmdfunc(struct mtd_info *mtd, unsigned command, int column,
-   int page_addr)
+static void nand_hwcontrol (struct mtd_info *mtd, int cmd)
 {
struct nand_chip *chip = mtd->priv;
struct fsl_upm_nand *fun = chip->priv;
 
-   fsl_upm_start_pattern(&fun->upm, fun->upm_cmd_offset);
-
-   if (command == NAND_CMD_SEQIN) {
-   int readcmd;
-
-   if (column >= mtd->oobblock) {
-   /* OOB area */
-   column -= mtd->oobblock;
-   readcmd = NAND_CMD_READOOB;
-   } else if (column < 256) {
-   /* First 256 bytes --> READ0 */
-   readcmd = NAND_CMD_READ0;
-   } else {
-   column -= 256;
-   readcmd = NAND_CMD_READ1;
-   }
-   fsl_upm_run_pattern(&fun->upm, fun->width, readcmd);
+   switch (cmd) {
+   case NAND_CTL_SETCLE:
+   fsl_upm_start_pattern(&fun->upm, fun->upm_cmd_offset);
+   fsl_upm_in_pattern++;
+   break;
+   case NAND_CTL_SETALE:
+   fsl_upm_start_pattern(&fun->upm, fun->upm_addr_offset);
+   fsl_upm_in_patt

[U-Boot-Users] [PATCH] 83xx/85xx/86xx: add more MxMR local bus definitions

[Wolfgang Grandegger]

83xx/85xx/86xx: add more MxMR local bus definitions

This patch adds more macro definitions for the UPM Machine Mode Registers
They are copied from "include/mpc82xx.h" to simplify the merge of all 8xxx
common local bus definitions into include/asm-ppc/fsl_lbc.h. They are
required for my forthcoming FSL NAND UPM driver re-write and the support
for the TQM8548 module.

This patch is based on the following two patches from Anton Vorontsov:

http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg06511.html
http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg06587.html

I leave coding style violation fixes, code beautification and name
corrections to somebody else ;-(.

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 include/asm-ppc/fsl_lbc.h |   43 ++-
 1 file changed, 38 insertions(+), 5 deletions(-)

Index: u-boot/include/asm-ppc/fsl_lbc.h
===
--- u-boot.orig/include/asm-ppc/fsl_lbc.h
+++ u-boot/include/asm-ppc/fsl_lbc.h
@@ -161,11 +161,6 @@
 #define OR_UPM_EAD 0x0001
 #define OR_UPM_EAD_SHIFT   0
 
-#define MxMR_OP_NORM   0x /* Normal Operation */
-#define MxMR_DSx_2_CYCL0x0040 /* 2 cycle Disable Period */
-#define MxMR_OP_WARR   0x1000 /* Write to Array */
-#define MxMR_BSEL  0x8000 /* Bus Select */
-
 #define OR_SDRAM_AM0x8000
 #define OR_SDRAM_AM_SHIFT  15
 #define OR_SDRAM_XAM   0x6000
@@ -198,6 +193,44 @@
 #define OR_AM_2GB  0x8000
 #define OR_AM_4GB  0x
 
+/* MxMR - UPM Machine A/B/C Mode Registers
+ */
+#define MxMR_MAD_MSK   0x003f /* Machine Address Mask */
+#define MxMR_TLFx_MSK  0x03c0 /* Refresh Loop Field Mask  */
+#define MxMR_WLFx_MSK  0x3c00 /* Write Loop Field Mask*/
+#define MxMR_WLFx_1X   0x0400 /*   executed 1 time*/
+#define MxMR_WLFx_2X   0x0800 /*   executed 2 times   */
+#define MxMR_WLFx_3X   0x0c00 /*   executed 3 times   */
+#define MxMR_WLFx_4X   0x1000 /*   executed 4 times   */
+#define MxMR_WLFx_5X   0x1400 /*   executed 5 times   */
+#define MxMR_WLFx_6X   0x1800 /*   executed 6 times   */
+#define MxMR_WLFx_7X   0x1c00 /*   executed 7 times   */
+#define MxMR_WLFx_8X   0x2000 /*   executed 8 times   */
+#define MxMR_WLFx_9X   0x2400 /*   executed 9 times   */
+#define MxMR_WLFx_10X  0x2800 /*   executed 10 times  */
+#define MxMR_WLFx_11X  0x2c00 /*   executed 11 times  */
+#define MxMR_WLFx_12X  0x3000 /*   executed 12 times  */
+#define MxMR_WLFx_13X  0x3400 /*   executed 13 times  */
+#define MxMR_WLFx_14X  0x3800 /*   executed 14 times  */
+#define MxMR_WLFx_15X  0x3c00 /*   executed 15 times  */
+#define MxMR_WLFx_16X  0x /*   executed 16 times  */
+#define MxMR_RLFx_MSK  0x0003c000 /* Read Loop Field Mask */
+#define MxMR_GPL_x4DIS 0x0004 /* GPL_A4 Ouput Line Disable*/
+#define MxMR_G0CLx_MSK 0x0038 /* General Line 0 Control Mask  */
+#define MxMR_DSx_1_CYCL0x /* 1 cycle Disable Period
   */
+#define MxMR_DSx_2_CYCL0x0040 /* 2 cycle Disable Period
   */
+#define MxMR_DSx_3_CYCL0x0080 /* 3 cycle Disable Period
   */
+#define MxMR_DSx_4_CYCL0x00c0 /* 4 cycle Disable Period
   */
+#define MxMR_DSx_MSK   0x00c0 /* Disable Timer Period Mask*/
+#define MxMR_AMx_MSK   0x0700 /* Addess Multiplex Size Mask   */
+#define MxMR_OP_NORM   0x /* Normal Operation */
+#define MxMR_OP_WARR   0x1000 /* Write to Array   */
+#define MxMR_OP_RARR   0x2000 /* Read from Array  */
+#define MxMR_OP_RUNP   0x3000 /* Run Pattern  */
+#define MxMR_OP_MSK0x3000 /* Command Opcode Mask  */
+#define MxMR_RFEN  0x4000 /* Refresh Enable   */
+#define MxMR_BSEL  0x8000 /* Bus Select   */
+
 #define LBLAWAR_EN 0x8000
 #define LBLAWAR_4KB0x000B
 #define LBLAWAR_8KB0x000C

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012

[U-Boot-Users] [PATCH] PPC: add accessor macros to clear and set bits in one shot

[Wolfgang Grandegger]

PPC: add accessor macros to clear and set bits in one shot

This patch adds macros from linux/include/asm-powerpc/io.h to clear and
set bits in one shot using the in_be32, out_be32, etc. accessor functions.
They are very handy to manipulate bits it I/O registers.

This patch is required for my forthcoming FSL NAND UPM driver re-write and
the support for the TQM8548 module.

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 include/asm-ppc/io.h |   28 
 1 file changed, 28 insertions(+)

Index: u-boot/include/asm-ppc/io.h
===
--- u-boot.orig/include/asm-ppc/io.h
+++ u-boot/include/asm-ppc/io.h
@@ -238,6 +238,34 @@ extern inline void out_be32(volatile uns
__asm__ __volatile__("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" 
(val));
 }
 
+/* access ports */
+#define setbits32(_addr, _v) out_be32((_addr), in_be32(_addr) |  (_v))
+#define clrbits32(_addr, _v) out_be32((_addr), in_be32(_addr) & ~(_v))
+
+#define setbits16(_addr, _v) out_be16((_addr), in_be16(_addr) |  (_v))
+#define clrbits16(_addr, _v) out_be16((_addr), in_be16(_addr) & ~(_v))
+
+#define setbits8(_addr, _v) out_8((_addr), in_8(_addr) |  (_v))
+#define clrbits8(_addr, _v) out_8((_addr), in_8(_addr) & ~(_v))
+
+/* Clear and set bits in one shot.  These macros can be used to clear and
+ * set multiple bits in a register using a single read-modify-write.  These
+ * macros can also be used to set a multiple-bit bit pattern using a mask,
+ * by specifying the mask in the 'clear' parameter and the new bit pattern
+ * in the 'set' parameter.
+ */
+
+#define clrsetbits(type, addr, clear, set) \
+   out_##type((addr), (in_##type(addr) & ~(clear)) | (set))
+
+#define clrsetbits_be32(addr, clear, set) clrsetbits(be32, addr, clear, set)
+#define clrsetbits_le32(addr, clear, set) clrsetbits(le32, addr, clear, set)
+
+#define clrsetbits_be16(addr, clear, set) clrsetbits(be16, addr, clear, set)
+#define clrsetbits_le16(addr, clear, set) clrsetbits(le32, addr, clear, set)
+
+#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+
 /*
  * Given a physical address and a length, return a virtual address
  * that can be used to access the memory range with the caching

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] TQM85xx: NAND support via local bus UPMB

[Wolfgang Grandegger]

Anton Vorontsov wrote:
> On Fri, May 30, 2008 at 08:00:32PM +0200, Wolfgang Grandegger wrote:
> [...]
>> Fix that, but I can still not access the device properly. I'm a bit
>> puzzled because it uses a different algorithm to access the device.
>> While my and the Linux fsl_upm driver uses NAND_ALE, NAND_CLE and
>> friends to manage the access via hwcontrol callback, the fsl_upm driver
>> of U-Boot uses the cmdfunc callback doing different things. 
> 
> I wonder if your NAND chip is a large page one? Because currently
> fsl_upm_nand hardcodes OOB stuff (bad thing, but with old mtd subsystem
> I didn't find better way ;-).
> 
> As for u-boot and linux doing different things... with this patch
> u-boot and linux are identical:
> 
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-nand-flash.git;a=commitdiff;h=dffa9a8b31b2c21fd3a72ba1f58dd04911b95b6f
> 
> This is in U-Boot's mtd-2.6.22.1 branch though. :-/ Your approach with hwctl
> seem to be more universal (for old mtd subsystem), since it doesn't duplicate
> MTD cmdfunc, thus should work for all NAND chips...
> 
> Could you prepare a patch that replacing fsl_upm_nand.c's current logic
> with yours (that should work for your NAND chip), and I'll test it
> on MPC8360E-RDK?

Here we go. I'm going to send 4 patches that work for me on my TQM8548
module. Could you please give it a try?

Thanks,

Wolfgang.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] TQM85xx: NAND support via local bus UPMB

[Wolfgang Grandegger]

Wolfgang Grandegger wrote:
> Anton Vorontsov wrote:
>> On Fri, May 30, 2008 at 08:00:32PM +0200, Wolfgang Grandegger wrote:
>> [...]
>>> Fix that, but I can still not access the device properly. I'm a bit
>>> puzzled because it uses a different algorithm to access the device.
>>> While my and the Linux fsl_upm driver uses NAND_ALE, NAND_CLE and
>>> friends to manage the access via hwcontrol callback, the fsl_upm driver
>>> of U-Boot uses the cmdfunc callback doing different things. 
>> I wonder if your NAND chip is a large page one? Because currently
>> fsl_upm_nand hardcodes OOB stuff (bad thing, but with old mtd subsystem
>> I didn't find better way ;-).
> 
> On my TQM8548 there is a Micron MT29F8G08FABWP, page size 2048 + 64
> bytes, block size 128K + 4K bytes.
> 
>> As for u-boot and linux doing different things... with this patch
>> u-boot and linux are identical:
>>
>> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-nand-flash.git;a=commitdiff;h=dffa9a8b31b2c21fd3a72ba1f58dd04911b95b6f
>>
>> This is in U-Boot's mtd-2.6.22.1 branch though. :-/ Your approach with hwctl
>> seem to be more universal (for old mtd subsystem), since it doesn't duplicate
>> MTD cmdfunc, thus should work for all NAND chips...
> 
> A closer look to the code confirms that.
> 
>> Could you prepare a patch that replacing fsl_upm_nand.c's current logic
>> with yours (that should work for your NAND chip), and I'll test it
>> on MPC8360E-RDK?
> 
> The attached preliminary patch works for me. Compared to my specific
> driver, it saves start_pattern and end_pattern calls :-).
> It now also supports a bus width of 8, 16 and 32 bits and width is now
> in bits like in the Linux driver. I'm going to prepare a proper patch
> series beginning of next week.

Here is the missing patch:

---
 drivers/mtd/nand/fsl_upm.c |  132 +
 include/asm-ppc/io.h   |   28 +
 2 files changed, 79 insertions(+), 81 deletions(-)

Index: u-boot/drivers/mtd/nand/fsl_upm.c
===
--- u-boot.orig/drivers/mtd/nand/fsl_upm.c
+++ u-boot/drivers/mtd/nand/fsl_upm.c
@@ -20,112 +20,89 @@
 #include 
 #include 
 
-#define FSL_UPM_MxMR_OP_NO (0 << 28) /* normal operation */
-#define FSL_UPM_MxMR_OP_WA (1 << 28) /* write array */
-#define FSL_UPM_MxMR_OP_RA (2 << 28) /* read array */
-#define FSL_UPM_MxMR_OP_RP (3 << 28) /* run pattern */
+static int fsl_upm_in_pattern;
 
 static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
 {
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_RP | pat_offset);
+   clrsetbits_be32(upm->mxmr, MxMR_MAD, MxMR_OP_RUN | pat_offset);
 }
 
 static void fsl_upm_end_pattern(struct fsl_upm *upm)
 {
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
-   while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
+   clrbits32(upm->mxmr, MxMR_OP_RUN);
+
+   while (in_be32(upm->mxmr) & MxMR_OP_RUN)
eieio();
 }
 
 static void fsl_upm_run_pattern(struct fsl_upm *upm, int width, u32 cmd)
 {
-   out_be32(upm->mar, cmd << (32 - width * 8));
-   out_8(upm->io_addr, 0x0);
-}
-
-static void fsl_upm_setup(struct fsl_upm *upm)
-{
-   int i;
-
-   /* write upm array */
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_WA);
-
-   for (i = 0; i < 64; i++) {
-   out_be32(upm->mdr, upm->array[i]);
-   out_8(upm->io_addr, 0x0);
+   out_be32(upm->mar, cmd << (32 - width));
+   switch (width) {
+   case 8:
+   out_8(io_base, 0x0);
+   break;
+   case 16:
+   out_be16(io_base, 0x0);
+   break;
+   case 32:
+   out_be32(io_base, 0x0);
+   break;
}
-
-   /* normal operation */
-   out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
-   while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
-   eieio();
 }
 
-static void fun_cmdfunc(struct mtd_info *mtd, unsigned command, int column,
-   int page_addr)
+static void nand_hwcontrol (struct mtd_info *mtd, int cmd)
 {
struct nand_chip *chip = mtd->priv;
struct fsl_upm_nand *fun = chip->priv;
 
-   fsl_upm_start_pattern(&fun->upm, fun->upm_cmd_offset);
-
-   if (command == NAND_CMD_SEQIN) {
-   int readcmd;
-
-   if (column >= mtd->oobblock) {
-   /* OOB area */
-   column -= mtd->oobblock;
-   readcmd = NAND_CMD_READOOB;
-   } else if (column < 256) {
-   /* First 256 bytes --> READ0 */
-   readcmd = N

Re: [U-Boot-Users] [PATCH] TQM85xx: NAND support via local bus UPMB

[Wolfgang Grandegger]

Anton Vorontsov wrote:
> On Fri, May 30, 2008 at 08:00:32PM +0200, Wolfgang Grandegger wrote:
> [...]
>> Fix that, but I can still not access the device properly. I'm a bit
>> puzzled because it uses a different algorithm to access the device.
>> While my and the Linux fsl_upm driver uses NAND_ALE, NAND_CLE and
>> friends to manage the access via hwcontrol callback, the fsl_upm driver
>> of U-Boot uses the cmdfunc callback doing different things. 
> 
> I wonder if your NAND chip is a large page one? Because currently
> fsl_upm_nand hardcodes OOB stuff (bad thing, but with old mtd subsystem
> I didn't find better way ;-).

On my TQM8548 there is a Micron MT29F8G08FABWP, page size 2048 + 64
bytes, block size 128K + 4K bytes.

> As for u-boot and linux doing different things... with this patch
> u-boot and linux are identical:
> 
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-nand-flash.git;a=commitdiff;h=dffa9a8b31b2c21fd3a72ba1f58dd04911b95b6f
> 
> This is in U-Boot's mtd-2.6.22.1 branch though. :-/ Your approach with hwctl
> seem to be more universal (for old mtd subsystem), since it doesn't duplicate
> MTD cmdfunc, thus should work for all NAND chips...

A closer look to the code confirms that.

> Could you prepare a patch that replacing fsl_upm_nand.c's current logic
> with yours (that should work for your NAND chip), and I'll test it
> on MPC8360E-RDK?

The attached preliminary patch works for me. Compared to my specific
driver, it saves start_pattern and end_pattern calls :-).
It now also supports a bus width of 8, 16 and 32 bits and width is now
in bits like in the Linux driver. I'm going to prepare a proper patch
series beginning of next week.

Wolfgang.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] TQM85xx: NAND support via local bus UPMB

[Wolfgang Grandegger]

Anton Vorontsov wrote:
> On Thu, May 29, 2008 at 01:58:14PM +0200, Wolfgang Grandegger wrote:
>> Anton Vorontsov wrote:
>>> On Wed, May 28, 2008 at 08:38:37PM +0200, Wolfgang Grandegger wrote:
>>>> Scott Wood wrote:
>>>>> On Wed, May 28, 2008 at 08:12:28PM +0200, Wolfgang Grandegger wrote:
>>>>>> This patch adds support for NAND FLASH on the TQM8548. It is disabled by
>>>>>> default and can be enabled for the TQM8548 modules. Note that the R/B pin
>>>>>> is not supported by that module requiring to use the specified maximum
>>>>>> delay time.
>>>>>>
>>>>>> Note: With NAND support enabled the size of the U-Boot image exceeds
>>>>>> 256 KB and TEXT_BASE must therefore be set to 0xfff8 in config.mk,
>>>>>> doubling the image size :-(.
>>>>> What does this do differently from the code in drivers/mtd/nand/fsl_upm.c?
>>>> Maybe it does not support multi banks on a NAND chip. I have to check.
>>> Me thinks that you'll have to call fsl_upm_nand_init() for each
>>> chip, and that's all. If not, feel free to patch it as you feel appropriate,
>>> I'll able to regress-test this driver on MPC8360E-RDK.
>> That seems not to be a minor problem. If CFG_MAX_NAND_DEVICE > 1,
>> board_nand_init() will be called twice with the base address from
>> CFG_NAND_BASE_LIST. The only problem I see is that the UPM interface is
>> setup twice.
> 
> Personally I think we should remove UPM programming code from the
> fsl_upm_nand.c, and program the UPM via its own interface, see this post:
> 
> From: David Saada <[EMAIL PROTECTED]>
> To: "'u-boot-users@lists.sourceforge.net'" 
> 
> Date: Mon, 19 May 2008 19:05:04 +0300
> Subject: [U-Boot-Users] [PATCH][resubmit] MPC85xx, MPC83xx: Add/Fix UPM 
> configuration support
> 
> ^^^ But this is still WIP, and I'm not sure if this is suitable for our
> needs (didn't try it).

OK.

>>>>> How much of this is board-specific?
>>>> Well, I already gave drivers/mtd/nand/fsl_upm.c a try but was unable to
>>>> get it working on this board. Therefore I decided to keep this known to
>>>> work driver which we have already for a while.
>>> This isn't really an excuse to duplicate drivers. :-) This driver was
>>> tested on MPC8555 and MPC8360 CPUs, so it should work with no drastic
>>> changes. Some issues might still be there, and if so, fixes are highly
>>> appreciated.
>> I know, sniff.
>>
>>>> With Linux, I had more success.
>>> ..especially if general idea works well, we should use single driver.
>> I already had a closer look and realized a difference in writing the UPM
>> array. In fsl_upm.c there is:
>>
>>   static void fsl_upm_setup(struct fsl_upm *upm)
>>   {
>>  int i;
>>
>>  /* write upm array */
>>  out_be32(upm->mxmr, FSL_UPM_MxMR_OP_WA);
>>
>>  for (i = 0; i < 64; i++) {
>>  out_be32(upm->mdr, upm->array[i]);
>>  out_8(upm->io_addr, 0x0);
>>  }
>>
>>  /* normal operation */
>>  out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
>>  while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
>>  eieio();
>>   }
>>
>> But in my driver I fold the machine address into mbmr for each value:
>>
>> out_be32 (&lbc->mbmr,
>>  (in_be32 (&lbc->mbmr) & ~(MxMR_OP_NORM | MxMR_MAD)) |
>>   MxMR_OP_WARR | (i & MxMR_MAD));
>>   ^
> 
> I see. I think there will be a problem with a
> 
> static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
> {
> out_be32(upm->mxmr, FSL_UPM_MxMR_OP_RP | pat_offset);
> }
> 
> static void fsl_upm_end_pattern(struct fsl_upm *upm)
> {
> out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
> while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
> eieio();
> }
> 
> Since it zeroes these values. No problem though, this should
> be replaced by the Linux' versions, that is
> 
> clrsetbits_be32(upm->mxmr, MxMR_MAD, MxMR_OP_RP | pat_offset);
> for start_pattern, and  clrbits32(upm->mxmr, MxMR_OP_RP); for
> end_pattern.
> 
> So, this will leave your values intact, and will work for all boards as
> well.

Fix that, but I can still not access the device properly. I'm a bit
puzzled because it uses a different algorithm to access the device.
While my and the

Re: [U-Boot-Users] [PATCH] TQM85xx: NAND support via local bus UPMB

[Wolfgang Grandegger]

Anton Vorontsov wrote:
> On Wed, May 28, 2008 at 08:38:37PM +0200, Wolfgang Grandegger wrote:
>> Scott Wood wrote:
>>> On Wed, May 28, 2008 at 08:12:28PM +0200, Wolfgang Grandegger wrote:
>>>> This patch adds support for NAND FLASH on the TQM8548. It is disabled by
>>>> default and can be enabled for the TQM8548 modules. Note that the R/B pin
>>>> is not supported by that module requiring to use the specified maximum
>>>> delay time.
>>>>
>>>> Note: With NAND support enabled the size of the U-Boot image exceeds
>>>> 256 KB and TEXT_BASE must therefore be set to 0xfff8 in config.mk,
>>>> doubling the image size :-(.
>>> What does this do differently from the code in drivers/mtd/nand/fsl_upm.c?
>> Maybe it does not support multi banks on a NAND chip. I have to check.
> 
> Me thinks that you'll have to call fsl_upm_nand_init() for each
> chip, and that's all. If not, feel free to patch it as you feel appropriate,
> I'll able to regress-test this driver on MPC8360E-RDK.

That seems not to be a minor problem. If CFG_MAX_NAND_DEVICE > 1,
board_nand_init() will be called twice with the base address from
CFG_NAND_BASE_LIST. The only problem I see is that the UPM interface is
setup twice.

>>> How much of this is board-specific?
>> Well, I already gave drivers/mtd/nand/fsl_upm.c a try but was unable to
>> get it working on this board. Therefore I decided to keep this known to
>> work driver which we have already for a while.
> 
> This isn't really an excuse to duplicate drivers. :-) This driver was
> tested on MPC8555 and MPC8360 CPUs, so it should work with no drastic
> changes. Some issues might still be there, and if so, fixes are highly
> appreciated.

I know, sniff.

>> With Linux, I had more success.
> 
> ..especially if general idea works well, we should use single driver.

I already had a closer look and realized a difference in writing the UPM
array. In fsl_upm.c there is:

  static void fsl_upm_setup(struct fsl_upm *upm)
  {
int i;

/* write upm array */
out_be32(upm->mxmr, FSL_UPM_MxMR_OP_WA);

for (i = 0; i < 64; i++) {
out_be32(upm->mdr, upm->array[i]);
out_8(upm->io_addr, 0x0);
}

/* normal operation */
out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
eieio();
  }

But in my driver I fold the machine address into mbmr for each value:

out_be32 (&lbc->mbmr,
 (in_be32 (&lbc->mbmr) & ~(MxMR_OP_NORM | MxMR_MAD)) |
  MxMR_OP_WARR | (i & MxMR_MAD));
  ^

Seem also that defines a duplicated :-(.

Has it been tested with an MPC85xx? I will do some more test now.

Wolfgang.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] TQM: move TQM boards to board/tqc

[Wolfgang Grandegger]

[EMAIL PROTECTED] wrote:
> From: Wolfgang Grandegger <[EMAIL PROTECTED]>
> 
> Move all TQM board directories to the vendor specific directory "tqc"
> for modules from TQ-Components GmbH (http://www.tqc.de).
> 
> Note: this patch is too big for posting here and therefore I removed
> the hunks moving the files. I could provide the full patch on request.
> 
> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>

Wolfgang, could you please apply this patch/commit directly, if there
are no objections.

Thanks.

Wolfgang.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] TQM85xx: NAND support via local bus UPMB

[Wolfgang Grandegger]

Scott Wood wrote:
> On Wed, May 28, 2008 at 08:12:28PM +0200, Wolfgang Grandegger wrote:
>> This patch adds support for NAND FLASH on the TQM8548. It is disabled by
>> default and can be enabled for the TQM8548 modules. Note that the R/B pin
>> is not supported by that module requiring to use the specified maximum
>> delay time.
>>
>> Note: With NAND support enabled the size of the U-Boot image exceeds
>> 256 KB and TEXT_BASE must therefore be set to 0xfff8 in config.mk,
>> doubling the image size :-(.
> 
> What does this do differently from the code in drivers/mtd/nand/fsl_upm.c?

Maybe it does not support multi banks on a NAND chip. I have to check.

> How much of this is board-specific?

Well, I already gave drivers/mtd/nand/fsl_upm.c a try but was unable to
get it working on this board. Therefore I decided to keep this known to
work driver which we have already for a while.

With Linux, I had more success.

Wolfgang.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] TQM85xx: Change memory map to support Flash memory > 128 MiB

[Wolfgang Grandegger]

Some TQM85xx boards could be equipped with up to 1 GiB (NOR) Flash
memory. The current memory map only supports up to 128 MiB Flash.
This patch adds the configuration option CONFIG_TQM_BIGFLASH. If
set, up to 1 GiB flash is supported. To achieve this, the memory
map has to be adjusted in great parts (for example the CCSRBAR is
moved from 0xE000 to 0xA000).

If you want to boot Linux with CONFIG_TQM_BIGFLASH set, the new
memory map also has to be considered in the kernel (changed
CCSRBAR address, changed PCI IO base address, ...). Please use
an appropriate Flat Device Tree blob (tqm8548.dtb).

Signed-off-by: Martin Krause <[EMAIL PROTECTED]>
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 board/tqc/tqm85xx/law.c   |   29 --
 board/tqc/tqm85xx/tlb.c   |   97 +
 include/configs/TQM85xx.h |   52 +---
 3 files changed, 167 insertions(+), 11 deletions(-)

diff --git a/board/tqc/tqm85xx/law.c b/board/tqc/tqm85xx/law.c
index 914ce68..b4e663b 100644
--- a/board/tqc/tqm85xx/law.c
+++ b/board/tqc/tqm85xx/law.c
@@ -30,6 +30,8 @@
 /*
  * LAW(Local Access Window) configuration:
  *
+ * Standard mapping:
+ *
  * 0x_0x7fff_ DDR 2G
  * 0x8000_0x9fff_ PCI1 MEM512M
  * 0xc000_0xdfff_ RapidIO or PCI express  512M
@@ -37,22 +39,41 @@
  * 0xe200_0xe2ff_ PCI1 IO 16M
  * 0xe300_0xe3ff_ CAN and NAND Flash  16M
  * 0xef00_0xefff_ PCI express IO  16M
- * 0xfe00_0x_ FLASH (boot bank)   32M
+ * 0xfc00_0x_ FLASH (boot bank)   128M
+ *
+ * Big FLASH mapping:
+ *
+ * 0x_0x7fff_ DDR 2G
+ * 0x8000_0x9fff_ PCI1 MEM512M
+ * 0xa000_0xa000_ CCSR1M
+ * 0xa200_0xa2ff_ PCI1 IO 16M
+ * 0xa300_0xa3ff_ CAN and NAND Flash  16M
+ * 0xaf00_0xafff_ PCI express IO  16M
+ * 0xb000_0xbfff_ RapidIO or PCI express  256M
+ * 0xc000_0x_ FLASH (boot bank)   1G
  *
  * Notes:
  *CCSRBAR and L2-as-SRAM don't need a configured Local Access Window.
  *If flash is 8M at default position (last 8M), no LAW needed.
  */
 
+#ifdef CONFIG_TQM_BIGFLASH
+#define LAW_3_SIZE LAW_SIZE_1G
+#define LAW_5_SIZE LAW_SIZE_256M
+#else
+#define LAW_3_SIZE LAW_SIZE_128M
+#define LAW_5_SIZE LAW_SIZE_512M
+#endif
+
 struct law_entry law_table[] = {
SET_LAW_ENTRY (1, CFG_DDR_SDRAM_BASE, LAW_SIZE_512M, LAW_TRGT_IF_DDR),
SET_LAW_ENTRY (2, CFG_PCI1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI),
-   SET_LAW_ENTRY (3, CFG_LBC_FLASH_BASE, LAW_SIZE_128M, LAW_TRGT_IF_LBC),
+   SET_LAW_ENTRY (3, CFG_LBC_FLASH_BASE, LAW_3_SIZE, LAW_TRGT_IF_LBC),
SET_LAW_ENTRY (4, CFG_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI),
 #ifdef CONFIG_PCIE1
-   SET_LAW_ENTRY (5, CFG_PCIE1_MEM_BASE, LAW_SIZE_512M, 
LAW_TRGT_IF_PCIE_1),
+   SET_LAW_ENTRY (5, CFG_PCIE1_MEM_BASE, LAW_5_SIZE, LAW_TRGT_IF_PCIE_1),
 #else /* !CONFIG_PCIE1 */
-   SET_LAW_ENTRY (5, CFG_RIO_MEM_BASE, LAW_SIZE_512M, LAW_TRGT_IF_RIO),
+   SET_LAW_ENTRY (5, CFG_RIO_MEM_BASE, LAW_5_SIZE, LAW_TRGT_IF_RIO),
 #endif /* CONFIG_PCIE1 */
 #if defined(CONFIG_CAN_DRIVER) || defined(CONFIG_NAND)
SET_LAW_ENTRY (6, CFG_CAN_BASE, LAW_SIZE_16M, LAW_TRGT_IF_LBC),
diff --git a/board/tqc/tqm85xx/tlb.c b/board/tqc/tqm85xx/tlb.c
index 7f4efc1..380448a 100644
--- a/board/tqc/tqm85xx/tlb.c
+++ b/board/tqc/tqm85xx/tlb.c
@@ -44,6 +44,7 @@ struct fsl_e_tlb_entry tlb_table[] = {
   MAS3_SX | MAS3_SW | MAS3_SR, 0,
   0, 0, BOOKE_PAGESZ_4K, 0),
 
+#ifndef CONFIG_TQM_BIGFLASH
/*
 * TLB 0, 1:128MNon-cacheable, guarded
 * 0xf800   128MFLASH
@@ -146,6 +147,102 @@ struct fsl_e_tlb_entry tlb_table[] = {
   0, 9, BOOKE_PAGESZ_16M, 1),
 #endif /* CONFIG_PCIE */
 
+#else /* CONFIG_TQM_BIGFLASH */
+
+   /*
+* TLB 0,1,2,3:   1GNon-cacheable, guarded
+* 0xc000 1GFLASH
+* Out of reset this entry is only 4K.
+*/
+   SET_TLB_ENTRY (1, CFG_FLASH_BASE, CFG_FLASH_BASE,
+  MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
+  0, 3, BOOKE_PAGESZ_256M, 1),
+   SET_TLB_ENTRY (1, CFG_FLASH_BASE + 0x1000,
+  CFG_FLASH_BASE + 0x1000,
+  MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
+  0, 2, BOOKE_PAGESZ_256M, 1),
+   SET_TLB_ENTRY (1, CFG_FLASH_BASE + 0x2000,
+  CFG_FLASH_BASE + 0x2000,
+  MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
+  0, 1, BOOKE_PAGESZ_256M, 1),
+  

[U-Boot-Users] [PATCH] TQM8548: PCI express support

[Wolfgang Grandegger]

This patch adds support for PCI express cards. The board support
now uses common FSL PCI init code, for both, PCI and PCIe on all
TQM85xx modules.

Signed-off-by: Thomas Waehner <[EMAIL PROTECTED]>
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 board/tqc/tqm85xx/law.c |   15 +++-
 board/tqc/tqm85xx/tlb.c |   30 ++
 board/tqc/tqm85xx/tqm85xx.c |  205 ---
 include/configs/TQM85xx.h   |   35 +++-
 4 files changed, 249 insertions(+), 36 deletions(-)

diff --git a/board/tqc/tqm85xx/law.c b/board/tqc/tqm85xx/law.c
index ad35464..bec1ed5 100644
--- a/board/tqc/tqm85xx/law.c
+++ b/board/tqc/tqm85xx/law.c
@@ -32,11 +32,11 @@
  *
  * 0x_0x7fff_ DDR 2G
  * 0x8000_0x9fff_ PCI1 MEM512M
- * 0xc000_0xdfff_ RapidIO 512M
+ * 0xc000_0xdfff_ RapidIO or PCI express  512M
  * 0xe000_0xe000_ CCSR1M
  * 0xe200_0xe2ff_ PCI1 IO 16M
  * 0xe300_0xe3ff_ CAN 16M
- * 0xf800_0xf80f_ BCSR1M
+ * 0xef00_0xefff_ PCI express IO  16M
  * 0xfe00_0x_ FLASH (boot bank)   32M
  *
  * Notes:
@@ -49,10 +49,17 @@ struct law_entry law_table[] = {
SET_LAW_ENTRY (2, CFG_PCI1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI),
SET_LAW_ENTRY (3, CFG_LBC_FLASH_BASE, LAW_SIZE_128M, LAW_TRGT_IF_LBC),
SET_LAW_ENTRY (4, CFG_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI),
-   SET_LAW_ENTRY (5, CFG_RIO_MEM_BASE, LAWAR_SIZE_512M, LAW_TRGT_IF_RIO),
+#ifdef CONFIG_PCIE1
+   SET_LAW_ENTRY (5, CFG_PCIE1_MEM_BASE, LAW_SIZE_512M, 
LAW_TRGT_IF_PCIE_1),
+#else /* !CONFIG_PCIE1 */
+   SET_LAW_ENTRY (5, CFG_RIO_MEM_BASE, LAW_SIZE_512M, LAW_TRGT_IF_RIO),
+#endif /* CONFIG_PCIE1 */
 #ifdef CONFIG_CAN_DRIVER
-   SET_LAW_ENTRY (6, CFG_CAN_BASE, LAWAR_SIZE_16M, LAW_TRGT_IF_LBC),
+   SET_LAW_ENTRY (6, CFG_CAN_BASE, LAW_SIZE_16M, LAW_TRGT_IF_LBC),
 #endif /* CONFIG_CAN_DRIVER */
+#ifdef CONFIG_PCIE1
+   SET_LAW_ENTRY (7, CFG_PCIE1_IO_BASE, LAW_SIZE_16M, LAW_TRGT_IF_PCIE_1),
+#endif /* CONFIG_PCIE */
 };
 
 int num_law_entries = ARRAY_SIZE (law_table);
diff --git a/board/tqc/tqm85xx/tlb.c b/board/tqc/tqm85xx/tlb.c
index dc36201..7c4b9a1 100644
--- a/board/tqc/tqm85xx/tlb.c
+++ b/board/tqc/tqm85xx/tlb.c
@@ -74,6 +74,24 @@ struct fsl_e_tlb_entry tlb_table[] = {
   MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
   0, 3, BOOKE_PAGESZ_256M, 1),
 
+#ifdef CONFIG_PCIE1
+   /*
+* TLB 4:   256MNon-cacheable, guarded
+* 0xc000   256MPCI express MEM First half
+*/
+   SET_TLB_ENTRY (1, CFG_PCIE1_MEM_BASE, CFG_PCIE1_MEM_BASE,
+  MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
+  0, 4, BOOKE_PAGESZ_256M, 1),
+
+   /*
+* TLB 5:   256MNon-cacheable, guarded
+* 0xd000   256MPCI express MEM Second half
+*/
+   SET_TLB_ENTRY (1, CFG_PCIE1_MEM_BASE + 0x1000,
+  CFG_PCIE1_MEM_BASE + 0x1000,
+  MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
+  0, 5, BOOKE_PAGESZ_256M, 1),
+#else /* !CONFIG_PCIE */
/*
 * TLB 4:   256MNon-cacheable, guarded
 * 0xc000   256MRapid IO MEM First half
@@ -90,6 +108,7 @@ struct fsl_e_tlb_entry tlb_table[] = {
   CFG_RIO_MEM_BASE + 0x1000,
   MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
   0, 5, BOOKE_PAGESZ_256M, 1),
+#endif /* CONFIG_PCIE */
 
/*
 * TLB 6:64MNon-cacheable, guarded
@@ -116,6 +135,17 @@ struct fsl_e_tlb_entry tlb_table[] = {
   CFG_DDR_SDRAM_BASE + 0x1000,
   MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
   0, 8, BOOKE_PAGESZ_256M, 1),
+
+#ifdef CONFIG_PCIE1
+   /*
+* TLB 9:16MNon-cacheable, guarded
+* 0xef0016MPCI express IO
+*/
+   SET_TLB_ENTRY (1, CFG_PCIE1_IO_BASE, CFG_PCIE1_IO_BASE,
+  MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
+  0, 9, BOOKE_PAGESZ_16M, 1),
+#endif /* CONFIG_PCIE */
+
 };
 
 int num_tlb_entries = ARRAY_SIZE (tlb_table);
diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c
index 4d06599..6459b7a 100644
--- a/board/tqc/tqm85xx/tqm85xx.c
+++ b/board/tqc/tqm85xx/tqm85xx.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -257,13 +258,6 @@ int checkboard (void)
}
putc ('\n');
 
-#ifdef CONFIG_PCI
-   printf ("PCI1:  32 bit, %d MHz (compiled)\n",
-   CONFIG_SYS_CLK_FREQ / 10

[U-Boot-Users] [PATCH] TQM85xx: NAND support via local bus UPMB

[Wolfgang Grandegger]

This patch adds support for NAND FLASH on the TQM8548. It is disabled by
default and can be enabled for the TQM8548 modules. Note that the R/B pin
is not supported by that module requiring to use the specified maximum
delay time.

Note: With NAND support enabled the size of the U-Boot image exceeds
256 KB and TEXT_BASE must therefore be set to 0xfff8 in config.mk,
doubling the image size :-(.

Signed-off-by: Thomas Waehner <[EMAIL PROTECTED]>
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 board/tqc/tqm85xx/Makefile |8 +-
 board/tqc/tqm85xx/law.c|6 +-
 board/tqc/tqm85xx/nand.c   |  597 
 board/tqc/tqm85xx/tlb.c|2 +-
 include/configs/TQM85xx.h  |   80 ++-
 include/mpc85xx.h  |4 +
 6 files changed, 689 insertions(+), 8 deletions(-)
 create mode 100644 board/tqc/tqm85xx/nand.c

diff --git a/board/tqc/tqm85xx/Makefile b/board/tqc/tqm85xx/Makefile
index 52f5ef9..8ea07f2 100644
--- a/board/tqc/tqm85xx/Makefile
+++ b/board/tqc/tqm85xx/Makefile
@@ -25,8 +25,14 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(BOARD).a
 
-COBJS  := $(BOARD).o sdram.o law.o tlb.o
+COBJS-y+= $(BOARD).o
+COBJS-y+= sdram.o
+COBJS-y+= law.o
+COBJS-y+= tlb.o
 
+COBJS-$(CONFIG_NAND) += nand.o
+
+COBJS  := $(COBJS-y)
 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS))
 SOBJS  := $(addprefix $(obj),$(SOBJS))
diff --git a/board/tqc/tqm85xx/law.c b/board/tqc/tqm85xx/law.c
index bec1ed5..914ce68 100644
--- a/board/tqc/tqm85xx/law.c
+++ b/board/tqc/tqm85xx/law.c
@@ -35,7 +35,7 @@
  * 0xc000_0xdfff_ RapidIO or PCI express  512M
  * 0xe000_0xe000_ CCSR1M
  * 0xe200_0xe2ff_ PCI1 IO 16M
- * 0xe300_0xe3ff_ CAN 16M
+ * 0xe300_0xe3ff_ CAN and NAND Flash  16M
  * 0xef00_0xefff_ PCI express IO  16M
  * 0xfe00_0x_ FLASH (boot bank)   32M
  *
@@ -54,9 +54,9 @@ struct law_entry law_table[] = {
 #else /* !CONFIG_PCIE1 */
SET_LAW_ENTRY (5, CFG_RIO_MEM_BASE, LAW_SIZE_512M, LAW_TRGT_IF_RIO),
 #endif /* CONFIG_PCIE1 */
-#ifdef CONFIG_CAN_DRIVER
+#if defined(CONFIG_CAN_DRIVER) || defined(CONFIG_NAND)
SET_LAW_ENTRY (6, CFG_CAN_BASE, LAW_SIZE_16M, LAW_TRGT_IF_LBC),
-#endif /* CONFIG_CAN_DRIVER */
+#endif /* CONFIG_CAN_DRIVER || CONFIG_NAND */
 #ifdef CONFIG_PCIE1
SET_LAW_ENTRY (7, CFG_PCIE1_IO_BASE, LAW_SIZE_16M, LAW_TRGT_IF_PCIE_1),
 #endif /* CONFIG_PCIE */
diff --git a/board/tqc/tqm85xx/nand.c b/board/tqc/tqm85xx/nand.c
new file mode 100644
index 000..4ae8475
--- /dev/null
+++ b/board/tqc/tqm85xx/nand.c
@@ -0,0 +1,597 @@
+/*
+ * (C) Copyright 2008 Wolfgang Grandegger <[EMAIL PROTECTED]>
+ *
+ * (C) Copyright 2006
+ * Thomas Waehner, TQ-System GmbH, [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+extern uint get_lbc_clock (void);
+
+/* index of UPM RAM array run pattern for NAND command cycle */
+#defineCFG_NAND_UPM_WRITE_CMD_OFS  0x08
+
+/* index of UPM RAM array run pattern for NAND address cycle */
+#defineCFG_NAND_UPM_WRITE_ADDR_OFS 0x10
+
+/* Structure for table with supported UPM timings */
+struct upm_freq {
+   ulong freq;
+   const ulong *upm_patt;
+   uchar gpl4_disable;
+   uchar ehtr;
+   uchar ead;
+};
+
+/* NAND-FLASH UPM tables for TQM85XX according to TQM8548.pq.timing.101.doc */
+
+/* UPM pattern for bus clock = 25 MHz */
+static const ulong upm_patt_25[] = {
+   /* Offset *//* UPM Read Single RAM array entry -> NAND Read Data */
+   /* 0x00 */ 0x0ff32000, 0x0fa32000, 0x3fb32005, 0xfc00,
+   /* 0x04 */ 0xfc00, 0xfc00, 0xfc00, 0xfc00,
+
+   /* UPM Read Burst RAM array entry -> NAND Write CMD */
+   /* 0x08 */ 0x00ff2c30, 0x00ff2c30, 0x0fff2c35, 0xfc00,
+   /* 0x0C */ 0xfc00, 0xfc00, 0xfc00, 0xfc00,
+
+   /* UPM Read Burst RAM a

[U-Boot-Users] [PATCH] TQM85xx: Support for Flat Device Tree

[Wolfgang Grandegger]

This patch adds support for Linux kernels using the Flat Device Tree.
It also re-defines the default environment settings for booting Linux
with the FDT blob.

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 Makefile|3 +-
 board/tqc/tqm85xx/tqm85xx.c |   24 
 include/configs/TQM85xx.h   |   50 +-
 3 files changed, 64 insertions(+), 13 deletions(-)

diff --git a/Makefile b/Makefile
index 7d05d62..32c9643 100644
--- a/Makefile
+++ b/Makefile
@@ -2233,8 +2233,7 @@ TQM8560_config:   unconfig
echo "#define CONFIG_MPC$${CTYPE}">>$(obj)include/config.h; \
echo "#define CONFIG_TQM$${CTYPE}">>$(obj)include/config.h; \
echo "#define CONFIG_HOSTNAME tqm$${CTYPE}">>$(obj)include/config.h; \
-   echo "#define CONFIG_BOARDNAME 
\"TQM$${CTYPE}\"">>$(obj)include/config.h; \
-   echo "#define CFG_BOOTFILE_PATH 
\"/tftpboot/tqm$${CTYPE}/uImage\"">>$(obj)include/config.h
+   echo "#define CONFIG_BOARDNAME 
\"TQM$${CTYPE}\"">>$(obj)include/config.h;
@$(MKCONFIG) -a TQM85xx ppc mpc85xx tqm85xx tqc
 
 #
diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c
index bca59a3..8690fb1 100644
--- a/board/tqc/tqm85xx/tqm85xx.c
+++ b/board/tqc/tqm85xx/tqm85xx.c
@@ -34,6 +34,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -481,6 +483,28 @@ void pci_init_board (void)
 #endif /* CONFIG_PCI */
 }
 
+#if defined(CONFIG_OF_BOARD_SETUP)
+void ft_board_setup (void *blob, bd_t *bd)
+{
+   int node, tmp[2];
+   const char *path;
+
+   ft_cpu_setup (blob, bd);
+
+   node = fdt_path_offset (blob, "/aliases");
+   tmp[0] = 0;
+   if (node >= 0) {
+#ifdef CONFIG_PCI
+   path = fdt_getprop (blob, node, "pci0", NULL);
+   if (path) {
+   tmp[1] = hose.last_busno - hose.first_busno;
+   do_fixup_by_path (blob, path, "bus-range", &tmp, 8, 1);
+   }
+#endif
+   }
+}
+#endif
+
 #ifdef CONFIG_BOARD_EARLY_INIT_R
 int board_early_init_r (void)
 {
diff --git a/include/configs/TQM85xx.h b/include/configs/TQM85xx.h
index 9eec858..ef89ba4 100644
--- a/include/configs/TQM85xx.h
+++ b/include/configs/TQM85xx.h
@@ -201,6 +201,11 @@
 #defineCFG_PROMPT_HUSH_PS2 "> "
 #endif
 
+/* pass open firmware flat tree */
+#define CONFIG_OF_LIBFDT   1
+#define CONFIG_OF_BOARD_SETUP  1
+#define CONFIG_OF_STDOUT_VIA_ALIAS 1
+
 /* CAN */
 #ifdef CONFIG_CAN_DRIVER
 #define CFG_CAN_BASE   0xE300  /* CAN base address */
@@ -463,10 +468,26 @@
 
 #undef CONFIG_BOOTARGS /* the boot command will set bootargs   */
 
+
+/*
+ * Setup some board specific values for the default environment variables
+ */
+#ifdef CONFIG_CPM2
+#define CFG_ENV_CONSDEV"consdev=ttyCPM0\0"
+#else
+#define CFG_ENV_CONSDEV"consdev=ttyS0\0"
+#endif
+#define CFG_ENV_FDT_FILE   "fdt_file="MK_STR(CONFIG_HOSTNAME)"/" \
+   MK_STR(CONFIG_HOSTNAME)".dtb\0"
+#define CFG_ENV_BOOTFILE   "bootfile="MK_STR(CONFIG_HOSTNAME)"/uImage\0"
+#define CFG_ENV_UBOOT  "uboot="MK_STR(CONFIG_HOSTNAME)"/u-boot.bin\0" \
+   "uboot_addr="MK_STR(TEXT_BASE)"\0"
+
 #defineCONFIG_EXTRA_ENV_SETTINGS   
\
-   "bootfile="CFG_BOOTFILE_PATH"\0"\
+   CFG_ENV_BOOTFILE\
+   CFG_ENV_FDT_FILE\
+   CFG_ENV_CONSDEV \
"netdev=eth0\0" \
-   "consdev=ttyS0\0"   \
"nfsargs=setenv bootargs root=/dev/nfs rw " \
"nfsroot=$serverip:$rootpath\0" \
"ramargs=setenv bootargs root=/dev/ram rw\0"\
@@ -476,17 +497,24 @@
"addcons=setenv bootargs $bootargs "\
"console=$consdev,$baudrate\0"  \
"flash_nfs=run nfsargs addip addcons;"  \
-   "bootm $kernel_addr\0"  \
+   "bootm $kernel_addr - $fdt_addr\0"  \

[U-Boot-Users] [PATCH] TQM85xx: Support for Intel 82527 compatible CAN controller

[Wolfgang Grandegger]

This patch adds initialization of the UPMC RAM to support up to two
Intel 82527 compatible CAN controller on the TQM85xx modules.

Signed-off-by: Thomas Waehner <[EMAIL PROTECTED]>
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 board/tqc/tqm85xx/law.c |4 +++
 board/tqc/tqm85xx/tlb.c |1 +
 board/tqc/tqm85xx/tqm85xx.c |   59 +++
 include/configs/TQM85xx.h   |   11 
 include/mpc85xx.h   |5 +++
 5 files changed, 80 insertions(+), 0 deletions(-)

diff --git a/board/tqc/tqm85xx/law.c b/board/tqc/tqm85xx/law.c
index d937700..ad35464 100644
--- a/board/tqc/tqm85xx/law.c
+++ b/board/tqc/tqm85xx/law.c
@@ -35,6 +35,7 @@
  * 0xc000_0xdfff_ RapidIO 512M
  * 0xe000_0xe000_ CCSR1M
  * 0xe200_0xe2ff_ PCI1 IO 16M
+ * 0xe300_0xe3ff_ CAN 16M
  * 0xf800_0xf80f_ BCSR1M
  * 0xfe00_0x_ FLASH (boot bank)   32M
  *
@@ -49,6 +50,9 @@ struct law_entry law_table[] = {
SET_LAW_ENTRY (3, CFG_LBC_FLASH_BASE, LAW_SIZE_128M, LAW_TRGT_IF_LBC),
SET_LAW_ENTRY (4, CFG_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI),
SET_LAW_ENTRY (5, CFG_RIO_MEM_BASE, LAWAR_SIZE_512M, LAW_TRGT_IF_RIO),
+#ifdef CONFIG_CAN_DRIVER
+   SET_LAW_ENTRY (6, CFG_CAN_BASE, LAWAR_SIZE_16M, LAW_TRGT_IF_LBC),
+#endif /* CONFIG_CAN_DRIVER */
 };
 
 int num_law_entries = ARRAY_SIZE (law_table);
diff --git a/board/tqc/tqm85xx/tlb.c b/board/tqc/tqm85xx/tlb.c
index 3e29062..dc36201 100644
--- a/board/tqc/tqm85xx/tlb.c
+++ b/board/tqc/tqm85xx/tlb.c
@@ -95,6 +95,7 @@ struct fsl_e_tlb_entry tlb_table[] = {
 * TLB 6:64MNon-cacheable, guarded
 * 0xe000 1MCCSRBAR
 * 0xe20016MPCI1 IO
+* 0xe30016MCAN
 */
SET_TLB_ENTRY (1, CFG_CCSRBAR, CFG_CCSRBAR_PHYS,
   MAS3_SX | MAS3_SW | MAS3_SR, MAS2_I | MAS2_G,
diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c
index f38b009..bca59a3 100644
--- a/board/tqc/tqm85xx/tqm85xx.c
+++ b/board/tqc/tqm85xx/tqm85xx.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -333,6 +334,28 @@ int misc_init_r (void)
return 0;
 }
 
+#ifdef CONFIG_CAN_DRIVER
+/*
+ * Initialize UPMC RAM
+ */
+static void upmc_write (u_char addr, uint val)
+{
+   volatile ccsr_lbc_t *lbc = (void *)(CFG_MPC85xx_LBC_ADDR);
+
+   out_be32 (&lbc->mdr, val);
+
+   out_be32 (&lbc->mcmr,
+ (in_be32 (&lbc->mcmr) & ~(MxMR_OP_NORM | MxMR_MAD)) |
+ MxMR_OP_WARR | (addr & MxMR_MAD));
+   /* dummy access to perform write */
+   out_8 ((void __iomem *)CFG_CAN_BASE, 0);
+
+   /* normal operation */
+   out_be32 (&lbc->mcmr,
+ (in_be32 (&lbc->mcmr) & ~MxMR_OP_WARR) | MxMR_OP_NORM);
+}
+#endif /* CONFIG_CAN_DRIVER */
+
 /*
  * Initialize Local Bus
  */
@@ -389,6 +412,42 @@ void local_bus_init (void)
gur->lbcdllcr = (((temp_lbcdll & 0xff) << 16) | 0x8000);
asm ("sync;isync;msync");
}
+
+#ifdef CONFIG_CAN_DRIVER
+   /* Initialize OR2 / BR2 */
+   lbc->or2 = CFG_OR2_CAN;
+   lbc->br2 = CFG_BR2_CAN;
+
+   /*
+* According to timing specifications EAD must be
+* set if Local Bus Clock is > 83 MHz.
+*/
+   if (lbc_hz > 83)
+   lbc->or2 |= ORxU_EAD;
+
+   /* LGPL4 is UPWAIT */
+   out_be32(&lbc->mcmr, MxMR_DSx_3_CYCL | MxMR_GPL4_DIS | MxMR_WLFx_3X);
+
+   /* Initialize UPMC for CAN: single read */
+   upmc_write (0x00, 0xED00);
+   upmc_write (0x01, 0xCCFFCC00);
+   upmc_write (0x02, 0x00FFCF00);
+   upmc_write (0x03, 0x00FFCF00);
+   upmc_write (0x04, 0x00FFDC00);
+   upmc_write (0x05, 0x00FFCF00);
+   upmc_write (0x06, 0x00FFED00);
+   upmc_write (0x07, 0x3FFFCC07);
+
+   /* Initialize UPMC for CAN: single write */
+   upmc_write (0x18, 0xED00);
+   upmc_write (0x19, 0xCCFFEC00);
+   upmc_write (0x1A, 0x00FFED80);
+   upmc_write (0x1B, 0x00FFED80);
+   upmc_write (0x1C, 0x00FFFC00);
+   upmc_write (0x1D, 0x0FFFEC00);
+   upmc_write (0x1E, 0x0FFFEF00);
+   upmc_write (0x1F, 0x3FFFEC05);
+#endif /* CONFIG_CAN_DRIVER */
 }
 
 #if defined(CONFIG_PCI)
diff --git a/include/configs/TQM85xx.h b/include/configs/TQM85xx.h
index 4011b2a..9eec858 100644
--- a/include/configs/TQM85xx.h
+++ b/include/configs/TQM85xx.h
@@ -52,6 +52,8 @@
 
 #define CONFIG_FSL_LAW 1   /* Use common FSL init code */
 
+#undef CONFIG_CAN_DRIVER   /* CAN Driver support   */
+
 /*
  * sysclk for MPC85xx
  *
@@ -199,6 +201,15 @@
 #defineCFG_PROMPT_HUS

[U-Boot-Users] [PATCH] TQM8548: Basic support for the TQM8548 modules

[Wolfgang Grandegger]

This patch adds basic support for the TQM8548 module from TQ-Components
(http://www.tqc.de/) including DDR2 SDRAM initialisation and support for
eTSEC 3 and 4

Furthermore Flash buffer write has been enabled to speed up output to
the Flash by approx. a factor of 10.

Signed-off-by: Thomas Waehner <[EMAIL PROTECTED]>
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 MAKEALL |1 +
 Makefile|1 +
 board/tqc/tqm85xx/sdram.c   |  150 ++-
 board/tqc/tqm85xx/tqm85xx.c |  113 
 drivers/input/ps2ser.c  |   31 ++---
 include/configs/TQM85xx.h   |   71 ++--
 include/mpc85xx.h   |9 +++
 7 files changed, 343 insertions(+), 33 deletions(-)

diff --git a/MAKEALL b/MAKEALL
index 0674069..ec20e62 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -359,6 +359,7 @@ LIST_85xx=" \
stxssa  \
TQM8540 \
TQM8541 \
+   TQM8548 \
TQM8555 \
TQM8560 \
 "
diff --git a/Makefile b/Makefile
index 32c9643..3cca59c 100644
--- a/Makefile
+++ b/Makefile
@@ -2225,6 +2225,7 @@ stxssa_4M_config: unconfig
 
 TQM8540_config \
 TQM8541_config \
+TQM8548_config \
 TQM8555_config \
 TQM8560_config:unconfig
@mkdir -p $(obj)include
diff --git a/board/tqc/tqm85xx/sdram.c b/board/tqc/tqm85xx/sdram.c
index e005d84..442ff66 100644
--- a/board/tqc/tqm85xx/sdram.c
+++ b/board/tqc/tqm85xx/sdram.c
@@ -30,16 +30,27 @@
 struct sdram_conf_s {
unsigned long size;
unsigned long reg;
+#ifdef CONFIG_TQM8548
+   unsigned long refresh;
+#endif /* CONFIG_TQM8548 */
 };
 
 typedef struct sdram_conf_s sdram_conf_t;
 
+#ifdef CONFIG_TQM8548
+sdram_conf_t ddr_cs_conf[] = {
+   {(512 << 20), 0x80044102, 0x0001A000},  /* 512MB, 13x10(4)  */
+   {(256 << 20), 0x80040102, 0x00014000},  /* 256MB, 13x10(4)  */
+   {(128 << 20), 0x80040101, 0xC000},  /* 128MB, 13x9(4)   */
+};
+#else /* !CONFIG_TQM8548 */
 sdram_conf_t ddr_cs_conf[] = {
{(512 << 20), 0x8202},  /* 512MB, 14x10(4)  */
{(256 << 20), 0x8102},  /* 256MB, 13x10(4)  */
{(128 << 20), 0x8101},  /* 128MB, 13x9(4)   */
{( 64 << 20), 0x8001},  /*  64MB, 12x9(4)   */
 };
+#endif /* CONFIG_TQM8548 */
 
 #defineN_DDR_CS_CONF (sizeof(ddr_cs_conf) / sizeof(ddr_cs_conf[0]))
 
@@ -56,8 +67,12 @@ long int sdram_setup (int casl)
 {
int i;
volatile ccsr_ddr_t *ddr = (void *)(CFG_MPC85xx_DDR_ADDR);
+#ifdef CONFIG_TQM8548
+   volatile ccsr_gur_t *gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
+#else /* !CONFIG_TQM8548 */
unsigned long cfg_ddr_timing1;
unsigned long cfg_ddr_mode;
+#endif /* CONFIG_TQM8548 */
 
/*
 * Disable memory controller.
@@ -65,6 +80,122 @@ long int sdram_setup (int casl)
ddr->cs0_config = 0;
ddr->sdram_cfg = 0;
 
+#ifdef CONFIG_TQM8548
+   ddr->cs0_bnds = (ddr_cs_conf[0].size - 1) >> 24;
+   ddr->cs0_config = ddr_cs_conf[0].reg;
+   ddr->timing_cfg_3 = 0x0001;
+
+   /* TIMING CFG 1, 533MHz
+* PRETOACT: 4 Clocks
+* ACTTOPRE: 12 Clocks
+* ACTTORW:  4 Clocks
+* CASLAT:   4 Clocks
+* REFREC:   34 Clocks
+* WRREC:4 Clocks
+* ACTTOACT: 3 Clocks
+* WRTORD:   2 Clocks
+*/
+   ddr->timing_cfg_1 = 0x4C47A432;
+
+   /* TIMING CFG 2, 533MHz
+* ADD_LAT:   3 Clocks
+* CPO:   READLAT + 1
+* WR_LAT:3 Clocks
+* RD_TO_PRE: 2 Clocks
+* WR_DATA_DELAY: 1/2 Clock
+* CKE_PLS:   1 Clock
+* FOUR_ACT:  13 Clocks
+*/
+   ddr->timing_cfg_2 = 0x3318484D;
+
+   /* DDR SDRAM Mode, 533MHz
+* MRS:  Extended Mode Register
+* OUT:  Outputs enabled
+* RDQS: no
+* DQS:  enabled
+* OCD:  default state
+* RTT:  75 Ohms
+* Posted CAS:   3 Clocks
+* ODS:  reduced strength
+* DLL:  enabled
+* MR:   Mode Register
+* PD:   fast exit
+* WR:   4 Clocks
+* DLL:  no DLL reset
+* TM:   normal
+* CAS latency:  4 Clocks
+* BT:   sequential
+* Burst length: 4
+*/
+   ddr->sdram_mode = 0x439E0642;
+
+   /* DDR SDRAM Interval, 533MHz
+* REFINT:  1040 Clocks
+* BSTOPRE: 256
+*/
+   ddr->sdram_interval = (1040 << 16) | 0x100;
+
+   /*
+* workaround for erratum DD10 of MPC8458 family below rev. 2.0:
+* DDR IO receiver must be set to an acceptable bi

[U-Boot-Users] [PATCH] TQM85xx: Bugfix in the SDRAM initialisation

[Wolfgang Grandegger]

The CS0_BNDS register is now set according to the detected
memory size.

Signed-off-by Martin Krause <[EMAIL PROTECTED]>
---
 board/tqc/tqm85xx/sdram.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/board/tqc/tqm85xx/sdram.c b/board/tqc/tqm85xx/sdram.c
index 413567e..e005d84 100644
--- a/board/tqc/tqm85xx/sdram.c
+++ b/board/tqc/tqm85xx/sdram.c
@@ -104,8 +104,10 @@ long int sdram_setup (int casl)
if (get_ram_size (0, ddr_cs_conf[i].size) ==
ddr_cs_conf[i].size) {
/*
-* OK, size detected -> all done
+* size detected -> set Chip Select Bounds Register
 */
+   ddr->cs0_bnds = (ddr_cs_conf[i].size - 1) >> 24;
+
return ddr_cs_conf[i].size;
}
}
-- 
1.5.2.2


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] TQM85xx: Fix chip select configuration for second FLASH bank

[Wolfgang Grandegger]

This patch fixes the re-calculation of the automatic chip select
configuration for boards with two populated FLASH banks.

Signed-off-by: Martin Krause <[EMAIL PROTECTED]>
---
 board/tqc/tqm85xx/tqm85xx.c |   86 +++---
 1 files changed, 47 insertions(+), 39 deletions(-)

diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c
index af8c170..f38b009 100644
--- a/board/tqc/tqm85xx/tqm85xx.c
+++ b/board/tqc/tqm85xx/tqm85xx.c
@@ -274,53 +274,61 @@ int misc_init_r (void)
gd->bd->bi_flashstart = 0 - gd->bd->bi_flashsize;
gd->bd->bi_flashoffset = 0;
 
-   /*
-* Check if boot FLASH isn't max size
+   /*
+* Recalculate CS configuration if second FLASH bank is available
 */
-   if (gd->bd->bi_flashsize < (0 - CFG_FLASH0)) {
-   memctl->or0 =
-   gd->bd->bi_flashstart | (CFG_OR0_PRELIM & 0x7fff);
-   memctl->br0 =
-   gd->bd->bi_flashstart | (CFG_BR0_PRELIM & 0x7fff);
-
+   if (flash_info[0].size > 0) {
+   memctl->or1 = ((-flash_info[0].size) & 0x8000) |
+   (CFG_OR1_PRELIM & 0x7fff);
+   memctl->br1 = gd->bd->bi_flashstart |
+   (CFG_BR1_PRELIM & 0x7fff);
/*
-* Re-check to get correct base address
+* Re-check to get correct base address for bank 1
 */
-   flash_get_size (gd->bd->bi_flashstart, CFG_MAX_FLASH_BANKS - 1);
+   flash_get_size (gd->bd->bi_flashstart, 0);
+   } else {
+   memctl->or1 = 0;
+   memctl->br1 = 0;
}
 
/*
-* Check if only one FLASH bank is available
+*  If bank 1 is equipped, bank 0 is mapped after bank 1
 */
-   if (gd->bd->bi_flashsize != CFG_MAX_FLASH_BANKS * (0 - CFG_FLASH0)) {
-   memctl->or1 = 0;
-   memctl->br1 = 0;
+   memctl->or0 = ((-flash_info[1].size) & 0x8000) |
+   (CFG_OR0_PRELIM & 0x7fff);
+   memctl->br0 = (gd->bd->bi_flashstart + flash_info[0].size) |
+   (CFG_BR0_PRELIM & 0x7fff);
+   /*
+* Re-check to get correct base address for bank 0
+*/
+   flash_get_size (gd->bd->bi_flashstart + flash_info[0].size, 1);
 
-   /*
-* Re-do flash protection upon new addresses
-*/
-   flash_protect (FLAG_PROTECT_CLEAR,
-  gd->bd->bi_flashstart, 0x,
-  &flash_info[CFG_MAX_FLASH_BANKS - 1]);
-
-   /* Monitor protection ON by default */
-   flash_protect (FLAG_PROTECT_SET,
-  CFG_MONITOR_BASE,
-  CFG_MONITOR_BASE + monitor_flash_len - 1,
-  &flash_info[CFG_MAX_FLASH_BANKS - 1]);
-
-   /* Environment protection ON by default */
-   flash_protect (FLAG_PROTECT_SET,
-  CFG_ENV_ADDR,
-  CFG_ENV_ADDR + CFG_ENV_SECT_SIZE - 1,
-  &flash_info[CFG_MAX_FLASH_BANKS - 1]);
-
-   /* Redundant environment protection ON by default */
-   flash_protect (FLAG_PROTECT_SET,
-  CFG_ENV_ADDR_REDUND,
-  CFG_ENV_ADDR_REDUND + CFG_ENV_SIZE_REDUND - 1,
-  &flash_info[CFG_MAX_FLASH_BANKS - 1]);
-   }
+   /*
+* Re-do flash protection upon new addresses
+*/
+   flash_protect (FLAG_PROTECT_CLEAR,
+  gd->bd->bi_flashstart, 0x,
+  &flash_info[CFG_MAX_FLASH_BANKS - 1]);
+
+   /* Monitor protection ON by default */
+   flash_protect (FLAG_PROTECT_SET,
+  CFG_MONITOR_BASE,
+  CFG_MONITOR_BASE + monitor_flash_len - 1,
+  &flash_info[CFG_MAX_FLASH_BANKS - 1]);
+
+   /* Environment protection ON by default */
+   flash_protect (FLAG_PROTECT_SET,
+  CFG_ENV_ADDR,
+  CFG_ENV_ADDR + CFG_ENV_SECT_SIZE - 1,
+  &flash_info[CFG_MAX_FLASH_BANKS - 1]);
+
+#ifdef CFG_ENV_ADDR_REDUND
+   /* Redundant environment protection ON by default */
+   flash_protect (FLAG_PROTECT_SET,
+  CFG_ENV_ADDR_REDUND,
+  CFG_ENV_ADDR_REDUND + CFG_ENV_SIZE_REDUND - 1,
+  &flash_info[CFG_MAX_FLASH_BANKS - 1]);
+#endif
 
return 0;
 }
-- 
1.5.2.2


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-User

[U-Boot-Users] [PATCH] TQM85xx: Support for Spansion 'N' type flashes added

[Wolfgang Grandegger]

The 'N' type Spansion flashes (S29GLxxxM series) have bigger sectors,
than the formerly used 'M' types (S29GLxxxM series), so the flash layout
needs to be changed -> new start address of the environment. The macro
definition CONFIG_TQM_FLASH_N_TYPE is undefined by default and must be
defined for boards with 'N' type flashes.

Signed-off-by: Martin Krause <[EMAIL PROTECTED]>
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 include/configs/TQM85xx.h |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/include/configs/TQM85xx.h b/include/configs/TQM85xx.h
index f0e7318..4011b2a 100644
--- a/include/configs/TQM85xx.h
+++ b/include/configs/TQM85xx.h
@@ -109,6 +109,13 @@
 #endif /* CONFIG_TQM8541 || CONFIG_TQM8555 */
 
 /*
+ * Old TQM85xx boards have 'M' type Spansion Flashes from the S29GLxxxM
+ * series while new boards have 'N' type Flashes from the S29GLxxxN
+ * series, which have bigger sectors: 128 instead of 256 KB.
+ */
+#undef CONFIG_TQM_FLASH_N_TYPE
+
+/*
  * Flash on the Local Bus
  */
 #define CFG_FLASH0 0xFC00
@@ -151,7 +158,7 @@
 #define CFG_INIT_SP_OFFSET CFG_GBL_DATA_OFFSET
 
 #define CFG_MONITOR_LEN(256 * 1024)/* Reserve 256kB for 
Mon */
-#define CFG_MALLOC_LEN (128 * 1024)/* Reserved for malloc  */
+#define CFG_MALLOC_LEN (256 * 1024)/* Reserved for malloc  */
 
 /* Serial Port */
 #if defined(CONFIG_TQM8560)
@@ -351,10 +358,15 @@
  * Environment
  */
 #define CFG_ENV_IS_IN_FLASH1
-#define CFG_ENV_ADDR   (CFG_MONITOR_BASE - 0x2)
-#define CFG_ENV_SECT_SIZE  0x2 /* 128K(one sector) for env */
+
+#ifdef CONFIG_TQM_FLASH_N_TYPE
+#define CFG_ENV_SECT_SIZE  0x4 /* 256K (one sector) for env*/
+#else /* !CONFIG_TQM_FLASH_N_TYPE */
+#define CFG_ENV_SECT_SIZE  0x2 /* 128K (one sector) for env*/
+#endif /* CONFIG_TQM_FLASH_N_TYPE */
+#define CFG_ENV_ADDR   (CFG_MONITOR_BASE - CFG_ENV_SECT_SIZE)
 #define CFG_ENV_SIZE   0x2000
-#define CFG_ENV_ADDR_REDUND(CFG_ENV_ADDR-CFG_ENV_SECT_SIZE)
+#define CFG_ENV_ADDR_REDUND(CFG_ENV_ADDR - CFG_ENV_SECT_SIZE)
 #define CFG_ENV_SIZE_REDUND(CFG_ENV_SIZE)
 
 #define CONFIG_LOADS_ECHO  1   /* echo on for serial download  */
-- 
1.5.2.2


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] TQM85xx: Fix CPM port pin configuration

[Wolfgang Grandegger]

Do not configure port pins PD30/PD31 as SCC1 TxD/RxD except for the TQM8560
board. On the other TQM85xx boards (TQM8541 and TQM8555) SCC1 is not used
as serial interface anyway. Worse, on some board variants configuring the
pins for SCC1 leads to short circuits (for example on the TQM8541-BG).

Signed-off-by: Martin Krause <[EMAIL PROTECTED]>
---
 board/tqc/tqm85xx/tqm85xx.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c
index 31364d3..af8c170 100644
--- a/board/tqc/tqm85xx/tqm85xx.c
+++ b/board/tqc/tqm85xx/tqm85xx.c
@@ -165,9 +165,15 @@ const iop_conf_t iop_conf_tab[4][32] = {
 
/* Port D: conf, ppar, psor, pdir, podr, pdat */
{
+#ifdef CONFIG_TQM8560
 {1, 1, 0, 0, 0, 0},/* PD31: SCC1 EN RxD */
 {1, 1, 1, 1, 0, 0},/* PD30: SCC1 EN TxD */
 {1, 1, 0, 1, 0, 0},/* PD29: SCC1 EN TENA */
+#else /* !CONFIG_TQM8560 */
+{0, 0, 0, 0, 0, 0},/* PD31: PD31 */
+{0, 0, 0, 0, 0, 0},/* PD30: PD30 */
+{0, 0, 0, 0, 0, 0},/* PD29: PD29 */
+#endif /* CONFIG_TQM8560 */
 {1, 1, 0, 0, 0, 0},/* PD28: PD28 */
 {1, 1, 0, 1, 0, 0},/* PD27: PD27 */
 {1, 1, 0, 1, 0, 0},/* PD26: PD26 */
-- 
1.5.2.2


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] TQM85xx: Various coding style fixes

[Wolfgang Grandegger]

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 board/tqc/tqm85xx/law.c |   12 +-
 board/tqc/tqm85xx/sdram.c   |   56 
 board/tqc/tqm85xx/tlb.c |   98 +++--
 board/tqc/tqm85xx/tqm85xx.c |  330 +-
 include/configs/TQM85xx.h   |   88 ++--
 5 files changed, 293 insertions(+), 291 deletions(-)

diff --git a/board/tqc/tqm85xx/law.c b/board/tqc/tqm85xx/law.c
index 224af6c..d937700 100644
--- a/board/tqc/tqm85xx/law.c
+++ b/board/tqc/tqm85xx/law.c
@@ -44,11 +44,11 @@
  */
 
 struct law_entry law_table[] = {
-   SET_LAW_ENTRY(1, CFG_DDR_SDRAM_BASE, LAW_SIZE_512M, LAW_TRGT_IF_DDR),
-   SET_LAW_ENTRY(2, CFG_PCI1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI),
-   SET_LAW_ENTRY(3, CFG_LBC_FLASH_BASE, LAW_SIZE_128M, LAW_TRGT_IF_LBC),
-   SET_LAW_ENTRY(4, CFG_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI),
-   SET_LAW_ENTRY(5, CFG_RIO_MEM_BASE, LAWAR_SIZE_512M, LAW_TRGT_IF_RIO),
+   SET_LAW_ENTRY (1, CFG_DDR_SDRAM_BASE, LAW_SIZE_512M, LAW_TRGT_IF_DDR),
+   SET_LAW_ENTRY (2, CFG_PCI1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI),
+   SET_LAW_ENTRY (3, CFG_LBC_FLASH_BASE, LAW_SIZE_128M, LAW_TRGT_IF_LBC),
+   SET_LAW_ENTRY (4, CFG_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI),
+   SET_LAW_ENTRY (5, CFG_RIO_MEM_BASE, LAWAR_SIZE_512M, LAW_TRGT_IF_RIO),
 };
 
-int num_law_entries = ARRAY_SIZE(law_table);
+int num_law_entries = ARRAY_SIZE (law_table);
diff --git a/board/tqc/tqm85xx/sdram.c b/board/tqc/tqm85xx/sdram.c
index 788a48c..413567e 100644
--- a/board/tqc/tqm85xx/sdram.c
+++ b/board/tqc/tqm85xx/sdram.c
@@ -21,7 +21,6 @@
  * MA 02111-1307 USA
  */
 
-
 #include 
 #include 
 #include 
@@ -39,12 +38,12 @@ sdram_conf_t ddr_cs_conf[] = {
{(512 << 20), 0x8202},  /* 512MB, 14x10(4)  */
{(256 << 20), 0x8102},  /* 256MB, 13x10(4)  */
{(128 << 20), 0x8101},  /* 128MB, 13x9(4)   */
-   {(64  << 20), 0x8001},  /* 64MB,  12x9(4)   */
+   {( 64 << 20), 0x8001},  /*  64MB, 12x9(4)   */
 };
 
 #defineN_DDR_CS_CONF (sizeof(ddr_cs_conf) / sizeof(ddr_cs_conf[0]))
 
-int cas_latency(void);
+int cas_latency (void);
 
 /*
  * Autodetect onboard DDR SDRAM on 85xx platforms
@@ -53,7 +52,7 @@ int cas_latency(void);
  *   so this should be extended for other future boards
  *   using this routine!
  */
-long int sdram_setup(int casl)
+long int sdram_setup (int casl)
 {
int i;
volatile ccsr_ddr_t *ddr = (void *)(CFG_MPC85xx_DDR_ADDR);
@@ -92,17 +91,18 @@ long int sdram_setup(int casl)
ddr->sdram_interval = 0x05160100;   /* autocharge,no open page */
ddr->err_disable = 0x000D;
 
-   asm ("sync;isync;msync");
-   udelay(1000);
+   asm ("sync; isync; msync");
+   udelay (1000);
 
ddr->sdram_cfg = 0xc200;/* unbuffered,no DYN_PWR */
asm ("sync; isync; msync");
-   udelay(1000);
+   udelay (1000);
 
-   for (i=0; ics0_config = ddr_cs_conf[i].reg;
 
-   if (get_ram_size(0, ddr_cs_conf[i].size) == 
ddr_cs_conf[i].size) {
+   if (get_ram_size (0, ddr_cs_conf[i].size) ==
+   ddr_cs_conf[i].size) {
/*
 * OK, size detected -> all done
 */
@@ -110,30 +110,30 @@ long int sdram_setup(int casl)
}
}
 
-   return 0;   /* nothing found !  
*/
+   return 0;   /* nothing found !  */
 }
 
-void board_add_ram_info(int use_default)
+void board_add_ram_info (int use_default)
 {
int casl;
 
if (use_default)
casl = CONFIG_DDR_DEFAULT_CL;
else
-   casl = cas_latency();
+   casl = cas_latency ();
 
-   puts(" (CL=");
+   puts (" (CL=");
switch (casl) {
case 20:
-   puts("2)");
+   puts ("2)");
break;
 
case 25:
-   puts("2.5)");
+   puts ("2.5)");
break;
 
case 30:
-   puts("3)");
+   puts ("3)");
break;
}
 }
@@ -149,7 +149,7 @@ long int initdram (int board_type)
 */
{
volatile ccsr_gur_t *gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
-   int i,x;
+   int i, x;
 
x = 10;
 
@@ -157,32 +157,32 @@ long int initdram (int board_type)
 * Work around to stabilize DDR DLL
 */
gur->ddrdllcr = 0x8100;
-   asm("sync;isync;msync");
+   asm ("sync; isync; msync");
udelay (200);
while (gur->

[U-Boot-Users] [PATCH] MPC85xx: Beatify boot output of L2 cache configuration

[Wolfgang Grandegger]

The boot output is now aligned poperly with other boot output
lines, e.g.:

  FLASH: 128 MB
  L2:512 KB enabled

Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
 cpu/mpc85xx/cpu.c  |2 +-
 cpu/mpc85xx/cpu_init.c |   18 ++
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 9873383..274b486 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -159,7 +159,7 @@ int checkcpu (void)
}
 
 #ifdef CONFIG_CPM2
-   printf("CPM:  %lu Mhz\n", sysinfo.freqSystemBus / 100);
+   printf("CPM:   %lu Mhz\n", sysinfo.freqSystemBus / 100);
 #endif
 
puts("L1:D-cache 32 kB enabled\n   I-cache 32 kB enabled\n");
diff --git a/cpu/mpc85xx/cpu_init.c b/cpu/mpc85xx/cpu_init.c
index e3240b5..0fb36c4 100644
--- a/cpu/mpc85xx/cpu_init.c
+++ b/cpu/mpc85xx/cpu_init.c
@@ -265,6 +265,8 @@ int cpu_init_r(void)
 #endif
 #endif
 
+   puts ("L2:");
+
 #if defined(CONFIG_L2_CACHE)
volatile ccsr_l2cache_t *l2cache = (void *)CFG_MPC85xx_L2_ADDR;
volatile uint cache_ctl;
@@ -281,17 +283,17 @@ int cpu_init_r(void)
case 0x2000:
if (ver == SVR_8548 || ver == SVR_8548_E ||
ver == SVR_8544 || ver == SVR_8568_E) {
-   printf ("L2 cache 512KB:");
+   puts ("512 KB ");
/* set L2E=1, L2I=1, & L2SRAM=0 */
cache_ctl = 0xc000;
} else {
-   printf ("L2 cache 256KB:");
+   puts("256 KB ");
/* set L2E=1, L2I=1, & L2BLKSZ=2 (256 Kbyte) */
cache_ctl = 0xc800;
}
break;
case 0x1000:
-   printf ("L2 cache 256KB:");
+   puts("256 KB ");
if (ver == SVR_8544 || ver == SVR_8544_E) {
cache_ctl = 0xc000; /* set L2E=1, L2I=1, & L2SRAM=0 
*/
}
@@ -299,18 +301,18 @@ int cpu_init_r(void)
case 0x3000:
case 0x:
default:
-   printf ("L2 cache unknown size (0x%08x)\n", cache_ctl);
+   printf(" unknown size (0x%08x)\n", cache_ctl);
return -1;
}
 
if (l2cache->l2ctl & 0x8000) {
-   printf(" already enabled.");
+   puts("already enabled");
l2srbar = l2cache->l2srbar0;
 #ifdef CFG_INIT_L2_ADDR
if (l2cache->l2ctl & 0x0001 && l2srbar >= CFG_FLASH_BASE) {
l2srbar = CFG_INIT_L2_ADDR;
l2cache->l2srbar0 = l2srbar;
-   printf("  Moving to 0x%08x", CFG_INIT_L2_ADDR);
+   printf("moving to 0x%08x", CFG_INIT_L2_ADDR);
}
 #endif /* CFG_INIT_L2_ADDR */
puts("\n");
@@ -318,10 +320,10 @@ int cpu_init_r(void)
asm("msync;isync");
l2cache->l2ctl = cache_ctl; /* invalidate & enable */
asm("msync;isync");
-   printf(" enabled\n");
+   puts("enabled\n");
}
 #else
-   printf("L2 cache: disabled\n");
+   puts("disabled\n");
 #endif
 #ifdef CONFIG_QE
uint qe_base = CFG_IMMR + 0x0008; /* QE immr base */
-- 
1.5.2.2


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH 0/12] 85xx: various fixes for TQM85xx and support for TQM8548

[Wolfgang Grandegger]

This series of patches fixes various issues with TQM85xx modules and adds
support for TQM8548 modules from TQ Components GmbH (http://www.tqc.de).

Note: The patches rely on "[PATCH] TQM: move TQM boards to board/tqc"
  sent a few minutes ago to this list.

Wolfgang.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC 405EP-based board.

[Wolfgang Grandegger]

Hi Stefan,

Stefan Roese wrote:
> Hi Gary,
> 
> Please use only one coding style in one file. So either:
> 
>   func();
> 
> or
> 
>   func ();
> 
> Since this file mostly consists of the func() style I suggest you switch to 
> this one completely.

Do we really have the choice?

Wolfgang.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] PCI express NIC for testing?

[Wolfgang Grandegger]

Hello,

I'm looking for a PCIe card, preferably a NIC, to test PCIe under
U-Boot. I have realized, that the E1000 driver of U-Boot does not have
support for PCIe cards. It actually lags behind the Linux driver a lot
and porting seems to require substantial effort (different SPD EEPROM,
PCIe, etc.). Are there other choices?

TIA.

Wolfgang.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users