[PATCH] MPC8xx PCMCIA driver
Hello all, Nice to see that this driver gets forward ported to 2.6. I originally wrote it for pcmcia-cs, but it made its way into 2.4 after a while. Thanks to all the people who added code and fixes. I'm not sure how the current Linux pcmcia layer works, and I am not involved in powerpc land anymore so I have no comments on the porting work or the driver itself. On 9/1/05, Dominik Brodowski wrote: > On Mon, Aug 29, 2005 at 11:48:40PM -0300, Marcelo Tosatti wrote: > > Russell: The driver is using pccard_nonstatic_ops for card window > > management, even though the driver its marked SS_STATIC_MAP (using > > mem->static_map). > > This is obviously broken. Where does it fail if pccard_static_ops is used? I remember it was interesting to write the driver for pcmcia-cs. This was because the mpc8xx socket hardware did not implement per-window offsets, and pcmcia-cs required that. So a wild guess is that this static/notstatic thing is related to that. / magnus
[PATCH] drivers/ide/ppc/mpc8xx.c - volatile fix
Hello, I fixed this in a local tree for a customer half a year ago (mvl-3.1) and forgot to report it to the lists. Now I came across it in vanilla 2.5.10-rc3. I have not tested the fix but it is pretty obvious that access with a non-volatile pointer to hardware is bad, at least with gcc-3 or above. Please apply. Or ignore if already fixed. =) Thanks. / magnus (needs CC) -- next part -- A non-text attachment was scrubbed... Name: linux-2.6.9-mpc8xx-volatile.patch Type: application/octet-stream Size: 376 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20041211/47b51773/attachment.obj
Why not kmalloc() ??
On Fri, 2004-07-16 at 11:25, Rupesh S wrote: > Hi, > > I just figured out that I need to use m8xx_cpm_hostalloc() to allocate memory > for "buffer" that needs to be attached to the "Buffer Descriptor" of an > MPC8xx CPM peripheral (like IIC, SPI, SCC etc). Instead, if I try to use > kmalloc() or a static memory allocation, my driver isn't working. > > 1) Can somebody throw some light on what exactly is the difference between > m8xx_cpm_hostalloc() and kmalloc(). kmalloc allocates from the kernel memory pool, ie your sdram. you usually have several megabytes of sdram. hostalloc allocates memory from the internal dpram area in the mpc8xx processor. a mpc8xx-processor usually has around 4-8 kilobyte dpram. > 2) Why is the difference important in ppc linux ? the dpram (dual port ram) is used to communicate with the cpm devices such as scc:s and smc.s found inside processors from the mpc8xx family. the powerpc core has access to one side, the cpm has access to the other side of the dual port memory. sort of anyway. consult your friendly mpc8xx manual for further info. /magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Initrd and PPCbug, can it work?
On Tue, 27 Apr 2004 14:45:17 +0200 Oliver Korpilla wrote: > Use the initrd loaded with the kernel as a root filesystem in memory > after bootup. > > Exactly what commandline parameters for the kernel would I need to make > that? I don't know what magic patches that are applied to the mvl-3.1 kernel that a customer of mine use, but we use one kernel with initrd (ext2fs) and nfs root + ip pnp support. Then we select at boot-time how we want to boot the system: Development: "noinitrd ip=on nfsroot=192.168.1.1:/home/nfs/foobar" Standalone: "ip=off" We boot a "Gzipped Multi-File Image" from u-boot, but I guess that booting a standard zImage from anywhere would do too. / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Initrd and PPCbug, can it work?
On Tue, 27 Apr 2004 11:42:12 +0200 Oliver Korpilla wrote: > This was the first I checked - CONFIG_EXT2_FS is set to y. Besides, I > tried doing the same with a cramfs initrd - won't work either. Cannot > say whether I configured that right. > > Maybe this is an endianess problem in my initrds? As long as you use ext2 you should not have any endian problems. It might be tempting to use other fancy filesystems, but I don't like endian problems so I usually stick to ext2. I create my ext2 initrds on x86 systems and use them on ppc without problems. / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problem cross-compiling for MPC860T on x86 host
Unless you've done some wierdo chroot-build, "-I/usr/src/linux/include" probably points to include files for your build/host machine. You want the includes for your cross target. The error you see is probably because the ppc-compiler does not know how to compile x86 assembly. / magnus On Mon, 20 Oct 2003 10:01:12 -0700 "L. Puneeth Rao" wrote: > > Greetings All, > I have a MPC860T evaluation board, and i would like to load > linux2.4 kernel. For this i have used a x86 system as host machine and > followed the procedure prescribed in > http://penguinppc.org/embedded/cross-compiling/. i have obtained 2.4.18 > kernel sources and applied the suggested patch ppc-patch-2.4.18 and > additional tools used are gcc-core-3.3.1 and binutils-2.11.90.0.8. Upon > executing make zImage i found the following errors. it is only one type of > error repeated over and over. > kindly suggest some way out. TIA > with regards, > Puneeth > > make zImage > powerpc-linux-gcc -D__KERNEL__ -I/usr/src/linux/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer > -fno-strict-aliasing -fno-common -D__powerpc__ -fsigned-char -msoft-float > -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring > -mcpu=860 -DKBUILD_BASENAME=main -c -o init/main.o init/main.c > /usr/src/linux/include/asm/unistd.h: In function `do_linuxrc': > /usr/src/linux/include/asm/unistd.h:413: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:413: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h: In function `prepare_namespace': > /usr/src/linux/include/asm/unistd.h:416: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:416: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h: In function `init': > /usr/src/linux/include/asm/unistd.h:413: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:413: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h: In function `write': > /usr/src/linux/include/asm/unistd.h:408: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:408: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h: In function `read': > /usr/src/linux/include/asm/unistd.h:409: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:409: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h: In function `lseek': > /usr/src/linux/include/asm/unistd.h:410: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:410: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h: In function `execve': > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_4' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h:412: error: asm-specifier for variable > `__sc_5' conflicts with asm clobber list > /usr/src/linux/include/asm/unistd.h: In function `open': > /usr/src/linux/include/asm/unistd.h:413: error: asm-specifier for variable > `__sc_4' c
x86(host) --> ppc(tgt) cross-tool-chain
I don't know about that book and your specific glibc version, but earlier versions of glibc (2.1.3) needed a patch to correctly support powerpc processors with 16-byte cachelines like the 4xx- and 8xx-series. I've built several cross compilers (for ppc) from scratch for use on x86-based machines using gcc-2.95.3 and glibc-2.1.3. I have tested several binutils versions, don't remember all right now, but I think binutils-2.11.2 worked out ok except for some strip command line problems. And yes, the toolchain was used with mpc8xx processors. / magnus On Fri, 6 Jun 2003 07:11:39 -0700 brian.auld at adic.com wrote: > > Hello, > > Using Karim's new book "Building Embedded Linux Systems", has anyone out > there successfully built an x86(host) --> ppc(tgt) tool chain using the > versions stipulated in the book (gcc 2.95.3, binutils: 2.10.1, glibc, 2.2.1). > > If yes: > > (a) What host system are you using? > > (b) Did you diverge from the directions in the book? > > If no: > > (a) Can someone out there suggest a known valid combination? > > > I anticipate needing ssh, some web-server and snmp as application > requirements, so I figured it would be prudent to get the tool-chain working > with glibc as opposed to uClibc. > > -- Brian > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Failsafe bootloader
On Tue, 3 Jun 2003 23:47:22 -0700 Darin.Johnson at nokia.com wrote: > It also could be very nice if you could upgrade the lowest level of software, > the boot loader or system initializer (ppcboot, etc). We had found a bug in > our loader at one point, and because many registers are "write once" it was > difficult to fix these settings from the application software. But finding a > foolproof and reliable way to upgrade the boot loader software is difficult, > especially if you are relying on customers and operators to do the upgrading. And that's why you should use Miniboot as your first bootloader. =) It's not upgradeable itself, but it is used to load and update a secondary bootloader. Miniboot itself should be very small and simple to keep the number of bugs low. It only requires the internal memory of the mpc8xx so almost all hardware initialization is made after miniboot has run, and therefore is upgradeable. Need to upgrade your hardware configuration? No problem as long as you haven't changed CS0 or your SMC... =) And yes, it runs with watchdog on and leaves that configuration up to the secondary bootloader. http://opensource.se/projects/miniboot/index.html However, the number of boards / processors supported are limited at the moment. I've also heard that uboot/ppcboot could be used to update itself, but I've never tested it myself. / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
file system over CF flash
There is no need for any special Flash file system, the Compact Flash itself keeps track of things like wear levelling, sector size and command set of the flash devices. The exported interface for a Compact Flash is just like any ATA Flash and under Linux the standard IDE driver is normally used. The CF needs to be mapped into some address space however, and this setup is usually taken care of by the PCMCIA layer or the firmware/bootloader of your specific board. So the Compact Flash itself does not limit you to any special kind of filesystem, but I think the CF devices are shipped with some kind of FAT filesystem by default. Then what this "xilinx virtex-ii pro eval board ML300" might assume is another thing. / magnus On Sun, 1 Jun 2003 10:46:17 +0800 ?? wrote: > > There is a CF flash of IBM MicroDrive in xilinx virtex-ii pro eval board > ML300. > Can someone tell me what type of fs is used over such kind of flash device? > > thanks in advance > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ppcboot
Hi, > I'm working on a motorola MPc8xx. i would like to know if it's possible > to run ppcboot trough an another ppcboot I know people that run ppcboot from miniboot. http://opensource.se/projects/miniboot/ / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linuxppc on dsp-board
I've actually run Linux on a hardware that might be something like yours, but it was 3 years ago now. A 2.2-kernel. The board we used had a 860 and a Texas DSP + some kind of FPGA, great for telecommunications... I wrote a small piece of boot software that could be compiled to be placed in the internal DPRAM by a BDM or be burned into flash. The boot software then started a zImage from ram or from flash. I would suggest you to burn a zImage.embedded into the flash. / magnus On Sat, 15 Mar 2003 00:12:59 +0100 Guenther SOMMER wrote: > > > i'd like to start linux on a dsp-board (where no linux has gone before :))) > > > > it's a dsp-board with some dsp on board an a motorola 860 processor. the > > board itself has 32mb sdram and 8 mb flash. the board has a bootloader > > integrated, which configures the mpcs and start a simple "boot-aplication". > > i didn't write it straightforward. i mean it should run on the > control-processor (the mpc860), not on the dsps itself. but i think it > would be cool, if linux lets the "dsp-dolls" dance :) > > grettings, guenther sommer. > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA
Hi, > We are using MPC860T with one possible PCMCIA port and Montavista kernel > 2.4.2. > So it is possible to use every PCMCIA card, which is supported by Linux? Not all cards worked "right out of the box" when I wrote the socket driver. And I don't think that all of them will work today either. There are many things that might cause problems - endian unawareness, timing stuff etc. So you will not be able to install a set of RPMs on your hardware and then just insert any PCMCIA card and hear bleep-bleep and everything works. No. But with some hacking and some knowledge of Linux and PCMCIA you will probably find out a collection of PCMCIA cards that will work ok. I don't know how many PCMCIA cards that Linux/pcmcia-cs supports, but I guess that everyone uses CARDBUS today instead of PCMCIA. 32 bits are much more fun. I think that I read that someone was planning on writing a list, but I don't remeber seeing any actual output. Or maybe I missed that. There are (were anyhow) many things that differs between a common PC and the Linux implementation on a embedded powerpc box. The IDE stuff, serial ports and other things are treated different. And it all depends on the variant and version of your kernel. What fun. And the status of your Montavista kernel - I have no idea. Have you modified the socket driver to fit your hardware? You will not be able to use any PCMCIA card without correct configuration. Hope this leads you in the right direction. / magnus On Fri, 07 Mar 2003 08:32:47 +0100 "Gerhard TAEUBL" wrote: > > Hi again! > > Maybe I frogot some information: > > We need for a project a second 100MBit interface, so our soloution will be to > use a PCMCIA card. Does there exists an actual compatibility list which cards > works, which not? I only found a list from 2000 or 2001. > > Please help :-) > > > We are using MPC860T with one possible PCMCIA port and Montavista kernel > 2.4.2. > So it is possible to use every PCMCIA card, which is supported by Linux? > > Again, please help... > > best regards > Gerhard > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
3Com 574BT PCMCIA Card on PowerPC
Make sure that the socket driver is configured correctly for your board. Voltage control pins and stuff like that are board-specific. I would first try a PCMCIA card that is known to work easily right out of the box. Maybe the wireless board. Then you could verify the 3Com card. Scan the source-code for the 3Com card and see if it's endian-aware. / magnus On Fri, 31 Jan 2003 13:04:38 +0100 (MET) Andreas Plaickner wrote: > > Hello, > > I am new to the development of RTAI Linux on > PowerPC boards, therefore I would be very > grateful for some advice. > > I want to use the PCMCIA card 3Com > 3CCFE574BT in the pcmcia-slot on the board. On the > board is a Motorola MPC855T. > > I have seen that there exists already a solution > for a wireless LAN card. I took these steps as > a basis to try to bring to work my card. On my > board it is not possible to start the card > services with the script > /etc/rc.d/rc.pcmcia start > as there is no bash to interpret the script, there > is only a BusyBox. > > S I start the PCMCIA card services manually: > insmod pcmcia_core.o > insmod m8xx_pcmcia.o > insmod ds.o > insmod 3c574_cs.o > > When I don't insert the card in the slot and I only > start the cardmgr everything seems to be fine, > the cardmgr responds with: > > cardmgr[61]: watching 1 sockets > cardmgr[62]: starting, version is 3.2.0 > > When I insert the card, nothing happens so I have > to call the command > cardctl insert > > When I do this one I get the following error message, > and the system reboots: > > / # Oops: Kernel Mode Software FPU Emulation, sig: 8 > NIP: 0304 XER: A07F LR: C3040490 SP: C07F1810 REGS: c07f1760 TRAP: > 1000 > MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 > TASK = c07f[58] 'cardmgr' Last syscall: 54 > last math last altivec > GPR00: 0800 C07F1810 C07F 001F 0010 0002 C07F17AB > > GPR08: 000F 030E 0058 C000B2D4 95743B34 018223F8 00FF3D00 > 007FFF5D > GPR16: 0001 007FFF00 9032 007F1E80 C07F19B8 > C07F1838 > GPR24: C093D0FC C093D000 C093D08C C0941170 002B C093D1BC 0300 > C093D000 > Call backtrace: > C3040490 C304098C C3030208 C3031880 C3040244 C303C894 C303D614 > C004377C C00025BC 01802D18 01803444 01804A20 016D9DBC > > When I, after inserting the modules, dont start the cardmgr, > but write cardctl insert I can check with the commands > > cardctl status > cardctl config > cardctl ident > > and get some information that the card is in the socket. > But I think this one doesn't help as I need to start the > cardmgr to use the card. When I start the cardmgr now > I get again the above errormessage. > > What I also tried is to change the file config.opts, > setting the memory area to 0xe000-0xec00 > because when I start the board during the boot > process appears > PCMCIA slot B: phys mem e000...ec00 (size 0c00) > > When I did this one I got the following error-msg: > > /lib/modules/2.4.4-rthal5/pcmcia # cardmgr > cardmgr[61]: watching 1 sockets > cardmgr[62]: starting, version is 3.2.0 > /lib/modules/2.4.4-rthal5/pcmcia # cardctl insert > /lib/modules/2.4.4-rthal5/pcmcia # __ioremap(): phys addr 0 is RAM lr > c000b25c > Oops: kernel access of bad area, sig: 11 > NIP: CF032C34 XER: A07E LR: CF032C10 SP: C09AF8F0 REGS: c09af840 TRAP: > 0300 > MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > DAR: , DSISR: 0405 > TASK = c09ae000[62] 'cardmgr' Last syscall: 54 > last math last altivec > > > > My Kernel-Image is > > ## Booting image at 4004 ... >Image Name: Linux-2.4.4 >Created: 2002-07-17 10:40:49 UTC >Image Type: PowerPC Linux Kernel Image (gzip compressed) >Data Size:614209 Bytes = 599 kB = 0 MB >Load Address: >Entry Point: >Verifying Checksum ... OK >Uncompressing Kernel Image ... OK > > I didn't create a new kernel, but I used one that was already > pre-installed on the board. Could this one be the reason > for the above error? > > I am stuck and don't know how to continue, therefore I > would be very grateful if someone could give me some advice. > > Thanks very much in advance. > > Andreas > > -- > +++ GMX - Mail, Messaging & more http://www.gmx.net +++ > NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen! > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
embedded help for linux links
For some generic Embedded Linux PowerPC information, have a look at this HOWTO: http://penguinppc.org/embedded/howto/PowerPC-Embedded-HOWTO.html I use Miniboot as a bootloader. It only supports mpc8xx out of the box, though. http://www.opensource.se/projects/miniboot/ / magnus Jerry Van Baren wrote: > > Denx Software >http://www.denx.de/ > See especially the ELDK stuff. > > For a BootROM solution, U-boot (also maintained by Wolfgang Denks for Denx > Software) >http://sourceforge.net/projects/u-boot > > gvb > > At 06:45 PM 12/4/2002 +0530, Omanakuttan wrote: > > >Hi, > >I am a newbie in the embedded linux world, we are working to build a > >bridge (E1/T1 ethernet and E3/T3 ) with ppc8260. > >Could anybody direct me some links so that I can have a good starting > >point of linux on PPC in order to get a better idea of what is happening > >in this list and embedded linux world in general? > > > >Thanks for your time.. > >bye.. > >Om. > > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bi_record and initrd
> This would be a good opportunity to switch-over to allowing the bootloader > stick the initrd where it wants and just pass the physical pointer in via > bi_record in all cases. It would certainly simplify these cases. So, the following registers passed to the kernel could change from * r3: ptr to board info data * r4: initrd_start or if no initrd then 0 * r5: initrd_end - unused if r4 is 0 * r6: Start of command line string * r7: End of command line string to * r3: ptr to bi_record If the initrd is going to be passed with the bi_record, and the command line already is there, then it's just the board info left. (for the 8xx anyhow) Or maybe there are zillions of applications booting the kernel directly without the bootloader.. / magnus Cort Dougan wrote: > > This would be a good opportunity to switch-over to allowing the bootloader > stick the initrd where it wants and just pass the physical pointer in via > bi_record in all cases. It would certainly simplify these cases. > > } > Can you give more information about where everything is loaded up at? I > } > thought this was a non-issue, but it's been a while since I tested > } > initrds. > } > } Sure. > } The first example below does not trigger the bug. > } The second one shows the bug. > } > } First example: > } > } loaded at: 0018 0023C1D0 > } board data at: 00239124 00239140 > } relocated to: 001852FC 00185318 > } zimage at: 00185880 00214ADE > } initrd at: 00215000 002388D9 > } avail ram: 0023D000 0400 > } > } gunzip() unzips the zimage to address 0 and sets zimage_size to 0x00148A6C. > } I'm not sure about the _ALIGN() macro and how it's used, but in this case > } rec gets calculated to 0x0030. > } I thought the idea was to get a address that is aligned to the nearest > } 1-megabyte boundary. > } (2 megabyte in this case - but that would overwrite the zimage...) > } > } anyhow, the rec at 3 megabytes is inside of the available ram - good. > } > } this mail says something about typos or misuse of _ALIGN(). > } http://www.geocrawler.com/archives/3/8358/2002/9/0/9715261/ > } > } If _ALIGN() now is used correctly, then the align definition > } maybe chould be changed from > } #define _ALIGN(addr,size)(((addr)+size-1)&(~(size-1))) > } to > } #define _ALIGN(addr,size)(((addr)+(size)-1)&(~((size)-1))) > } to make sure that size is treated correctly. Or maybe it's a feature. =) > } > } Second example: > } > } loaded at: FE2226F0 FE3098C0 > } relocated to: 0018 002671D0 > } board data at: 00264124 00264140 > } relocated to: 001852E8 00185304 > } zimage at: 00185840 001CCEAB > } initrd at: 001CD000 00263A21 > } avail ram: 00268000 0400 > } > } I have not been able to output the value of zimage_size for this case, but > I'm > } sure that my initrd gets overwritten with the bi_record at 0x0020. > } We read out the initrd memory area with a BDM debugger and compared with the > } original compressed filesystem image. So rec gets set to 2 megabytes. > } This results in a initrd with bad crc. If it would help you I could get the > value > } of zimage_size, but it's on another machine and I don't have the time today. > } > } Another thing - why is the second argument (dstlen) to gunzip() always 4 > megabytes? > } Maybe it could be set to the address that the image is loaded at / > relocated to? > } (0x18 above) That way the gunzip function wouldn't overwrite the > running code, > } if I understand the dstlen argument correctly that is. > } > } I'm using a 2.4.18 kernel patched up to 2.4.19-pre9 with more patches to > match > } linuxppc_2_4 (downloaded from ppckernel.org). So if you've made any changes > } recently then I don't have them. But I compared my bi_record code with the > } latest code available via rsync and they look identical. > } > } thanks / > } > } magnus > } > } Tom Rini wrote: > } > > } > On Thu, Nov 14, 2002 at 04:54:47PM +0100, Magnus Damm wrote: > } > > } > > The bi_record setup code in linux/arch/ppc/boot/simple/misc-embedded.c > } > > doesn't care about the initrd size. So, if you are using a initrd that > } > > crosses a megabyte-boundary you will have your initrd overwritten with > } > > the bi_record. This results in crc error when unpacking the initrd. > } > > > } > > The quick fix is to add a offset to the boot-code and to > } > > arch/ppc/kernel/setup.c. > } > > > } > > So, what's the long term solution? > } > > Passing a pointer to the kernel? > } > > } > Can you give more information about where everything is loaded up at? I > } > thought this was a non-issue, but it's been a while since I tested > } > initrds. > } > > } > -- > } > Tom Rini (TR1265) > } > http://gate.crashing.org/~trini/ > } ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bi_record and initrd
> Can you give more information about where everything is loaded up at? I > thought this was a non-issue, but it's been a while since I tested > initrds. Sure. The first example below does not trigger the bug. The second one shows the bug. First example: loaded at: 0018 0023C1D0 board data at: 00239124 00239140 relocated to: 001852FC 00185318 zimage at: 00185880 00214ADE initrd at: 00215000 002388D9 avail ram: 0023D000 0400 gunzip() unzips the zimage to address 0 and sets zimage_size to 0x00148A6C. I'm not sure about the _ALIGN() macro and how it's used, but in this case rec gets calculated to 0x0030. I thought the idea was to get a address that is aligned to the nearest 1-megabyte boundary. (2 megabyte in this case - but that would overwrite the zimage...) anyhow, the rec at 3 megabytes is inside of the available ram - good. this mail says something about typos or misuse of _ALIGN(). http://www.geocrawler.com/archives/3/8358/2002/9/0/9715261/ If _ALIGN() now is used correctly, then the align definition maybe chould be changed from #define _ALIGN(addr,size)(((addr)+size-1)&(~(size-1))) to #define _ALIGN(addr,size)(((addr)+(size)-1)&(~((size)-1))) to make sure that size is treated correctly. Or maybe it's a feature. =) Second example: loaded at: FE2226F0 FE3098C0 relocated to: 0018 002671D0 board data at: 00264124 00264140 relocated to: 001852E8 00185304 zimage at: 00185840 001CCEAB initrd at: 001CD000 00263A21 avail ram: 00268000 0400 I have not been able to output the value of zimage_size for this case, but I'm sure that my initrd gets overwritten with the bi_record at 0x0020. We read out the initrd memory area with a BDM debugger and compared with the original compressed filesystem image. So rec gets set to 2 megabytes. This results in a initrd with bad crc. If it would help you I could get the value of zimage_size, but it's on another machine and I don't have the time today. Another thing - why is the second argument (dstlen) to gunzip() always 4 megabytes? Maybe it could be set to the address that the image is loaded at / relocated to? (0x18 above) That way the gunzip function wouldn't overwrite the running code, if I understand the dstlen argument correctly that is. I'm using a 2.4.18 kernel patched up to 2.4.19-pre9 with more patches to match linuxppc_2_4 (downloaded from ppckernel.org). So if you've made any changes recently then I don't have them. But I compared my bi_record code with the latest code available via rsync and they look identical. thanks / magnus Tom Rini wrote: > > On Thu, Nov 14, 2002 at 04:54:47PM +0100, Magnus Damm wrote: > > > The bi_record setup code in linux/arch/ppc/boot/simple/misc-embedded.c > > doesn't care about the initrd size. So, if you are using a initrd that > > crosses a megabyte-boundary you will have your initrd overwritten with > > the bi_record. This results in crc error when unpacking the initrd. > > > > The quick fix is to add a offset to the boot-code and to > > arch/ppc/kernel/setup.c. > > > > So, what's the long term solution? > > Passing a pointer to the kernel? > > Can you give more information about where everything is loaded up at? I > thought this was a non-issue, but it's been a while since I tested > initrds. > > -- > Tom Rini (TR1265) > http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bi_record and initrd
Hi all, The 2.4.19 kernel and the current rsync kernel from source.mvista.com::linuxppc_2_4 does not work with large initrds. The bi_record setup code in linux/arch/ppc/boot/simple/misc-embedded.c doesn't care about the initrd size. So, if you are using a initrd that crosses a megabyte-boundary you will have your initrd overwritten with the bi_record. This results in crc error when unpacking the initrd. The quick fix is to add a offset to the boot-code and to arch/ppc/kernel/setup.c. So, what's the long term solution? Passing a pointer to the kernel? / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Binary Compatibility of various flavors of PPC
> But as Matt said (and later reminded me) the 405 has errata that is 405 > specific, and the 8xx and 403 half smaller cacheline size. So anything > statically linked may not operator correctly but yes, if you switch the > whole of userspace to soft-floating point then "in general" they should all be > compatable. I don't know if gcc generates any code that tweaks with the cache, but if you only consider applications/libraries that use assembly routines to control the cache then it should be possible to convert the assembly code to assume 16-byte cachelines for all processors. That should work for processors with larger cachelines, with a performance penalty. I use a patch for glibc-2.1.3 that does exactly that. But I've only used it on 8xx-series, so correct me if I'm wrong. Btw - does someone know what the status is for recent glibc versions - do they work for 8xx out of the box? Thanks / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
loading modules
This might be related to a powerpc-specific bug in the busybox
insmod implementation. Try the 0.60.4 release or use this patch:
http://opensource.se/projects/busybox/busybox-0.60.3-insmod_rewrite.patch
/ magnus
stefania magistrali wrote:
>
> Hi all!
> I am working with a PowerPC 860T based board.
> I have a problem with loading modules: I made:
>
> make dep make clean make zImage make modules and make modules_install
>
> to create my kernel and modules , but when I try to load the module
> hdlc.o with insmod, I have a segmentation fault. I am using busybox
> version 0.60.3 and linux version 2.4.19pre6. Here I send the last part
> of the strace sequence of the command "insmod hdlc"
> Can anyone help me?
> Thanks very much in advance!
> Stefania
>
> query_module(NULL, 0, NULL, 0) = 0
> query_module(NULL, QM_MODULES, { /* 0 entries */ }, 0) = 0
> mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x30033000
> query_module(NULL, QM_SYMBOLS, 0x30032e08, 16384, 21866) = -1 ENOSPC (No
> space left on device)
> mmap(NULL, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x30037000
> query_module(NULL, QM_SYMBOLS, { /* 961 entries */ }, 961) = 0
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA cards for MPC8xx?
I've used 16550 serial ports with the m8xx_pcmcia driver. It did not work right out of the box then (2.2), I think some structure was shared between 8xx_io/uart.c and the generic 16550 serial.c. And I think serial.c poked around in some unmapped io-space. If you get a list of working cards, maybe they could be put in the embedded powerpc howto? / Magnus Matthew Locke wrote: > > Fanny Wakizaka wrote: > > >Hi, > >We are developing a custom hw based on the MPC855 with support to PCMCIA. We > >are using MontaVista linux kernel 2.4.17. > >Could you give me some suggestions of PC Cards that worked with MPC8xx? I'm > >looking for ethernet cards, modem cards and wireless cards. > >Thanks in advance, > >Fanny > > > I have used: cisco 340/350 and lucent wlan cards, 3com 3c589 lan cards, > and modems cards do not work. The problem with modem cards had > something to do with a dependancy on serial.c (8xx uses > arch/ppc/8xx_io/uart.c). I don't remember the exact problem now. > > > > > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Password on ELDK nfs booting
I've made a patch for e2fsprogs that makes it possible to use debugfs to create ext2-images from userspace. If that program is used together with fakeroot it's possible to do everything* without root access. *if everything is generating your target filesystem with correct permissions and uids/gids I think that is nice. Mail me if you want the patch. / magnus Wolfgang Denk wrote: > > In message > you wrote: > > > > > It seems you are using devfs; try running without it. I don't see > > > much advantages of devfs for embedded systems where such a > > > flexibility is usually not needed, on contrary. > > > > Well, I see at least two advantages: a) you don't need to have root > > privileges to assemble your root-filesystem, b) it's the way /dev > > should have been implemented in the first place. > > > > I admid both arguments cover rather aesthetical aspects, so your > > mileage may vary. > > The main disadvantage is the increased memory footprint which you > have to pay for a flexibility on the target which is usually not > necessary. > > Your (a) is not really an argument; there are several solutions for > this "problem", for example: > > genext2fs - ext2 filesystem generator for embedded systems > see http://packages.debian.org/unstable/admin/genext2fs.html > > gBootRoot - distribution creation program which may be used by a > normal user > see http://gbootroot.sourceforge.net/ > > (b) is a matter of taste; for embedded systems, I tend to prefer a > fixed, static configuration which does not cost too much of the > resources which may be somewhat limited (espacially ROM and RAM). > > Yes, MMV ;-) > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de > By the way, ALL software projects are done by iterative prototyping. > Some companies call their prototypes "releases", that's all. > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA on an MPC860
I've not used the driver together with a 2.4 kernel,
so I'm not sure how well modules from pcmcia-cs plays
with pcmcia stuff in the kernel.
Linux-2.4.19 has a version of the driver that
Matthew Locke modified and bugfixed. Maybe that one
works better with 2.4 kernels.
What happens if you decode the OOPS?
To get symbols, use the file System.map from
the kernel together with the map generated by
"insmod -m".
Or use /proc/ksysms from the running system.
"cardctl ident" and "cardctl status" only reads
the CIS and checks the pin status. (Correct me
if I remember wrong).
I think it will be the ide-driver that starts
accessing the IO-space. Maybe that doesn't work.
/ Magnus
Alex Zeffertt wrote:
>
> All,
>
> Has anybody had any luck getting PCMCIA to work on an MPC860?
>
> I have a custom MPC860 board, with a single PCMCIA socket connected to Slot
> B. This is what I have
> so far done:
>
> 1.
> Downloaded pcmcia-cs-3.2.0.tar.gz
> 2.
> Added board specific definitions in modules/m8xx_pcmcia.c for
> hardware_enable()
> hardware_disable()
> voltage_set()
> socket_get()
> 3.
> Cross compiled for the 8xx.
> 4.
> In my kernel (linux-2.4.4-2001-11-24 from Denx) I added the following lines
> include/asm-ppc/.h:
> /* define IO_BASE for pcmcia */
> #define _IO_BASE 0x8000
> #define _IO_BASE_SIZE (1024*64)
> arch/ppc/mm/init.c:
> void __init MMU_init(void) {
> ...
> ioremap(_IO_BASE,_IO_BASE_SIZE);
>
> ...as suggested by Magnus Damm in
> http://lists.linuxppc.org/linuxppc-embedded/25/msg00227.html
>
> HOWEVER,
>
> 5. When I boot my board with a Flash card in the PCMCIA slot, and I run:
> /etc/rc.d/rc.pcmcia start
> I find that ide_cs.o causes an Oops when it calls ide_register().
> "cardctl status"
> and "cardctl ident" work though.
>
> Can anybody suggest what I'm doing wrong?
>
> Thanks in advance,
>
> Alex
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cygwin and embedded linux
> How many out there actually are compiling PPC code natively > on a PowerPC Linux box for their embedded devices? Not me. I cross compile all my distributions from x86 hosts. I like the idea of separating the target system from the host system. To keep track of used libraries and to be able to recreate the same distribution in the future with another host. I've always wanted a sleek laptop from apple, but I would like more than one mouse button... / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cygwin and embedded linux
> Are there others in this situation and how have they chosen to solve it? Vmware could be one way to solve it. Good if you want to develop and test device drivers. Or use separate Linux boxes and use a X server to connect to them. There are commercial X servers for Windows like X-Win32 and it should also be possible to use Xfree86 on Windows for free. Both work great. That way you can stay on Windows for a while, use the X-Server to access the Linux box (and other boxes that supports X), and then maybe later switch to a Linux-only solution. Another way to solve it would be to switch to Linux and use VNC to connect to your Windows boxes. I'm not sure how well this works out, though. / magnus > John Fisher wrote: > > > Actually, my personal opinion on that matter is that I'm not very fond > > of using Windows for a Linux kernel development platform. Doing -- > > So what are the issues: How is cygwin significantly different from Linux > that you would not want to use it? > Are there useful tools that run under Linux but not under cygwin? > > The reason I ask is that my organization currently does its software > development under windows using proprietary tools. We have to maintain our > existing products using these tools. We are however contemplating new > development using linux. If we have to dual boot our PCs or have an extra PC > running Linux for each developer, that is going to bring its own set of > nuisances and problems. > > Are there others in this situation and how have they chosen to solve it? > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cygwin and embedded linux
> Is anyone seriously trying to do embedded Linux development for power PC > using Cygwin as the host? I've designed a build-system for a customer, and I tried (just to see how much that worked ok) to build under Cygwin. Everything worked out ok until the system cross compiled glibc-2.1.3. Building glibc generated a error message that meant something like you-have-bad-memory-on-your-system. I tried to find the source of the problem with rebuilding and running memtest86. But no success. But this was maybe a year ago. The same system works great on Linux boxes. That's my only experience. But I have a box from Lynuxworks somewhere here (someone gave it to me) and that box says that the build system is hosted on windows... / Magnus John Fisher wrote: > > Is anyone seriously trying to do embedded Linux development for power PC > using Cygwin as the host? > > I'm trying to get linux running on proprietary MPC850/860/8260 boards. I'll > start with either the 850 or the 860 board as I'm more familiar with these > processors than with the 8260. > > I have the Macraigor blackbird BDM interface for the MPC850/860. I have both > an Agilent ethernet based probe and the Wind River Vision Probe II for the > 8260. > > All boards will be running with plenty of flash and RAM: 16MB and 32MB > respectively for both the 850 and 860 boards. They will be running with no > disk drive, no monitor and a serial port on SCC3. > > I may have real time requirements, but this is yet to be determined. > > This is a learning exercise at this stage. > > John Fisher > NEC Australia Pty Ltd > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
can I find the patch files for mpc860T
Search the list!
http://lists.linuxppc.org/
See this answer for more information:
http://lists.linuxppc.org/linuxppc-embedded/200103/msg00026.html
/ Magnus
?? wrote:
>
> hello !
>
> I have some problems, when I compile with bash-2.05a for Powerpc (mpc860).
> I download the sources from LFS stie , but it is not support for MPC860T
> when I build the sources, it was occur some errors with following error
> message
>
> can you help me what's problem and I can find the patch files for mpc860T
>
> error MESAGE =
>
> [root at CBLinux bash-2.05a]# CC=powerpc-linux-gcc AR=powerpc-linux-ar
> RANLIB=powerpc-linux-ranlib ./configure --host=powerpc-linux
> --build=i686-pc-linux-gnu
>
> checking build system type... i686-pc-linux-gnu
> checking host system type... powerpc-unknown-linux-gnu
> Beginning configuration for bash-2.05a for powerpc-unknown-linux-gnu
> checking for powerpc-linux-gcc... powerpc-linux-gcc
> checking whether powerpc-linux-gcc needs -traditional... no
> checking for a BSD compatible install... /usr/bin/install -c
> checking for ar... powerpc-linux-ar
> checking for powerpc-linux-ranlib... powerpc-linux-ranlib
> checking for bison... bison -y
> checking whether make sets ${MAKE}... yes
> checking for powerpc-linux-gcc option to accept ANSI C... none needed
> checking for an ANSI C-conforming const... yes
> checking for inline... inline
> checking whether byte ordering is bigendian... yes
> checking for preprocessor stringizing operator... yes
> checking for long double... yes
> checking for function prototypes... yes
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking whether char is unsigned... yes
> checking for dirent.h that defines DIR... yes
> checking for opendir in -ldir... no
> checking whether time.h and sys/time.h may both be included... yes
> checking for inttypes.h... (cached) yes
> checking for unistd.h... (cached) yes
> checking for stdlib.h... (cached) yes
> checking for stdarg.h... yes
> checking for varargs.h... yes
> checking for limits.h... yes
> checking for string.h... (cached) yes
> checking for memory.h... (cached) yes
> checking for locale.h... yes
> checking for termcap.h... yes
> checking for termio.h... yes
> checking for termios.h... yes
> checking for dlfcn.h... yes
> checking for stddef.h... yes
> checking for stdint.h... (cached) yes
> checking for netdb.h... yes
> checking for grp.h... yes
> checking for strings.h... (cached) yes
> checking for sys/ptem.h... no
> checking for sys/pte.h... no
> checking for sys/stream.h... no
> checking for sys/select.h... yes
> checking for sys/file.h... yes
> checking for sys/resource.h... yes
> checking for sys/param.h... yes
> checking for sys/socket.h... yes
> checking for sys/time.h... yes
> checking for sys/times.h... yes
> checking for sys/wait.h... yes
> checking for netinet/in.h... yes
> checking for arpa/inet.h... yes
> checking for working alloca.h... yes
> checking for alloca... yes
> checking whether getpgrp takes no argument... yes
> checking whether setvbuf arguments are reversed... configure: error: cannot
> run test program while cross compiling
> ===
>
> This version is not support for powerpc architecture??
> if you have a some solutions, please help me !
> Do you know where I can get some patchs???
>
> thanks for reading and have a good day!
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Strange writings at 0x0
I think the file arch/ppc/kernel/head_8xx.S saves stuff on address 0 in the tlb handler. (line 361 on 2002-03-21) / magnus Jakob Jepsen wrote: > > Hi > > When tracking a bug in our own code we stumbled over some strange > writings to addr 0x0. > > The pattern : > > : 55 00 30 55 01 30 5e 80 00 00 00 00 00 00 00 00 > > are written continuously to memory. > > The writings have in them self no effect, but must be considered a bad > sign. > > We are running on a MPC857T rev. A BETA running at 50 MHZ. > Linux version 2.4.4 from Denx > > Have anybody seen something like this or have anybody an idea to where > the data are > coming from. (The CPM is a sure guess, but what are generating it ?) > > Thanks. > > Jakob > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
FEC CONFIG_FEC_PACKETHOOK option?
Throw it away, please! It was a hack done by people on my department when I was working on Ericsson here in Sweden. We used it to capture packets and forward them to a closed-source module where further processing was made. The option should have been removed a long time ago. I'm pretty confused about all sources and everything, if someone would point me to what sources are affected, then I will make some patches. Thanks / magnus Michael Fischer wrote: > > Hello, > just looked into the 8xx fec.c sources of 2.4.18 tree and discovered there > is a CONFIG_FEC_PACKETHOOK option. Couldnt find any further information > about it, not even the included linux/pkthook.h file. Has anyone more > information what this is for? Is this outdated, not finished yet...? > > Thanks for any information, > Best regrads, Michael > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Does anyone port m8xx_pcmcia driver to Linux Kernel successfully?
Hi folks, The patch file you are referring to, is that the same patch as I released in the mail below? http://lists.linuxppc.org/linuxppc-embedded/22/msg00093.html If that is the case I think you should try pcmcia-cs-3.1.10 instead of 2.1.10. Or was that a typo? / Magnus Jacky Wang wrote: > > Conn, > > I found while use Linux 2.2.13 + pcmcia-cs 2.1.10 + patch file (w/o any > modification), I couldn't re-compile pcmcia-cs successfully. > They are what I work with: > Debian OS w/ 2.2.18pre21 kernel > powerpc-linux-gcc 2.95.2 > powerpc-linux-as 2.9.5 > > Would you give me your advise? Or.. it's a problem about configurations of > Makefile? > > Jacky > -Original Message- > From: Jacky Wang [mailto:jacky at premierme.com.tw] > Sent: Thursday, April 18, 2002 9:31 AM > To: Conn Clark > Cc: May Ling List > Subject: RE: Does anyone port m8xx_pcmcia driver to Linux Kernel successfully? > > Conn, > > while I enter the ftp site of MontaVista, I couldn't see anything on the site. > If it is the patch file that Magnus loaded in the webpage? > > Jacky > > -Original Message- > From: root at esteem.com [mailto:root at esteem.com]On Behalf Of Conn Clark > Sent: Thursday, April 18, 2002 1:12 AM > To: Jacky Wang > Cc: May Ling List > Subject: Re: Does anyone port m8xx_pcmcia driver to Linux Kernel successfully? > > Jacky Wang wrote: > > > > Conn, > > > > hmm.. > > sounds good. > > > > but, I am a newbie about programming with linux kernel and MPC850. > > Could you tell me which kernel release and how to port it smoothly? > > We are using kernel 2.2.13 and pcmcia card services 3.1.10 . > Unfortunately our hardware is proprietary and doesn't have a full pcmcia > interface. I had to comment out all the voltage detect and such. Other > than that I just followed the instructions that came with the mpc8xx > patch file. The patch used to be availible from montavista's ftp site > but > isn't any more. > > here is some help full notes. > > http://lists.linuxppc.org/linuxppc-embedded/25/msg00227.html > > Conn > > -- > > * > If you live at home long enough, your parents will move out. > * > > Conn Clark > Engineering Stooge clark at esteem.com > Electronic Systems Technology Inc. www.esteem.com > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Accessing BCSR's
Hi, If you have memory-mapped io (The (F)ADS8xx BCSR registers is a good example) which is mapped to a certain physical address, it is very simple to access it if the MMU is turned off. The Linux kernel runs with the MMU on, and it needs a virtual-to-physical address mapping to be able to access memory-mapped io. So, my 2.2-kernel has a file called arch/ppc/mm/init.c. Inside that file there's a function called "ioremap()" - that is what you are looking for. Make sure that your Linux kernel has a virtual page for your io-area, and access the virtual address that is returned by "ioremap()". If you use "ioremap()" before a certain moment when the Linux kernel starts up, you will get a 1:1 mapping between virtual and physical addresses. (This is true for 2.2 anyhow) Look how the internal io block is ioremap():ped for a good example how it is done. Cheers / magnus Jeremy Rosen wrote: > > Hello everybody, > > I have 860T FADS board, and I am trying to access the (board specific) > registers BCSRs. > > I have no problem accessing them in PPCBOOT, since they are accessed > through CS1, at address FF01, but I can't access them in linux for > the moment. > My first attempt was by using the /dev/mem device, but it doesn't seem > to work, the result read are not correct. > so I have to question > 1) why doesn't it work, I probably don't understand how /dev/mem works > : does it map only memory and not the address space ? do I have to > register the address range or the BCSR in the kernel ? > 2) what is the proper way of doing this ? writing a driver ? or using > /dev/mem properly ? > > thx for your help... > > Jeremy > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Development tools version
FYI, strip in binutils-2.11.2 has problems... Not very important maybe, but annoying. http://sources.redhat.com/ml/bug-binutils/2001-q3/msg00108.html / magnus Neil Horman wrote: > > Yes, binutils 2.11.2. Sorry about my fat fingers... :) > SaySpeaking of those memory faults. I never got around to > researching > them. Can you or anyone else provide general notes on exactly what those > patches fix? I'd certainly appreciate it, as I always wanted to track those > down, but never quite found the time. Thanks! > > Laurent Pinchart wrote: > > > > > > > > > > >I think that the Hard Hat tools will probably be the easiest for you to > > >get up > > >and running with. They have probably been the most throughly debugged for > > >the > > >8xx. Although if your looking to put together your own tools for the 860 > > >series, we here have built the following, with a reasonably good deal of > > >success. See the notes for details: > > > > > >Binutils: > > > 2.1.2 - no problems at all. Download and build them for > > > powerpc-linux and away > > >you go > > > > > >GCC: > > > 2.95.3 - again no real problems. > > > > > >GLIBC: > > > 2.2.4 - relatively easy. Some issues with memory faults on > > > occasion, which I > > >have not yet traked down. > > > > > >GDB: > > > 5.1.1 - no problems > > > > > >General notes: > > > I've personally been following the embedded cross-gcc mini howto > > > available on > > >penguinppc.com and I've been more or less happy with the results. hope > > >that > > >helps! > > > > > Thanks Neil. > > > > I've been able to succesfully use the Hard Hat binaries (actually that's > > so simple that I wouldn't have dared asking questions in this mailing > > list if I hadn't :-), but I'd like to recompile from the sources, in > > order not to depend on a binary release, and also to be able to modify > > the tools if needed. > > > > I tried to compile the tools from the sources without patching them a > > few months ago, and experienced memory faults and a lot of other > > problems with dynamically linked executables (is that a known issue ?). > > > > Recompiling from the SRPMS shouldn't be a hard job, so that's what I'll > > try. All the patches are supposed to be included in there... > > > > Just to make sure, did you mean binutils 2.11.2 ? > > > > Laurent Pinchart > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
monitor in mpc860fads
> If you intend to run Linux on your fads, I recommend you using ppcboot as > bootloader. A more minimalistic approach would be Miniboot. =) http://opensource.se/projects/miniboot The FADS board is supported right out of the box. Just make sure you use the right crystal. You could then boot PPCBoot from Miniboot if you want network support, etc. / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Kernel 2.4.4
> My next step is to find a simple bootloader.. Try Miniboot! It is almost as simple as a bootloader can be. http://opensource.se/projects/ Miniboot now supports 4 different boards, all with mpc8xx processors. A new version will be released soon... And, you may want to boot PPCBoot from Miniboot. This will make it possible to update PPCBoot without any BDM. Cheers / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Solutions for Fast Software Upgrade in Linux/PPC
I recommend a combination of a simple bootloader and a reboot-linux-in-linux piece of software. You can find miniboot - a safe and simple bootloader at http://opensource.se/projects/ With a clever-designed upgrade application it's possible to update the flash in a fail-safe way. One neat feature is that miniboot runs without any external RAM, which makes it possible to keep the RAM-code in a upgradeable image. I also have a driver, relf, (Reboot ELF) that makes it possible to reboot an ELF directly from Linux. It has booted Linux, vxWorks and pSOS. mpc8xx only. If you're intrested - give me a mail and I will send it to you. Good luck / Magnus Josh Huber wrote: > > Grant Erickson writes: > > [snip] > > I'd also recommend the fast-reboot option, but since no one mentioned > yet I'll suggest Werner Almsberger's bootimg utility. > > Take a look at: > ftp://icaftp.epfl.ch/pub/people/almesber/misc/> > > specifically, bootimg-current.tar.gz > > Also, in ../booting/ there is a paper describing the > method. (bootinglinux-current.ps.gz) > > I've tested this many times (we use it at Mission Critical for our > kernel crash dump system), and if you're looking for fast reboots this > is the way to go. > > Unfortunately, it doesn't solve the upgrading of the ROM issue. > > For the lazy who don't want to look at the references, what this > allows you to do is boot a linux kernel, using an already loaded Linux > kernel. > > ttyl, > -- > Josh Huber > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Cross-compiling standard utilities for MPC823
If you're cross-compiling applications that use autoconf "configure"
scripts, you will need to set some variables to override tests that
configure is unable to perform when you're cross-compiling.
Here are some mpc8xx-specific variables:
ac_cv_c_cross=yes
ac_cv_c_bigendian=yes
ac_cv_c_char_unsigned=no
ac_cv_sizeof_long_long=8
ac_cv_sizeof_long=4
ac_cv_sizeof_int=4
ac_cv_sizeof_short=2
ac_cv_sizeof_unsigned_long=4
ac_cv_sizeof_unsigned_int=4
..and some other ones if you use glibc-2.1.3:
ac_cv_header_stdc=yes
ac_cv_func_closedir_void=no
ac_cv_func_setvbuf_reversed=no
ac_cv_func_getpgrp_void=yes
ac_cv_func_setpgrp_void=yes
ac_cv_func_mmap=yes
ac_cv_func_setpgrp_void=yes
ac_cv_func_strcoll_works=yes
ac_cv_func_vfork=yes
ac_cv_func_wait3_rusage=yes
ac_cv_sys_restartable_syscalls=yes
The variables above will make it possible to cross-compile
fileutils-4.1. Other packages (bash, readline) might need
more variables, but if you read the configure-file, you
will figure out what is missing.
Or, you can take the blue pill and go the RPM-way ... ;)
Cheers /
magnus
opensource.se - custom linux distributions
Cindy Peters wrote:
>
> I am attempting to cross-compile the file utilities that I downloaded from
> the linuxppc ftp site for the MPC823 on an x86 PC running Redhat 6.2. I am
> getting an error when configure is trying to determine the byte ordering.
> Following is a clip from the config.log file.
>
> configure:2220: checking whether byte ordering is bigendian
> configure:2242: powerpc-linux-gcc -c -g -O2 conftest.c >&5
> configure: In function `main':
> configure:2236: `bogus' undeclared (first use in this function)
> configure:2236: (Each undeclared identifier is reported only once
> configure:2236: for each function it appears in.)
> configure:2236: parse error before `endian'
> configure: failed program was:
> #line 2228 "configure"
> #include "confdefs.h"
> #include
> #include
>
> int
> main ()
> {
> #if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN
> bogus endian macros
> #endif
>
> ;
> return 0;
> }
>
> I have tried defining BIG_ENDIAN and BYTE_ORDERING but that is not helping.
> Can someone tell me what I need to do to successfully cross-compile this?
> Here is the command line I am using.
>
> AR=powerpc-linux-ar AS=powerpc-linux-as LD=powerpc-linux-ld \
> RANLIB=powerpc-linux-ranlib CC=powerpc-linux-gcc NM=powerpc-linux-nm \
> ./configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu \
> --target=powerpc-unknown-linux-gnu \
> --prefix=/opt/usr/local/powerpc-linux
>
> Thanks,
>
> Cindy Peters
> Adaptive Micro-Ware, Inc.
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8xxFADS support
Michael Habermann wrote: > > I intend to use the MPC8xxFADS board with an 855T. I've read in this > newsgroup several times that the FADS are causing problems. > Which kind of problems do I have to expect? Is PCMCIA supported reliable? Don't get me started. I had some problems with the ZIF socket on my FADS860T. And the MACH chips might have some bugs which makes PCMCIA/FLASH accesses wierd if not done the right way. I think that the PCMCIA accesses was trashed in some way if the previous access was made to the flash... But that is usually no problem if you run Linux from memory. Only some versions of the 860T chip seemed to work with my FADS860T, even if all my 860:s (T:s and non-T:s) acted normal with my ADS860 board The socket driver for the pcmcia-cs package should support FADS860T. I don't know how the 855T is connected to the PCMCIA socket on the FADS, you might need to modify the socket driver... Cheers / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Journaling Filesystem?
Well, Tom, I disagree with you. I don't know much about Linux/PPC for desktop machines, but Linux as an embedded OS for embedded processors such as the mpc8xx series is very stable. If you do it the right way. / Magnus Zehetbauer Thomas wrote: > > PPC itself seems to be very beta, so why do you care about a beta > quality filesystem?!? > > Tom > > > -Original Message- > > From: Thomas Lange [mailto:thomas at corelatus.com] > > Sent: Tuesday, April 10, 2001 12:21 AM > > To: linuxppc-embedded at lists.linuxppc.org > > Subject: Re: Journaling Filesystem? > > > > > > > > I was just about to ask the same question. > > I need a journalling fs for our ppc ( 8xx ) system. > > All I have found so far seems to be very beta. > > > > /Thomas Lange/ > > > > "Sacha J. Bernstein" wrote: > > > > > > Is there a working journaling filesystem that works with > > PPC linux? What > > > does everyone alse to do handle the embedded devices that > > people may just > > > walk up and unplug? I use ReiserFS on x86, but I've heard > > that it may not > > > work with PPC. I haven't tried to check myself... > > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA-ATA DMA and Minix/FATxx
> Minix is told to be simple but where is it documented? I think that the Minix filesystem doesn't specify what endian to store the data. Storing files on a PC and reading them on your PowerPC target might be hard... / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
runtime check of cacheline size.
Hi all, Wouldn't it be nice with a glibc that works for all of us? Idea: Let's run-time check the cacheline-size of our cpu! How? First we need to make sure that the maximum cacheline size of any PowerPC cpu is 128 bytes. (CACHELINE_MAX) If it's anything else then it's easy to add that to the code. Then if we should use the dcbz instruction we need at least CACHELINE_MAX bytes aligned to a CACHELINE_MAX address. (buf) Then we write: address: data (32bit) buf+16 16 buf+32 32 buf+64 64 Then we use the "dcbz" instruction on buf. then we add together all data we've written above (sum): 32 bit data on address: buf+64 buf+32 buf+16 then: cachelinesize = 128-sum Easy, right? I tried to implement it using assembler: cut here cachelinesize_detect: #define CACHELINE_MAX 128 /* use dcbz to figure out the size of a cacheline * on our system... * needs a CACHELINE_MAX bytes buffer in r3. * r3 should be aligned to CACHELINE_MAX too. */ li r4, 0x10/* 16 bytes: mpc8xx, ibm4xx */ stwxr4, r4, r3 li r4, 0x20/* 32 bytes */ stwxr4, r4, r3 li r4, 0x40/* 64 bytes */ stwxr4, r4, r3 dcbz0, r3 add r5, r4, r4 /* 128 bytes */ lwzxr4, r4, r3 sub r5, r5, r4 lwz r4, 0x20(r3) sub r5, r5, r4 lwz r4, 0x10(r3) sub r5, r5, r4 /* now: r5 contains cacheline size */ cut here The code is untested and I've probably use the "sub" instruction the wrong way. You get the idea anyhow. Who wants to adopt the idea for memset.S? I don't really have time, sorry... Cheers / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MII PHY support?
Dan Malek wrote: > Maybe we should just move this into a separate source file instead of > making a big configuration mess of the FCC Ethernet driver. I'm about > to do that for some 8xx FEC functions as well. the MII stuff is shared between many other drivers in the Linux kernel. I've seen PCMCIA hardware that bitbangs some port to play around with the PHY registers. So, some generic bitbanging code with callbacks for the bitsetting would be nice for them. Have a look at the mii-tool program from the net-tools package! Cheers / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
glibc-2.2.2
Hi all, Anyone tried glibc-2.2.2? It cross-compiles cleanly, but acts wierd on my mpc8xx target. I've browsed through my old 2.1.3 patches for the cacheline- size and I'm not sure if everything is ok with 2.2.2... / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kernel support of MPC8XX series
> For us, the majority of devices are memory cards like SanDisk, > CompactFlash or IDE harddisk adapters. On one side, the PCMCIA > package is a lot of overkill here; on the other side it cannot be > used when you want to boot from such a device. Not really true. It _is_ possible to boot with the PCMCIA package, it's just a bit harder. Use an initrd with a scaled-down PCMCIA package to solve it. But I suggest you try the in-kernel support as a first step. / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Cross compiling bash
> How does one cross-compile bash? I have successfully cross-compiled many applications on my x86 host. First you need a cross-compiled libc. Then you need to tell "configure" some things to make it use your compiler/libc. You also might need to pass other configuration values that are impossible to autodetect if crossc-ompiling. I use a wrapper around configure to pass some values to it. Here are some values from my wrapper, some might not be needed for bash, but maybe for other packages.. some bash specific variables: export bash_cv_func_sigsetjmp=present export bash_cv_job_control_missing=present export bash_cv_sys_named_pipes=present export bash_cv_sys_siglist=yes export bash_cv_ulimit_maxfds=yes export bash_cv_under_sys_siglist=yes export bash_cv_type_rlimit=long and some powerpc specific stuff: export ac_cv_c_bigendian=yes export ac_cv_c_char_unsigned=no export ac_cv_sizeof_long_long=8 export ac_cv_sizeof_long=4 export ac_cv_sizeof_int=4 export ac_cv_sizeof_short=2 export ac_cv_sizeof_unsigned_long=4 export ac_cv_sizeof_unsigned_int=4 I also export the following variables from my wrapper: They pretty much depend on what you compile for and where your compiler is, you'll have to figure out them yourself. export CC CXX CFLAGS CPP LDFLAGS AR RANLIB HOSTCC HOST_CC BUILD_CC I have a patch for bash-2.04 that makes it possible to crosscompile. But it is too big to be sent to this public list. Ask nice and I will send it to you.. =) Cheers / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linuxppc-embedded: mpc8260 bus frequency calculations
> > One solution is to have the > > board_info fields in units of Hz instead of MHz. > > I know. It's one of my patches to add real soon now :-). I think that would be nice for the mpc8xx boards too. / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Runtime libs
> Now I'm looking for a runtime lib. I've tried compiling both stock > glibc-2.2.1 > and dietlibc, and failed miserably. What is the favored runtime lib now > for > a 823 target? I've used glibc-2.1.3 with some patches for my mpc8xx projects. You will need a patch for the cacheline size, (search this list) and a patch to fix a typo affecting little-endian in C-ctype.c. I cross-compile it on a x86-box and it works like a dream. =) A good thing to do is to download tarballs+diffs/SRPMS from debian/redhat and check out their patches. Hope this helps / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bk-linuxppc_2_4 mpc8xx compile fix
Hi all, I recently tried to compile a fresh bitkeeper linuxppc_2_4 tree for mpc8xx: arch/ppc/kernel/kernel.o: In function `SoftwareEmulation': arch/ppc/kernel/kernel.o(.text+0xa04): undefined reference to `Soft_emulate_8xx' arch/ppc/kernel/kernel.o(.text+0xa04): relocation truncated to fit: R_PPC_REL24 Soft_emulate_8xx make: *** [vmlinux] Error 1 The relevant .config line: # CONFIG_MATH_EMULATION is not set I will probably not get the nobelprize for the fix, but is works for me... =) Cheers / Magnus diff -urN linux-2.4.1/arch/ppc/kernel/Makefile linux-2.4.1-cllf_ok/arch/ppc/kern el/Makefile --- linux-2.4.1/arch/ppc/kernel/MakefileTue Jan 23 00:41:15 2001 +++ linux-2.4.1-cllf_ok/arch/ppc/kernel/MakefileWed Feb 7 11:32:08 2001 @@ -56,7 +56,13 @@ else obj-$(CONFIG_PPC) += hashtable.o endif -obj-$(CONFIG_MATH_EMULATION) += softemu8xx.o + +ifeq ($(CONFIG_8xx),y) +ifneq ($(CONFIG_MATH_EMULATION),y) +obj-$(CONFIG_8xx) += softemu8xx.o +endif +endif + obj-$(CONFIG_MBX) += i8259.o obj-$(CONFIG_APUS) += apus_setup.o obj-$(CONFIG_ALL_PPC) += pmac_pic.o pmac_setup.o pmac_time.o prom.o \ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA trouble
Hi all, I've recently received some mail concerning my m8xx PCMCIA socket driver. So, I thought of sorting some things out here: Start by reading "Linux PCMCIA Programmer's Guide": http://pcmcia.sourceforge.org/ftp/doc/PCMCIA-PROG.html I will now try to make things a bit clearer: Please correct me when I'm wrong. -- I/O space -- If you have some kind of register in external hardware and wants your CPU to access it in some way, you can choose from two methods: Address space mapped I/O or I/O space mapped I/O. Address space mapped I/O: Your external hardware compares all accesses on the bus with it's own address (or triggers on a CS) and if the address matches it will perform a read or write. The access will be performed via a standard memory access. I/O space mapped I/O: The external hardware will check if a special pin on the bus tells that the access is a I/O access and also check the address, and the perform the operation if it matches. The registeraccess will be done through some special instruction. Motorola has a history of Address mapped I/O. A clean and simple way. Intel and clones (and the zilog Z80) has always used the I/O space. Maybe it was bacause they didn't want to waste the 1MByte address space with I/O or maybe it was just for compability with the 8080. Who knows. The I/O space used on a PC has 64K addresses and each access takes 1us. (?) Linux has special macros for I/O space operations. inb() - outb(), insb() - outsb(), 8 bit access. inw() - outw(), insw() - outsw(), 16 bit access. inl() - outl(), insl() - outsl(), 32 bit access. ins() and outs() are string operations and will read a string. in() and out() are single access macros. Check include/asm-ppc/io.h for more info. On the PC these macros will be translated into special instructions (in / out). These macros in Linux on the PowerPC will translate all I/O space operations into standard memory accesses that starts at _IO_BASE. 64KByte should be ioremapped phys=virt at _IO_BASE. I think the only way to do that is to do in in arch/ppc/mm/init.c, but I would be glad to put it in m8xx_pcmcia.c if someone knows how. Please note that even if 64KByte space at _IO_BASE is ioremapped it doesn't mean that any access to that area is valid. The generic PCMCIA code will tell me to open up a gap that is valid at say I/O space address 0x1f0 that is 8 bytes long. Only the addresses at _IO_BASE+0x1f0 -> _IO_BASE+0x1f7 will be valid. The 8250/16550 driver (serial.c) probes at init-time which will cause problems. -- Endian -- The m8xx series of PowerPC processors are all big endian. All I/O space accesses to done by any PCMCIA device driver should be done with little endian accesses. So, swapping should be performed. include/asm-ppc/io.h: All in() / out() are translated into in_le() / out_le(), ie they are swapped. arch/ppc/kernel/m8xx_setup.c: m8xx_ide_insw() / m8xx_ide_outsw() will call ide_insw() / ide_outsw() arch/ppc/kernel/misc.S: ide_insw() / ide_outsw() will do the same as _insw_ns() / _outsw_ns(), ie no swap. So, all accesses except the ide are swapped. Don't ask me why. -- Memory Windows -- Usually the PCMCIA code tells the socket driver that is should map in a memory window at a certain address in the address space. This works fine if the PCMCIA socket hardware (usually a ISA or PCI card) has offset register for their windows. All (I think) PC hardware has that. The m8xx series of processors does not have any offset register. David Hinds and me made some kind of interface change to support this hardware. So now the generic code asks me for an address where the window that has a certain offset is. Get it? Probably no. Anyhow what is important is that lots of physical address space is needed. Read more about it in m8xx_pcmcia.c. -- IRQ -- There are two kinds of IRQs - IRQs for my socket driver and IRQs for the PCMCIA-card driver. My socket driver's IRQ handles stuff like insertion and removal. The socket driver also tells the generic code what interrupt it should use for the PCMCIA-card driver. -- Vcc and Vpp -- The voltage setting routines are very board specific. Please double-check with your manual. Don't blame me if your board will be fried. The generic PCMCIA code will tell me what voltage to set. I have nothing to do with it except doing what he says. Some of my voltage-detection code should be rewritten, I thought that I was supposed to report all values to the generic code, but I should tell it the lowest possible value. And that is board specific too. -- Timing -- The socket driver tries to figure out how many waitstates each windows should have depending on the MHz value of the CPU and the nano second setting from the generic PCMCIA code. If the driver gets wrong MHz value for some reason stuff will not work. Double check that too. You might run into trouble if you have your BMT enabled (check SYPCR). -- Final words -- I've successfully used several differnet ATA cards and the xirc2ps.c drive
SCC1 Serial on 855T
Hi All, The SCC support is pretty limited in uart.c... So - no modem control, and receive works pretty bad. To get modem control to work as good as in serial.c you will need to hook interrupts on the status pins and do much more. I am working on a new serial driver with support for modem control on SCCs. It's not finished yet, I'm busy with some other things right now. I've been able to control a modem with modem control at 115200 bps with SCC2. I suggest you wait a while... Cheers / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems with serial ports
Dan Malek wrote: > > Kim J?rgensen wrote: > > > Is the new driver available? > > No. It's kind of low on the list of other problems to solve at > the moment. I am working on a new serial driver with support for SCCs with modem control. Have a nice weekend / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xxROM with MPC860ADS - ATA Flash Card not recognized?
Eisenzopf Thomas wrote: > > Hallo, > > does anyone know this problem: > > Using 8xxROM on a MPC860ADS board does not recognize my ATA flash card in > the PCMCIA slot (SanDisk compact flash with PCMCIA adapter). In the > beginning of the bootloader startup I get the message "pcmcia: no card > present". Parts of my "config.h" (I tried with and without PCMCIABUG): I think Raphael Bossek made some FADS823 changes to this code. The 823 use pcmcia port B and the (F)ADS860 use port A. Check the init code for the pcmcia controller, it is hardcoded to port B right now... And.. ..you need to use PCMCIABUG with your ADS. Cheers / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA driver for the m8xx series!
Hello all, I've written a PCMCIA socket driver for the m8xx family. The driver is written to support one or two sockets, but when compiled for two sockets the resources are limited. See modules/m8xx_pcmcia.c for more info. You also need to modify your kernel and I don't have a patch for it. I will tell you more below. I hope you find it useful, feedback is welcome! Cheers / Magnus - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The driver needs the pcmcia-cs package written by David Hinds. More information about the pcmcia-cs package can be found at: http://pcmcia.sourceforge.org/ This patch should be applied to pcmcia-cs-3.1.10: ftp://sourceforge.org/pcmcia/pcmcia-cs-3.1.10.tar.gz - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The following hardware is supported: Board Cpu SlotStatus RPX CLLF 860DTB OK RPX LITE 823 B OK RPX LITE 850 B OK ADS860 A OK ADS821 A untested FADS860T 860T A OK FADSxxx?A or B untested Some boards with the BMT (Bus monitor timer) enabled might get in trouble with PCMCIA cards that are too slow. The solution is to disable the BMT in SYPCR. Please double-check with your manual that my board-specific code that controls the power to the PCMCIA cards is correct. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Supported and tested PCMCIA cards: ATA-Flash: CompactFlash cards from SanDisk, Mitsubishi and Viking. [ide_cs.o] PCMCIA card from Feiya. Modems:V.34 CreditCard modem from Ericsson. [serial_cs.o] The modem part of a Xircom RealPort REM56G-100 works only on boards with BMT disabled. Ethernet: Xircom CE2-10. [xirc2ps_cs.o] Xircom RealPort REM56G-100 works without BMT. Non-supported and tested PCMCIA cards: Ethernet: 3Com Megahertz 3CCFEM556B Ethernet/Modem. [3c574_cs.o] I tried but I only get 0xff from it.. Non-tested PCMCIA cards: The rest: Please tell me if you have any success! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Kernel modification: This is not included in the patch! 1. First of all you need to ioremap 64KByte at _IO_BASE. This is for the emulated ISA-bus. VIRT must be PHYS and I don't know how to do that from a module. 2. All bus operations that are 16 bit or more should be big endian - no swapping. This is the same as APUS in io.h. We need to figure out how this should co-exist with the swapped ISA. 3. My driver needs a bd_t * called mpc8xx_bdinfo to figure. out the busfrequency. A standard with the frequencyvalues in HZ would be good. 4. Kernel drivers that are used by pcmcia-cs. I havn't had any success with module-based ide code. But when I compile-in the ide code I need to pass "ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe" to be able to boot. You also might have to play a bit with the ide code in m8xx_setup.c I've added an option to serial.c to avoid probing when the module is inserted. 5. The pcmcia code ioremaps/iounmaps quite much. It would be nice with a working iounmap! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- next part -- A non-text attachment was scrubbed... Name: patch-m8xx-pcmcia-cs-3.1.10.diff.gz Type: application/x-gzip Size: 14261 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/2215/d5cd3749/attachment.bin
Linux w/ Motorola 860ADS target
"Clayton, Mark" wrote: > > Is there a difference between the 860ADS and the 860FADS? Yep. The big difference is that the FADS series of boards all share the same motherboard and different CPU:s has got different daughterboards with some extra features. My FADS860T has got a 100Mbit PHY on the daughterboard. The FADS motherboard has got 4MBytes of sdram conneted to it. The ADS is only supporting the 860/821 processor and has no daughterboard and no sdram either. None of the boards are stable. The worst board it the FADS. I wonder if it will boot today... For more info and pictures: http://www.s4l.de/powerpc.html > Thanks, > Mark > > > > > > > "Todd_Tomaino"@vnci.net wrote: > > > > > > Hello, > > > > Hi! > > > > > I am brand new to Linux as well as the list. I am > > interested in using > > > Linux with the 860ADS demo board as a target. > > > > That is a pretty good board. But watch out for the ZIF socket! > > I've got two boards: One PILOT and one REV-B. Only the REV-B works. > > > > > Could anyone suggest a > > > version of Linux that is well suited for this purpose. > > > > ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/mpc8xx-2.2.13.tgz > > > > That version has not much ADS860 support, but I've made a patch > > that is floating around. Check previous messages! > > > > You also need to apply a low-memory patch if you > > want to be able to do something. > > Check the archives there too. > > > > This site has info about booting and stuff. > > > > http://www.s4l.de/powerpc.html > > > > You will probably need 8xxrom to boot your board. > > > > > Also, drivers for > > > the PCMCIA interface would be a real plus. > > > > Well, that's me! > > > > I am actually running Linux on a ADS860 right now, trying out > > my PCMCIA socket driver for the mpc8xx series. > > > > Most things work, but I have not released the driver yet. > > I plan doing so next week or so. > > > > The driver will be as a patch against David Hinds pcmcia-cs package. > > > > > In looking around under the > > > search criteria for "Linux PPC" I am seeing versions such > > as Black Lab, > > > Yellow Dog, Debian, etc. These appear to be geared more > > towards desktop > > > power pc units. Is it possible to use one of these for an embedded > > > application?? > > > > If you patch and replace glibc it should be possible. > > You probably need heaps of memory, though. > > > > We crosscompile the programs we need. > > > > Good luck / > > > > Magnus > > > > > best regards, > > > > > > Todd ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux w/ Motorola 860ADS target
"Todd_Tomaino"@vnci.net wrote: > > Hello, Hi! > I am brand new to Linux as well as the list. I am interested in using > Linux with the 860ADS demo board as a target. That is a pretty good board. But watch out for the ZIF socket! I've got two boards: One PILOT and one REV-B. Only the REV-B works. > Could anyone suggest a > version of Linux that is well suited for this purpose. ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/mpc8xx-2.2.13.tgz That version has not much ADS860 support, but I've made a patch that is floating around. Check previous messages! You also need to apply a low-memory patch if you want to be able to do something. Check the archives there too. This site has info about booting and stuff. http://www.s4l.de/powerpc.html You will probably need 8xxrom to boot your board. > Also, drivers for > the PCMCIA interface would be a real plus. Well, that's me! I am actually running Linux on a ADS860 right now, trying out my PCMCIA socket driver for the mpc8xx series. Most things work, but I have not released the driver yet. I plan doing so next week or so. The driver will be as a patch against David Hinds pcmcia-cs package. > In looking around under the > search criteria for "Linux PPC" I am seeing versions such as Black Lab, > Yellow Dog, Debian, etc. These appear to be geared more towards desktop > power pc units. Is it possible to use one of these for an embedded > application?? If you patch and replace glibc it should be possible. You probably need heaps of memory, though. We crosscompile the programs we need. Good luck / Magnus > best regards, > > Todd ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
821/823 and Linuxppc problems revisited
Karl P?lsson wrote: > > Hi all, Hi! > Thank you for your replies regarding the 821 and related problems. > We will use 823 in our design instead of the 821. That brings me back to the > original question: Are there any known problems implementing Linuxppc on the > 823? Hints? Advice? Any luck with DiskOnChip? I say: Go for CompactFlash on the PCMCIA port instead of the DiskOnChip. They are cheap and they work great. We use it here. I tried linux on a 823 yesterday and it works great! The cpu core is the same as 850 (not 823e though). As I said before - try a RPX LITE 823 from embedded planet. I've got one here! Then you can run Linux on it and try it out if it meets your performance demands before you make your own board. The 860/821/823e has bigger caches/mmu which will give you better performance. Cheers / Magnus > Best regards, > Karl Palsson, B.Sc.E.E. > Infocom Defence Systems A/S > Ellegaardsvej 25 > 6400 Soenderborg > Tel: +45-73 12 30 00 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA socket driver (was Re: Non NFS boot)
I am working on a PCMCIA socket driver for the 8xx series. I've managed to run a Xircom based ethernetcard and ATA-Flash. The following boards will be supported: BOARDCPU RPX CLASSIC LOW FAT 860T RPX LITE 850 823 ADS 860 FADS 860T This will make it possible to use any ATA-Disk as root fs. The code will be available as a patch againts pcmcia-cs-3.1.8.tar.gz Cheers / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Antwort: Re: Antwort: 8xxrom wierdness, 2nd
> - Do you have experience with the sandisk pc cards? Not with pc cards. But my compact-flash cards with converter works. I've got cf-cards from Sandisk, Viking and Mitsubishi. I posted about the wierd Viking card a few weeks ago... If anyone out there wants support for a certain ATA-card feel free to send them to me and I will make sure it works! =) If I were you would I have a look at the data-sheet for the pc-card and verify that the ata registers are mapped at the right positions... SanDisk has got pretty nice CF manuals and I guess that their pc-card documentation is good too. > - I formatted the pc card on a win95 box. That should work, right? > (At least the boot device list should mention something) It should work. >> ATA disk: 'SunDisk SDP'. > > Boot device list:Card Not Ready 0x0 It is good that it is able to parse the cis and find out that it is a ATA disk. It probably fails when it should send a identify command. You might need some spinup time if it is a mechanical drive. Cheers / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xxrom wierdness
Hello all, > Hi Mika > > How did your mkrombin work on the zImage. Here it always failed > > Therefore I bought an ATA Flash disk. > I copied the zImage to the flash disk and plugged it into the board. > > My problem is that the board doesn't recognise the Flash disk. > > First it says that 'pcmcia: card not present' > Then It prints an error message like: "Boot device list: Card not ready, 0xf0" > and exits with an 'Software emulation interrupt' Ok, this is it: depending on what kind of processor you are using the fads board use different slots: 860 SLOT_A 823 SLOT_B The pcmcia code in the 8xxrom 0.3.0 is pretty screwed. Things did not work out of the box with for my ADS860. I've done some hacking and things are back where they were on my ADS860 and SLOT_A and SLOT_B configuration option is added and some nice pcmcia code is created... Things are not really finished yet... I can send my hacked work to anyone who wants it. If no one wants to deal with it will I fix it later. Cheers and good luck! / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Antwort: Re: Loading the Kernel on a FADS
> Not that I understand the above problem any better, but I see where it > crashes more clearly now. > > > It always crashes when it jumps into a string function from the > > lib 'string'. (e.g. strchr) > > Any ideas?? I think someone messed with PGSZ settings in main.c... I changed it back to 4096 and things started to work again. I don't really know why. It would be good if someone sat down and had a thought about what is going on... Hope it helps / Magnus Damm ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
CompactFlash Viking problem
Hello! I've been playing around with the 8xxrom pcmcia code and done some simple CIS parsing code. I am using a ADS860 Rev B board. The MMU is off, the code is running from flash. I've done a workaround for the bugs in the MACH-circuits. The code works fine with: SanDisk CompactFlash Mitsubishi CompactFlash Ericsson Pcmcia V34 Modem The following card does not work: Viking components CompactFlash. My code reads the attribute space on each card and parses the tuples. The problem is that the Viking card gives me correct CIS sometimes, but mostly crap (I guess some kind of test-pattern). This leads to no end-of-cis marker, which is bad. I browsed the net and found that Paul Rubin have had a problem that seems related: http://hyper.stanford.edu/HyperNews/get/pcmcia/ataide/39.html People has experienced problem with Viking components before: http://www.goof.com/~mmead/dc120/mail-archive/9806/msg00026.html I've contacted Viking support but they told me that they didn't do that kind of tech-support. Another thing is that if I stick to access the ATA registers all CompactFlash cards (even the Viking) work. Any ideas, workarounds, similar problems? TIA / Magnus Damm ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
pcmcia-cs for 8xx
Hello all, What's the status about the 8xx pcmcia controller? I've played around with my FADS board and boot software. The pcmcia stuff works pretty fine. I did a small hack half a year ago to use my pcmcia-ata disk as root filesystem using the ide code in Linux. That wasn't such a generic solution... Wouldn't it be nice to use the pcmcia-cs package? Anyone done that already? I saw some messages floating around about RPXLite 823. Is there anything I should know before I start digging? TIA / Magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ask for help
> the main difference between the environments of yours and mine is that > you > put image on disk while i put it on flash. something must do some > transferring Hm. Nowadays I use NFS/compact flash for storage. But before stuff like that worked I used initrd. And I am very sure I did the initrd on my x86 server. I copied the linux image and the initrd to flash on my 8xx board. It worked. Did not gzip it though. And I did some code to 8xxrom that reads blocks from a romdisk. This is how it must be: 1. The program you use to write the diskimage to flash does not convert anything. If it did it would convert your linux image too, right? And that would not work. 2. Your block device driver reads the data from the flash, right? Lets say that the x86 computer has stored the 32bit number 0xdeadbeef in memory and written it to disk: byte no. 00 01 02 03 content ef be ad de You burn your file to your flash: flash addr 00 01 02 03 contentef be ad de You read it out to register r3. r3 = 0xefbeadde - not the same 32bit value as on the x86! But the contents of the memory is the same on both platforms. It is the way it is written/read that matters. That is why it must be some standard how the fs is treated. The blockdriver should copy 512/4 bytes. No translation at all. 3. File systems are either big endian or little endian. If your platform is say big endian and the fs is little, you need to byteswap. This is usually handled by the fs with macros. If you have a look at minix source code it looks like the code does not support endian changing. That means that you have to create the fs on the machine you intend to use it on. Both fat and ext2 supports both endians -> no problems! Good luck / Magnus Damm ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ask for help
I don't know about minix, but I've made a ramdisk with ext2 support on my x86 server and used it on a 8xx. I've never experienced any endian problems with that. That was a while ago though... Maybe things have changed.. Cheers / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ads fads 860 patch
Hello all,
Here comes my embedded-2.2.13 patch for ADS and FADS.
The following works:
ADS and FADS NFSROOT.
Only 860 tested.
Does not work:
fec.c with FADS860T.
The following files are not properly changed
they are only changed to be able to compile quick fix.
arch/ppc/kernel/ksysm.c
arch/ppc/kernel/setup.c
arch/ppc/mm/init.c
They have nothing to do with ADS / FADS.
Have a nice weekend!
Cheers /
Magnus Damm
-- next part --
diff -ruN embedded_2.2.13_org/arch/ppc/8xx_io/commproc.h
embedded-2.2.13/arch/ppc/8xx_io/commproc.h
--- embedded_2.2.13_org/arch/ppc/8xx_io/commproc.h Sat Oct 23 01:14:48 1999
+++ embedded-2.2.13/arch/ppc/8xx_io/commproc.h Fri Nov 26 16:10:00 1999
@@ -457,6 +457,33 @@
#define SICR_ENET_CLKRT((uint)0x003d)
#endif
+#if defined(CONFIG_ADS) || defined(CONFIG_FADS)
+
+/*
+ * The Motorola (F)ADS boards has got ethernet on SCC1.
+ */
+
+#define PA_ENET_RXD((ushort)0x0001)
+#define PA_ENET_TXD((ushort)0x0002)
+
+#define PA_ENET_TCLK ((ushort)0x0100)
+#define PA_ENET_RCLK ((ushort)0x0200)
+#define PB_ENET_TENA ((ushort)0x1000)
+
+#define PC_ENET_CLSN ((ushort)0x0010)
+#define PC_ENET_RENA ((ushort)0x0020)
+
+#define SICR_ENET_MASK ((uint)0x00ff)
+#define SICR_ENET_CLKRT((uint)0x002c) // T=CLK1, R=CLK2
+
+/* 68160 PHY control */
+
+#define PC_ENET_ETHLOOP ((ushort)0x0800)
+#define PC_ENET_TPFLDL ((ushort)0x0400)
+#define PC_ENET_TPSQEL ((ushort)0x0200)
+
+#endif
+
/* SCC Event register as used by Ethernet.
*/
#define SCCE_ENET_GRA ((ushort)0x0080)/* Graceful stop complete */
diff -ruN embedded_2.2.13_org/arch/ppc/8xx_io/enet.c
embedded-2.2.13/arch/ppc/8xx_io/enet.c
--- embedded_2.2.13_org/arch/ppc/8xx_io/enet.c Fri Oct 22 23:24:13 1999
+++ embedded-2.2.13/arch/ppc/8xx_io/enet.c Fri Nov 26 15:40:21 1999
@@ -981,6 +981,23 @@
immap->im_ioport.iop_pcdat &= ~PC_BSE_LOOPBACK;
#endif
+#if defined(CONFIG_ADS) || defined(CONFIG_FADS)
+ cp->cp_pbpar |= PB_ENET_TENA;
+ cp->cp_pbdir |= PB_ENET_TENA;
+
+/* Port C is used to control the PHY, 68160.
+ */
+immap->im_ioport.iop_pcdir |=
+ (PC_ENET_ETHLOOP | PC_ENET_TPFLDL | PC_ENET_TPSQEL);
+
+immap->im_ioport.iop_pcdat |= PC_ENET_TPFLDL;
+immap->im_ioport.iop_pcdat &= ~(PC_ENET_ETHLOOP | PC_ENET_TPSQEL);
+
+ /* Enable the PHY in Board Control Status Register 1 */
+
+*((uint *)BCSR1) &= ~BCSR1_ETHEN;
+#endif
+
dev->base_addr = (unsigned long)ep;
dev->priv = cep;
#if 0
@@ -1005,4 +1022,14 @@
return 0;
}
+
+
+
+
+
+
+
+
+
+
diff -ruN embedded_2.2.13_org/arch/ppc/8xx_io/uart.c
embedded-2.2.13/arch/ppc/8xx_io/uart.c
--- embedded_2.2.13_org/arch/ppc/8xx_io/uart.c Thu Oct 21 00:02:21 1999
+++ embedded-2.2.13/arch/ppc/8xx_io/uart.c Fri Nov 26 15:41:06 1999
@@ -2417,7 +2417,12 @@
* make it out of the transmit buffer.
*/
if (i == CONFIG_SERIAL_CONSOLE_PORT)
+#if defined(CONFIG_ADS) || defined(CONFIG_FADS)
+ mdelay(200);
+#else
mdelay(2);
+#endif
+
#endif
info = kmalloc(sizeof(ser_info_t), GFP_KERNEL);
if (info) {
diff -ruN embedded_2.2.13_org/arch/ppc/config.in
embedded-2.2.13/arch/ppc/config.in
--- embedded_2.2.13_org/arch/ppc/config.in Fri Oct 22 23:56:10 1999
+++ embedded-2.2.13/arch/ppc/config.in Thu Nov 25 16:02:25 1999
@@ -31,7 +31,9 @@
MBXCONFIG_MBX \
RPXL CONFIG_RPXLITE \
RPXC CONFIG_RPXCLASSIC \
-BSE-IP CONFIG_BSEIP" PowerMac
+BSE-IP CONFIG_BSEIP \
+ADSCONFIG_ADS \
+FADS CONFIG_FADS" PowerMac
bool 'Symmetric multi-processing support' CONFIG_SMP
if [ "$CONFIG_ALL_PPC" != "y" ];then
diff -ruN embedded_2.2.13_org/arch/ppc/kernel/irq.c
embedded-2.2.13/arch/ppc/kernel/irq.c
--- embedded_2.2.13_org/arch/ppc/kernel/irq.c Fri Oct 22 22:48:22 1999
+++ embedded-2.2.13/arch/ppc/kernel/irq.c Thu Nov 25 16:56:46 1999
@@ -54,9 +54,13 @@
#include
#include
#include
+
+#ifdef CONFIG_APUS
#include
#include
#include
+#endif /* CONFIG_APUS */
+
#include
#include "local_irq.h"
diff -ruN embedded_2.2.13_org/arch/ppc/kernel/ppc8xx_pic.c
embedded-2.2.13/arch/ppc/kernel/ppc8xx_pic.c
--- embedded_2.2.13_org/arch/ppc/kernel/ppc8xx_pic.cFri Oct 22 22:50:42 1999
+++ embedded-2.2.13/arch/ppc/kernel/ppc8xx_pic.cFri Nov 26 13:22:59 1999
@@ -137,6 +137,8 @@
ppc_irq_dispatch_handler( regs, irq );
}
+#endif
+
/* Only the MBX uses the external 8259. This allows us to catch standard
* d
need suggestions
> I have a ADS8xx board and I downloaded kernel source mpc8xx-2.2.13.tgz > from ppc.kernel.org. Can you tell me how to port it to ADS8xx board and > make a bootrom of Linux? > I am a newbie, so please tell something in detail. First of all: Check the revision of the board and the cpu. If you have a 860, find a cpu with revision C or later. If you have a ADS with rev. ENG, PILOT or A you will have some trouble. I have had linux up and running on a ADS board. A good starting point is to read the manual and check what differs from the FADS. I have bootcode that is based on fadsrom by Dan Malek. It is kind of a mess right now, but it should support both the ADS and the FADS board using 860(t). It loads a zImage or vmlinux from a ATA-FLASH or the onboard flash-simm. It understands ext2 and dos. No network support, though. I can mail the source to anyone who is interested. You will need a linux source tree and a (cross)compiler. But I have no time for answers. Good luck / magnus damm ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
generic smc code patch
Hello all, This patch for embedded-2.2.13 will make macros out of some SMC / SCC constants in commproc.h. Creating generic SCC and SMC code will now be easier. Instead of PROFF_SCC1 use PROFF_SCC(1), or PROFF_SCC(n). Patch instructions: $ pwd /xxx/yyy/zzz/embedded-2.2.13 $ cat smc_scc.diff | patch -p1 Comments ? / Magnus -- next part -- diff -u -r embedded-2.2.13/arch/ppc/8xx_io/commproc.h embedded-2.2.13_smcp/arch/ppc/8xx_io/commproc.h --- embedded-2.2.13/arch/ppc/8xx_io/commproc.h Sat Oct 23 01:14:48 1999 +++ embedded-2.2.13_smcp/arch/ppc/8xx_io/commproc.h Thu Nov 18 09:08:24 1999 @@ -14,7 +14,18 @@ * bytes of the DP RAM and relocates the I2C parameter area to the * IDMA1 space. The remaining DP RAM is available for buffer descriptors * or other use. + * + * 17 Nov 1999: Magnus Damm + * Converted some constants to macros for the SCC:s and SMC:s. + * + * CPM_CR_CH_SxCn -> CPM_CR_CH_SxC(n) + * PROFF_SxCn -> PROFF_SxC(n) + * CPMVEC_SxCn-> CPMVEC_SxC(n) + * + * Generic SCC/SMC code will now be smaller/faster/better. + * No bounds checking is done, be careful. */ + #ifndef __CPM_8XX__ #define __CPM_8XX__ @@ -39,14 +50,17 @@ /* Channel numbers. */ -#define CPM_CR_CH_SCC1 ((ushort)0x) +#define CPM_CR_CH_SCC(n) ((ushort)(((n)-1) << 2)) +#define CPM_CR_CH_SMC(n) ((ushort)(0x0009 | (((n)-1) << 2))) + +/* #define CPM_CR_CH_SCC1 ((ushort)0x) */ #define CPM_CR_CH_I2C ((ushort)0x0001)/* I2C and IDMA1 */ -#define CPM_CR_CH_SCC2 ((ushort)0x0004) +/* #define CPM_CR_CH_SCC2 ((ushort)0x0004) */ #define CPM_CR_CH_SPI ((ushort)0x0005)/* SPI / IDMA2 / Timers */ -#define CPM_CR_CH_SCC3 ((ushort)0x0008) -#define CPM_CR_CH_SMC1 ((ushort)0x0009)/* SMC1 / DSP1 */ -#define CPM_CR_CH_SCC4 ((ushort)0x000c) -#define CPM_CR_CH_SMC2 ((ushort)0x000d)/* SMC2 / DSP2 */ +/* #define CPM_CR_CH_SCC3 ((ushort)0x0008) */ +/* #define CPM_CR_CH_SMC1 ((ushort)0x0009) */ /* SMC1 / DSP1 */ +/* #define CPM_CR_CH_SCC4 ((ushort)0x000c) */ +/* #define CPM_CR_CH_SMC2 ((ushort)0x000d) */ /* SMC2 / DSP2 */ #define mk_cr_cmd(CH, CMD) ((CMD << 8) | (CH << 4)) @@ -91,14 +105,18 @@ /* Parameter RAM offsets. */ -#define PROFF_SCC1 ((uint)0x) + +#define PROFF_SCC(n)((uint)(((n)-1) << 8)) /* SCC(1) -> SCC(4) */ +#define PROFF_SMC(n)((uint)n)-1) << 8) + 0x280)) /* SMC(1) -> SMC(2) */ + +/* #define PROFF_SCC1 ((uint)0x) */ #define PROFF_IIC ((uint)0x0080) -#define PROFF_SCC2 ((uint)0x0100) +/* #define PROFF_SCC2 ((uint)0x0100) */ #define PROFF_SPI ((uint)0x0180) -#define PROFF_SCC3 ((uint)0x0200) -#define PROFF_SMC1 ((uint)0x0280) -#define PROFF_SCC4 ((uint)0x0300) -#define PROFF_SMC2 ((uint)0x0380) +/* #define PROFF_SCC3 ((uint)0x0200) */ +/* #define PROFF_SMC1 ((uint)0x0280) */ +/* #define PROFF_SCC4 ((uint)0x0300) */ +/* #define PROFF_SMC2 ((uint)0x0380) */ /* Define enough so I can at least use the serial port as a UART. * The MBX uses SMC1 as the host serial port. @@ -653,12 +671,16 @@ * use the table as defined in the manuals (i.e. no special high * priority and SCC1 == SCCa, etc...). */ + +#define CPMVEC_SCC(n) ((ushort)(0x1f-(n))) /* SCC(1) -> SCC(4) */ +#define CPMVEC_SMC(n) ((ushort)(0x05-(n))) /* SMC(1) -> SMC(2) */ + #define CPMVEC_NR 32 #defineCPMVEC_PIO_PC15 ((ushort)0x1f) -#defineCPMVEC_SCC1 ((ushort)0x1e) -#defineCPMVEC_SCC2 ((ushort)0x1d) -#defineCPMVEC_SCC3 ((ushort)0x1c) -#defineCPMVEC_SCC4 ((ushort)0x1b) +/* #define CPMVEC_SCC1 ((ushort)0x1e) */ +/* #define CPMVEC_SCC2 ((ushort)0x1d) */ +/* #define CPMVEC_SCC3 ((ushort)0x1c) */ +/* #define CPMVEC_SCC4 ((ushort)0x1b) */ #defineCPMVEC_PIO_PC14 ((ushort)0x1a) #defineCPMVEC_TIMER1 ((ushort)0x19) #defineCPMVEC_PIO_PC13 ((ushort)0x18) @@ -678,8 +700,8 @@ #define CPMVEC_TIMER4 ((ushort)0x07) #defineCPMVEC_PIO_PC6 ((ushort)0x06) #defineCPMVEC_SPI ((ushort)0x05) -#defineCPMVEC_SMC1 ((ushort)0x04) -#defineCPMVEC_SMC2 ((ushort)0x03) +/* #define CPMVEC_SMC1 ((ushort)0x04) */ +/* #define CPMVEC_SMC2 ((ushort)0x03) */ #defineCPMVEC_PIO_PC5 ((ushort)0x02) #defineCPMVEC_PIO_PC4 ((ushort)0x01) #defineCPMVEC_ERROR((ushort)0x00) Only in embedded-2.2.13_smcp/arch/ppc/8xx_io: commproc.h~ Only in embedded-2.2.13_smcp/arch/ppc/8xx_io: commproc.o diff -u -r embedded-2.2.13/arch/ppc/8xx_io/enet.c embedded-2.2.13_smcp/arch/ppc/8xx_io/enet.c --- embedded-2.2.13/arch/ppc/8xx_io/enet.c Fri Oct 22 23:2
PCMCIA use
> Hello, > > Has anyone out there done anything with PCMCIA on the 8xx? Have a look at the IDE code. (8xx specific part)! And check out the fadsrom code. I tried to do some CIS parsing code a while ago, but I ended up with some cards working, some not. Maybe we should use the pcmcia-cs package and modify it? Good luck! / magnus ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Cleanup thought.
Hi all,
I would like to take up the question about configuration again.
I believe that the situation is the same for a lot of people
out here: Get Linux working on some kind of new 8xx hardware.
Today we need to modify and add #ifdefs to different files.
I like the idea of some kind of central board specific file.
I'm relly happy the day I just add my board_name.h to mpc8xx.h
and everything works...or something else.
I suggested the following code to Dan Malek a while ago, and he didn't
like the idea with a lot of inline code in one .h file, right Dan?
Anyone else out there with another idea how to solve this problem?
Or is it a problem..?
Cheers /
Magnus
Code from my ads.h - board specific file for my ADS board.
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
/* Macros and values needed by the ethernet driver - enet.c */
#include
#include
#include
#define PA_ENET_RXD ((ushort)0x0001)
#define PA_ENET_TXD ((ushort)0x0002)
#define PA_ENET_TCLK((ushort)0x0100)
#define PA_ENET_RCLK((ushort)0x0200)
#define PB_ENET_TENA((ushort)0x1000)
#define PC_ENET_CLSN((ushort)0x0010)
#define PC_ENET_RENA((ushort)0x0020)
#define SICR_ENET_MASK ((uint)0x00ff)
#define SICR_ENET_CLKRT ((uint)0x002c) // T=CLK1, R=CLK2
#define PC_ENET_ETHLOOP ((ushort)0x0800)
#define PC_ENET_TPFLDL ((ushort)0x0400)
#define PC_ENET_TPSQEL ((ushort)0x0200)
/* tell the ethernet driver we want to use SCC1 */
extern __inline__ int enet_get_scc(unsigned int enet_nr)
{
switch(enet_nr) {
case 0: return 1; /* allow only one ethernet, use SCC1 */
default: return 0;
}
}
/* configure ethernet pins, clocks and the ethernet address */
extern __inline__ void enet_configure(unsigned int enet_nr,
immap_t *immap, unsigned char *eap)
{
bd_t*bd = (bd_t *)res;
int i;
/* Configure port A pins for Txd and Rxd.
*/
immap->im_ioport.iop_papar |= (PA_ENET_RXD | PA_ENET_TXD);
immap->im_ioport.iop_padir &= ~(PA_ENET_RXD | PA_ENET_TXD);
immap->im_ioport.iop_paodr &= ~PA_ENET_TXD;
/* Configure port C pins to enable CLSN and RENA.
*/
immap->im_ioport.iop_pcpar &= ~(PC_ENET_CLSN | PC_ENET_RENA);
immap->im_ioport.iop_pcdir &= ~(PC_ENET_CLSN | PC_ENET_RENA);
immap->im_ioport.iop_pcso |= (PC_ENET_CLSN | PC_ENET_RENA);
/* Configure port A for TCLK and RCLK.
*/
immap->im_ioport.iop_papar |= (PA_ENET_TCLK | PA_ENET_RCLK);
immap->im_ioport.iop_padir &= ~(PA_ENET_TCLK | PA_ENET_RCLK);
/* Port C is used to control the PHY, 68160.
*/
immap->im_ioport.iop_pcdir |=
(PC_ENET_ETHLOOP | PC_ENET_TPFLDL | PC_ENET_TPSQEL);
immap->im_ioport.iop_pcdat |= PC_ENET_TPFLDL;
immap->im_ioport.iop_pcdat &= ~(PC_ENET_ETHLOOP | PC_ENET_TPSQEL);
/* Configure Serial Interface clock routing.
* First, clear all SCC bits to zero, then set the ones we want.
*/
immap->im_cpm.cp_sicr &= ~SICR_ENET_MASK;
immap->im_cpm.cp_sicr |= SICR_ENET_CLKRT;
/* Set ethernet address
*/
for (i=0; i<6; i++)
eap[i] = bd->bi_enetaddr[i];
}
/* enable the ethernet transmitter */
extern __inline__ void enet_tena(unsigned int enet_nr, immap_t *immap)
{
immap->im_cpm.cp_pbpar |= PB_ENET_TENA;
immap->im_cpm.cp_pbdir |= PB_ENET_TENA;
*((uint *)BCSR1) &= ~BCSR1_ETHEN;
}
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
/* Should there be a SMC at /dev/ttyS ? */
extern __inline__ int uart_get_smc(unsigned int uart_nr)
{
switch(uart_nr) {
case 0: return 1; /* the first serial port is at SMC1 */
case 2: return 2;
default: return 0;
}
}
/* Or should it be a SCC ? */
extern __inline__ int uart_get_scc(unsigned int uart_nr)
{
switch(uart_nr) {
case 1: return 3;
default: return 0;
}
//return 0; /* we don't want any SCC
