This is the step-by-step progress record. It started as a SPI programming record, but then I recorded all the steps here. -- (C) Wojtek Skulski 2006. All rights reserved. -- File: Progress_record.txt ------------------------------------------------------------------------- Read SPI_Flash_programming.txt in the CPLD code directory ------------------------------------------------------------------------- NOTE: What Xilinx calls MCS format, Blackfin/uCLinux folks call HEX format. Therefore: -- Produce your files in HEX format under uCLinux. -- Tell XSPI that this is MCS format. ------------------------------------------------------------------------- The Xapp800 package contains *two* utilities, x_spi.exe and xspi_at.exe. It turns out that xspi_at has more features and is faster. I was later advised by Xilinx that a newer xspi is distributed with Xapp445 package. ------------------------------------------------------------------------- References about SPI memory programming: 1. Xilinx Application Note Xapp445. <-- The most important. XAPP445 Configuring Spartan-3E Xilinx FPGAs with SPI Flash Includes the software xspi.exe utility to program SPI flash. 2. Xilinx Application Note Xapp800. <-- Older version of Xapp445. Used for testing, but not recommended because Xapp445 is better. 3. Circuit Cellar ISSUE 84 July 1997 Using Serial EEPROMs—Part 1: General Principles by Jan Axelson, p. 74. PDF copy available from www.lvr.com, see below. 4. Circuit Cellar ISSUE 85 August 1997 Using Serial EEPROMs—Part 2: Putting It All Together by Jan Axelson, p. 70. Both parts of the article by J.Axelson are available as one PDF file: www.lvr.com/files/seeprom.pdf ------------------------------------------------------------------------- The CPLD code was tested with Xapp800 software and Xilinx ISE 6.3 SP 3 installed under Windows 2000. The parallel cable drivers and port setup that worked for CPLD iMPACT programming, have both proven insufficient for SPI programming. In particular, the following changes had to be made: Worked with ISE 6.3 ---> had to be changed for Xapp800 utility --------------------------------------------------------------- ECP parallel port | bidirectional parallel port Default ECP settings | Legacy PnP enabled, never use interrupt ISE port drivers | Jungo WinDriver (see below) I was able to program the CPLD using the ECP port and parallel port drivers that ISE 6.3 put in place when it was installed. However, xspi.exe refused to work. I had to change the port to "bidirectional" and change port settings, as described in the other file Readme.txt. The Jungo WiDriver had to be installed after receiving the following message from xspi: Error: Invalid parallel port address detected. Install or start Xilinx Windriver device driver. To install driver, download and run ftp.xilinx.com/pub/utilities/M1_pc/pc3driver.exe, or search for "Answer record 13360" in AnswerDatabase in support.xilinx.com. So I installed the WinDriver. This failed to make xspi happy. The error message persisted. So I searched for "Answer record 13360". The answer 13360 was hard to find. Finally, found it after searching for "Xilinx 13360" in http://www.xilinx.com/support/mysupport.htm. After more searching and reading Xilinx Answers Database, changed the parallel port settings to the following: Legacy Plug-and-Play Enabled Never use an interrupt Changed Port in BIOS to "bidirectional". This made xspi happy. ------------------------------------------------------------------------- ========= Testing record using Xapp800 software =========== ------------------------------------------------------------------------- This record shows that things basically work with Xapp800 software. However, one should use the newer Xapp445 version of xspi. NOTE: I have not programmed any meaningful data yet into the SPI flash. The tests merely show that the part could be programmed, and the xspi utility was happy. The real test will be programming the Linux kernel into the SPI flash and booting the Blackfin chip. I used a file with dummy data. The file was in MCS format, as required by Xapp800 software. The newer Xapp445 software can also use the HEX format. Note that the "synchronization words" are not present in Blackfin files, and therefore should not be checked by xspi. The Xapp445 software has a switch to turn off the check. ----------------------------------------------------------------------- Verifying the blank M25P32. C:\Xapp\XappCPLD\xapp800>xspi_at -spi_b 8192 -o test.txt => Overwrite [test.txt] or Exit (o/e) ? o x_spi(tm) Version 1.08c (c) 2003-2004 Xilinx, Inc. Xilinx SPI Programming Utility Start : Sat Mar 18 21:27:17 2006 Blank checked [8388608] of [8388608] bytes (0 errors) --> Total non-FF bytes [0] (see [test.txt]) Finish : Sat Mar 18 21:37:58 2006 Elapsed clock time (00:10:41) = 641 seconds ----------------------------- Programming the SPI memory M25P32. C:\Xapp\XappCPLD\xapp800>xspi_at -spi_pv -i untitled.mcs -l test.log -o test.txt => Overwrite [test.log] or Exit (o/e) ? o => Overwrite [test.txt] or Exit (o/e) ? o x_spi(tm) Version 1.08c (c) 2003-2004 Xilinx, Inc. Xilinx SPI Programming Utility Start : Sat Mar 18 22:58:57 2006 Programmed [234456] of [234456] bytes (w/ polling) Verified [234456] of [234456] bytes (0 errors) --> Total byte mismatches [0] (see [test.txt]) Finish : Sat Mar 18 22:59:43 2006 Elapsed clock time (00:00:46) = 46 seconds ----------------------------------------------------------------------- This means 5097 bytes per second, or roughly 5 kB/sec. ===> 5 MBytes = 1000 seconds = about 1/3 hour for 5 MB. ----------------------------------------------------------------------- ------------------------------------------------------------------------- ========= Testing record using Xapp445 software =========== ------------------------------------------------------------------------- I used another Win2k machine. Checked with System->Device_Manager that LPT1 port settings are ECP and "Never use an interrupt". Started DOS prompt. Changed prompt to ? Very Long Prompt> prompt ? ? <--- now this is the prompt Started the BlackStamp board, connected Digilent cable. Enabled JTAG, (used JTAG_ena) on the board. Verified that iMPACT can see the CPLD. Then disabled JTAG. BlackStamp DIP switch settings. (1..5) are "CPLD switch". 6 is JTAG_ena. (7..8) are Blackfin BMODE 0,1. 1 2 3 4 5 6 7 8 <-- switch 0 0 0 0 1 0 0 0 <-- ON/OFF Note: switch #5 enables communication with SPI flash over Xilinx JTAG port. ---------------------------------------------------------------------------- -- Checking the communication with the SPI device. Note: the CPLD is already programmed according to XAPP800/XAPP445. The communication with SPI flash is enabled in hardware, see above. ?xspi -accept_notice -spi_dev m25p32 Start : Sat Jun 17 17:43:58 2006 ==> Checking SPI device [STMicro_M25P32_ver_00100] ID code(s) - density = [4194304] bytes = [33554432] bits - mfg_code = [0x20] - memory_type = [0x20] - density_code = [0x16] +-----------------------------------------+ | Device ID code(s) check ====> [ OK ] | +-----------------------------------------+ Finish : Sat Jun 17 17:43:59 2006 Elapsed clock time (00:00:01) = 1 seconds ---------------------------------------------------------------------------- -- Checking whether dis-abling the communication in hardware will disrupt the software. Flipped switch #5 to '0'. ?xspi -accept_notice -spi_dev m25p32 Start : Sat Jun 17 18:00:19 2006 ==> Checking SPI device [STMicro_M25P32_ver_00100] ID code(s) - density = [4194304] bytes = [33554432] bits - mfg_code = [0x00] ==> error: expected [0x20] Finish : Sat Jun 17 18:00:19 2006 Elapsed clock time (00:00:00) = 0 seconds Conclusion: yes, indeed. The communication was cut. Good! ---------------------------------------------------------------------------- Erasing the SPI flash before programming it. ?xspi -accept_notice -spi_dev m25p32 -spi_e Start : Sat Jun 17 18:50:45 2006 ==> Checking SPI device [STMicro_M25P32_ver_00100] ID code(s) - density = [4194304] bytes = [33554432] bits - mfg_code = [0x20] - memory_type = [0x20] - density_code = [0x16] +-----------------------------------------+ | Device ID code(s) check ====> [ OK ] | +-----------------------------------------+ => Operation: Erase = elapsed SPI erase time [26] secs (iteration 26 of max 80) Finish : Sat Jun 17 18:51:11 2006 Elapsed clock time (00:00:26) = 26 seconds ---------------------------------------------------------------------------- Programming SPI flash with the file app.hex I built app.hex by running the script in the directory ~/u-boot_1.1.3/tools/bin2ldr ~/u-boot_1.1.3/tools/bin2ldr <-- folder $ sh runme.sh <-- ran the script Then I copied the file app.hex to the Windows side and ran the xspi as follows ?xspi -accept_notice -mcs -skip_syncword_check -spi_dev m25p32 -i app.hex -spi_p Start : Sat Jun 17 18:53:53 2006 ==> Checking SPI device [STMicro_M25P32_ver_00100] ID code(s) - density = [4194304] bytes = [33554432] bits - mfg_code = [0x20] - memory_type = [0x20] - density_code = [0x16] +-----------------------------------------+ | Device ID code(s) check ====> [ OK ] | +-----------------------------------------+ => Operation: Program only with file [app.hex] Programmed [111552] of [111552] bytes (w/ polling) Finish : Sat Jun 17 18:53:58 2006 Elapsed clock time (00:00:05) = 5 seconds ---------------------------------------------------------------------------- Changed DIP switch settings. Disabled SPI flash access. Changed BMODE 1,0 to 11 --> SPI master. The minicom settings are 57600 8N1 NOR. Verified that it works with ADI Stamp. BlackStamp DIP switch settings. (1..5) are "CPLD switch". 6 is JTAG_ena. (7..8) are Blackfin BMODE 0,1. 1 2 3 4 5 6 7 8 <-- switch 0 0 0 0 0 0 1 1 <-- ON/OFF Connected the serial cable, started minicom, pressed the Reset button. LED3 blinks briefly. (With other BMODE settings it does not blink.) LED (3) <= NOT SPI_FLASH_PF; -- from BF, SPI flash access Nothing happens in the minicom. Also, the LED 3 blinks too briefly. ---------------------------------------------------------------------------- Starting to troubleshoot. I know the following is working: The direction SPI_SI, SPI_SO is OK. Otherwise I would not have communication. However... I am directing SPI --> JTAG directly. But in case of BF, I am doing an OR with SD lines inside the CPLD. This is wrong.... I should not OR. Possible problems: SPI data to BF may be wrong because I am using OR inside CPLD. Changed CPLD code to remove OR of SPI data and SD data. Now the blinking pattern makes more sense. The program is being loaded. It takes a few seconds. So I removed one possible problem. But there is no response from minicom. I guess the boot loader is messed up. ---------------------------------------------------------------------------- 06/18/06 Possible problems: The U-Boot was built for M25P64 (128 sectors), but I am using M25P32 (64 sectors). This however only matters when the U-Boot is alrady running. The sectors are in the SPI driver spi.c. The U-Boot will be able to talk to SPI flash with that many sectors, but it must be running first. So this is not the main problem. In U-Boot, the memory layout was for BF533, but I am using BF532. In U-Boot, I defined CONFIG_STAMP (because of the Common Flash Interface driver), what may have selected wrong memory layout in cpu.h PF flags should not be the problem, because the PF2 is used in hardware before any code is loaded. (PF2 is used to select the SPI chip as soon as I hit the RESET button. Of course, the BMODE switch has to set the proper way.) Other possibilities: CPLD code is messed up. Not sure if it passes PF2 to the SPI chip. To be checked. To Do: Modify the CPLD code. Blink LED when reading the SPI code. (I looked at the CPLD code. This is actually done....) ---------------------------------------------------------------------------- Maybe the SPI loading address is wrong? XSPi loads at addr = 0. It ignores any offsets that may be there in the HEX file. According to EE-240 (BF533 Booting Modes) BF on-chip ROM expects to find the boot image in SPI addr = 0. Same as XSPI writes to SPI flash. So this should work OK. ---------------------------------------------------------------------------- Before we can use SDRAM, it has to be initialized. How is this done? The LDR file should initialize SDRAM. The LDR is the "startup code". Now, how is SDRAM initialized? Is it initialized right? If SDRAM is not inited right, then the image will not be loaded correctly to SDRAM. ---------------------------------------------------------------------------- Let me find the file which initializes SDRAM. Here is how the script runme.sh was run. It follows, that init_sdram is to be found in folder ../../cpu/bf533/ File name init_sdram.S ---> compiled into init_sdram.o $ pwd /home/uclinux/u-boot_1.1.3/tools/bin2ldr $ sh runme.sh make distclean make[1]: Entering directory `/home/uclinux/u-boot_1.1.3/tools/bin2ldr' rm bin2ldr bin2ldr.o -f rm init_sdram.o init_sdram init_sdram.bin -f rm jump.o jump jump.bin -f make[1]: Leaving directory `/home/uclinux/u-boot_1.1.3/tools/bin2ldr' rm app.bin app.ldr app.hex -f gcc -g -c bin2ldr.c gcc bin2ldr.o -o bin2ldr bfin-uclinux-gcc -g -c jump.S bfin-uclinux-ld -o jump -e 0x00000000 jump.o bfin-uclinux-objcopy -O binary jump jump.bin cp ../../cpu/bf533/init_sdram.o . <--- here!!! bfin-uclinux-ld -o init_sdram -e 0x00000000 init_sdram.o bfin-uclinux-objcopy -O binary init_sdram init_sdram.bin cp ../../u-boot.bin app.bin bin2ldr 1.0 (C) 2005 Analog Device rm bin2ldr bin2ldr.o -f rm init_sdram.o init_sdram init_sdram.bin -f rm jump.o jump jump.bin -f All this happening in the following folder $ pwd /home/uclinux/u-boot_1.1.3/tools/bin2ldr The folder contains the following files: $ ls Makefile README app.bin app.hex app.ldr bin2ldr.c bin2ldr.h jump.S runme.sh CONCLUSION: the file ../../cpu/bf533/init_sdram.o is the one that inits SDRAM. ---------------------------------------------------------------------------- 06/18/06 Let me examine init_sdram.S I looked at the file init_sdram.S. Now it becomes clear why they put conditional define symbols and init things OTHER than SDRAM. This file is also a header for the bootloader in case of serial boot from SPI. This file is being executed by the on-chip ROM boot loader. So they put stuff in there, which is contrary to the official Wiki documentation. They did so because this file is the first file to be executed when the image is loaded from SPI. This file is initing SDRAM. It is the "preamble" LDR file. So it must be initing SDRAM correctly, otherwise the U-Boot cannot be loaded SPI --> SDRAM. At first sight, it seems I need to #define CONFIG_SERIAL_STAMP in order for this file to work correctly. At the first glance, symbol CONFIG_SERIAL_STAMP means "STAMP which is booting from the SPI flash". After looking in more detail: not true. CONFIG_SERIAL_STAMP is not critical. The file init_sdram.S is used as the "preamble" file by the script runme.sh. The script does not depend on CONFIG_SERIAL_STAMP. This symbol is not critical. Reminder: I also need to #define CONFIG_STAMP in order for the CFI parallel flash to work correctly. CONCLUSIONS: 1) #define CONFIG_SERIAL_STAMP --> not critical when booting from SPI flash 2) #define CONFIG_STAMP --> necessary when using parallel flash (using for anything, not only booting) 3) script runme.sh is the one which uses init_sdram.S as the "preamble" which initializes SDRAM. WARNING: CONFIG_STAMP will force the memory to be 128 MB. If the board has anything else than 128 MB, this is WRONG! Deciphering this logic required reading EE-240 "BF533 Booting Process". What a monumental mess. There should be a comment in the file explaining what it is doing and why. ---------------------------------------------------------------------------- 06/18/06 After implementing the above, still no response in minicom. 1. Used CONFIG_STAMP --> can use CFI parallel flash 2. Used CONFIG_SERIAL_STAMP --> does something in init_sdram.S 3. patched cpu.c to define the mem layout with 64 MB (to fix the 128MB problem) Still no boot. To Do: CPLB blocks. How to set these up? Try using 32 MB mem layout? (I have 64 MB...) Is the MCS format OK? Can the switch -mcs be used for XSPI with .hex files? What is CONFIG_SERIAL_STAMP really doing? Is it critical? Is SDRAM initialized correctly? ---------------------------------------------------------------------------- 06/19/06 Commented out CONFIG_SERIAL_STAMP. It is setting SPI to high rate in init_sdram.S. We do not need SPI high rate now. Changed cpu.c. Both SDRAM page 14 and page 15 should be 64 MB. Previosly I forgot page 14. Now both are set in cpu.c. Notice, this is cpu.c, not init_sdram.S ! This code is not in the "init block". (The init block is just the init_sdram.S.) /* bstamp532 added by WS */ #if defined(CONFIG_BSTAMP532) {0x03C00000, SDRAM_IKERNEL}, /*SDRAM_Page14 */ #endif /* bstamp532 added by WS */ #if defined(CONFIG_BSTAMP532) {0x03C00000, SDRAM_DKERNEL}, /*SDRAM_Page15 */ #endif How did I know which values to use? I copied values used for BF537 Stamp which has 64 MB, same as BlackStamp. Note, if I had 8, 16, or 32MB on board then I would still not know how to setup these memory pages. ---------------------------------------------------------------------------- 06/19/06 SDRAM is now correctly initialized. So this was the problem! ============================================================ After doing the above, partial success. The following shows in minicom after pressing RESET on the board. U-Boot-1.1.3-ADI-2006R1 (Jun 19 2006 - 13:38:57) CPU: ADSP BF532 Rev.: 0.3 Board: BlackStamp BF532 Support: http://blackfin.uclinux.org/ The board then hangs. But now I know SDRAM is working. It is a very powerful test. ---------------------------------------------------------------------------- 06/19/06 Fixing the messy role of the symbol CONFIG_STAMP In file ./drivers/cfi_flash.c Changed #ifdef CONFIG_STAMP to #if defined (__ADSPLPBLACKFIN__) | defined (CONFIG_STAMP) because it is the Blackfin, not the ADI Stamp, which requires ssync. I checked ADI .h files and the symbol is in all of these. I leave CONFIG_STAMP in place for those poor souls who used this stupidity. I have not removed CONFIG_STAMP from my bf532.h yet. ---------------------------------------------------------------------------- 06/19/06 After doing the above, recompiling, and reloading, the result is the same. So the changes are OK. (But CONFIG_STAMP is still #defined in bstamp532.h.) ---------------------------------------------------------------------------- 06/19/06 In ./board/bstamp532 changed num of sectors in spi.c from 128 to 64 (i.e., SPI flash chip M25P64 --> M25P32, which is the one which I have on board). Recompile, reloaded to SPI flash. Same result. I.e., partial success --> hang. ---------------------------------------------------------------------------- 06/19/06 I found the function which prints these messages and returns. It is in file bstamp532.c, name of the function "checkboard". It is called from ./lib_blackfin/board.c, function name "board_init_f". Here it seems to hang. I am adding some trace printouts. ---------------------------------------------------------------------------- Defining DEBUG breaks the compilation. Awful. It happens in board_init_r. It happens when CONFIG_SOFT_I2C is not defined in bstamp532.h (why should this be???) ---------------------------------------------------------------------------- Added the following to board.c #include /*WS 06/19/06 to fix the i2c_init not declared*/ Moved the function init_func_i2c to top of the file because it was used before it was declared. Now it compiles. ---------------------------------------------------------------------------- Fixed another bug: a function call was display_global_data (void). The keyword "void" cannot be used in a function call. So many bugs in one file ./lib_blackfin/board.c Now it compiles with DEBUG. ---------------------------------------------------------------------------- It hangs in rtc_init. So I commented the rtc_init out. #if defined(CONFIG_RTC_BF533) && (CONFIG_COMMANDS & CFG_CMD_DATE) printf(" Before rtc_init.\n"); /* rtc_init (); it hangs here WS*/ #endif ---------------------------------------------------------------------------- Now it went further. Notice that SDRAM Bank size is WRONG! This is printed by initdram from file .c, but this is just a fake. It has no meaning. printf("Bank size = %d MB\n", 128); <--- HARDWIRED number. So the printout saying "128 MB" was meaningless. U-Boot-1.1.3-ADI-2006R1 (Jun 19 2006 - 21:16:26) CPU: ADSP BF532 Rev.: 0.3 Board: BlackStamp BF532 Support: http://blackfin.uclinux.org/ Caches enabled. Returning. Before rtc_init. Before timer_init. Clock: VCO: 250 MHz, Core: 250 MHz, System: 50 MHz SDRAM: SDRAM attributes: tRCD:1 Cycles; tRP:1 Cycles; tRAS:3 Cycles; tWR:2 Cycles; CAS Latency:3 cycles SDRAM Begin: 0x0 Bank size = 128 MB <===== WRONG but harmless, see above 64 MB The following lines are from functions in ./drivers/cfi_flash.c flash detect cfi <===== flash_detect_cfi fwc addr 20000000 cmd f0 f0 8bit x 8 bit <== function flash_write_cmd fwc addr 20000055 cmd 98 98 8bit x 8 bit is= cmd 51(Q) addr 20000010 is= ae 51 <== function flash_isequal fwc addr 20000000 cmd f0 f0f0 16bit x 8 bit fwc addr 200000aa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr 20000020 is= 0000 5151 fwc addr 20000000 cmd f0 00f0 16bit x 16 bit fwc addr 200000aa cmd 98 0098 16bit x 16 bit is= cmd 51(Q) addr 20000020 is= 0000 0051 fwc addr 20000000 cmd f0 f0f0f0f0 32bit x 8 bit fwc addr 20000154 cmd 98 98989898 32bit x 8 bit is= cmd 51(Q) addr 20000040 is= 00000000 51515151 fwc addr 20000000 cmd f0 00f000f0 32bit x 16 bit fwc addr 20000154 cmd 98 00980098 32bit x 16 bit is= cmd 51(Q) addr 20000040 is= 00000000 00510051 fwc addr 20000000 cmd f0 000000f0 32bit x 32 bit fwc addr 20000154 cmd 98 00000098 32bit x 32 bit is= cmd 51(Q) addr 20000040 is= 00000000 00000051 WARNING: flash_make_cmd: unsuppported LittleEndian mode fwrite addr 20003066 cmd f0 fffffffffffffffffffff0 64 bit x 8 bit The last line was from ./drivers/flash_write_cmd and now it hangs. Are we doing something funky with the parallel flash? (The fact that we are running this code means that SPI flash is working, and the board is booting from SPI flash. On every step I keep re-burning the U-Boot image into the SPI flash, using the XSPI utility and Digilent cable. Read the text SPI_Flash_Programming for the exact description.) ---------------------------------------------------------------------------- 06/20/06 In file ./include/asm-blackfin/hw_irq.h Added __ADSPBF533__ to the selectors, so CONFIG_STAMP can be undefined #ifdef __ADSPBF533__ #include #endif ---------------------------------------------------------------------------- 06/20/06 The CPLB tables look suspect In file ./cpu/bf533/cpu.c the CPLB descriptor tables should have 16 entries. It is therefore essential to avoid repetitions and adding extra entries by defining CONFIG_STAMP. Therefore, I made the entries mutually exclusive: #if defined (CONFIG_STAMP) && ! defined (CONFIG_BSTAMP532) {0x07C00000, SDRAM_DKERNEL}, /*SDRAM_Page15 */ #endif #if defined(CONFIG_BSTAMP532) /* bstamp532 added by WS */ {0x03C00000, SDRAM_DKERNEL}, /*SDRAM_Page15 */ #endif ---------------------------------------------------------------------------- Fixing the CPLB tables. We have 64 MB. STAMP had 128MB. /include/asm-blackfin/cplbtab.h This file is peppered with CONFIG_STAMP and other symbols. Needs to be fixed for the 64 MB case. Take this case from BF537 case which has 64 MB. ---------------------------------------------------------------------------- I tried to turn off CFI flash testing by defining the following symbol, but this breaks the compilation. I tried this in bstamp532.h /* Try turning off CFI flash, but this breaks compilation #define CFG_NO_FLASH 1 #undef CFG_FLASH_CFI_DRIVER */ ---------------------------------------------------------------------------- 06/23/06 SUCCESS! U-Boot now goes to the very end. ======================================== So, what happened with the CPLB code? I actually did not fix it any further. See the log entry above titled "The CPLB tables look suspect". I only made sure there were 16 entries. This was not the case (I think) because some symbols created more entries than necessary (multiple lines for SDRAM page 15?) I suspect that CPLB entries are not very critical. If there is an entry for the memory beyond 64 MB, it will never generate a hit on the 64 MB board. So it means that this CPLB entry is wasted. But it will never be executed. However, the compiler has to be properly informed how much RAM is there on the board. So the various "memsize" symbols have to be correct. There are about five or six of those! This is a mess. If you tell the compiler your board has 128 MB, but in reality it has 64 MB, then some instructions may actually try accessing the non-existing memory, and then KABOOM! So, after making sure the memory size symbols are #defined correctly, U-Boot then worked. Read the Survival Guide for details, which "mem size" symbols are there and how many (too many!!!). The following is with DEBUG #defined. There are lots of trace printouts. NOTE: I am using silicon Rev. 0.3. Lower silicon revisions would not work. U-Boot-1.1.3-ADI-2006R1 (Jun 23 2006 - 17:59:20) CPU: ADSP BF532 Rev.: 0.3 Board: BlackStamp BF532 Support: http://blackfin.uclinux.org/ Caches enabled. Returning. Before rtc_init. rtc_init IS COMMENTED OUT. Before timer_init. Clock: VCO: 250 MHz, Core: 250 MHz, System: 50 MHz SDRAM: SDRAM attributes: tRCD:1 Cycles; tRP:1 Cycles; tRAS:3 Cycles; tWR:2 Cycles; CAS Latency:3 cycles SDRAM Begin: 0x0 Bank size CFG_MAX_RAM_SIZE = 67108864 bytes 64 MB Entering ./lib_blackfin/board.c board_init_r Before flash_init. (Which is in file ./drivers/cfi_flash.c). begin info->portwidth= 1 fwc addr 20000000 cmd f0 f0 8bit x 8 bit info->portwidth= 1 fwc addr 20000055 cmd 98 98 8bit x 8 bit info->portwidth= 1 is= cmd 51(Q) addr 20000010 case FLASH_CFI_8BIT is= ff 51 info->portwidth= 2 fwc addr 20000000 cmd f0 f0f0 16bit x 8 bit info->portwidth= 2 fwc addr 200000aa cmd 98 9898 16bit x 8 bit info->portwidth= 2 is= cmd 51(Q) addr 20000020 case FLASH_CFI_16BIT is= 0051 5151 info->portwidth= 2 fwc addr 20000000 cmd f0 00f0 16bit x 16 bit info->portwidth= 2 fwc addr 200000aa cmd 98 0098 16bit x 16 bit info->portwidth= 2 is= cmd 51(Q) addr 20000020 case FLASH_CFI_16BIT is= 0051 0051 info->portwidth= 2 is= cmd 52(R) addr 20000022 case FLASH_CFI_16BIT is= 0052 0052 info->portwidth= 2 is= cmd 59(Y) addr 20000024 case FLASH_CFI_16BIT is= 0059 0059 Entering ushort addr is at 20000050 info->portwidth = 2 addr[0] = 0x2 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 retval = 0x2 device interface is 2 found port 2 chip 2 port 16 bits chip 16 bits Entering ushort addr is at 20000026 info->portwidth = 2 addr[0] = 0x2 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 retval = 0x2 20000020 : 51 00 52 00 59 00 02 00 00 00 40 00 00 00 00 00 Q.R.Y.....@..... 20000030 : 00 00 00 00 00 00 27 00 36 00 b5 00 c5 00 04 00 ......'.6....... 20000040 : 00 00 0a 00 00 00 05 00 00 00 04 00 00 00 16 00 ................ 20000050 : 02 00 00 00 00 00 00 00 04 00 00 00 00 00 40 00 ..............@. 20000060 : 00 00 01 00 00 00 20 00 00 00 00 00 00 00 80 00 ...... ......... 20000070 : 00 00 3e 00 00 00 00 00 01 00 ff ff ff ff ff ff ..>............. 20000080 : 50 00 52 00 49 00 31 00 30 00 00 00 02 00 01 00 P.R.I.1.0....... 20000090 : 01 00 04 00 00 00 00 00 00 00 b5 00 c5 00 02 00 ................ manufacturer is 2 size_ratio 1 port 16 bits chip 16 bits found 4 erase regions long addr is at 2000005a info->portwidth = 2 addr[0] = 0x0 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 addr[4] = 0x40 addr[5] = 0x0 addr[6] = 0x0 addr[7] = 0x0 erase_region_count = 1 erase_region_size = 16384 long addr is at 20000062 info->portwidth = 2 addr[0] = 0x1 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 addr[4] = 0x20 addr[5] = 0x0 addr[6] = 0x0 addr[7] = 0x0 erase_region_count = 2 erase_region_size = 8192 long addr is at 2000006a info->portwidth = 2 addr[0] = 0x0 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 addr[4] = 0x80 addr[5] = 0x0 addr[6] = 0x0 addr[7] = 0x0 erase_region_count = 1 erase_region_size = 32768 long addr is at 20000072 info->portwidth = 2 addr[0] = 0x3e addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 addr[4] = 0x0 addr[5] = 0x0 addr[6] = 0x1 addr[7] = 0x0 erase_region_count = 63 erase_region_size = 65536 Entering ushort addr is at 20000054 info->portwidth = 2 addr[0] = 0x0 addr[1] = 0x0 addr[2] = 0x0 addr[3] = 0x0 retval = 0x0 <--------- here it crashes coLinux info->portwidth= 2 fwc addr 20000000 cmd f0 00f0 16bit x 16 bit Before display_flash_config FLASH: 4 MB Before flash_protect. (Parallel flash, file ./common/flash.c). flash_protect ON: from 0x20000000 to 0x2001FFFF protect on 0 protect on 1 protect on 2 protect on 3 protect on 4 Before mem_malloc_init Before malloc_bin_reloc Before spi_init_r Before env_relocate *** Warning - bad CRC, using default environment Before devices_init Before jumptable_init In: serial Out: serial Err: serial ERROR: Can't find SMC91111 at address 20300300 I2C: ready --flags:3 --board_type:0 --baudrate:e100 --have_console:1 --ram_size:0 --reloc_off:0 --env_addr:4 --env_valid:1 --bd:3f9c028 3f9c028 ---bi_baudrate:e100 ---bi_ip_addr:1e0d0c0a ---bi_enetaddr:0 50 ba cf 94 a9 ---bi_arch_number:0 ---bi_boot_params:0 ---bi_memstart:0 ---bi_memsize:4000000 ---bi_flashstart:20000000 ---bi_flashsize:400000 ---bi_flashoffset:0 --jt:3fa0160 *:3fd13f8 ### main_loop entered: bootdelay=5 ### main_loop: bootcmd="eeprom read 0x1000000 0x100000 0x180000;icache on;dcache on;bootm 0x1000000" Hit any key to stop autoboot: 0 bstamp532> bstamp532>printenv bootargs=root=/dev/mtdblock0 rw bootcmd=eeprom read 0x1000000 0x100000 0x180000;icache on;dcache on;bootm 0x1000 000 bootdelay=5 baudrate=57600 loads_echo=1 ethaddr= "do not release" ipaddr=10.12.13.30 serverip=10.12.13.20 rootpath=/checkout/uClinux-dist/romfs gatewayip=10.12.13.20 netmask=255.255.255.0 hostname=STAMP ramargs=setenv bootargs root=/dev/mtdblock0 rw nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath) addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmas k):$(hostname):eth0:off ramboot=tftpboot 0x1000000 linux;run ramargs;run addip;bootelf nfsboot=tftpboot 0x1000000 linux;run nfsargs;run addip;bootelf flashboot=bootm 0x20100000 update=tftpboot 0x1000000 app.ldr;eeprom write 0x1000000 0x0 $(filesize); stdin=serial stdout=serial stderr=serial Environment size: 811/8188 bytes bstamp532> So we went till the end and got U-Boot prompt. GOOD! ---------------------------------------------------------------------------- 06/23/06 A minor problem: coLinux was crashed by the above trace printout. Therefore, I had to start using Windows HyperTerm. Major problem: ether chip was not detected. Notes: 1. we got full trace printout. Nothing seems wrong. Yet, this very same output kills coLinux! This means minicom has a bug. 2. Ether chip not found. I suspect PF0 was not switched during detection. Wrong! It is being switched to in ./lib-blackfin/board.c in function board_init_r, near the end of the file. 3. This probably means CPLD code does not open bus switch, because ether is behind the switch on my board. See the schematic. Note added later: this problem was due to a mistake in CPLD code. A wrong CPLD pin was used to select the chip. It took quite a while to find out the mistake in the VHDL code. ---------------------------------------------------------------------------- 06/23/06 I executed "ping 10.12.13.20". This should access Ether. The LEDs did the following: LED (0) <= A2x (0); ON LED (1) <= A2x (1); ON From this it follows AMS(3,2,1,0) = 0111. Good! Ether is in AMS3 bank. So ether is being addressed in this bank. LED (2) <= NOT PAR_FLASH_PF; -- from BF, parallel flash access OFF LED (3) <= NOT SPI_FLASH_PF; -- from BF, SPI flash access OFF This is also good! Ether chip is being selected with PF0 which we see on LED2. PF0 should be HIGH for Ether --> LED2 OFF. This is what we see. So now I want to see bus switch CS# to know whether the switch has been opened. So I reprogrammed CPLD as follows: LED (4) <= NOT SWITCH_ENA_bar_local; -- is bus switch open? LED (5) <= ETHER_IRQ; -- ether interrupt to BF After executing "ping 10.12.13.20", LED4 starts pulsating (barely visible, but it is pulsing). So there is a lot of activity going on on the bus switch. I am assuming the Ether chip is being accessed. But this does not go well. The failure is consistent with earlier failure to auto-detect. bstamp532>ping 10.12.13.20 SMC91111: PHY auto-negotiate timed out Warning: MAC addresses don't match: HW MAC address: xx:xx:xx:xx:xx:xx "ethaddr" value: ### Set MAC addr from environment Using MAC Address Reminder: The failure to auto-detect was reported as follows: ERROR: Can't find SMC91111 at address 20300300 BANK_SELECT = 0xe (Added later: this was due to an error in the CPLD code.) ---------------------------------------------------------------------------- 06/23/06 I recompiled U-Boot without DEBUG, just in case. I can now run the minicom and the coLinux will not crash, because the trace output is short. Size with DEBUG 116,156 bytes. Size without DEBUG 111,548 bytes. The Ether is not found. U-Boot-1.1.3-ADI-2006R1 (Jun 23 2006 - 20:44:01) CPU: ADSP BF532 Rev.: 0.3 Board: BlackStamp BF532 Support: http://blackfin.uclinux.org/ rtc_init IS COMMENTED OUT. Clock: VCO: 250 MHz, Core: 250 MHz, System: 50 MHz SDRAM: 64 MB FLASH: 4 MB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial ERROR: Can't find SMC91111 at address 20300300 I2C: ready Hit any key to stop autoboot: 0 ---------------------------------------------------------------------------- I am taking the board home to examine electrical connections. They turned out to be OK. ---------------------------------------------------------------------------- ERROR: Can't find SMC91111 at address 20300300 BANK_SELECT = 0xe SMC_inw(BANK_SELECT) = 0x0 masked SMC_inw(BANK_SELECT) = 0x0 expected value was = 0x3300 According to the Data Sheet, rev 1.3, page 46, we are reading Bank Select Register at offset Base + E. This register is always accessible. The upper byte always reads 0x33 and can be used to identify the chip. IO base = Stamp base + chip base = 0x20300000 + 0x300. So the algorithm is OK. However, the chip does not respond. ---------------------------------------------------------------------------- 06/24/06 I added a CPLD switch 2 = HIGH --> force the bus switch OPEN. In such a way the bus switch should be out of the way. It did not help. The ether chip still does not communicate. ---------------------------------------------------------------------------- 06/25/06 Found the problem by examining the VHDL code and the CPLD pin assignment in the UCF file. It was a wrong pin. -- 06/25/06 Ether chip did not respond due to wrong assignment of -- SWITCH_ENA_bar. Should be pin 74, was 94 by mistake. -- After correcting the pin, ether chip is responding. Even thogh I forced the "bus switch enable" to LOW, but it was assigned to a WRONG CPLD pin, and therefore the bus switch was permanently closed. So no data went through. Moreover, it was the DATA15 pin, what likely caused bad data. It is interesting that nothing was smoked on the board. Probably because the CPLD drive is fairly weak. ---------------------------------------------------------------------------- 06/25/06 Ether chip is detected by U-Boot. ================================= So here we are. U-Boot is pinging the coLinux host. Awesome. The MAC address was not yet programmed into the ether EEPROM. Not sure what is this "HW MAC address" which I am seeing. (I am not releasing these.) bstamp532>ping 10.12.13.20 SMC91111: PHY auto-negotiate timed out Warning: MAC addresses don't match: HW MAC address: xx:xx:xx:xx:xx:xx "ethaddr" value: ### Set MAC addr from environment Using MAC Address host 10.12.13.20 is alive bstamp532> ---------------------------------------------------------------------------- 06/26/06 Now I want to burn in the MAC number into the EEPROM. ===================================================== I found an old ether card and I am reusing its MAC. The old card will never be used again, so I can use its MAC number. PLEASE DO NOT USE THE MAC NUMBER WHICH I AM USING !!!!!! -------------------------------------------------------- How to program the MAC into the EEPROM? Read http://blackfin.uclinux.org/forum/forum.php?thread_id=2299&forum_id=51 where this was discussed. The advice by Mike Frysinger and Robin Getz u-boot_1.1.3/examples/README.smc91111_eeprom covers all of this In .h do the following: /* Undefine HARDCODE_MAC to remove MAC hardcoding which is in the file ./drivers/smc91111.c. This will also enable MAC storage in EEPROM. u-boot_1.1.3/examples/README.smc91111_eeprom covers all of this */ /* #define HARDCODE_MAC 1 */ /*If the MAC is defined here, it cannot be burnt into the EEPROM. Read the above-mentioned README.*/ #define CONFIG_ETHADDR 00:50:ba:cf:94:a9 /*it should be unique*/ So I have to comment out the above #define, recompile, and re-flash. ---------------------------------------------------------------------------- 06/26/06 Following the u-boot_1.1.3/examples/README.smc91111_eeprom 1. Comment out HARDCODE_MAC and CONFIG_ETHADDR (see above). 2. Recompile and reload U-Boot to SPI flash. 3. bstamp532>loadb 0x1000000 ## Ready for binary (kermit) download to 0x01000000 at 57600 bps... Hit CTRL-C 4. It does not work. I am back at the U-Boot prompt. ---------------------------------------------------------------------------- 06/26/06 I have to load a special utility to SDRAM and execute it. My network is not setup yet, so I have to use serial transfer. -------------------------------------------------------------- Read about "transferring files over serial". http://docs.blackfin.uclinux.org/doku.php?id=loading_dxes_via_the_serial_port Use Kermit from within coLinux? Bad idea... Continue with HyperTerm.... 3. bstamp532>loadb 0x1000000 ## Ready for binary (kermit) download to 0x01000000 at 57600 bps... 4. In HyperTerm menu, Transfer -> Transfer file, select Kermit as protocol, and browse for the file "smc91111_eeprom" (no extension!) in coLinux file system U-Boot --> "examples" folder File: ~/u-boot_1.1.1/examples/smc91111_eeprom In full: \\10.12.12.10\uclinux\u-boot_1.1.3\examples\smc91111_eeprom 5. It worked (14 seconds or so). Here is the proof: bstamp532>loadb 0x1000000 ## Ready for binary (kermit) download to 0x01000000 at 57600 bps... ## Total Size = 0x000037e9 = 14313 Bytes ## Start Addr = 0x01000000 bstamp532> 6. Run it: bstamp532>bootelf 0x1000000 Loading .text @ 0x00001000 (1960 bytes) Loading .rodata @ 0x000017a8 (535 bytes) ## Starting application at 0x000013d4 ... SMC91111> 7. To set the EEPROM MAC address to 00:50:ba:cf:94:a9 ----- ----- ----- Note the reversed order of bytes 2 1 4 3 6 5 SMC91111> W E 20 5000 Writing EEPROM register 20 with 5000 SMC91111> W E 21 CFBA Writing EEPROM register 21 with cfba SMC91111> W E 22 A994 Writing EEPROM register 22 with a994 SMC91111> P Current MAC Address in SMSC91111 ff:ff:ff:ff:ff:ff Current MAC Address in EEPROM 00:50:ba:cf:94:a9 SMC91111> 8. Copy from EEPROM to SMSC chip SMC91111> C EEPROM contents copied to MAC SMC91111> P Current MAC Address in SMSC91111 00:50:ba:cf:94:a9 Current MAC Address in EEPROM 00:50:ba:cf:94:a9 SMC91111> 9. Terminate the EEPROM writer application SMC91111> ## Application terminated, rc = 0x0 bstamp532> 10. Reset CPU (will reboot from SPI flash). 11. After reboot, see the MAC address. bstamp532>ping 10.12.13.20 Using MAC Address 00:50:BA:CF:94:A9 host 10.12.13.20 is alive bstamp532> SUCCESS! The MAC number was burnt into the small EEPROM attached to the SMC ether chip. ---------------------------------------------------------------------------- 06/27/06 Next goal: flash the U-Boot into the parallel flash. ==================================================== Note: Later on I will want to flash the kernel into the SPI flash, too. But now I am using the parallel flash because I have it on board... http://docs.blackfin.uclinux.org/doku.php?id=upgrading_u-boot 1. Copy u-boot.bin to TFTP folder. This has to be done as root. # cp u-boot.bin /svr/tftp 2. Execute tftp on the board. The IP's have been already setup in .h, see the Setting Up Survival Guide. It works great. bstamp532>tftp 0x1000000 u-boot.bin Using MAC Address 00:50:BA:CF:94:A9 TFTP from server 10.12.13.20; our IP address is 10.12.13.30 Filename 'u-boot.bin'. Load address: 0x1000000 Loading: ###################### done Bytes transferred = 111176 (1b248 hex) bstamp532> 3. Testing the recently downloaded U-Boot. This will require to re- download U-Boot. It is done like this: BOARD> go 0x1000000 Tested, works. This destroys the SDRAM copy, so I will have to TFTP one more time. 4. Execute step 2 again in order to load fresh copy into SDRAM. 5. Erase parallel flash. (I feel safe because I have U-Boot in SPI flash.) Erasing takes good few seconds. bstamp532>protect off all Un-Protect Flash Bank # 1 bstamp532>erase all Erase Flash Bank # 1 ................................................................... done bstamp532> 6. Burn U-Boot into parallel flash. It takes a second or two. bstamp532>cp.b 0x1000000 0x20000000 $(filesize) Copy to Flash... done bstamp532> 7. Compare the flash image with the RAM image. bstamp532>cmp.b 0x1000000 0x20000000 $(filesize) Total of 111176 bytes were the same bstamp532> 8. Boot from parallel flash. Switch BMODE 0,1 to (ON, OFF) and hit reset. Does not work. The board does not boot from the parallel flash. I tried all three BMODE combinations (00), (10) and (01) to make sure it really does not boot. It does not. Fortunately, I do have U-Boot in SPI flash, so I can easily recover from this situation. ---------------------------------------------------------------------------- 06/27/06 So I failed with using the parallel flash. WHY??? ================================================= Recompiled U-Boot with DEBUG. I did not have to build the serial image because I am loading the ".bin" file from the main U-Boot directory. So I executed only the steps as above. Burnt into parallel flash. It does not boot at all. There are no messages. Nothing is loading? I tried combinations (0,1) and (1,0) for BMODE pins. Tried both RESET and power-cycle. Same result. ---------------------------------------------------------------------------- After power-cycling, booted from SPI and TFTPed the .bin image again to SDRAM, and then compared with parallel flash (without erasing it). It says "same". Allright, let's erase the flash and then compare. bstamp532>erase all Erase Flash Bank # 1 ................................................................... done bstamp532>cmp.b 0x1000000 0x20000000 $(filesize) byte at 0x01000000 (0x90) != byte at 0x20000000 (0xff) Total of 0 bytes were the same bstamp532> I also TFTPed and then compared (without reprogramming parallel flash). Still not the same. Good. So erasing does work. ---------------------------------------------------------------------------- Burnt image into parallel flash again. Same result: no boot. ---------------------------------------------------------------------------- 06/29/06 Copying SDRAM --> flash produces non-bootable configuration. let's try copying the other way. 1. Reboot from SPI to make sure there is no image in SDRAM. 2. Cpy from flash to SDRAM. $(filesize) was 1c548 cp.b 0x2000000 0x10000000 0x1c548 This hangs the board. ---------------------------------------------------------------------------- 07/05/06 BOOTING Linux kernel from parallel flash WORKS!!!! ================================================== References: 1. http://docs.blackfin.uclinux.org/doku.php?id=compiling_the_kernel 2. http://docs.blackfin.uclinux.org/doku.php?id=basic_compilation 3. http://docs.blackfin.uclinux.org/doku.php?id=downloading_to_the_target 4. http://docs.blackfin.uclinux.org/doku.php?id=setting_up_a_tftp_server Ref 1. is a list of sub-chapters, out of which Ref. 2 provides concrete steps. The following trace was copied from BlackStamp HyperTerm window U-Boot-1.1.3-ADI-2006R1 (Jun 30 2006 - 15:12:39) CPU: ADSP BF532 Rev.: 0.3 Board: BlackStamp BF532 Support: http://blackfin.uclinux.org/ *** In file./lib_blackfin/board.c, in function board_init_f, *** call to rtc_init will be performed. Clock: VCO: 250 MHz, Core: 250 MHz, System: 50 MHz SDRAM: 64 MB FLASH: 4 MB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: found SMC91111 at 0x20300300 I2C: ready Hit any key to stop autoboot: 0 bstamp532> bstamp532>tftp 0x1000000 linux Using MAC Address 00:50:BA:CF:94:A9 TFTP from server 10.12.13.20; our IP address is 10.12.13.30 Filename 'linux'. Load address: 0x1000000 Loading: ################################################################# many more such lines ... ######### done Bytes transferred = 10025042 (98f852 hex) bstamp532>bootelf 0x1000000 Loading .text @ 0x00001000 (967252 bytes) Loading .init @ 0x000ed254 (54868 bytes) Loading .text_l1 @ 0xffa08000 (204 bytes) sh_addr: FFA08000, p_paddr: 000FA8A8 Loading from: 010FB000 to 000FA8A8, size: 204 Loading .data @ 0x000fa974 (200120 bytes) Clearing .bss @ 0x0012b730 (53996 bytes) Loading .romfs @ 0x00138a1c (8388608 bytes) ## Starting application at 0x00001000 ... Linux version 2.6.16.11.ADI-2006R1blackfin (uclinux@colinux) (gcc version 3.4.56 Blackfin support (C) 2004 Analog Devices, Inc. ADSP-BF532 Rev. 0.3 uClinux/BF532 Blackfin uClinux support by blackfin.uclinux.org Processor Speed: 250 MHz core clock and 50 Mhz System Clock Board Memory: 64MB Memory map: text = 0x001000-0x0ed254 data = 0x0fa974-0x12b72c bss = 0x12b730-0x138a1c rootfs = 0x3700000-0x3f00000 stack = 0x0fc000-0x0fe000 Command line: 'root=/dev/mtdblock0 rw' Instruction Cache Enabled Data Cache Enabled (write-through) Hardware Trace Enabled Built 1 zonelists Kernel command line: root=/dev/mtdblock0 rw Configuring Blackfin Priority Driven Interrupts PID hash table entries: 256 (order: 8, 4096 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Physical pages: 3700 Memory available: 54528k/64533k RAM, (50k init code, 944k kernel code, 52k data) Blackfin Scratchpad data SRAM: 4 KB Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 NET: Registered protocol family 16 Blackfin DMA Controller for BF533 stamp_init(): registering device resources io scheduler noop registered io scheduler anticipatory registered (default) io scheduler cfq registered Real Time Clock Driver v1.10e BlackFin BF533 serial driver version 2.00 With DMA Support RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize smc91x: not found (-19). <<================= PROBLEM! uclinux[mtd]: RAM probe address=0x3700000 size=0x800000 Creating 1 MTD partitions on "RAM": 0x00000000-0x00800000 : "EXT2fs" uclinux[mtd]: set EXT2fs to be root filesystem NET: Registered protocol family 2 IP route cache hash table entries: 512 (order: -1, 2048 bytes) TCP established hash table entries: 2048 (order: 1, 8192 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 48k freed (0xee000 - 0xf9000) dma_alloc_init: dma_page @ 0x000f6000 - 256 pages at 0x03f00000 Welcome to: ____ _ _ / __| ||_| _ _ _ _| | | | _ ____ _ _ \ \/ / | | | | | | || | _ \| | | | \ / | |_| | |__| || | | | | |_| | / \ | ___\____|_||_|_| |_|\____|/_/\_\ |_| For further information see: http://www.uclinux.org/ http://blackfin.uclinux.org/ BusyBox v1.00 (2006.07.03-23:47+0000) Built-in shell (msh) Enter 'help' for a list of built-in commands. root:~> root:~> ls bin home mnt sbin usr dev lib proc sys var etc lost+found root tmp root:~> root:~> ping blackfin.uclinux.org ping: blackfin.uclinux.org: Unknown host root:~> ping nowshell.pas.rochester.edu ping: nowshell.pas.rochester.edu: Unknown host root:~> ping 172.20.32.116 PING 172.20.32.116 (172.20.32.116): 56 data bytes ping: sendto: Network is unreachable root:~> printenv printenv: not found root:~> path path: not found root:~> pwd / root:~> cd etc root:/etc> ls TZ host.conf mime.types rc boa hosts modprobe.conf services boa.conf index.html motd tux-wink.gif config inetd.conf passwd tuxsit_small.gif dhcpc inittab protocols version group issue ramfs.img ---------------------------------------------------------------------------- 07/07/06 Next problem: ether chip not found by Linux kernel Remember: it WAS found by U-Boot! The following trace is from BlackStamp HyperTerm window Networking is not working because the ether chip is not found. See below: smc91x: not found (-19). This is strange, because earlier the chip was found by U-Boot. Here are "dmesg" messages: root:~> dmesg Linux version 2.6.16.11.ADI-2006R1blackfin (uclinux@colinux) (gcc version 3.4.5 (ADI 2006R1)) #2 Wed Jul 5 14:06:37 EDT 2006 Blackfin support (C) 2004 Analog Devices, Inc. ADSP-BF532 Rev. 0.3 uClinux/BF532 Blackfin uClinux support by blackfin.uclinux.org Processor Speed: 250 MHz core clock and 50 Mhz System Clock Board Memory: 64MB Memory map: text = 0x001000-0x0ed254 data = 0x0fa974-0x12b72c bss = 0x12b730-0x138a1c rootfs = 0x3700000-0x3f00000 stack = 0x0fc000-0x0fe000 Command line: 'root=/dev/mtdblock0 rw' On node 0 totalpages: 14080 DMA zone: 14080 pages, LIFO batch:3 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 0 pages, LIFO batch:0 HighMem zone: 0 pages, LIFO batch:0 Instruction Cache Enabled Data Cache Enabled (write-through) Hardware Trace Enabled Built 1 zonelists Kernel command line: root=/dev/mtdblock0 rw Configuring Blackfin Priority Driven Interrupts PID hash table entries: 256 (order: 8, 4096 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Physical pages: 3700 Memory available: 54528k/64533k RAM, (50k init code, 944k kernel code, 52k data, 9216k dma) Blackfin Scratchpad data SRAM: 4 KB Calibrating delay loop... 496.64 BogoMIPS (lpj=993280) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 NET: Registered protocol family 16 Blackfin DMA Controller for BF533 stamp_init(): registering device resources io scheduler noop registered io scheduler anticipatory registered (default) io scheduler cfq registered Real Time Clock Driver v1.10e BlackFin BF533 serial driver version 2.00 With DMA Support RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize smc91x: not found (-19). <========= here not found uclinux[mtd]: RAM probe address=0x3700000 size=0x800000 Creating 1 MTD partitions on "RAM": 0x00000000-0x00800000 : "EXT2fs" uclinux[mtd]: set EXT2fs to be root filesystem NET: Registered protocol family 2 IP route cache hash table entries: 512 (order: -1, 2048 bytes) TCP established hash table entries: 2048 (order: 1, 8192 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 48k freed (0xee000 - 0xf9000) ttyS0 at irq = 21<7> is a builtin BlackFin UART dma_alloc_init: dma_page @ 0x000f6000 - 256 pages at 0x03f00000 bfin_change_speed: baud = 57600, cval = 0x13 root:~> ---------------------------------------------------------------------------- 07/07/06 I want to see how it works on ADI STAMP (for comparison) The following is done on ADI STAMP running uCLinux Reference: http://blackfin.uclinux.org/forum/forum.php?thread_id=2414&forum_id=39 http://docs.blackfin.uclinux.org/doku.php?id=setting_up_the_network There was a good reason why networking did not work on BlackStamp: chip not detected. So I fired ADI Stamp. Here there is problem, too.... Note that networking did work in U-Boot on both boards.... /> ping 10.12.13.20 <--- this is ADI STAMP PING 10.12.13.20 (10.12.13.20): 56 data bytes ping: sendto: Network is unreachable ping: wrote 10.12.13.20 64 chars, ret=-4294967297 OK. Mike Frysinger said "use ifconfig", see above refs. /> ifconfig eth0 10.12.13.30 netmask 255.255.255.0 up eth0: PHY=LAN83C183 (LAN91C111 Internal) /> ifconfig eth0 Link encap:Ethernet HWaddr 00:E0:22:FE:03:FA inet addr:10.12.13.30 Bcast:10.255.255.255 Mask:255.255.255.0 So now eth0 is configured, but ping still does not work either way. ping 10.12.13.20 (STAMP --> eth2 in coLinux) failed ping 10.12.13.10 (STAMP --> dedicated card in Windows) failed ping 10.12.13.30 <-- STAMP pinging itself, OK. ping 172.20.32.116 (STAMP --> Windows PC ) failed [This last may have failed because there was no gateway defined]. The following is executed on Windows DOS prompt ping 10.12.13.10 (Windows --> dedicated card in Windows) OK ping 10.12.13.20 (Windows --> eth2 in coLinux) OK ping 10.12.13.30 (Windows --> STAMP) failed The following is executed on coLinux prompt ping 10.12.13.30 (coLinux --> STAMP) failed ping 172.20.32.116 (coLinux --> Windows PC ) OK So ADI Stamp is not responding to ping while running uCLinux which was booted from the flash. ---------------------------------------------------------------------------- 07/07/06 The following is done on ADI BF-533 STAMP running U-Boot 1.1.1 I want to verify that ADI STAMP can use the network and ping the PC. BOOT> ping 10.12.13.10 (STAMP --> dedicated card in Windows) OK Using MAC Address 00:FFFFFFE0:22:FFFFFFFE:03:FFFFFFFA host 10.12.13.10 is alive BOOT> ping 172.2.32.116 (STAMP --> Windows PC ) failed Using MAC Address 00:FFFFFFE0:22:FFFFFFFE:03:FFFFFFFA ping failed; host 172.2.32.116 is not alive Conclusion: U-Boot 1.1.1 can ping IP on the same subnet, but fails on a different subnet. (This was on ADI BF-533 STAMP) Next, see if TFTP still works on ADI STAMP. Remember that the settings were saved in the flash long ago, so it knows the TFTP server. BOOT> tftp 0x100000 u-boot.bin Using MAC Address 00:FFFFFFE0:22:FFFFFFFE:03:FFFFFFFA TFTP from server 10.12.13.20; our IP address is 10.12.13.30 Filename 'u-boot.bin'. Load address: 0x100000 Loading: ###################### done Bytes transferred = 111176 (1b248 hex) ---> So we have two problems to solve: 1. The ether chip is not detected on BlackStamp. 2. Networking does not work on ADI STAMP running uCLinux kernel. Ad. 1. The ether PFx interrupt may be misconfigured in uCLinux kernel. We need to use the proper PF in the kernel settings. ADDED LATER: 1) Software was OK, but the instructions in menuconfig were nonsense. I typed in a wrong number, because I misunderstood the menuconfig prompt. It cost me 6 days of unnecessary effort. 2) I had to change PF7 --> PF3, because ADI STAMP uses PF7 for ether interrupt, and it was hardcoded. I am using PF3 for ether interrupt. ---------------------------------------------------------------------------- 07/07/06. Trying to fix the ether problem in BlackStamp. Why is ether not detected? After searching docu I found that the PF7 is configured in smc91x.c as the ether interrupt source. This info is is well hiden in a FAQ titled "What does a normal Boot Look like?" Among boot messages there is one saying that interrupt 27 comes from PF7. These are old boot messages. In new boot messages this is not printed. I have to change PF7 --> PF3. The next task: where the heck is smc91x.c in the kernel tree? ---------------------------------------------------------------------------- 07/08/06 Finding the place to correct in the Linux kernel The kernel follows the same logic as U-Boot. There is a "board" file. It is located in uCLinux-dist\linux-2.6x\arch\blackfin\mach-bf533\boards\stamp.c In this file the resources are hardcoded. In particular, addresses of the ether and the PFx flags used for ether interrupt. Hardcoded!! Amazing. The error message was emitted from file linux-2.6.x/drivers/net/smc91x.c The function which emits the error: smc_drv_probe The error means "chip not found". ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ File linux-2.6.x/drivers/net/smc91x.c contains #ifdef symbols for particular ADI boards. It fixes in software their hardware mistakes. For example #ifdef CONFIG_IRQCHIP_DEMUX_GPIO /* fix a floating input on the USB-LAN EZ-Extender */ # if defined (CONFIG_BF561) *pFIO0_DIR |= (1 << 12); # endif /* defined (CONFIG_BF561) */ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In the function smc_drv_probe the PF0 flag is asserted to switch to the ether. This is good. Notice comment which says AMS3. The ether address is HARDCODED, and therefore they are saying "AMS3" here. #if defined(CONFIG_BFIN_SHARED_FLASH_ENET) /* setup BF533_STAMP CPLD to route AMS3 to Ethernet MAC */ bfin_cpld_setup(); #endif ---------------------------------------------------------------------------- The startup code is in the file uClinux-dist\linux-2.6.x\arch\blackfin\mach-bf533\head.S Interrupt priority is in the file uClinux-dist\linux-2.6.x\arch\blackfin\mach-bf533\ints-priority.c Power management is in the file uClinux-dist\linux-2.6.x\arch\blackfin\mach-bf533\pm.c ---------------------------------------------------------------------------- 07/08/06 Trying to fix the Linux kernel to make ether chip visible ========================================================= Changed PF7 --> PF3 in uCLinux-dist\linux-2.6x\arch\blackfin\mach-bf533\boards\stamp.c Recompiled, same problem when GPIO DEMUX enabled in kernel build (kernel options). Now trying GPIO DEMUX disabled. ---> same result, ether not found. So the problem was not solved yet. ---------------------------------------------------------------------------- This comment is at the top of linux-2.6.x/drivers/net/smc91x.c It suggests that DEMUX should be enabled. So I enabled it. #if defined(CONFIG_BFIN) /* * irq_pfx comes from platform_device and tells us which flag pin is used * IRQ_PF0 <= irq_pfx <= IRQ_PF15 * irq_pfx is used as the irq if CONFIG_IRQCHIP_DEMUX_GPIO is enabled. */ ---------------------------------------------------------------------------- However, the problem is that smc_probe failed. It read all 1's from the chip. It looks like the chip is not being selected properly. smc91x: smc_drv_probe will try to find device. smc91x: platform_get_resource_byname failed in smc_drv_probe. smc91x: will try to platform_get_resource. smc91x: PF flag 0 asserted in smc_drv_probe. smc91x: interrupt 36 will be used in smc_drv_probe. smc91x: PF flag 0 asserted just before smc_probe. smc91x: smc_probe smc91x: smc_probe got bank signature 0xffff smc91x: smc_probe will return -19 (from CURRENT_BANK). smc91x: smc_probe failed in smc_drv_probe. smc91x: not found (-19). ---------------------------------------------------------------------------- See earlier battles with U-Boot. We should be reading 0x3300 from address 0x2030030E. However, we are reading 0xffff. After I burnt uImage into parallel flash, it now reads 0x274e OBSERVATION: When the parallel flash was erased, we read 0xffff (i.e., all 1's). When the parallel flash was programmed, we read 0x274e This means something! It is known that "flash erased" means "all bits are 1's". So we must be reading from parallel flash, not from ether. So it means we are not selecting the ether. We are selecting parallel flash! So we have the "shared resources" problem, i.e., PF0 flag problem. We are reading from the parallel flash, not from ether. Let me investigate. How to erase parallel flash http://docs.blackfin.uclinux.org/doku.php?id=loading_a_compressed_kernel_image Do the following under U-Boot. The 1st is starting address in flash to be erased. erase 0x20040000 0x203FFFFF OK, now I am getting signature 0xffff. Remember that erased flash means all bits "1". This means, erasing parallel flash changes the readout from 0x274e to 0xffff. So we are not addressing ether. We are addressing parallel flash instead. This confirms that cpld switching with PF0 does not work. Inserted code in smc_probe. This code should turn the PF0 ON and read from ether. This code was taken from U-Boot, from the board/stamp/stamp.c asm("ssync;"); /* WOJTEK tutaj */ *pFIO_DIR |= 0; asm("ssync;"); *pFIO_FLAG_S = 0; asm("ssync;"); (This actually should not work either, but it apparently it did work! Note the bitpattern is "0". It should not work....) SO I FOUND THE PROBLEM. PF0 switching does not work. SOLUTION: CONFIG_ENET_FLASH_PIN is a bit pattern!!!! They said "number" in Linux menuconfig. So I typed "0" to mean PF0. But this is NOT a number. It is a bitpattern. I should have typed "1" to mean PF0. They wrote a nonsense prompt in menuconfig, and I believed what they wrote. The code in function bfin_cpld_setup is the following: __builtin_bfin_ssync(); *pFIO_DIR |= CONFIG_ENET_FLASH_PIN; __builtin_bfin_ssync(); *pFIO_FLAG_S = CONFIG_ENET_FLASH_PIN; __builtin_bfin_ssync(); The constant CONFIG_ENET_FLASH_PIN was equal to 0, which did not switch any PF pin high. In particular, it did not switch PF0. Therefore, the ether chip was not selected. The flash chip was read instead. Is it a bug or a feature? The constant CONFIG_ENET_FLASH_PIN comes from menuconfig. The dialog which sets this constant is titled "PF port/pin used for flash and ethernet sharing" and a comment says "Please enter a decimal value. Fractions will not be accepted." I understood that I need to enter "0" for PF0, or "1" for PF1, or "2" for PF2, etc. Seems logical. Having understood the issues better (after spending six days of unnecessary effort) I know that I should enter "1" for PF0, "2" for PF1, "4" for PF3, etc. Is it not obvious from the beginning? For a hacker it may be obvious. But even a hacker should know English and use it correctly. ---------------------------------------------------------------------------- 07/11/06 Ether chip detection works in the Linux kernel on BlackStamp ============================================================ The following is done on BlackStamp running uCLinux After finding out that I should enter "1" in menuconfig, I copied the modified driver away, restored the original one, recompiled and reloaded the kernel. It worked. smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre Blackfin SMC91x interrupt setup: flag PF3, irq 27 eth0: SMC91C11xFD (rev 1) at 20300300 IRQ 27 [nowait] eth0: Ethernet addr: 00:50:ba:cf:94:a9 Now it is time to activate eth0 and to setup the network. Reference: http://blackfin.uclinux.org/forum/forum.php?thread_id=2414&forum_id=39 http://docs.blackfin.uclinux.org/doku.php?id=setting_up_the_network root:~> ifconfig eth0 10.12.13.30 netmask 255.255.255.0 up eth0: link down root:~> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 here I had to hit root:~> root:~> ifconfig eth0 Link encap:Ethernet HWaddr 00:50:BA:CF:94:A9 inet addr:10.12.13.30 Bcast:10.12.13.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 Interrupt:27 Base address:0x300 DMA chan:ff lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 root:~> route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.12.13.0 * 255.255.255.0 U 0 0 0 eth0 root:~> We do not have the gateway, but we are on the "private net", so not sure if we need one for local communication. The following worked under U-Boot (see earler record). BOOT> ping 10.12.13.10 (ADI STAMP --> dedicated card in Windows) was OK Does it work on BlackStamp uCLinux ??? BlackStamp --> dedicated card in Windows ----------------------------------------- root:~> ping 10.12.13.10 YES, IT WORKS! PING 10.12.13.10 (10.12.13.10): 56 data bytes 64 bytes from 10.12.13.10: icmp_seq=0 ttl=128 time=3.9 ms 64 bytes from 10.12.13.10: icmp_seq=1 ttl=128 time=0.0 ms 64 bytes from 10.12.13.10: icmp_seq=2 ttl=128 time=0.0 ms 64 bytes from 10.12.13.10: icmp_seq=3 ttl=128 time=0.0 ms 64 bytes from 10.12.13.10: icmp_seq=4 ttl=128 time=0.0 ms 64 bytes from 10.12.13.10: icmp_seq=5 ttl=128 time=0.0 ms --- 10.12.13.10 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.6/3.9 ms root:~> coLinux --> BlackStamp ----------------------- The following is in coLinux window: uclinux@colinux:~$ ping 10.12.13.30 WORKS (though slow) PING 10.12.13.30 (10.12.13.30): 56 data bytes 64 bytes from 10.12.13.30: icmp_seq=0 ttl=64 time=3.6 ms 64 bytes from 10.12.13.30: icmp_seq=1 ttl=64 time=15.8 ms 64 bytes from 10.12.13.30: icmp_seq=2 ttl=64 time=15.6 ms 64 bytes from 10.12.13.30: icmp_seq=3 ttl=64 time=15.6 ms 64 bytes from 10.12.13.30: icmp_seq=4 ttl=64 time=15.7 ms --- 10.12.13.30 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 3.6/13.2/15.8 ms Windows DOS prompt --> BlackStamp --------------------------------- C:\>ping 10.12.13.30 YES, IT WORKS! Pinging 10.12.13.30 with 32 bytes of data: Reply from 10.12.13.30: bytes=32 time<10ms TTL=64 Reply from 10.12.13.30: bytes=32 time<10ms TTL=64 Reply from 10.12.13.30: bytes=32 time<10ms TTL=64 Reply from 10.12.13.30: bytes=32 time<10ms TTL=64 Ping statistics for 10.12.13.30: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms BlackStamp --> Windows PC failed (no gateway) ----------------------------------------------- root:~> ping 172.2.32.116 PING 172.2.32.116 (172.2.32.116): 56 data bytes ping: sendto: Network is unreachable root:~> Trying to fix this, but the gateway does not work. Well, we need to add a gateway to the system, or move the board to the general network. root:~> route add default gw 10.12.13.20 root:~> route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.12.13.0 * 255.255.255.0 U 0 0 0 eth0 default 10.12.13.20 0.0.0.0 UG 0 0 0 eth0 root:~> root:~> root:~> root:~> ping 172.2.32.116 PING 172.2.32.116 (172.2.32.116): 56 data bytes --- 172.2.32.116 ping statistics --- 14 packets transmitted, 0 packets received, 100% packet loss ---------------------------------------------------------------------------- 07/10/06 How to burn Linux kernel into parallel flash. Do it under U-Boot http://docs.blackfin.uclinux.org/doku.php?id=loading_a_compressed_kernel_image erase 0x20040000 0x203FFFFF tftp 0x1000000 uImage cp.b 0x1000000 0x20040000 $(filesize) bootm 0x20040000 One can also bootm directly from SDRAM bootm 0x1000000 BOTH METHODS WORK ---------------------------------------------------------------------------- To be continued. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ----------------------------------------------------------------------------