Ask::: OAL boot sequence problem? ? Also take the PXA270 SPI problem! HELP!!!!!!!!!!!!!!!!!![Copy link]
I would like to ask you all: I passed a virtual address of NORFLASH to the third parameter of the last function OEMLaunch of my EBOOT, and finally I can jump to Startup.s in OAL (you can see it by turning on the light) Question 1: The last 5 BYTEs of the binary code of NK.bin are the virtual addresses of SDRAM, but I cannot enter OAL when I pass this address to the third parameter of OEMLaunch. So is my way of booting from FLASH XIP? ? I don't understand this! Question 2: I read in a book that after entering Startup.s of OAL, it jumps to the kernelstart function, and this function is in: PRIVATE\WINCEOS\COREOS\NK\LDR... But in my PRIVATE C:\WINCE500\PRIVATE\WINCEOS\COREOS\NK, there is only one folder KERNEL folder, and this folder only has one SH folder. Can I replace other people's PRIVATE with mine and then rebuild and sysgen? ? Question 3:Since there are not many available points, I can only ask more questions at once: Is the SPI of PXA270 grouped? ? ? I see that the SSP register sscr is divided into 0, 1, and 2, which seems to be grouped. So can I use GPIO26--SSPRXD and GPIO38--SSPTXD2 together for SPI reception and transmission? ?
1. 1.1 What is XIP (eXecute In Place)? It means that the executable code is directly executed in the storage medium, rather than being loaded from the storage medium to RAM through the bootloader. The only storage media that can be directly executed are NOR Flash and ROM. 1.2 The last 5 BYTEs -> 32bits = 4bytes. It should not be 5 bytes. 1.3 The address should be ROMSTART in confib.bib. The address should be the same as the ROMSTART in LZ. 2. 2.1 KernelStart is located in C:\WINCE500\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\armtrap.s. 2.2 Does LZ need to track KernelStart? Generally speaking, LZ only needs to make sure that OEMAddressTable & config.bib are correct, and then it will execute OEMInitDebugSerial & OEMInit. Modifying the tracking KernelStart may not help clarify the problem. 3. It should be possible, as long as you remember to set the GPIO and use sscr0. Paul, Chao @ Techware
Quote from paul_chao's reply on the second floor: 1. 1.1 What is XIP (eXecute In Place)? It means that the executable code is directly executed in the storage medium, rather than being loaded from the storage medium to RAM through the bootloader for execution. The only storage media that can be directly executed are NOR Flash and ROM. 1.2 The last 5 BYTEs -> 32bits = 4bytes. It should not be 5 bytes. 1.3 The address should be ROMSTART in confib.bib. The address should be the same as the ROMSTART in LZ. 2. 2.1 KernelStart is located in C:\WINCE500\PRIVATE\WINCEOS\COREOS\NK\KER…
1. ROMSTART in my config.bib: ROMSTART=$(NKSTART) ROMWIDTH=32 ROMSIZE=$(NKLEN) and #define NKSTART 80100000 is the virtual address of RAM, not the address of FLASH. This address cannot be passed into OAL. What I am passing now is dwLaunchAddr = 0x9CA80000; #define NKLEN 01B00000 And I see that OEMLaunch(RAMSTART,dwPhysLen,FLASH_IMG_START,((const ROMHDR *)dwpToc)); called in void BootloaderMain (void) switch (dwAction = OEMPreDownload ()) case BL_JUMP: under C:\WINCE500\PLATFORM\COMMON\SRC\COMMON\BOOT\BLCOMMON\blcommon.c also passes the address of FLASH. 2. There are no such files in my PRIVATE at all. I don't know why. Did I miss something during installation? Will this have any impact? If I use someone else's PRIVATE to overwrite my PRIVATE, will the build and sysgen fail to compile? I see that PRIVATE is excluded from build in FILEVIEW under PB. 3. Another important question is: how to determine which of the three groups sscr0, sscr1, and sscr2 to use? ? Can all GPIOs with SSP of PXA270 be matched at will? Can I just match any GPIO with SSP function to SSPSCLK, SSPTXD, SSPRXD at will? 4. I see that SSP has NetWork mode in SPEC? May I ask if the wireless network card (8686) using SPI has nothing to do with this NetWork mode?
1. Could you please post config.bib & OEMAddressTable & eboot.bib? 2. I can't answer this because mine is fine and I've never built a private one. 3. It mainly depends on how the hardware is connected. As long as the tx, rx, clk, etc. are connected correctly and are in the same group, it's fine. Also, it depends on how the driver is written. It's not just hard-coded for a certain group. It's generally recommended to match the schematic of the BSP you cloned, with the least amount of changes required. 4. It shouldn't be relevant. Please check the protocol in your spec. Paul, Chao @ Techware
3. It mainly depends on how the hardware circuits are connected. As long as the tx, rx, clk, etc. that should be connected are connected correctly and are in the same group, it will be fine. In addition, it depends on how the driver is written. It is not enough to just hard-code a certain group. Generally, it is recommended to match the schematic of the BSP you cloned, and the required modifications are minimal. May I ask: As long as the tx, rx, clk, etc. that should be connected are connected correctly and are in the same group , it will be fine. What does this "same group" mean? Also: How do you determine which group to use among the three groups sscr0, sscr1, and sscr2? ?
1. When downloading eboot, the download location will be used as a parameter to call OEMIsFlashAddr, and the return value will be used to determine whether to call OEMMapMemAddr & OEMWriteFlash. I don't know what the input and return values of LZ's OEMIsFlashAddr are? 2. It doesn't mean it's correct. It's correct only if it can move as you want. LZ, can you add a debug message in OEMLaunch, dump the first 16 bytes of the download location, and then compare it with the content of nk.nb0/nk.bin. 3. SSPTXD (GPIO25, GPIO57), SSPTXD2 (GPIO38, GPIO87, GPIO89), SSPTXD3 (GPIO35, GPIO38, GPIO81), so for sscr0_1, sscr1_1 is for SSPTXD, sscr0_2, sscr1_2 is for SSPTXD2, sscr0_3, sscr1_3 is for SSPTXD3 port control. So the schematic will connect ssptxd to which CPU pin, which determines which group to use. Paul, Chao @ Techware
Oh! Thank you very much!!! 1&2, I did not use OEMIsFlashAddr, my EBOOT process: 1): First, use the button to determine whether to download NK.NB0, if (need) { g_DownloadImage = TRUE; } else {g_DownloadImage = FALSE}; 2): Then call OEMPreDownload { if (g_DownloadImage) directly return (BL_DOWNLOAD); else return (BL_JUMP); } 3): In BLCOMMON, call switch (dwAction = OEMPreDownload ()) { case BL_DOWNLOAD: Call OEMReadData(); case BL_JUMP://Directly start OEMLaunch (RAMSTART, dwPhysLen, FLASH_IMG_START, ((const ROMHDR *) dwpToc)); } 4): Among them, OEMReadData() function calls usbdown() function to download NK from PC to terminal 5): usbdown() first downloads NK.NB0 to SDRAM of terminal, and determines whether to start directly from SDRAM or need to write to FLASH usbdown() { ...... if(write to flash) { FlashWrite( RAMSTART, dwPhysLen);//Write from SDRAM to FLASH, of course, you need to call EraseFlash to erase FALSH before writing } if(start from FALASH) { OEMLaunch (pImgStart, dwPhysLen, FLASH_IMG_START, (const ROMHDR *)lpdwToc); } else OEMLaunch (pImgStart, dwPhysLen, pImgStart, (const ROMHDR *)lpdwToc);//Generally not started from here } 3.Which SPI group is used is determined by the data transmission pin SSPTXD? ? Then: 1. How to distinguish between sscr0_1 and sscr1_1? 2. Is it true that once SSPTXDx is determined, other pins such as SSPSCLK and SSPRXD can be matched at will? For example: use sscr0_1: use this group: GPIO25: OUTPUT, SSPTXD GPIO52: OUTPUT, SSPSCLK3 GPIO40: INPUT, SSPRXD2 Is this also OK? Is it sscr0_1or sscr1_1 ??
Assume that LZ is continuing the content of http://topic.eeworld.net/u/20090522/12/98ac9845-fb0c-43fe-9cde-1ceabbb92489.html and http://topic.eeworld.net/u/20090525/13/8de788ce-c9dd-4f4b-9ef0-43d22da407c2.html 1. According to the answer at that time, it seems that LZ still didn't understand it, so I copied the answer at that time here again 2. ( ((DWORD)lpdwToc & 0x90000000) == 0x80000000 ) to determine whether NK.nb0 is to be used for RAM or burned into flash, so LZ can refer to OEMAddressTable, Flash Is it mapped to VA 0x8xxxxxxx, is RAM mapped to VA 0x9xxxxxxx. Obviously, in LZ's OEMAddressTable, Flash is mapped to VA 0x9CA00000, and RAM is mapped to VA 0x80000000, so the OEMusbdown program is written wrong, it should be #define FLASH_RAM_CHECK_MASK 0x90000000 #define FLASH_CHECK_LOCATION 0x90000000 #define RAM_CHECK_LOCATION 0x80000000 ( ((DWORD)lpdwToc & FLASH_RAM_CHECK_MASK) == FLASH_CHECK_LOCATION ) So although LZ's NK.nb0 is placed in RAM (0x80100000), OEMusbdown I mistakenly thought it was in FLASH, so this error occurred. And there seems to be more than just this judgment in the program, please remember to check all of them. 3. How to distinguish sscr0_1 & sscr1_1 is not something that can be explained clearly on the forum. The SSP chapter of the PXA270 User's Manual has very detailed instructions. This work cannot be omitted. And SSPTXD, SSPRXD, SSPSCLK, etc. must be matched. SSPTXD + SSPRXD2 or SSPTXD + SSPSCLK3 will not work. Only SSPTXD + SSPRXD + SSPSCLK or SSPTXD2 + SSPRXD2 + SSPSCLK2 or SSPTXD3 + SSPRXD3 + SSPSCLK3 will work. Paul, Chao @ Techware
Oh, I completely understand question 3. Thank you paul_chao! As for questions 1 and 2, I still have some questions: if(((DWORD)lpdwToc&0x90000000)==0x90000000)//I used to write lpdwToc & 0x80000000) ！ =0x90000000 like this//Because I didn't understand what this was for at the time, it always got FALSE, so I forced it//! =Let it enter 1111--------------! { EdbgOutputDebugString("\r\n1111--------------!\r\n"); memcpy((LPVOID)&RomHdr, (LPVOID)(RAMSTART + ((DWORD)lpdwToc - FLASH_IMG_START)), sizeof(ROMHDR)); } else { EdbgOutputDebugString("\r\n2222---------------!\r\n"); memcpy((LPVOID)&RomHdr, (LPVOID)lpdwToc, sizeof(ROMHDR));//No matter what, don't let the program go here } if( ((DWORD)lpdwToc & 0x90000000) == 0x90000000 ) //This is the same, // I force the program to go here: lpdwToc & 0x80000000)! =0x90000000 { EdbgOutputDebugString("xxxxxxxxxxxxyyyyyyyyyyyyyy!\r\n"); if (FlashWrite( RAMSTART, dwPhysLen)) //Because I want to write NK from RAM address RAMSTART to FLASH virtual address{ EdbgOutputDebugString("Flash programming Error. System halted!\r\n"); while (1); } EdbgOutputDebugString("Will goto launch!\r\n"); //step10 OEMLaunch (pImgStart, dwPhysLen, FLASH_IMG_START, (const ROMHDR *)lpdwToc);//This can actually be removed because after restart} //OEMLaunch is called through BL_JUMP: //Jump to the kernel. else { EdbgOutputDebugString("launch2!\r\n"); //step10 //This basically does not take into account OEMLaunch (pImgStart, Bufflen, pImgStart, (const ROMHDR *)lpdwToc); } In short, I think that ((DWORD)lpdwToc & 0x90000000) == 0x90000000 is just a judgment. I can use an arbitrary variable to make this judgment condition. The purpose is to let EBOOT write the NK that has been downloaded to SDRAM to FLASH. By printing information, it is found that it has also been written to FLASH. So if the third parameter of OEMLaunch is the virtual address of SDRAM, then after restarting the terminal, there should be a program segment in EBOOT to move NK from FLASH to SDRAM for execution. But now it seems that there is no such program! In addition, I found that the problem now is: after transferring the virtual address of FLASH, EBOOT calls OEMLaunch to get a physical address, which is the address of FLASH 0x0+EBOOT_OFFSET(0X10000), and then finally calls launch(PA) to enter OAL's startup.s. But sometimes it can enter ARMINIT, and then jump to the RTC driver in the BSP to execute (maybe it was called somewhere) and drive NAND FLASH. The printed information is as follows: 321 ---------This is the information printed in OAL's STARTUP Windows CE Kernel for ARM (Thumb Enabled) Built on Jun 3 2009 at 10:47:01 //This should be ARMINIT ProcessorType=0411 Revision=7 sp_abt=ffff5000 sp_irq=ffff2800 sp_undef=ffffc800 OEMAddressTable = 9ca89378 +OEMInit -OEMInit Error Reporting Memory Reserved, dump size = 00020000 Booting Windows CE version 5.00 for (ARM) Old or invalid version stamp in kernel structures - starting clean! Configuring: Primary pages: 9121, Secondary pages: 0, Filesystem pages = 4560 Booting kernel with clean memory configuration: Memory Sections: [0] : start: 8193c000, extension: 00003000, length: 023a1000 Sp=ffffc7cc RTC:Read time from PCF8563....sucessed OEMIoControl:Unsupported Code 0x101008c - device 0x0101 func 35 Initialize NAND Flash Controller. NAND_Init:return 0x1 Initialize NAND Flash Controller Successfully. //This is not found? However, with the same kernel and the same BOOT, repeatedly restarting and shutting down several times, only 321 will be printed out. ---------This is the information printed in the STARTUP of OAL. Please help analyze it! , Thank you!
It is better to tell LZ how to find the answer than to tell him the answer directly. In config.bib, there are the following two lines: $(NKNAME) $(NKSTART) $(NKLEN) RAMIMAGE RAM $(RAMSTART) $(RAMLEN) RAM 1. After substituting the values, we get: Could you please explain the meaning of this line?? NK 80100000 01B00000 RAMIMAGE RAM 81F00000 02100000 RAM 2. If it is written as, what does it mean and what is the difference between it and 1.?? NK 9CA00000 01B00000 RAMIMAGE RAM 80100000 03F00000 RAM LZ wants to write NK to flash and execute it in flash, should he write 1. or 2.??? Paul, Chao @ Techware
Oh, thank you very much, paul_chao: Mine should be the second one! Do you mean that the NKSTART defined in config.bib does not correspond to the starting position defined in EBOOT, so although it is started, there is an abnormal phenomenon? Can I understand it this way, that the NKSTART and other fields in config.bib are added to NK when compiling the kernel, and the information in NK is obtained through the TOC pointer when parsing the kernel, that is, the configuration information in config.bib. So my question is: the configuration information I obtained through TOC is started in SDRAM, but it must be compared with the virtual address of FLASH, and it must be started at the virtual address of FLASH, such as: ( ((DWORD)lpdwToc & 0x90000000) == 0x80000000 ) This sentence caused the abnormality. So it seems that I should directly modify config.bib and change the address of NKSTART to the corresponding address of FALSH.
提升卡
变色卡
千斤顶
京公网安备 11010802033920号
