* [RFC] C64 DTS
@ 2018-11-18 16:39 Geert Uytterhoeven
2018-11-18 19:10 ` Linus Walleij
2018-11-18 21:28 ` Wolfram Sang
0 siblings, 2 replies; 5+ messages in thread
From: Geert Uytterhoeven @ 2018-11-18 16:39 UTC (permalink / raw)
To: devicetree; +Cc: Wolfram Sang, Linus Walleij, Matt Porter, Geert Uytterhoeven
Hi all,
Sometimes it's just fun to apply modern practices to old hardware.
Hence below is an attempt to write a DTS for the Commodore 64.
DT binding documentation is not yet included.
Thanks for your comments ;-)
---8<-------------------------------------------------------------------
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
/* FIXME <dt-bindings/6502.h> */
#define CPU_IRQ 0
#define CPU_NMI 1
/ {
model = "Commodore 64";
compatible = "cbm,c64";
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&cpu>;
color_clock: color_clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <17734472>; // PAL
};
dot_clock: dot_clock {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clock-div = <9>;
clock-mul = <4>;
clocks = <&color_clock>;
};
phi0: phi0_clock {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clock-div = <8>;
clock-mul = <1>;
clocks = <&dot_clock>;
};
phi2: phi2_clock {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clock-div = <1>;
clock-mul = <1>;
clocks = <&phi0>;
};
ps_freq: ps_freq {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <50>;
};
cpus {
#address-cells = <0>;
#size-cells = <0>;
cpu: cpu {
device_type = "cpu";
compatible = "cbm,6510", "mos,6502";
clock-frequency = <985000>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
};
};
// FIXME sub-node with ranges to describe bank switching
// cbm,loram-gpios = <&cpu 0 GPIO_ACTIVE_LOW>,
// cbm,hiram-gpios = <&cpu 1 GPIO_ACTIVE_LOW>,
// cbm,charen-gpios = <&cpu 2 GPIO_ACTIVE_LOW>,
ram: memory@0 {
device_type = "memory";
reg = <0 0x10000>;
};
basic_rom: memory@a000 {
reg = <0xa000 0x2000>;
// FIXME ROM, reserved
};
character_rom: memory@d000 {
reg = <0xd000 0x1000>;
// FIXME ROM, reserved
};
vic: video-controller@d000 {
reg = <0xd000 0x400>;
compatible = "cbm,6569", "cbm,vic-ii"; // PAL
clocks = <&color_clock>, <&dot_clock>;
clock-names = "color", "dot";
interrupts = <CPU_IRQ>;
cbm,vic-bank-gpios = <&cia2 0 GPIO_ACTIVE_HIGH>,
<&cia2 1 GPIO_ACTIVE_HIGH>;
};
sid: sound@d400 {
reg = <0xd400 0x400>;
compatible = "cbm,6581", "cbm,sid";
};
color_ram: memory@d800 {
reg = <0xd800 0x400>;
// FIXME Nibble RAM, reserved
};
cia1: system-controller@dc00 {
reg = <0xdc00 0x100>;
compatible = "cbm,6526", "mos,cia";
#clock-cells = <0>; // CNT
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
clocks = <&phi2>, <&ps_freq>;
clock-names = "phi2", "tod";
interrupts = <CPU_IRQ>;
};
cia2: system-controller@dd00 {
reg = <0xdd00 0x100>;
compatible = "cbm,6526", "mos,cia";
#clock-cells = <0>; // CNT
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
clocks = <&phi2>, <&ps_freq>;
clock-names = "phi2", "tod";
interrupts = <CPU_IRQ>;
};
kernal_rom: memory@e000 {
reg = <0xe000 0x2000>;
// FIXME ROM, reserved
};
keyboard {
compatible = "cbm,c64-keyboard", "gpio-matrix-keypad";
col-gpios = <&cia1 0 GPIO_ACTIVE_HIGH>,
<&cia1 1 GPIO_ACTIVE_HIGH>,
<&cia1 2 GPIO_ACTIVE_HIGH>,
<&cia1 3 GPIO_ACTIVE_HIGH>,
<&cia1 4 GPIO_ACTIVE_HIGH>,
<&cia1 5 GPIO_ACTIVE_HIGH>,
<&cia1 6 GPIO_ACTIVE_HIGH>,
<&cia1 7 GPIO_ACTIVE_HIGH>;
row-gpios = <&cia1 8 GPIO_ACTIVE_HIGH>,
<&cia1 9 GPIO_ACTIVE_HIGH>,
<&cia1 10 GPIO_ACTIVE_HIGH>,
<&cia1 11 GPIO_ACTIVE_HIGH>,
<&cia1 12 GPIO_ACTIVE_HIGH>,
<&cia1 13 GPIO_ACTIVE_HIGH>,
<&cia1 14 GPIO_ACTIVE_HIGH>,
<&cia1 15 GPIO_ACTIVE_HIGH>;
interrupts = <CPU_NMI>;
linux,keymap = <0 /* FIXME */>;
};
iec {
compatible = "cbm,c64-iec-bus";
cbm,atn-gpios = <&cia2 3 GPIO_ACTIVE_LOW>;
cbm,clock-out-gpios = <&cia2 4 GPIO_ACTIVE_LOW>;
cbm,data-out-gpios = <&cia2 5 GPIO_ACTIVE_LOW>;
cbm,clock-in-gpios = <&cia2 6 GPIO_ACTIVE_LOW>;
cbm,data-in-gpios = <&cia2 7 GPIO_ACTIVE_LOW>;
};
};
------------------------------------------------------------------->8---
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [RFC] C64 DTS
2018-11-18 16:39 [RFC] C64 DTS Geert Uytterhoeven
@ 2018-11-18 19:10 ` Linus Walleij
2018-11-18 20:15 ` Geert Uytterhoeven
2018-11-18 21:28 ` Wolfram Sang
1 sibling, 1 reply; 5+ messages in thread
From: Linus Walleij @ 2018-11-18 19:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Wolfram Sang, Matt Porter
On Sun, Nov 18, 2018 at 5:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Sometimes it's just fun to apply modern practices to old hardware.
>
> Hence below is an attempt to write a DTS for the Commodore 64.
> DT binding documentation is not yet included.
>
> Thanks for your comments ;-)
It is useful not only for nostalgic reasons but because many
people have deep understanding of this hardware and thus
it becomes a reference example that many people can
grasp when learning device tree.
> cpus {
> #address-cells = <0>;
> #size-cells = <0>;
>
> cpu: cpu {
> device_type = "cpu";
> compatible = "cbm,6510", "mos,6502";
> clock-frequency = <985000>;
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <1>;
> };
> };
This looks correct.
I think the SA110/SA1100/SA1110 ARMs may need to have a
similar GPIO controller jitted with the CPU since they are
so tightly coupled. This IRQ is active low I would however
suggest having it twocell and explicitly state all clients as
active low on the flag as that gives a better understanding
of the connections.
> basic_rom: memory@a000 {
> reg = <0xa000 0x2000>;
> // FIXME ROM, reserved
> };
>
> character_rom: memory@d000 {
> reg = <0xd000 0x1000>;
> // FIXME ROM, reserved
> };
Use mtd-physmap with "mtd-rom" right?
Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> vic: video-controller@d000 {
> reg = <0xd000 0x400>;
> compatible = "cbm,6569", "cbm,vic-ii"; // PAL
> clocks = <&color_clock>, <&dot_clock>;
> clock-names = "color", "dot";
> interrupts = <CPU_IRQ>;
>
> cbm,vic-bank-gpios = <&cia2 0 GPIO_ACTIVE_HIGH>,
> <&cia2 1 GPIO_ACTIVE_HIGH>;
> };
The interrupts all need to be requested as shared as
for a generic OS all IRQ handlers would need to get
called to figure out which hardware fired it. But I guess
we see that as a OS problem altogether.
> color_ram: memory@d800 {
> reg = <0xd800 0x400>;
> // FIXME Nibble RAM, reserved
> };
This is an "interesting" RAM type.
The upper nibble in each byte can be successfully sampled and used
as enthropy source as it picks up radio interference from
the surrounding universe.
> cia1: system-controller@dc00 {
> reg = <0xdc00 0x100>;
> compatible = "cbm,6526", "mos,cia";
> #clock-cells = <0>; // CNT
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <1>;
> clocks = <&phi2>, <&ps_freq>;
> clock-names = "phi2", "tod";
> interrupts = <CPU_IRQ>;
> };
I'm going back and forth whether this should be an MFD
or not. It has a crowd of subdevices, including RTC,
clocksource, clockevent, GPIO, IRQ controller, UART
also parallel port with a shift register (IIRC).
It is also possible to let several subdriver bind to this
one node.
So I'm uncertain :/
> keyboard {
> compatible = "cbm,c64-keyboard", "gpio-matrix-keypad";
>
> col-gpios = <&cia1 0 GPIO_ACTIVE_HIGH>,
> <&cia1 1 GPIO_ACTIVE_HIGH>,
> <&cia1 2 GPIO_ACTIVE_HIGH>,
> <&cia1 3 GPIO_ACTIVE_HIGH>,
> <&cia1 4 GPIO_ACTIVE_HIGH>,
> <&cia1 5 GPIO_ACTIVE_HIGH>,
> <&cia1 6 GPIO_ACTIVE_HIGH>,
> <&cia1 7 GPIO_ACTIVE_HIGH>;
> row-gpios = <&cia1 8 GPIO_ACTIVE_HIGH>,
> <&cia1 9 GPIO_ACTIVE_HIGH>,
> <&cia1 10 GPIO_ACTIVE_HIGH>,
> <&cia1 11 GPIO_ACTIVE_HIGH>,
> <&cia1 12 GPIO_ACTIVE_HIGH>,
> <&cia1 13 GPIO_ACTIVE_HIGH>,
> <&cia1 14 GPIO_ACTIVE_HIGH>,
> <&cia1 15 GPIO_ACTIVE_HIGH>;
Uncertain about active high here. Or open drain?
> interrupts = <CPU_NMI>;
I don't think it's advisible to use the NMI for the keyboard.
> iec {
> compatible = "cbm,c64-iec-bus";
>
> cbm,atn-gpios = <&cia2 3 GPIO_ACTIVE_LOW>;
> cbm,clock-out-gpios = <&cia2 4 GPIO_ACTIVE_LOW>;
> cbm,data-out-gpios = <&cia2 5 GPIO_ACTIVE_LOW>;
> cbm,clock-in-gpios = <&cia2 6 GPIO_ACTIVE_LOW>;
> cbm,data-in-gpios = <&cia2 7 GPIO_ACTIVE_LOW>;
> };
Whether it is C64 or not doesn't really matter, the
compatible should be something like "gpio-iece-bus"
in analogy with "gpio-leds" etc.
I'm not the smartest guy with the best memory but doesn't
IEC mandate that some of the lines be used as open drain?
So you need to tag on GPIO_LINE_OPEN_DRAIN where
appropriate on these lines.
The 6526 GPIO will emulate open drain output by switching
the line into output mode (which is what the Linux gpiolib
does with lines like that if it can't find a special register for
open drain). I imagine this is how it was
used but have no reference for it...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [RFC] C64 DTS
2018-11-18 19:10 ` Linus Walleij
@ 2018-11-18 20:15 ` Geert Uytterhoeven
2018-11-19 14:37 ` Linus Walleij
0 siblings, 1 reply; 5+ messages in thread
From: Geert Uytterhoeven @ 2018-11-18 20:15 UTC (permalink / raw)
To: Linus Walleij
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Wolfram Sang, Matt Porter
Hi Linus,
On Sun, Nov 18, 2018 at 8:10 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sun, Nov 18, 2018 at 5:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Sometimes it's just fun to apply modern practices to old hardware.
> >
> > Hence below is an attempt to write a DTS for the Commodore 64.
> > DT binding documentation is not yet included.
> >
> > Thanks for your comments ;-)
>
> It is useful not only for nostalgic reasons but because many
> people have deep understanding of this hardware and thus
> it becomes a reference example that many people can
> grasp when learning device tree.
True.
> > cpus {
> > #address-cells = <0>;
> > #size-cells = <0>;
> >
> > cpu: cpu {
> > device_type = "cpu";
> > compatible = "cbm,6510", "mos,6502";
> > clock-frequency = <985000>;
> > gpio-controller;
> > #gpio-cells = <2>;
> > interrupt-controller;
> > #interrupt-cells = <1>;
> > };
> > };
>
> This looks correct.
>
> I think the SA110/SA1100/SA1110 ARMs may need to have a
> similar GPIO controller jitted with the CPU since they are
> so tightly coupled. This IRQ is active low I would however
> suggest having it twocell and explicitly state all clients as
> active low on the flag as that gives a better understanding
> of the connections.
OK.
> > basic_rom: memory@a000 {
> > reg = <0xa000 0x2000>;
> > // FIXME ROM, reserved
> > };
> >
> > character_rom: memory@d000 {
> > reg = <0xd000 0x1000>;
> > // FIXME ROM, reserved
> > };
>
> Use mtd-physmap with "mtd-rom" right?
> Documentation/devicetree/bindings/mtd/mtd-physmap.txt
OK, so just e.g. rom@a000 with a compatible value of "mtd-rom"?
At first I thought mtd-physmap would be a solution for the bank switching,
but that turned out to be untrue ;-)
> > cia1: system-controller@dc00 {
> > reg = <0xdc00 0x100>;
> > compatible = "cbm,6526", "mos,cia";
> > #clock-cells = <0>; // CNT
> > gpio-controller;
> > #gpio-cells = <2>;
> > interrupt-controller;
> > #interrupt-cells = <1>;
> > clocks = <&phi2>, <&ps_freq>;
> > clock-names = "phi2", "tod";
> > interrupts = <CPU_IRQ>;
> > };
>
> I'm going back and forth whether this should be an MFD
> or not. It has a crowd of subdevices, including RTC,
> clocksource, clockevent, GPIO, IRQ controller, UART
> also parallel port with a shift register (IIRC).
>
> It is also possible to let several subdriver bind to this
> one node.
>
> So I'm uncertain :/
Personally, I don't like MFD in DT (akin "simple-mfd"), but prefer a single
node describing all of it.
BTW, the interrupts property of cia2 was not correct, as it is tied to NMI,
not IRQ.
>> > keyboard {
> > compatible = "cbm,c64-keyboard", "gpio-matrix-keypad";
> >
> > col-gpios = <&cia1 0 GPIO_ACTIVE_HIGH>,
> > <&cia1 1 GPIO_ACTIVE_HIGH>,
> > <&cia1 2 GPIO_ACTIVE_HIGH>,
> > <&cia1 3 GPIO_ACTIVE_HIGH>,
> > <&cia1 4 GPIO_ACTIVE_HIGH>,
> > <&cia1 5 GPIO_ACTIVE_HIGH>,
> > <&cia1 6 GPIO_ACTIVE_HIGH>,
> > <&cia1 7 GPIO_ACTIVE_HIGH>;
> > row-gpios = <&cia1 8 GPIO_ACTIVE_HIGH>,
> > <&cia1 9 GPIO_ACTIVE_HIGH>,
> > <&cia1 10 GPIO_ACTIVE_HIGH>,
> > <&cia1 11 GPIO_ACTIVE_HIGH>,
> > <&cia1 12 GPIO_ACTIVE_HIGH>,
> > <&cia1 13 GPIO_ACTIVE_HIGH>,
> > <&cia1 14 GPIO_ACTIVE_HIGH>,
> > <&cia1 15 GPIO_ACTIVE_HIGH>;
>
> Uncertain about active high here. Or open drain?
They're just standard totem-pole outputs.
No need for open drain on a keyboard scanning matrix (unless
it's also used for other purposes).
> > interrupts = <CPU_NMI>;
>
> I don't think it's advisible to use the NMI for the keyboard.
The RESTORE key is wired to the NMI line.
But it is indeed the 65th key, separate from the matrix scanning.
So it makes sense to leave it out here, and drop the "cbm,c64-keyboard"
compatible value.
BTW, how do you describe a separate button connected to an NMI line?
Or just omit it completely? Reset buttons are usually not described neither.
> > iec {
> > compatible = "cbm,c64-iec-bus";
> >
> > cbm,atn-gpios = <&cia2 3 GPIO_ACTIVE_LOW>;
> > cbm,clock-out-gpios = <&cia2 4 GPIO_ACTIVE_LOW>;
> > cbm,data-out-gpios = <&cia2 5 GPIO_ACTIVE_LOW>;
> > cbm,clock-in-gpios = <&cia2 6 GPIO_ACTIVE_LOW>;
> > cbm,data-in-gpios = <&cia2 7 GPIO_ACTIVE_LOW>;
> > };
>
> Whether it is C64 or not doesn't really matter, the
> compatible should be something like "gpio-iece-bus"
> in analogy with "gpio-leds" etc.
Correct.
> I'm not the smartest guy with the best memory but doesn't
> IEC mandate that some of the lines be used as open drain?
> So you need to tag on GPIO_LINE_OPEN_DRAIN where
> appropriate on these lines.
>
> The 6526 GPIO will emulate open drain output by switching
> the line into output mode (which is what the Linux gpiolib
> does with lines like that if it can't find a special register for
> open drain). I imagine this is how it was
> used but have no reference for it...
The {clock,data}-out lines are driving TTL open-collector buffers.
So combined with the {clock,data}-in lines, they're actually emulating
open-collector GPIOs.
So an IEC bus could be implemented using only 3 GPIOs, if two of
them can be configured as GPIO_LINE_OPEN_DRAIN.
Do you intend supporting the emulation of an open-collector GPIO in
gpiolib using a pair of GPIOs, so avoid implementing that in every
driver that may need it? ;-)
Thanks for the review!
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [RFC] C64 DTS
2018-11-18 20:15 ` Geert Uytterhoeven
@ 2018-11-19 14:37 ` Linus Walleij
0 siblings, 0 replies; 5+ messages in thread
From: Linus Walleij @ 2018-11-19 14:37 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Wolfram Sang, Matt Porter
On Sun, Nov 18, 2018 at 9:15 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> BTW, how do you describe a separate button connected to an NMI line?
> Or just omit it completely? Reset buttons are usually not described neither.
Just add it as a stand-alone button connected to the
NMI line of the interrupt controller. It's what it is after
all.
The ARM Juno board has an ordinary gpio button marked
"NMI". I think we should take that (in the input subsystem)
and configure it as a NMI (in ARM terms an "FIQ") but that
arch has a distinction where every IRQ line can be switched
between beeing IRQ or FIQ so it is quite different.
Anyways: NMI buttons is pretty common on some servers
I am told, I would look to x86 for an answer.
> The {clock,data}-out lines are driving TTL open-collector buffers.
> So combined with the {clock,data}-in lines, they're actually emulating
> open-collector GPIOs.
>
> So an IEC bus could be implemented using only 3 GPIOs, if two of
> them can be configured as GPIO_LINE_OPEN_DRAIN.
>
> Do you intend supporting the emulation of an open-collector GPIO in
> gpiolib using a pair of GPIOs, so avoid implementing that in every
> driver that may need it? ;-)
Somebody already suggested adding GPIOs on top of buffer
drivers in turn controlled by GPIO. So I think the answer is yes.
But it depends on this person implementing the code for it.
I can look up a reference if you're interested!
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] C64 DTS
2018-11-18 16:39 [RFC] C64 DTS Geert Uytterhoeven
2018-11-18 19:10 ` Linus Walleij
@ 2018-11-18 21:28 ` Wolfram Sang
1 sibling, 0 replies; 5+ messages in thread
From: Wolfram Sang @ 2018-11-18 21:28 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: devicetree, Linus Walleij, Matt Porter
[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]
Hi Geert,
> cpu: cpu {
> device_type = "cpu";
> compatible = "cbm,6510", "mos,6502";
I don't think mos,6502 will work. You will lose the data port at $00/$01
and can't configure memory then.
> clock-frequency = <985000>;
Can't this be derived from some other clock?
> sid: sound@d400 {
> reg = <0xd400 0x400>;
> compatible = "cbm,6581", "cbm,sid";
> };
Actually, this file should be a DTSI and VIC, SID, and CIA would need to
be defined in the DTS file. Different C64 models have different versions
of these chips.
> iec {
> compatible = "cbm,c64-iec-bus";
>
> cbm,atn-gpios = <&cia2 3 GPIO_ACTIVE_LOW>;
> cbm,clock-out-gpios = <&cia2 4 GPIO_ACTIVE_LOW>;
> cbm,data-out-gpios = <&cia2 5 GPIO_ACTIVE_LOW>;
> cbm,clock-in-gpios = <&cia2 6 GPIO_ACTIVE_LOW>;
> cbm,data-in-gpios = <&cia2 7 GPIO_ACTIVE_LOW>;
> };
The user port has lots of GPIOs, too :D And the tape port...
And you found out that CIA2 uses NMI already. I spotted that, too.
Geez, since when do I have too much time ;)
Happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-11-20 1:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-11-18 16:39 [RFC] C64 DTS Geert Uytterhoeven
2018-11-18 19:10 ` Linus Walleij
2018-11-18 20:15 ` Geert Uytterhoeven
2018-11-19 14:37 ` Linus Walleij
2018-11-18 21:28 ` Wolfram Sang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).