Re: [Fx2lib-devel] Setupdata at 0xe000

[Daniel O'C. <doc...@gs...>]

On 17/09/2011, at 5:25, Maarten Brock wrote:
>> OK I see now. Sorry, I was unaware of the 512 bytes of RAM at 0xe000.
> 
> But these can only be used as RAM accordign to the 
> datasheet.

Yes, you can't put code there.

>> If we just go ahead and change the storage class of the string
>> descriptors from "code" to "xdata" in setupdat.c[1] (i.e no preprocessor
>> guards), will it conceivably break anything? It looks to me like
>> changing it to "xdata" merely gives apps the option of relocating
>> DSCR_AREA to 0xe000 (which may be used for "xdata" only, not "code"),
>> but with NO downside.
>> 
>> Or am I missing something?
> 
> And how is that xdata filled? SDCC assumes the code 
> memory is stored in a ROM-like memory and xdata is 
> volatile. So during startup it copies initialized data 
> from code to xdata. So you have two copies in memory and 
> thus your memory footprint has grown. If you use --no-
> xinit-opt it is not copied but initialized by lots of 
> instructions, usually taking even more code memory.
> 
> I guess it works because SDCC's initialization code 
> copied it from lower memory to xdata at 0xe000. I also 
> guess you missed the downside.

Hmm I didn't consider this, however I just examined the output file and I don't think it is doing that.
ie I did this..
gobjcopy -I ihex -O binary obj/ugsio.ihx obj/ugsio.bin
hexdump -Cv obj/ugsio.bin

and I see..
<snip>
0000e000  12 01 00 02 ff ff ff 40  53 47 01 00 01 00 01 02  |.......@SG......|
0000e010  04 01 0a 06 00 02 ff ff  ff 40 01 00 09 02 35 00  |.........@....5.|
<snip>
0000e080  07 05 08 02 00 02 00 00  04 03 09 04 22 03 47 00  |............".G.|
0000e090  65 00 6e 00 65 00 73 00  69 00 73 00 20 00 53 00  |e.n.e.s.i.s. .S.|
0000e0a0  6f 00 66 00 74 00 77 00  61 00 72 00 65 00 0c 03  |o.f.t.w.a.r.e...|
<snip>

> SDCC does not support the concept of preinitialized 
> xdata as the FX2 has when it gets the firmware from the 
> driver or the I2C eeprom.

I think it probably "just works" in this case because the descriptor table is defined in assembly and its address is forced in the linker.

Hence the declaration only affects how the C code accesses it.

>> FWIW, I just tried the code->xdata + DSCR_AREA=e000 change on the
>> firmware in FPGALink[2] and it works fine.
> 
> Are you using C0 or C2 mode? C2 mode cannot load 0xe000 
> according to the datasheet. Can the driver download to 
> 0xe000 directly?
> 
> My advice is to keep these constants in code memory. And 
> if you do want to change them at runtime cast a code 
> pointer to xdata pointer to access them.
> 
> If the driver really supports loading to 0xe000 you can 
> choose to store the constants there. You can also choose 
> to use 0xe000 as xdata as it was meant.

I am using C2 mode, and the firmware is loaded into RAM using fxload.

EEPROM has a PID of 0xff01 and devd (somewhat like udev but for FreeBSD) looks for this and runs fxload. The firmware has a PID of 0x0001 and the kernel driver attaches to this.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C