[U-Boot-Users] [Patch] JSE SDRAM size probing

[U-Boot-Users] [Patch] JSE SDRAM size probing

[Stephen Williams]

This patch adds to JSE support a probe for various plausible SDRAM
configurations available for the board.

DHANGELOG
Patch by Stephen Williams <steve@icarus.com> 20 January 2006
* Probe main SDRAM size

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jse-sdram-20060120.patch
Type: text/x-patch
Size: 0 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060120/193a73ef/attachment.bin 

[U-Boot-Users] [Patch] JSE SDRAM size probing

[Wolfgang Denk]

In message <43D16CC0.8030904@icarus.com> you wrote:
> 
> This patch adds to JSE support a probe for various plausible SDRAM
> configurations available for the board.
> 
> DHANGELOG
> Patch by Stephen Williams <steve@icarus.com> 20 January 2006
> * Probe main SDRAM size

Patch missing, please resubmit.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Human beings were created by water to transport it uphill.

[U-Boot-Users] Re: [Patch] JSE SDRAM size probing

[Stephen Williams]

Stephen Williams wrote:
> This patch adds to JSE support a probe for various plausible SDRAM
> configurations available for the board.
> 
> DHANGELOG
> Patch by Stephen Williams <steve@icarus.com> 20 January 2006
> * Probe main SDRAM size
> 
> 

OK, this time with a non-nil attachment.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jse-sdram-20060120.patch
Type: text/x-patch
Size: 7420 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060120/1ddf4b29/attachment.bin 

[U-Boot-Users] Re: [Patch] JSE SDRAM size probing

[Wolfgang Denk]

In message <dqrtqm$bcg$1@sea.gmane.org> you wrote:
>
> > This patch adds to JSE support a probe for various plausible SDRAM
> > configurations available for the board.

I know that this is board-specific code, but I tend  to  reject  this
patch  anyway.  Why  don't  you use the existing code to detet memory
sizes or to test memory for errors?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
For every complex problem, there is a solution that is simple,  neat,
and wrong.                                               - Mark Twain

[U-Boot-Users] Re: [Patch] JSE SDRAM size probing

[Stephen Williams]

Wolfgang Denk wrote:
> In message <dqrtqm$bcg$1@sea.gmane.org> you wrote:
>>> This patch adds to JSE support a probe for various plausible SDRAM
>>> configurations available for the board.
> 
> I know that this is board-specific code, but I tend  to  reject  this
> patch  anyway.  Why  don't  you use the existing code to detet memory
> sizes or to test memory for errors?


Uh, because I can't find it? This board doesn't have an SPD bus, if
that is what you mean.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

[U-Boot-Users] Re: [Patch] JSE SDRAM size probing

[Wolfgang Denk]

In message <dqs4i8$srl$1@sea.gmane.org> you wrote:
>
> Uh, because I can't find it? This board doesn't have an SPD bus, if
> that is what you mean.

That's not what I  mean.  I  was  thinking  of  common/memsize.c  and
post/memory.c,  for  example.  Eventually  about  CFG_ALT_MEMTEST  in
common/cmd_mem.c, too.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"It's hard to believe that something which is neither seen  nor  felt
can do so much harm."
"That's true. But an idea can't be seen or felt. And that's what kept
the Troglytes in the mines all these centuries. A mistaken idea."
	-- Vanna and Kirk, "The Cloud Minders", stardate 5819.0

[U-Boot-Users] Re: [Patch] JSE SDRAM size probing

[Stefan Roese]

Hi Steve,

On Saturday 21 January 2006 02:59, Stephen Williams wrote:
> > In message <dqrtqm$bcg$1@sea.gmane.org> you wrote:
> >>> This patch adds to JSE support a probe for various plausible SDRAM
> >>> configurations available for the board.
> >
> > I know that this is board-specific code, but I tend  to  reject  this
> > patch  anyway.  Why  don't  you use the existing code to detet memory
> > sizes or to test memory for errors?
>
> Uh, because I can't find it? This board doesn't have an SPD bus, if
> that is what you mean.

Please take a look at cpu/ppc4xx/sdram.c. It handles right now only the first 
SDRAM bank (405 and DDR on 440) by defining "CONFIG_SDRAM_BANK0" in your 
board config file. This is done with memory size autodetection using the 
functions Wolfgang pointed out.

A few remarks:
- We will add some additional defines in the near future to allow to
  configure further SDRAM parameters like CAS latency. With these setting
  the timing regs (TR1, RTR) will be generated depending on the SDRAM
  clock.
- You would have to enhance the code for multiple SDRAM banks.
- The config table "CFG_SDRAM_TABLE" has to be extended for 256MByte support.

Best regards,
Stefan

[U-Boot-Users] New Boards

[uboot at sundmangroup.com]

Hello Wolfgang,
I would like to have your advice on how to handle Uboot code for 5
in-house boards called MxB1,MxB2,MxB3 and ExB1,ExB2. Common name XxB.

The boards feature the following functionality ;

o IPMI <--> PPC communication channel ( Serial ) Parts of the ATCA
spec is followed. MAC address retrieval is e.g. done through IPMI.

o Dual Boot areas in FLash ( 32M ) with one Exchangeable area and one
Fallback area.

o Log area in flash

o If both FLash areas are empty BOOTP will be used for Booting

o UPM Machine programmed for HDD PIO or DMA access through the PPC processor

o Password protected login at start-up. If a button is pressed by mistake
the board will boot anyway , only a correct password will stop the boot
sequence.

The boards are based on a PPC 8270 with 256M RAM and 32M FLash.
They also have Broadcom 5690&5670/5671 Switch circuits.

Questions;

o Are you keen on taking in a new (Ericsson) board series?

o If so should I port the existing code to the latest Bootloader?

o How do you want the code delivered?


We have ofcourse prepared to ship the Source code to our customers.

Best Regards // Matias Sundman

[U-Boot-Users] New Boards

[Wolfgang Denk]

Dear Matias,

in message <37507.194.237.142.21.1137849385.squirrel@webmail1.unisite.se> you wrote:
>
> I would like to have your advice on how to handle Uboot code for 5
> in-house boards called MxB1,MxB2,MxB3 and ExB1,ExB2. Common name XxB.

General remark: I intend to handle this like all other boards, too.

> o Are you keen on taking in a new (Ericsson) board series?

Yes.

> o If so should I port the existing code to the latest Bootloader?

Yes.

> o How do you want the code delivered?

Ideally you provide a git repository where  I  can  pull  from,  plus
submit   your  patches  here  on  the  list  for  archival  purposes.
alternatively, just posting the patches is OK, too - see  the  README
for Coding Style and Patch Submission rules.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Far back in the mists of ancient time, in the great and glorious days
of the former Galactic Empire, life was wild, rich  and  largely  tax
free.         - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_

[U-Boot-Users] Re: [Patch] JSE SDRAM size probing

[Stephen Williams]

Wolfgang Denk wrote:
> In message <dqs4i8$srl$1@sea.gmane.org> you wrote:
>> Uh, because I can't find it? This board doesn't have an SPD bus, if
>> that is what you mean.
> 
> That's not what I  mean.  I  was  thinking  of  common/memsize.c  and
> post/memory.c,  for  example.  Eventually  about  CFG_ALT_MEMTEST  in
> common/cmd_mem.c, too.

Oh. Well, besides the point that only 8 lines of my function are the
memory size probe (3 writes into memory and 1 read per bank) the
get_ram_size function doesn't address mapping of two banks once the
sizes are detected. That is where most of my effort went.

Also, Stefan Roese points out the cpu/ppc4xx/sdram.c file, but
that only handles 1 bank (and so obviously doesn't do mapping,
which is largely what I worried about) and uses hard coded timings
different from those appropriate for my board.

So I'll stick with my code for now, although  I'll keep a watch on
the changes that Stefan suggests are coming.

Thanks,
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

[U-Boot-Users] Re: [Patch] JSE SDRAM size probing

[Wolfgang Denk]

In message <dqtnno$3c4$1@sea.gmane.org> you wrote:
>
> Oh. Well, besides the point that only 8 lines of my function are the
> memory size probe (3 writes into memory and 1 read per bank) the
> get_ram_size function doesn't address mapping of two banks once the
> sizes are detected. That is where most of my effort went.

I don't understand why you use a static layout which  can  deal  only
with  a  few predefined sizes but needs such a lot of code. There are
other boards with more than one bank of  memory,  which  IMHO  handle
this  more flexible and with less "magic" and less code; please study
the sources - and read the README.

> So I'll stick with my code for now, although  I'll keep a watch on
> the changes that Stefan suggests are coming.

I don't think I will accept your patch.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hi there! This is just a note from me, to you, to tell you, the  per-
son  reading this note, that I can't think up any more famous quotes,
jokes, nor bizarre stories, so you may as well go home.

[U-Boot-Users] Re: [Patch] JSE SDRAM size probing

[Stephen Williams]

Wolfgang Denk wrote:

> I don't understand why you use a static layout which  can  deal  only
> with  a  few predefined sizes but needs such a lot of code. There are
> other boards with more than one bank of  memory,  which  IMHO  handle
> this  more flexible and with less "magic" and less code; please study
> the sources - and read the README.

That's great, there are a lot of PPC boards. Can you recommend
one or two that you would judge to be good models of the "right"
way to do this? I suspect by your tone that you have at least
one example in mind.


-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

[U-Boot-Users] Re: [Patch] JSE SDRAM size probing

[Wolfgang Denk]

In message <dqtvnu$se3$1@sea.gmane.org> you wrote:
> 
> That's great, there are a lot of PPC boards. Can you recommend
> one or two that you would judge to be good models of the "right"
> way to do this? I suspect by your tone that you have at least
> one example in mind.

Ummm... not in mind, but in the sources :-)

-> -> egrep -l 'size_b0.*size_b1' board/*/*.c | grep -v flash.c
board/esteem192e/esteem192e.c
board/etx094/etx094.c
board/genietv/genietv.c
board/mvs1/mvs1.c
board/nx823/nx823.c
board/tqm8xx/tqm8xx.c

Here you have a list of some boards that have  two  SDRAM  banks.  In
your  case  board/tqm8xx/tqm8xx.c  ins probably best as it implements
the algorithm described in the README.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Cigarette, n.: A fire at one end, a fool at the other, and a  bit  of
tobacco in between.