linux-2.6.24.atmel.1 crashes during compile

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tried to compile linux-2.6.24.atmel.1 on Ubunty 'Gutsy' 32-bit with the official Debian AVR32 compiler packages and tools from Atmel. To configure and make the kernel, I am using:

make ARCH=avr32 KBUILD_HAVE_NLS=yes xconfig
make ARCH=avr32 CROSS_COMPILE=avr32-linux- KBUILD_HAVE_NLS=yes

I have tried using defaults for all of the choices presented by xconfig. Ideally, I would like to compile the kernel and then customize it for a board that I am designing. However, I find that the kernel compile crashes:


  CC [M]  crypto/tea.o
  CC [M]  crypto/khazad.o
  CC [M]  crypto/anubis.o
  CC [M]  crypto/deflate.o
  CC [M]  crypto/michael_mic.o
  CC [M]  crypto/crc32c.o
  CC [M]  crypto/tcrypt.o
  CC [M]  crypto/xor.o
crypto/xor.c:23:21: error: asm/xor.h: No such file or directory
crypto/xor.c: In function 'calibrate_xor_blocks':
crypto/xor.c:131: error: 'XOR_TRY_TEMPLATES' undeclared (first use in this function)
crypto/xor.c:131: error: (Each undeclared identifier is reported only once
crypto/xor.c:131: error: for each function it appears in.)
make[1]: *** [crypto/xor.o] Error 1
make: *** [crypto] Error 2

Does anyone know what is happening? I would like to get this up and running, and I am becoming slightly frustrated. The same error seems to occur when I try compiling from the Atmel AVR32 git tree.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Drop compiling the crypto stuff in the kernel? You would probably not need it either.

The include/asm-avr32/xor.h header file would probably be wise to add to the AVR32 architecture though.

If you need the XOR stuff, you can add a include/asm-avr32/xor.h file which contains:

#include 

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hce,

Thank you ever so much for your reply! :D I added the #include to a file called include/asm-avr32/xor.h, and the compile did not crash when making the crypto stuff. However, there is yet another crash that occurs later along in the build process:

drivers/char/keyboard.c:1125:2: warning: #warning "Cannot generate rawmode keyboard for your architecture yet."
drivers/char/keyboard.c:1125:2: warning: #warning "Cannot generate rawmode keyboard for your architecture yet."
  CC      drivers/char/vt.o
  SHIPPED drivers/char/defkeymap.c
  CC      drivers/char/defkeymap.o
  CC      drivers/char/tty_audit.o
  CC      drivers/char/sysrq.o
  CC      drivers/char/rtc.o
In file included from drivers/char/rtc.c:70:
include/linux/mc146818rtc.h:16:59: error: asm/mc146818rtc.h: No such file or directory
drivers/char/rtc.c: In function 'rtc_is_updating':
drivers/char/rtc.c:220: error: implicit declaration of function 'CMOS_READ'
drivers/char/rtc.c: In function 'rtc_do_ioctl':
drivers/char/rtc.c:508: error: 'RTC_ALWAYS_BCD' undeclared (first use in this function)
drivers/char/rtc.c:508: error: (Each undeclared identifier is reported only once
drivers/char/rtc.c:508: error: for each function it appears in.)
drivers/char/rtc.c:519: error: implicit declaration of function 'CMOS_WRITE'
drivers/char/rtc.c: In function 'rtc_request_region':
drivers/char/rtc.c:928: error: implicit declaration of function 'RTC_PORT'
drivers/char/rtc.c: In function 'rtc_get_rtc_time':
drivers/char/rtc.c:1310: error: 'RTC_ALWAYS_BCD' undeclared (first use in this function)
drivers/char/rtc.c: In function 'get_rtc_alm_time':
drivers/char/rtc.c:1350: error: 'RTC_ALWAYS_BCD' undeclared (first use in this function)
make[2]: *** [drivers/char/rtc.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

Hmm. I wonder what version of Linux is used by Atmel on their development machines. (i.e. Ubuntu, Red Hat, Fedora, Suse, etc.) Could this be a problem with my version of Linux?

I wish this would work as smoothly as Atmel buildroot! I've been using the official version of Atmel buildroot, but I'm running into problems with I2C support (even with the bit-banging driver). I have the debug terminal for my custom board on USART0, and I am trying to communicate over I2C. However, SCL goes low (and stays low) when the Linux kernel boots, thereby not allowing me to access the I2C bus!

I'm hoping that a newer version of the kernel might have some bugs corrected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have no idea what you have enabled now, but it seems like you are trying to compile support for a driver which should not exist on AVR32 architecture. Enter xconfig or menuconfig and find the RTC section under, here you should disable the stuff you will not need.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should disable "Enhanced Real Time Clock Support" and "Generic /dev/rtc emulation". I suppose we should really make those buggers unselectable on AVR32...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Btw, those are under "Character Devices", not under "Real Time Clock" as you would expect. Hopefully they will soon both be phased out in favour of the new RTC framework which works on all platforms.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hce and how:

Thank you once again for these suggestions. I disabled "Enhanced Real Time Clock Support", which had been enabled by default. I didn't have to disable "Generic /dev/rtc emulation", which was already disabled.

and---it worked! The compile proceeded peacefully until the next crash:

  CC [M]  drivers/i2c/algos/i2c-algo-bit.o
  CC [M]  drivers/i2c/algos/i2c-algo-pcf.o
  CC [M]  drivers/i2c/algos/i2c-algo-pca.o
  LD      drivers/i2c/busses/built-in.o
  CC [M]  drivers/i2c/busses/i2c-ocores.o
  CC [M]  drivers/i2c/busses/i2c-parport.o
  CC [M]  drivers/i2c/busses/i2c-parport-light.o
  CC [M]  drivers/i2c/busses/i2c-simtec.o
  CC [M]  drivers/i2c/busses/i2c-stub.o
  CC [M]  drivers/i2c/busses/i2c-tiny-usb.o
  LD      drivers/i2c/chips/built-in.o
  CC [M]  drivers/i2c/chips/ds1337.o
  CC [M]  drivers/i2c/chips/ds1374.o
  CC [M]  drivers/i2c/chips/eeprom.o
  CC [M]  drivers/i2c/chips/max6875.o
  CC [M]  drivers/i2c/chips/pca9539.o
  CC [M]  drivers/i2c/chips/pcf8574.o
  CC [M]  drivers/i2c/chips/pcf8591.o
  LD      drivers/i2c/built-in.o
  CC [M]  drivers/i2c/i2c-core.o
  CC [M]  drivers/i2c/i2c-dev.o
  LD      drivers/ide/built-in.o
  CC [M]  drivers/ide/ide.o
In file included from drivers/ide/ide.c:68:
include/linux/ide.h:249:21: error: asm/ide.h: No such file or directory
make[2]: *** [drivers/ide/ide.o] Error 1
make[1]: *** [drivers/ide] Error 2
make: *** [drivers] Error 2

Linux is an amazing operating system, but it is a huge beast that cannot be quickly tamed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm...yeah. It's a bit of a shame that there are so many drivers that can be selected but don't actually work...

This time: Disable IDE support. If you really need IDE, please use the new libata subsystem instead (which has a driver for avr32 too.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Starting at the host computers config and cutting back (which is what happens implicitly when you run xconfig without any existing configuration) is fairly silly IMO. I'd start with a defconfig and work up, eg

make ARCH=avr32 atstk1002_defconfig
make ARCH=avr32 KBUILD_HAVE_NLS=yes xconfig
make ARCH=avr32 CROSS_COMPILE=avr32-linux- BUILD_HAVE_NLS=yes 

That said, there does need to be some work in Kconfig and creating include/asm-avr32 so that you can't actually create an invalid configuration on AVR32. It would be lovely to get to a stage where all{yes,mod}config/randconfig works as expected.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hce and how and Squidgit:

A million smiles for your help! :D :D :D :D :D (and so on!)

how: I disabled IDE support as you said in your previous post. I simply did a search using the xconfig tool until I found everything that was marked with IDE, and removed it.

This worked, and the compile proceeded until I reached another crash. I removed support for flexcop, ttusb, cpia, se401, stv680, pwc, "V4L usb devices", airo, parport, pcf8583, all things marked with "scsi" which can be unchecked, scsi, sg, and all things marked with "8250".

Now I have a uImage from the linux-2.6.24 tree!

So once again, thank you for pointing me in the right direction!

(Yes, I agree that starting without defconfig is silly. I live and learn.)