May 2003 - U-Boot

RE: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx
by Christophe.LINDHEIMER＠fr.thalesgroup.com 23 May '03

23 May '03

> > it is a custom board with a mpc8xx. > > Then the answer to your question is simple: you made some errors in > your port of U-Boot to your hardware. I know, this is just an anwer > to your question, not a solution to your problem. > > > I think that most of the config is board independant. ( > Prog of the BRG, > > Prog of the CPM ... ) > > You are wrong. A LOT of the configuration parameters are hardware > specific. > > > U-Boot finds 9600 for the baudrate in the env. > > So I wonder where board specific items can make it hang. > > Basicly anything. Bad clock configuration for example. > You right. It seems that with new values for clock registers it works much better... So it doesn't hang anymore and I reach the getc(). I still don't have anything on my terminal console but the solution can't be far ! Chris

1 0

[U-Boot-Users] Changed to get CVS head to build sc520_cdp
by Marc Singer 23 May '03

23 May '03

Both 0.3.0 and the latest head revision refused to build until I made this patch. Am I misunderstanding something? diff -ru u-boot-0.3.0/include/asm-i386/u-boot.h ../coastal/uboot/u-boot-0.3.0/include/asm-i386/u-boot.h --- u-boot-0.3.0/include/asm-i386/u-boot.h Sun Nov 17 15:11:13 2002 +++ ../coastal/uboot/u-boot-0.3.0/include/asm-i386/u-boot.h Tue May 6 00:44:33 2003 @@ -44,6 +44,8 @@ unsigned long bi_intfreq; /* Internal Freq, in MHz */ unsigned long bi_busfreq; /* Bus Freq, in MHz */ unsigned long bi_baudrate; /* Console Baudrate */ + /* *** added to get the code to compile for x86 */ + unsigned long bi_boot_params; /* where this board expects params */ struct environment_s *bi_env; struct /* RAM configuration */ { My method was simple. > make sc520_cdp_config > make ######################################## On another track, I suspect that there may be a typographically generated bug in cpu/i386/start16.S. The code reads like this. /* Turn of cache (this might require a 486-class CPU) */ movl %cr0, %eax orl $060000000,%eax movl %eax, %cr0 wbinvd I believe that the correct immediate value is $0x60000000. The given octal value is 0x00c00000 hexadecimal. According to the Intel documentation I have on hand, these bits are presently reserved in %cr0.

2 1

[U-Boot-Users] configs/FADS860T.h
by Nye Liu 23 May '03

23 May '03

None of these values from include/configs/FADS860T.h are used in boards/fads/fads.c... Is somebody else working in fads.c other than me currently? I am about to rewrite large portions of it. --------------- snip --------------- /* periodic timer for refresh */ #define CFG_MAMR_PTA 97 /* start with divider for 100 MHz */ /* refresh rate 15.6 us (= 64 ms / 4K = 62.4 / quad bursts) for <= 128 MBit */ #define CFG_MPTPR_2BK_4K MPTPR_PTP_DIV16 /* setting for 2 banks */ #define CFG_MPTPR_1BK_4K MPTPR_PTP_DIV32 /* setting for 1 bank */ /* refresh rate 7.8 us (= 64 ms / 8K = 31.2 / quad bursts) for 256 MBit */ #define CFG_MPTPR_2BK_8K MPTPR_PTP_DIV8 /* setting for 2 banks */ #define CFG_MPTPR_1BK_8K MPTPR_PTP_DIV16 /* setting for 1 bank */ /* * MAMR settings for SDRAM */ /* 8 column SDRAM */ #define CFG_MAMR_8COL ((CFG_MAMR_PTA << MAMR_PTA_SHIFT) | MAMR_PTAE | \ MAMR_AMA_TYPE_0 | MAMR_DSA_1_CYCL | MAMR_G0CLA_A11 | \ MAMR_RLFA_1X | MAMR_WLFA_1X | MAMR_TLFA_4X) /* 9 column SDRAM */ #define CFG_MAMR_9COL ((CFG_MAMR_PTA << MAMR_PTA_SHIFT) | MAMR_PTAE | \ MAMR_AMA_TYPE_1 | MAMR_DSA_1_CYCL | MAMR_G0CLA_A10 | \ MAMR_RLFA_1X | MAMR_WLFA_1X | MAMR_TLFA_4X) #define CFG_MAMR 0x13a01114 -- Nye Liu nliu(a)mrv.com (818) 772-6235x248 "Who would be stupid enough to quote a fictitious character?" -- Don Quixote

2 2

[U-Boot-Users] bringing up a new x86 board
by Marc Singer 23 May '03

23 May '03

Daniel, I found one patch you've made (april 30'th) to u-boot-3.0 since it was released in early April. Are there any others? Also, when I attempted to apply the patch I found in the archive, I discovered it was truncated. Would you be kind enough to send me a copy?

1 0

RE: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx
by Christophe.LINDHEIMER＠fr.thalesgroup.com 22 May '03

22 May '03

>> >> I have just flashed U-Boot. > >Which board configuration? it is a custom board with a mpc8xx. I think that most of the config is board independant. ( Prog of the BRG, Prog of the CPM ... ) U-Boot finds 9600 for the baudrate in the env. So I wonder where board specific items can make it hang. >> It starts but it seems it hangs in serial_putc ( in the while at the end of >> the function ). >> Any idea about what to look ? > >With that little information you provide? Sorry... Well, I thought ( and hoped ) that I made a standard mistake somewhere ... Chris

3 2

[U-Boot-Users] PCI patch for MPC8266
by Rune Torgersen 22 May '03

22 May '03

Patch for getting PCI to work on a MPC8266ADS board. Also incorporates change to /cpu/mpc8260/pci.c to enable overrides of PCI memory parameters Rune Torgersen Software Developer Innovative Systems 1000 Innovative Drive Mitchell, SD 57301 Phone: 605-995-6120 Fax: 605-995-0084 email: runet(a)innovsys.com www.innovsys.com

2 1

[U-Boot-Users] UBoot hangs in serial_putc on mpc8xx
by Christophe.LINDHEIMER＠fr.thalesgroup.com 22 May '03

22 May '03

Hi. I have just flashed U-Boot. It starts but it seems it hangs in serial_putc ( in the while at the end of the function ). Any idea about what to look ? Thanks Chris

2 1

[U-Boot-Users] ECC DIMM's with walnut board
by Thomas Schäfer 22 May '03

22 May '03

Hi all, I tried to boot a walnut board with a 256 ECC DIMM using u-boot 0.3.0, but didn't succeed. When examining the code in the function spd_sdram in cpu/ppc4xx/spd_sdram, I found that the ECC configuration code is probably wrong. I suppose, that the following lines /* now check for ECC ability of module. We only support ECC * on 32 bit wide devices with 8 bit ECC. */ if ( (read_spd(11)==2) && ((read_spd(6)==40) || (read_spd(14)==8)) ){ sdram0_ecccfg=0xf<<SDRAM0_ECCCFG_SHIFT; ecc_on = 1; should be replaced with /* now check for ECC ability of module. We only support ECC * on 32 bit wide devices with 8 bit ECC. */ ==> if ( (read_spd(11)==2) && ((read_spd(6)==40) && read_spd(14)==8)) ){ <== sdram0_ecccfg=0xf<<SDRAM0_ECCCFG_SHIFT; ecc_on = 1; The reason is, that the if statement in the first code is also true for 72 bit ECC devices. So ECC is enabled for such a device which fails in the following. The changed code works for me with several DIMM types (32MB without ECC, 256 MB with ECC and without ECC), but I'm not an expert with all types of SDRAM and so I'm not sure if I fully understood the code in that place. Any ideas, comments? Best regards Thomas Schäfer ____________________________________ GIGA STREAM - UMTS Technologies GmbH Konrad-Zuse-Str. 7 66115 Saarbrücken Tel.: + 49 (0)681 / 95916 - 203 Fax: + 49 (0)681 / 95916 - 100 E-mail: tschaefer(a)giga-stream.de

3 2

[U-Boot-Users] I386 U-boot update
by Daniel Engström 22 May '03

22 May '03

Hello I have attached a number of patches wich updates Uboot to my current version for i386. Some common files are touched, mostly small changes except for the IDE driver which I made some more changes for code readability and 386 support, I hope that it still works for the PPC case. I will be out of the office until May 14. so any comments will not be answred until then. /Daniel

2 2

Re: [U-Boot-Users] Please explain this code in drivers/pci.c
by Donald White 21 May '03

21 May '03

Udi, I am convinced now it is incorrect. A minimal fix is to make the code look like this: /* Check the BAR type and set our address mask */ if (bar_response & PCI_BASE_ADDRESS_SPACE) { bar_size = ~(bar_response & PCI_BASE_ADDRESS_IO_MASK) + 1; /* round up region base address to a multiple of size */ io = ((io - 1) | (bar_size - 1)) + 1; bar_value = io; /* compute new base address for region */ io = io + bar_size; } else { if ( (bar_response & PCI_BASE_ADDRESS_MEM_TYPE_MASK) == PCI_BASE_ADDRESS_MEM_TYPE_64) found_mem64 = 1; bar_size = ~(bar_response & PCI_BASE_ADDRESS_MEM_MASK) + 1; /* round up region base address to multiple of size */ mem = ((mem - 1) | (bar_size - 1)) + 1; bar_value = mem; /* compute new region base address */ mem = mem + bar_size; } The ORing just rounds up the current base for the region to be a multiple of the size. The ORing was in the wrong place and there was no increment of the region base to beyond the allocated area. It worked with cards with single BARs and suitable region bases. This is not optimal, but it is useable for simple cases. Thanks for the comments, Don Udi Finkelstein wrote: > I've looked at the code you posted, and it looks indeed incorrect. (I > didn't look into the entire file in u-boot, so take this with a grain of > salt). > However, and optimal PCI alolcator must sort the BAR size in decreasing > orders if it wants to pack the BARs into an area as small as possible. > If you have BAR0 size 4K and BAR1 size 256M and BAR2 size 4K, then > allocating BAR0 from (for example) 0xe0000000 would yield BAR0 range of > 0xe0000000-0xe0000fff, BAR1 would be mapped to 0xf0000000 - 0xffffffff, > and BAR2 would not fit! > An optimal allocator must start from the biggest BARs first: > > BAR1 would fit at 0xe0000000-0xefffffff > BAR2 would fit at 0xf0000000-0xf0ffffff > BAR0 would fit at 0xf1000000-0xf1000fff > > Udi > > Donald White wrote: > >> >> Rune Torgersen wrote: >> >>> >>>> Subject: [U-Boot-Users] Please explain this code in drivers/pci.c >>> >>> >>> >>> >>>> The value of bar_response is 0xffff8008 which looks good. This >>>> gives bar >>> >>> >>> >>> size of >>> >>>> 0x8000 which also looks good. The value of mem is initially >>>> 0x90000000. >>> >>> >>> >>> So, >>> >>>> (mem - 1) = 0x8fffffff and (bar_size - 1) = 0x7fff). When these >>>> are or'd >>> >>> >>> >>> one gets >>> >>>> 0x8fffffff and adding 1 gives 0x90000000. This result is that the >>>> card is >>> >>> >>> >>> given 4 >>> >>>> address bases all at 0x90000000. >>> >>> >>> >>> >>> >>> If the card wants 4 different memory regiuons, I assume it has 4 BAR >>> registers? Each BAR must have the correct base address, so you have >>> to add >>> the size of the last region to the memory pointer before writing the >>> address to the next BAR >>> >>> >> >> I am not sure if you are trying to clarify the question or provide an >> answer. My complaint is that the code does not do what you say. I >> believe the code should provide four unique values for the four BARs, >> but it does not. Each gets the same value because the ORing logic >> does not succeed in doing a new base = old base + size. >> >> The logic envoked by CONFIG_PCI_PNP gets the calculation right. If >> someone is familiar with the code and can confirm that it is not >> behaving as intended, then I will do a patch. The ORing logic looks >> to me to be copied from the Linux kernel where the allocation starts >> at the top of the address range and proceeds downward, but maybe it is >> an attempt to force alignment. I don't know. >> >> Don >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: ObjectStore. >> If flattening out C++ or Java code to make your application fit in a >> relational database is painful, don't do it! Check out ObjectStore. >> Now part of Progress Software. http://www.objectstore.net/sourceforge >> _______________________________________________ >> U-Boot-Users mailing list >> U-Boot-Users(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/u-boot-users >> >

1 0