January 2004 - U-Boot

RE: [U-Boot-Users] U-Boot on MPC8280
by Rod Boyce 08 Jan '04

08 Jan '04

John, The method I use is no less "cleaner" I just start out in userland process in stead of kernel mode. Single stepping from Userland to Kernel mode has never worked I just use two hardware break points one in the kernel and one in the User process. Regards, Rod Boyce. -----Original Message----- From: John W. Linville [mailto:linville@lvl7.com] Sent: Friday, January 09, 2004 1:36 AM To: Rod Boyce Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] U-Boot on MPC8280 Is your method any "cleaner"? Thanks, John -- John W. Linville LVL7 Systems, Inc.

1 0

[U-Boot-Users] Re: Some puzzles on dram_size()
by chris＠nanometrics.ca 08 Jan '04

08 Jan '04

Hi Sam, Your problem with dram_size() may be that it tests memory beyond the maxsize given. for (cnt = maxsize / sizeof (long); cnt > 0; cnt >>= 1) { addr = base + cnt; /* pointer arith! */ save[i++] = *addr; *addr = ~cnt; } If maxsize = 16M, initial cnt = 4M, so if base = 0, the first time through the loop, addr = 16M which is the first address outside of the memory range given to test. The reason it usually works is that most boards make the AM (address mask) in the OR (option register) of the memory controller specify more memory than they actually need. This may be the easy way to fix it, however I would say the correct way would be to change the lines for (cnt = maxsize / sizeof (long); cnt > 0; cnt >>= 1) { for (cnt = 1; cnt <= maxsize / sizeof (long); cnt <<= 1) { to for (cnt = maxsize / sizeof (long) / 2; cnt > 0; cnt >>= 1) { for (cnt = 1; cnt < maxsize / sizeof (long); cnt <<= 1) { Unfortunately it appears in many board specific versions. While I'm at it, the entire function should be moved to a file in the common directory and the function definition changed to long int dram_size (long int *base, long int maxsize) The setting of the MxMR (memory A/B mode register) has nothing to do with determining the DRAM size and should be done in the calling function which is board specific. I know, I'm free to submit a patch, but I'm a combination of busy and lazy. Chris

3 7

Re: [U-Boot-Users] Re: Some puzzles on dram_size()
by chris＠nanometrics.ca 08 Jan '04

08 Jan '04

Hi Sam, Sam you wrote: > 3.When I changed two lined code as Chris gave and set > SDRAM_MAX_SIZE = 0x8000000(128MB),it worked badly. Did you remember to change the AM bits in the OR? If you want to test 128MB the memory controller must be given 128MB for the SDRAM chip select. You must have changed it before for 64MB to work, since the default value for CFG_PRELIM_OR_AM for the RPX Lite is 0xfe000000 (32MB). Most board specific files include/configs/<board>.h have a line like: #define CFG_OR1_PRELIM (CFG_PRELIM_OR_AM | CFG_OR_TIMING_SDRAM ) Maybe it should be changed to #define CFG_OR_AM_SDRAM (- (SDRAM_MAX_SIZE & 0xffff8000)) #define CFG_OR1_PRELIM (CFG_OR_AM_SDRAM | CFG_OR_TIMING_SDRAM ) Then the only problem will be if the banks overlap, which is much too complicated to automate or verify. Thanks Wolfgang for such a quick patch. Note that the remaining dram_size functions can usually be eliminated and have the initdram function call get_ram_size directly after setting the MxMR again. Chris

2 1

[U-Boot-Users] U-Boot on MPC8280
by sudhakar rajashekhara 08 Jan '04

08 Jan '04

Hi, I am trying to port U-boot-1.0.0 on a board which has MPC8280 processor. I have started with RAM boot. I am using VisionPROBE utility to debug. One of the line which U-boot executes is as follows. boot_warm: mfmsr r5 /* save msr contents */ This line is supposed to move the contents of MSR register to R5 register. I am seeing the content of these two registers before the execution of the above statement and after the execution, using "DR" command. But I feel that the above statement is not executed properly as the content of R5 register is same even after the above line is executed (in my case 40) whereas MSR is all ZEROes. Why is it happening so? I also want to know whether anyone has sucessfully ported U-boot to MPC8280? regards, Sudhakar. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

3 4

[U-Boot-Users] Unexpected crash in init_baudrate
by Jeff Stevens 08 Jan '04

08 Jan '04

I am porting U-Boot over to a new product running an MPC855T processor, 512KB of flash, 16MB of SDRAM, and a 32KB Simtek NVRAM. I have the board booting up to the point where it tries to read the baudrate for the RS-232 port (init_baudrate). When it goes into the getenv_r function from within init_baudrate, it seems to eventually crash before it comes back with an answer. The system seems to read from the NVRAM fine when it boots and runs crc32 on it. It also crashes if I change CFG_ENV_SIZE to 0x4 and force it to read the default values (env_get_char_init). Does anyone have any ideas as to what can be causing this? I'm going to keep poking around myself, but I just wanted to see if anyone else has had a problem like this while porting U-Boot. Thanks in advance, Jeff Stevens __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 3

RE: [U-Boot-Users] U-Boot on MPC8280
by David Aldrich 07 Jan '04

07 Jan '04

Hi Wolfgang May I ask one further question re. the BDI2000? An article on the internet states: "You might be wondering why the BDI2000 only works with kernel-mode code and not user-land application code. The technical details are beyond the scope of this AppNote. The 10,000 foot answer is that while the BDI2000 can work with the MMU enabled, it can only work with a single continuous memory map. Kernel-mode code exists in a single continuous memory map, which is disjoint from all of the user-land process memory maps. As an example of the usefulness of this tool in production environments, the PPC porting engineers at Monta Vista Software use the BDI2000 extensively for kernel bring-up and device driver debug" Is it true that the BDI is not suitable for user app debug? Is this a problem in practice? Thanks David

3 3

RE: [U-Boot-Users] U-Boot on MPC8280
by David Aldrich 07 Jan '04

07 Jan '04

Hi Wolfgang Thank you very much for your explanation. Best regards David

1 0

RE: [U-Boot-Users] U-Boot on MPC8280
by David Aldrich 07 Jan '04

07 Jan '04

Hi > Do you think that the Windriver equipment ( e.g. VisionPROBE > ) is of low quality? > > When looking at the demos, they have been looking a bit > sharper than e.g. the BDI2000. I have seen several posts by Wolfgang giving a poor opinion (to put it mildly) of the Vision Probe. However, it is worth noting that Wind River announced in late 2003 that Vision Probe now supports Linux. So I guess they now properly support the MMU etc. But I can't get much information about it from Wind River. Has anyone tried the new version? David

2 1

RE: [U-Boot-Users] U-Boot on MPC8280
by Matias Sundman (AL/EAB) 07 Jan '04

07 Jan '04

Hi Wolfgang, Do you think that the Windriver equipment ( e.g. VisionPROBE ) is of low quality? When looking at the demos, they have been looking a bit sharper than e.g. the BDI2000. Regards // Matias -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Wolfgang Denk Sent: den 7 januari 2004 14:58 To: sudhakar rajashekhara Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] U-Boot on MPC8280 Hello, in message <20040107131759.31653.qmail(a)web10602.mail.yahoo.com> you wrote: > > I am trying to port U-boot-1.0.0 on a board which has > MPC8280 processor. I have started with RAM boot. I am As pointed out many times before this is probably not a good idea unless you know exactly what you are doing and how U-Boot is working. If this is one of your first ports of U-Boot and/or if you don;t know the processor really well I recommend to use the standard way of booting from flash instead. > using VisionPROBE utility to debug. One of the line Sincere condolences. > This line is supposed to move the contents of MSR > register to R5 register. I am seeing the content of > these two registers before the execution of the above > statement and after the execution, using "DR" command. > But I feel that the above statement is not executed > properly as the content of R5 register is same even > after the above line is executed (in my case 40) > whereas MSR is all ZEROes. Why is it happening so? I Maybe your debugger is not working as expected... Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de A meeting is an event at which the minutes are kept and the hours are lost. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

2 1

[U-Boot-Users] [patch] CONFIG_SILENT_CONSOLE
by Wolter Kamphuis 07 Jan '04

07 Jan '04

Hi all, I have sent this patch on 15 December but didn't received any comments so it probably has been overlooked. I've changed the implementation of the CONFIG_SILENT_CONSOLE flag a bit. Instead of checking for the CONFIG_SILENT_CONSOLE flag in lib_*/board.c I've moved the code to common/console.c. Now all (and future) architectures and boards can use the CONFIG_SILENT_CONSOLE flag. The patch is against the CVS. Wolter Kamphuis MuLogic B.V. diff -purN u-boot/common/console.c u-boot.silent/common/console.c --- u-boot/common/console.c 2003-10-16 01:53:50.000000000 +0200 +++ u-boot.silent/common/console.c 2003-12-15 10:37:49.000000000 +0100 @@ -191,6 +191,11 @@ void putc (const char c) { DECLARE_GLOBAL_DATA_PTR; +#ifdef CONFIG_SILENT_CONSOLE + if (gd->flags & GD_FLG_SILENT) + return(0); +#endif + if (gd->flags & GD_FLG_DEVINIT) { /* Send to the standard output */ fputc (stdout, c); @@ -204,6 +209,11 @@ void puts (const char *s) { DECLARE_GLOBAL_DATA_PTR; +#ifdef CONFIG_SILENT_CONSOLE + if (gd->flags & GD_FLG_SILENT) + return; +#endif + if (gd->flags & GD_FLG_DEVINIT) { /* Send to the standard output */ fputs (stdout, s); diff -purN u-boot/doc/README.silent u-boot.silent/doc/README.silent --- u-boot/doc/README.silent 2003-10-10 12:05:42.000000000 +0200 +++ u-boot.silent/doc/README.silent 2003-12-15 10:54:52.000000000 +0100 @@ -9,8 +9,6 @@ The following actions are taken if "sile - Until the console devices have been initialized, output has to be suppressed by testing for the flag "GD_FLG_SILENT" in "gd->flags". - Currently only the messages for the TRAB board are handled in this - way. - When the console devices have been initialized, "stdout" and "stderr" are set to "nulldev", so subsequent messages are diff -purN u-boot/lib_arm/board.c u-boot.silent/lib_arm/board.c --- u-boot/lib_arm/board.c 2003-12-07 01:46:27.000000000 +0100 +++ u-boot.silent/lib_arm/board.c 2003-12-15 10:39:02.000000000 +0100 @@ -115,13 +115,6 @@ static int init_baudrate (void) static int display_banner (void) { -#ifdef CONFIG_SILENT_CONSOLE - DECLARE_GLOBAL_DATA_PTR; - - if (gd->flags & GD_FLG_SILENT) - return (0); -#endif - printf ("\n\n%s\n\n", version_string); printf ("U-Boot code: %08lX -> %08lX BSS: -> %08lX\n", _armboot_start, _armboot_end_data, _armboot_end); @@ -148,11 +141,6 @@ static int display_dram_config (void) DECLARE_GLOBAL_DATA_PTR; int i; -#ifdef CONFIG_SILENT_CONSOLE - if (gd->flags & GD_FLG_SILENT) - return (0); -#endif - puts ("RAM Configuration:\n"); for(i=0; i<CONFIG_NR_DRAM_BANKS; i++) { @@ -165,12 +153,6 @@ static int display_dram_config (void) static void display_flash_config (ulong size) { -#ifdef CONFIG_SILENT_CONSOLE - DECLARE_GLOBAL_DATA_PTR; - - if (gd->flags & GD_FLG_SILENT) - return; -#endif puts ("Flash: "); print_size (size, "\n"); }

2 1