As my colleague started to modify the linker script, I found more problems to be solved in the simulator.
The RISC-V Angel Memory
One of my concern this week is to set or limit the memory that could be created by the simulator, which is also the size for the RAM of simulator. The default RISC-V Angel RAM is set to 8 MiB (MegaByte), which can be calculated from
Total Memory (byte) = 1 x 1024 x 1024 = 10485760 byte
Total Memory (bits) = 8 x 1024 x 1024 = 8388608 bits
However, knowing the calculation is just the initial part of solving my problem. Since my colleague Sumia had modified the linker script, the global pointer actually start at address 0x80002000, this actually tells me that my RAM memory should be as large as 0x80002000, which is extremely unpractical where I would need a 256 MiB RAM. This would make the browser hang, as I am creating a JavaScript array that is almost 256 MiB. Thus, I had thought to make a mask on the load and store registers, so that it would decode the address 0x80002000 to 0x00082000 instead, which require just 128 kiB of RAM, which exactly suit the RAM space.
Besides, I also noticed that the RISC-V Angel original source code does not actually read the most significant bits, as you can referred in here, in the for loop of loadElf() function. Thus, which in my case, I would need to change the reading of most significant bits.
The Two Complement Issue of RISC-V Angel
As I am going to read from the address 0x80002000, I actually need to store and load these addresses from the RAM, which it would result in a negative array of -7fffxxxx. These addresses is not translated to two compliments. Loading of negative arrays would produce undefined results, which is not desirable. However, one useful tool that had been used by RISC-V Angel was the Closure Library, which contains the Long function that would translate the addresses into two complements automatically. Thus, in order to process the addresses, I have to translate the data into Long type from Closure library, to get rid of the negative array.
Memory-Mapped I/O
As the work progressed, my supervisor explained to me about the memory-mapped I/O that is going to be used by the simulator. Fortunately, RISC-V Angel actually uses memory-mapped I/O, and the work that had been done on previous week was not a waste. One biggest confusion from me and my colleague Sumia, was the addresses of the I/O and the instructions are the same, and we assumed that the processor is actually using Port-Mapped I/O, which it is not! The AEMB processor actually uses memory-mapped I/O. In order to load and store the instructions for I/O properly, the store and load instruction need to be masked to treat these addresses for the I/O, not for the instruction, so that no instructions memory would be overwrite by the load and store instructions.
Hopefully by next week, the GPIO module would be working fine with the integration that should be done.
0 Comments