freemint-discuss

[Freemint-discuss] Ssystem( ) and ColdFire processors

[David G. <dga...@gm...>]

Hi,

while working on removing the M68040 machine flag for the ColdFire
build, I've found out that the Ssystem() system call (
http://toshyp.atari.org/en/00500e.html#Ssystem ) doesn't return
ColdFire information for the mode S_OSCOMPILE. This mode should return
the CPU type the kernel has been compiled for. Now a ColdFire kernel
returns 68040. I'd like to add the right ColdFire information.

The value returned is a 32 bit number which encodes the information like this:

0-7 Binary minor CPU ID
8-15 Binary major CPU ID
16-31 Reserved for future definition

The major CPU ID now only returns a 0x00 value and means m68k family.

1) First question. Should the ColdFire be included in this family or
should we add 0x01 value for the ColdFire family?

Here I'm for adding a new family.

The minor CPU ID means the exact CPU and the values are:

0x00 68000
0x0a 68010
0x14 68020
0x1e 68030
0x28 68040
0x3c 68060

Now the kernel returns values for the 68000, 68030, 68040 and the 68060

2) Second question. Which information do we give for the ColdFire processors?.

We can give:
a) the ISA classification (isaa, isab, isac, etc...).
b) the CPU names as given in the "-mcpu=" option in GCC (52xx, 53xx, 54xx, etc).
c) what it's called as micro-architecture by GCC (cfv1, cfv2, cfv3, cfv4, etc).

I'm for the ISA option but I don't have a strong opinion about it.

Later we should decide how this info is shown, it's not going to be
possible to be consistent with how it's done for the 680x0 family.

Re: [Freemint-discuss] Ssystem( ) and ColdFire processors

[Thorsten O. <ad...@th...>]

On Montag, 23. April 2018 16:33:05 CEST David Gálvez wrote:
> First question. Should the ColdFire be included in this family or
> should we add 0x01 value for the ColdFire family?

I don' think so. The reason is the same as why FireTOS does not set the _CPU 
cookie: The ColdFire just does not fit into this "level" scheme. And actually 
it is not real 68000 compatible, so not setting the cookie at all follows the 
logic of other cookies like not setting _VDO when no st-compatible video is 
present. 

>We can give:
>a) the ISA classification (isaa, isab, isac, etc...).
>b) the CPU names as given in the "-mcpu=" option in GCC (52xx, 53xx, 54xx, 
>etc).
>c) what it's called as micro-architecture by GCC (cfv1, cfv2, cfv3, cfv4, 
>etc).

The information for the actual system should already be present in the _MCF  
cookie. Using the compiler flags to setup similar information for the compile-
time options IMHO does not make much sense, as all the libraries are only 
compiled for -mcpu=5475.

Re: [Freemint-discuss] Ssystem( ) and ColdFire processors

[David G. <dga...@gm...>]

2018-04-23 17:26 GMT+02:00 Thorsten Otto <ad...@th...>:
>
> The information for the actual system should already be present in the _MCF
> cookie. Using the compiler flags to setup similar information for the
> compile-time options IMHO does not make much sense, as all the libraries are
> only compiled for -mcpu=5475.
>
I don't want to enter in if it makes sense or it doesn't make sense.
We have a system call that gives this information and now it's giving
it wrong for the ColdFire and I'd like to fix this. If I'm going to do
it I'd like to have in mind future additions to the platform, perhaps
support for the 54455 with a different instruction set (ISAC) than the
5475. Probably those addition are unrealistic but you never know what
this crazy people coding for old computers/systems will decide to do
;-)

Re: [Freemint-discuss] Ssystem( ) and ColdFire processors

[Thorsten O. <ad...@th...>]

On Montag, 23. April 2018 18:22:05 CEST David Gálvez wrote:
> We have a system call that gives this information and now it's giving
> it wrong for the ColdFire

Maybe. But then it was wrong also before the patch i guess. The problem with 
OS_OSCOMPILE is that it can return only a 32bit value, so you won't be able to 
squeeze all the possible isa names/cpu types/whatever for coldfire into it. 
The best thing would maybe to set the major cpu id to 1, as that, according to 
the documentation, would indicate a non-m68k processor. And maybe the core 
version (mcf_v1 etc.) into the minor id. But i would leave the remaining bits 
out, after all all that information is not really very useful for 
applications, as it only tells how the kernel was compiled, but nothing about 
the running system. And it also does not guarantee that all the drivers for 
example were compiled the same way.

Re: [Freemint-discuss] Ssystem( ) and ColdFire processors

[David G. <dga...@gm...>]

I've just commit the additions to Ssystem( ).
Major CPU ID will be 0x01 for the ColdFire processors.
And the minor ID for the ColdFire will be:
0x00 for isa_a
0x01 for isa_a+
0x02 for isa_b
0x03 for isa_c

Re: [Freemint-discuss] Ssystem( ) and ColdFire processors

[Vincent R. <vin...@fr...>]

On 23/04/2018 at 19:03, Thorsten Otto wrote:
> The best thing would maybe to set the major cpu id to 1, as that, according to
> the documentation, would indicate a non-m68k processor.

That makes sense.

Key point is: ColdFire is not 680x0.

In EmuTOS for ColdFire, I have even removed the _CPU cookie, as it 
doesn't make sense on a non-680x0 CPU.

But beware at something. The above is true for EmuTOS, where the CPU is 
pure ColdFire without any emulation.

But with FireTOS, the situation is different. The ColdFire is 
*partially* available

- user ColdFire instructions are available (not even fully true, as 
incompatible instruction such as move.b to stack are partially hacked to 
mimic 68000 behaviour)

- but ColdFire supervisor instructions are not available at all, hidden 
by the CF68KLib (remember that *all* programs running on FireTOS 
actually run in user mode, even when they think they have switched to 
supervisor)

In case of FireTOS, the _CPU cookie reflects what the *emulated* CPU is 
supposed to be. Maybe it should be the same for Ssystem(), that would 
make sense. Then provide new *documented* way to add information for 
ColdFire, which can't clash with any 680x0 values.

-- 
Vincent Rivière

Re: [Freemint-discuss] Ssystem( ) and ColdFire processors

[David G. <dga...@gm...>]

2018-04-25 0:21 GMT+02:00 Vincent Rivière <vin...@fr...>:
>
> In case of FireTOS, the _CPU cookie reflects what the *emulated* CPU is
> supposed to be. Maybe it should be the same for Ssystem(), that would make
> sense. Then provide new *documented* way to add information for ColdFire,
> which can't clash with any 680x0 values.
>

The information given by this system call is independent from the
machine you're running the kernel on, so it can be a bit confusing.
It's the option it was used to compile the kernel.
If you're using a 060 kernel with FireTOS it will return 68060 but if
you are using a 5475 kernel it will return a ColdFire kernel with
isa_b instruction set.
>From the documentation:
"This is not the same as the _CPU cookie value. The _CPU cookie
specifies the CPU physically present in the machine, while the
S_OSCOMPILE indicates the processor type selected at the time when the
system was compiled. In other words, running a 68000-compiled kernel
will return a 0x00 here, even if the machine is running 68040 or
something."

Re: [Freemint-discuss] Ssystem( ) and ColdFire processors

[David G. <dga...@gm...>]

2018-04-25 9:14 GMT+02:00 David Gálvez <dga...@gm...>:
>
>
> The information given by this system call is independent from the
> machine you're running the kernel on, so it can be a bit confusing.
> It's the option it was used to compile the kernel.
> If you're using a 060 kernel with FireTOS it will return 68060 but if
> you are using a 5475 kernel it will return a ColdFire kernel with
> isa_b instruction set.
> From the documentation:
> "This is not the same as the _CPU cookie value. The _CPU cookie
> specifies the CPU physically present in the machine, while the
> S_OSCOMPILE indicates the processor type selected at the time when the
> system was compiled. In other words, running a 68000-compiled kernel
> will return a 0x00 here, even if the machine is running 68040 or
> something."

I've just had a real situation where to know some compile time flags
has been useful.
I was testing transferring files to/from a USB device with a kernel
with -DOLDTOSFS flag, after doing some transfers (it's a 100 MB zip
file and through the ROM-port it takes some minutes) I wasn't sure if
I loaded the right kernel, then I remember that a XaAES's menu option
shows the flags the kernel running has been built with, and I saw that
it was the wrong kernel, without the -DOLDTOSFS flag.