[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Coldfire Boards

Hash: SHA1

I'm just curious on who got what. I know Stephen gave me his board,
but I'm curious to know which boards went where.

Anyway, here are a couple of my bootstrapping notes.

1. Coldfire m68k IGNORES command line args, they're hardcoded. If you
want to change it, you need to change the hardcoding. Its a
configuration option.
2. Bug in usbcore prevents the detection of mountable harddrives. No
matter what USB device I had plugged in, while the device itself was
detected, it doesn't find any paritions. It looks like this may be an
issues with the m68k SCSI handling code.
3. Possible initramfs bug - it always panics for me trying to execute
/init. Can't confirm if this a legit bug, or a toolchain/user issue at
this time.
4. The board has two flash chips, which may throw some people through
a loop since Linux only sees one.

There is a 2MB flash, address range: 0xFF800000->0xFF9FFFFF
dBUG and LogicLoader live on this chip. dBug is at 0xFF9FFFFF as far
as I can tell.

The main 16MB flash is on address range 0xE0000000->0xE0FFFFFF
There is a kernel configuration option on this, make sure you give it
the right starting range, or else the MTD device will point to the
wrong flash chip and quite possible brick your device.

5. It is possible to boot a kernel from dBUG directly since the kernel
will load and execute at entry point 0x200000. just dn -i the image,
then use go to jump to the execution point. BSP packages will
configure the kernel to output on the right serial port.

6. BSP doesn't support cross-building the toolchain (not surprising,
since cross-building GCC is more of an art than a science).

7. Unlike most other CF boards, I can't find anything in the specs
that can change the load location of the IPL (most other CF boards
have the ability via a jumper to load to the halfway point in the
first flash chip), so if you want to replace dBUG with u-boot, you
have to write over it. Don't try this without JTAG access or
confirming the BDM module works! (for those of us with BDM modules)

8. My current technique is to write a JFFS2 filesystem to the second
flashchip, and then get linux to use /dev/mtdblock0 as its root
parition. Not ideal, but without replacing dBUG, and properly
parationing the second flash chip, its the best I got.

Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org


Reply to: