Hi Chris,

I have a quick question. We have a 256MB enp2505 board but linux (free) reports 64MB. Any idea how to fix this?

It's a feature. Only 64MB is directly controlled by linux, e.g. used by the kernel and as user page frame area. The rest is uncontrolled so you can use it as you please without negotiating with the kernel. You could probably contrive to expand linux's portion but I like to think of it as a reminder that you're not supposed to get too enamored with linux on the strongarm, you're supposed to get back to work writing code for those uEngines :-). Other useful memory tidbits if you're looking at it for the first time: o It's the "second quarter" of the SDRAM that linux owns: byte addresses 64M to 128M. o The bottom half (128MB) of the SDRAM is mapped by default into the virtual address space of every user process on the strongarm. To access it, #include and use "DRAM_BASE" as the base virtual address. o Yes, you play "core wars" on your own kernel this way. Try it! o I don't know why it's half. Looks like a holdover from an older board that would require moving regions around in order to change, doubtless breaking something. o The whole (256MB) of SDRAM are mapped as physical memory on the PCI bus by the host system. o There are four "even/odd" banks in this configuration, corresponding (I *believe*) to the four quarters (HW ref, p. 234). However, before getting excited about banks, note that the "optimize_mem" feature doesn't work (errata #40 in the spec update) in C0 and earlier silicon (which is all IXP1200 silicon so far, AFAIK). I mention this only because I went down this particular rathole before learning *always* to read the errata sheet. regards, -- Ken