Hi Richard, John Williams wrote: > Today's been megahectic - if I get a chance tonight or tomorrow I'll > shrink a stock mbvanilla_net down to 8MB and see if I can duplicate your > problem. OK, here's what I did: Take a clean CVS uClinux-2.4.x kernel Modify the mbvanilla link script to 8MB of RAM Modify include/asm-microblaze/mbvanilla.h ERAM_SIZE to 8MB copy your .config file into linux-2.4.x/.config make menuconfig, save and exit etc etc make I download this image.bin to my regular (ie 32MB) mbvanilla platform - it worked first time, clean boot, no errors, shell prompt etc etc. This image.bin is attached, give it a go on your platform. If it works, it means you've accidentally broken something in your local kernel - just repeat my steps above and you'll be laughing. (One thing I'm curious about, in your first messaegs to the uclinux-dev list, you had a booting kernel, but it broke on entry to userland. what's changed?) Anyway next, I tweaked a standard mbvanilla_net MHS file by just truncating the external RAM (DDR, but it shouldn't matter) down to 8MB. Built this system, configured it, downloaded the same kernel image, and again everything works - snippet of bootlog to prove it: Linux version 2.4.27-uc0 (jwilliam@g435-9029) (gcc version 2.94 On node 0 totalpages: 2048 zone(0): 2048 pages. zone(1): 0 pages. zone(2): 0 pages. CPU: MICROBLAZE Console: xmbserial on UARTLite Kernel command line: Calibrating delay loop... 1.77 BogoMIPS Memory: 8MB = 8MB total Memory: 6336KB available (1084K code, 674K data, 44K init) Dentry cache hash table entries: 1024 (order: 1, 8192 bytes) Inode cache hash table entries: 512 (order: 0, 4096 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 2048 (order: 1, 8192 bytes) POSIX conformance testing by UNIFIX ... So, if my image.bin works for you, problem solved. If my image.bin *doesn't* work, then it seems there's still an issue in your hardware somewhere. We'll just keep chipping away until you find it. The fact that you got an OK kernel boot late last week but not now suggests hardware is probably fine - chances are you've just nudged something in the kernel and forgotten about it - a fresh start will probably solve the problem. > Once we solve this, it really, really, really needs to be a FAQ! I'm thinking I should just parameterise the ERAM_START and ERAM_SIZE into the kernel config - any comments from interested parties? Regards, John
Attachment:
image.bin
Description: application/msdos-program