I am working in Linux 2.6.20.14 running processor having USB chip FT313. I got a Linux driver from a vendor and I ported that to my Linux. When I do the memory read at the Uboot side on the memory to be mapped to my FT313 chip, I saw each 16-bit value was repeated twice in the memory. For e.g, if the default value is 03130001, the output will be like 03130313 00010001.
I needed to have dummy entries for each register to ignore these repeated values. After that, USB insertion and ejection give prints and IRQ count also increases. But when I tried to mount the Pen Drive as mass storage, SCSI probes won't happen and a USB device is not getting detected as Mass storage. I have already installed USB storage and scsi_mod modules.
Can anyone who has worked on FT313 in Linux tell me whether it is the expected behavior or not? And if it is possible to have FT313 chip as USB mass storage.
Related
Recently, I beginning research how to write SPI ADC driver(ADS7950) on the raspberry pi 4 with Linux.
I read this book which tell me I can get good flexibility with LKM driver.
I know every device should be initialized with device tree when Linux boot.
Device tree pass the features into device driver such as clock frequency and device address in memory.
So if I just make LKM module which means driver will initialize after boot.
Should I also make(append) device for LKM drive?
I'm deciding between the MiniPCIe and USB accelerators for a home Linux CCTV project. The host has both USB3 and a MiniPCIe socket. The host's physical environment will range from an ambient 20C up to a potential 35C (during the summer).
I'm struggling to determine the pros and cons for each. I have gotten this far, although many are guesses:
USB:
Supports Windows and MacOS as well as Linux
Appears to have greater mindshare/use/community support on the Internet
External so can be placed to optimise heat dissipation
Heatsink
Two manual performance modes, highest requires ambient temp of max 25C
Can use up to 4.5W (900mA # 5V)
Mini PCie:
Cheaper (25%)
Lower power consumption (1.4W for 416 fps)
Automatic thermal throttling via driver
Relies on host system for active cooling
Will maintain max operation at 85C
There's probably many I've missed. In particular I can't determine if there's any limitations on throughput/capacity using USB vs PCIe. If there is no difference, then I suspect the USB form factor is the better option, if only for the mindshare, although the power usage/heat generated may be a concern.
To whittle this down to an actual question: in what cases would the Mini PCIe interace be a preferred option to the USB one?
If you are looking for a plug&play solution, then I definitely suggest the USB Accelerator. Overall, as long as you have the system requirements then it'll always works (maybe with some modifications to the standard linux configs like adding your user to the plugdev group, ...). Then the software for the CCTV is all up to you :)
PCIes sometimes need extra works like adding extra kernel arguments and modules to keep the pcie modules happy. If you are looking to launch a huge product where volumes are expected, then it is worth investigating it since it's cheaper and more compact. However, the power usage is a must for consideration as the USB Accelerator could uses up to 900mA, so that could play a factor.
May I know what host are you trying to attach the accelerators to?
Please anyone explain the exact differences?
While implemntin the driver code, I have facing an issue in both places.
We will need more information for getting to the root of your issue. What exact problem you are facing. Well as per your query different types of driver details are given below.
Physical Device Driver: A physical device driver is a driver for a specific piece of hardware. This drivers are written by device vendor. Some of the examples are ethernet drivers, graphics drivers(intel, nvidia) etc
Logical Device Driver: A logical device driver is a high level abstraction of how a device behaves. The logical device driver talks to the physical device driver for you to keep you abstracted from the underlying hardware. So Logical device drivers are written by operating system vendor. some of the examples are generic drivers provided by microsoft like USB etc
Virtual Device Driver: Virtual device drivers are drivers which emulates a hardware device. It emulates a piece of harware, so that softwares can have illusion of accessing real hardware. Some of the virtual device driver examples are virtual network adapter, virtual DVD/CD drive, virtual disk device etc
1) Is it possible to access a physical address which is not defined in /proc/iomem?
2) If the physical address range of a device does not appear in /proc/iomem, does it mean that the device has not been utilized/initialized yet?
1) Is it possible to access a physical address which is not defined in /proc/iomem?
Yes.
Assuming an ARM processor which memory maps all directly-connected periperals, the driver could perform an ioremap() operation to map the physical memory to virtual memory for access.
But a properly written driver would first call request_mem_region() to ensure that it can use (and lay claim to) that physical address space.
The information in /proc/iomem comes from drivers calling request_mem_region().
2) If the physical address range of a device does not appear in /proc/iomem, does it mean that the device has not been utilized/initialized yet?
You would have to inspect the driver code to determine how well written the driver is.
Is there a request_mem_region() before the ioremap()?
Check the system log using the dmesg command; perhaps driver initialization failed.
Assuming that this is a statically-linked driver rather than a loadable module, then as each kernel device driver has its init() routine called you can get trace output by having added the option "initcall_debug" on the kernel command line. If you are using U-Boot, then this option should be added to the "bootargs" variable (which is used for the kernel command line).
I understand that the computer loads the first sector of memory known as BIOS, which runs diagnostics on hardware and the proceeds to load the OS. I guess my question leans towards the hardware side. How does the computer know which memory to boot from (RAM, ROM, FLASH, etc). I understand the differences between memory and I understand computers boot from the hard drive, but Im attempting to make an 8 bit computer with a z80 microprocessor, which will need to boot from ROM or Flash memory. The only problem is that the processor reads only from whatever memory the address pins are connected to and there are no separate address pins for ram and rom. Its also impractical to run the system on rom or flash due to the much slower read/write time compared to ram. The z80 to the best of my knowledge doesnt have separate commands for reading from rom and ram, and it wouldnt matter even if it did because the ram will be blank upon powering up. How does a computer choose to read from rom only upon booting and then switch to ram once the OS has been loaded. Is it hardwired in using logic gates? And how does a computer choose to write to flash memory or a hard drive instead of ram once the OS has been loaded? Would flash memory be treated as a device? Or is this also hardwired into the motherboard using logic gates? Sorry for giving so much background, I just dont want you to waste your time explaining things Ive already grasped. Ive just researched this to a great extent and thought about it for hours on end and cant seem to figure it out, and everywhere Ive looked doesnt explain how the computer chooses which memory to read from, it just says that it does. Thanks
I'm not sure I'm answering what you are asking, but I'll give it a try.
Some computers (at least, IBM PC-compatible computers), after powering up, usually run this BIOS (Basic Input/Output System) program. For this to happen, to the best of my knowledge, the hardware must make the jump to this code, and this code must be accessible (that is, mapped) from the physical memory, since that's where the CPU will execute code from. So, a physical address space with some read-only areas where this code is hard-wired to would do the trick.
Once the BIOS code is running, it can select how to proceed next. It can copy a sector from a hard disk to memory, (or a bunch of data from a Flash drive) and then jump to it, or whatever. That's up to the BIOS writer.
I will try to explain the Pentium boot up process very briefly.
On the flash ROM mounted on the Motherboard. there is a small program called BIOS (basic input, output system). After pressing the power button the BIOS program is executed.
The BIOS contains low level software that performs the following operations :-
checks how much RAM is installed and if all other PCI and ISA buses peripherals are connected.
it checks if all IO devices are connected.
scans a list of boot devices and selects the boot devices based on BIOS configurations setup earlier by the user.
once the boot devices is selected. the first sector from the boot device is read into memory and executed. it contains a simple program which examines the partition table and selects the Active one (Holding the OS). The secondary bootloader is read from that partition. this loader then reads the OS from the partition into the memory and runs it. After running, the OS asks the BIOS for the configuration info for each device and configure the new devices (those have no stored configurations). after all devices configurations are set. they are delivered to the kernel. Then it initializes tables, background boot up processes and starts login program or GUI.