can't compile kernel for CS-E9301

Hi,

I recently bought a CS-E9301, that shipped with the 2.4 kernel preinstalled.

I tried to boot a 2.6 kernel from the cirrus 2.6 package, then I compiled the one from the cirrus package and finally I tried to compile a 2.6.19 with the config from Dominic.

Neither of these kernels worked. After loading and executing them from redboot I get the message that the kernel gets uncompressed (lots of dots following) and then nothing happens anymore.

(I tried with the following commands:

RedBoot> load -r -v -b 0x800000 ramdisk.gz

RedBoot> load -r -v -b 0x80000 zImage

RedBoot> exec -r 0x800000 -s 0x800000 -c “root=/dev/ram console=ttyAM”

)

Can someone help ?

Axel

I think the kernel 2.6.x provides additional feature form 2.4.x.

I experience many bugs when I use 2.6.x.

I my opinion, you should use the old v2.4 kernel.

Hello Axel,

the bootloader passes a machine ID to the kernel, telling it which machine the kernel runs on. This allows (among other things) a single kernel to support several different machines. The .config and kernel patch I’ve provided expects the CS-E9301’s own machine ID - your redboot uses the EDB9301’s machine ID. If you don’t want to modify your bootloader, you could change arch/arm/tools/mach-types and switch numbers between EDB9301 and CS-E9301, or you could add a kernel shim that correctly sets the boot parameters before the kernel gets run.

I have a U-Boot patch that sets things up correctly and passes the right machine ID for the CS-E9301 - if you have access to JTAG tools to be able to reprogram the flash if something goes wrong, you could use this, too.

@sci-3d:

The current Linux 2.6 kernels are superior to 2.4 kernels in almost every possible way. The EP93xx support in mainline is stable, it’s main problem is the lack of support for several of the peripherals. Cirrus seems to be unable or unwilling to work with the community on getting these things upstream (in a form acceptable to upstream). Cirrus’ own 2.6.8.1 port supports most of the EP93xx’s peripherals, but the quality of this code is generally thought to be inferior. The 2.6.8.1 codebase itself might very well have known bugs - after all it’s been more than two years since it was released.

Regards,

Dominic

In case anyone is interested:

I’ve put my U-Boot patch (based on work from Cory T. Tusar and Andrea “llandre” Marson) online at http://mmd.ath.cx/cs-e9301/u-boot-ep93xx.patch.gz

Regards,

Dominic

Hi Dominic,

your answer was the key.

The machine ID was wrong, but it was not the ID of the EDB9301 (462), it was 454 (eb67xdip).

As you suggested, I switched the numbers and then it complained about the wrong ID.

Should I switch to U-Boot instead of Redboot ? Can I use the Redboot Download Utility to reprogram the flash ?

Yours,

Axel

Hello Axel,

I prefer U-Boot because I’ve used it more often, and because I think it’s slightly less bloated than the redboot. It was also a lot easier for me to set up a development environment for U-Boot then it was to set up a eCos/Redboot environment.

You really shouldn’t replace your bootloader unless you have access to a JTAG interface. The EP93xx allows you to bootstrap using a serial interface, but it’s a lot easier to just flash a new u-boot.bin to the flash. I’m not sure what the Redboot download utility is, but you could use Redboot to replace itself with U-Boot. In case something goes wrong, you’ll want to use JTAG to get your system going again.

Regards,

Dominic