ARM linux and cross toolchain issue

4
votes

I have a problem probably with my arm toolchain but maybe there's something other that I do wrong. I have Chinese made dev board qq2440 using Samsung s3c2440 ARM9 uC. I'm using Ubuntu x86 with native gcc(4.3.3) and cross-compile version arm-unknown-linux-uclibc-gcc (crosstool-NG-1.3.2) 4.3.2

I followed tutorials from http://blog.leshak.ru/english/pages/how-to-install-u-boot-linux-2629-rootfsjffs2-busybox-1132-into-nand-qq2440/ and used Leshak's kernel patches for that board. Problem is that his binaries work perfectly and mine don't...

I communicate with my board over RS232 (serial port) and I have serial terminal configured on target Linux. I use Leshak's uboot image. To configure my kernel I use following command line:

qq2440> setenv bootargs 'noinitrd root=/dev/mtdblock2 rootfstype=jffs2 rw console=ttySAC0,115200'

For target I use vanilla Linux sources version 2.6.29, with patches created by Leshak. I don't honestly believe that this will ever be supported officially by Linux as it's not mainstream product.

My kernel image starts booting up, but it probably changes bandwidth (or CPU frequency) to some non standard value (tried all standard ones already). Instead of dots indicating loading kernel into memory I've got only trash instead. Unfortunately it doesn't probably finish the boot process as the network interface nor file system don't come up. So I figured out that it panics somewhere in the middle.

Any ideas what should I do next?

Thanks & regards,

Chris

3
linuxembeddedkernelarmtoolchain
You may have to post some of the actual terminal output to get any useful feedback. – simon
Did you get a pre-built image to load and boot? If so try building a demo app with your tool chain and run it with the pre-built images. If a simple test app doesn't run then there is some thing wrong with the toolchain setup and your image may not have built correctly. – simon
Ubuntukernel makes a lot of adjustments on the vanilla kernels; you might want to check for inconsistencies that're architecture specific, you probably ought to have some sort of /var/log/boot that you should show the output to. – amaterasu
@simon: will compile some simple test app (like led test) with my toolchain to see if it works – Chris Ciesielski
@simon: I will add some output as soon as I get home – Chris Ciesielski

3 Answers

2
votes

There are a lot of different things that could be going on here.

It sounds like you are talking about a serial port, and that it appears to be giving garbage once control is passed to the kernel from uboot. Am I understanding that correctly?

Look into specifying the baud rate, parity, etc. for the serial console on the kernel commandline.

Oh, and IIRC, there was some 'early_printk' thing in the ARM Linux tree that might help you debug serial console problems. (But I'll warn you -- it's been a couple years since I dealt with that so my memory is fuzzy.)

Double-check that the memory address layout (the locations of all the various devices) matches what your board has. (I think this is probably not the issue, but wanted to mention it for completeness.)

You say that you have a binary kernel that works correctly; compare the kernel config of that kernel to the config you are using for building your kernel. Investigate every difference, particularly any specific to ARM.

You may want to double-check the endianness of your toolchain vs what your board is expecting. Some of the ARM / XScale processors can be configured to big-endian or little-endian in software, so it might be worth double-checking.

1
votes

  1. Just enable the debug build of the kernel[while building the uImage] so that you get a more clearer picture of the scenario [Just would make your boot up somewhat slow since all the printk's would be enabled].

  2. Can you check whether you are passing the correct parameters to the UART ie. Serial Port Name, it's baud rate etc This would be provided by the board manufacturer-Samsung

  3. WRT the network instead of DHCP can you just assign a static ip address to your system as it might be possible that the DHCP process is still not ON.

  4. Also a better option would be to use NFS but yeah, it depends on your choice and the purpose of your application. To use NFS, your network should be UP & running and your filesystem should be shared.

As retracile has already pointed out "Endianness" could be a point to look into !!!

You can refer this link which might help you out since it is specific to S3C2440

Hope this helps.

-hjsblogger

0
votes

I had a similar problem at one point when I omitted --send-cmd from picocom. this is the command I issue to picocom for serial uBoot comms with the mini2440.

picocom -b 115200 /dev/ttyS0 --send-cmd "sx -vv"