Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
On Tue, Apr 15, 2014 at 12:43:42PM -0700, Dennis Ferguson wrote: > > I'm pretty sure NetBSD could never run on a 68000 since the 68000 > had no memory management unit. The 68010 and 68020 didn't have memory > management units either, but Sun did proprietary MMUs for both (that's > sun2 and sun3, respectively) and I think other companies may have done > MMUs for the 68020. The 68030 was the first CPU in the series to come > with an MMU built in. ISTR that either (or both) of the 68000 or 68010 don't save enough state to make all address faults recoverable. This stops you running OS that do paging - so you could only run OS that swap entire processes. The '020 saves the mid-instruction state for some faults (as well as the actual fault reason) so they can be recovered. (Just don't continue on a cpu with a different mask level.) David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
Dennis, while the MC68020 did not have an MMU onboard there where Motorola PMMUs out there (MC68851). In the beginning there was an FPGA solution that emulated a subset of the MC68851 PMMU via the Coprocessor interface. Later when the PMMU became available it was also used in designs. E. g. I put an XC68851 (pre-production sample) into my Mac II around 1988 and could run A/UX (or whatever it was called). Early versions of NetBSD did work too. So there was some 'common' MMU support for the '20 via the PMMU coprocessor support. Sun had it's own MMU, though. The MC68851 came late to the market, that's probably the cause why so many non-Motorola solutions existed for the 68020. Frank On 04/15/14 21:43, Dennis Ferguson wrote: On 15 Apr, 2014, at 05:14 , Izumi Tsutsui wrote: - NetBSD/x68k supports only X680x0 machines with MC68030 and higher processors. - Normal X68000 machines (i.e. all X680x0 except X68030) have MC68000, so 030 accelerators are required for the X68000 models, i.e. XVI, SUPER, EXPERT, PRO, and ACE. (BTW the normal X68030 has MC68EC030 so users also have to replace its CPU to with MC68030 to use NetBSD/x68k) - On the other hand, probably early x68k developers considered that some stupid users could try to boot NetBSD/x68k on X68000 without 030 and bootloaders should have some sanity checks. I'm pretty sure NetBSD could never run on a 68000 since the 68000 had no memory management unit. The 68010 and 68020 didn't have memory management units either, but Sun did proprietary MMUs for both (that's sun2 and sun3, respectively) and I think other companies may have done MMUs for the 68020. The 68030 was the first CPU in the series to come with an MMU built in. That generic x68x requires a 68030 makes sense since that's the first CPU where the code can count on knowing how the MMU works. A 68020 would have a manufacturer-specific MMU, while for the 68010 there is only sun2. There is no reason to restrict the instruction set to that of the 68000 in any case since NetBSD won't run on that. I once had a 68000 board that ran a 4.3 BSD kernel, but it was a 4.3 BSD kernel with all the process scheduling hacked out so that it ran exactly 1 compiled-in "user space" process, without memory protection. I used it as an ntp server. Dennis Ferguson
Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
martin@ wrote: > It doesn't really matter for .S files, as long as the code does not mutate > due to ifdefs - or am I missing something? Just FYI, as(1) converts "jbsr [LABEL]" lines into "jsr [absolute address]" with -m68000, and "bsrl [relative address]" with -m68020. The latter is not supported by 68000/010. (and probably faster on 020 and later?) --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
dennis wrote: > That generic x68x requires a 68030 makes sense since that's the first > CPU where the code can count on knowing how the MMU works. Well, it's not a guess but the design of NetBSD/x68k. > A 68020 > would have a manufacturer-specific MMU, Note there is Motorola MC68851 PMMU for 68020 and some hp300 and mac68k machines have it (and we support them). > There is no reason to restrict the instruction set to > that of the 68000 in any case since NetBSD won't run on that. In this prinary bootloader case, 68000 was intended to be supported to print "wrong MPU" warning for users, while it isn't implemented yet. Actually X68000 EXPERT (emulated by XM6i) can run the primary boot_ustar in NetBSD/x68k 6.1.3 boot floppy and it loads the secondary boot. (though it fails in the secondary boot without proper warning yet) Anyway, >> AFLAGS+= -Wa,-march=m68000 -Wa,-mcpu=m68000 works both with gcc 4.5 and 4.8 (and same binaries are generated) so I'll put it back to the Makefile. --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
On 15 Apr, 2014, at 05:14 , Izumi Tsutsui wrote: > - NetBSD/x68k supports only X680x0 machines with MC68030 and higher > processors. > > - Normal X68000 machines (i.e. all X680x0 except X68030) have MC68000, > so 030 accelerators are required for the X68000 models, i.e. > XVI, SUPER, EXPERT, PRO, and ACE. > > (BTW the normal X68030 has MC68EC030 so users also have to replace > its CPU to with MC68030 to use NetBSD/x68k) > > - On the other hand, probably early x68k developers considered > that some stupid users could try to boot NetBSD/x68k on X68000 > without 030 and bootloaders should have some sanity checks. I'm pretty sure NetBSD could never run on a 68000 since the 68000 had no memory management unit. The 68010 and 68020 didn't have memory management units either, but Sun did proprietary MMUs for both (that's sun2 and sun3, respectively) and I think other companies may have done MMUs for the 68020. The 68030 was the first CPU in the series to come with an MMU built in. That generic x68x requires a 68030 makes sense since that's the first CPU where the code can count on knowing how the MMU works. A 68020 would have a manufacturer-specific MMU, while for the 68010 there is only sun2. There is no reason to restrict the instruction set to that of the 68000 in any case since NetBSD won't run on that. I once had a 68000 board that ran a 4.3 BSD kernel, but it was a 4.3 BSD kernel with all the process scheduling hacked out so that it ran exactly 1 compiled-in "user space" process, without memory protection. I used it as an ntp server. Dennis Ferguson
Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
mrg@ wrote:
> Martin Husemann writes:
> > On Tue, Apr 15, 2014 at 04:51:29PM +1000, matthew green wrote:
> > > hmmm this option is now called -march=68000.
I don't think this is correct.
> > > i don't think any
> > > x68k are 68000 are they? all 020/030/040? perhaps using
> > > -mcpu=m68020 here might be best? i would test some and see if
> > > size or speed matters any.
In this case, it looks 68000 was intended to be supported.
(see below)
> > It doesn't really matter for .S files, as long as the code does not mutate
> > due to ifdefs - or am I missing something?
Probably as(1) might do some optimization or instruction replacement
per the specified processor (addressing, branch ranges etc).
> i think it matters because as(1) might reject stuff otherwise,
> but i would imagine that the defaults for m68k are ok defaults
> for x68k port, so maybe this option going away is fine.
Here is my guess:
- NetBSD/x68k supports only X680x0 machines with MC68030 and higher
processors.
- Normal X68000 machines (i.e. all X680x0 except X68030) have MC68000,
so 030 accelerators are required for the X68000 models, i.e.
XVI, SUPER, EXPERT, PRO, and ACE.
(BTW the normal X68030 has MC68EC030 so users also have to replace
its CPU to with MC68030 to use NetBSD/x68k)
- On the other hand, probably early x68k developers considered
that some stupid users could try to boot NetBSD/x68k on X68000
without 030 and bootloaders should have some sanity checks.
- All primary bootloaders except the boot_ustar have 020 checks:
http://nxr.netbsd.org/xref/src/sys/arch/x68k/stand/boot_ufs/boot.S?r=1.10#65
but the boot_ustar (for boot floppy) doesn't due to size restriction,
so -mc68000 was intentionally specified for it:
http://mail-index.netbsd.org/source-changes/2001/10/01/0037.html
- However, the secondary boot doesn't have proper 68000 check (yet?):
http://nxr.netbsd.org/xref/src/sys/arch/x68k/stand/boot/srt0.S?r=1.2#60
Nowadays all (aged) X680x0 geeks know it won't work on normal X68000,
so probably it's safe to remove it.
(I'm not sure if -mc68000 actually emits different code though)
Note a possible change in gcc 4.8 that causes this trouble is:
http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/m68k/m68k.c?annotate=173256#l482
I guess that gcc 4.5 passes only explicitly specified -m680x0
(which seems equivalent to -march=m680x0) options
(i.e. as(1) will use its default -mcpu), but gcc 4.8 always passes
both -march and -mcpu per the specified -m options to gcc(1)
("m68k_cpu_entry" is always set?) so passing only -Wa,-m[c]680x0
on gcc 4.8 makes as(1) complain arch vs cpu mismatch.
That's the reason why passing both -march=m68030 and -mcpu=m68030
solves build failure on mvme68k 060 kernels with both gcc 4.5 and 4.8.
In this boot_ustar case, passing only -Wa,-mcpu=m68000 fails with gcc 4.5,
and passing only -Wa,-march=m68000 (or -Wa,-m68030) fails with gcc 4.8.
---
Izumi Tsutsui
re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
Martin Husemann writes: > On Tue, Apr 15, 2014 at 04:51:29PM +1000, matthew green wrote: > > hmmm this option is now called -march=68000. i don't think any > > x68k are 68000 are they? all 020/030/040? perhaps using > > -mcpu=m68020 here might be best? i would test some and see if > > size or speed matters any. > > It doesn't really matter for .S files, as long as the code does not mutate > due to ifdefs - or am I missing something? i think it matters because as(1) might reject stuff otherwise, but i would imagine that the defaults for m68k are ok defaults for x68k port, so maybe this option going away is fine. .mrg.
Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
On Tue, Apr 15, 2014 at 04:51:29PM +1000, matthew green wrote: > hmmm this option is now called -march=68000. i don't think any > x68k are 68000 are they? all 020/030/040? perhaps using > -mcpu=m68020 here might be best? i would test some and see if > size or speed matters any. It doesn't really matter for .S files, as long as the code does not mutate due to ifdefs - or am I missing something? Martin
re: CVS commit: src/sys/arch/x68k/stand/boot_ustar
"Tetsuya Isaki" writes: > Module Name: src > Committed By: isaki > Date: Mon Apr 14 14:24:27 UTC 2014 > > Modified Files: > src/sys/arch/x68k/stand/boot_ustar: Makefile > > Log Message: > Remove -mc68000 asm option for GCC4.8 (or new binutils?). > With this option, new gcc complains that "boot_ustar.S:21: Error: > selected processor does not have all features of selected architecture". > I'm not sure about the essence of this error, but this option maybe > not needed because there is no need to consider about 68000 here. hmmm this option is now called -march=68000. i don't think any x68k are 68000 are they? all 020/030/040? perhaps using -mcpu=m68020 here might be best? i would test some and see if size or speed matters any. .mrg.
