| Message ID | 3784a31c12dc9c23c5c497786f503e1acafe64dd.1461880061.git.dalias@libc.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 >; + }; + }; +};
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