I want to upload the device firmware to a file using dfu-util. How can I determine the correct size of flash memory?
After booting the device into DFU it can be found using:
dfu-util -l
For which I receive the following information:
Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, alt=1, name="#Option Bytes /0x1FFFF800/01*016 e", serial="FFFFFFFEFFFF"
Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, alt=0, name="#Internal Flash /0x08000000/064*0002Kg", serial="FFFFFFFEFFFF"
To upload the flash configuration to a file I need to determine the size of flash memory. Based on this article the size would be 64 x 1kB of flash memory.
What is the meaning of 'Kg' in 0002Kg?
The instructions I am following (elsewhere, for a different device, see above) is using 128 x 1kB, instead which I believe is incorrect. How can I calculate the size of flash memory and what will happen if I set the memory size too large to download an image?
The command is:
dfu-util -a 0 -s 0x08000000:131072 -U ./original.bin
I think it should be
dfu-util -a 0 -s 0x08000000:65536 -U ./original.bin
Please see UM0290 in which we find:
Each Alternate setting string descriptor must follow this memory mapping else the PC
Host Software would be able to decode the right mapping for the selected device:
#: To detect that this is a special mapping descriptor (to avoid decoding standard
descriptor)
/: for separator between zones
Maximum 8 digits per address starting by “0x”
/: for separator between zones
Maximum of 2 digits for the number of sectors
* : For separator between number of sectors and sector size
Maximum 3 digits for sector size between 0 and 999
1 digit for the sector size multiplier. Valid entries are: B (byte), K (Kilo), M (Mega)
1 digit for the sector type as follows:
a (0x41): Readable
b (0x42): Erasable
c (0x43): Readable and Erasable
d (0x44): Writeable
e (0x45): Readable and Writeable
f (0x46): Erasable and Writeable
g (0x47): Readable, Erasable and Writeable
So your string really does mean that the internal flash is 64 sectors of 2 KB, and that they are "readable, erasable and writable" (i.e. flash). Are you sure about your expectations of the device's flash layout?
Related
The image is relating to an example of translating in virtual memory. The address of phys. mem. starts from 0x000 ~ 0x0FC, then moves start 0x100 ~ 0x1FC and so on. Why don't it go like 0x000 ~ 0x0FF, and then 0x100 ~ 0x1FF etc. What are the two lowest bits stand for?
Thank you for your answers. This photo came from MIT open course, and they didn't reveal more details about the address. But I finally figured it out in the later example of the courses.
The two lowest bits can always be zero as the following example:
Supports that we have:
4GB of MM size.
64 lines of cache.
ONLY 1 WORD = 4 bytes PER CACHE LINE.
The address have 32 bits because of 4GB of MM.
The partial address defining the line have 6 bits because of 64 lines of cache.
And because the cache size is 2^6*4B
=> The tag have 24 bits (log2(4GB/2^8B))
=> The lowest bits have 2(32 - 24 - 6) bits.
Because there is only a word per block so that the lowest bits, which act as a data boundary(This is what the course said), are always 0.
How can I find DRAM row buffer size programmatically or by using already existing tools in say a *nix system ?
As an example, with a Kingston DDR4, I executed the following commands (you might need to install some packages) :
sudo modprobe eeprom
decode-dimms
These commands, among many information, give me the characteristics of my DDR stick:
---=== Memory Characteristics ===---
Maximum module speed 2132 MHz (PC4-17000)
Size 16384 MB
Banks x Rows x Columns x Bits 16 x 16 x 10 x 64
SDRAM Device Width 8 bits
Ranks 2
Rank Mix Symmetrical
AA-RCD-RP-RAS (cycles) 14-14-14-35
Supported CAS Latencies 16T, 15T, 14T, 13T, 12T, 11T, 9T
Rows and columns are actually number of address bits (you can check the decode-dimms source at https://fossies.org/linux/i2c-tools/eeprom/decode-dimms, and understand what the code is doing when you look at the DDR4 SPD information: https://en.wikipedia.org/wiki/Serial_presence_detect#DDR4_SDRAM)
Thus, if we have 10 column bits, we have 1024 columns (2^10), where each column is composed of the module width (64 as per the data above, represented as "bits"). Since we can also see that the SDRAM device width is 8x, we can deduce that the DIMM locksteps 8 SDRAM chips (those black boxes you see in your DRAM stick) to get that total width of 64 bits.
The row buffer size in my DDR4 is, therefore, 64 bits * 1024 columns = 65536 bits wide (8192 Bytes). Row buffer sizes in DDR3 and DDR4 are mostly this length, but new architectures such as HMC and HBM have different sizes.
So, in one short commandline, to return in bits (just divide by 8 to get bytes):
decode-dimms | grep "Columns x Bits" | awk -F 'x' '{print (2^$(NF-1))*$NF}
PS: mind you, this handles a single DIMM. if you have multiple DIMMS decode-dimms might return information for multiple modules.
Most posts i read just give info about the maximum file name length's. But, i want to understand why there's this limit. Why can't file name's be big. I see that few file systems have put a limit of 255 bytes. Why not 1 MB or anything more than 255 bytes. I probably would never have a file name of length more than 100 characters. But, this question is about why the limit?
long file name costs much more space and time than you can imagine
the 255 bytes limit of file name length is a long time trade off between human
onvenience and space/time efficiency
and backward compatibility , of course
back to the dark old days , the capacity of hard drive capacity was count by MB or a few GB
file name are often stored in some fixed length C structs ,
and the size of the struct was mostly round by the factor of 512 byte,
which is the size of a physical sector ,so that it can be read out by a single touch of the head
if the file system put a limit of 1MB on filename, it would run out of harddisk space with only a few hundred files. and memory limits also applys.....
I am having hard time calculating the page size as from below link:
http://www.embedded-bits.co.uk/2011/mmucode/
As we know page table entries in this table are 4 bytes long and that there is a maximum of 4096 entries (one for each 1MB of the address space) we can calculate the size of the table as 16KB
Now total size of page table is 4096 entries * 4 bytes wide entry = 16384 bytes = 16kb
But as from above statement each of the 4096 entry corresponds to 1 Mb of address space, that means 1 entry = 1MB .
Since there are 4096 entries, space required to store it is 4096MB but we have page table size of 16kb only.
Also, how many virtual address this 1mb of section has, 250000?
EDIT:
Sorry, if its going to be more stupid from my end. I tried to understand it again. This 1 Mb of section is part of Physical memory not the virtual memory/page table(which I understood earlier).
Now each entry is 4 Bytes longs, does it means 4 virtual addresses are going to cover 1 Mb of Physical Memory section ?
Not quite sure what the question is asking but in a typical AArch32 MMU (barring the newer extensions), you would have first and second level translation tables in a typical configuration.
The first level translation table splits the entire address space into 1MB sections and typically contain pointers to level 2 tables which split those 1MB sections into granular pages (traditionally 4KB on most machines). 2nd level translation tables store physical addresses that correspond to those virtual addresses (each entry stores a physical address along with some flags). The virtual address is determined by its position within the L1 and L2 tables. To further clarify, all addresses stored in page tables (including addresses to L2 tables in the L1 table) are physical.
The first level translation table has a fixed size but depending on which architecture you're running you can change its size (this is used by a lot of ARM kernels to provide a user/kernel address space split). Each gigabyte of virtual memory space requires 4096 bytes in the L1 table at 4096 byte page size.
To even further clarify as far as I remember you can use L1 entries to map 1MB chunks directly without using L2 tables, the type of L1 entry is denoted by lower bits of it.
(Sorry if I got the unit suffixes wrong)
I have a buffer in SRAM of size 4096 bytes which gets updated with new raw audio data periodically:
----------------------------------------
| 2048 bytes of L | 2048 bytes of right|
----------------------------------------
^ ^
|A |B
NOTE: A and B are pointers to the start addresses.
As shown, the data is non-interleaved stereo (16 bit samples, 44100Hz sampling rate) and since it is in memory already, I prefer to use MMAP'ed access instead of RW (and as far as my understanding of alsa goes, it should not use a separate buffer for copying data into from this buffer).
The starting address for this buffer is fixed (say 0x3f000000 physical address) and I am MMAPing this buffer to get a virtual address pointer.
Now, how do I send data to alsa for playback and what should be my configuration?
My current unsuccessful way is:
Resample ON
Rate 44100
SND_PCM_ACCESS_MMAP_NONINTERLEAVED
channels 2
format SND_PCM_FORMAT_S16_LE
period near 1024 frames
buffer near 2*1024 frames
void* ptr[2];
ptr[0] = A // Points to mmaped virtual address of A
ptr[1] = B // Points to mmaped virtual address of B
while(1)
{
wait_for_new_data_in_buffer();
snd_pcm_mmap_writen(handle, &ptr, period_size);
}
Extra info:
1. I am using an embedded board with arm cores and running basic linux on it.
2. This is a proprietary work related project and hence the vague-ness of this question.
3. I already know that directly MMAPing a physical address is not recommended so do not waste your time commenting about it.
Thanks in advance.