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

Re: [MiNT] Sparemint Coldfire

On 1/8/10 1:17 PM, Paul Wratt wrote:

(could not post this for 3 days now, bit late, but still relevant)

Great work Mark, and unfortunately I dont have anything to contribute
yet, soon hopefully (but hard without any hardware)

2010/1/3 Vincent Rivière<vincent.riviere@freesbee.fr>:

Mark Duckworth wrote:

In the coming weeks I will be rebuilding all of sparemint for coldfire.

Excellent. But it will be a lot of work.
The main problem is that the only compiler for ColdFire is GCC 4.x, most
SpareMiNT sources are really outdated. As I have already underlined, old
software often need some minor patches to be compatible with GCC 4.x.
We would probably have more chances to have a ColdFire distribution with
Alan's Gentoo which use up to date packages.
And also, there is the problem that the RPMs can't be cross-compiled...


Again, SRC2PKG should be able to do this no problem, unless you
specifically mean:
"v4e RPM's created with v4e RPM"
This allows cheats. As a platform we shouldn't allow the RPM build process to be cheated as it will contribute to overall neglect of things like the malloc bug which has plagued for so long. The RPM build process is easy and you can steal spec files from other platforms. 
I will be using m5474 arch and -mcpu=5474 cflag.  So a package for
coldfire will look like 'aalib-1.2-1.m5474mint.rpm.

Currently, we have 3 ColdFire processors around:
- The ACP computer use the MCF5474
- The Freescale evaluation boards use the MCF5484 and the MCF5485

All of these use a V4e core and are fully compatible. The only
differences are the clock speed and the additional hardware controllers
built into the processors.

The same compiler options can be used for all V4e processors. In the GCC
sources, the 5475 has been chosen arbitrarily as the default model for
the V4e family. For example, the m68k-linux use the 5475 CPU for the V4e
multilib. So I did the same in the m68k-atari-mint patches, and in the
MiNTLib, etc.

I really believe there are no differences by compiling with -mcpu=5474
or -mcpu=5475 or any other V4e CPU. I have explicitly verified that any
V4e CPU option links the correct V4e multilibs from the m5475 directory.
However it could be theoretically possible to write sources that behave
differently on specific processors by using specific defines, but I
really believe no one does that because there is no good reason.


would this not make more sense then:
aalib-1.2-1.m5474-v4e-mint.rpm
aalib-1.2-1.m5475-v4e-mint.rpm
aalib-1.2-1.v4e-mint.rpm
Maybe v4emint. Either way, if there is no vote on it, I'm just going to set it to what I think is best which is either m5474mint or v4emint. Probably v4emint 
So when compiling for ColdFire, I recommend using the -mcpu=5475 option
as it is the GCC default choice, until someone finds a difference
between the the different CPU models.




But if that doesn't work I'll be building everything on real coldfire
hardware depending on how far away Didier is from having firetos run without
cf68klib.

Note that thanks to the CF68KLib, FireTOS can run both 68000 and
ColdFire executables. Of course the ColdFire ones are faster. It could
be theoretically possible to run the standard 68000 EasyMiNT on FireTOS
on the evaluation boards, then to use GCC to build native ColdFire RPMs,
and progressively replace the 68000 binaries by ColdFire ones for
improved speed.


this looks like a good way to go, presuming that v4e does not need any
patches applied to source, or is that the point of the previous
comments, that it still needs minimal patching (compared to other 68k
variant output).

BTW: why is there still a need to patch is the source is C/C++, wasn't
that the point of another discussion re: ASM. I do however understand
the need to patch for GCC 4.x "strictness" due to the age of
sources...
It's a lot of explanation to explain this but numerous patches are needed to build typical unix packages on our platform due to subtle differences and missing features. A classic example was building git today. Git wants to use mmap which our system doesn't have due to lack of vm which means it must be coded around. Luckily someone already did this work and you just have to enable it. Then in the posix layer there is another problem. On almost every platform the __S_IFLNK octal for file permissions is defined as 0120000. On our platform it is defined as 0160000 which collides with a git cache type. So now I have to learn about posix, learn what we can change where to make this work. Most likely I'll be changing the octal value for the git cache which means a patch and it means that a tarred git repository may not work from our platform on linux and vice versa. This is the type of work that needs to be done to build each package. GCC 4.4.2 is much stricter than 2.95.3 which means builds will fail for things that worked before. This basically means that a lot of the software needs to be either updated or manually fixed patch by patch. Since I am working on sparemint for modern machines like coldari I will update ;)
Really with newer packages we will run even more into problems with missing features like dynamic loading, virtual memory. It will make porting the most recent software more challenging than it has been in the past. 

Thanks,
Mark