I implemented FatFS in internal memory of MCU STM32 Chan's library. Now I try to emulate bigger volume of flash device to receive large files from PC.
I can do it by changing two places of FatFS image:
1. By changing MBR_start + 12 field value of MBR sector to required amount of sectors to emulate (address 0x1CA, LBA format):
2. By changing total number of sectors in the filesystem in FAT12 boot sector:
But the max number I can put there ix 0x13F (in LBA format) to emulate 142KB flash storage visible for PC. If I try to change that fields to higher I value my USB mass storage emulation fails and PC says me that USB device is not recognized.
Here is link for my FAT12 FS storage binary scan:
https://cloud.mail.ru/public/GddY/6rvUuyPHx
Did someone do same things?
I can't find any forum of FatFS gurus.
Thank you for any suggestion.
Related
A 32-bit register can store 232 different values. The signed range of integer values that can be stored in 32 bits is -2,147,483,648 through 2,147,483,647 (unsigned: 0 through 4,294,967,295). Hence, a processor with 32-bit memory addresses can directly access 4 GiB of byte-addressable memory. so how this kind of processor deal with disk of size more than 4 gb?
Hence, a processor with 32-bit memory addresses can directly access 4 GiB of byte-addressable memory. so how this kind of processor deal with disk of size more than 4 gb?
For disks; typically they're not byte addressable and the smallest amount that can be read or written (the block size) is 512 bytes or larger (maybe 4096 bytes). Block numbers may also be larger than 32 bits (e.g. maybe 48 bit block numbers).
With 512-byte blocks and 48 bit block numbers (which was common in the late 1990s; for ATA and SATA, etc) you'd end up with a maximum disk size of 134217728 GiB.
Of course the CPU probably (see note) can't directly access any of the data on disk. Software (file system) has to ask a device driver to fetch the block/s it wants, and device driver asks hardware (disk controller) to copy data between disk and memory. Depending on OS; this software interface (used by file system to ask device driver to read or write blocks) most likely uses 64-bit block numbers (e.g. two 32-bit registers joined together).
Note: More recently, the possibility of using non-volatile RAM (e.g. https://en.wikipedia.org/wiki/3D_XPoint ) as storage changed things (it is byte addressable and does use physical addresses); but modern hardware is all "64-bit" (with physical addresses that may be 48 bits or larger in practice) so even though the theoretical limit is much smaller it's still large enough in practice (e.g. maybe 200000 GiB).
On x86-64, the main CPU architecture of most desktop computers, an interface is standardized in the AHCI (Advanced Host Controller Interface). The computer accesses the hard-disk using this interface which is, in practice, a PCI-Express device compliant with the PCI-Express specification.
With PCI, the CPU has a memory controller which will write to the PCI devices registers instead of RAM when writing to some portions of RAM. Software (the operating-system) will write in uncached RAM and it will instead write to the registers of the PCI device. This way it can tell the devices, including an AHCI, to do some operations like a DMA operation from the hard-disk to RAM and vice-versa.
I didn't read the specification in full but the specification probably holds 64 bits registers that can be written as 2 32 bits words. More often, software will write to the lower part of the register then to the higher part of the register. This allows any 32 bits computers to still be able to interact with AHCI. On a 64 bits computer, the registers will be written as one 64 bits write.
A 32 bits computer is thus still able to trigger DMA writes to some portions of the hard-disk which are much higher than 4GB.
I'm confused.
I have recently started working on building an operating system while using bochs as an emulator and a certain manual online.
In the manual to move the vga framebuffer cursor I'm using the IO ports using the command 'out'. I get how to control it but I don't know what is it that I'm controlling, and after some reading it seems like everywhere it was addressed as an abstract thing that for example makes the cursor to change its position on the screen.
What I want to know: what are they physically? are they cables? if yes from where to where they are connected? can I input from them also as there name suggest? and why do I need the out command and cant write directly to their place in the memory?
If in your answer you can also include the serial ports and the difference between them and the IO ones it will be amazing,
with respect,
revolution
(btw the operating system is 32 bits)
An IO port is basically memory on the motherboard that you can write/read. The motherboard makes some memory available other than RAM. The CPU has a control bus which allows it to "tell" the motherboard that what it outputs on the data bus is to be written somewhere else than RAM. When you output to the VGA buffer, you write to video memory on the motherboard. The out/in instructions are used to write/read IO ports instead of writing to RAM. When you use out/in instructions, you instruct the CPU to set a certain line on its control bus to tell the motherboard to write/read a certain byte to an IO port instead of RAM.
Today, a lot of RAM memory is used for hardware mapping instead of IO ports. This is often called the PCI hole. It is memory mapped IO. So you will write to RAM and it will send the data to hardware like graphics memory. All of this is transparent to OS developers. You are simply using very abstract hardware interfaces which are either conventional (open source) or proprietary.
Serial ports in the meantime are simply ports which are serial in nature. A serial port is defined to be a port where data is transferred one bit at a time. USB is serial (universal serial bus). VGA is serial and others are too. These ports are not like IO ports. You can output to them indirectly using IO ports.
IO ports offer various hardware interfaces which allow to drive hardware. For example, if you have a VGA compatible screen and set text mode, the motherboard will make certain IO ports available and, when you write to these IO ports, video memory will vary depending on what you output to these ports. Eventually, the VGA screen will refresh when the video controller will output data written to video memory through the actual VGA port. I'm not totally aware of how all of this works since I'm not an electrical engineer and I never read about this stuff. To what I know, you can see the pins of the VGA port and what they do independently on wikipedia. VGA works with RGBHV. RGB stands for red, green and blue while HV stand for horizontal/vertical sync. As stated on wiki in the article on analog television:
Synchronizing pulses added to the video signal at the end of every scan line and video frame ensure that the sweep oscillators in the receiver remain locked in step with the transmitted signal so that the image can be reconstructed on the receiver screen. A sync separator circuit detects the sync voltage levels and sorts the pulses into horizontal and vertical sync.
The horizontal synchronization pulse (horizontal sync, or HSync), separates the scan lines. The horizontal sync signal is a single short pulse which indicates the start of every line. The rest of the scan line follows, with the signal ranging from 0.3 V (black) to 1 V (white), until the next horizontal or vertical synchronization pulse.
Memory in itself takes various forms in hardware. Video memory is often called VRAM (Video RAM) or the Frame Buffer as you can read in a Wikipedia article. So in itself video memory is an array of DRAM. DRAM today is one capacitor (which stores the data) and one mosfet transistor (which controls the flow of the data). So you have special wiring on the motherboard between the data bus of the processor and the VRAM. When you output data to video memory, you write to VRAM on the motherboard. Where you write and how just depends on the video mode you set up.
Most modern systems work with HDMI/Display port along with graphics card. These graphics card are other hardware interfaces which are often complex and they often cannot be known because the drivers for the cards are provided by the manufacturers. osdev.org has information on Intel HD Graphics which has a special interface to interact with. It can be used to gather info on the monitor and to determine what RAM address to use to write to the monitor.
For example...
16GB USB flash drive's real capacity is almost 14.8~15.4 GiB.
these are different by each manufaturers or models.
In this situation....
How can I expect real minimum capacity?(GiB or Sectors)
Is there a standard? or de facto?
Back in the days, the size for hard-drives were always in gibibytes (1000 mibibytes) instead of gigabytes. That accounts for 7,4% size difference when comparing a gigabyte with a gibibyte.
lpc1768 linker script why ram start address should be given at 0x100000C8, RAM (rwx) : ORIGIN = 0x100000C8, LENGTH = 0x7F38.
If I give at 0x10000000 then system is crashing when I enable UART interrupts.
Your crash cause should be a providing a big clue - that offset of 0xC8 (192 bytes) is to allow space for the interrupt vector table.
Not all applications will require that the vector table be in RAM - if you have a fixed program in flash then the vector table can be there as well. But if you are using a bootloader to run code from RAM and want that code to include interrupt service routines, you would need to place a vector table in RAM and update the register which points to it. See for example AN10866.
I'm trying to extract data from 3.5" floppy disks formatted on a +D interface for a ZX spectrum. It's close but not exactly the same as for a PC. I've written software to do this in the past useing the BIOS to access a floppy.
However some disks are old and have bad sectors. I am trying to create a floppy drive controller to read a disk at a bit level to recover as much data as possible. I'm fully aware of how difficult this might be. I have however written a disk utility program that interfaced with the interface at a machine code level on the original spectrum computer, written in Z80 assembly software to emulate MSDOS to access and write files to FAT12 floppy disks. The original computer that accessed these disks did so using a 3.4MHz processor, so the Rasperry Pi that I'm thinking of using should be more than fast enough. I might even be able to run it from Linux but if not I have figured out to access the GPIO port, screen, keyboard and SD card using assembly language that would not need any kernal to run it. I've read up on how floppy drive reads and write data and have seen some basic example of how to opperate the floppy disk (not just the stepping motor).
I've done some research but have a few questions I can't seem to find answers to, and wonder if people here might know.
1) The read data pin (30). Does this return a logic high/low value of what's under the read head (rounding up or down to logic high or low), or is it analog? I ask because if it's analog, getting any input back would enable me to better try and recover corrupt sectors,but would make interface circuit harder to make, and depending on ADC used make interface with GPIO harder, and slower.
2) I know the molex power of +5V and +12V. But what current would a floppy expect?
3) I assume that the control pins from the ribbon cable on the floppy work at 0 or +5V, but that people seem to be able to run them at +3.3V. Does anyone know what they should be running at, and what their current tolerance are: what voltage and current the inputs expect, and what current/voltage the outputs deliver?
Many thanks for any information/knowledge that you might have on this.
A little late, but if someone else is interested:
1) The data output of the floppy is open-collector. So you can pull it up to your 3.3 Volts and will be fine.
2) 600 mA # 12V, 500 mA # 5V should be safe
3) Think of TTL input, that expects 2.4 Volts for HIGH. (2.5V according to the NEC 3.5" floppy drive).