Ahh, this is because we dont build the boot code for 85xx. Since the only bootloader I'm aware of is u-boot, we do the following:
$ make uImage - kumar On Mar 3, 2005, at 10:49 AM, Clemens Koller wrote: > Hello, Kumar, > > I guess you are the right person to help me with the MPC85xx devices > and platforms. > Maybe you remember that I use a MPC8540 on the Board from Microsys. > (www.microsys.de). > > The Problem: 2.6.11 (as well as 2.6.11-rc4) breaks due to a > missing SERIAL_PORT_DFNS for mpc8540_ads in ns16550: > > root at ecam:/share/kernel/linux$ make > ?? CHK???? include/linux/version.h > make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date. > ?? CHK???? include/linux/compile.h > ?? CHK???? usr/initramfs_list > make[1]: `arch/ppc/boot/images/uImage' is up to date. > ?? CC????? arch/ppc/boot/common/ns16550.o > arch/ppc/boot/common/ns16550.c:20: error: `SERIAL_PORT_DFNS' undeclared > here (not in a function) > arch/ppc/boot/common/ns16550.c:20: error: initializer element is not > constant > arch/ppc/boot/common/ns16550.c:20: error: (near initialization for > `rs_table[0]') > make[2]: *** [arch/ppc/boot/common/ns16550.o] Error 1 > make[1]: *** [arch/ppc/boot/common] Error 2 > make: *** [zImage] Error 2 > > > > Well, I see that you try to get rid of the mess... but I still > didn't understand all your changes and the different flavors of > the platforms. (Uses the SBC8560 non-std. serial ports on external > interrupts? But all the others are 'normal' MPC85xx_DUART types?) > > STD_SERIAL_PORT_DFNS are also missing... so, how can I tell that > I want to use the same as I did in 2.6.10? Can I use STD_UART_OP? > Or is it deprecated to use an extra define if I don't have any > special non std. hardware. > > What is the best way for me to integrate my board (which will be used > in another system with some more PCI devices not part of the Microsys > platform) into your platform / device structures? > > Currently, only minor changes were necessary to get 2.6.10 mpc8540ads > working with my board. I needed to change only > the PHY addresses (ids) on the FECs) > and the PCI Interrupt routing (IDSEL -> IRQ ABCD) > as they are wired up slightly different. > > > > Best greets, > > Clemens Koller > _______________________________ > R&D Imaging Devices > Anagramm GmbH > Rupert-Mayer-Str. 45/1 > 81379 Muenchen > Germany > > http://www.anagramm.de > Phone: +49-89-741518-50 > Fax: +49-89-741518-19
