TC and memory

[Paulo]

Hi

I have a need to use memory directly but at a fixed address and must be accessible by various apps (and scripts)
which pretty much rules out using 'malloc'.

Writing to and reading from a fixed location is the easy part and I have decided to use 0x7C00 to 0x7DFF which is the first stage OS boot sector
copied to RAM and used before control is passed to the kernel and thus no longer needed.
However this is only 512 bytes long and I need a bit more so been thinking of also using the area used by the Real Mode Interrupt Vector Table
which will give me another 1024 bytes.

My question then is:
Does TC make use of or ever goes back to Real Mode (or BIOS after booting) for anything including changing screen resolution?
I don't expect that it would but thought it wiser to double check with those that know more about these things.

Thanks.

[curaga]

You're trying to access the RAM behind the kernel's back - that will end up blowing up

It sounds like you're doing a driver in userspace for something that needs DMA at that address. In that case, you should get a kernel driver.
Alternatively, you could try restricting the kernel's access with the mem boot option.

If this is not a driver, but merely IPC (inter-process communication), there are much saner ways.


edit: Our kernel reserves the first 64kb for BIOS use, but then you'd be going behind the back of the BIOS.

[Paulo]

Hi curaga

You're trying to access the RAM behind the kernel's back - that will end up blowing up

Normally I would agree with you, but remember that the address range/s I want to use are never touched by the kernel anyway, certainly not the first stage loader.
I can't see the kernel allocating this to a process.

It sounds like you're doing a driver in userspace for something that needs DMA at that address. In that case, you should get a kernel driver.

In a round about way, yes.
What I'm actually doing is reading external data and writing it to RAM as fast as possible.
I'm using assembler to maximize speed and minimize overheads associated with higher level languages.
It's a simple logic analyzer to capture some "glitches" and it just seems that making a kernel driver is quite a long winded way of doing it.
The reasons I'm trying to avoid a kernel driver is due to my limited knowledge of them and the fact that if a kernel driver goes bonkers for whatever reason, it pretty much
takes the kernel with it whereas in userspace that won't happen.

If this is not a driver, but merely IPC (inter-process communication), there are much saner ways.

I suppose in a way it could be classified as IPC and my motivation for using direct memory access is partly to learn and partly because I need the speed.
I would however, be very interested in other methods that maybe available for IPC.

EDIT:

In reply to your edit,

edit: Our kernel reserves the first 64kb for BIOS use, but then you'd be going behind the back of the BIOS.

But does TC make use of BIOS at all after booting?

[Rich]

Hi Paulo
Curaga is right. This is a very bad idea, not just because you are essentially deceiving the kernel, but because there
are simpler ways to accomplish this.

I have a need to use memory directly but at a fixed address and must be accessible by various apps (and scripts)
which pretty much rules out using 'malloc'.

If you believe that, it's time to re-examine the architecture of your project.

It's a simple logic analyzer to capture some "glitches" ...

So you need to watch for a trigger condition, and start collecting data once it's met. This is the "real time" part of your
application. Then there is the post processing (display, instruction dis-assembly, histograms, whatever) which does
not have to occur in "real time".
For the first part, you most certainly can malloc the RAM you need and use that. Or you can declare a local block of
RAM as part of your program, with luck, it will all fit in the processors cache. Once the data has been captured, you
save it to a file, and then the post processing can be handled.

[Paulo]

Hi Rich

What you and curaga say does make sense, however I as thinking of doing the project in two parts.

1) The "real time" part in either C or ASM, haven't quite decided yet.

2) The "non real time" display stuff in gtkdialog as it's very versatile and easy to make a nice GUI.

Since I'm not a sadomasochist, I don't intent making a GUI in either C or ASM hence the gtkdialog part.
However this creates a bit of a problem as when the first pgm terminates after writing data to memory using malloc,
the memory allocated will also be reclaimed and thus lost.
Hence my idea of writing to a non-used portion of RAM, then I'm free to read it with any other binary or script.

Am I missing something here?

[bmarkus]

Am I missing something here?

What you are missing is LINUX itself. You are planning a program for a bare system without considering the operating system. For example LINUX provides interprocess communication mechanisms.

[Rich]

Hi Paulo

Am I missing something here?

Yes you are, read:

For the first part, you most certainly can malloc the RAM you need and use that. Or you can declare a local block of
RAM as part of your program, with luck, it will all fit in the processors cache. Once the data has been captured, you
save it to a file, and then the post processing can be handled

Prior to terminating, you save the contents of the capture buffer to a file.

[bmarkus]

WHy to hack an operating system when it offers solution?

[Paulo]

Good thing I'm wearing my fire proof suit   

OK, I relent, saving to a file it is.
I just thought the whole idea of Linux was being able to experiment with different ways of doing things
even if some of them may be a bit unorthodox.

I'm still curious though if TC does use BIOS/Real Mode in any way.

[Rich]

Hi Paulo

I'm still curious though if TC does use BIOS/Real Mode in any way.

I think the Linux kernel in general pretty much ignores the BIOS. I have an old machine from around 1997 or so with
a 320Gbyte hard drive in it. I set that drive to be non existent in the BIOS setup because the machine couldn't boot
with a drive that large present, and TInycore finds and mounts it anyway. As far as applications are concerned, maybe
wine uses it, I don't know. I've know that Xorg or one of the video driver packages has an int10 module, and the Xorg
development packages contain xf86int10.h.

I just thought the whole idea of Linux was being able to experiment with different ways of doing things
even if some of them may be a bit unorthodox.

You are of course free to experiment, but unorthodox solutions are best saved for when an orthodox solution does
not exist.

[tinypoodle]

I'm still curious though if TC does use BIOS/Real Mode in any way.

The closest to that I could think of would be elksemu, but I suspect that won't work with the Core stock kernel:

Code: [Select]

# CONFIG_BINFMT_MISC is not set
http://linux.die.net/man/1/elks
https://github.com/lkundrak/dev86/tree/master/elksemu

[Paulo]

Hi Rich

I think the Linux kernel in general pretty much ignores the BIOS

My thoughts as well.

As far as applications are concerned, maybe
wine uses it, I don't know.

Never used Wine myself, but if it's anything like XP, then BIOS functions are emulated via the NTVM
and not the real BIOS.
In fact I have found quite a few dependencies between real BIOS and the way Microsoft thinks it should be implemented.

I've know that Xorg or one of the video driver packages has an int10 module, and the Xorg
development packages contain xf86int10.h.

Very interesting.
Surely there must be quite a performance hit going back and forth between PM and RM?

You are of course free to experiment, but unorthodox solutions are best saved for when an orthodox solution does
not exist.

Fair enough.
I did do some experimenting just for fun and the section reserved for the first stage boot loader seems OK to mess about with but I will
use a file to save the memory block allocated by calling 'malloc'.

Thanks for the answers.

[Rich]

Hi Paulo
Another advantage to saving to a file is your capture program can save the data in whatever format is convenient for
the post processing program using fprintf, be it binary, hex, ASCII, or something else.

[Paulo]

Hi tinypoodle

Never heard of ELKS before but looks very interesting.
Still have an old 286 knocking about somewhere, maybe it's just the thing for it.

[Paulo]

Hi Rich

Another advantage to saving to a file is your capture program can save the data in whatever format is convenient for
the post processing program using fprintf, be it binary, hex, ASCII, or something else.

Microsoft Excel format?
Only kidding, but yes good point, it will make life easier when it comes to displaying the data.
Never used fprintf in C, only printf, will investigate fprintf.