0

Suppose for an embedded program, the hardware is designed such a way that it performs certain operation if the memory address 0x8729 is filled with 0xff. Is there a way to access the memory address 0x8729 and write to it?

Satish Kumar Singh
  • 117
  • 8
  • Do a search for **devmem2.c** and/or the devmem command in Busybox. BTW avoid the naked use of "*memory*" unless the context of *virtual* or *physical* memory is obvious. – sawdust Nov 15 '22 at 00:24

2 Answers2

1

Try this:

uint8_t * p_memory = (uint8_t *) 0x8729;
const uint8_t value_from_memory = *p_memory;
*p_memory = 0xff; // Writing to memory.

You may not need the cast, but I put it there anyway.

Explanation:

  1. Declare a uint8_t pointer and assign to your memory address.
  2. To write, dereference the pointer and assign your value.
  3. To read, dereference the pointer and assign the value to your variable.
Thomas Matthews
  • 56,849
  • 17
  • 98
  • 154
  • Caveats: 1) The address must be writeable. 2) Your program needs permission to access the memory location. – Thomas Matthews Nov 14 '22 at 21:33
  • 4
    I would slap `volatile` onto it. – HolyBlackCat Nov 14 '22 at 21:47
  • Since the question is tagged with `embedded linux`, you should expect a userspace program to be executing in virtual memory. So a write to "memory" address 0x8729 will be to a page of virtual memory mapped to some unknown physical page which the mystery device is not aware of. – sawdust Nov 15 '22 at 00:23
  • 1
    @sawdust: not necessarily. Embedded linux comes in several sizes and one of those features is supporting virtual memory, fencing and kernel vs. user space. All depends on what elements of linux the OP has implemented. Smaller embedded systems don't have the capacity for a standard linux implementation. – Thomas Matthews Nov 15 '22 at 00:30
0

I'd say that without more information about the specific Linux implementation we won't know if this is a problem with a "tiny" Linux implementation that doesn't support memory virtualization for userspace apps or if this is the normal behavior of a "standard" Linux implementation that does virtualize physical memory addresses from userspace.

I am inclined to believe this is userspace a virtualization issue, in which case you could use the techniques mentioned with this posting. It describes how to use devmem to access physical memory from the command line, and how to use the device file handle /dev/mem and memmap from within a C program.

Robert McLean
  • 196
  • 1
  • 8