1.50 EUR DDR1 Memory now available!! How to replace HYNIX DDR?

[srungerson]

The Industrial Variant of Micron is :
Long life industrial temp part: MT46V32M16P-5B XIT:J
Commercial temp part: MT46V32M16P-5B:J

Both are stocked in the USA. However, as I mentioned above, any rev:J does not work,  only  :F version works

J now gives  Undefined Instruction  r14_ on DDR Intit...

Best , SR

(Still hoping someone can tell me what to change to get it to boot!) If needed I can pay for someones time

SR

[RSA]

Try setting EN_LOWPOWER_MODE bit in DRAM control register 05.
(this enables the otherwise undefined DRAM Extended Mode register to be written)

For me this allowed the Alliance chip to boot without error.

[jaycarlson]

Try setting EN_LOWPOWER_MODE bit in DRAM control register 05. ...For me this allowed the Alliance chip to boot without error.

Wow! After making this change, I can verify this at least gets the system up and running. Because of stability issues, I had to cut the clock down to get Linux to boot. I'm going to start investigating changing timing parameters, but I was wondering if you had to make any other changes, RSA?

[srungerson]

Jay,

Are you also testing the Alliance DDR chip or the Micron Revision J DDR?

Thanks
SR

[RSA]

Jay,

I also see stability issues with linux which I think are related to timing but I didn't check any further. I decided to check the Micron part first to see if that one works with the current timing settings (awaiting delivery of the parts).

[RSA]

SR,

I've just mounted the Micron part MT46V32M16P-5B:J
This part works straight out of the box, no changes to the DRAM registers required !
To me this seems to be a straight replacement for the Hynix part.

[jaycarlson]

srungerson,
I'm talking about the Alliance part.

Once I cut the clock in half, I stress-tested it all weekend and it's still running fine. I tried running at an intermediate frequency (somewhere between 266 and 133) and it doesn't seem to like that very much. I'm going to try to play around with some of the imx233 DRAM controller registers, but there's 41 of them (!!!), so it might take a while to figure out possible fixes for the Alliance part -- other than running my board at half-speed.

RSA -- great to hear about the Micro part -- but where the heck do you source it? I can't find it on any of the distributors I go through for small-volume stuff (DigiKey, Newark, Mouser). It's also very expensive compared to the Alliance part; that's why I'm so interested in getting that part working.

[RSA]

Jay,

I got the Micron part at nl.farnell.com (at low volume it is expensive indeed).
For me the Alliance part has too many pitfalls such as the needed timing changes in the registers and it uses 2x more power compared to Micron or Hynix part.

[srungerson]

Micron rev J: is much less power than Rev F in standby   (30-50%!)

[srungerson]

RSA... I have one question..

Can you post or link to the the DDR registers you are using.

It seems to me there may be different versions and this may be why there are different results. I know Olimex made changes from Freescale, so I am not sure if we are all using the same registers setting.

Thanks
SR

[jaycarlson]

I'm not sure what you mean when you talk about changes "Olimex made" -- but in U-Boot, the current value of the register is 0. Change it to 1. That's all that needs to be changed to get things working -- though, as we've mentioned, we had to cut the clock in half to get it to run stable. I'm going to look into timing parameters once I have some free time.

[srungerson]

I have a compiled Olimex image that was shipped in an MicroSD card with my IMX233 Micro. This works 100% of the time with REV J:

However I have downloaded source that only works with F: and does not boot with Rev J: .
This is available here: www.ghlsystems.com:3000/redmine/projects/l280/repository/revisions/11/entry/src/boot/uboot/bootloader/imx-bootlets-src-10.12.01/boot_prep/init-mx23.c

The GITHUB/FREESCAKE source does not output the same DEBUG RS-232 output as my Olimex Factory SDCard

Olimex code includes a debug line from the source highlighted in RED below... This line is NOT included in the Github/Freescale code, so we know there are two builds.


May 11 201215:26:EMI_CTRL 0x1C08404init_ddr_mt46v32m10Frac 0x92926192
LJUncompressing Linux... done, booting the kernel.
Linux version 2.6.35.3_OLinuXinoR4 ... (hehopmajieh@hehopmajieh-office) (gcc version 4.7.1 20120421 (prerelease) (GCC) ) #11 PREEMPT Mon May 21 10:27:52 EEST 2012

In summary... I'd really like to see what we are all using for DDR register constants.. or if ANYONE has an init-mx23.c with the debug output text "init_ddr_mt46v32m10"" . If this debug phrase is in the source code, then I would LOVE to see it! My guess is the DDR init routine or registers are different than the Freescale code.

Thanks for reading this long post

[RSA]

I'm not using any Olimex sources, I'm using the freescale imx-bootlets-src-10.05.02 with barebox as bootloader.

Anyway, the relevant register settings in init-mx23.c:

void init_ddr_mt46v32m16_133Mhz(int ce)
{
   HW_DRAM_CTL00_WR(0x01010001);
   HW_DRAM_CTL01_WR(0x00010100);
   HW_DRAM_CTL02_WR(0x01000101);
   HW_DRAM_CTL03_WR(0x00000001);
   HW_DRAM_CTL04_WR(0x00000101);
   HW_DRAM_CTL05_WR(0x00000000); //EN_LOWPOWER_MODE for setting EMRS with alliance memory set bit 0 to 1
   HW_DRAM_CTL06_WR(0x00010000);
   HW_DRAM_CTL07_WR(0x01000001);
   HW_DRAM_CTL09_WR(0x00000001);
   HW_DRAM_CTL10_WR(0x07000200);
   HW_DRAM_CTL11_WR(0x00070202);
   HW_DRAM_CTL12_WR(0x02020000);
   HW_DRAM_CTL13_WR(0x04040a01);
   HW_DRAM_CTL14_WR(0x00000200|ce);
   HW_DRAM_CTL15_WR(0x02040000);
   HW_DRAM_CTL16_WR(0x02000000);
   HW_DRAM_CTL17_WR(0x19000f08);
   HW_DRAM_CTL18_WR(0x0d0d0000);
   HW_DRAM_CTL19_WR(0x02021313);
   HW_DRAM_CTL20_WR(0x02061521);
   HW_DRAM_CTL21_WR(0x0000000a);
   HW_DRAM_CTL22_WR(0x00080008);
   HW_DRAM_CTL23_WR(0x00200020);
   HW_DRAM_CTL24_WR(0x00200020);
   HW_DRAM_CTL25_WR(0x00200020);
   HW_DRAM_CTL26_WR(0x000003f7);
   HW_DRAM_CTL29_WR(0x00000020);
   HW_DRAM_CTL30_WR(0x00000020);
   HW_DRAM_CTL31_WR(0x00c80000);
   HW_DRAM_CTL32_WR(0x000a23cd);
   HW_DRAM_CTL33_WR(0x000000c8);
   HW_DRAM_CTL34_WR(0x00006665);
   HW_DRAM_CTL36_WR(0x00000101);
   HW_DRAM_CTL37_WR(0x00040001);
   HW_DRAM_CTL38_WR(0x00000000);
   HW_DRAM_CTL39_WR(0x00000000);
   HW_DRAM_CTL40_WR(0x00010000);
   HW_DRAM_CTL08_WR(0x01000000);

}

[jlumme]

Sorry for raising this topic back from the dead, but I didn't want to start a new one since the topic is exactly about the Alliance AS4C32M16D1 chip.

We made a production run with this chip (actually we made boards also with ISSI IS43R16320D, but it has some other issues currently), and after lowering the clock speed to 96mhz (and lowering CAS value to 3), I can boot u-boot every time, but the chip is recognized as 16MB part instead of 64MB.
u-boot seems stable, but if I try to load linux to memory, after I try to boot it, bootm complains that it doesn't recognize the image (I wonder if loading was corrupted, or data is plain lost).

If I flash the same image to a board with original memory used by Olimex (Hynix), it's recognized appropriately - so I think ADDR_PINS and COLUMN_SIZE should be correct as these chips share same count for address and row pins.

I noticed that if I tinker with other values (caslat_lin, caslat_lin_gate, cas), I can get this chip "recognized" as 8MB chip as well (strange, I know), but at that time uboot is not stable, and usually results into reset at some point if I try executing some commands.

The earlier suggestion by some people of setting lowpower_en bit in control register 5 does not help this board to wake up.

Has anyone seen this type of situation where memory chip is not recognized appropriately ? Could this even be a real 16MB chip that was sold as 64MB (though the markings are correct on the chip) ?

[jaycarlson]

This is probably way too late a reply, but if anyone is looking for a solution, changing CAS Latency from 2.0 to CL=2.5 will make the Alliance memory work.