[U-Boot-Users] [Patch] JSE SDRAM size probing
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
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
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.
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
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.
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
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
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
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,
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
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.
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
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
participants (4)
-
Stefan Roese -
Stephen Williams -
uboot＠sundmangroup.com -
Wolfgang Denk