July 2001 - ixp1200 - lists.cs.princeton.edu

linux on ixps and memory map
by Josh Fryman 14 Sep '01

14 Sep '01

hi all, this is a follow-on to my earlier question. i got enough information to find a trivial way to change the amount of memory linux is using, but now i'm trying to do some more challenging things, and having no luck. first off, to change the amount of memory being used, the simplest way is to edit "arch/arm/kernel/setup.c" and change the "#define CONFIG_CMDLINE" to include "mem=XM", where X=4,6,8... i received many suggestions, but they all involved more work than this ;) [note: X = size of space for linux + size of ramdisk] second, by resizing the ramdisk image down to 6MB from 8MB, we were able to save another little bit of space. between these two options, we can comfortably run linux in a 14MB footprint... but that leaves now 18MB of free space. now what we want to do is to move this space used by linux and ramdisk to the top or bottom of memory, and increasing the SDRAM_PACKET_xxx values such that instead of the sdram uncached packet buffer area being 8MB, it's increased to 18MB. i've modified the various values in include/asm-arm/arch-ixp1200/ hardware.h ixp1200eb.h arch/arm/mm/ mm-ixp1200.c the various combinations i've tried: - make the buffer at the top of memory, size > 8MB - make the buffer at the bottom of memory, size > 8MB - make the buffer in the middle of memory, size > 8MB - make TWO buffers, at top and bottom, each size = 8MB no matter how i try to modify the behavior in these files, if i make the buffer > 8MB, OR if i move the linux base address away from 0xc080...., OR if i try and add a 2nd buffer region... the system won't boot correctly. the most common behavior is lockup either when it reaches "Uncompress..............................done," or when it tries to initialize the Intel EEPro 10/100 card, at which point it fails the self-test and the system generally panics. does anyone have any idea what i'm doing wrong? i'm careful to modify those values that should - such as base addresses of the SDRAM_PACKET and SDRAM_BASE, sizes, etc, but no matter how i try, i can't seem to make this work. has anyone been able to move the memory blocks around? thanks for any input, josh fryman

2 1

RE: [ixp1200] GigaMAC <--> switch problems...
by Brandewie, Dirk J 31 Jul '01

31 Jul '01

Hi Austen, I will try to find someone that might have some advice on this. --Dirk > -----Original Message----- > From: Austen McDonald [mailto:austen@cc.gatech.edu] > Sent: Tuesday, July 31, 2001 12:52 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: [ixp1200] GigaMAC <--> switch problems... > > > > Has anyone connected their GigaMACs to gigabit switches? We have > one old 3com switch w/ one gigabit connection and it seems to > work fine w/ > autoconfiguation enabled. However, when I try it w/ our > Alteon ACEswitch > 180 it wont give me a link light. Between the 3com and the > Alteon requires > that auotconfiguration be turned off---I try to mimic these settings > between the IXP and the Alteon but the link just wont work. > Any tricks? > Im writing 0x0140 to the GMII_CTL register to disable the > autoconf. > > Austen McDonald > austen(a)cc.gatech.edu > > God does not care about our mathematical difficulties. > He integrates empirically. > -- Albert Einstein > >

1 0

GigaMAC <--> switch problems...
by Austen McDonald 31 Jul '01

31 Jul '01

Has anyone connected their GigaMACs to gigabit switches? We have one old 3com switch w/ one gigabit connection and it seems to work fine w/ autoconfiguation enabled. However, when I try it w/ our Alteon ACEswitch 180 it wont give me a link light. Between the 3com and the Alteon requires that auotconfiguration be turned off---I try to mimic these settings between the IXP and the Alteon but the link just wont work. Any tricks? Im writing 0x0140 to the GMII_CTL register to disable the autoconf. Austen McDonald austen(a)cc.gatech.edu God does not care about our mathematical difficulties. He integrates empirically. -- Albert Einstein

1 0

Hardware problem: won't book the BootMgr...
by Austen McDonald 19 Jul '01

19 Jul '01

My IXP appears not to boot the BootMgr: when I turn it on, it just sets the LEDs to 00 and then sits--no output on the serial or anything. I can boot it into diagnostics but it fails (or rather, doesnt get past) the IRQ/FIQ test: it never prints test complete. All the jumpers are set to factory default. Does anyone know what is wrong with it and to how fix it? Austen McDonald austen(a)cc.gatech.edu God does not care about our mathematical difficulties. He integrates empirically. -- Albert Einstein

3 2

RE: [ixp1200] questions on memory in linux
by Naik, Uday 11 Jul '01

11 Jul '01

a) For memory, one easy solution is to map this memory as unprotected uncached memory in kernel space. We did exactly this. Look at the ixp1200 linux kernel on www.netwinder.org/~urnaik Look at mm-ixp1200.c, and include/asm/arch/hardware.h. We mapped the packet memory into virtual memory 0xd8000000 with cache off and memory protection off. It is accessible to all processes at that address. b) This is doable. Cygmon puts the boot string into 0xc0000000. But currently the linux port does not read this string. You need to change the head.S in arch/arm/boot/compressed Regards Uday -----Original Message----- From: Josh Fryman [mailto:fryman@cc.gatech.edu] Sent: Tuesday, July 10, 2001 11:44 AM To: ixp1200(a)CS.Princeton.EDU; linux-kernel(a)vger.kernel.org Subject: [ixp1200] questions on memory in linux hi, we've got some intel IXP 1200 (spin B0) eval boards, and are running linux in them. we have some questions about how to do specific things with (a) memory and (b) the cygmon mini-boot loader... (a) memory: the IXP 1200 boards have 32M of SDRAM in two 16MB banks. the bottom 24MB are used for linux, the rest are free... however, we want to allocate some memory in that first bank and *tie* it down so that it's always available at that address physically to the IXP microengines as well as virtually to the linux system. can anyone provide pointers to FAQs or other documents for handling this? eg, some way to do a malloc( 1MB ) and then get the true physical address of the malloc results? (b) the IXP 1200 has a SA-1100 core running the cygmon mini loader from flash. is there any way to specify kernel-load arguments, similar to how LILO works, with this system? any pointers to where we can find out more details for this? the process is to boot the cygmon from flash, give it the parameters for where to TFTP the kernel / ramdisk from, and then let it run. we'd like to force the kernel to run with a "mem=4M" type of setting so it doesn't suck down our very meager memory for buffers we don't want/need. (note, if we can do this, the part (a) above doesn't necessarily go away... it's something we still need to know how to do...) thanks for any input, josh

1 0

questions on memory in linux
by Josh Fryman 10 Jul '01

10 Jul '01

hi, we've got some intel IXP 1200 (spin B0) eval boards, and are running linux in them. we have some questions about how to do specific things with (a) memory and (b) the cygmon mini-boot loader... (a) memory: the IXP 1200 boards have 32M of SDRAM in two 16MB banks. the bottom 24MB are used for linux, the rest are free... however, we want to allocate some memory in that first bank and *tie* it down so that it's always available at that address physically to the IXP microengines as well as virtually to the linux system. can anyone provide pointers to FAQs or other documents for handling this? eg, some way to do a malloc( 1MB ) and then get the true physical address of the malloc results? (b) the IXP 1200 has a SA-1100 core running the cygmon mini loader from flash. is there any way to specify kernel-load arguments, similar to how LILO works, with this system? any pointers to where we can find out more details for this? the process is to boot the cygmon from flash, give it the parameters for where to TFTP the kernel / ramdisk from, and then let it run. we'd like to force the kernel to run with a "mem=4M" type of setting so it doesn't suck down our very meager memory for buffers we don't want/need. (note, if we can do this, the part (a) above doesn't necessarily go away... it's something we still need to know how to do...) thanks for any input, josh

1 0