Using Hyper-V, I am running a Windows XP machine and I have a virtual floppy drive mounted too, where, using the following code, I am writing the bootloader.bin into the virtual floppy drive.
>debug
-n bootloader.bin
-l 0
-w 0 0 0 1
-quit
This is working well with a virtual floppy drive. I am compiling the asm files using NASM. However, I want to get my custom OS along with the new kernel.bin on a flash drive. Now, I saw that the mikeOS source has an ISO image, but I cannot get that on my flash drive using traditional methods, since it uses the own bootleader.
I am looking for a way in which I can get this OS working on any x86 PCs. I need a way to migrate the storage. Also, I do not wish to use a CD-R for this purpose. The memory should be rewritable.
You should be able to put a raw floppy image (or bootloader) straight onto the USB. Use a raw burning program to do so. If you have your own VFD or ISO, you could use UNetbootin to put in onto the USB as it will assist in the booting process. If you have just the files, you could use Winimage to create a VFD or ISO with those files. If you feel stuck, go back to the MikeOS handbooks. They have a lot of helpful information.
UPDATE
In your case, you can easily use UNetbootin.
Download it for your platform (I assume Windows). You should have only one executable file.
Run the the executable file. NOTE: It isn't an installer.
Select 'diskimage' instead of 'Distribution'.
Change 'ISO' to 'Floppy'.
Select your VFD's location.
Select the type of disk you want to write to. In this case, USB Drive is default.
Select the drive, in this case drive G:\. BE SURE THAT YOU PICK THE RIGHT ONE. THAT DRIVE WILL BE COMPLETELY WIPED BEFORE INSTALLATION!
Click OK. If everything goes good, you'll now have a bootable USB for your OS.
I hope this helps!
"Format" it in assembly language, assemble, mount the image with ImDisk and copy the files over. This can all be done with a cmd script.
While you're at it take a look at The 1.44MB FAT32 floppy disk and MikeOS-4.5 FAT32 (16-bit real mode) to see how simple it is to use FAT32 instead of FAT12.
PS. The formatting is done in bootload.asm in the MikeOS-4.5 FAT32 (16-bit real mode) distribution.
Related
I have a portable VSCode install on an external USB SSD.
I need it to switch systems a lot and still have a familiar environment.
However, some systems I work on dont have powershell.
So, I have downloaded a portable install to the USB.
I know how to set up this to use it, but it makes problems when e.g. the drive letter changes, because that alters the path.
How do i relative that?
e.g. use a path like:
{VSCodeDir}\powershell\pwsh.exe
According to this reference, there is
${execPath} - location of Code.exe
I have a computer which is not to be connected to the internet for security reasons. It is running Linux. On a separate computer, I have code and a cross compiler for linux. When I move the program over to the offline Linux computer, I cannot execute it, due to an error " version `GLIBC_2.17' not found "
After checking /lib, I see that I do indeed only have version 2.13 of libc. On my development computer, I have all the relevant files for the 2.22 version which is being used to compile the program. I would like to somehow copy this version of libc on my development computer over to my offline computer so that I can run my program.
The problem is, I cannot seem to copy the files. Attempting to do so gives an error:
mv: error writing ‘./libc.so.6’: No space left on device
or something similar. I know this is not actually due to there not being space left on the device, because I don't have much of anything ON the device, and I can copy the files to other places in the filesystem, just not to the /lib directory. How can I migrate my newer version of libc over to the offline computer?
I would like to somehow copy this version of libc on my development computer over to my offline computer so that I can run my program.
Incorrectly updating libc on your "offline" computer is a very easy way to render it unbootable. You should not attempt this unless you understand what you are doing (which you clearly do not), and unless you know how to restore "offline" computer in case of failure.
The best approach is to use the package manager on the "offline" computer to install libc package correctly (details vary on what package manager is being used).
If the package manager approach doesn't work, you can copy individual files. Hoever note that system ld-linux.so and libc.so.6 must match at all times, or every dynamically linked program (your shell, cp, mv etc.) will break.
Since you need to update two files simultaneously, how could this be done? You need a statically-linked copy of cp. It is best to have a statically-linked copy of $SHELL and ln as well (in case you make a mistake).
I installed (extracted) msysgit portable (PortableGit-1.9.5-preview20150319.7z)
The compressed archive is 23 MB, but once extracted the contents take up 262 MB. This is mostly due to the git command binaries (under 'libexec\git-core'). Almost all of the binaries are identical, they just have different names.
Why did the developers build the project like this? I suppose they need an executable for each command to support the CLI on windows cmd.exe.
But isn't there a way to avoid having ~100 identical binaries, each 1.5 MB in size (ex: using batch files)?
Why did the developers build the project like this? I suppose they
need an executable for each command to support the CLI on windows
cmd.exe.
Under unixoid OSes, you can have symbolic links to another file that behave exactly like the original file; if you do that for your executable, your executable can look into argv[0] to find out how it was called. That's a very common trick for many programs.
Under Windows, and especially without installers, it's (to my knowledge) impossible to get the same behaviour out of your file system -- there's just no symbolic link equivalent. Especially when you consider that programs that are meant to run from USB drives have to cope with ancient filesystems such as FAT32!
Thus, the executables simply were copied over. Same functionality, more storage. However, on a modern machine that you'd run windows on, you really don't care about 200MB give or take for such a versatile tool such as git.
In conclusion: the developers had no choice here; since windows (though having some posix abstraction layer) has no proper filesystem support for symbolic links, that was the only good way to port this unix-originating program. You either shouldn't care or use an OS that behaves better in that respect. I'd recommend the latter, but OS choices often aren't made freely...
I can build and manually execute an EFI application in a UEFI environment. But, I'd like to have my application executed automatically at boot time.
Is there a way to tell the bootloader to do this or do I need to turn my application in to a driver to have it automatically executed? Is there maybe some entry in an FDF, DEC, DSC, or INF file I'm missing?
You can add a startup.nsh script file to your UEFI Shell boot drive that calls you application.
The following link should serve as a handy reference for working with scripts in the shell: UEFI Shells and Scripting. Look at section 3 (EFI Shell Scripts) specifically.
However, if you are actually building your own firmware, you can also look at creating a bootable EFI image and set your default boot option to this binary. This is most useful if you are including the binary as a part of your ROM, but it might be a little involved to set up the filesystem so that it is seen as a normal boot option.
Also, if you have complete access to your firmware source, you could also just load and call your binary from your BDS driver. I don't recommend this route, unless you are specifically aiming to create a standalone device that will never boot any other image.
#NicholasEmbry answer contain almost all what is needed, but I would like to clarify some things and add recent improvements in that area.
Adding UEFI application image to boot option is actually best known method when you don't have source code of your firmware, what is typical situation. You don't have to create any special bootable image it should be simple UEFI application image, what means that your INF should contain:
MODULE_TYPE = UEFI_APPLICATION
This option is not just for Option ROMs this is for all UEFI readable medium. For example you can create FAT32 partition on your storage (no matter if it is USB, HDD, SSD, etc. it just have to be readable by firmware) and place application image on this partition. Then boot to UEFI Shell and use bcfg command to affect your boot order.
bcfg command can be blocked by you BIOS vendor. In that situation please follow procedure from this post. This is booting rEFInd using USB stick. rEFInd contain bcfg tool and give you ability to use it.
How to use bcfg ?
All is described in help help bcfg -b. -b is UEFI pager. For those who like shortcuts, this command will display all boot options in system:
bcfg boot dump -v
You can add your application using command:
bcfg boot add <boot_pos> <path_to_uefi_image> <boot_order_name>
<boot_pos> - position in boot order. Note you usually want to put your application before OS. If there is no free boot option number before your OS you can of course move your OS one option down bcfg boot mv <old_pos> <new_pos> and then add your application image in between.
<path_to_uefi_image> - path to your UEFI image. This is UEFI readable path ie. fs0:\foobar.efi
<boot_order_name> - this is how you application will be visible in boot BIOS menu
I have a hello world bootloader code in assembly written (I'm sure I coded it right). I have the .bin file with me and .exe also.
I want to test it now with a USB, how do I do it? Everything I googled out and found on the topic pretty much didn't work out.
I have tried the way with "Disk Explorer NTFS 3.66". I have also tried the mkbt way. Both of them though mentioned highly in blogs/forums/etc don't seem to work for some reason.
Disk Explorer is not letting me paste from file onto the bootsector.
Any ideas/help is much appreciated.
I am 99.9% sure that you won't be able to use bootloader with USB. Because, bootloader is initialized first then it loads the Operating System, which loads USB drivers. It can work if you can trick your machine to look for USB as a primary booting device (I was using a P4 with XP and couldn't get my system to do it). The thing that worked for me was a Floopy Drive, it was back in 2006 !
You can use a Virtual Machine as suggested by Federico, and emulate the USB drive as a booting device, that's the best option.
Follow the link given below . I think it will help you to make bootloader as "Hello World" in your usb .
http://pcguide4you.blogspot.in/2011/09/designing-simple-hello-world-bootloader.html