[PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Rich Felker]

Signed-off-by: Rich Felker <dalias@libc.org>
---
 arch/sh/boot/dts/j2_mimas_v2.dts | 98 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 98 insertions(+)
 create mode 100755 arch/sh/boot/dts/j2_mimas_v2.dts

diff --git a/arch/sh/boot/dts/j2_mimas_v2.dts b/arch/sh/boot/dts/j2_mimas_v2.dts
new file mode 100755
index 0000000..0d509f9
--- /dev/null
+++ b/arch/sh/boot/dts/j2_mimas_v2.dts
@@ -0,0 +1,98 @@
+/dts-v1/;
+
+/ {
+	compatible = "jcore,j2-soc";
+	model = "J2 FPGA SoC on Mimas v2 board";
+
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	interrupt-parent = <&aic>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "jcore,j2";
+			reg = < 0 >;
+			clock-frequency = < 50000000 >;
+		};
+	};
+
+	memory@10000000 {
+		device_type = "memory";
+		reg = < 0x10000000 0x4000000 >;
+	};
+
+	chosen {
+		stdout-path = "/soc@abcd0000/serial@100";
+	};
+
+	soc@abcd0000 {
+		compatible = "simple-bus";
+		ranges = <0 0xabcd0000 0x100000>;
+
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		aic: interrupt-controller {
+			compatible = "jcore,aic1";
+			reg = < 0x200 0x10 >;
+			cpu-offset = < 0x300 >;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		cache-controller {
+			compatible = "jcore,cache";
+			reg = < 0xc0 4 >;
+			cpu-offset = < 4 >;
+		};
+
+		timer {
+			compatible = "jcore,pit";
+			reg = < 0x200 0x30 >;
+			cpu-offset = < 0x300 >;
+			interrupts = < 0x48 >;
+		};
+
+		ethernet {
+			compatible = "jcore,emac";
+			reg = < 0x10000 0x2000 >;
+			//interrupts = < 0x60 >;
+			interrupts = < 0x11 >;
+		};
+
+		spi {
+			compatible = "jcore,spi2";
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			spi-max-frequency = <12500000>;
+
+			reg = < 0x40 0x8 >;
+
+			sdcard@1 {
+				compatible = "mmc-spi-slot";
+				reg = <0>;
+				spi-max-frequency = <12500000>;
+				voltage-ranges = <3200 3400>;
+				mode = <0>;
+			};
+		};
+
+		serial@100 {
+			clock-frequency = <125000000>;
+			compatible = "jcore,uartlite", "xlnx,xps-uartlite-1.00.a";
+			current-speed = <115200>;
+			device_type = "serial";
+			//interrupts = < 0x5d >;
+			interrupts = < 0x12 >;
+			port-number = <0>;
+			reg = < 0x100 0x10 >;
+		};
+	};
+};
-- 
2.8.1

Re: [PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Geert Uytterhoeven]

Hi Rich,

On Thu, Apr 7, 2016 at 5:01 PM, Rich Felker <dalias@libc.org> wrote:
> --- /dev/null
> +++ b/arch/sh/boot/dts/j2_mimas_v2.dts
> @@ -0,0 +1,98 @@
> +/dts-v1/;
> +
> +/ {
> +       compatible = "jcore,j2-soc";
> +       model = "J2 FPGA SoC on Mimas v2 board";
> +
> +       #address-cells = <1>;
> +       #size-cells = <1>;
> +
> +       interrupt-parent = <&aic>;
> +
> +       cpus {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               cpu@0 {
> +                       device_type = "cpu";
> +                       compatible = "jcore,j2";

This brings an interesting question: how do you plan to do IP core versioning?
I.e. which version of the HDL code does "jcore,j2" correspond to?


> +                       reg = < 0 >;
> +                       clock-frequency = < 50000000 >;
> +               };
> +       };

> +       chosen {
> +               stdout-path = "/soc@abcd0000/serial@100";

Adding a label to the serial node below would be useful, and allows
to simplify this to:

        stdout-path = &serial0;

> +       };

> +               serial@100 {

serial0: serial@100

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Rob Landley]

[Cross-posted to j-core mailing list.]

On 04/29/2016 01:58 AM, Geert Uytterhoeven wrote:
> Hi Rich,
> 
> On Thu, Apr 7, 2016 at 5:01 PM, Rich Felker <dalias@libc.org> wrote:
>> --- /dev/null
>> +++ b/arch/sh/boot/dts/j2_mimas_v2.dts
>> @@ -0,0 +1,98 @@
>> +/dts-v1/;
>> +
>> +/ {
>> +       compatible = "jcore,j2-soc";
>> +       model = "J2 FPGA SoC on Mimas v2 board";
>> +
>> +       #address-cells = <1>;
>> +       #size-cells = <1>;
>> +
>> +       interrupt-parent = <&aic>;
>> +
>> +       cpus {
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +
>> +               cpu@0 {
>> +                       device_type = "cpu";
>> +                       compatible = "jcore,j2";
> 
> This brings an interesting question: how do you plan to do IP core versioning?
> I.e. which version of the HDL code does "jcore,j2" correspond to?

J2 has a stable instruction set based on sh2 plus 2 backported sh3
barrel shift instructions and one added cmpxchg instruction. Other than
the cmpxchg (which was added last year when we started adding SMP
support) it's been stable for a couple years now. We're pondering a run
of ASICs, which sets it in stone, and don't expect any instruction set
changes between now and then. (That'll probably be our next kickstarter
after the turtle boards.)

Just today Jeff, Jen,and myself were researching the j3 roadmap. The sh3
patents expired in december, and we're thinking of implementing it
sometime in 2017.

The big new features sh3 (and sh3e) added are MMU, FPU, and DSP.

We're _not_ doing the DSP. (We have a better one of our own in the works
already, using a completely different instruction set. The sh3 DSP and
FPU instructions overlap anyway, let's just not go there.)

As for FPU: SH3 had 32 bit, SH4 had 64 bit, but we might just implement
both sizes at the same time in j3 since it's IEEE standard format and C
has "float" and "double". Not sure yet. If not, 64 bit would be in J4,
but we'll probably do both because IEEE-754 was published in 1985 so
it's out of patent regardless of the rest of superh.

The MMU is what most people will notice, so yes we're doing that. The
j-core j3 instruction set should give you a stock with-mmu Linux system.

There are only three new nonprivileged instructions: clrs and sets to
clear/set the S bit in the status register, and prefetch (which we might
just NOP because we do our own prefetch and the cache is only 8k each
for instruction and data). The rest are privileged instructions, so if
we decide to fiddle with them we'd just have to make sure the kernel
(and qemu) got updated to match. Userspace can avoid caring.

sh3 added 4 instructions each to load/set the SSR, SPC,and  Rn_BANK
registers. The first two are for "supervisor mode" which is necessary to
make the mmu privileged, the third is a register bank switching thing
sh3 did that may not actually be a good idea. (Rich, opinions?) We can
skip that (make it trap) if we decide it's a bad idea...

It also added "ldtbl" to load the translation lookaside buffer, which
Jeff is unhappy about (pointing out there isn't an instruction to load
the CPU cache; he doesn't like having mmu policy in the cpu), but we're
still looking into that part. We might do the MMU in a slightly
different way. (In a coprocessor. He says "The good thing about all this
is we get clean stuff up and do it the way it should have been done.")

So anyway, at this point new changes would go into j3 next year, which
would MOSTLY be sh3 compatible. And then j3 would get frozen when we do
a first run of asics, and we'd move on to j4.

Rob

Re: [PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Geert Uytterhoeven]

Hi Rob,

On Fri, Apr 29, 2016 at 10:56 AM, Rob Landley <rob@landley.net> wrote:
> On 04/29/2016 01:58 AM, Geert Uytterhoeven wrote:
>> On Thu, Apr 7, 2016 at 5:01 PM, Rich Felker <dalias@libc.org> wrote:
>>> --- /dev/null
>>> +++ b/arch/sh/boot/dts/j2_mimas_v2.dts
>>> @@ -0,0 +1,98 @@
>>> +/dts-v1/;
>>> +
>>> +/ {
>>> +       compatible = "jcore,j2-soc";
>>> +       model = "J2 FPGA SoC on Mimas v2 board";
>>> +
>>> +       #address-cells = <1>;
>>> +       #size-cells = <1>;
>>> +
>>> +       interrupt-parent = <&aic>;
>>> +
>>> +       cpus {
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>> +
>>> +               cpu@0 {
>>> +                       device_type = "cpu";
>>> +                       compatible = "jcore,j2";
>>
>> This brings an interesting question: how do you plan to do IP core versioning?
>> I.e. which version of the HDL code does "jcore,j2" correspond to?
>
> J2 has a stable instruction set based on sh2 plus 2 backported sh3
> barrel shift instructions and one added cmpxchg instruction. Other than
> the cmpxchg (which was added last year when we started adding SMP
> support) it's been stable for a couple years now. We're pondering a run
> of ASICs, which sets it in stone, and don't expect any instruction set
> changes between now and then. (That'll probably be our next kickstarter
> after the turtle boards.)

OK. So that's your answer for the CPU core.

What about the other IP cores, e.g. jcore,emac and jcore,spi2?
The latter already has a "2" suffix?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Rich Felker]

On Fri, Apr 29, 2016 at 08:58:44AM +0200, Geert Uytterhoeven wrote:
> Hi Rich,
> 
> On Thu, Apr 7, 2016 at 5:01 PM, Rich Felker <dalias@libc.org> wrote:
> > --- /dev/null
> > +++ b/arch/sh/boot/dts/j2_mimas_v2.dts
> > @@ -0,0 +1,98 @@
> > +/dts-v1/;
> > +
> > +/ {
> > +       compatible = "jcore,j2-soc";
> > +       model = "J2 FPGA SoC on Mimas v2 board";
> > +
> > +       #address-cells = <1>;
> > +       #size-cells = <1>;
> > +
> > +       interrupt-parent = <&aic>;
> > +
> > +       cpus {
> > +               #address-cells = <1>;
> > +               #size-cells = <0>;
> > +
> > +               cpu@0 {
> > +                       device_type = "cpu";
> > +                       compatible = "jcore,j2";
> 
> This brings an interesting question: how do you plan to do IP core versioning?
> I.e. which version of the HDL code does "jcore,j2" correspond to?

It's a question I'd like input on, because both the kernel driver
architecture and DT seem to have been designed with fixed hardware
devices in mind, not soft cores and updatable hardware.

For cpu nodes, I take the compatible tag mostly as just reflective of
the ISA and other broad cpu architecture characteristics. My intent in
the DT representation has been to factor out everything else, even
"L1" cache, as a separate device that can be represented on its own.
For example if you remove the cache node from the DT, the system will
boot with icache and dcache disabled (and will run really slow).

The main places it might be nice to know about specific cpu versions
are when new instructions are added, and when there are significances
in instruction timings that might matter to performance. But both of
these are cases where we'd probably want a public-facing name of some
sort (e.g. something like j2-rev2, j2+, ...) and the DT compatible tag
caan just be aligned with it.

For devices which have different generations with different
programming interfaces or capabilities the driver needs to know about,
I've done things like "aic1" vs "aic2", etc. Soon there will be "spi3"
for the (wip) spi master with a DMA-based interface.

Other than that, what to do about version details for the sake of
working around small bugs? It's complicated by the possibility that a
bug might even be caused by the bitstream generation for a particular
FPGA/board, not the source, so a source version might not even
suffice. My leaning for FPGA builds is just to put detailed soc-wide
board-target and version information in the top-level DT node (note:
once the DT bindings are official, DTB will be included in the boot
rom in the FPGA bitream) with the expectation that it's unlikely to be
used, but useful to have for bug reporting, etc., and that if you have
a buggy build, you should just fix/upgrade it rather than trying to
work around it on the kernel side. For future ASICs, OTOH, we should
probably coordinate having production-run-specific information in the
DT bindings in case there are bugs to be worked around.

Does this approach make sense? If so, it might make sense to write up
the ideas/rational as a proposal for inclusion in the DT docs, for
future soft-core projects to use as guidelines.

> > +                       reg = < 0 >;
> > +                       clock-frequency = < 50000000 >;
> > +               };
> > +       };
> 
> > +       chosen {
> > +               stdout-path = "/soc@abcd0000/serial@100";
> 
> Adding a label to the serial node below would be useful, and allows
> to simplify this to:
> 
>         stdout-path = &serial0;

OK.

> > +       };
> 
> > +               serial@100 {
> 
> serial0: serial@100

Looks good. Thanks for the comments and questions to lead discussion.

Rich

Re: [PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Rich Felker]

On Fri, Apr 29, 2016 at 11:20:02AM +0200, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Fri, Apr 29, 2016 at 10:56 AM, Rob Landley <rob@landley.net> wrote:
> > On 04/29/2016 01:58 AM, Geert Uytterhoeven wrote:
> >> On Thu, Apr 7, 2016 at 5:01 PM, Rich Felker <dalias@libc.org> wrote:
> >>> --- /dev/null
> >>> +++ b/arch/sh/boot/dts/j2_mimas_v2.dts
> >>> @@ -0,0 +1,98 @@
> >>> +/dts-v1/;
> >>> +
> >>> +/ {
> >>> +       compatible = "jcore,j2-soc";
> >>> +       model = "J2 FPGA SoC on Mimas v2 board";
> >>> +
> >>> +       #address-cells = <1>;
> >>> +       #size-cells = <1>;
> >>> +
> >>> +       interrupt-parent = <&aic>;
> >>> +
> >>> +       cpus {
> >>> +               #address-cells = <1>;
> >>> +               #size-cells = <0>;
> >>> +
> >>> +               cpu@0 {
> >>> +                       device_type = "cpu";
> >>> +                       compatible = "jcore,j2";
> >>
> >> This brings an interesting question: how do you plan to do IP core versioning?
> >> I.e. which version of the HDL code does "jcore,j2" correspond to?
> >
> > J2 has a stable instruction set based on sh2 plus 2 backported sh3
> > barrel shift instructions and one added cmpxchg instruction. Other than
> > the cmpxchg (which was added last year when we started adding SMP
> > support) it's been stable for a couple years now. We're pondering a run
> > of ASICs, which sets it in stone, and don't expect any instruction set
> > changes between now and then. (That'll probably be our next kickstarter
> > after the turtle boards.)
> 
> OK. So that's your answer for the CPU core.
> 
> What about the other IP cores, e.g. jcore,emac and jcore,spi2?
> The latter already has a "2" suffix?

We went through several rounds of ideas on how to name things, and the
one I'm trying to go with is trying to match, as closely as is
reasonable, the names and numbers used in the jcore source & repo
history. spi2 is the current generation of the spi controller and
there's a spi3 in the works that's dma-based. aic2 is the name that's
been used internally in all development discussion and in the source
for the new interrupt controller that supports a lot more irqs and
does not require configuration of their priorities. etc.

There's always the option to use completely new naming for a new
version of a device, like i486->pentium, etc. I don't think we have to
be completely committed to any particular naming/numbering scheme; we
just have to have names where it's clear what maps to what. And that's
why I opted for following the names from the source -- it's clear to
someone working with both the DT and the hw source what maps to what
(and soon the hw build process is going to be generating DTs from the
hw source, even).

Rich

Re: [PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Geert Uytterhoeven]

Hi Rich,

On Fri, Apr 29, 2016 at 6:06 PM, Rich Felker <dalias@libc.org> wrote:
> On Fri, Apr 29, 2016 at 08:58:44AM +0200, Geert Uytterhoeven wrote:
>> On Thu, Apr 7, 2016 at 5:01 PM, Rich Felker <dalias@libc.org> wrote:
>> > +               cpu@0 {
>> > +                       device_type = "cpu";
>> > +                       compatible = "jcore,j2";
>>
>> This brings an interesting question: how do you plan to do IP core versioning?
>> I.e. which version of the HDL code does "jcore,j2" correspond to?
>
> It's a question I'd like input on, because both the kernel driver
> architecture and DT seem to have been designed with fixed hardware
> devices in mind, not soft cores and updatable hardware.

The issue is not limited to softcores and updatablt hardware. Even for
normal SoCs of the same family, it's not guaranteed that two on-SoC
device with the same name and same documentation are identical revisions
of that device.

Of course you can fix hardware bugs and add hardware features on the
fly ;-)

> For cpu nodes, I take the compatible tag mostly as just reflective of
> the ISA and other broad cpu architecture characteristics. My intent in
> the DT representation has been to factor out everything else, even
> "L1" cache, as a separate device that can be represented on its own.
> For example if you remove the cache node from the DT, the system will
> boot with icache and dcache disabled (and will run really slow).

OK.

> The main places it might be nice to know about specific cpu versions
> are when new instructions are added, and when there are significances
> in instruction timings that might matter to performance. But both of
> these are cases where we'd probably want a public-facing name of some
> sort (e.g. something like j2-rev2, j2+, ...) and the DT compatible tag
> caan just be aligned with it.
>
> For devices which have different generations with different
> programming interfaces or capabilities the driver needs to know about,
> I've done things like "aic1" vs "aic2", etc. Soon there will be "spi3"
> for the (wip) spi master with a DMA-based interface.

OK.

> Other than that, what to do about version details for the sake of
> working around small bugs? It's complicated by the possibility that a
> bug might even be caused by the bitstream generation for a particular
> FPGA/board, not the source, so a source version might not even
> suffice. My leaning for FPGA builds is just to put detailed soc-wide
> board-target and version information in the top-level DT node (note:
> once the DT bindings are official, DTB will be included in the boot
> rom in the FPGA bitream) with the expectation that it's unlikely to be
> used, but useful to have for bug reporting, etc., and that if you have
> a buggy build, you should just fix/upgrade it rather than trying to
> work around it on the kernel side. For future ASICs, OTOH, we should
> probably coordinate having production-run-specific information in the
> DT bindings in case there are bugs to be worked around.

Hmm, I never considered the bitstream generation making a difference,
so e.g. having the git SHA1 ID for a component in a read-only hardware
registers is no longer sufficient to uniquely identify it.

> Does this approach make sense? If so, it might make sense to write up
> the ideas/rational as a proposal for inclusion in the DT docs, for
> future soft-core projects to use as guidelines.

Yes it does.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Rich Felker]

On Fri, Apr 29, 2016 at 10:10:40PM +0200, Geert Uytterhoeven wrote:
> > Other than that, what to do about version details for the sake of
> > working around small bugs? It's complicated by the possibility that a
> > bug might even be caused by the bitstream generation for a particular
> > FPGA/board, not the source, so a source version might not even
> > suffice. My leaning for FPGA builds is just to put detailed soc-wide
> > board-target and version information in the top-level DT node (note:
> > once the DT bindings are official, DTB will be included in the boot
> > rom in the FPGA bitream) with the expectation that it's unlikely to be
> > used, but useful to have for bug reporting, etc., and that if you have
> > a buggy build, you should just fix/upgrade it rather than trying to
> > work around it on the kernel side. For future ASICs, OTOH, we should
> > probably coordinate having production-run-specific information in the
> > DT bindings in case there are bugs to be worked around.
> 
> Hmm, I never considered the bitstream generation making a difference,

Supposedly Xilinx's tools are even nondeterministic if you run them in
multithreaded mode. I have not checked this, but given how awful ISE
is, I wouldn't be surprised if it's true.

In any case, certainly the version of the tools you use could make a
difference, just like the version of gcc/binutils you use makes a
difference to your output binaries for software.

> so e.g. having the git SHA1 ID for a component in a read-only hardware
> registers is no longer sufficient to uniquely identify it.

Indeed. I think you'd need to do something like sha1 the FPGA
configuration flash contents at runtime, or have a way of patching in
the hash to the bitstream after it's generated but before it's written
to flash.

> > Does this approach make sense? If so, it might make sense to write up
> > the ideas/rational as a proposal for inclusion in the DT docs, for
> > future soft-core projects to use as guidelines.
> 
> Yes it does.

Great. I don't think I'll get around to that step right away but it's
good to have planned.

Rich

Re: [PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Rob Landley]

On 04/29/2016 11:06 AM, Rich Felker wrote:
> The main places it might be nice to know about specific cpu versions
> are when new instructions are added, and when there are significances
> in instruction timings that might matter to performance. But both of
> these are cases where we'd probably want a public-facing name of some
> sort (e.g. something like j2-rev2, j2+, ...) and the DT compatible tag
> caan just be aligned with it.

My understanding is that the j2 instruction set is now frozen, j3 gets
frozen sometime next year, and j4 (probably) the year after that.

I believe the pending j4 issues are the rest of sh4 (non-privileged)
instruction support (there's like 6 more instructions? The printout with
the highlighter on it is at the office), 128 bit floating point, and 64
bit integer math.

Jeff was objecting this morning that our j2 is really "j23" (cherry
picking the barrel shifter out of sh3) and our j3 is really "j34"
(cherry picking 64 bit floating point out of sh4), but I really, really,
really don't want to explain that from a branding standpoint. :)

Rob

Re: [PATCH 7/7] sh: add device tree source for J2 FPGA on Mimas v2 board

[Rich Felker]

On Fri, Apr 29, 2016 at 03:56:32AM -0500, Rob Landley wrote:
> J2 has a stable instruction set based on sh2 plus 2 backported sh3
> barrel shift instructions and one added cmpxchg instruction. Other than
> the cmpxchg (which was added last year when we started adding SMP
> support) it's been stable for a couple years now. We're pondering a run
> of ASICs, which sets it in stone, and don't expect any instruction set
> changes between now and then. (That'll probably be our next kickstarter
> after the turtle boards.)
> 
> Just today Jeff, Jen,and myself were researching the j3 roadmap. The sh3
> patents expired in december, and we're thinking of implementing it
> sometime in 2017.
> 
> The big new features sh3 (and sh3e) added are MMU, FPU, and DSP.
> 
> We're _not_ doing the DSP. (We have a better one of our own in the works
> already, using a completely different instruction set. The sh3 DSP and
> FPU instructions overlap anyway, let's just not go there.)
> 
> As for FPU: SH3 had 32 bit, SH4 had 64 bit, but we might just implement
> both sizes at the same time in j3 since it's IEEE standard format and C
> has "float" and "double". Not sure yet. If not, 64 bit would be in J4,
> but we'll probably do both because IEEE-754 was published in 1985 so
> it's out of patent regardless of the rest of superh.

I think adding both at the same time is the right solution. Having
float but not double in hardware is clunky, and the only way gcc
supports this right now is by redefining double as an alias for float
rather than doing double with soft-fp code, which utterly breaks
software that expects IEEE double. We could teach gcc to do the right
thing, but that seems like wasted effort when we could instead spend
that effort making the hardware behave right.

> The MMU is what most people will notice, so yes we're doing that. The
> j-core j3 instruction set should give you a stock with-mmu Linux system.
> 
> There are only three new nonprivileged instructions: clrs and sets to
> clear/set the S bit in the status register, and prefetch (which we might
> just NOP because we do our own prefetch and the cache is only 8k each
> for instruction and data). The rest are privileged instructions, so if
> we decide to fiddle with them we'd just have to make sure the kernel
> (and qemu) got updated to match. Userspace can avoid caring.

Indeed.

> sh3 added 4 instructions each to load/set the SSR, SPC,and  Rn_BANK
> registers. The first two are for "supervisor mode" which is necessary to
> make the mmu privileged, the third is a register bank switching thing
> sh3 did that may not actually be a good idea. (Rich, opinions?) We can
> skip that (make it trap) if we decide it's a bad idea...

Without the bank registers the kernel entrypoint from userspace would
have to be redesigned I think. Unlike on nommu where some saved state
just gets thrown on the userspace stack at trap time, in order for the
mmu to actually provide protection guarantees you need to be able to
save and restore userspace register state without using storage that's
under userspace control. Register banks make that easy and efficient,
and the current sh3/sh4 entry.S depend on them.

> It also added "ldtbl" to load the translation lookaside buffer, which
> Jeff is unhappy about (pointing out there isn't an instruction to load
> the CPU cache; he doesn't like having mmu policy in the cpu), but we're
> still looking into that part. We might do the MMU in a slightly
> different way. (In a coprocessor. He says "The good thing about all this
> is we get clean stuff up and do it the way it should have been done.")

From the SH-4 docs I've seen, the TLB is both memory-mapped (in a zone
that's not subject to MMU mappings; note that these fixed zones
unfortunately limit the amount of memory you can map) and accessible
in a primitive way through the ldtbl instruction. So you could get by
without the insn and otherwise be compatible, I think.

However, if part of the long-term goal for j4 is being able to serve
as a drop-in replacement for sh4, it might make sense not to diverge
gratuitously -- at least to keep the design sufficiently close that
someone could hook up ldtbl to behave like on a legacy sh4 if they
wanted to.

Rich