From: cross@spitfire.i.gajendra.net
In article <65c92373-e8b6-4d43-8e08-21af230b23f5n@googlegroups.com>,
muta...@gmail.com wrote:
>On Tuesday, April 4, 2023 at 2:07:30 AM UTC+8, Dan Cross wrote:
>
>> >I'm not using "mips open deliverables".
>
>> I'd re-read that if I were you. Note that they refer to the
>> _instruction set architecture_. You seem to be confused about
>> what precisely this citizen computer thing is actually referring
>> to: that is an implementation of a MIPS soft-core on an FPGA.
>> That's quite different from the ISA being in the public domain,
>> though.
>
>Again - copyright covers a work of art. Not an
>architectural concept. Patents could cover the later.
>But 20 years have passed.
You should probably take a law course focusing on intellectual
property before assuming that.
>I didn't say that "MIPS is a PD processor", if that even
>has a meaning.
>
>What I said is that the VHDL produced by the Plasma project
>has been released to the public domain.
>
>So we have a public domain CPU available. In my
>understanding of the law, the MIPS company can't
>stop me taking that VHDL to a manufacturer and
>getting chips produced, and selling them.
You should really take a couple of law courses, or better yet
consult with a qualified attorney, before making assumptions
here, _particularly_ regarding MIPS.
>That by itself wouldn't avoid patents though.
>
>But the 20 year wait has avoided patents.
Invest some time learning about the actual laws here, instead
of naively making assumptions.
>> >Note that we will be using PS/2 for the keyboard to
>> >avoid needing a USB stack.
>
>> Doesn't matter. That's only a small part of what you'd have to
>> write, and the impedence mismatch is large.
>
>What impedence mismatch?
Look it up.
>> Also note that on a lot of laptops, you don't actually have a
>> physical PS/2 keyboard controller. Rather, you have an emulator
>> that's implements a soft-PS/2 controller in proprietary code
>> that runs in SMM mode, but that is actually talking to a USB
>> keyboard on your behalf. If you yank the x86 CPU, you also lose
>> SMM mode (which is x86-specific) and you lose that capability.
>
>I think you have misunderstood what I asked for.
You seem to be acting as if one could simply slap together some
"laptop" components with an FPGA as a processor and have a
laptop, but that's not how those kinds of systems are built.
At a minimum, you'd have to design and fabricate a mainboard
in a laptop form-factor, ensuring that it could accommodate your
soft CPU/FPGA.
>I'm not talking about getting an existing laptop and swapping
>out the CPU.
>
>I'm talking about creating a new laptop based around a
>specific FPGA. Presumably high priced, and only of
>interest to hobbyists.
>
>With that proposal on the website I need to assemble my
>own desktop.
>
>I'd prefer to buy an expensive (within reason) laptop.
Such a thing doesn't exist. The closest thing is probably the
MNT Reform, which uses an ARM CPU. A system based on this FPGA
soft-core would have to be designed and built by a competent
engineer (and more likely by more than one such engineer).
>> >Jean-Marc has higher goals, but I'm only trying to get
>> >to a lower goal of getting a C compiler working.
>> >
>> >And after that a serial port to access the outside world.
>> >
>> >I've written a serial port driver before, for the 8086.
>> >It wasn't a lot of code.
>
>> That's only one of many things you'd have to write, and it's
>> relatively easy by comparison to many of the others.
>
>Could you give me say the 3 most difficult things to
>write for the proposed desktop?
Probably initializing the memory and cache controllers, then
DRAM training, and then IO topology initialization. Of course,
all of this is after loading an an initial bootstrap and before
the CPU is even out of reset.
>> Possibly, but it depends very much on the specific UART. Often,
>> these are embedded in the platform chipset, but you'll have to
>> know a lot about _that_ to make it all work. Very often you'd
>> have to fiddle with the platform's control apparatus in order to
>> configure the UART to respond to either MMIO accesses or legacy
>> IO accesses before doing either; usually the firmware does this
>> for you (and these days sometimes provides a BIOS emulation
>> layer). Doing this successfully requires a lot of experience
>> and patience.
>
>Ok, so the proposed laptop could be built, and cover both
>memory-mapped I/O and "legacy IO".
That would be a silly design if your intent is to work with a
CPU that doesn't even have programmed IO instructions, let alone
the sort of external bus cycles required for PIO to work.
>If it's a once-off software cost, that's fine. I'm more trying
>to get a flexible laptop than avoid code.
This is not how one does that.
>> >Or just split FPGA laptops into two broad categories?
>
>> Trying to rip a central component out of a tightly-integrated,
>> highly vertical system and replacing it with a completely
>> different component without significant re-design is just not
>> viable.
>
>The proposal was for a NEW tightly-integrated system.
This requires the capacity for absorbing quite a bit of
electrical and computer engineering knowledge, not to mention
electronics experience, to make it happen.
>TWO new systems in fact. In laptop form.
>
>Pre-made.
>
>If one is insufficient because of MMIO vs legacy.
>
>But it sounds like one is (probably) sufficient in
>conjunction with code.
These statements, in themselves, betray a lack of understanding
of the complexity involved.
What you want doesn't exist, and you have to actually have a lot
of real knowledge to build such a thing. Building a laptop
style system around an FPGA is non-trivial; certainly not the
type of thing a hobbyist with no domain knowledge is up to.
- Dan C.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
