Gryphon 68030 [message #761] |
Wed, 08 June 2016 13:57 |
lynchaj
Messages: 1017 Registered: June 2016
|
Senior Member |
|
|
Hi
Is anyone working on or still interested in the Gryphon 68030 SBC project?
Andrew Lynch
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Gryphon 68030 [message #774 is a reply to message #773] |
Sat, 11 June 2016 03:29 |
|
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Hi
Getting Linux booting may prove a pain if there is ROM at physical address 0; the kernel expects to be loaded here and expects the MMU disabled on boot.
The KISS-68030 gives us a solid 68K machine with MMU and DRAM already. Enhancements I would like to see in a future 68K board would be;
- 68040 or 68060 CPU at high clock speed
- Memory controller which makes use of the CPU's synchronous, pipeline and burst mode transfer features
- Support for DMA, primarily for ethernet and hard disk interfaces
I think the idea of exchanging GALs for a CPLD or FPGA is excellent. There is now a fully open-source toolchain for Lattice ICE40 FPGAs. I am told it is possible ("easy", some bravely claim!) to hand solder TQFP-144 packages so we could use a iCE40HX4K-TQ144, an inexpensive part with over 100 I/O pins. This, and the later 68K CPUs, would require the board to run on 3.3V.
It would be nice to have a keyboard and high-resolution video output although this could be on a peripheral board as I am very happy with a serial console.
W
[Updated on: Sat, 11 June 2016 03:32] Report message to a moderator
|
|
|
|
Re: Gryphon 68030 [message #781 is a reply to message #776] |
Sun, 12 June 2016 04:15 |
lynchaj
Messages: 1017 Registered: June 2016
|
Senior Member |
|
|
Hi
OK. I've been reading the above discussion and it sounds like there are two issues which need to be addressed before moving on to a more advanced prototype board. I am nearly complete with the recapture of the Gryphon version 1.1 schematic and will be posting it soon.
First, the ROM at address 0 is blocking progress on a Linux port. So modify the existing Gryphon design to add another 512K SRAM and some minimal glue logic to allow swapping of the Flash with the SRAM. It really is pretty trivial and the original N8VEM SBC has simple memory swapping circuit. We can use something like that.
Second, the build and test of the original Gryphon was not completed due to PCB problems and various debugging issues that Yoda discussed earlier. This needs to be accomplished so the later core CPU boards and IO boards have a reasonable chance of working.
So I propose a slightly revised plan going forward. Begin with building the existing Gryphon 1.1 plus swappable 512K SRAM + minor glue logic fixes. That can be made into a PCB which can be used to begin a Linux port while simultaneously completing the original Gryphon build and test cycle. It also recaptures the Gryphon EDA in KiCAD which I cannot emphasize enough is a huge and risky step by itself. Oh BTW, I have found there are a number of errors embedded in the original Gryphon 1.1 schematic so we still have to deal with verifying the basic design.
Next taking the results of the initial Linux port and completed build and test, prepare the updated Gryphon board with a small core CPU board and separate IO board. This would entail the CPLD changes, swapping out the DRAM glue from VT8242 to the 68030-KISS style logic, and creation of some sort of crude 68030 version of ISA bus. These are all huge changes and will take some time to lay them out properly. Some of this can be done in parallel with the Linux port and Gryphon 1.1 build and test.
I think this new approach breaks up the development into logical phases so we are not trying to make too many changes at once. Previous projects have done this and it results in a lot of non-working prototype boards and general frustration all around. Let's try a more modest, less risky, phased approach that allows different people to do different tasks in parallel.
Thanks
Andrew Lynch
[Updated on: Sun, 12 June 2016 04:21] Report message to a moderator
|
|
|
|
|
Re: Gryphon 68030 [message #784 is a reply to message #783] |
Sun, 12 June 2016 07:13 |
lynchaj
Messages: 1017 Registered: June 2016
|
Senior Member |
|
|
Hi Dave
OK looks good to go with the CPLD. I like the idea of some spare logic capacity since the 512K SRAM would require a bit of decoding and swap logic to get it to replace the Flash on command. My concern is to keep the project focused and not introduce too many changes at once or it will blow up into massive complexity. Lets get what we have working first and then modify something we know works. The bus, more advanced CPUs, DMA, etc. can wait for now.
While others are working on reviewing the schematics, making the CPLD changes, etc. I will start on replicating the Gryphon 1.0 PCB layout so we can verify part footprints. There will have to be some differences because the Gryphon specified parts like the stacked 9 pin dual male DB connectors which are unobtainium in KiCAD. Those will have to be replaced with single male DB9s.
Thanks
Andrew Lynch
PS, BTW do we really need 512KB Flash and 1024KB SRAM just to boot this thing? How about a 32KB EEPROM and a pair of 32KB skinny SRAMs instead? Pull the rest of the initialization data from external stores. It is something to consider and may simplify this design a bit -- possibly a 32KB EEPROM for boot only to bring in the DRAM and swap out the EEPROM for an all DRAM system.
[Updated on: Sun, 12 June 2016 07:25] Report message to a moderator
|
|
|
Re: Gryphon 68030 [message #785 is a reply to message #761] |
Sun, 12 June 2016 07:27 |
|
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Hey
On the memory map front: The ideal mapping for Linux would place 32-bit wide DRAM from physical address 0 upwards. Linux locates the kernel here at the bottom of physical memory so placing narrower RAM or less than about 16MB of RAM at 0 is likely to be a pain or limit performance (or both!).
32KB EEPROM would be enough to boot the system from disk I expect. Even my minimal ROMs for the KISS board are about 48KB, though, so I would prefer to see the 512KB ROM capability.
One thing confuses me -- why not start from the known-working KISS-68030 design, convert the GALs to a CPLD, possibly enlarge the board, and add new features to that? The KISS design is in KiCAD already. Starting with the known non-working Gryphon design, taking out the interesting features like DMA, bringing in the KISS memory controller etc, then fixing it until it works , just feels a bit like re-inventing something we already have?
W
[Updated on: Sun, 12 June 2016 07:28] Report message to a moderator
|
|
|
Re: Gryphon 68030 [message #786 is a reply to message #784] |
Sun, 12 June 2016 08:07 |
|
yoda
Messages: 125 Registered: October 2015 Location: Cedar Rapids, IA
|
Senior Member |
|
|
lynchaj wrote on Sun, 12 June 2016 09:13Hi Dave
OK looks good to go with the CPLD. I like the idea of some spare logic capacity since the 512K SRAM would require a bit of decoding and swap logic to get it to replace the Flash on command. My concern is to keep the project focused and not introduce too many changes at once or it will blow up into massive complexity. Lets get what we have working first and then modify something we know works. The bus, more advanced CPUs, DMA, etc. can wait for now.
The SRAM does not replace the Flash. Flash is mapped at the top of memory then the SRAM is mapped directly below it. DRAM is mapped from 0. The SRAM can be used for stack, variable scratch space and buffers.
Quote:
While others are working on reviewing the schematics, making the CPLD changes, etc. I will start on replicating the Gryphon 1.0 PCB layout so we can verify part footprints. There will have to be some differences because the Gryphon specified parts like the stacked 9 pin dual male DB connectors which are unobtainium in KiCAD. Those will have to be replaced with single male DB9s.
Thanks
Andrew Lynch
PS, BTW do we really need 512KB Flash and 1024KB SRAM just to boot this thing? How about a 32KB EEPROM and a pair of 32KB skinny SRAMs instead? Pull the rest of the initialization data from external stores. It is something to consider and may simplify this design a bit -- possibly a 32KB EEPROM for boot only to bring in the DRAM and swap out the EEPROM for an all DRAM system.
Yes keep the size. Paul and I did a very nice curses monitor that uses more than 32k and is/was growing.
|
|
|
Re: Gryphon 68030 [message #788 is a reply to message #785] |
Sun, 12 June 2016 10:19 |
|
yoda
Messages: 125 Registered: October 2015 Location: Cedar Rapids, IA
|
Senior Member |
|
|
will wrote on Sun, 12 June 2016 09:27Hey
On the memory map front: The ideal mapping for Linux would place 32-bit wide DRAM from physical address 0 upwards. Linux locates the kernel here at the bottom of physical memory so placing narrower RAM or less than about 16MB of RAM at 0 is likely to be a pain or limit performance (or both!.
I think that is the plan: To re-arrange the memory map from the original - it was non optimal
Quote:
32KB EEPROM would be enough to boot the system from disk I expect. Even my minimal ROMs for the KISS board are about 48KB, though, so I would prefer to see the 512KB ROM capability.
I think the original intent was to do other OSes besides Linux - so let's keep the Flash at least the same size - It requires a healthy size ROM to be able to run diagnostics on all the I/O on the board.
Quote:
One thing confuses me -- why not start from the known-working KISS-68030 design, convert the GALs to a CPLD, possibly enlarge the board, and add new features to that? The KISS design is in KiCAD already. Starting with the known non-working Gryphon design, taking out the interesting features like DMA, bringing in the KISS memory controller etc, then fixing it until it works , just feels a bit like re-inventing something we already have?
W
I think the intent is to preserve the Gryphon board as well. It was designed before KISS-68030 and did take a different approach. I think Paul wanted to run some type of Amiga OS as well as eventually Linux so let's not preclude those things from happening as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|