At the invitation of Shenzhen youjian technology, djyos should be transplanted to their idea6410 these days.
Now we have released the SI version, which runs in single-chip mode. The powerful CPU such as runs the SI version and is used as a high-speed single-chip microcomputer. All addresses are mapped one to one based on physical addresses. The CPU status does not distinguish between kernel and user.
1. the initial part of the interrupt engine code is in the IRQ state (FIQ is not determined yet ).
2. Most of the interrupt engines and user ISR are running in SVC mode.
3. All other code runs in the SYS state.
The first problem encountered during porting is the problem of burning code to flash. Because the cheap JTAG recorder does not support arm11, we cannot require users to have expensive Simulation Burning tools to use djyos on idea6410, which is not conducive to users.
My first goal is to find out how to download the program, that is, to run the simplest flashlight program and write several lines of code, as shown below:
LDR r0, = 0x7f008820
LDR R1, = 0x1111
STR R1, [R0]
LDR r0, = 0x7f008824
LDR R1, [R0]
Bic R2, R1, #3
ORR R2, R2, # 0xc
Bic R3, R1, # 0xc
ORR R3, R3, #3
STR R2, [R0]
LDR R4, = 5000000
Sub R4, R4, #1
CMP R4, #0
STR R3, [R0]
LDR R4, = 5000000
Sub R4, R4, #1
CMP R4, #0
In the 6410 manual, it can be started from nandflash, onenand, and SD card. If there is no dedicated burning tool, only the SD card can be started. As you can see in the manual, the SD card is actually started by executing a program in the irom of the chip. The program reads the code from the SD card and writes it to stepping stone, stepping Stone is the on-chip memory at 0x0c000000 and 8 KB. After the code is written to stepping stone, it jumps to 0x0c000000 to continue executing the program. To enable startup from the SD card, you must make it clear:
1. Where is the 8 K code stored on the SD card.
2. the format in which the code is stored.
In order to find out the above problems, Google did not find any useful information. On Samsung's website, 6410 of the information was not made public. I applied for it and received approval the next day, there is no information about how to start from the SD card. Looking for a Samsung agent, it seems that I am not very fond of taking care of me, too. I am a thin man, how can they see it. Is there no way?
When there is no way to go, can 2450 be started from the SD card? Look for 2450 of the information to see if there is any. Thank God, I found a document on the Internet:
Although I have never written too much details about code verification algorithms, I can always try it out.
Write the compiled code to the offset-9216 byte at the end of the chip, insert the SD block, switch to the start position of the sd0 card, power on, haha, success, several blue LEDs flash happily. I tried two SD cards: 16 MB, but 2 GB. Somehow, put them aside for the moment.
The first battle is successful. It's time to stop.
Port log 2
As mentioned in the previous article, you can start with a 16 m SD card, but you cannot use a 2G card. I have tried it again. I really don't know what's going on, and I don't have any further information on loading programs in IROM, the problem cannot be found. Let's put it aside for the moment and finish the subsequent transplantation work.
Porting the operating system is different from developing a streaking program. A streaking program can write programs from main. Before executing the main program, the compiler generates a large amount of code for initializing the cpu, clearing the memory, initializing the heap and stack until the main execution environment is established. The operating system usually has its own running environment requirements. The Environment completed by the C compiler often does not meet the requirements. You need to write the initialization file, that is, the initcpu. s file.
Initialize the file to complete the following tasks:
1. jump from the reset address to the startup address.
2. Set the cpu to the privileged mode, disable the dog and interrupt, and disable the cache.
3. Set the clock. Some cpu clock settings are complex, especially for high-speed CPUs. It is difficult to set the clock because of kernel and peripheral matching problems.
4. Set the memory bus and set the memory access speed. It should work with the clock design in the previous step to enable the cpu to correctly read and write memory and memory ing peripherals.
5. Configure the cache and mmu, and then enable the cache and mmu.
6. initialize the stack and jump to the C code.
According to the principle of "tailism", you must not write the cpu initialization code from 0. Instead, you need to find a ready-made reference, because the cpu initialization work of each system is similar. In addition, many cpu vendors generate example with a file name similar to startup. s. Refer to this file for writing. However, Samsung does not know from what year and month it will not disclose its cpu documentation, and even the datasheet has to be applied. When I tried to find the source code package "6410_Test_Rev01" provided by Samsung, my heart became cooler. Although the code package contains start. s file, but there are only a few commands in the file. the initialization process is in the "_ rt_entry" function, and the function is in the library. I have done so well on the confidentiality of chip application materials that Samsung is looking.
No way. Continue searching. You can't write your own lines. Fortunately, there was no such thing as the path, and finally found the start of eboot in the eboot Code provided by youjian. s file, open a look, it is indeed a detailed Startup File, can not help but ecstasy!
The next step is to compare the datasheet, understand the start. s, and then transform it into a suitable djyos. Not to mention it. The workload is huge. 6410 of datasheet has more than 1300 pages, and there are more than 100 pages related to the optical clock and bus configuration. E files are dizzy. The differences between mmu and cache configurations and ARM9. Write it here today. Let's break it down next time.
Third part of the transplantation log
Start. s. Like all startup files, the start part is to disable cache and disable interruption. Here, I will explain a little about why we want to do this and prohibit interruptions. The key is why we must disable cache. We didn't know why the program should be restarted, you do not know the status of the cpu and cache before the restart. The cache may contain error information, and the cpu may obtain incorrect instructions from the cpu, so that the system cannot be started normally. Start of eboot. s misses a very important process, that is, to reset the cpu to the svc status, because the cpu status is unknown just like we do not know the cache status before restarting, add the following statements to ensure that the cpu is in the svc state:
Mrs r0, cpsr @ CPSR
Bic r0, r0, # MODEMASK @ Clear mode bit
ORR R1, R0, # svcmode | noint @ is set to the management mode, and interruption is prohibited.
MSR cpsr_cxsf, R1 @ switch to the management state to prevent unexpected error when 0 address is returned.
In fact, these statements are not safe enough, because if the program directly jumps from the user State to the 0 address, the MRS and MSR commands are invalid. The practice of insurance is to use the SWI command to force modification. Since it is a simple bootloader program, it is a bit lazy for the moment.
By convention, the next step is the initialization of various clocks. The clock structure of the is complicated. There are three PLL to be set, and the frequency division control is also complicated, although start. s has to copy, but you still need to figure it out, because the next programming is useful. The clock of 6410 is so complex that it is used to adapt to a wide range of internal peripherals. Different peripherals require different clocks. To set the clock speed, it is nothing more than defining several common clock frequencies, and then defining the frequency division coefficients of the PLL for these clock frequencies respectively, and then filling these frequency division coefficients into the corresponding registers, the details will not be repeated. Check the code.
After the clock is initialized, it is time to initialize the memory bus. Based on the principle of initialization, only the srom0 and DRAM regions are initialized here. This part of the code is implemented in C language. See memcfg. c file, the code is relatively simple, but according to datasheet requirements, set registers in turn.
Next, you will surely think that it is time to initialize the MMU. initializing the MMU is a complicated task, but the SI version is prepared for the single chip microcomputer. Even if the 6410 is strong, you have to be wronged, when the High-speed single-chip microcomputer. MMU does not use address translation here, but maps all 4G memory space to its physical address. This ing effect is the same as disabling MMU, but the MMU and cache of arm are bound together. Disabling MMU also disables cache, so you can only enable MMU. The address of the page table is 0x50000000, which occupies 16 Kbytes. Therefore, the initial address of the application is 0x50004000.
Can also be lazy, 6410 of the core is arm11jzf-s, 2440 of the core is ARM920T, arm11jzf-s MMU function is much stronger than ARM920T, but are arm companies, is it compatible with the simplest ing? I am too lazy to read the arm11 manual. Try to copy the MMU initialization part of version 2440 directly. It turns out to be feasible, but it is a waste of time to go around a large circle here. After adding some code for initializing MMU, I tried it and found that the light was not flashing. However, I can put this program before the code for initializing the page table. Check carefully and find that it is because DRAM is not initialized. After DRAM Initialization is added, first put the flashlight program behind DRAM initialization and you can find it. At this time, unfortunately, when I moved the flashlight program, I only copied half of the Code. Of course, I did not check the code carefully, I suspect that the MMU initialization code is 2440 can not be used for 6410 (lazy, guilty), so find the arm11jzf-s manual, a few hundred pages of English Information ah, after several days, I finally proved one thing: the original MMU Initialization is correct !!
By now, the initialization of the basic hardware is complete, and the norflash and UART driver will be involved. To be continued ......
The third step is to initialize the UART so that the CPU can be connected to the PC.
The uartclk and baudclk must be distinguished when the UART of 6410 is initialized. The former is controlled by the system control registers clk_src and clk_div2. The Manual does not describe the purpose of the clock, I guess it is used to run the UART module itself. The other clock is baudclk, which is used to control baud and generate a serial shift clock. It is set in ucon, the control register of the UART module, then set baud with the ubrdiv and udivslot0 registers. UART works in the following way:
Baud = 115200
Receiving and sending FIFO: On
Interrupt: Disable and send and receive data in query mode.
The next step is the norflash driver, which is to write the erasure and write programs. Write the program according to the am29lv160db manual. There is nothing to say. In addition to some low-level errors, the test was almost successful.
At this point, it is the XMODEM protocol receiving and receiving program. XMODEM is a simple protocol for sending and receiving files through serial ports. It divides the files into 128 bytes of packets for transmission, if the last packet is less than 128 bytes, it is filled with 0x1a. This Protocol is flawed. It is okay to transmit text files because the text file will not contain 0x1a, but it won't work if it transfers a binary file, because the receiver cannot tell whether the final 0x1a is the content of the file or the padding. But it doesn't matter. As Code, there is no way to add more garbage. It's nothing more than a few bytes.
XMODEM originally had error control. It ensured correct transmission by frame-by-frame response and checksum (or CRC). However, it was a bit lazy, and all these were omitted, if an error is reported, upload it again.
So far, the first step of porting to the is that the sdbootloader is created, and the next step is to transplant the entire operating system. The sdbootloader code is downloaded here:
6410 of sdbootloader is complete
1. Use the winhex tool to write boot_rom.bin to the SD card. Address: SD card end address-9216.
2. Set the dial switch of the Development Board to start from the SD card and power it on.
2. Open the Super Terminal, use the xmodem protocol to download the program, and save it to dram.
3. Write the downloaded code to norflash.
4. Set the dial switch of the Development Board to start from norflash, reset or power on again.
5. xmodem frame format check and checksum check are removed.
When developing an operating system, whether it is a PC, server, or embedded operating system, the first thing to solve is the storage of startup files. No matter what cpu, after power-on or reset, the First Command will be read from the specified storage location for execution. We will convert this address into a start vector, some CPUs can use jumpers to set different start vector addresses. The familiar PC is to burn the bios to the boot vector, and then start a more advanced operating system, such as windows and linux.
In the embedded industry, taking linux as an example, linux images can be downloaded through the network port or other communication ports, but when you get a bare host, you must first install uboot, vivi, or other bootloader in flash. Djyos is no exception. The difference is that the released si version of djyos does not have a separate bootloader, but integrates the bootloader role into the executable image. Therefore, you need to burn the entire djyos image like uboot.
Earlier than 2410, djyos released two versions: ARM7 (44b0) and arm9-( 2440 and), benefiting from the low-cost ARM7 and arm9-simulator, such as hjtag, the two versions of arm are directly burned to norflash through hjtag, jlink, or other tools. However, cloud6410 is the core of arm11. These Cheap tools do not support arm11, and the burning tools supporting arm11 are all over several thousand yuan. This will inevitably affect the use of djyos. To enable 6410 to execute djyos, you must install djyos on the Startup Device without a dedicated burning tool.
6410 a total of four startup devices are supported: norflash, nandflash, SD card, and modem. Specifically, norflash and nandflash must use a dedicated burning tool. Modem needs to understand its communication protocol, write the corresponding PC-side applications. In contrast, the SD card is the easiest. You can use the ordinary card reader + winhex tool to write data. But there is a limit that 6410 reads 8 K code from the SD card to the internal RAM at startup (chapter 2 of the 6410 manual says 4 K, Chapter 8 says 8 K, the actual measurement is 8 K ). After reading the code, the program will jump to the internal RAM for execution. The 8 K program can only be used as a simple bootloader to load the entire operating system. At this time, there are two options:
1. Write the program to other places on the SD card, but this method is unrealistic. The SD card is made of nandflash and must undergo ECC verification. When writing code to the SD card, you must use a file system, but 8 K Code cannot be used as a file system; you can either use a dedicated Write Card tool that supports ECC on the PC end. Unfortunately, it is not found.
2. Download via serial port. This is a traditional method. There are many PC-side tools and the most common is the Super Terminal.
We chose the Super Terminal and XMODEM protocol for download.
The code is relatively simple. For details, refer to the "X" series of migration logs with ". Download the source code: [url] http://www.djyos.com/download/sdboot6410.zip#/url].
This article is from the CSDN blog. For more information, see [url] sources.