I/O Buffer question

RaduP

Re: I/O Buffer question

« Reply #10 on: 06 / April / 2009, 20:27:53 »

Advertisements

ewavr, why would the JPG buffer need to be 19M when the RAW buffer is just a little over 7MB? Maybe most of it is not used, or used for I/O.
Either way, I hope I get a broken camera tomorrow, and I will do some experiments with it.

Logged

reyalp

13880

Re: I/O Buffer question

« Reply #11 on: 06 / April / 2009, 20:40:09 »

Quote from: RaduP on 06 / April / 2009, 20:22:37

Ok, so my original assumption was correct, there is more memory out there than the one taken by the main buffers.

Yes, each camera appears to be equipped with 32-128 megs of RAM, which is shared with frame buffers, program memory etc.

edit:
This memory appears at two different addresses, for cached and uncached access.

Quote

Some memory might not even be used, but it would not make sense not to use at least parts of it for i/o buffers To find out if it is used or not, I guess it can all be filled with data at startup, then read later on, after using the camera for a while, and see what memory didn't change. Of course, you can also go manually through 3MB worth of binary dumps and find out which memory is free.

Unless you exercise all the features of the camera, this is not a safe method.

You'd don't have to reverse the entire dump, you just have to figure out how the various parts are managed.

Quote

The reason why I don't like your idea is because you can't know for sure if the camera does some fancy things later on and allocates/changes more of the memory. The code you referenced in that thread is right near the beginning of the dump, but did you look through all the code to see if the camera talks again with the MPU? It is also possible that the camera has other memory areas that may or may not be allocable via the MPU, and it could use some DIGI specific ways, or maybe some I/O, or who knows what.

I got the memory region settings by querying CP15 while the while the camera is running. The results were identical to what the startup code sets. While it's possible there's other magic going on, there's nothing that suggests it. All indications are that the memory layout is set once at startup.

Finding all the instructions that manipulate CP15 registers related to memory regions would not be hard.

Logged

Don't forget what the H stands for.

RaduP

Re: I/O Buffer question

« Reply #12 on: 06 / April / 2009, 21:03:02 »

Well then, it seems that there is plenty of memory that can be used for all kind of neat things. Sure, it MIGHT get overwritten sometimes, but I would guess that for the most part (normal features) some of it can be used, and the features that overwrite it can be disabled.

Now, another question: Is the ROM code relocatable? Are there any portions that need to be changed if the code is moved somewhere else?

Logged

RaduP

Re: I/O Buffer question

« Reply #13 on: 08 / April / 2009, 19:21:50 »

Ok, after looking at some of the code and discussing with mx3, some of the code is NOT relocatable.
There is [admin: avoid swearing please] like ldr pc, constant.
I have no clue why that is there, and why the compiler didn't just generate a B instruction. Since all the instructions are the same size, and the jump location is (obviously) not outside the +/- 32MB limit, it should be relatively easy to have a program replace all that code with B.
Now, of course, there are two problems:
1. Cases where PC is not loaded with a direct constant.
2. Cases where data is intepreted as code.

But I think it could be done on a PC, where there are no memory or speed restrictions.

Logged