ds84182
commented
8 years ago So here is how OpenArms does it:
struct value_s;
struct type_none {};
struct type_array {
int length;
struct value_s** values;
};
struct type_string {
int length;
const char *chars;
};
struct type_float {
float number;
};
struct type_integer {
int integer;
};
struct value_s {
int type;
union {
struct type_none none;
struct type_array array;
struct type_string string;
struct type_float number;
struct type_integer integer;
};
};
typedef struct value_s value;All values to and from OC use this structure (signals and components). For example, code to find and use a GPU is:
static void GPU_Set(char* address, int x, int y, char* str) {
value arguments;
arguments.type = TYPE_ARRAY;
arguments.array.length = 3;
value vx;
vx.type = TYPE_INTEGER;
vx.integer.integer = x;
value vy;
vy.type = TYPE_INTEGER;
vt.integer.integer = y;
value string;
string.type = TYPE_STRING;
string.string.chars = str;
string.string.length = strlen(str);
value* valuelist[3] = {&vx,&vy,&string};
arguments.array.values = valuelist;
// Inlines a call to the OC coprocessor which handles unboxing on the Java side
// Requests no output (NULL buffer with a size of 0)
COM_Invoke(address, "set", &arguments, NULL, 0);
}All these structures are located in main memory, and privilege mode checks are done by the coprocessor. OpenARMs used to use a MMIO interface combined with SVC calls, but it was quite hard to balance when making an OS with privileged execution modes. It's not the most efficient, but it gets the job done :sweat_smile:
Anyways...
This is a great idea because OpenGX uses a FIFO queue system to submit GPU commands, so this could allow for super efficient writing to its FIFO buffer on low level architectures.
fnuecke
iamgreaser
MaHuJa
gjgfuj
SaphireLattice
dsolmann
Friendly reminder that the spec here is out of date - see this URL for up-to-date spec (namely main.md): https://github.com/iamgreaser/hardbus-oc
LAST UPDATE: 2016-04-05 22:50 UTC
Dropping this here as I'm not sure who lurks on the forums and those who would actually understand what I'm asking for would already be over here. Still lots of room for discussion.
Because of the current date in a lot of places around the world, I have to also point out that this is a serious request.
I don't remember what the OC ARM project uses to communicate with the bus. OCMIPS does a call that looks a bit like this:
Translated it's more like this:
Not pictured: the code required to find the gpu, starring strncmp and memcpy.
Basically it's a pain in the arse to work with, from both the MIPS end and the Java end, and it gets even worse when one of the things that get returned code is a floating point number and you don't have floating point support available because, for a totally made-up example, you're writing code for the Linux kernel. (Project shelved for the time being, but that screenshot does make people think you're pulling their leg seeing as it's April Fools Day somewhere in the world. And yes, it still builds.)
It would be a lot more sensible to do something like this:
These are of course volatile, uncached hardware registers.
Which is fine for immediate, non-DMA data. A "set" command, on the other hand, does need DMA for maximum efficiency, but a non-DMA "setch" command would work just fine for architectures that don't have DMA at the time, especially if it autoincrements dx.
DMA facilities should be provided by the architecture, not by the hardware. There are notably fewer architecture types than component types.
Draft Proposal
This is based on how the MIPS data bus typically works, because it's reasonably simple and very flexible. Or at least how I think it works. This is also reminding me that I really need to refactor OCMIPS.
If there's something that sucks about it, please leave it in the comments and I can change it.
I'm pretty sure the ARM data bus works in a similar fashion. Probably the same for the 68000.
MMIO bus
Components shall provide these two functions to architectures (names are preliminary and subject to change):
It is REQUIRED that every byte of
maskprovided by the architecture is either0x00or0xFF. Real hardware would use a byte enable.It is NOT REQUIRED that the lower 2 bits of
addrare00. However, they can be ignored. The mask can also be ignored. Architecture authors MUST pass the appropriate address toaddrand mask tomask, even if it's unaligned.This may get chucked out like that section that was marked as "this may get chucked out"
Architectures should have access to a utilities API to convert addresses to masks:
These are completely optional and to be blunt very easy to implement yourself:
And of course
getHiMask8is completely useless, but provided for completeness.DMA
Components shall provide these functions to architectures:
Architectures shall provide these functions to components:
dmaChannelCountreturns the number of channels this component has. This function may be unnecessary.For
dmaSetChannel, anarc_chnof-1disables DMA for that channel.Either end can call
dmaAlertwhen they are ready to receive data.For
dmaWrite,sizeis either8,16, or32. Returnstrueif the data was accepted. The recipient can ignore the size, but the sender MUST provide it.It is good practice to keep writing to
dmaWriteuntil it returnsfalse.If DMA is not supported by a component, this will be an acceptable implementation:
If DMA is not supported by an architecture, this will be an acceptable implementation:
A component MUST NOT attempt DMA on an architecture channel that was not granted to it.
With that said, an architecture SHOULD handle such a case without catching fire. Ignoring it is the best outcome. Unless your aim is to make an easily exploitable system.
Interrupts
Components shall provide these two functions to architectures:
Architectures shall provide this function to components:
Interrupts from a component MUST only be fired from a valid token.
For
interruptSetToken,pinrefers to a pin on the component, not on the architecture. Iftokenis -1, this interrupt is disabled.Sidenote: If you are implementing a Z80 or 8080, the data that gets chucked on the data bus should be determined in the architecture implementation, not the component implementation.
Component headers for Plug 'n' Play bus
NOTE: This may actually be dropped from the spec and implemented in an architecture-dependent way.
Each component has a 256-byte structure as follows:
00 30 = zero-padded component address string (0x30 bytes) 30 0C = \ RESERVED 3C 04 = CRC-32 of address 40 30 = zero-padded component type string (0x30 bytes) 70 0C = \ RESERVED 7C 04 = CRC-32 of type 80 04 = HW API revision for this component (bump every time it changes, please!) 84 04 = MMIO address space size shift amount (size in bytes = 1<<[0x80]) 88 04 = DMA channel count 8C 04 = IRQ pin count 90 70 = \ RESERVED **
CRC-32 is as per zlib (0xEDB88320 right-shift Galois LFSR) and does not include the padding in its calculation.
OpenComputers should handle the header, all a component needs to do is provide the relevant fields - this does not include the CRC-32s, which will be handled by OC itself.
A component MUST NOT provide an address or type with NUL bytes (
"\x00"/ 0x00) within it.Endianness
The bus will be in little-endian.
If this is to be used by a big-endian architecture, it is up to the architecture to decide how this will even work. However, it will most likely require translating the mask field, and possibly the data field as well if the data value is not repeated over the bus.
Ideally the address SHOULD match the address fed to the component documentation. If this is the case, then the mask (and possibly the data) MUST be adjusted to suit.