Articles on this topic from 2012 for earlier RPi hardware extolling the virtues of using an external USB flash drive are now dated.
In 2015, using Raspberry Pi 2 hardware, is there still any advantage to moving the root file system and booting from an external USB flash drive instead of just using the default microSD card?
I'm not sure if the raspberry pi bootloader is even capable of booting from USB, but I could be mistaken (there might be a way to set up an SD card to act as an intermediate step in mounting the OS from USB).
Aside from that, I can't imagine you'll notice much of a speed difference between the micro sd and a USB 2 flash drive (as far as I'm aware, the rpi doesn't have usb 3 hardware). Both will have similar life span.
Other considerations: power consumption (I believe SD has an advantage here, especially since a card will have to be used anyway to boot), quality of either device (you can buy really bad SD cards and USB flash drives alike)
I would be interested in seeing some bench marks if you decide to run any tests to see if there's a difference.
My DriveSpeed benchmark measures speed of large and small file writes and reads, plus random writing and reading. RPi 2 results for SD and USB drives are here.
http://www.roylongbottom.org.uk/Raspberry%20Pi%20Benchmarks.htm#anchor21
For booting, you need to establish which performance feature is more important and it is not just large file data transfer speed. Anyway, it mainly depends on the drive hardware performance characteristics. My system SD card can be out performed by SD cards in a USB card reader.
Related
I have two nucleo boards (F4339ZI and F303K8) and neither of them show up as USB devices when I plug them into a computer via the USB port (CN1 - the USB micro port on the ST-Link, not the USB port for the board itself).
I have tried multiple host USB ports, with and without a USB hub, across two different computers, one running OS X and one running Linux. I have tried at least 6 different cables. The OSX machine is using a USB-C to USB-A converter (if that's the correct terminology). The Linux machine has USB-A ports.
In no case does the device show up using lsusb under Linux or system_profiler SPUSBDataType under OSX. Needless to say STM32CubeIDE and st-info can't see the boards. Other USB devices are functional.
The COM LED is slow blinking red which the manual (https://www.st.com/resource/en/user_manual/dm00244518-stm32-nucleo144-boards-stmicroelectronics.pdf) says means USB enumeration hasn't completed (matching what is seen from the OS level).
The boards successfully run their factory supplied blink programs when powered on.
I have tried (with the F4395I) moving JP3 to VIN so the board doesn't power up which should just leave the ST-Link running - still no enumeration though.
I tried connecting to a USB charger with JP1 off (and JP3 on U5V) and the board powers up and blinky runs. The manual referenced above says:
In case the board is powered by a USB charger, there is no USB enumeration, so the green LED LD6 stays in OFF state permanently and the target STM32 is not powered.
But everything works for me - LD6 goes a steady green as it does when connected to a computer.
Given it happens with multiple computers, OSs, cables and Nucleo boards I assume the error lies with me, the common factor in all the tests. This is my first use of Nucleo boards so I may well have a mis-assumption.
Out of frustration and lacking anything else to try I dug up every micro USB cable I could find. One had chokes on each end and magically, using that cable, everything just works as expected.
Can it be that I have at least 10 broken USB cables? I don't have an easy way to test them but I guess they might not have the data lines wired to save cost if manufacturers assumed people would only charge phones with them. I don't recall where they all came from...they have just accumulated in a box of USB cables.
Perhaps the Nucleo board sensitive to some horrible interference floating around my room?
Sorry for the noise! Broken cable was genuinely one of the things I suspected - but not 6 of them...
i'm using STM32 as my microprocessor along with I2C EEPROM for storage and ESP8266 for Wifi
How can i download an update binary for the bootloader to flash using ESP8266 although the firmware file will be larger than STM32 Ram so i can't load the file from the ESP8266 in one chunk ?
I suppose that you want to update the stm32 firmware.
In this case allow to upload a new binary for the stm32 to the web, store it in the esp8266 file system (it must be bigger than stm32 flash size).
After that, enable flash memory writing, set an small protocol for update stm32 from serial comm from esp8266 the file to stm32 flash.
Remember that all functions that are used to update the stm32 flash must be in RAM.
I'm doing a project for stm32f4 and esp8266 and I will do exactly this.
OPTION 2:
If your program binary size is under 50% of stm32 flash size, then use the above half of the stm32 flash memory to store the new program, after reset, check if there is something there, and if it is then update (this is what i'm doing actually in stm32, very secure method to update since only stm32 cpu is used for update and it is very fast).
I suppose that you have two firmwares on the STM32 flash. First one is boot loader and the second one is your application. Your boot loader gets new firmware over serial interface of the ESP8266; so you can use flow control pins to halt communication until you write the data into flash memory.
I use that combination, stm32 and esp32/esp8266, for now i have not used firmware upgrade from esp (my stm32 supports it but I have not needed it for now).
The easier way is to set a serial protocol between both cpus. I'm using half of the stm32 memory for code and half for updating. What I do actually is using the communication protocolo is copy the file to the upper half of the flash memory. After when i reset the code i check if there is a firmware ready to be updated, then I copy from top half of flash to bottom half.
With this system, you can check if all is ok and the update process with take few ms. After you have this system tested (using for example a PC) you can try to do it from your esp, but it is just as easy as repeat the process.
My tip about the esp8266 is to download the file to a spiffs. If you are not using spiffs, use it, create a drive a little bigger than your memory.. for example if your stm32 firmware binary is around 60kb, and your target cpu is 256, use around 160kb for it.
There is another way, it is download the html file in chunks and then send them to the top half of the cpu, it is not very complex. I would requests chunks with the same size of the block size of your comunnication process (in my case i'm using 256b or 512b, i dont remember at this moment).
Anyways if you have enough spiffs size download the file, update the stm32 cpu, delete the file and send a reboot.
Dont forget to add a crc for data transmision between stm32 and esp8266
Btw you dont need to download it to ram , since update is used rarely and you have limitations like number of times that you can update a flash memory, so, it is not a problem to save it to flash in the esp8266 neither the stm32
Best regards
I'm about to buy a huge amount of USB sticks in order to install a custom OS in them. Do they need a special hardware configuration to make the MBR section suitable for booting? or just by defining it is enough?
Any USB stick can be turned into a bootable USB. They don't need any special configuration. I use universal USB installer software to make a bootable pen drive. You can search on YouTube. It's a 5 minutes process.
All I know is It helps in initializing processor hardware and operating system.
First I need to know what is a firmware and how it works.
Probably showing a list of firmware and what they do can be a good idea for explanation.
Typically, microprocessors performa start up process that usually takes the form of "begin execution of the code that is found starting at a specific address" or "look for a multibyte code at a pinpointed location and jump to the indicated locale to begin execution"
Since the introduction of IC ROM, with its many variants, including, but not limited to mask programmed ROMs, and programmable ROMs, and EPROMs. Since this time, firmware boot programs were shipped and isntalled on computers. Then the introduction of an external ROM was an italian telephone switching elaborator, called "Gruppi Speciali".
When a computer's turned off, it's software remains stored on nonvolatile data devices such as HDDs CDs DVDs SD cards, USBs, floppies, etc. WHen the computer's powere don, it doen't have an operating system or its lloader in RAM, it first of all executes a relatively small program stored in ROM, along with a small amount of needed data to access the nonvolatile device or devices from which the operating system programs the data and can be uploaded into RAM, this small program being known as a bootstrap loader.
I have a NIC card and a HDD both connected on PCIe slots in a Linux machine. Ideally, I'd like to funnel incoming packets to the HDD without involving the CPU, or involving it minimally. Is it possible to set up direct communication along the PCI bus like that? Does anyone have pointers as to what to read up on to get started on a project like this?
Thanks all.
Not sure if you are asking about PCI or PCIe. You used both terms, and the answer is different for each.
If you are talking about a legacy PCI bus: The answer is "yes". Board to board DMA is doable. Video capture boards may DMA video frames directly into your graphics card memory for example.
In your example, the video card could DMA directly to a storage device. However, the data would be quite "raw". Your NIC would have no concept of a filesystem for example. You also need to make sure you can program the NIC's DMA engine to sit within the confines of your SATA controller's registers. You don't want to walk off the end of the BAR!
If you are talking about a modern PCIe bus: The answer is "typically no, but it depends". Peer-to-peer bus transactions are a funny thing in the PCI Express Spec. Root complex devices are not required to support it.
In my testing, peer-to-peer DMA will work, if your devices are behind a PCIe switch (not directly plugged into the motherboard). However, if your devices are connected directly to the chipset (Root Complex), peer-to-peer DMA will not work, except in some special cases. The most notable special case would be the video capture example I mentioned earlier. The special cases are mentioned in the chipset datasheets.
We have tested the peer-to-peer PCIe DMA with a few different Intel and AMD chipsets and found consistent behavior. Have not tested the most recent generations of chipsets though. (We have discussed the lack of peer-to-peer PCIe DMA support with Intel, not sure if our feedback has had any impact on their Engineering dept.)
Assuming that both the NIC card and the HDD are End Points (or Legacy Endpoints) you cannot funnel traffic without involving the Root Complex (CPU).
PCIe, unlike PCI or PCI-X, is not a bus but a link, thus any transaction from an Endpoint device (say the NIC) would have to travel through the Root Complex (CPU) in order to get to another branch (HDD).