[MiNT] FreeMiNT for ColdFire: Generic - was: XaAES

[m0n0 <ole@monochrom.net>]

Am Dienstag, den 17.05.2011, 09:33 +0200 schrieb Stefan Niestegge 
<beetle@abbuc.de>:

> > The kernel still has to be fully patched (mainly the "arch" subdir), 
> > the various modules have to be checked and maybe patched, same story 
> > for the tools...
> > I'm going to continue!
> Understood. Thanks and thumbs up for the good work! Keep going!

I want to mention the following,... from my point of view it is an big 
problem.
Maybe I'm just to confused ;) And I don't want Vincent to repeat 
everything he already told about it.
However, I try to explain - don't take everything here for the real 
thing..., I'm just getting into it...

With the firebee we have 2 optional low-level systems. Options: a.) the 
BaS b.) dbug.
Both of them hide the real hardware and put the TOS into an Hardware 
environment which looks like the one of the falcon
(and it's ready to have a go... "everything" is initialized etc...) .
If you want to access hardware - that's maybe possible. Vincent said: 
"just do it as you would do it - it will work"
- I'm not sure what Vincent meant with that - because I would do it as 
the Coldfire Manual tells me, but maybe he thought
I would do it as I would do it with my Falcon...

It's also possible to start the firebee without dbug / BaS. Drawback: 
no m68k compatibility, no hardware init. I could live without
the m68k compatibility, however - the early hardware init would be up 
to the EmuTOS. (That's the only TOS running without dbug/BaS).
(Altough the code is already present within FireTOS/BaS/dbug I assume 
something is blocking that code from beeing used within 
FreeMiNT/EmuTOS...)

Problems:
- Maybe the FPGA/BaS remamps memory Registers to the addresses where 
TOS expects the hardware - or does it mirror them?
- More critical: when running freemint on top of BaS/dbug/Firetos ( 
whooo,... there is so much low level stuff loading before MiNT )
  we don't have access to the Ethernet hardware... FireTOS/dbug already 
uses the Hardware - and dbug runs in Super-User mode - where
  MiNT doesn't run in SuperUser mode - and it will never run in super 
user mode with FireTOS/dbug/BaS. So there is no way to stop
  dbug from using the Network hardware. It's not an option to use the 
lwip stack as network hardware - because that would mean 2 stacks
  stacked together. Maybe it would be an option if there is an gateway 
to low-level LWIP packet functions,... However, the upper
  layer of lwip probably expects these packets to be passed to it's own 
upper layer.
- In generally you are free to do with an kernel what/where you want to 
do... with Firebee this doesn't seem to be possible. That's possibly ok
as long as you don't need priviled instructions & don't want to use 
custom coldfire drivers... - but what I find more
complicated is the fact that there is already some low-level task 
running which prevents me from accessing the Network Hardware...  (If 
you would ask me,
I would just shutdown these LWIP tasks, but freemint kernel has no 
right to do that and even if it would, it would need to know how to do 
that).

I know this is chaotic... sorry guys.

So there are different directions for FreeMiNT:

FreeMiNT with FireTOS/dbug
FreeMiNT with FireTOS/BaS
FreeMiNT with EmuTOS/BaS
FreeMiNT with EmuTOS  ( totally native, no access restrictions, full 
access to hardware - sounds good, 'eh? ;) -
but the EMUTOS code misses a lot which is expected to be there when 
FreeMiNT boot's up.... , like MMU setup)

I guess some FreeMiNT kernel guru will answer this mail, clarify 
everything and give us direction ;)

Greets,
m