July 2004 - U-Boot

RE: [U-Boot-Users] Ethernet does not work on at91rm9200
by Kögler Peter 06 Jul '04

06 Jul '04

hi hamid, i added CONFIG_AT91C_USE_RMII to my configuration and now it works. sorry guys for trouble i caused! another problem i have is that if i boot via nfs everything works, linux knows the mac-adress. but if i boot from filesystem (jffs2) than linux doesnt know the mac-adress. if i stop at u-boot prompt, call any network function, and start linux afterwords, then linux knows the mac-adress. does u-boot only initialize the ethernet interface if it is needed? can i force u-boot to init the ethernet interface or is there another 'standard' way to tell linux the mac-adress? wbr peter -------------------------------------------------------------- Peter Kögler EL-ME AG Gewerbering 1 D-84072 Au i. d. Hallertau Tel.: +49 / 8752 / 864 - 527 Fax.: +49 / 8752 / 864 - 100 mailto.: p.koegler(a)el-me.de Web: www.el-me.de -----Original Message----- From: Hamid IKDOUMI [mailto:hikdoumi@rfo.atmel.com] Sent: Friday, July 02, 2004 10:23 AM To: 'Kögler Peter'; u-boot-users(a)lists.sourceforge.net Subject: RE: [U-Boot-Users] Ethernet does not work on at91rm9200 Hi Peter, The ethernet works fine on at91rm9200dk board. Can you give more information about this issue? (hardware differences with at91rm9200dk board (PHY MII or RMII). Best regards, Hamid -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Kögler Peter Sent: vendredi 2 juillet 2004 09:41 To: 'u-boot-users(a)lists.sourceforge.net' Subject: [U-Boot-Users] Ethernet does not work on at91rm9200 Hello, our custom board runs now perfectly with u-boot 1.1.1 except that the ethernet is not working. But the ethernet worked when we used u-boot 0.4.0. Changing only the driver file at91rm9200_ether.c, now using the u-boot 0.4.0 driver file version in u-boot 1.1.1 helped to fix this problem. wbr Peter ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

3 3

RE: [U-Boot-Users] Ethernet does not work on at91rm9200
by Kögler Peter 06 Jul '04

06 Jul '04

There is an interesting thread about initializing the mac adress: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-April/021126.h tml -------------------------------------------------------------- Peter Kögler EL-ME AG Gewerbering 1 D-84072 Au i. d. Hallertau Tel.: +49 / 8752 / 864 - 527 Fax.: +49 / 8752 / 864 - 100 mailto.: p.koegler(a)el-me.de Web: www.el-me.de -----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Monday, July 05, 2004 7:47 PM To: Kögler Peter Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] Ethernet does not work on at91rm9200 In message <367ED8C46538D7119DAC000A0D106744520D54(a)elmegmbh.elmedmn.com> you wrote: > > but if i boot from filesystem (jffs2) than linux doesnt know the mac-adress. > if i stop at u-boot prompt, call any network function, and start linux > afterwords, then linux knows the mac-adress. This is a problem with your LInux driver which does not perform all the required initialization. This tends to become a FAQ. > does u-boot only initialize the ethernet interface if it is needed? can i Yes. > force u-boot to init the ethernet interface or is there another 'standard' > way to tell linux the mac-adress? U-Boot should NOT touch any hardware it does not access itself. If you don't use the ethernet interface in U-Boot it shall NOT be initialized by U-Boot. The standard way is that the Linux driver is responsible to perform all required initialization. The method to pass information from the boot loader to the Linux kernel is architecture dependent; it may use a bd_info structure (like on PPC), or ATAGs (like on ARM) or command line arguments, or a combination of these. 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 I have made mistakes, but have never made the mistake of claiming I never made one. - James G. Bennet

2 1

RE: [U-Boot-Users] u-boot and 2.4.18 kernel problem
by Lokesh Kumar 06 Jul '04

06 Jul '04

Thanks for this I checked and rechecked my sequence according to document and I do not see any problem. However, I changed PLPRCR to give me reset if I get checkstop, and that is what is happening i.e. I am getting checkstop exception. Any ideas what could be wrong? Lokesh -----Original Message----- From: Sam Song [mailto:samsongshu@yahoo.com.cn] Sent: Wednesday, June 30, 2004 10:22 AM To: Lokesh Kumar Cc: u-boot-users(a)lists.sourceforge.net Subject: RE: [U-Boot-Users] u-boot and 2.4.18 kernel problem Lokesh Kumar wrote: > /* perform SDRAM initializsation sequence */ > > memctl->memc_mar = 0x00000088; > > memctl->memc_mcr = 0x80002105; > memctl->memc_mcr = 0x80002830; > memctl->memc_mcr = 0x80002106; It seems sth out of place here.But I am not quite sure.At least two cycles before refresh should be safer than one.You could refer to my poor work http://cvs.sourceforge.net/viewcvs.py/*checkout*/u-boot/u-boot/board/RPXlite _dw/RPXlite_dw.c?rev=1.1 > udelay (1000); > > size10 = dram_size (CFG_MAMR_10COL, (ulong > *) SDRAM_BASE_PRELIM, > SDRAM_MAX_SIZE); > > memctl->memc_mamr |= MAMR_PTAE; > return (size10); > } > I do not have the upm config tool from motorola to > verify these settings. > Has anybody used this chip with mpc855T and can help > me figure this out? I tested 2 MT48LC16M16A2-75 in 32-bit mode on 832e RPXlite_DW board.It worked fine.Next,I will also test 2 MT48LC8M16A2 on a 8xx custom board.So please let me know your advancement.I just had a look at the datasheet of MT48LC8M16A2 and MT48LC16M16A2.They have exactly the same timing waveform on initialization. Hope this help! Best regards, Sam _________________________________________________________ Do You Yahoo!? 100兆邮箱够不够用？雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/100m/*http://cn.promo.yahoo.com/minisite/ 100m/

2 1

[U-Boot-Users] Relocation code on NIOS
by Maksim Pyatkovskiy 05 Jul '04

05 Jul '04

Good day, I am trying to figure how does U-Boot relocates itself on Cyclone Edition board (DK-1C20). Probably this should be an easy question for most developers familiar with NIOS, but I can't find the answer since I am new to this platform. So, this is my question: =================== The following lines are located in the early beginning of start.s: mov %g7, %o7 /* %o7 has return addr -- save in %g7 use later */ ... pfx %hi(__u_boot_cmd_end) movi %g5, %lo(__u_boot_cmd_end) pfx %xhi(__u_boot_cmd_end) movhi %g5, %xlo(__u_boot_cmd_end) /* %g5 <- end address */ lsli %g7, 1 /* mem = retaddr << 1 */ mov %g6, %g7 subi %g6, 4 /* %g6 <- src addr */ ld %g7, [%g7] /* %g7 <- dst addr */ 1: cmp %g7, %g5 skps cc_nz br 2f nop /* delay slot */ ld %g0, [%g6] addi %g6, 4 /* src++ */ st [%g7], %g0 addi %g7, 4 /* dst++ */ br 1b nop /* delay slot */ I don't understand this particular line of code: ld %g7, [%g7] Per my understanding, %g7 keeps the return address. This address should point to the next instruction of code just after the delay slot of CALL or BSR used to call u-boot. So, if %g7 keeps this address, than [%g7] keeps the code (instruction bytes) located by this address. In this case "ld %g7, [%g7]" loads 4 bytes from code segment to the %g7. Later this value (instruction bytes) is compared with %g5 that keeps the end of data segment according to u-boot.lds. I can't understand why code address is being compared with instruction bytes. Please explain if possible - what does [%g7] keep and where am I wrong? Thank you!

1 0

[U-Boot-Users] u-boot compile failure with gcc-3.4.x and fix.
by Woodruff, Richard 05 Jul '04

05 Jul '04

Hello, I'm noticing that the examples directory fails to compile with gcc-3.4.0. The _exports.h symbols are not making it into stubs.o . I found that the compile works if you: Change: static void __attribute__((unused)) dummy(void) to: void __attribute__((unused)) dummy(void) This would seem to be a new optimization or bug. I would expect that unused should make it stick around, even if it is not used locally. The kernel uses this same construct in a few places mostly in debug code and drivers I don't' use... Regards, Richard W.

3 3

RE: [U-Boot-Users] How to generalize SDRAM support for MPC5200 an d MGT5100?
by Jonas Mark-r50740 05 Jul '04

05 Jul '04

Reinhard, > It DID appear on the list. Good. My mistake was assuming I would still get a copy of the post although I put myself on CC. > However what is the benefit of putting not even a dozen > statements for the standard case into an extra file? Not to > mention the extra work to be done if there are two banks of > SDRAM/DDRAM present? I am not able to follow you here. Do you want to say here that the existing code is to simple to be generalized? In that case I disagree. And that people copy it 1:1 proofs that in regards that they do not write their own version. Or do you want to say that if the code would be specific for each board it could be much shorter? Here I agree but I think having generic code which makes porting U-Boot to a new platform is also worth something. If you want to be quick, take the generic code and if you are using an already support SDRAM you do not even need to calculate the timing parameters. If you want to squeeze out the very last byte in regards of code size you can take it as a guide and delete the constant parts. Looking at how Wolfgang wrote the original IceCube/Lite5x00 code I guess he prefers generic, bank and size detecting code over a specialized version. But I guess I haven't understood at all what you wanted to say because your Top5200.h states that you want to read the SDRAM configuration from VPD (EEPROM?) later. So your code would also benefit from a generic piece of initialization code fed with this data. Please detail your comments. Regards Mark

1 0

[U-Boot-Users] down() and up() not found
by Vladimir_Levertov＠mksinst.com 05 Jul '04

05 Jul '04

Hello, I use ELDK with RTAI patch installed on MPC850. I attempted writing a regular Linux driver (independent from RTAI calls) using down()/up() functions. When I attempted to load insmod to install my module I received error "unresolved symbols" for these calls. I assume some module should be added ELDK configuration. But, may be, the problem is in RTAI extension? Thanks. Vlad,

2 1

AW: [U-Boot-Users] How to generalize SDRAM support for MPC5200 and MGT5100?
by Reinhard Meyer 05 Jul '04

05 Jul '04

Hello, It DID appear on the list. However what is the benefit of putting not even a dozen statements for the standard case into an extra file? Not to mention the extra work to be done if there are two banks of SDRAM/DDRAM present? -----Ursprüngliche Nachricht----- Von: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] Im Auftrag von Jonas Mark-r50740 Gesendet: Montag, 5. Juli 2004 16:39 An: u-boot-users(a)lists.sourceforge.net Cc: Jonas Mark-r50740 Betreff: [U-Boot-Users] How to generalize SDRAM support for MPC5200 and MGT5100? I sent the email below 01-July-2004 but it never appeared on the mailing list. So I give it another try. -- Hello, while porting U-Boot to Total5200 I thought that it would be nice if all MPC5200 and MGT5100 platforms could share their SDRAM initialization code. In fact this is already done but by means of code duplication. So far most people (everybody?) simply copied the board/icecube/icecube.c and took it SDRAM init code unchanged. And if the SDRAM chips themselves were matching the appropriate mt4*-75.h file was copied as well. So how can we move the SDRAM init functions from the board directory to the drivers or the cpu/mpc5xxx directory? (I think cpu/mpc5xxx would be the better match) In the Total5200 port I already went half way but taking the SDRAM init functions out from board/total/total5200.c to board/total5200/sdram.*. I did not put it into cpu/mpc5xxx because if I did so I wanted to have a smart solution in regards to coupling that with the SDRAM parameter includes (mt48lc16m16a2-75.h, mt46v16m16-75.h and mt48lc32m16a2-75.h). Does anybody have an idea how we can make this generic for all MPC5200 and MGT5100 boards? Regards Mark

1 0

[U-Boot-Users] How to generalize SDRAM support for MPC5200 and MGT5100?
by Jonas Mark-r50740 05 Jul '04

05 Jul '04

I sent the email below 01-July-2004 but it never appeared on the mailing list. So I give it another try. -- Hello, while porting U-Boot to Total5200 I thought that it would be nice if all MPC5200 and MGT5100 platforms could share their SDRAM initialization code. In fact this is already done but by means of code duplication. So far most people (everybody?) simply copied the board/icecube/icecube.c and took it SDRAM init code unchanged. And if the SDRAM chips themselves were matching the appropriate mt4*-75.h file was copied as well. So how can we move the SDRAM init functions from the board directory to the drivers or the cpu/mpc5xxx directory? (I think cpu/mpc5xxx would be the better match) In the Total5200 port I already went half way but taking the SDRAM init functions out from board/total/total5200.c to board/total5200/sdram.*. I did not put it into cpu/mpc5xxx because if I did so I wanted to have a smart solution in regards to coupling that with the SDRAM parameter includes (mt48lc16m16a2-75.h, mt46v16m16-75.h and mt48lc32m16a2-75.h). Does anybody have an idea how we can make this generic for all MPC5200 and MGT5100 boards? Regards Mark

1 0

RE: [U-Boot-Users] [PATCH] Total5100 and Total5200 platform suppo rt
by Jonas Mark-r50740 05 Jul '04

05 Jul '04

> Can you please fix this patch to use the standard console > device mechanism of U-Boot? Instead of introducing a new > "console" variable. the standard mechanism of assigning to > the stdin / stdout / stderr streams should be used. Done. Attached is the patch to the patch. Additionally the patch fixes a problem with the environment not being placed correctly (lowboot and highboot positions interchanged). The other boards should be fixed by adding the setenvs to the CONFIG_PREBOOT as well. As far as I am concerned you can delete the "console" variable from cfg_console.c.

1 0