Overlaying a WLA-DX ROM into a board's RAM #597
Comments
|
Sorry for taking so long with this; first I was totally out of energy and didn't completely understand what is going on, but after reading this four times I think I have a hunch now. So this issue contains actually two issues, which are not really connected?
EDIT: No? As ROM and RAM data need to occupy the same memory area? So actually we'll need a way to insert .RAMSECTIONs into normal SLOTs where .SECTIONs are? Maybe add a new keyword to a .RAMSECTION?
|
|
A question regarding having .RAMSECTIONs sharing the same SLOT with normal .SECTIONs: Why not mimick a .RAMSECTION with a .SECTION? .RAMSECTION "Vars" ... is kinda the same as .SECTION "Vars" ? |
Yes, that is correct. Right now, I'm just plain assuming conflicts can't occur. Basically, I want "initialized global RAM data", and I want WLA-DX to be aware of initialized global RAM data. A
Yes, I consider vectors to be ROM, even though they're physically placed in RAM in this specific board. Debugger variables which I don't touch surround the vectors. I would want a However, I need some way to "insert" my
This is indeed what I'm doing: "So what's the problem", you ask? Well, having a section like this is going to zero-pad the ROM all the way to the vectors. If I upload the "raw" ROM file, the zero-padding will overwrite debugging variables. I am using heuristics in my uploader program to avoid the zero-pad problem.
Obviously, raw ROM file format will not be able to support "holes"/"initialized global data" in the address space like this, but I think maybe WLA should be aware of "initialized RAM"/special RAM locations. That's why I brought up the WDC format.
Correct.
Seems to be limited to WDC IDEs. I'm not married to the format, I just think it's a very simple "not-raw binary" format :). |
I also tried another approach that works sometimes but not all the time. I have a magic cookie value that is padded after all the sections I define but before the Unfortunately, I couldn't find a way to consistently "append a section to ensure it's second-to-last in the ROM", and I think it's a bit hacky anyway :). |
|
Ok, I just added (didn't push to master, yet) support for OCCUPYROM keyword in .RAMSECTION .RAMSECTION "Vars" OCCUPYROM that turns it into a corresponding .SECTION when sections are sorted and placed so this makes .SECTION/.RAMSECTION collisions possible. But what puzzles is that should I mark also the same "area" occupied that the .RAMSECTION takes in a RAM bank? Here it just takes space in a ROM bank... |
|
I would personally have the assembler be aware that initialized and uninitialized RAM are in the same |
|
The more I think about this the less I think I understand what is going on. :) If you already have a loader and everything is in the same address space, why not just make everything a .SECTION of some sort? Why would you need a .RAMSECTION for anything there? You can initialize data in .SECTIONs, and embed a special keyword to the names of such .SECTIONs where you don't want to copy the data to output so you can skip them later. EDIT: Ah, .SECTION names are not available in the symbol file or in the output in any way. Maybe it could be useful if I modified the symbol file writer to add .SECTION information into the symbol file? |
…ions] and [ramsections]. Might help fixing GitHub issue #597.
Yes, also this. I didn't think to mention that after being the first thing I tried. I'm looking at your new commits now to see if I can modify my loader program to do what I want.
My original answer was: I still think "initialized RAM" and "ROM" should be distinguished in some way, in case other object formats besides raw get added to WLALINK. For example o65 format. But reading o65 format spec:
This is what you're suggesting, except without a marker to deliminate "this is RAM". Maybe a |
I remembered the answer to this. Because you can't place So I can place initialized RAM vars into Because I'm placing initialized RAM into only Other RemarksA This results in the following symbol file:
Should there be slot information as well to uniquely identify a specific c30fa7e#diff-2168ac48f5c76aca9c113f05cddde4475d1365833d42c82dcba4588054aba516R118
RAM slot offset? |
|
I can add slot number there per .RAMSECTION later today after work. Just thinking, should I also write .MEMORYMAP (-> [memorymap]) and .ROMBANKMAP (-> [rombankmap]) into the symbol file?
Isn't the RAM slot offset the same as RAM bank offset? |
I'd hold off on this personally for now.
No, see my example (unless this is not intended to work), where two different RAM vars have the same bank:offset, but are different addresses:
Is there any possible way around this for initialized RAM? |
Yeah, the address is different, but the bank/slot offset is the same, AFAIK. Bank starts at the beginning of a slot. With .RAMSECTIONs each slot has a set of 256 RAM banks, I think. Let me double check this. If true, this might be actually a flaw in WLA DX, because some systems might have multiple slots where the same RAM banks could be inserted into... EDIT: This seems to be correct - each SLOT has its own set of 256 RAM banks. I think I need to add a switch that makes the slots to share the same RAM banks... EDIT: I added support for a RAM bank sharing between multiple slots, but when I was writing tests I realized it wouldn't work - WLALINK has one address for a label, but when changing slots the address would be different. So if one wants to use a RAM bank in multiple slots he/she must per slot fill the RAM banks with identical data, only the label names must be different. This also means that ROM banks cannot be used in multiple slots. Unless we figure out how to fix this situation. I guess the code would have to be given hints like BANK x IS IN SLOT y and WLALINK would get this information somehow and then change the addresses on the fly. Sounds really complicated...
I have to admit that I don't understand what you are doing LOL :D |
What would WRITABLE keyword do, codewise, in WLA/WLALINK? I mean I can add a new variable to section struct, but it has to be used somehow... |
SLOT's just a slot in the memory where you can put any ROM bank that has the same size as the SLOT so no, SLOT doesn't uniquely indentify a ROM bank AFAIK... ? |
This was the part I was missing. I forgot that each slot has 256 RAM banks. Contrast to ROM banks, where you have to assign each ROM bank defined to a slot manually. IIRC
You mean mirroring? I figured that was out of scope.
Indeed, let's not go down this path for now.
I'm trying to initialize RAM, similar to However, at some point, I think I lost the plot. So let me take some time to gather my thoughts.
If other object formats are added, like o65,
There can only be a single slot where ROM BANK 0 is placed, correct? Ditto for ROM BANK 1, ROM BANK 2, etc. In contrast, each SLOT has 256 RAM BANKS. So each slot will have a RAM BANK 0, RAM BANK 1, etc up to 255. In that sense, if you have the ROM BANK number in the symbol file, you can uniquely identify which SLOT it's in. But you cannot do the same for RAM BANKS. Is this correct? |
You can actually place a ROM bank into multiple slots, but when you define a .SECTION you give it a slot so references to the labels inside that .SECTION work only when the ROM bank is in that SLOT. So you could in theory have .SECTIONs with SLOT 0 covering 50% of ROM bank 1, and the rest filled with .SECTIONs with SLOT 1... |
Ahhh, I see. And placing a ROM bank into multiple slots only works without warnings when I have some ideas to fix my code now... |
Possibly related to #56?
I have a rare case where ROM and RAM overlap slightly. Specifically, I overlay my "ROM" image into RAM which is shared w/ a debugger's variables (the debugger itself is in Flash ROM in the upper half of the address space).
There are a few variables that the debugger provides that the user is expected to fill in. Specifically, the user populates interrupt vectors; the debugger has vectors at the normal $fffa and friends and jumps to routines pointed to at $7fea and friends. The remaining variables the debugger uses from $7c00 should not be touched by my code. Unfortunately, since ROM sections are the only place where a user can "lay down" initialized bytes into an image, I opt to include the debugger RAM as part of my ROM bank.
memorymap/rombankmap (I allocate 8kB for my own RAM. Hardcoding a RAM split is probably unavoidable):
linkfile:
Vectors overwriting debugger RAM:
OVERWRITEat least signifies intent that I'm doing something weird. Of course the output ROM fills the "unused" RAM/ROM locations leading up to theVectorssection with 0. But I can use WLA's symbol file with-x(extra definitions) to figure out (SECTIONSTART_*,SECTIONEND_*) which offsets into the ROM file should actually be loaded into my board's RAM.I Want WLA-DX To Detect Conflicts, Not Silently Misassemble
This works, but I unfortunately lose WLA DX's ability to determine conflicts between sections/slots (ROM/RAM conflicts are not supported). DEBUGGER_MAIN_RAM begins at $7c00; what recourse do I have to have the link fail if my ROM section crosses into debugger RAM?
A New Output Format?
In addition, instead of me parsing symbol files, could there be a "standardized" output format which consists of instructions of where to load each section of the output binary? I found WDC has a simple loading format, as follows (bank:address and length are little-endian):
Here's a simple example of the format (comments mine):
How difficult would this be to add? Note that section data wouldn't have any zero padding, which would result in significant file size/transfer time savings for small pieces of code for my board. I started taking a look at
wlalinkmyself. It looks likeg_rom_usageis the variable that controls how much of a section is actually used.The text was updated successfully, but these errors were encountered: