I am making a small hobby operating system that I would like to run from an external media such as CD-ROM or a thumb drive, but to do so I need to be able to read the ISO9660 file system that they use. Could anyone supply me with some sample code? Any help is appreciated.
EDIT:
I need the samples to be 16 bit, since this will be executed in the bootloader
Related
is it possible to replace a ram with higher storage on a machine with a processor of low speed? is speed of processing increased or decreased.
i want to replace the ram drive of my machine with a higher storage ram so that I can try to manipulate the processor speed without changing the processors, will it work?
Yes. You can use faster RAM, currently up to DDR4-4800MHz. Using higher capacity RAM would also be useful if running out of RAM capacity is what’s slowing you down. Using a high-speed solid-state drive (SSD) would also speed up task that require reading or writing from storage, including booting up the computer and running programs that use a lot of assets on the computer. You can also overclock both your CPU and RAM to make them faster, but this may void your warranty.
Additionally, you can use software. For example, you can use CCleaner to remove useless files which clutter your computer. You can also use it to disable unneeded scheduled tasks that your computer runs. If your computer has a spinning-disc hard drive, then you can try defragmenting it by using the built-in Windows defragger, or you can use the Defraggler program from the same people who make CCleaner. Of course, you can also try deleting programs or files you no longer need or use if it’s limited hard drive capacity that’s slowing you down.
If it’s web browsing that’s slow, you may want to consider using a faster browser, like Google Chrome or Firefox. You can also install browser extensions/add-ons like AdBlock and Ghostery to prevent unneeded things from being loaded on pages, making pages load faster.
I've got a Netgear D8500 router which apparently has a wireless IC that doesn't quite match up to the supplied driver firmware. Thus, OOB it works, however whenever there's a firmware update it completely bricks the router because the firmware driver for the WLan IC doesn't take into account this slight IC variation. Very common issue and the router got mothballed.
I'm not entirely clued up on firmware, software, coding etc so please excuse my ignorance, afterall I've come here for help/advice/to learn.
The driver in question is contained within the dhd.ko file in the linux kernel directory in the firmware. Simply put, I've extracted the driver dhd.ko file of a known working firmware for an exactly similar device and replaced the same file in a genuine Netgear firwmare.
The issue is, when it comes to flashing, it fails the CRC32 checksum because obviously, it doesn't match up to the original anymore.
How do I correct this?
EDIT: For a more visual guide, please see the picture here. The top half is of the PUTTY serial terminal after flashing the modified firmware, the bottom half is of 7Zip CRC32 checksum so I think it's an embedded CRC. Possibly in the header?
I’ve found about file management explanations and file system explanations and “file system is part of file management” explanations. But I am wondering if they are the same or two different things? Because I cannot seem to find an article about them.
A modern Operating System, to be portable, must be file system independent. i.e.: It should not matter what type of storage format a given media device contains. At the same time, a media device must contain a specific type of storage format to contain files and folders, and at the same time be Operating System independent.
For example, an OS should be able to handle any file locally, allowing the actual transfer of these files from physical media to the OS (and visa-versa) to be managed by the file system manager. Therefore, an OS can be completely independent of how the file was stored on the media.
With this in mind, there are at least two layers, usually more, of management between the file being viewed and the file on the physical media. Here is a (simple) list of layers that might be used from top down.
OS App viewing the file
OS File Manager
OS File System Manager (allowing multiple file systems)
Specific File System Driver
Media Device Driver
When a call to read a file is made, the app (1) calls the OS File manager (2), which in turn--due to the opening of the file--calls the correct OS File System Manager (3), which then calls the Specific File System Driver (4), which then calls the Media Device Driver (5) for the actual access.
Please note that any or all could have a working cache manager which means calls are processed and returned without calling lower layers. e.g.: each read more than requested in anticipation of another read.
By having multiple layers like this, you can have any (physical) file system and/or media device you wish and the OS would be none the wiser. All you need is a media driver for the specific physical device and a file system manager for the physical format of the contents of the media. As long as these layers all support the common service calls, any format of media and content on that media will be allowed by the OS.
I can see from my OS the informations about my hard disk, RAM and CPU. But I've never told my OS these info.
How does my OS know it?
Is there some place in the hard disk or CPU or RAM that stores this kind of information?
Is there some standard about the format of this kind of information?
SMBIOS (formerly known as DMI) contains much of this information. SMBIOS is a a data structure/API that is part of the BIOS/UEFI firmware and contains info like brand and model of the computer, etc.
The rest is gathered by the OS querying hardware directly.
Answer grabbed from superuser by Mokubai.
You don't need to tell it because each device already knows (or has a way) to identify itself.
If you get the idea that every device is accessed via address and data lines, and in some cases only data lines then you come to the relaisation that in those data lines you need some kind of "protocol" that determines just how you talk to those devices.
In amongst that protocol you have commands that say "read this" and "send that" or "put this over there". It is also relatively easy to have a command that says "identify yourself" which, rather than reading a block of disk or memory or painting a pixel a particular colour, will return a premade string or set of strings that tell the driver or operating system what that device is. Using a series of identity commands you could discover a device type, it's capabilities and what driver might be able to work with it.
You don't need to tell a device what it is, because it already knows. And you don't need to tell the operating system what it is because it can ask the device itself.
You don't tell people what they're called and how they talk, you ask them.
Each device has it's own protocol for these messages, and they don't store the details of other devices because to do so would be insane and near useless given that you can remove any device at any time. Your hard drive doesn't need to store information about your memory or graphics card except for the driver that the operating system uses to talk to it with.
The PC UEFI specification would define a core set of system specifications that every computer has, allowing the processor to be powered up and for a program stored in an EEPROM to begin the asbolute basic system probing necessary to determine the processor, set up the RAM, find a disk and display and thus continue to boot the computer.
From there the UEFI system would hand over to the operating system which would have more detailed probing and identification procedures, but it all starts at the most basic "I have a processor, what is around me?" situation.
There are two case when working on an embedded system.
Embedded system have limited resources like as ARM Cortex M0 Microcontroller with 12 K Flash.
Case 1 :
Common function/module usage for Bootloader and Firmware :
Bootloader and Firmware may need to use same module and function to prevent code duplication. Otherwise, same code will be included both Firmware and Bootloader twice.
We can prevent this by specify the function address and call this function by calling functions by addresses. This is one of the solutions.
Is there any smart method to provide common function usage?
Case 2 :
Sometimes, we need to upgrade firmware. One of the duties of bootloader is firmware upgrades. We can easily upgrade the firmware by overwrite the old one.
As we saw, two case can be implemented separately. But when we merge they, some problems are appeared.
Question :
Bootloader's are generally static objects but firmware's are can be modified. Therefore, common functions are generally located at Bootloaders. But when we need update a common module/function, how can we do?
What are the general or smart approaches which bootloader, firmware structured embedded systems? In Addition, for limited resources.
To discrete common modules/functions, Can one or more additional areas solve this problems.
Firmware, Bootloader and Library(New Area)?
I want to learn general approaches. Is there any paper, book and source about advanced Firmware management?
Thanks
If you share code between your bootloader and your mainline firmware application, then your bootloader will be using this code when it flashes the application space. In order to prevent this condition you must sacrifice the ability to update the common code, otherwise your bootloader will crash.
With only 12k of flash, it's pretty ambitious to expect a bootloader and mainline application to fit. You might consider writing the bootloader in assembly (gasp!). Some Cortex M0 parts (such as the NXP LPC11xx family) have an additional boot ROM which stores some useful functions and help alleviate some of the memory constraints.
Your question states the problem correctly - you cannot have your cake and eat it. Either:
1. You go for a small memory footprint and do not include firmware upgrade logic in the bootloader (i.e bootloader might just validate application image CRC etc but nothing more complicated). Here you could share functions to save space. OR
2. The bootloader has firmware upgrade functionality. Here you have to have shared functions compiled both into app and bootloader. The shared functions should be small - probably not a huge overhead but you need the space that this would take - if you dont have it then you need to go for more memory.
There is no way to share functionality and do firmware upgrade from bootloader reliably.
In lights of the current discussion about security in the firmware update process I would like to add the following for clarification:
Sharing code between the bootloader and the app will open yet another door for the potential attack, so you really want to avoid that.
The bootloader part is the part you actually do not want to change ever, this should be as static as possible. If the bootloader is broken, in-the-field-updates become nearly impossible or at least insecure.
Having said that, you might want to use a different approach.
You could create a maintenance mode for your device.
This mode opens the JTAG interface and allows direct access to memory. Than the service technician could apply the update.
Now you "only" need to secure the activation of the maintenance mode.
The following could work:
Use a UART interface to communicate the activation.
Maintenance system sends its own id and requests maintenance mode via UART
The id of the maintenance system, a random number and a unique system id are sent back to the maintenance system.
The maintenance system sends this id-sequence to your certification server.
If the unique system id and the maintenance systems id is correct, the server will create a signature of the information received and send it back to the maintenance system.
Your system now will receive the signature via UART
Your system verifies the signature against the previously send id-string with a public key stored during production
On a successfull verification maintenance mode is entered
To add security, you definitely want to put some effort into the maintenance systems id following a similar scheme. The ID should basically depend on MAC-address or another unique hardware id and a signature of the same. The ID should be created in a secure environment during production process of the maintenance system. The unique hardware id should be something visible to the outside world, so the server could actually verify, whether the ID received matches with the maintenance system communicating with the server.
This whole setup would give you a secure firmware update without a bootloader.
To have secure firmware updates, common understanding is, that you need a authentication system based on asymmetric encryption like RSA. If you need the verification code anyway, the above will exchange a bootloader capable of accepting updates with a simple UART interface, saving some resources in the process.
Is this something you were looking for?
A commercial bootloader in my experience uses between 4 and 8k of flash memory depending on flash algorithm and a couple of other things. I have been sticking with the same vendor throughout my carreer, so this might vary from your experience.
A digital signature system optimized for embedded systems uses approximately 4.5kByte in flash memory (for an example, see here: https://www.segger.com/emlib-emsecure.html ) and no more RAM than the stack.
You see, that 12k is really really low in terms of having a system which can be updated securely in the field. And even more so, if you want the system to be updated using a bootloader.