OSDev.org

Hello Gurus,
In my setup, Linux runs on the BSP of my dual core cpu and a tiny simple OS runs on the AP core with its own reserved memory, IDT and GDT. No paging. AP code can see all the memory.

There is an inexpensive PCI-X card on the system which is memory mapped (This card asks for 1MB mem space, but does not have any on-board memory).

I'm discarding the original driver and writing a new one. This driver would write some data in the base addr mentioned in BAR0 of this card and send a fixed-vector IPI to the AP core. The Intr handler in AP for this vector should be able to read the data written in the above base addr.

Will the following scheme work for the above requirement?
1. In the tiny kernel running on AP core, statically allocate the memspace requirement sizing BAR0. (e.g long driverMem[4 MB])
2. Point this allocated memory to the device's base address (e.g. *baseAddr = driverMem)

If this won't work, is there a correct or better way to do it?
Thanks for your time.

Hi,

sawdust wrote:There is an inexpensive PCI-X card on the system which is memory mapped (This card asks for 1MB mem space, but does not have any on-board memory).

If this mysterious PCI-X card doesn't have any onboard memory, then can I assume it needs 1 MB of physical address space for memory mapped I/O? It's the only sane assumption I can make (otherwise the PCI-X card wouldn't be memory mapped in the first place).

sawdust wrote:I'm discarding the original driver and writing a new one. This driver would write some data in the base addr mentioned in BAR0 of this card and send a fixed-vector IPI to the AP core.

Do you mean the driver would write some data to the card's registers that are mapped into the physical address space at the address mentioned in BAR0? What do these registers do, and why are your writing data to them?

Why does the device driver send a fixed-vector IPI to the AP core, and what does this have to do with the PCI-X device?

Can't you just do whatever the original device driver did?

sawdust wrote:Will the following scheme work for the above requirement?
1. In the tiny kernel running on AP core, statically allocate the memspace requirement sizing BAR0. (e.g long driverMem[4 MB])
2. Point this allocated memory to the device's base address (e.g. *baseAddr = driverMem)

I'm trying to clean the insulation off of the wires inside the walls of my house, because the karma from this insulation is starting to annoy my chickens and the noise from these annoyed chickens make the trees grow too fast.

Will the following scheme work for the above requirement?
1. Buy a goat and turn the goat inside-out
2. Wear the inside-out goat like a hat
3. Run in circles chanting "Oooba! Oooba!"

sawdust wrote:If this won't work, is there a correct or better way to do it?

What exactly are you trying to do (and have you tried rubbing mayonnaise on the PCI-X card)?


Cheers,

Brendan

Brendan wrote: Do you mean the driver would write some data to the card's registers that are mapped into the physical address space at the address mentioned in BAR0? What do these registers do, and why are your writing data to them?

Why does the device driver send a fixed-vector IPI to the AP core, and what does this have to do with the PCI-X device?

Can't you just do whatever the original device driver did?

I'm only using this pci card as a place-holder to get pci resources. Not using the card otherwise.

Brendan wrote: 1. Buy a goat and turn the goat inside-out
2. Wear the inside-out goat like a hat
3. Run in circles chanting "Oooba! Oooba!"

HeHe.. I admire your sense of humor very much

Brendan wrote: What exactly are you trying to do (and have you tried rubbing mayonnaise on the PCI-X card)?

Honestly, I have no goal in mind. Just trying to hack-around and learn things like many people do. Is it wrong to try something unconventional?

Thanks anyways.

Maybe I'm being uncommonly thick but I can't understand the permise of your post. AP core? BSP (which is not referring to Binary Space Partitioning)?

BSP stands for Bootstrap Processor, which is the processor which executes the BIOS, the Bootloader and the OS and AP stands for Application processor. The APs are the processors that are just 'hlt'ed by the BIOS and that are waiting to be started by an OS that supports multiple processors.

edit: btw. why are you posting in this thread even if you don't know what it is about? I am feeling a tendency among some newer forum members towards "posting without knowing", but that might just be me...

It was of my opinion that his post was extremely poorly explained and I wanted him to post more stuff. Besides what's this 'newer member' stuff. I've been here for ages - just not posting.

edit: And I suspect Brendan has no clue what the guy is on about either.

Hi,

ucosty wrote:edit: And I suspect Brendan has no clue what the guy is on about either.

You're mostly right - the original questions in this topic make no sense at all, but I was sent an email requesting an answer and obliged in the best way I could.

However, I do have some background knowledge about what Sawdust is trying to do. The background knowledge is that Sawdust is trying to implement a type of OS that runs on one CPU while Linux runs on another, with a type of device driver built into Linux so that his OS and Linux can communicate. For some reason this is hardware specific code (not general purpose code that could work on other CPUs/motherboards) and needs to use LinuxBIOS, which makes it very difficult to debug and test. I have no idea what the reason is for it or what it'd be used for (other than he says he's hoping to get some sort of grant for it if/when it works).

I assume he's trying to figure out how to get his OS and Linux to communicate, needs some sort of buffer that's shared between the Linux driver and his OS for this communication, and is allocating some RAM for this buffer from within Linux and trying to find a way to tell his OS the address of this buffer.

However, I have no idea what this has to do with any PCI-X card, or why the Linux driver for his OS needs any physical device (except RAM and CPU/s). I'm guessing he's misusing PCI configuration space as a way to tell his OS the address of the communication buffer, without considering how his OS can reliably access PCI configuration space without causing re-entrancy problems (without some sort of lock, both OSs could be trying to use the PCI configuration space "address" and "data" I/O ports at the same time and stuffing each other's PCI configuration space accesses up).

I think the general problem may be that Linux assumes it has complete control of the computer and therefore his OS can't have control over anything, except for things that can be hidden from Linux by hacking the firmware (e.g. make LinuxBIOS generate MP specification tables and/or ACPI tables that don't include one of the CPUs, and modify the memory map passed from LinuxBIOS to Linux so that Linux doesn't know about some RAM).

In general (based on some assumptions and guessing what the real questions are) he should using a fixed address in RAM to tell his OS where this buffer is.

If this isn't possible for some reason then using IPIs alone can work (by sending IPIs from the Linux driver to his OS): with 2 interrupt vectors (e.g. interrupt 0x80 and interrupt 0x81) you can send one bit per IPI, and would need to send a sequence of 32 IPIs for 32-bits. If the address of the communication buffer is aligned, then you wouldn't need to send the full 32-bits (e.g. only send 20 bits if it's aligned on a page boundary because you know the lowest 12 bits are zero).

With 32 interrupt vectors you can send 5 bits per IPI (e.g. interrupt 0x80 = 00000b, interrupt 0x81 = 00001b, interrupt 0x82 = 00010b, ..., interrupt 0x9E = 11110b, interrupt 0x9F = 11111b) and you'd only need to send 4 IPIs from Linux to his OS to tell his OS the 20 most significant bits of a page aligned communication buffer.


Cheers,

Brendan

Wouldn't it be easier to use a userspace linux type of job to get linux and your OS to cooperate?