RetroBSD

2.11BSD operating system for microcontrollers
It is currently Wed Jun 20, 2018 5:00 pm

All times are UTC




Post new topic Reply to topic  [ 94 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Wed Oct 05, 2011 2:09 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
@madscifi:
2) my current understanding is the only "hard" requirement here is the signals are transfered to sdram at _rising_edge_ of the clock. I guess the timing is not critical when the _sequence_ of control signals and address/data is kept correct and _periods_ of the clock are not such long that the capacitors in the cells discharges. The "ns-like" timings there are coming from memory bus controller's signals specs at 133-183MHz speeds. But maybe I am wrong..
4) Great - that is ~25x faster write than an average sdcard does..
@jaromir - nice artwork! Could you upload it to the media library at this site then?

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Wed Oct 05, 2011 2:48 pm 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
Jaromir - I agree, nice layout.

Pito - My best understanding, based on reading various documents (See http://www.micron.com/support/faq/sdram.html, for example), is that the CLK must be stable. If that is not the case then it simplifies things significantly. The document I referenced gave a rather stilted response and didn't actually say it would not work. However, I'll let someone else chase down that possibility.

I've had no luck using the Burst Terminate/Stop operation in order to speed up writes. It just keeps right on writing. I'm going to ignore this for the moment as the current speed should be useful.


Top
 Profile  
 
PostPosted: Wed Oct 05, 2011 3:06 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Jim, thanks for the link. I see there Micron strongly recommends to keep CKE low before CLK is stable. So we may use pulldown resistor at CKE there. Also they support my guess that "SDRAM parts will work at very low frequencies if all data sheet specifications are met", the only thing they mention explicitly is to keep slew rate high (this is about pic32 outputs fanout/current and pcb design). From my experience the wording "CLK shall be kept stable during.." in such synchronous designs means you rather not interrupt the process for _arbitrary_ long period, i.e. 4 days (there is an upper limit given by the self-discharge rate of the memory cells' capacitors in the SDRAM, under normal conditions seconds even minutes, but it may vary with fab process, voltage and temperature). I am sure somebody may verify then. I bet it will work with clocks at 10-100Hz and signals timings within msecs. Therefore I asked on C code availability as we may use that with other designs too as the manual CLK bitbanging will work fine (as the manual routing does :) ).
PS: the SDRAM's control units and state machines are fully static designs, only the memory cells are dynamic structures (_minimal_ timings reqs in the spec - those few ns - are given by charging/discharging speed during r/w and cmos logic's speed).
PS: so the message is - when you could achieve a speed ~5-6MBytes/sec with manual clocking that would be the perfect solution. That hw clocking is a big pain..
P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Thu Oct 06, 2011 2:10 pm 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
Extending the amount of memory used has relieved that my new wiring, or my new code, is not working correctly and/or is unreliable. It will most likely take a while to figure out what is wrong.


Top
 Profile  
 
PostPosted: Thu Oct 06, 2011 4:44 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
We keep our fingers crossed for you. That's one small step for you, a giant leap for retrobsd..

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Thu Oct 06, 2011 11:27 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
FYI - the Stellaris cortex m3 (ie. LM3S9B90) has got "EPI" interface with SDRAM capability (can execute out of sdram):
"Synchronous Dynamic Random Access Memory (SDRAM) mode
– Supports x16 (single data rate) SDRAM at up to 50 MHz
– Supports low-cost SDRAMs up to 64 MB (512 megabits)
– Includes automatic refresh and access to all banks/rows
– Includes a Sleep/Standby mode to keep contents active with minimal power draw
– Multiplexed address/data interface for reduced pin count" <<<<<<
What is interesting: they use the same wiring as we are elaborating now - sdram's addresses and data lines connected in parallel.
In the datasheet there is a description of the SDRAM interface with sdram signal diagrams with muxed data/addr (Chapter 10.4.1.).
http://www.ti.com/product/lm3s9b90

The diagrams might be rewritten into asm or c (ie. with manual clocking) so we may emulate EPI interface then.. And we may use our sdram pcb as it matches exactly :).
P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sun Oct 09, 2011 3:13 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I'm afraid I have the proverbial good news/bad news to report. The good news is that I've worked out the coding bug that I introduced when converting the shared address/data lines and now basic reading/writing of bank 0 of the ram works. The bad news is that whenever 6-8 of data bits are ones it fails.

I presume at the moment that the data bits problem is due the horrible qualities of the testbed. I'm also assuming that breaking out the data from the address lines will not fix the problem, but I don't actually know that for a fact. The issue with multiple banks may well be a coding problem, I have not had time to investigate it.

I need to put this aside and work on a different project for the next couple of weeks, so I've uploaded the code as it currently stands to my github respository https://github.com/madscifi/Misc_Utils/tree/master/sdram_interface_16_shared/sdram_interface in case anyone else has time/hardware to work on the issue in the meantime.


Top
 Profile  
 
PostPosted: Wed Oct 12, 2011 3:53 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
It could be the wiring contributes to an unstability as well. So the pcb with a good decoupling may help.
On the other hand I still think a simple rewrite of the EPI into C with manual clocking may help too. Write/read to sdram is done on the leading edge of CLK only, so toggling to 1 and back to 0 will do and it takes 25ns when run in sram. Worth of try :).P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sun Apr 15, 2012 10:29 pm 

Joined: Sun Apr 15, 2012 8:15 pm
Posts: 1
There has been no activity on this thread for 6 months or so - does this mean the SDRAM project has been shelved for the time being?
I was enticed by the 5MB/sec transfer rate and followed the thread with great interest and was about to build a small proof of concept board when I discovered that the project may be in limbo - and later postings on a different thread seem to indicate that it may be better to just stick with TSOP - SRAM ?

RK


Top
 Profile  
 
PostPosted: Mon Apr 16, 2012 1:37 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Maybe the very old drams are easier to handle (ie 421000, 511000), but not easy to get today.. The newest ones seem to be very complex to handle..

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sun Sep 23, 2012 2:35 pm 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
I decided to pull the hardware back out and give this another try. The shared data/address line approach was abandoned as I was never able to get it to work reliably.

At this point swap-on-sdram is working with code based on the latest revision in svn. A lot of the existing swap-to-ram code was reused. In order to minimize processor pins only 8 of the 16 data pins on the sdram are used. Twenty-eight processor pins are needed to get 8 megs of space (although only 2 megs is being used at the moment in the software).

The test bed uses a HY57V281620 memory chip that was pulled from an old hard disk, soldered to a breakout board, and wire-wrapped to a UBW32. A AS4C8M16S128 chip, which can be purchased new for about $1.67 in single units, should be a drop in replacement (note that I have not actually tried one yet).

The code needs a *lot* of cleanup so it will be a week or two before it goes up on the svn site. I will have some questions about how to best integrate this code with the existing ram-based swap.

The code reserves 2k of kernel ram because the core functions need to execute out of ram due to the tight timing requirements. Consequently, it does not fit alongside the USB-based console.

Hopefully I'll remember to press the Submit button this time. ;)


Top
 Profile  
 
PostPosted: Sun Sep 23, 2012 3:28 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Great! I still think the timing parameters could be relaxed with retrobsd, but we will see.. Moreover, there is that Stellaris EPI interface - they really use DQx-ADx connected in parallel (as we elaborated in past), so we can try to emulate it. Typical 8Mx16 SDRAM connected (ie IS42S16100E) = 24 lines used.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sun Sep 23, 2012 6:01 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
I have stacks of of SDRAM chips here that I really would love to use with Retro. The SDRAM interface has always been a bit of a mystery to me - it would be great to be able to pull apart your code and work out just how it works.

I also have some old FPM DIMMs from an old SUN server that I think will be easier to get working (I even have the DIMM slots for them). I guess I could build a DIMM slot breakout board. Either that or I could just cook the chips off the DIMMs and use them direct... Hmmm...

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
PostPosted: Thu Sep 27, 2012 1:19 pm 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
Pito, would you mind running the command "ps -aux" on a system with ram-based swap and let me know if it displays the command lines correctly for all of the processes? I've been trying to track down the error in my swap code that is causing the command names to be messed up on out-of-memory processes in the ps output, but I cannot find any reason for the problem in the ram interface code.

Thanks.


Top
 Profile  
 
PostPosted: Thu Sep 27, 2012 1:46 pm 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
Pito, thanks, I figured out the problem.

The default swap device used by ps to determine the command line for each out-of-process swap is /dev/swap. However, the device id on /dev/swap is (char 3,0), which points to the sdcard in the kernel. The device id for the swap device internally is (block 1,0) or (char 6,0). If ps is told to use /dev/sw0 (block device id 1,0) or /dev/rsw0 (char device id 6,0) then it works with ram-based swap.

At the risk of stating the obvious, to fix the bug on a system with ram-based swap, login as root and:

rm /dev/swap

mknod /dev/swap c 6 0


Top
 Profile  
 
PostPosted: Thu Sep 27, 2012 1:57 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Yea I have to:
rm /dev/swap
mknod /dev/swap c 6 0
to see the stuff in ps properly.. Maybe worth of adding somewhere in.. Does your sdram work already?

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Thu Sep 27, 2012 2:16 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
I am doing it manually all the time (the fix has been suggested by Serge to me long time back so the risk is low..), as well as inhibiting the swapdev stuff in "init_kernel" when using sw0 as the filesystem only. Maybe our developers shall incorporate that in the source (ie. with switches like -DSWAP_RAMDSK -DFS_RAMDSK or so) to make it easier for ramdisk owners :)

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Thu Sep 27, 2012 2:27 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
It is in init_main.c :
/* Find a swap file. */
#ifdef SWAPDEV
..
so
#if 0 //def SWAPDEV
will enable ramdisk for the mount of a filesystem on it..

BUT NOT BOTH :) This is a problem we have to tackle somehow - to be able to run swpadevice and filesystem both on the ramdisk, otherwise the idea of larger ramdisks is void..

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Thu Sep 27, 2012 3:24 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Serge has provided an utility for testing the external ramdisks - "disktool". The SWAPDEV shall be commented out in init_main.c(see above). In the board's makefile the SWAPDEV shall be enabled.
For example (where 2047, or other size, are 1kB large blocks):

# disktool -f 0xFF /dev/rsw0 2047
It fills the memory (0-2047kB) with given value and tests the result.

# disktool -v -c /dev/rsw0
It writes a counter pattern to block 0 and reads it back.

# disktool -v -b /dev/rsw0 2047
It checks all address bus by testing blocks 0-1-2-4-8-16...-1024-2047.

Unless disktool shows none errors it has no sense to connect the ramdisk as the swapdevice..

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sat Sep 29, 2012 1:23 am 
Committer

Joined: Thu Nov 08, 2012 3:55 am
Posts: 177
Pito, thanks for the information on the disktool.

The sdram is working. I did spend 3 evenings trying to track down the phantom bug that I assumed had to be in the sdram code and that had to be causing the output of "ps -aux" to be wrong, but as that issue is now resolved I hope to check the code into a branch on SVN this weekend. It still needs some work, specifically it needs to be optimized to minimize data transfers and to optimize the hardware, but it is currently functional.

Which brings me to the following question: What is the purpose of /dev/swap? That is, is its purpose to provide programs in userspace with access to the swap space as defined in the kernel, or it is to specify where the kernel should put swap?

I see several approaches to resolving the swap issue but I'm not certain which approach would be best.

1) Create a new swap device that is always the device used for swap and have the kernel map it to the correctly physical device based on the kernel build.

2) Have the kernel build control the swap device as it does now, but also have it update /dev/swap on the root filesystem at startup, if needed, to point to the correct device.

3) Have /dev/swap specify the swap device. That is, have the kernel read the device specified by /dev/swap at startup and place swap on the specified device. This means the swap device can be modified and changed by the user without rebuilding the kernel (assuming the appropriate device exists). Note that a reboot would be required to make any change to /dev/swap take effect.

Any opinions? Anyone know how it is "supposed" to work?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 94 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission