- I added a "fill first 16 pages" command to VMDEBUG (key '0')
- I disabled shr_hits for now
- I have a bug when flushing dirty pages, seems to start writing one byte too early
- I force show_page to page in the desired page (instead of complaining if it is not in the working set)
Looks like I have missed out some hardware setup/initialization for the TriBlade RAM which is actually done by the separate TriBladeProp driver in ZiCog and friends.
Might want to add a BINIT to accommodate such one off hardware initialization at start up.
Actually I'm wondering how it works at all with out that init but the results to look like they might be caused by low address bits error.
No time to change/test till later today.
Edit: Just noticed you already have a BINIT section.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have this code immediately after vm.start in the main method:
waitcnt(clkfreq*1 + cnt) 'Delay to work around timing bug iin vmcog
repeat ad from 0 to (1024 * 64) - 1 step 1
vm.wrvbyte(ad, ad)
i := 0
repeat ad from 0 to (1024 * 64) - 1 step 1
ser.hex(vm.rdvbyte(ad),2)
ser.tx($20)
i := i + 1
if i == 16
ser.tx(13)
ser.tx(10)
i := 0
repeat
The idea is to simply right the low byte of RAM address to each location. Then go through RAM and print the content.
There results are wrong in a very consistent way.
First 4 bytes out of 16 are OK.
Next 4 bytes are copies of the 4th byte
Next 4 bytes are OK
Next 4 bytes are copies of the 12th byte
I added your test to VMCOG as the 'h' command. I've modified the test a bit, so now it shows the memory address of each line, and it exits after 256 errors. I am attaching a log snapshot.
On my system, VMCOG worked perfectly for $0000-$7FFF then went nuts; I saw this early in my development, and it is either a bad ram chip, or the second chip did not get initialized correctly.
I am attaching the new version of VMDEBUG, and my log file from BST's terminal.
Fixed the bug for PropCade. It was in the initialization section - I initialized the first chip four times, instead of all four chips once [noparse]:)[/noparse]
It now passes the heater test with 0 errors.
The waitcnt() issue is almost certainly having to wait until the cog loads, initializes, and pages in the initial working set. I am looking into it.
If there is a valid read request in the mailbox, it takes 1.2us-1.3us to finish processing it, however the response is in the mailbox in 1.1us-1.2us
By using some more cog memory I can reduce these times by 0.2us for the current code (NOT for BIGVM)
My experimental "BIGVM" paper design takes 1.2us-1.3us to finish processing a request, and also has the response in the mailbox in 1.1us-1.2us
Using a 1KB hub page table, BIGVM allows for a 512KB virtual memory AND frees up 64 longs in VMCOG!
Since PropCade has six memory sockets, PropCade will be able to have a 192KB SRAM VM with six cheap 23K256 chips.
I will add the requested "READONLY" flag to BIGVM, as it will allow 160KB ram (for data) and 2MB flash (for code) on PropCade in six cheap DIP8 chips!
Also, there is no reason why an LMM kernel could not use VMCOG - yes, it would be significantly slower, but it would allow large LMM programs on the cheap.
Below is my diff on vmcog.spin. I have to add a mailbox and other code to vmdebug.spin to use it though and am a little hesitant to do that. I really don't want to add code directly to vmcog.spin for accessing the memory at this point. My diff tools don't work with parallax fonts (mainly the mit license) so I have to convert the files each time.
diff -c vmdebug-bst-archive-100606-144439/vmcog.spin vmdebug-bst-archive-100606-122239/vmcog.spin
*** vmdebug-bst-archive-100606-144439/vmcog.spin 2010-06-06 17:22:24.124422500 -0700
--- vmdebug-bst-archive-100606-122239/vmcog.spin 2010-06-06 17:23:54.110422500 -0700
***************
*** 81,87 ****
#define EXTRAM
#ifdef EXTRAM
! #define PROPCADE
'#define FLEXMEM
'#define MORPHEUS_SPI
'#define MORPHEUS_XMM
--- 81,87 ----
#define EXTRAM
#ifdef EXTRAM
! '#define PROPCADE
'#define FLEXMEM
'#define MORPHEUS_SPI
'#define MORPHEUS_XMM
***************
*** 91,96 ****
--- 91,97 ----
'#define TRIBLADE
'#define TRIBLADE_2
'#define RAMBLADE
+ '#define XEDODRAM
#else
#warn External Ram access disabled - only use memory up to WS_SIZE
#endif
***************
*** 354,359 ****
--- 355,366 ----
#ifdef TRIBLADE
'End of TriBlade code
#endif
+ #ifdef XEDODRAM
+ mov XDRAM_cmd,par
+ add XDRAM_cmd,#16 ' par+16 for cmd ... vmcog mailbox is 4 longs
+ mov XDRAM_dat,XDRAM_cmd
+ add XDRAM_dat,#4 ' par+20 for dat
+ #endif
'----------------------------------------------------------------------------------------------------
' END OF BINIT SECTION
'----------------------------------------------------------------------------------------------------
***************
*** 969,974 ****
--- 976,999 ----
#ifdef RAMBLADE
'End of RamBlade code
#endif
+ #ifdef XEDODRAM
+ ' get 256*2 bytes
+ mov xcmd,vmaddr ' get physical address
+ and xcmd,XDRAM_amsk
+ or xcmd,XDRAM_rbuf ' set readbuf command
+ mov count,#2
+ mov ptr,hubaddr ' set hub pointer
+ and ptr,dmask
+ :next
+ wrlong ptr,XDRAM_dat ' send new hub pointer
+ wrlong xcmd,XDRAM_cmd ' send command
+ rdlong temp,XDRAM_cmd wz
+ if_nz jmp #$-1 ' wait for command complete
+ add ptr,#256 ' incr pointers
+ add xcmd,#256
+ djnz count,#:next ' do next 128
+ #endif
+ ' endif XEDORAM
#endif
BREAD_RET ret
***************
*** 1040,1045 ****
--- 1065,1088 ----
#ifdef RAMBLADE
'End of RamBlade code
#endif
+ #ifdef XEDODRAM
+ ' write 256*2 bytes
+ mov xcmd,vmaddr ' get physical address
+ and xcmd,XDRAM_amsk
+ or xcmd,XDRAM_wbuf ' set writebuf command
+ mov count,#2
+ mov ptr,hubaddr ' set hub pointer
+ and ptr,dmask
+ :next
+ wrlong ptr,XDRAM_dat ' send new hub pointer
+ wrlong xcmd,XDRAM_cmd ' send command
+ rdlong temp,XDRAM_cmd wz
+ if_nz jmp #$-1 ' wait for command complete
+ add ptr,#256 ' incr pointers
+ add xcmd,#256
+ djnz count,#:next ' do next 128
+ #endif
+ ' endif XEDODRAM
#endif
BWRITE_RET ret
***************
*** 1147,1152 ****
--- 1190,1204 ----
offs_mask long $7FFF
miso_mask long MISO ' required due to ina not being usable in destination field
#endif
+ #ifdef XEDODRAM
+ xcmd long 0
+ XDRAM_cmd long 0
+ XDRAM_dat long 0
+ XDRAM_rbuf long $7000_0000 ' always read 256 at a time ... loops 4 times
+ XDRAM_wbuf long $8000_0000 ' always write 256 at a time ... loops 4 times
+ XDRAM_amsk long $0003_ffff ' address mask ... just allow 256K for now ....
+ #endif
+ ' endif XEDODRAM
#endif
'----------------------------------------------------------------------------------------------------
Tomorrow I'll move PropCade to my Windows workstation, which has ViewPort on it. Time to look at BREAD/BWRITE with a logic analyzer [noparse]:)[/noparse]
I actually remember this problem from before I moved the read/write routines into VMCOG - I guess I re-introduced the bug when I merged the source, or later when I was trying to recover some cog memory.
Bill Henning said...
weird... can you show me your vm.start() line?
mine is:
vm.start(@mailbox,$7C00,14) ' start up VMCOG
where $7C00 is the start of the last valid page (ie $7C00-$7DFF), and there are a total of 14 pages (including the last valid page)
Ok, here is what I'm using.
...
OBJ
ser: "FullDuplexSerialPlus" ' so we can talk to a terminal program over SerPlug
vm : "vmcog" ' the MMU/virtual memory manager cog
#ifdef XEDODRAM
xm : "XEDODRAM_1MB"
#endif
VAR
long command, addr, val
'----------------------------------------------------------------------------------------------------
' Variables defined for VMDEBUG use
'----------------------------------------------------------------------------------------------------
long mailbox[noparse][[/noparse] 4 ]
#ifdef XEDODRAM
long xmailbox[noparse][[/noparse] 2 ]
#endif
long tlb[noparse][[/noparse]256]
'----------------------------------------------------------------------------------------------------
' Main
'
'----------------------------------------------------------------------------------------------------
PUB main | ch
ser.start(31,30,0,baud)
waitcnt(clkfreq+cnt)
vm.start(@mailbox,$7C00,12) ' start up VMCOG
#ifdef XEDODRAM
xm.start(@xmailbox) ' start up inter-cog xmem
#endif
...
Bill Henning said...
XDRAM_amsk long $0003_fe00 ' address mask ... just allow 256K for now ...
That will force the vmaddr to be 512 byte aligned at the start of a page.
I'm not sure how that is relevant since your vmaddr is either and with dmask or shl by 9 before any call to BREAD/BWRITE ... unless you plan to change that [noparse]:)[/noparse]. This mask is just to keep the address from overflowing in the "physical back-store" (term usage as defined in linux and on wikipedia) EDO DRAM device.
I did notice while running my debugger for the initial port that some of your hub pointers end up having bits set in the upper word. I suppose that is an artifact of the tag line entries not being masked and is harmless for P8x32a.
As for my other strange output I think I've convinced myself it's in my TriBlade B* codes.
Basically I did some "perturbation" experiments like making BWRITE write out an ever increasing counter no matter what it was actually asked to write. Likewise BREAD returning a counter whatever it actually got from RAM.
I have to look at this some more, perhaps create a simple standalone external RAM test.
However I'm off on a trip to Stockholm for three days so there will be some delay.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Looking at my erroneous test results I see that towards the end of the memory dump everything is correct after a certain point but before that has very consistent errors.
So for example in the dump below everything after F200 is correct.
READY>
Testing $00010000 bytes
Zero fill...
Checking 00 writing FF ...
Checking FF writing AA ...
Checking AA writing 55 ...
Checking 55 writing 00 ...
OK
I have managed to convince this to work by taking the TriBladeProp driver into use in it's own COG. This holds some signal in the correct state which otherwise is not so in the byte read/write routines.
This is only a temporary fix as we don't want to waste a COG on it.
I have included a more sophisticated RAM test which goes some way to detecting shorted data/address pathways etc.
With this test I have determined that...
The problem with the error every 512 bytes is actually nothing to do with it being the first byte of a page. I have discovered that the first write to anywhere in page does not "stick".
You will find in the heater3 test the following code that tries to create a RAM error but it does not:
Thanks, your start up looks fine... and you are right about the mask change.
jazzed said...
Ok, here is what I'm using.
...
I'm not sure how that is relevant since your vmaddr is either and with dmask or shl by 9 before any call to BREAD/BWRITE ... unless you plan to change that [noparse]:)[/noparse]. This mask is just to keep the address from overflowing in the "physical back-store" (term usage as defined in linux and on wikipedia) EDO DRAM device.
I did notice while running my debugger for the initial port that some of your hub pointers end up having bits set in the upper word. I suppose that is an artifact of the tag line entries not being masked and is harmless for P8x32a.
The problem HAS to be in BUSERR. I will squish it.
heater said...
Bill: "It fails on the first byte of every page"
Yep, I see that as well.
As for my other strange output I think I've convinced myself it's in my TriBlade B* codes.
Basically I did some "perturbation" experiments like making BWRITE write out an ever increasing counter no matter what it was actually asked to write. Likewise BREAD returning a counter whatever it actually got from RAM.
I have to look at this some more, perhaps create a simple standalone external RAM test.
However I'm off on a trip to Stockholm for three days so there will be some delay.
heater said...
OK, my trip Stockholm was cancelled so...
Looking at my erroneous test results I see that towards the end of the memory dump everything is correct after a certain point but before that has very consistent errors.
So for example in the dump below everything after F200 is correct.
Excellent - this verifies that the error has to be a clobbered pointer (most likely vmentry) in BUSERR.
heater said...
Yay it works on TriBlade (almost)!
READY>
Testing $00010000 bytes
Zero fill...
Checking 00 writing FF ...
Checking FF writing AA ...
Checking AA writing 55 ...
Checking 55 writing 00 ...
OK
I have managed to convince this to work by taking the TriBladeProp driver into use in it's own COG. This holds some signal in the correct state which otherwise is not so in the byte read/write routines.
This is only a temporary fix as we don't want to waste a COG on it.
I have included a more sophisticated RAM test which goes some way to detecting shorted data/address pathways etc.
With this test I have determined that...
The problem with the error every 512 bytes is actually nothing to do with it being the first byte of a page. I have discovered that the first write to anywhere in page does not "stick".
You will find in the heater3 test the following code that tries to create a RAM error but it does not:
Comments
- I added a "fill first 16 pages" command to VMDEBUG (key '0')
- I disabled shr_hits for now
- I have a bug when flushing dirty pages, seems to start writing one byte too early
- I force show_page to page in the desired page (instead of complaining if it is not in the working set)
Here's the latest:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Might want to add a BINIT to accommodate such one off hardware initialization at start up.
Actually I'm wondering how it works at all with out that init but the results to look like they might be caused by low address bits error.
No time to change/test till later today.
Edit: Just noticed you already have a BINIT section.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/6/2010 6:47:58 AM GMT
I have this code immediately after vm.start in the main method:
waitcnt(clkfreq*1 + cnt) 'Delay to work around timing bug iin vmcog repeat ad from 0 to (1024 * 64) - 1 step 1 vm.wrvbyte(ad, ad) i := 0 repeat ad from 0 to (1024 * 64) - 1 step 1 ser.hex(vm.rdvbyte(ad),2) ser.tx($20) i := i + 1 if i == 16 ser.tx(13) ser.tx(10) i := 0 repeatThe idea is to simply right the low byte of RAM address to each location. Then go through RAM and print the content.
There results are wrong in a very consistent way.
First 4 bytes out of 16 are OK.
Next 4 bytes are copies of the 4th byte
Next 4 bytes are OK
Next 4 bytes are copies of the 12th byte
And so on for the next 16 like so:
When I try setting all bytes to $FF instead they are all set except for every 512th byte which is zero.
Attached is the code and a capture of the 64K dump.
Towards the end of the dump everything seem to be OK.
Is this TriBlade code or VmCog.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
thanks for the info!
I added your test to VMCOG as the 'h' command. I've modified the test a bit, so now it shows the memory address of each line, and it exits after 256 errors. I am attaching a log snapshot.
On my system, VMCOG worked perfectly for $0000-$7FFF then went nuts; I saw this early in my development, and it is either a bad ram chip, or the second chip did not get initialized correctly.
I am attaching the new version of VMDEBUG, and my log file from BST's terminal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Fixed the bug for PropCade. It was in the initialization section - I initialized the first chip four times, instead of all four chips once [noparse]:)[/noparse]
It now passes the heater test with 0 errors.
The waitcnt() issue is almost certainly having to wait until the cog loads, initializes, and pages in the initial working set. I am looking into it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
If there is a valid read request in the mailbox, it takes 1.2us-1.3us to finish processing it, however the response is in the mailbox in 1.1us-1.2us
By using some more cog memory I can reduce these times by 0.2us for the current code (NOT for BIGVM)
My experimental "BIGVM" paper design takes 1.2us-1.3us to finish processing a request, and also has the response in the mailbox in 1.1us-1.2us
Using a 1KB hub page table, BIGVM allows for a 512KB virtual memory AND frees up 64 longs in VMCOG!
Since PropCade has six memory sockets, PropCade will be able to have a 192KB SRAM VM with six cheap 23K256 chips.
I will add the requested "READONLY" flag to BIGVM, as it will allow 160KB ram (for data) and 2MB flash (for code) on PropCade in six cheap DIP8 chips!
Also, there is no reason why an LMM kernel could not use VMCOG - yes, it would be significantly slower, but it would allow large LMM programs on the cheap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I am uploading v0.950 to the first post. This version adds:
- heater's test (slightly modified)
- a really dumb benchmark that mainly shows Spin overhead
- a much nicer TLB listing
Keep the feedback coming!
Additional BINIT/BREAD/BWRITE code for other platforms is most welcome, and will be integrated into future releases.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Using fill seems to work to a point. Some pages seem to be using ROM for storage.
The virtual/physical address meanings appear reversed on the dumps.
The heater test and benchmark crash for me.
Virtual Addr: $00000000 Physical Addr: $6C00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 000: A3 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 010: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 020: 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 030: 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 040: 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 050: 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 060: 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 070: 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 080: 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 090: 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F 0A0: A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF 0B0: B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF 0C0: C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 0D0: D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF 0E0: E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF 0F0: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 100: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 110: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 120: 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 130: 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 140: 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 150: 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 160: 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 170: 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 180: 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 190: 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F 1A0: A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF 1B0: B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF 1C0: C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF 1D0: D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF 1E0: E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF 1F0: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FFA page using ROM for virtual storage ?
Enter HEX Address: 2600 Virtual Addr: $00002600 Physical Addr: $8C00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 010: 00 00 00 00 00 D0 1F 00 00 F5 5F 01 40 FD 5F 05 020: 40 AF 5E 05 D0 AB 1E 15 F0 8B 1F 15 F0 83 1F 15 030: 50 81 0F 15 50 81 0F 15 50 81 0F 15 50 C1 0F 15 040: 50 C1 0F 15 50 C1 0B 15 50 C1 0B 15 50 C1 0B 15 050: 50 D1 0B 15 50 D1 0B 15 50 D1 0A 15 40 D5 4A 05 060: E0 FF FF 2F A0 FF FF 2B A0 FA BF 2A 00 00 00 00 070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 090: 00 00 00 00 00 F0 3F 00 00 FF FF 03 C0 FF FF 0F 0A0: C0 0F C0 0F F0 03 00 3F F0 03 00 3F 00 00 00 3F 0B0: 00 00 00 3F 00 00 C0 0F 00 A0 FA 0F 00 A0 FF 03 0C0: 00 E0 FF 0A 00 54 85 0A 00 55 01 2A 40 15 00 2A 0D0: 40 05 00 2A F0 07 00 2A F0 03 00 2A D0 0B 80 0A 0E0: D0 FF FF 1F 50 FF FF 17 50 F5 7F 15 00 00 00 00 0F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 110: 00 00 00 00 A0 EA AF 0A A0 EA AF 0A A0 FA AB 0A 120: A0 52 01 00 A0 52 01 00 A0 56 00 00 A0 56 00 00 130: A0 56 00 00 A0 B7 2A 00 A0 BF FE 02 A0 BF FE 0A 140: E0 07 D4 0A 40 05 54 2A 40 05 54 2A 50 55 55 3F 150: 50 55 55 3F F0 57 55 3F A0 02 54 2A 80 0A D4 0A 160: 80 AA FE 0A 00 AA FE 02 00 A0 7E 00 00 00 00 00 170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 190: 00 00 00 00 A0 FA BF 2A A0 FF FF 2B E0 FF FF 2F 1A0: 40 05 40 2F 50 01 80 1F 50 01 80 1F 50 01 80 0A 1B0: 50 01 A0 02 50 51 B5 02 50 55 F5 03 50 55 FD 05 1C0: 50 05 E8 05 50 01 A8 15 50 01 2A 15 50 01 2A 15 1D0: 50 01 2A 15 50 81 0A 15 50 81 0A 15 40 85 4A 05 1E0: 40 F5 57 05 00 F5 57 01 00 F0 17 00 00 00 00 00 1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I will check for the reversal you mention.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I have no idea why that did not occur to me!
Changing...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
- minimal TLB display, only shows active rows (great suggestion from jazzed)
- new 'f' Fill test
The new test puts a unique pattern into each 512 byte page, so it is easy to tell that you are reading the right page.
In each page, Fill writes 256 words, with each word defined as follows:
$HHLL
where
HH = page number ($00-$7F)
LL = word address within the page ($00-FF)
The test passes on PropCade.
It fails on the first byte of every page - I am guessing there is a bug in my page write routine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I turned off EXTRAM, and ran with just 16 pages (8KB). I modified Fill2 to only fill the first 8KB, and every read/write made by Fill2 was perfect.
I have a bug to chase... however since it is easily repeated, it will be squished RSN [noparse]:)[/noparse]
so it only works 99.8% on PropCade (511 bytes in 512)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 6/6/2010 11:22:13 PM GMT
Nice display below ... why do entried $D..$11 have $8000+ for hub address?
TLB Contents: Acesses L D Hub (Raw Data) VM_ADDR ------- - - ----- ---------- ------- 00: $000001 - - $6C00 (00000836) $000000 01: $000001 - - $6E00 (00000837) $000200 05: $000000 - - $7000 (00000038) $000A00 06: $000000 - - $7200 (00000039) $000C00 07: $000000 - - $7400 (0000003A) $000E00 08: $000000 - - $7600 (0000003B) $001000 09: $000000 - - $7800 (0000003C) $001200 0A: $000000 - - $7A00 (0000003D) $001400 0B: $000000 - - $7C00 (0000003E) $001600 0C: $000200 - D $6600 (00100233) $001800 0D: $000201 - D $8000 (00100A40) $001A00 0E: $000201 - D $8200 (00100A41) $001C00 0F: $000201 - D $8400 (00100A42) $001E00 10: $000000 - - $8600 (00000043) $002000 11: $000000 - - $8800 (00000044) $002200Below is my diff on vmcog.spin. I have to add a mailbox and other code to vmdebug.spin to use it though and am a little hesitant to do that. I really don't want to add code directly to vmcog.spin for accessing the memory at this point. My diff tools don't work with parallax fonts (mainly the mit license) so I have to convert the files each time.
diff -c vmdebug-bst-archive-100606-144439/vmcog.spin vmdebug-bst-archive-100606-122239/vmcog.spin *** vmdebug-bst-archive-100606-144439/vmcog.spin 2010-06-06 17:22:24.124422500 -0700 --- vmdebug-bst-archive-100606-122239/vmcog.spin 2010-06-06 17:23:54.110422500 -0700 *************** *** 81,87 **** #define EXTRAM #ifdef EXTRAM ! #define PROPCADE '#define FLEXMEM '#define MORPHEUS_SPI '#define MORPHEUS_XMM --- 81,87 ---- #define EXTRAM #ifdef EXTRAM ! '#define PROPCADE '#define FLEXMEM '#define MORPHEUS_SPI '#define MORPHEUS_XMM *************** *** 91,96 **** --- 91,97 ---- '#define TRIBLADE '#define TRIBLADE_2 '#define RAMBLADE + '#define XEDODRAM #else #warn External Ram access disabled - only use memory up to WS_SIZE #endif *************** *** 354,359 **** --- 355,366 ---- #ifdef TRIBLADE 'End of TriBlade code #endif + #ifdef XEDODRAM + mov XDRAM_cmd,par + add XDRAM_cmd,#16 ' par+16 for cmd ... vmcog mailbox is 4 longs + mov XDRAM_dat,XDRAM_cmd + add XDRAM_dat,#4 ' par+20 for dat + #endif '---------------------------------------------------------------------------------------------------- ' END OF BINIT SECTION '---------------------------------------------------------------------------------------------------- *************** *** 969,974 **** --- 976,999 ---- #ifdef RAMBLADE 'End of RamBlade code #endif + #ifdef XEDODRAM + ' get 256*2 bytes + mov xcmd,vmaddr ' get physical address + and xcmd,XDRAM_amsk + or xcmd,XDRAM_rbuf ' set readbuf command + mov count,#2 + mov ptr,hubaddr ' set hub pointer + and ptr,dmask + :next + wrlong ptr,XDRAM_dat ' send new hub pointer + wrlong xcmd,XDRAM_cmd ' send command + rdlong temp,XDRAM_cmd wz + if_nz jmp #$-1 ' wait for command complete + add ptr,#256 ' incr pointers + add xcmd,#256 + djnz count,#:next ' do next 128 + #endif + ' endif XEDORAM #endif BREAD_RET ret *************** *** 1040,1045 **** --- 1065,1088 ---- #ifdef RAMBLADE 'End of RamBlade code #endif + #ifdef XEDODRAM + ' write 256*2 bytes + mov xcmd,vmaddr ' get physical address + and xcmd,XDRAM_amsk + or xcmd,XDRAM_wbuf ' set writebuf command + mov count,#2 + mov ptr,hubaddr ' set hub pointer + and ptr,dmask + :next + wrlong ptr,XDRAM_dat ' send new hub pointer + wrlong xcmd,XDRAM_cmd ' send command + rdlong temp,XDRAM_cmd wz + if_nz jmp #$-1 ' wait for command complete + add ptr,#256 ' incr pointers + add xcmd,#256 + djnz count,#:next ' do next 128 + #endif + ' endif XEDODRAM #endif BWRITE_RET ret *************** *** 1147,1152 **** --- 1190,1204 ---- offs_mask long $7FFF miso_mask long MISO ' required due to ina not being usable in destination field #endif + #ifdef XEDODRAM + xcmd long 0 + XDRAM_cmd long 0 + XDRAM_dat long 0 + XDRAM_rbuf long $7000_0000 ' always read 256 at a time ... loops 4 times + XDRAM_wbuf long $8000_0000 ' always write 256 at a time ... loops 4 times + XDRAM_amsk long $0003_ffff ' address mask ... just allow 256K for now .... + #endif + ' endif XEDODRAM #endif '----------------------------------------------------------------------------------------------------▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
mine is:
vm.start(@mailbox,$7C00,14) ' start up VMCOG
where $7C00 is the start of the last valid page (ie $7C00-$7DFF), and there are a total of 14 pages (including the last valid page)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
XDRAM_amsk long $0003_fe00 ' address mask ... just allow 256K for now ....
That will force the vmaddr to be 512 byte aligned at the start of a page.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I actually remember this problem from before I moved the read/write routines into VMCOG - I guess I re-introduced the bug when I merged the source, or later when I was trying to recover some cog memory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I'm not sure how that is relevant since your vmaddr is either and with dmask or shl by 9 before any call to BREAD/BWRITE ... unless you plan to change that [noparse]:)[/noparse]. This mask is just to keep the address from overflowing in the "physical back-store" (term usage as defined in linux and on wikipedia) EDO DRAM device.
I did notice while running my debugger for the initial port that some of your hub pointers end up having bits set in the upper word. I suppose that is an artifact of the tag line entries not being masked and is harmless for P8x32a.
EDIT: forum software ate my array declarations :<
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Post Edited (jazzed) : 6/7/2010 5:07:09 AM GMT
Yep, I see that as well.
As for my other strange output I think I've convinced myself it's in my TriBlade B* codes.
Basically I did some "perturbation" experiments like making BWRITE write out an ever increasing counter no matter what it was actually asked to write. Likewise BREAD returning a counter whatever it actually got from RAM.
I have to look at this some more, perhaps create a simple standalone external RAM test.
However I'm off on a trip to Stockholm for three days so there will be some delay.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BTW: Can you put a 1 second delay in vmdebug.spin after serial start to give the terminal time to reconnect before the menu prints?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Looking at my erroneous test results I see that towards the end of the memory dump everything is correct after a certain point but before that has very consistent errors.
So for example in the dump below everything after F200 is correct.
Now from $F200 to $10000 is 3584 bytes or 7 pages of 512 bytes. Just so happens I have nump set to 8.
Setting nump to 12 gives the cut off point for errors at $E000 with the following 5632 bytes correct. That is 11 pages of 512 bytes.
Just seems to be a bit odd that these are off by one page.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have managed to convince this to work by taking the TriBladeProp driver into use in it's own COG. This holds some signal in the correct state which otherwise is not so in the byte read/write routines.
This is only a temporary fix as we don't want to waste a COG on it.
I have included a more sophisticated RAM test which goes some way to detecting shorted data/address pathways etc.
With this test I have determined that...
The problem with the error every 512 bytes is actually nothing to do with it being the first byte of a page. I have discovered that the first write to anywhere in page does not "stick".
You will find in the heater3 test the following code that tries to create a RAM error but it does not:
[noparse][[/noparse]code
'Force an error
vm.wrvbyte($13, 2)
vm.wrvbyte(512 + $89, 9)
[noparse][[/noparse]/code]
Here we tweak two bytes in two different pages, niether of them get written
Removing the "512 +" so that they both go to the same page results in an error at address $89 the first write at $13 having been lost.
Edit: Seems I've left a redundant "byte buff[noparse][[/noparse]1024]" declaration in that code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/7/2010 4:21:46 PM GMT
Just had to fix the latching of some chip selects and such in BINIT and add a extra bit for the latch signal to the bit masks.
There will need to be some further mods to work with an SD card as it shares some RAM pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
The problem HAS to be in BUSERR. I will squish it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Good idea, I am adding the delay.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
So as soon as I squish the BUSERR "lost first write" bug, VMCOG will be functional on PropCade, TriBlade_2, and the EDO driver!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.