MS7206SE01 (SH72060 Solution Engine)
This is Hitachi ULSI Systems' reference platform for the SH7206 processor.
The first step for working with this board should be getting a better loader on it. Porting of this was done by Yoshinori Sato. For anyone used to working with Solution Engine boards, this process should be pretty familiar. But nevertheless, Sato-san has more detailed instructions here. Likewise, S-records and other things can be found here, and here.
Porting of the 2.6 kernel to this platform has been started and is currently in progress. Work for this is being done in the
branch. More information on this and how to get at the branch can be obtained from the Archive Registry.
This board is wired as big endian out of the box, and while this is configurable, it is generally intended to remain in this configuration due to how the MRSHPC is configured. Most of the current readily available toolchains are aimed at little endian use, and also don't factor in running without an MMU. As a result of this, the uClibc buildroot is the only sensible way to produce a toolchain for this platform.
Buildroot now also has a target device configuration for this board, though this is only of use to those building gcc 4.x and later toolchains (specifically targetted at sh2a_nofpueb).
Pre gcc 4.x toolchains
Ideally an sh2eb-linux-uclibc toolchain should be created, though for those interested in hacking on the kernel for this platform, an sh4eb-linux-uclibc toolchain with a recent binutils (at least 22.214.171.124.1) will suffice. The newer versions of binutils support proper ISA tuning for SH-2A, which is a significant benefit for hunting down bogus instructions in the current kernel tree that need to be handled.
For gcc 4.x and up, it's recommended to use an sh2a_nofpueb-linux-uclibc toolchain. While the naming convention leaves quite a lot to be desired, it ensures that the ISA tuning is taken care of transparently (though it is still possible to manually tune the ISA via -Wa,-isa= if for some reason some deviation is necessary). Transparent tuning will give us the best results when building anything other than the kernel where we don't want to bother with explicit ISA tuning.