I have got a beaglebone black and I want to start working on a project from scratch. I have setup the flyswatter2 for debugging and flashing purposes.
I can have a startupcode which ideally should work. but the problem is that I dont know from what memory address the begalebone black starts booting? and what memory address I should flash my code to inside the board's memory?
If I know the place from where I should flash my startup code then from there I can take it up with help of debugger and programming a UART for progress of my code. But I am stuck at the very first step.
Please note that I have read the chaper 26 of technical reference manual for AM335x from ARM and it talks about public RAM and ROM at certain addresses. But I am still unsure about from where to start.
If someone could just let me know that flashing my code at address 0xXXXXXXX will execute my code at startup then I can take it from there.
Thanks in advance
-Ravi
Actually Beaglebone black boards are configured to boot with either external SD cards or an internal eMMC memory, that de-facto is a MMC card soldered in the PCB.
If you take a look to the documentation of the processor on chapter 26 it describes the boot process, from all this section of the documentation, you will be interested for BBB on chapter 26.1.5.7.6. The most simple way is to format the MMC (or internal eMMC) in FAT format, and right after format create a file called "MLO". It is very important that this file is the very first in the FAT filesystem, so make sure to copy the file right after formatting.
That file is a a small header followed by your application in binary format. The header have the following format (from chapter 26.1.9.2 in same document):
At offset 0, a 4 bytes word with the size of the image.
At offset 4, a 4 bytes word with the load address of your image.
Then just your image.
There is a ROM code inside the Sitara processor that "understands" that file and performs the load of the code.
Not a simple procedure for bare-metal, but ....
Hope it helps.
Related
I am quite new at embedded development and started with a STM32F429 board to improve myself.
I have just developed a basic Caesar encryption application for my board. It is working well, and defined the secret key as "3". Now I would like to extract this super secret(!) key from my device.
How can I do it? Should I dump the memory or firmware of my device, and how?
May you suggest me any software for this proccess? (Not ST Utility or STM softwares please. Because I would like to try gained experiences on other devices as well.)
Thanks!
I take it the value you're looking for is hardcoded. In that case it resides in the internal flash. So yes, a memory dump will be necessary.
I will go the long way and assume that you know very little about how it works, so if you know some of this stuff, well, good for you. I will try to give a few pointers.
Specifically about STM32:
You have an option to boot the microcontroller from the so-called system memory, which is read-only memory, and it is already preprogrammed from factory with a bootloader. You can talk to that running bootloader via UART (most common way, comes with ST-Link, but any cheapo USB-UART bridge also works). Or it can be some other protocol. You can ask that bootloader to read its flash out to you, among other things. This is covered in AN2606.pdf. It has some useful links in it, such as:
names of documents, where you can find specific bootloader commands for any interface you wish. Of course, you only care about interfaces, that the bootloader of your specific MCU F429 supports, which are found in the same AN2606, page 172 (for bootloader version 0.7, there is also 0.9 for those MCUs, I have no idea how to tell which one you have, so...try? UART configuration seems identical anyway):
So what exactly needs to be done? Flip the state of BOOT0 pin - permanently - of the MCU and reset it (power cycle or reset pin, both ok). You will boot the MCU into bootloader instead of booting program from flash. You can read about it in the Reference manual STM32F429, page 69. It talks about states of BOOT0 and BOOT1 pins on boot. What pins are boot0 - if they're not marked on your board, then you'll have to consult F429 datasheet, page 69 (I swear, it's a coincidence). Depending on your specific IC, it will be one pin or another.
It will activate all MCUs peripherals as per docs above and it and wait on its UART and other pins for commands. Commands listed in the documents I provided above. Let's take a look at AN3155 about USART of bootloader:
And the commands are
are all in that document, the table of contents in pdf really helps to find stuff quickly. Of course, if you need specific details, and you will need specific information about specific commands, it's all in there too. How many bytes in command, how many bytes at a time you read from flash etc. Basically, you can either write your own program that does that (even program another microcontroller to program that microcontroller using victim's bootloader), or use any other software that knows what commands to send to the bootloader. It can be ST utility, it can be any other program. They all implement the very same command set, so it doesn't actually matter much. I couldn't find many programs that do that, the only thing that stood out was stm32flash. Never used it myself. I'm ok with ST stuff, since I know what it does (I think).
Oh yeah back to getting the secret value out. I almost forgot about that. Well, then you open the dump in hex viewer/editor, and scroll it around looking for interesting combination of values. Yeah, that's kinda what it looks like. One can run it via disassembly. Scroll disassembled code around, see if there are any numeric values that stand out. You know, some random number 0xD35B581 or something hardcoded in the middle of pretty program could mean something, like be a serial number or a secret number. Unfortunately, I'm reaching boundaries of my competence here, so won't go any further on what one can do with dump.
I'm in an assembly language course focusing on x86 Pentium processors, and am working on a Linux system. I understand that programs get loaded into memory and that you can perform operations directly within the registers but I'm not sure you can avoid creating a data segment altogether.
A yes or no, followed by a brief explanation as to why would be great.
It is not required. A data segment is simply a block of memory allocated for data and thus can be written to and read from. Code segments are read only. If you try to write to a code segment the hardware will generate an interrupt. However, assembly codes can be fed any address in memory, and if protected mode is disabled, then the hardware won't generate an interrupt.
As an example, the boot sector loads into a very restricted space on launch, and it is quite common (because space is so restricted) to place variables among the code bytes. Once I even wrote a boot sector that adjusted its own byte-code to accommodate differences in booting from different disks. So this is a case of code using code addresses as variables.
However, while you definitely can avoid creating a data segment, 99.99% of the time you do separate out a data segment.
You may also want to read up on protected mode to understand this better.
I attended interview for samsung. They asked lot of questions on memory layout of the program. I barely know anything about this.
I googled it "Memory layout of an executable program". "Memory layout of process".
I'm surprised to see that there isn't much info on these topics. Most of the results are forum queries. I just wonder why?
These are the few links I found:
Run-Time Storage Organization
Run-Time Memory Organization
Memory layout of C process ^pdf^
I want to learn this from a proper book instead of some web links.(Randy Hyde's is also a book but some other book). In which book can I find clear & more information on this subject?
I also wonder, why didn't the operating systems book cover this in their books? I read stallings 6th edition. It just discusses the Process Control Block.
This entire creation of layout is task of linker right? Where can I read more about this process. I want COMPLETE info from a program on the disk to its execution on the processor.
EDIT:
Initially, I was not clear even after reading the answers given below. Recently, I came across these articles after reading them, I understood things clearly.
Resources that helped me in understanding:
www.tenouk.com/Bufferoverflowc/Bufferoverflow1b.html
5 part PE file format tutorial: http://win32assembly.online.fr/tutorials.html
Excellent article : http://www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html
PE Explorer: http://www.heaventools.com/
Yes, "layout of an executable program(PE/ELF)" != "Memory layout of process"). Findout for yourself in the 3rd link. :)
After clearing my concepts, my questions are making me look so stupid. :)
How things are loaded depends very strongly on the OS and on the binary format used, and the details can get nasty. There are standards for how binary files are laid out, but it's really up to the OS how a process's memory is laid out. This is probably why the documentation is hard to find.
To answer your questions:
Books:
If you're interested in how processes lay out their memory, look at Understanding the Linux Kernel. Chapter 3 talks about process descriptors, creating processes, and destroying processes.
The only book I know of that covers linking and loading in any detail is Linkers and Loaders by John Levine. There's an online and a print version, so check that out.
Executable code is created by the compiler and the linker, but it's the linker that puts things in the binary format the OS needs. On Linux, this format is typically ELF, on Windows and older Unixes it's COFF, and on Mac OS X it's Mach-O. This isn't a fixed list, though. Some OS's can and do support multiple binary formats. Linkers need to know the output format to create executable files.
The process's memory layout is pretty similar to the binary format, because a lot of binary formats are designed to be mmap'd so that the loader's task is easier.
It's not quite that simple though. Some parts of the binary format (like static data) are not stored directly in the binary file. Instead, the binary just contains the size of these sections. When the process is loaded into memory, the loader knows to allocate the right amount of memory, but the binary file doesn't need to contain large empty sections.
Also, the process's memory layout includes some space for the stack and the heap, where a process's call frames and dynamically allocated memory go. These generally live at opposite ends of a large address space.
This really just scratches the surface of how binaries get loaded, and it doesn't cover anything about dynamic libraries. For a really detailed treatment of how dynamic linking and loading work, read How to Write Shared Libraries.
Here is one way a program can be executed from a file (*nix).
The process is created (e.g. fork()). This gives the new process its own memory map. This includes a stack in some area of memory (usually high up in memory somewhere).
The new process calls exec() to replace the current executable (often a shell) with the new executable. Often, the new executables .text (executable code and constants) and .data (r/w initialized variables) are set up for demand page mapping, that is, they are mapped into the process memory space as needed. Often, the .text section comes first, followed by .data. The .bss section (uninitialized variables) is often allocated after the .data section. Many times it is mapped to return a page of zeros when the page containing a bss variable is first accessed. The heap often starts at the next page boundary after the .bss section. The heap then grows up in memory while the stack grows down (remember I said usually, there are exceptions!).
If the heap and stack collide, that often causes an out of memory situation, which is why the stack is often placed in high memory.
In a system without a memory management unit, demand paging is usually unavailable but the same memory layout is often used.
Art of assembly programming http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.artofasm.com/Windows/PDFs/MemoryAccessandOrg.pdf
Hey all. I am troubleshooting a thermal printer issue when printing over bluetooth. The printer in question is Extech 3750T and the software is running on Windows CE. The driver is implemented on top of Winsock and is written in C++. As far as I can tell the connection housekeeping is all according to spec.
The issue seems to be that sometimes (about once out of ten) when an image is printed the printer just stops. Then, when the next print job is sent it would output a single line (one pixel wide) of garbage and print the new page.
The driver is built on top of RTF and it translates RTF commands and graphics into printer specific characters and escape sequences. The developers manual is available from here:
http://www.adtech.com.pl/upload/3750T_Developers_Manual.pdf
At this stage I am fairly convinced that it is not a flow control issue (other than changing the buffer sizes might somehow help).
One thing that is confirmed is that whenever the printer screws up it sends an out of paper control character to the device, but by that time it's already too late to salvage it.
Also, I think the problem is caused by sending an image while text is still printing. A dirty hack of just wawiting like 5 seconds seems to make it go away, but it's way to awkward to implement that in production environment as the size of the text (font size, weight etc) will affect the amount of delay needed.
I guess I am looking for suggestions on how to tackle this rather than explicit solutions.
Any ideas?
After about 7 days solid on this I got some support from printer manufacturer and resolved the problem by sending images one line at a time. This particular printer is using an image compression mechanism where a byte represents either 8 bits of graphic and can either optionally be repeated a maximum of 129 times.
I have tried breaking the data stream every so many bytes but that didn't help. I think that's because an image doesn't like to be broken up into multiple transmissions. Transmitting one line at a time (roughly 72 bytes) fixed the problem.
how do i debug something like this? i need the debugger to stop and show me where the problem is. don't just show it in the event log & then hang.
first chance exception: system error 8: not enough storage space to perform the command
i'm using delphi 2009. the problem doesn't happen regulary. i'm not eager to pepper my program with OutputDebugString calls to track this down!
thank you for your help!
You are looking at a resource leak on your server, more than likely... Either handle related, or memory related...
I've had this happen a lot, and it's always the case... There CAN be other causes, but I think a resource leak is your #1 cause...
You are going to have to either find it and fix it, or start putting debug checks in on all memory allocations, handle allocations, and log them anytime you can't get memory, or handles.
It's also possible that your CLIENT machine is out of resources, but usually, it's the server at fault...
Failing all that, give us some more idea of what you are doing, what the code looks like, etc, to help spot issues. Just based on the error alone, isn't a lot to go on...
If your program uses a lot of windows resources it could be a Resource Heap shortage.
There is a registry entry that can be increased to raise the heap size for XP. For Vista Microsoft already sets the default value higher. I recommend changing the default 3072 to at least 8192.
This information is documented in the Knowledge Base Article ID 126962 (or search for "Out of Memory"). Additional details concerning the parameter values may be found in the Knowledge Base Article ID 184802.
I suggest you read the knowledgebase article but the basic info on the change is:
1) Run Registry Editor (REGEDT32.EXE).
2) From the HKEY_ LOCAL_MACHINE subtree, go to the following folder:
\System\CurrentControlSet\Control\Session Manager\SubSystem
3) On the right hand side of the screen double-click on the key:
windows
4) On the pop-up window you will see a very long field selected. Move the cursor near the beginning of the string looking for this (values may vary):
SharedSection=1024,3072,512
5) SharedSection specifies the System and desktop heaps using the following format: SharedSection=xxxx,yyyy,zzz where xxxx defines the maximum size of the system-wide heap (in kilobytes), yyyy defines the size of the per desktop heap, and zzz defines the size of the desktop heap for a "noninteractive" window station.
6) Change ONLY the yyyy value to 8192 (or larger) and press OK.
7) Exit the Registry Editor and reboot the PC for the change to take effect.
Good Luck