Does anyone know how to retrieve code from a Texas Instruments DSP processor? I'm using a TMS320LF2407 DSP, and I need to access the program on the chip, most likely using the JTAG connector. Any help would be appreciated. I've contacted TI, they were no help. I found SPRA830 that talks about using C code to copy blocks of program code to memory, but none of the associated files are available.
If you have access to the jtag then you should be able to connect to it with TI's Code Composer Studio. This also assumes that you have a supported JTAG emulator box which are fairly expensive. I think the biggest problem is going to be finding out what memory addresses are being used for code vs RAM. Can you give more details about what you're trying to do? Is this some specific hardware or is it an eval board?
Related
I'm trying to understand the userland part of the Raspberry Pi graphics driver code from https://github.com/raspberrypi/userland
My understanding so far is:
- a firmware blob runs in the GPU and offers an OpenGL-like interface which, on lower levels, is based on message (byte-array) passing on top of one of multiple 28-bit-word FIFOs called VCHIQ (the other VCHIQ queues are irrelevant for graphics)
- on the CPU part, OpenGL calls are turned into messages to the GPU. Access to the low-level facility (either the message queue or VCHIQ -- I haven't found that part yet in the code) requires a Linux kernel module, but no high-level logic happens in there.
- the GPU part is closed, but that's okay for my purposes. The (ARM) CPU part is, AFAIK, open
My ultimate goal is to get communication with the GPU working on bare metal (without Linux), but with the closed firmware blob intact. As a first goal, I want to understand how an OpenGL call is actually passed to the GPU. Anything beyond that is not part of this question.
However, I'm stuck at finding the actual code for this. The OpenGL calls use RPC_CALL* and in turn RPC_DO, which calls khronos_server_lock_func_table(). However, that function seems to be missing from the code, and to my surprise, I couldn't find anything useful about it on Google.
My questions:
- am I still on the ARM CPU side, or did I move to GPU land without noticing? If the latter is the case, where did I cross that line?
- Assuming I'm still on the CPU side -- where is the code for that function? Is it open at all, or do we actually have closed parts left around on the CPU side here? All sources on the web seem to indicate that the code for the CPU is 100% open.
- at which point does the implementation of the C OpenGL functions actually send a message to the GPU? I'm somewhat expecting a call to the kernel functionality that represents VCHIQ to be happening at some point, probably implemented as a device file.
I don't fully understand how do you intend to access the GPU without using Linux, and I am not that familiar with the technicalities, but some time ago I've been digging into the GPU for my private project so I'll tell you what I know.
The GPU is VideoCore IV and its documentation is available on Broadcom's website.
Also, on the Raspberry Pi Wiki you can see on the picture on the left that VCHIQ is in the kernel driver, so you might look for the implementation details in the kernel's source code.
Maybe this might be of some help too: VideoCore IV Programmer's Manual. About the document:
This is a independent documentation project based on a combination of static analysis and trial and error on real hardware. This work is 100% independent from and not sanctioned by or connected with Broadcom or its agents. No Broadcom documents or materials were used beyond those publicly available.
As for the software itself, The Khronos Group provides OpenGL ES and OpenVG implementation, but it's not open source. You can get the documentation from their website, but I doubt you'll find anything on such low level.
Hope it helps.
I want to write a program that will monitor memory in a driver and print the memory contents every so often.
However, I'm not finding any resources in the Windows API that seem to allow me to grab a pointer (Handle) to a specific driver.
I'd appreciate any answer either from User space OR kernel space.
If you want to know exactly what I'm doing, I'm attempting to duplicate the results from this paper except on Windows. After I gain the ability to monitor a buffer in a basic windows console program, I intend to monitor from the GPU.
[For the record: I am a Graduate Student who is pursuing this as a summer project... this is ethical malware research.]
============UPDATE ==================
This might technically be better suited as an answer, but not really until I have a working solution.
My initial plan of attack is to use WinDbg to do dynamic analysis on the keyboard driver when it gets loaded, so I can get some idea about normal loading/unloading behavior. I'm using chapter 10 of this book, to guide setting up my testbed and once I understand more about the keyboard structure and its buffer, I'll work backwards towards getting a permanent reference to this structure and see about passing it into the graphics card and monitoring it with DMA as the original paper did on Linux.
You won't solve this problem by "grabbing a pointer to a specific driver". You need to locate the specific buffer used by the keyboard driver that resides on top of the USB driver.
You will have to actually grok the keyboard and USB drivers for Windows. At least part of which is probably available if you have a DDK (driver development kit) [aka WDK, Windows Driver Kit]. You will definitely need a graphics driver for this part of the project.
You will also have to develop a driver mechanism to map an arbitrary (kernel) lump of memory to your graphics driver - which means you need access to the source code for the graphics driver. (In theory, you could perhaps hack about in the page-tables, but Windows itself isn't too keen on software messing with the page-tables, and you'd definitely need to be VERY careful if the system is SMP, since modifying page-tables in an SMP system requires that you flush the TLB's of the "other" CPU(cores) in the system after updates).
To me, this seems like a rather interesting project, but a really tough one in a closed source system like Windows. At least in Linux, the developer has the source-code to read. When it comes to Windows, most of the relevant source code is completely unavailable (unless your school has special license to the MS Source code - I think there are some that do).
I want to see CPU temperature and CPU load in Windows. I have to write it myself not using software like Core Temp. How can I access this information?
I read a similar question to mine, but there was no useful answer:(.
Recently I have started a similar project. I needed to read the cpu temperature and to control the fan in Linux and Windows. I don't know much about C++ and VS and DDK but I figured how to write a simple kernel driver and a simple program with winring0. In my laptop (and most other) the temperature and the fan is controled by the embedded controller. You have 2 choices, either you can write a kernel driver or you can use a library to access the embedded controller. It's because Windows protect the ec from being accessed with normal user rights. A good (and working) library is winring0 (WinRing0_1_3_1b). A useful program to check the ec and everything else in Windows is the RW tool.
Take a look at Getting CPU temp from MSDN forums, there are a few approaches.
As to the sane way, you can use Win32_TemperatureProbe class, that gets its intel from SMBIOS.
has anyone some kind of documentation how to implement an own flashing-procedure for an atmega8-microcontroller ?
when searching, i have only found tutorials, on how to flash custom software with the normal flashing-software (in most cases atmels flip), but i haven´t found any documentation, how you would implement it in your own software. eg. what are the commands in which timings and with which responses from the microcontroller.
so, thank you in advance
You program the chip by communicating with it through SPI lines while it is in reset. You can find details in the chip's datasheet.
You can't do that directly from your PC, you need to have an external hardware device (even if it is a mere level converter connected to your serial/parallel port). How you communicate with that device depends on the device.
If you want to implement bootloader functionality, you should take a look at boot_page_write() function in avr-gcc help. Basically what you need is the data stream from PC/other uC which will accumulate in RAM until you have enough to write one page.
You can search for AVR Universal Boot loader for example how it can be implemented.
I am trying to connect to a single USB device using the USB host port on an Atmel processor. I have an embedded system with limited memory and no OS. I want to implement a simple dedicated host to interface to a single USB slave device.
Can anyone guide me to a simple USB host implementation?
The processor is the Atmel AT91SAM9261S.
First of all if i remember correctly AT91SAM9261S have OHCI usb controller on board and you need to implement at least simple host controller driver (you can take a look on Linux implementation) . Depending on the transfer types your device will be using it might be not very hard - to very hard :) There is no trivial way to implement usb stack.
After implementing a controller driver you will need to take care usb device enumeration part take a look at Chapter 9 of USB spec. And only after this you can start implementing your device logic.
For simplified use case there is a lot of code that could be omitted, but without good usb background is hard to decide what is relevant and what is not.
Any way if you are looking for commercial solution my company can provide one.
I've used the RTUSB-32 stack from On-Time. It is a small foot print stack and was easy to integrate into our environment and the documentation is good. They abstract out nicely the needed support so that it is completely platform and OS neutral and has a relatively small number of hooks you need to provide to it - ie: It is well encapsulated.
Since you get all the source, you'll see that the code is not the most well constructed code in the world, certainly, but it can be deciphered without a whole lot of work if needed. In any case, it basically "just works" without issue. We have had it running in some products for a few years now and have only run into one compatibility problem with the stack where it wasn't quite doing auto-discovery quite right with a certain type of USB 2.0 hub. We sent them a sample of the hub and they had a patch for it within a few days. Hard to beat that. Overall, I consider it a good value and certainly beats sitting down to write the thing from scratch.
This would be so much easier if your device didn't have to be a host :-P, because Atmel provides example source code for USB devices. If I were you, I'd look into using one of the USB-loving RTOSs on Atmel's AT91SAM third party page which might entail the USB stack from jungo as suggested by Ilya.
If you do write your own OHCI driver, libusb could be helpful as an implementation of the upper layers of the USB stack.