January 2005 - U-Boot

[U-Boot-Users] Questions about startup code for S3C44B0 CPU-core
by Alex Zu 13 Jan '05

13 Jan '05

Hi Andrea, thank you for your explanation but the stacks of EXCEPTION MODEs which we discussed about is still not very clear. U-boot here does not use interrupts,so there is no need for such initialization for interrupts,but we can't insure that there is no core exception.In case of these exception,the system may go wrong.So I think that we should initialize the stacks for those exceptions. And there is no initialization in linux, either.What should linux do in case of these exceptions. So there is the initialization in other common start codes of s3c44b0x. Do you think is my comprehension right? Why did U-boot not make the initialization? Regards, Alex Zu

1 0

Re: [U-Boot-Users] ARM Integrator AP patch 2
by jean-paul.saman＠philips.com 13 Jan '05

13 Jan '05

Made the patch specific to a board/cpu combination as suggested by Peter Pears. Starting U-boot directly from the flash on the ARM integrator ommitted setting of the Core Module control register flag that remaps SSRAM to the base memory address 0x0000000. The problem surfaces when the ARM core (920T in my case) is mounted on a motherboard.(Integrator AP) and the bootloader started from flash. Starting the bootloader from the ARM debugger does not reveal this problem. It automatically sets this bit by default and explains why some people did not see the problem. Added documentation to the README file that describes that the options CONFIG_CM9x0, CONFIG_INTEGRATOR and CFG_INTEGRATOR_CM_REMAP should be defined to turn this behaviour on. Kind greetings, Jean-Paul Saman Philips Semiconductors CTO/RTG Building: WDA Philips HighTech Campus tel: +31 (0)40 27 45131 jean-paul.saman+FromInterNet(a)philips.com Sent by: u-boot-users-admin(a)lists.sourceforge.net 12-01-2005 14:46 To: u-boot-users(a)lists.sourceforge.net cc: (bcc: Jean-Paul Saman/EHV/SC/PHILIPS) Subject: [U-Boot-Users] ARM Integrator AP patch Classification: Unclassified Starting U-boot directly from the flash on the ARM integrator ommitted setting of the Core Module control register flag that remaps SSRAM to the base memory address 0x0000000. The problem surfaces when the ARM core (920T in my case) is mounted on a motherboard.(Integrator AP) and the bootloader started from flash. Starting the bootloader from the ARM debugger does not reveal this problem. It automatically sets this bit by default and explains why some people did not see the problem. Here is the patch please apply and/or comment on it. Kind greetings, Jean-Paul Saman Philips Semiconductors CTO/RTG Building: WDA Philips HighTech Campus tel: +31 (0)40 27 45131 [attachment "u-boot-12012005-integratorap-jpsaman-1.patch" deleted by Jean-Paul Saman/EHV/SC/PHILIPS]

1 1

RE: [U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint
by Peter Pearse 13 Jan '05

13 Jan '05

Hi I am not convinced drivers/cfi.flash.c performs correctly on the VersatilePB board - I am currently working on a patch..... I believe:: static int flash_full_status_check (flash_info_t * info, flash_sect_t sector, ulong tout, char *prompt) { int retcode; retcode = flash_status_check (info, sector, tout, prompt); switch (info->vendor) { case CFI_CMDSET_INTEL_EXTENDED: case CFI_CMDSET_INTEL_STANDARD: if ((retcode != ERR_OK) && !flash_isequal (info, sector, 0, FLASH_STATUS_DONE)) { ** retcode = ERR_INVAL; should be static int flash_full_status_check (flash_info_t * info, flash_sect_t sector, ulong tout, char *prompt) { int retcode; retcode = flash_status_check (info, sector, tout, prompt); switch (info->vendor) { case CFI_CMDSET_INTEL_EXTENDED: case CFI_CMDSET_INTEL_STANDARD: if ((retcode != ERR_OK) || !flash_isequal (info, sector, 0, FLASH_STATUS_DONE)) { ** retcode = ERR_INVAL; But perhaps only on VersatilePB. Regards Peter

1 0

[U-Boot-Users] REPOST: MII Support for Non-PCI dec21143 Clone.
by Rodel Miguel 13 Jan '05

13 Jan '05

Hi All, I am really clueless about this. The board manufacturer (ARM926EJ-S) suggests that its Fast Ethernet MAC is a dec21140/21143 clone. However, the board only has MII interface on its MAC Control Register. This means that it's dec21143 clone only provides MII interfaces. The MAC Control Registers have somewhat similar interfaces with the MII ports of the dec21143. Now, please help me with these: 1. Are there direct mapping of the PCI Control Registers of the dec21143 to its MII Interfaces? I was trying to make sense of the dc21143.c driver's PCI interfaces with MII interfaces, but I could not make any useful information from it. 2. Are there minimal configuration routines for MII interfaces similar to dec21143? Thank you very much for your time. Best Regards, Rodel

1 0

RE: [U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint
by Nghiem, Tien 13 Jan '05

13 Jan '05

Hi, You can you use the CFI driver in /u-boot-1.1.1/drivers/cfi_flash.c. it's generic and working. I have used it with these boards: IceCube(MPC5200) and EP8260 without modification. Tien -----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: Wednesday, January 12, 2005 11:55 AM To: Peter Asemann Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint In message <41E537A8.8050006(a)web.de> you wrote: > Im writing my own flash.c for "my" custom board in the moment. > That's why I'm trying to understand what the flash.c does. > I thought I got it when I encountered the following problem examining > board/fads/flash.c There must ne some strange fascination about the FADS port. I really wonder why everybody is picking one of the most complicated and poroblematic ports... Pleas ehave a loot at least at some other drivers, too. > All functions in there seem to be written to handle 4x8bit flash banks. SO look for other flash drivers, or maybe even for the generic CFI driver. > I'd be very happy if someone could give me a hint what I missed or what > I got wrong or why it must be that way though. Forget what the FADS is doing. Think about what is needed for your own hardware, and implement this. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de The high cost of living hasn't affected its popularity. ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

5 6

[U-Boot-Users] PCMCIA Networking w/u-boot-1.1.1+
by Craig A. Vanderborgh 13 Jan '05

13 Jan '05

Hello Everyone: We have become quite interested in using u-boot's tftp & dhcp features. Unfortunately, our custom board has only a PCMCIA slot (no ethernet interface). So if we are to use networking at all, we'll have to do it with PCMCIA cards. What is the status of PCMCIA networking in u-boot? I have looked through the sources and it seems that current PCMCIA functionality is limited to ATA flash cards at the moment. If this is so, what would we have to do to get PCMCIA networking running in u-boot? I am not put off by working on PCMCIA drivers - I have already done a lot of PCMCIA net driver work this month, so a little bit more isn't going to kill me. We need to get NE2000 working first, and then Cisco/Aironet wireless working after that. If at all possible, please say a few words about what would have to be done where in u-boot to make this happen. I am first and foremost interested in doing this job correctly so that I can submit patches to Wolfgang et al. Thanks in advance, craig vanderborgh voxware incorporated

2 1

Re: [U-Boot-Users] PCMCIA Networking w/u-boot-1.1.1+
by Michael Richardson 13 Jan '05

13 Jan '05

-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Craig" == Craig A Vanderborgh <craigv(a)voxware.com> writes: Craig> I am not put off by working on PCMCIA drivers - I have already done a lot of Craig> PCMCIA net driver work this month, so a little bit more isn't going to kill Craig> me. We need to get NE2000 working first, and then Cisco/Aironet wireless Craig> working after that. If at all possible, please say a few If you use a 16-bit PCMCIA, or keep a 32-bit card in 16-bit mode, then you can probably use a good ole polled-mode ne2000.c. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQeXKl4qHRg3pndX9AQGK8QP+Irv8nWeed98nVlfzkHppuF3rPiBgcMPF f6bQzE2hUcLFClNZDTfA1wJwpFM7IO9PBFIu1HqKXSuQP741W2eKaIV+2F3A8uiG NiigKS61+hmQyUh3TSA/yRu0KBYf+vENA6Zzl5F/w7D4h/bFZCsQbboln6dDZRCN cqKzz/oFdu0= =+h01 -----END PGP SIGNATURE-----

1 0

RE: [U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint
by Nghiem, Tien 12 Jan '05

12 Jan '05

I can return your question: why does the CFI exist?. Have a look at the u-boot-1.1.2/board/ppm8260/strataflash.c that is an example for a port that "only" uses the cfi_flash.c. Good luck Tien -----Original Message----- From: u-boot-users-admin(a)lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Peter Asemann Sent: Wednesday, January 12, 2005 2:34 PM To: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint Nghiem, Tien wrote: > Hi, > > You can you use the CFI driver in /u-boot-1.1.1/drivers/cfi_flash.c. it's generic and working. I have used it with these boards: IceCube(MPC5200) and EP8260 without modification. Ahh... thanks for the hint. But anyway... the u-boot readme says an own flash.c was a minimum requirement for a port. If the generic driver works, why do people write customs flash.c's at all? All modern flash chips seem to support CFI anyway. Is there an example for a port that "only" uses the cfi_flash.c so I can take a look on it? Best regards, Peter Asemann ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

[U-Boot-Users] Patch: allow fixed ports for TFTP (rc4)
by Jerry Van Baren 12 Jan '05

12 Jan '05

Hi Wolfgang, try four on the patch attached. The changes here are: * Use the approved environment variable names. * Added "tftpdstp" to allow ports other than 69 per Tolunay Orkun's recommendation. * Patch by Jerry Van Baren 12 January 2005 - Add a configuration option CONFIG_TFTP_PORT and optional env variables tftpsrcp and tftpdstp to control the ports TFTP uses. gvb Index: README =================================================================== RCS file: /cvsroot/u-boot/u-boot/README,v retrieving revision 1.117 diff -p -u -r1.117 README --- README 9 Jan 2005 23:16:42 -0000 1.117 +++ README 12 Jan 2005 19:02:09 -0000 @@ -1480,6 +1480,26 @@ The following options need to be configu When SystemACE support is added, the "ace" device type becomes available to the fat commands, i.e. fatls. +- TFTP Fixed UDP Port: + CONFIG_TFTP_PORT + + If this is defined, the environment variable tftpsrcp + is used to supply the TFTP UDP source port value. + If tftpsrcp isn't defined, the normal pseudo-random port + number generator is used. + + Also, the environment variable tftpdstp is used to supply + the TFTP UDP destination port value. If tftpdstp isn't + defined, the normal port 69 is used. + + The purpose for tftpsrcp is to allow a TFTP server to + blindly start the TFTP transfer using the pre-configured + target IP address and UDP port. This has the effect of + "punching through" the (Windows XP) firewall, allowing + the remainder of the TFTP transfer to proceed normally. + A better solution is to properly configure the firewall, + but sometimes that is not allowed. + - Show boot progress: CONFIG_SHOW_BOOT_PROGRESS @@ -2432,6 +2452,12 @@ Some configuration options can be set us Useful on scripts which control the retry operation themselves. + tftpsrcport - If this is set, the value is used for TFTP's + UDP source port. + + tftpdstport - If this is set, the value is used for TFTP's UDP + destination port instead of the Well Know Port 69. + vlan - When set to a value < 4095 the traffic over ethernet is encapsulated/received over 802.1q VLAN tagged frames. Index: net/tftp.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/net/tftp.c,v retrieving revision 1.9 diff -p -u -r1.9 tftp.c --- net/tftp.c 15 Apr 2004 21:48:55 -0000 1.9 +++ net/tftp.c 12 Jan 2005 19:02:10 -0000 @@ -301,6 +301,10 @@ TftpTimeout (void) void TftpStart (void) { +#ifdef CONFIG_TFTP_PORT + char *ep; /* Environment pointer */ +#endif + if (BootFile[0] == '\0') { IPaddr_t OurIP = ntohl(NetOurIP); @@ -354,7 +358,16 @@ TftpStart (void) TftpServerPort = WELL_KNOWN_PORT; TftpTimeoutCount = 0; TftpState = STATE_RRQ; + /* Use a pseudo-random port unless a specific port is set */ TftpOurPort = 1024 + (get_timer(0) % 3072); +#ifdef CONFIG_TFTP_PORT + if ((ep = getenv("tftpdstp")) != NULL) { + TftpServerPort = simple_strtol(ep, NULL, 10); + } + if ((ep = getenv("tftpsrcp")) != NULL) { + TftpOurPort= simple_strtol(ep, NULL, 10); + } +#endif TftpBlock = 0; /* zero out server ether in case the server ip has changed */

1 0

[U-Boot-Users] .../board/fads/flash.c confuses me - give me a hint
by Peter Asemann 12 Jan '05

12 Jan '05

Im writing my own flash.c for "my" custom board in the moment. That's why I'm trying to understand what the flash.c does. I thought I got it when I encountered the following problem examining board/fads/flash.c All functions in there seem to be written to handle 4x8bit flash banks. As indication for that are - in my opinion - the QUAD_ID macro in line 41+ and the fact that 0xAAAAAAAA, 0x55555555 and 0x90909090 and not 0x00AA00AA, 0x00550055 and 0x00900090 are written in the auto select command sequence, beginning in line 227 (u-boot 1.1.2). But they do write to the addresses which are typical - my fine flash datasheet says - for word-mode flash access. So the data written seems not to fit the addresses written to. I'd be very happy if someone could give me a hint what I missed or what I got wrong or why it must be that way though. Peter Asemann

2 3