May 2003 - U-Boot

[U-Boot-Users] Doubt on Kernel Linking
by Rupesh S 27 May '03

27 May '03

Hi, I work with MPC823FADS board. I'm using u-boot as the bootloader in it. The RAM memroy map as seen with the "bdinfo" command in u-boot says.. 0x00000000 to 0x00800000. I'm trying to boot linux kernel ( linux-2.4.4-2002-10-06 from DENX) on my board. By default , the kernel is build at 0xC0000000. (This memory is not mapped by u-boot). Do I have to change the kernel linking to a address that is within, 0x00000000 and 0x00800000 ? Rupesh

3 10

[U-Boot-Users] Sharing the serial driver
by Marc Singer 26 May '03

26 May '03

There appears to be a serial driver in most every BSP. Are you willing to merge a driver than can be shared among CPUs and boards?

2 1

[U-Boot-Users] Loads function and flow control.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 26 May '03

26 May '03

Hi. I am just starting to work with loads function. Is there any mechanism for software flow control ( XON, XOFF ) ? I have seen some define for loadb bu nothing for loads... It seems that loads works fine when I download small files but get lost with big ones. So I fear a flow control problem. What is the problem with minicom for loads ? I think that loads just expect to receive ascii data. Is it wrong to send srec file using ALT S in minicom ( and choosing ascii data ) ? Chris

5 10

RE: [U-Boot-Users] Loads function and flow control.
by Christophe.LINDHEIMER＠fr.thalesgroup.com 26 May '03

26 May '03

Well, I use a serial line at 9600 Bauds. I use minicom to send commands to UBoot. Once the loads is done I make a cat hello_world.srec > /dev/ttyS1 in order not to use minicom to keep Wolfgang in good mood for the whole week :-)) The first data are corrects but UBoot aborts the download after a few lines... => mw 0x4000 0 200 => loads ## Ready for S-Record download ... S013000068656C6C6F5F776F726C642E7372656376 S214040000000181749421FFE07C0802A6BF61000C05 S21404001090010024480000057FC802A6801EFFE861 S2140400207FC0F2147C7B1B78807E80007C9F2378C4 S214040030480000B1807E80047F64DB78480000A519 S2140400403B8000007C1CD8004181003080BF00004B S2140400503BFF00042C0500004082000880BE800898 S214040060807E800C7F84E378480000793B9C000106 ## S-Record download abortedE80104800006534 => 4204E8000208B Unknown command '4204E8000208B' - try 'help' => => 440000024E800020380000024400000273 Unknown command '440000024E800020380000024400000273' - try 'help' => => 420380000055A Unknown command '420380000055A' - try 'help' => => 080002038000007440000024E80002085 Unknown command '080002038000007440000024E80002085' - try 'help' => => 000A440000020A Unknown command '000A440000020A' - try 'help' => => 60000008B Unknown command '60000008B' - try 'help' => => 21545B25645D203D20222573220A00000000ED Unknown command '21545B25645D203D20222573220A00000000ED' - try 'help' => => 72E2E2081 Unknown command '72E2E2081' - try 'help' => => 4144000501640005015015 Unknown command '4144000501640005015015' - try 'help' => => md 0x40000 00040000: 00018174 9421ffe0 7c0802a6 bf61000c ...t.!..|....a.. 00040010: 90010024 48000005 7fc802a6 801effe8 ...$H........... 00040020: 7fc0f214 7c7b1b78 807e8000 7c9f2378 ....|{.x.~..|.#x 00040030: 480000b1 807e8004 7f64db78 480000a5 H....~...d.xH... 00040040: 3b800000 7c1cd800 41810030 80bf0000 ;...|...A..0.... 00040050: 3bff0004 2c050000 40820008 80be8008 ;...,...@....... 00040060: 807e800c 7f84e378 48000079 3b9c0001 .~.....xH..y;... 00040070: 00000000 00000000 00000000 00000000 ................ 00040080: 00000000 00000000 00000000 00000000 ................ 00040090: 00000000 00000000 00000000 00000000 ................ 000400a0: 00000000 00000000 00000000 00000000 ................ 000400b0: 00000000 00000000 00000000 00000000 ................ 000400c0: 00000000 00000000 00000000 00000000 ................ 000400d0: 00000000 00000000 00000000 00000000 ................ 000400e0: 00000000 00000000 00000000 00000000 ................ 000400f0: 00000000 00000000 00000000 00000000 ................

2 1

[U-Boot-Users] U-boot +BDI2000 code downloading
by Karoliya, Abhishek 24 May '03

24 May '03

Hi , I am trying to port u-Boot to a custom 8245 board using BDI2000 in the progress . I tried using the facility of BDI to download code {U-boot.bin} using the HOST section of the configuration file {sp8240.cfg}. For this purpose do I have to make changes to address where u-boot is linked or what offset should I download. Just wondering how would BDI can place the code in memory when the RAM interface has been configured {timings etc}. Also if I burn the Flash using BDI for u-boot.bin should I have to give address 0xfff00000 or 0xfff0 0100. thanks Abhi

1 0

[U-Boot-Users] PCI support on the PrPMC800
by Mark.Lightfoot＠sita.aero 24 May '03

24 May '03

Hello, My port of U-Boot the to Motorola PrPMC800 continues. My next task it to add PCI support. At this point I don't have a clue what to do! I've got the function stub, pci_init_board(), being executed but its an empty function and does nothing. What should it do? The board uses a Motorola Harrier ASIC to bridge the PowerPC bus to PCI so obviously I've have to configure that. But is that it. Does the U-Boot code take over from there and start scanning and mapping/configuring PCI devices from there? Another problem is my lack of knowledge on the finer point of how PCI works. Any one recommend a good source of such information? Regards, Mark ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Mark Lightfoot - Software Designer - SITA 777 Walker's Line, Burlington, Ontario, Canada, L7N 2G1 905-681-5575 mark.lightfoot(a)sita.aero ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

1 0

[U-Boot-Users] effort required to port u-boot
by Gupta, Kshitij 24 May '03

24 May '03

Hi, Does anyone have an idea of the effort required to port the full uboot to a new arm based target?? Please excuse me for the nature of the question but if anyone has done it already he can suggest abt how much time he took to port the whole u-boot on a new target (just a very rough estimate), assuming that the developer has a very good knowledge of the target but at a comfort level [medium] on linux.. Any comments will be really helpful Regards, kshitij

4 3

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

23 May '03

Hum hum... I have the feeling that you next mail will tell me that I should have read more deeply the Readme ... Sorry... & thanks for help !! Chris -----Message d'origine----- De: Wolfgang Denk [mailto:wd@denx.de] Date: vendredi 23 mai 2003 15:38 À: Christophe.LINDHEIMER(a)fr.thalesgroup.com Cc: nyet(a)mrv.com; u-boot-users(a)lists.sourceforge.net Objet: Re: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx In message <D96E2AFA0DF3D211B13900902745494803736286(a)helios.gnv.tcc.thomson-csf.com> you wrote: > > In fact it seems that the get_clocks return a freq of 33.6 Mhz whereas = > it > should be 38.4 Mhz... Do you have a clock connected to EXTAL, and which clock frequency is this? 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 The easiest way to figure the cost of living is to take your income and add ten percent.

2 1

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

23 May '03

>> >> In fact it seems that the get_clocks return a freq of 33.6 Mhz whereas = >> it >> should be 38.4 Mhz... > >Do you have a clock connected to EXTAL, and which clock frequency is this? It seems that there is a lovely pull up on EXTAL... Chris

2 1

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

23 May '03

Hi. In fact it seems that the get_clocks return a freq of 33.6 Mhz whereas it should be 38.4 Mhz... So a #define CONFIG_8xx_GCLK_FREQ in the file config for my board works fine. I have now U-boot writing on the console. Thanks for help. Chris -----Message d'origine----- De: nyet(a)mrv.com [mailto:nyet@mrv.com] Date: jeudi 22 mai 2003 21:58 À: Wolfgang Denk Cc: Christophe.LINDHEIMER(a)fr.thalesgroup.com; u-boot-users(a)lists.sourceforge.net Objet: Re: [U-Boot-Users] UBoot hangs in serial_putc on mpc8xx The 8xx BRG code is has an interesting side effect if the cpu clock rate is not properly detected... the divisor will overflow the allowed bitwidth and an invalid value will get put brgc1 Hardcode CONFIG_8xx_GCLK_FREQ and/or brgc1 in speed.c and serial.c I am working on putting together a fairly extensive 8xx patch to address this and many other problems.

2 1

[U-Boot-Users] CFG_MONITOR_BASE, CFG_FLASH_BASE, TEXT_BASE
by Bogdan Woldert-Jokisz 23 May '03

23 May '03

hi what are the macros CFG_MONITOR_BASE, CFG_FLASH_BASE and TEXT_BASE ? I think, CFG_FLASH_BASE is the lowest address of the flash. But what are the other macros? My problem: My flash memory (8MB) starts at 0xff800000. But the bootloader should start at 0xfff80000. Is it possible? The bootloader works if I define CFG_FLASH_BASE to 0xfff80000, but I need the real start address of the flash memory in the board-info-structure. Thanks Bogdan

2 1

[U-Boot-Users] [PATCH] change xscale to pxa
by Kyle Harris 23 May '03

23 May '03

In preparation for an ixp port, this patch renames cpu/xscale and arch-xscale to cpu/pxa and arch-pxa. It is applied against CVS timestamp 030520. MAKEALL completes for LIST_pxa. (Is there a better way for simply renaming directories?) Kyle.

2 1

RE: [U-Boot-Users] Doubt on Kernel Linking
by Flavio Pereira 23 May '03

23 May '03

Hi Rupesh >I'm trying to boot linux kernel ( linux-2.4.4-2002-10-06 from DENX) on my board. >By default , the kernel is build at 0xC0000000. (This memory is not mapped by u-boot). >Do I have to change the kernel linking to a address that is within, 0x00000000 and 0x00800000 ? The address 0xC0000000 is the virtual memory address in which the kernel runs, when the kernel decompresses you should see that it decompressed into the physical address 0x0, which is mapped by U-Boot. Therefore there is no problem in the kernel linking at 0xC0000000. Regards Flavio Pereira

1 0

[U-Boot-Users] Re: MIP405-3 Patch
by Wolfgang Denk 23 May '03

23 May '03

Dear Denis, in message <200305190957.h4J9vBQW023721(a)pip5.mpl.ch> you wrote: > > attached is a patch against the current CVS which will add support for the > MIP405-3 (405GPR) Board. Thanks, added. 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 "Whoever undertakes to set himself up as a judge of Truth and Know- ledge is shipwrecked by the laughter of the gods." - Albert Einstein

1 0

[U-Boot-Users] [patch] MPC8266 March-C memory test
by Rune Torgersen 23 May '03

23 May '03

Patch to do full March-C- memory test on the MPC8266ADS board. Later on I will probably include it as a command, right now it runs as test_dram() which is called first thing after SDRAM is initializes, and before anything uses the SDRAM. Note: Fast version uses floating point assembly and is therefore PPC specific. Generic version takes more than twice the amount of time to complete. (Fast version: ~50 sec on 256MB RAM, slow version ~1:50 on 256MB RAM) ADS 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

3 4

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