Freescale mx53 - use uboot boot eboot and winec7
-
Wednesday, August 31, 2011 2:27 AM
Dear all,
I am working @ i.mx53 serires project, OS is windows embedded compact 7 (winec7).
I am trying to use u-boot to boot e-boot, but got some troubles.
My eboot.nb0 and nk.nb0 work well at pure wince environment (eboot+winec7 kernel).
But if I use following u-boot commands to load eboot.nbo and try to boot it, it doesn't have any response.
u-boot> fatload mmc 0:2 0x70041000 eboot.nb0 ; // 0x70041000 is the entry point to IVT header
u-boot> go 0x70042000; // 0x70042000 is the entry point to Startup of eboot.
<...no response...>
Anyone can tell me how to solve this ??
or if I want to use u-boot to boot winec7, what should be modified ?
(I use u-boot to load winec7 kernel directly, it can boot. But system will idle after some kernel messages.
Suppose there are some args/settings that arranged by e-boot)
/****************************************/
The boot process of freescale mx53 that I understand should be as follows:
IVT will be directly loaded into internal RAM, ROMCODE will use IVT to initial DRAM controller and copy eboot to DRAM.
eboot will initial cpu/cache/registers/... at LEAF_ENTRY StartUp and jump to eboot's KernelStart, finally jump to C entrypoint main.c::main().
main() will initial platform, load nk.nb0, and jump to it, then winec 7 kernel starts.
/****************************************/
.
All Replies
-
Wednesday, August 31, 2011 8:22 AM
Hi,
check the mmu settings. Is the mmu turned off before you jump to the eboot code?
Why do you need eboot? I would start nk.nb0 directly with u-boot.
Do you have a xldr for loading eboot to SDRAM? Or does eboot handle the copy mechanism form Boot media (NAND Flash, ...) to SDRAM? If eboot handle the relocation I think you need to remove this part of code from eboot.
Best regards,
Andreas
-
Wednesday, August 31, 2011 9:50 AM
Dear Andreas,
>>check the mmu settings. Is the mmu turned off before you jump to the eboot code?
But the mmu seems to be turn on before jump to eboot main.c::main() in pure wince environment. (as attached code block Enable MMU)
Did you mean I should turn off mmu before eboot startup ? ? Did u-boot turn on the mmu ??
>>Why do you need eboot? I would start nk.nb0 directly with u-boot.
I use u-boot to load winec7 kernel directly before, it can bootup. But system will be idle after some kernel messages.
(Both of using u-boot to load omap35x wince 6 and freescale winec 7.)
Thus I guess there are some args/settings that arranged by e-boot.
or What is the key point to solve this issue ??
>>Do you have a xldr for loading eboot to SDRAM? Or does eboot handle the copy mechanism form Boot media (NAND Flash, ...) to SDRAM?
Yes, there is a xldr mechanism.
But in freescale i.mx53 project, there is a ROMCODE which will read a fixed address IVT table from sd card to initial DRAM controller,
and load eboot to DRAM then jump to it. eboot should not handle the relocation ?!
ALIGN LEAF_ENTRY KernelStart ; Copy the bootloader image from flash to RAM. The image is configured ; to run in RAM, but is stored in flash. Absolute address references ; should be avoided until the image has been relocated and the MMU enabled. ; ; NOTE: The destination (RAM) address must match the address in the ; bootloader's .bib file. The latter dictates the code fix-up addresses. ; ; Check if we are running from NOR flash mov r0, pc ldr r1, =IMAGE_BOOT_NORDEV_NOR_PA_START cmp r0, r1 blt CODEINRAM ldr r1, =IMAGE_BOOT_NORDEV_NOR_PA_END cmp r0, r1 bgt CODEINRAM ldr r8, =IMAGE_BOOT_BOOTIMAGE_NOR_PA_START ldr r1, =IMAGE_BOOT_BOOTIMAGE_RAM_PA_START ldr r2, =(IMAGE_BOOT_BOOTIMAGE_RAM_SIZE / 16) ; Bootloader image length (this must be <= the NK ; length in the .bib file). We are block-copying ; 16-bytes per iteration. ; Do 4x32-bit block copies from flash->RAM (corrupts r4-r7). ; 10 ldmia r8!, {r4-r7} ; Loads from flash (post increment). stmia r1!, {r4-r7} ; Stores to RAM (post increment). subs r2, r2, #1 ; bne %B10 ; Done? ; Now that we've copied ourselves to RAM, jump to the RAM image. Use the "CodeInRAM" label ; to determine the RAM-based code address to which we should jump. ; ldr r1, =IMAGE_BOOT_BOOTIMAGE_NOR_PA_START adr r2, CODEINRAM sub r2, r2, r1 ldr r0, =IMAGE_BOOT_BOOTIMAGE_RAM_PA_START add r2, r0, r2 mov pc, r2 nop nop nop CODEINRAM ; Now that we're running out of RAM, construct the first-level Section descriptors ; to create 1MB mapped regions from the addresses defined in the OEMAddressTable. ; This will allow us to enable the MMU and use a virtual address space that matches ; the mapping used by the OS image. ; ; We'll create two different mappings from the addresses specified: ; [8000 0000 --> 9FFF FFFF] = Cacheable, Bufferable ; [A000 0000 --> BFFF FFFF] = NonCacheable, nonBufferable ; BUILDTTB add r11, pc, #g_oalAddressTable-(.+8) ; Pointer to OEMAddressTable. ; Set the TTB. ; ldr r9, =IMAGE_BOOT_BOOTPT_RAM_PA_START ldr r0, =0xFFFFC000 ; and r9, r9, r0 ; Mask off TTB to be on 16K boundary. mcr p15, 0, r9, c2, c0, 0 ; Set the TTB. mov r10, r9 ; Save TTB address ; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ; ~~~~~~~~~~ MAP CACHED and BUFFERED SECTION DESCRIPTORS ~~~~~~~~~~~~~~~~~~ ; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mov r0, #0x0A ; Section (1MB) descriptor; (C=1 B=0: cached write-through). orr r0, r0, #0x400 ; Set AP. 20 mov r1, r11 ; Pointer to OEMAddressTable. ; Start Crunching through the OEMAddressTable[]: ; ; r2 temporarily holds OEMAddressTable[VA] ; r3 temporarily holds OEMAddressTable[PHY] ; r4 temporarily holds OEMAddressTable[#MB] ; 25 ldr r2, [r1], #4 ; Virtual (cached) address to map physical address to. ldr r3, [r1], #4 ; Physical address to map from. ldr r4, [r1], #4 ; Number of MB to map. cmp r4, #0 ; End of table? beq %F29 ; r2 holds the descriptor address (virtual address) ; r0 holds the actual section descriptor ; ; Create descriptor address. ; ldr r6, =0xFFF00000 and r2, r2, r6 ; Only VA[31:20] are valid. orr r2, r9, r2, LSR #18 ; Build the descriptor address: r2 = (TTB[31:14} | VA[31:20] >> 18) ; Create the descriptor. ; ldr r6, =0xFFF00000 and r3, r3, r6 ; Only PA[31:20] are valid for the descriptor and the rest will be static. orr r0, r3, r0 ; Build the descriptor: r0 = (PA[31:20] | the rest of the descriptor) ; Store the descriptor at the proper (physical) address ; 28 str r0, [r2], #4 add r0, r0, #0x00100000 ; Section descriptor for the next 1MB mapping (just add 1MB). sub r4, r4, #1 ; Decrement number of MB left. cmp r4, #0 ; Done? bne %B28 ; No - map next MB. bic r0, r0, #0xF0000000 ; Clear section base address field. bic r0, r0, #0x0FF00000 ; Clear section base address field. b %B25 ; Get and process the next OEMAddressTable element. ; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ; ~~~~~~~~~~ MAP UNCACHED and UNBUFFERED SECTION DESCRIPTORS ~~~~~~~~~~~~~~ ; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 29 tst r0, #8 ; Test for 'C' bit set (means we just used ; above loop structure to map cached and buffered space). bic r0, r0, #0x0C ; Clear cached and buffered bits in the descriptor (clear C&B bits). add r9, r9, #0x0800 ; Pointer to the first PTE for "unmapped uncached space" (0x2000 0000 + V_U_Adx). bne %B20 ; Repeat the descriptor setup for uncached space (map C=B=0 space). ; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ; ~~~~~~~~~~ MAP Execption Vector Table ADDRESS TO 0x00000000 for place exception vector ~~~~~~~~~~~~~~ ; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ; Create the descriptor. ldr r1, =IMAGE_SHARE_EVT_RAM_PA_START orr r0, r1, #(2 << 0) ; L1D[1:0) = 2 = 1MB Section orr r0, r0, #(1 << 10) ; L1D[11:10] = 1 = AP is R/W privileged; str r0,[r10] ; Create descriptor for 1M identity mapping to allow MMU enable transition. ; NOTE: code assume EBOOT does not span 1M boundary from current execution point. and r1, pc, r6 orr r0, r1, #(2 << 0) ; L1D[1:0) = 2 = 1MB Section orr r0, r0, #(1 << 10) ; L1D[11:10] = 1 = AP is R/W privileged orr r2, r10, r1, LSR #18 ; &L1D = TTB + (VA[31:20] >> 18) ldr r3, [r2] ; Save existing mapping str r0, [r2] ; Create identity mapping ACTIVATEMMU ; The 1st Level Section Descriptors are setup. Initialize the MMU and turn it on. ; mov r1, #1 mcr p15, 0, r1, c3, c0, 0 ; Set up access to domain 0. mov r0, #0 mcr p15, 0, r0, c8, c7, 0 ; Flush the instruction and data TLBs. mcr p15, 0, r1, c7, c10, 4 ; Drain the write and fill buffers. mrc p15, 0, r1, c1, c0, 0 ; Read control register orr r1, r1, #0x1 ; Enable MMU. orr r1, r1, #0x1000 ; Enable IC. orr r1, r1, #0x4 ; Enable DC. ldr r4, =VirtualStart ; Get virtual address of 'VirtualStart' label. cmp r4, #0 ; Make sure no stall on "mov pc,r4" below. mcr p15, 0, r1, c1, c0, 0 ; Enable MMU and caches mov pc, r4 ; Jump to virtual address nop ; We are now running virtual address space. VirtualStart str r3, [r2] ; Restore mapping overwritten by identity ; mapping mcr p15, 0, r2, c8, c7, 0 ; Flush the I&D TLBs ;Setup irq stack mrs r0, cpsr ; r0 = CPSR mov r0, #ARM_CPSR_MODE_IRQ ; enter irq mode orr r0, r0, #ARM_CPSR_IRQDISABLE ; disable normal IRQ orr r0, r0, #ARM_CPSR_FIQDISABLE ; disable fast IRQ msr cpsr_c, r0 ; update CPSR control bits ldr sp, =(IMAGE_BOOT_STACK_RAM_CA_START+228*1024) ;reserve the last 4k for isr stack. ; Set up EBOOT stack mrs r0, cpsr ; r0 = CPSR mov r0, #ARM_CPSR_MODE_SVC ; enter supervisor mode orr r0, r0, #ARM_CPSR_IRQDISABLE ; disable normal IRQ orr r0, r0, #ARM_CPSR_FIQDISABLE ; disable fast IRQ orr r0, r0, #ARM_CPSR_PRECISE ; enable precise data aborts msr cpsr_xc, r0 ; update CPSR control bits ldr sp, =(IMAGE_BOOT_STACK_RAM_CA_START) ; Set up exception vector mov r8, #0 ; (r8) = ptr to exception vectors add r7, pc, #VectorInstructions - (.+8) ldmia r7!, {r0-r3} ; load 4 instructions stmia r8!, {r0-r3} ; store the 4 vector instructions ldmia r7!, {r0-r3} ; load 4 instructions stmia r8!, {r0-r3} ; store the 4 vector instructions ldr r7, =VectorTable ; (r0) = VA of VectorTable add r8, r8, #0x3E0-(8*4) ; (r8) = target location of the vector table ldmia r7!, {r0-r3} stmia r8!, {r0-r3} ldmia r7!, {r0-r3} stmia r8!, {r0-r3} ;Enable Interrupt mrs r0, cpsr ; r0 = CPSR mov r0, #ARM_CPSR_MODE_SVC ; enter supervisor mode bic r0, r0, #ARM_CPSR_IRQDISABLE ; enable fast IRQ msr cpsr_c, r0 ; update CPSR control bits ; Jump to the C entrypoint. ; bl main ; Jump to main.c::main(), never to return... nop nop nop STALL2 b STALL2
-
Wednesday, August 31, 2011 9:55 AM
Hi,
how does your eboot.bib looks like? I think the load address you are using is wrong. I think it should be 0x7004000.
Best regards,
Mike
-
Wednesday, August 31, 2011 10:16 AM
Hi,
>>Did you mean I should turn off mmu before eboot startup ? ? Did u-boot turn on the mmu ??
With the default settings I think no, but you need to ensure the MMU is turned off before you jump to WinCE.
I use also U-Boot to boot WinCE and I turn on the MMU in U-Boot to speed up some copy and unzip procedures.
>>I use u-boot to load winec7 kernel directly before, it can bootup. But system will be idle after some kernel messages
What are your debug messages?
The input from Mike is interesting. Check your ROMOFFSET in the eboot.bib file. You should have something like this:
IF IMGSDMMC ; (0x93700000 + 0x00020000) = (0x80040000 + ROMOFFSET) & 0xFFFFFFFF ; ==> ROMOFFSET = 0x136E0000 ROMOFFSET=0x136E0000 ENDIF
Best regards,
Andreas
-
Wednesday, August 31, 2011 10:31 AM
Dear Mike,
eboot map: (First IVT 4K + offset 4K eboot body) = 512K
ROMCODE will load all sd content to 0x70040c00 (virtual address 0x80040c00)
Thus the virtual memory content is as follows:
---------------------------------------------
0x80040c00 ~ 0x80041000 : MBR (SIZE: 1K)
0x80041000 ~ IVT entry address (SIZE: 4K)
0x80042000 ~ eboot starup (SIZE: 512K-4K)
...
0x80200000 ~ nk.nb0
...
-----------------------------------------------
Thus I load eboot to 0x70041000 to match the memory map
And I checked the normal situation of eboot+wince7. The Startup function is located at virtual address 0x80042000.
I had tried 0x70040000, but can't bootup.
Eboot.map
0001:00001000 StartUp 00012000 f bootcmn:startup.obj
0001:000014a4 KernelStart 000124a4 f bootcmn:startup.obj
0001:00056124 main 00067124 f bootcmn:main.obj
0001:0006ce18 BootloaderMain 0007de18 f oal_blcommon:blcommon.obj
eboot.bib
;------------------------------------------------------------------------------ ; ; Copyright (C) 2007-2010, Freescale Semiconductor, Inc. All Rights Reserved. ; THIS SOURCE CODE, AND ITS USE AND DISTRIBUTION, IS SUBJECT TO THE TERMS ; AND CONDITIONS OF THE APPLICABLE LICENSE AGREEMENT ; ;------------------------------------------------------------------------------ ; ; OS MEMORY MAP BOOTLOADER / IPL MEMORY MAP ; ; OS MEMORY MAP BOOTLOADER MEMORY MAP ; ; +---- 8000.0000 ----+ ; ARGS (4 KB) | | ARGS (4 KB) ; +---- 8000.1000 ----+ ; | | XLDR Image (4 KB) ; | 8000.2000 ----+ ; CSPDDK (32 KB) | | ; +---- 8000.9000 | Bootloader / IPL Stack (232 KB) ; | | ; | 8003.C000 ----+ ; | | Bootloader / IPL Page Table (16 KB) ; unused (988 KB) | 8004.0000 ----+ ; | | ; | | Bootloader Image (512 KB) ; | | ; | 800C.0000 ----+ ; | | Bootloader / IPL RAM (1280 KB) ; +---- 8020.0000 ----+ ; | | ; | | ; | | ; NK Code (48 MB) | | ; | | ; | | ; | | ; **auto-size** +---- 80B1.0000 | Flash Cache ; | | ; | | ; | | ; NK RAM (63 MB) | | ; | | ; | | ; +---- 8F700000 -----+ ; | | ; | | ; IPU (9 MB) | | ; | | ; | | ; +---- 9000.0000 ----+ ; ;------------------------------------------------------------------------------ MEMORY ; Driver globals area (used to pass config info to kernel, don't change unless ; you update config.bib) NOTE: We're using physical addresses here. ; Name Start Size Type ; ------- -------- -------- ---- ARGS 80000000 00001000 RESERVED XLDR 80001000 00001000 RESERVED STACK 80002000 0003A000 RESERVED PAGE_TABLE 8003C000 00004000 RESERVED $(TARGETNAME) 80040000 00080000 RAMIMAGE ;IPL is obsolete, remove it to avoid potential romimage issue ;IPL 800C0000 00040000 RESERVED RAM 80100000 000FC000 RAM FEC 801FC000 00004000 RESERVED ; Flash cache (used to store eboot.bin or nk.bin before flashing) FCACHE 80200000 07E00000 RESERVED ; SCREEN BUFFER PIC 90000000 00200000 RESERVED CONFIG AUTOSIZE=OFF COMPRESSION=OFF PROFILE=OFF KERNELFIXUPS=ON ; Eboot is build to run out of RAM, so ROMSTART and ROMSIZE correspond to the ; RAM address range specified above. ; ROMSIZE =00080000 ROMWIDTH=32 ;ROM* creates eboot.nb0 file ;Notes: ; 1) romimage always adds a 4K page to the beginning of file. To get rid of this 4K page ; we'll specify additional 4K space for RAMIMAGE (above) and then cut it off from ; xldr.nb0 by specifying romstart at an offset of 4k. ; 2) since RAMIMAGE compiles with range 0x0->0x7F000 and we chop off first 4K, ; and flash the remaining 4K at 0x00 on flash; it means we can't have ; absolute addressing in EBOOT code. Only relative addresses should be used. ; 2) if eboot.nb1 is generated you can safely ignore it if it contains only ; pTOC and other debugging data since we don't need them. Look at the generated ; file eboot.map to make sure that your code does not overflow beyond 256k boundary. ; ROMSTART=80041000 ; ; ROMOFFSET applies to the BIN file sections and is used to "move" the image ; into SDMMC or SPI/NAND flash. The bootloader image already on the system will be able to tell ; that the BIN file is destined for flash (versus RAM) based on the address ; formed by RAMIMAGE Start plus ROMOFFSET. ; IF IMGSDMMC ! IF IMGNAND ; CSP_BASE_MEM_PA_NFC+IMAGE_BOOT_BOOTIMAGE_NAND_OFFSET = 0x9F5F0000 + 0x400 = 0x9F5F0400 ; 0x9F5F0400 = (0x80040000 + ROMOFFSET) & 0xFFFFFFFF ; ==> ROMOFFSET = 0x1F5B0000 ROMOFFSET=1F5B0400 ENDIF IF IMGNAND ! IF IMGATA ; 0x9FB00400 = (0x80040000 + ROMOFFSET) & 0xFFFFFFFF ==> ROMOFFSET = 0x1FAC0400 ; (0x9FB00400 is the CA of IMAGE_BOOT_BOOTIMAGE_ATA_PA_START defined in image_cfg.h) ROMOFFSET=1FAC0400 ENDIF IF IMGATA ! ; 0x9F000400 = (0x80040000 + ROMOFFSET) & 0xFFFFFFFF ; ==> ROMOFFSET = 1EFC0400 ROMOFFSET=1EFC0400 ENDIF ENDIF ENDIF IF IMGSDMMC ; 0x9FA00400 = (0x80040000 + ROMOFFSET) & 0xFFFFFFFF ==> ROMOFFSET = 0x1F9C0400 ; (0x9FA00400 is the CA of IMAGE_BOOT_BOOTIMAGE_SD_PA_START defined in image_cfg.h) ROMOFFSET=1F9C0400 ENDIF MODULES ; Name Path Memory Type ; ------ ---------------------------------------------- ----------- nk.exe $(SG_OUTPUT_ROOT)\platform\$(_TGTPLAT)\target\$(_TGTCPU)\$(WINCEDEBUG)\$(TARGETNAME).exe $(TARGETNAME)
-
Wednesday, August 31, 2011 11:13 AM
Dera Andreas and Mike,
What value I should adjust if ROMOFFSET=1F9C0400 in eboot.bib:
IF IMGSDMMC
; 0x9FA00400 = (0x80040000 + ROMOFFSET) & 0xFFFFFFFF ==> ROMOFFSET = 0x1F9C0400
; (0x9FA00400 is the CA of IMAGE_BOOT_BOOTIMAGE_SD_PA_START defined in image_cfg.h)
ROMOFFSET=1F9C0400
ENDIF
====================>>What are your debug messages?
Here is the log message if I use u-boot to boot i.mx53 winec7 directly.
SOM-CMX53 U-Boot >fatload mmc 0:2 0x70200000 nk.nb0 SOM-CMX53 U-Boot >go 0x70200000 ## Starting application at 0x70200000 ... INFO:OALLogSetZones: dpCurSettings.ulZoneMask: 0xb BSP Clock Configuration: OSC = 24000000 Hz PLL1 = 1000000000 Hz PLL2 = 400000000 Hz PLL3 = 216000000 Hz PLL4 = 455000000 Hz LP_APM = 24000000 Hz ARM = 1000000000 Hz AXI_A = 400000000 Hz AXI_B = 200000000 Hz EMI_SLOW = 133333333 Hz AHB = 133333333 Hz IPG = 66666666 Hz PERCLK = 33333333 Hz CKIL_SYNC = 32768 Hz DDR = 400000000 Hz ARM_AXI = 200000000 Hz IPU_HSP = 200000000 Hz VPU_AXI = 200000000 Hz GPU = 200000000 Hz GPU2D = 200000000 Hz DEBUG_APB = 200000000 Hz ENFC = 26666666 Hz USBOH3 = 54000000 Hz ESDHC1 = 80000000 Hz ESDHC2 = 80000000 Hz ESDHC3 = 80000000 Hz ESDHC4 = 80000000 Hz UART = 21600000 Hz SSI1 = 54000000 Hz SSI2 = 54000000 Hz SSI3 = 54000000 Hz SSI_EXT1 = 10285714 Hz SSI_EXT2 = 10285714 Hz USB_PHY = 24000000 Hz TVE_216_54 = 227500000 Hz DI0 = 0 Hz DI1 = 0 Hz VPU_RCLK = 24000000 Hz SSI_LP_APM = 22579200 Hz SPDIF_XTAL = 24000000 Hz LDB_DIO = 455000000 Hz LDB_DI1 = 455000000 Hz SPDIF0 = 10285714 Hz ESAI = 27000000 Hz ESAI_HCKR = 0 Hz ESAI_HCKT = 0 Hz CAN = 66666666 Hz FIRI = 54000000 Hz CSI_MCLK1 = 54000000 Hz CSI_MCLK2 = 54000000 Hz ECSPI = 54000000 Hz LPSR = 0 Hz PGC = 66666666 Hz ASRC = 113750000 Hz IEEE_CEMX = 18000000 Hz CKIH = 22579200 Hz CKIH2 = 0 Hz Windows CE Kernel for ARM (Thumb Enabled) OEMInit: silicon rev = 0x21 aaa BoardID = 0x0. OALBoard_ID_I2cInit: Trying to init LTC2495 I2C Interface OALPmicInit: Trying to init I2C Interface OALPmicInit: Invalid I2C port OALPmicInit: OALPAtoUA returned NULL OALBoard_ID_I2cIni -
Wednesday, August 31, 2011 11:45 AM
Hi,
your debug messages from the kernel start looks like the messages that I get at i.MX25 at the beginning. You don't get an error message, but the debug messages just end. In my case the function call OALInitializeClockGating() in function OEMInit() disables the serial clock. And in addition to that the debug messages stop, because the UART clock is also disabled.
Maybe you have the same problem.
ROMOFFSET:
You are loading the eboot.nb0 with the fatload u-boot function to SDRAM. So you should try it with ROMOFFSET = 0x0, because eboot is not in Flash in that case.
Best regards,
Andreas
-
Thursday, September 01, 2011 7:30 AM
Dear Andreas and Mike,
>>In my case the function call OALInitializeClockGating() in function OEMInit() disables the serial clock.
I can't find OALInitializeClockGating() in OEMInit().
Not only the debug messages stop, but also the system is idle (can't bootup to desktop).
So, how do u resolve this issue ??
or what is the key point to use u-boot to bootup wince kernel ?? /__\
>>So you should try it with ROMOFFSET = 0x0
I found something interesting.
In eboot.bib //=========================== ; Name Start Size Type; ------- -------- -------- ---- ... $(TARGETNAME) <strong>80040000</strong> 00080000 <strong>RAMIMAGE</strong> ... ... IF IMGSDMMC ; (0x9FA00400 is the CA of IMAGE_BOOT_BOOTIMAGE_SD_PA_START defined in image_cfg.h) ; <strong>0X9FA00400</strong> = <strong>0X80040000</strong> + ROMOFFSET <strong>ROMOFFSET=1F9C0400</strong> ENDIF //=========================== g_oalAddressTable DCD<strong> 0x9FA00000</strong>, <strong>CSP_BASE_MEM_PA_IRAM_1MB</strong>, 1 ; Internal RAM CSP_BASE_MEM_PA_IRAM EQU (0xF8000000) //===========================
ROMOFFSET is offset from IRAM virtual address. ==> Does this mean that eboot copy itself from Internal RAM to DRAM ??
or because ROMCODE executes in Internal RAM, the ROMOFFSET is necessary for ROMCODE to jump to eboot in RAM.
However, I try to re-build eboot with ROMOFFSET = 0x0, but still can't work,
and I can't find the copy mechanism in code now...
Thx ~ -
Thursday, September 01, 2011 7:50 AM
What hardware are you using? Is that the Freescale QSB?
If you use your own hardware you might need to do some more adaptation to the BSP no to stop. You maybe should review the power.c file. There normally the clocks and devices are enabled or disabled.
Are you sure you build your Windows CE and eboot to run in RAM?
Best regards,
Mike Engel
-
Thursday, September 01, 2011 8:21 AM
>> I can't find OALInitializeClockGating() in OEMInit().
In my case the system was also in idle state, because OALInitializeClockGating() disables several clocks. Maybe you have a similar function like OALInitializeClockGating()in your OAL code.
If your debug outputs stop you can't see possible other boot problems. You could only see that the explorer.exe don't start.
Do you have some possibilities for debugging? I think you should search the point where the system is going to idle state.
>> ROMOFFSET = 0x0
Which ROMOFFSET use your WinCE Image? Have a look at your config.bib file.
Best regards,
Andreas
-
Thursday, September 01, 2011 9:36 AM
Derar Mike,
This is a custom board, not Freescale QSB.
The ( eboot.nbo + nk.nb0 ) can work well in 512M DDR3 RAM, should I need to check power.c ??
By the way, I did a experiment.
I add a gpio control to control a beep in eboot startup.s KernelStart function.
After u-boot load eboot at 0x70041000, jump to KernelStart(0x700424a4), I can hear beep but system will be idle soon.
If jump to startup(0x80042000), I can't hear beep.
u-boot command:
fatload mmc 0:2 0x70041000 eboot.nb0
go 0x700424a4
---beep---idle....
-
Thursday, September 01, 2011 9:54 AM
Dear Andreas,
So u suggest me using u-boot to boot kernel directly and resolve the system down problem ?!
How do u handle the share region area between eboot and kernel ?
Here is the ROMOFFSET in config.bib.
Seems my FLASH PHYSICAL ADDRESS is 0X9FA00000... I have no idea about this value comes from...
So, I need to modify ROMOFFSET = 0 in config.bib, too ??
IF IMGSDMMC ; ROMOFFSET = (FLASH PHYSICAL ADDRESS - ULDR_PHSYICAL_START) % 0x100000000 ; = ( 0x9FA80400 - 0x80200000 ) % 0x100000000 = ROMOFFSET=1F880400 ENDIF
-
Thursday, September 01, 2011 10:16 AM
Dear Andreas,
I set ROMOFFSET=0 both in config.bib and eboot.bib.
Pure WinCE 7 (Eboot + kernel ) works well.
Why ? ... These two value seem have no effect.
eboot and kernel will not use this offset ?
-
Thursday, September 01, 2011 10:34 AM
>> How do u handle the share region area between eboot and kernel ?
You are speaking from the arguments area? I insert some code to U-Boot which generates the arguments area for WinCE. But I think you could start WinCE without the arguments block.
If you use u-boot for WinCE you don't need eboot. I think if you use both you waste boot time.
I reflect on ROMOFFSET. You use the *.nb0 files. These files you should be able to start directly. ROMOFFSET is only used for the *.bin files.
I still thinking, that you have a problem with your clock management. Have a look at power.c like Mike mentioned. I'm sure that the OAL code disables some clocks and in addition to that the system hangs.
Best regards,
Andreas
-
Thursday, September 01, 2011 10:51 AM
I agree with Andreas if your nk.nb0 image fails their might be some clocks that are not enabled that will cause hang your system.
So you should review your OAL sources.
Best regards,
Mike
-
Tuesday, September 06, 2011 8:11 AM
Dear Mike and Andreas,
Thx to your suggestion, after modify power.c, I can boot up wince7 by u-boot.
But I don't understand why ~ Plz kindly provide me a thinking why removing following code (#if 0) can enter kernel.
//=================//=========================== VOID OALPowerInit() { .... .... // Disable all unused clocks CLRREG32(&g_pCCM->CCGR[0], CCM_CGR0_ARM_DEBUG_MASK | CCM_CGR0_DAP_MASK | CCM_CGR0_TPIU_MASK | CCM_CGR0_CTI2_MASK | CCM_CGR0_CTI3_MASK | CCM_CGR0_ROMCP_MASK | CCM_CGR0_ROM_MASK | CCM_CGR0_IIM_MASK ); <strong>#if 0 // remove for uboot </strong> CLRREG32(&g_pCCM->CCGR[1], CCM_CGR1_TMAX1_MASK | CCM_CGR1_TMAX2_MASK | CCM_CGR1_TMAX3_MASK | CCM_CGR1_UART1_IPG_MASK | CCM_CGR1_UART1_PERCLK_MASK | CCM_CGR1_UART2_IPG_MASK | CCM_CGR1_UART2_PERCLK_MASK | CCM_CGR1_UART3_IPG_MASK | CCM_CGR1_UART3_PERCLK_MASK | CCM_CGR1_I2C1_MASK | CCM_CGR1_I2C2_MASK | CCM_CGR1_I2C3_MASK | CCM_CGR1_FIRI_IPG_MASK | CCM_CGR1_FIRI_SERIAL_MASK | CCM_CGR1_SCC_MASK ); #endif .... .... <strong>#if 0 // remove for uboot</strong> // Disable PLL3 if unused if (g_pDdkClkConfig->rootRefCount[DDK_CLOCK_BAUD_SOURCE_PLL3] == 0) { CLRREG32(&g_pDPLL3->DP_CTL, CSP_BITFMASK(DPLL_DP_CTL_UPEN)); } #endif .... .... }
Although I can enter kernel, I still got system hang ~ Plz provide me more suggestions if you have experience~
Here is my log message：
<span>SOM-CMX53 U-Boot > go 0x70200000 ## Starting application at 0x70200000 ... INFO:OALLogSetZones: dpCurSettings.ulZoneMask: 0xb BSP Clock Configuration: OSC = 24000000 Hz PLL1 = 1000000000 Hz PLL2 = 400000000 Hz PLL3 = 216000000 Hz PLL4 = 455000000 Hz LP_APM = 24000000 Hz ARM = 1000000000 Hz AXI_A = 400000000 Hz AXI_B = 200000000 Hz EMI_SLOW = 133333333 Hz AHB = 133333333 Hz IPG = 66666666 Hz PERCLK = 33333333 Hz CKIL_SYNC = 32768 Hz DDR = 400000000 Hz ARM_AXI = 200000000 Hz IPU_HSP = 200000000 Hz VPU_AXI = 200000000 Hz GPU = 200000000 Hz GPU2D = 200000000 Hz DEBUG_APB = 200000000 Hz ENFC = 26666666 Hz USBOH3 = 54000000 Hz ESDHC1 = 80000000 Hz ESDHC2 = 80000000 Hz ESDHC3 = 80000000 Hz ESDHC4 = 80000000 Hz UART = 21600000 Hz SSI1 = 54000000 Hz SSI2 = 54000000 Hz SSI3 = 54000000 Hz SSI_EXT1 = 10285714 Hz SSI_EXT2 = 10285714 Hz USB_PHY = 24000000 Hz TVE_216_54 = 227500000 Hz DI0 = 0 Hz DI1 = 0 Hz VPU_RCLK = 24000000 Hz SSI_LP_APM = 22579200 Hz SPDIF_XTAL = 24000000 Hz LDB_DIO = 455000000 Hz LDB_DI1 = 455000000 Hz SPDIF0 = 10285714 Hz ESAI = 27000000 Hz ESAI_HCKR = 0 Hz ESAI_HCKT = 0 Hz CAN = 66666666 Hz FIRI = 54000000 Hz CSI_MCLK1 = 54000000 Hz CSI_MCLK2 = 54000000 Hz ECSPI = 54000000 Hz LPSR = 0 Hz PGC = 66666666 Hz ASRC = 113750000 Hz IEEE_CEMX = 18000000 Hz CKIH = 22579200 Hz CKIH2 = 0 Hz Windows CE Kernel for ARM (Thumb Enabled) +OEMInit OEMInit: silicon rev = 0x21 aaa BoardID = 0x0. OALBoard_ID_I2cInit: Trying to init LTC2495 I2C Interface OALPmicInit: Trying to init I2C Interface OALPmicInit: Invalid I2C port OALPmicInit: OALPAtoUA returned NULL OALBoard_ID_I2cInit: OALI2cInit Error! BoardID = 0x0. OALPowerInit OALIntrInit OALTimerGetClkFreq IOCTL_KITL_STARTUP VFP_Init OEMGetRamTable cleanUp -OEMInit PID:00400002 TID:00410002 +OEMGetRealTime ....repeat PID:00400002 TID:xxxxxxxx +OEMGetRealTim</span><span> PID:00400002 TID:00500002 +OEMGetRealTime PID:00400002 TID:00520002 OALIoCtlHalInitRTC +++ PID:00400002 TID:00520002 OALIoCtlHalInitRTC(2006/1/1 12:0:0.000) PID:00400002 TID:00520002 WARNING: SRTC was reset. PID:00400002 TID:00520002 GGG. PID:00400002 TID:00520002 -OALIoCtlHalInitRTC(rc = 1) PID:00400002 TID:00520002 +OEMGetRealTime ....repeat PID:00400002 TID:oooooooo +OEMGetRealTime</span><span> .........<system hang>........</span>thx ~
OOBin
-
Tuesday, September 06, 2011 11:45 AM
It might be that you U-Boot enabled PLL3 and some peripherals that use that PLL3 as source clock and when you disable that PLL without disabling the peripheral it might cause hanging your system.
I would recommend you to review all your platform specific settings you do in U-Boot and then verify if they do not confict with your settings you maybe apply in Windows CE. It seems that is currently basically a problem of some miss configuration between U-Boot and Windows Ce.
Best regards,
Mike
-
Tuesday, September 06, 2011 12:19 PM
Dear Mike,
After some modifications of eboot statup (remove PLL and CCM initial settings),
I can use uboot to bootup eboot, then download wince ( uboot->eboot(m)->wince kernel(m)). (m means modified.)
But wince still got hang.
Under the same wince kernel (m), but use original eboot. Wince can bootup and work correctly. (eboot -> wince kernel(m) )
Fail: uboot->eboot(m)->wince kernel(m), uboot -> wince kernel(m)
Pass: eboot -> wince kernel(m)
It concluded that wince kernel (m) is ok.
It seems that some configurations between uboot and wince are missing as you said.
I am not family with uboot. I will try to find the uboot source code and check PLL initial settings.
Plz give me some suggestions if you have any idea. Thx.
-
Tuesday, September 06, 2011 1:39 PM
I would compare the configuration that eboot does and u-boot there must be some difference that make your Windows CE hang when booting with U-Boot. Have you tried to boot Windows CE without eboot only using u-boot? You can create a raw binary out of your nk.bin with the tool cvrtbin (http://msdn.microsoft.com/en-us/library/ee504639.aspx). Maybe that can help you further.
Sorry but that is all I can suggest you because I don’t know you hardware settings. But I think you are close to solve that problem.
Best regards,
Mike
-
Tuesday, September 06, 2011 3:33 PM
Dear Mike,
Yes, I had tried to boot Windows CE without eboot only using u-boot with some modifications by removing some clock management in OALPowerInit() as above article.
I am always using raw binary file: nk.nb0.
However, thx a lot. Keep working ... ~
-
Wednesday, September 07, 2011 11:53 AMDear Mike and Andreas,>> uboot to bootup eboot, then download wince ( uboot->eboot(m)->wince kernel(m)). (m means modified.) But wince still got hang.I can resolve this issue by modify PLL initial codes in startup.s. Now my system can get into wince desktop.However, there is still some clock issues (noise and flicker) during eboot drawing logo.Here is the problem which might be root cause but I don'w know how to resolve it:I can't config PERIPH_APM_CLK and PLL2.System seems stop if meet following codes:1) // Wait for switch of main_bus_clk to PLL3while (INREG32(&g_pCCM->CDHIPR));2) // Configure PLL2 for 400 MHzOUTREG32(&g_pDPLL2->DP_OP, 0x80);OUTREG32(&g_pDPLL2->DP_MFN, 0x1);OUTREG32(&g_pDPLL2->DP_MFD, 0x2);OUTREG32(&g_pDPLL2->DP_CTL, 0x232);If you know that, plz share with me ~ thx ~
-
Friday, September 09, 2011 9:39 AM
Dear all,
It will always cause system hang if I configure PERIPH clk.
Following code in \src\oal\oallib\startup.s will cause hang.
Plz help me if you know how to configure i.mx53 PLL clock in eboot correctly under uboot booting.
ldr r1, =CSP_BASE_REG_PA_DPLL1
ldr r2, =CSP_BASE_REG_PA_DPLL2
ldr r3, =CSP_BASE_REG_PA_DPLL3
ldr r4, =CSP_BASE_REG_PA_CCM
...
1)
; Configure main_bus_clk to be sourced from PERIPH_APM_CLK (mux input 1)
; must remove following code for uboot
ldr r0, [r4, #CCM_CBCDR_OFFSET]
orr r0, r0, #CCM_CBCDR_PERIPH_CLK_SEL
str r0, [r4, #CCM_CBCDR_OFFSET]
2)
; Restart PLL2 with new configuration
; must remove following code for uboot
ldr r0, =0x000001232
str r0, [r2, #DPLL_DP_CTL]
3)
; CCM Bus Clock Divider Register (CBCDR):
; must remove following code for uboot
ldr r0, =0x06117180
str r0, [r4, #CCM_CBCDR_OFFSET]
thx
-
Friday, September 09, 2011 2:07 PM
Why you want to reconfigure you PLL clock settings in eboot when you have done it already in U-Boot. I would setup all clock settings in U-Boot because it is you main bootloader and in eboot do nothing. Reconfiguration of the clocks might cause the problems you have because it can impact timings to the RAM memory.
I would only use u-boot and Windows CE or ebootand Windows CE nothing else.
Best regards,
Mike
-
Friday, September 09, 2011 4:25 PM
Dear Mike,
Use uboo-wince, I can enter wince kernel, but I still got system hang when loading driver ~
I didn't find the solution to improve that, thus I tried eboot with some PLL configureations, then wince can boot to desktop.
Maybe eboot just solve the power.c problem that you menthion before.
Use eboot due to following lazy reason:
1) eboot will cost 1~2 seconds booting time.
2) eboot can maintain the share args region without modifying uboot, and I am no familiar with uboot.
3) I can't find out why wince will got hang with only uboot, thus I try to use eboot to solve everything.
4) I am wondering the PLL configuration in uboot is different from eboot, I trust eboot more because eboot-wince is stable before.
-
Friday, September 23, 2011 7:04 AM
I tried this out myself with a iMX25 uboot and WinCE - although my WinCE image resides in NAND flash not an MMC, and I can't get WinCE to launch.
Like yourself I can go uboot->eboot->wince, just not uboot->wince. I get nothing if I do that, although I'm using the nand read command rather than the fatload command that you were. Has anyone got any tips on what I'd need to do to be able to use uboot to load wince directly out of nand?
I even tried modifying xldr to skip eboot and load wince directly into ram and that didn't work either! I can't even think what the problem could be there... The memory copy works but when I jump (to the address eboot jumps to) nothing happens and the unit aborts back to the bootstrap protocol.
If the arguments are the issue just create them in the 1st few functions of WinCE, debugserial init or something.
-
Friday, September 23, 2011 9:15 AM
If you need eboot to boot your Windows CE than you need to check your bootup code between U-Boot and eboot to make sure u-boot does the same low level configuration.
If you download (TFTP) your Windows CE image with u-Boot (tftp <RAM addr> <filename> that address has to be the physical address where your RAM is mapped to the processor. You can use the ocnfig.bib information to get the offset in the RAM where you need to download you Windows CE image. Than you do a go <RAM addr> to jump to your image.
Best regards,
Mike
-
Friday, October 21, 2011 9:07 AM
Dear Mike,
I can boot up wince by ubook directly now (PLL init problem), however, there are some error msgs when wince starts.
Error msgs will also occur if I move my mouse in Wince, but my mouse seems ok to operate Wince.
Could u plz share with me if you know what's wrong about below error msgs:
------------------------------------------------------------------------------------------
PID:00400002 TID:03D90002 Exception 'Data Abort' (0x4): Thread-Id=03d90002(pth=c 0827a98), Proc-Id=00400002(pprc=8482f5e0) 'NK.EXE', VM-active=013f000a(pprc=c080 e880) 'shell.exe' PID:00400002 TID:03D90002 PC=80212150(NK.EXE+0x00012150) RA=70001000(???+0x70001 000) SP=d144fc48, BVA=00000000 PID:00400002 TID:03D90002 Exception 'Data Abort' (0x4): Thread-Id=03d90002(pth=c 0827a98), Proc-Id=00400002(pprc=8482f5e0) 'NK.EXE', VM-active=059c0012(pprc=c087 8960) 'explorer.exe' PID:00400002 TID:03D90002 PC=80212150(NK.EXE+0x00012150) RA=70001000(???+0x70001 000) SP=d144fc48, BVA=00000000 PID:00400002 TID:03D90002 Exception 'Data Abort' (0x4): Thread-Id=03d90002(pth=c 0827a98), Proc-Id=00400002(pprc=8482f5e0) 'NK.EXE', VM-active=059c0012(pprc=c087 8960) 'explorer.exe' PID:00400002 TID:03D90002 PC=80212150(NK.EXE+0x00012150) RA=70001000(???+0x70001 000) SP=d144fc48, BVA=00000000 PID:00400002 TID:03D90002 Exception 'Data Abort' (0x4): Thread-Id=03d90002(pth=c 0827a98), Proc-Id=00400002(pprc=8482f5e0) 'NK.EXE', VM-active=059c0012(pprc=c087 8960) 'explorer.exe' PID:00400002 TID:03D90002 PC=80212150(NK.EXE+0x00012150) RA=70001000(???+0x70001 000) SP=d144fc48, BVA=00000000
------------------------------------------------------------------------------------------thx
- Edited by oobin168 Friday, October 21, 2011 9:07 AM
-
Friday, October 21, 2011 9:18 AM
You maybe should try to create a checked or debug image to get some more informaiton of the exceptions you are seeing.
The exceptions only occure when you move the mouse?
Best regards,
Mike
-
Friday, October 21, 2011 9:38 AM
Dear Mike,
Debug version seems to large to me to download !? I can only use sd card to bootup my platform.
(I never used debug version before...)
The exceptions will occur if I move usb mouse, insert/remove usb OTG device, insert/remove usb device. (seems usb issue ?!)
Insert/remove SD card and insert/remove network cable will not occur this exceptions.
-
Tuesday, October 25, 2011 1:42 AM
Dear Mike,
I can use uboot to boot nk directly.
Below are some of my changes:
1) Init PLL1 & PLL3 in start.s for NK
2) 'Data Abort' problem: modify OALArgsQuery in args.c
3) remove some pll init code in OALPowerInit
However, uboot load nk(100MB) will take about 9 seconds.
After loading nk, WinEC7 will take about 20 seconds to boot up to desktop.
It will cost a lot of time to load some drivers. ==> need to fine tune something !!??.
However, thx a lot ~ !! :)
- Marked As Answer by oobin168 Monday, November 07, 2011 9:25 AM
-
Tuesday, October 25, 2011 7:42 AM
Nice to hear that everything starts to work now. You could have a look and BusEnum2 driver to fine tune your boot up sequence.
Here some links for your information.
http://msdn.microsoft.com/en-us/library/dd187254.aspx
Best regards,
Mike
-
Wednesday, September 05, 2012 10:33 AM
Hi all,
I am trying to boot WEC7 through this procedure: uboot->eboot->NK.
It is hanging at OAL.
No drivers are getting loaded.
I tried commenting the initialization of clock in startup.s of OAL.
Any idea???
Regards,
Seetharam
