Installing bootloaders - operating-system

I am creating a toy os and cannot find a good way to install the bootloader onto the first sector of a drive.
I use PARTCOPY but that only works on xp with floppy disks.
Does anyone know a program or method to install a 512 byte bin file onto the first sector of a drive. Preferably the program can also read the first sector of a drive.
I am running windows

dd in Linux can do that:
http://www.cyberciti.biz/faq/howto-copy-mbr/
For example (http://en.wikipedia.org/wiki/Dd_%28Unix%29#Master_boot_record_backup_and_restore),
to backup the first sector of a harddrive:
dd if=/dev/sda of=MBR.img bs=512 count=1
to restore the first sector:
dd if=MBR.image of=/dev/sda
You can change /dev/sda to /dev/sda1 if you want to target the first partition instead of the entire disk.

Related

flashing yocto image to raspberrypi cm3 eMMC

I have build a yocto image for raspberrypi cm3 and i want to flash it to the eMMC.
In the deploy/images/raspberrypi-cm3 directory a don't have a .img file that would be flashed and also how can i knew if my image will boot directly when starting.
actually this is the first time i work with yocto and the first time i flash an image to a board.
THis is my deploy/image directory content.
I will be greatful if someone explains it to me.
thank you.
enter image description here
Thank youf or the answer.
As i understanded, the mount command line is to create a disk image and makes it readable by the system. So after copying all image directory to it and unmounted it, what would i have in the 'if' option when i will flash my image with 'dd if=/home/user/deploy/images/raspberry-cm3 of=/dev/mmcblk1 '.
Also when a tried to mount the disk image 'sudo mount -o loop raspberry-cm3.img /media/raspberry-cm3/'.
error:mount: mount point /media/raspberry-cm3/ does not exist.
Could you please help me with that ?
This question should be on Super User.
You can flash a image using Linux's dd command-line tool.
For example:
dd if=/home/user/deploy/images/raspberry-cm3 of=/dev/mmcblk1
Make sure you're using the correct device in the output (ie, make sure /dev/mmcblk1 is your eMMC card)
Edit: in order to flash, you'll need to generate an image. You can do it by creating an empty image, then mounting it as loop, then copying all the directory tree into the disk, and unmount it:
dd bs=512 count=2880 if=/dev/zero of=raspberry-cm3.img
mkfs.msdos raspberry-cm3.img
sudo mount -o loop raspberry-cm3.img /media/raspberry-cm3/
cp -r /deploy/images/raspberry-cm3/* /media/raspberry-cm3/
sudo umount /media/raspberry-cm3/
As i understanded, the mount command line is to create a disk image and makes it readable by the system. So after copying all image directory to it and unmounted it, what would i have in the 'if' option when i will flash my image with 'dd if=/home/user/deploy/images/raspberry-cm3 of=/dev/mmcblk1 '. would it be 'dd if=/media/raspberry-cm3/ of=/dev/mmcblk1 ' ?

Objcopy elf to bin file

I have STM32F404 board and I am trying to flash it. I am following this tutorial.
In the project Makefile
$(PROJ_NAME).elf: $(SRCS)
$(CC) $(CFLAGS) $^ -o $#
$(OBJCOPY) -O ihex $(PROJ_NAME).elf $(PROJ_NAME).hex
$(OBJCOPY) -O binary $(PROJ_NAME).elf $(PROJ_NAME).bin
burn: proj
$(STLINK)/st-flash write $(PROJ_NAME).bin 0x8000000
The bin file is generated using OBJCOPYand then flashed using the Make target burn
My questions :
Question 1: What does OBJCOPY=arm-none-eabi-objcopy in this case. I opened the man but I didn't fully undrestand can anyone explain it simply ?
Question 2: Flashing the bin file gives the expected result (Leds blinking) However the leds are not blinking by flashing the elf file $(STLINK)/st-flash write $(PROJ_NAME).elf 0x8000000 so why ?
Question 1: What does OBJCOPY=arm-none-eabi-objcopy in this case. I opened the man but I didn't fully undrestand can anyone explain it simply ?
It assigns value arm-none-eabi-objcopy to make variable OBJCOPY.
When make executes this command:
$(OBJCOPY) -O binary $(PROJ_NAME).elf $(PROJ_NAME).bin
the actual command that runs is
arm-none-eabi-objcopy -O binary tim_time_base.elf tim_time_base.bin
Question 2: Flashing the bin file gives the expected result (Leds blinking) However the leds are not blinking by flashing the elf file $(STLINK)/st-flash write $(PROJ_NAME).elf 0x8000000 so why?
The tim_time_base.elf is an ELF file -- it has metadata associated with it. Run arm-none-eabi-readelf -h tim_time_base.elf to see what some of this metadata are.
But when you processor jumps to location 0x8000000 after reset, it is expecting to find executable instructions, not metadata. When it finds "garbage" it doesn't understand, it probably just halts. It certainly doesn't find instructions to blink the lights.
In case someone wants to use the DFU ("Do a Firmware Upgrade") function, this tutorial teaches how to use the binary file to be loaded via USB, when the STM32 is operating with USB Host (or maybe OTG):
STM32 USB training - 11.3 USB MSC DFU host labs
This tutorial is part of a series of videos that are highly recommended for the programmer to watch, to understand a little better how the STM32 USB ports work and use (videos provided by the STM32 manufacturer itself, I recommend that the programmer watch all the videos on this channel):
MOOC - STM32 USB training
Notes: The example code from the STM32 tutorials are available in the descriptions of the videos themselves.
The binary file (*.bin) can be obtained with the help of the command that the colleague above explained (Employed Russian), and it (command) can also be adapted to produce a file containing the comparison value for CRC usage, as can be seen some details in these following posts:
Hands-on: CRC Checksum Generation
Srec_cat could be used to generate CRC checksum and put it into HEX
file. To simplify the process, please put srec_cat.exe into the root
of project folder.
Some tips and solutions about this CRC usage (Windows/Linux)
Unfortunately the amount of code is too big to post here directly, but I leave the code related to the other answer below:
arm-none-eabi-objcopy -O ihex "${BuildArtifactFileBaseName}.elf"
"${BuildArtifactFileBaseName}.hex" && ..\checksum.bat
${BuildArtifactFileBaseName}.hex
Contents of the checksum.bat file:
#!/bin/bash
# Windows [Dos comment: REM]:
#..\srec_cat.exe %1 -Intel -fill 0xFF 0x08000000 0x080FFFFC -STM32 0x080FFFFC -o ROM.hex -Intel
# Linux [Linux comment: #]:
srec_cat $1 -Intel -fill 0xFF 0x08000000 0x080FFFFC -STM32 0x080FFFFC -o ROM.hex -Intel
Note: In this case, the file to be written is ROM.hex (you will need to configure the STM32CubeIDE to be able to do this operation, the IDE uses the *.elf file, see how to do it in the tips above)
This other tutorial deals with using the file with *.DFU extension:
DFU - DfuSe
The key benefits of the DFU Boatloader are: No specific tools such us
JTAG, ST-LINK or USB-to-UART cable are needed. The ability to program
an "empty" STM32 device in a newly-assembled board via USB. And easy
upgrade the STM32 firmware during development or pre-production.
This need to use a HEX file facilitates the operation of the implementation of the ROM.hex file generated with the CRC value, being practically a continuity:
You must generate a .DFU file from an .HEX or .S19 file, for do this
use the DFU File Manager.
But it seems that using the *.DFU file is not as standalone as using the *.BIN file, so I found this other code that converts the HEX file (generated with CRC) to the *.BIN file, which can be used with a USB stick, as per the tutorial cited at the beginning of this answer (11.3 USB MSC DFU host):
objcopy --input-target=ihex --output-target=binary code00.hex code00.bin
Source
It sounds a little confusing, but we have these steps:
1- The STM32CubeIDE generates the *.elf file.
2- After compilation, the *.elf file is converted to *.hex.
3- CRC value is added in *.hex file via srec_cat application.
4- Now the *.hex file is converted to *.bin.
5- The BIN file is then stored on a USB flash drive.
6- STM32 updates firmware using USB flash drive file.
To use the *.BIN file it is necessary that the STM32 is already programmed to load the BIN file. If it is not programmed (the STM32 is empty, virgin or the program was not made to load the BIN file), it will be necessary to use St-Link or another programmer, or perhaps making use of the DFU method described in the tutorial above (DFU - DfuSe).

How to modify the user space and kernel space in xv6?

XV6 has 2 GB for user space and 2 GB for kernel space. If I want to change it to 3 GB for user space and 1 GB for kernel space. How should I implement this modification?
I tried modify KERNBASE + PHYSTOP in memlayout.h and then modify the start address in the linker script kernel.ld. But it failed.
Your approach is not wrong. Are you running xv6 using QEMU? If so, modify the Makefile and increase the memory to 4GB or more.
There are place where memory is set using the -m option around line 215 of the file. The default is 512 GB.
QEMUOPTS = -drive file=fs.img,index=1,media=disk,format=raw -drive file=xv6.img,index=0,media=disk,format=raw -smp $(CPUS) -m 512 $(QEMUEXTRA)
Then modify the memlayout.h and the kernel.ld file.
Probably it should work. If xv6 does not work, please tell me the part that failed. Please also show the modified memlayout.h and kernel.ld file.

Copying large files using Remote Desktop

I have a 4 GB text file, compressed to 1.4 GB zip file. I need to copy it over to a Windows secure server using RDP. I am able to copy small files but not this file. It takes 15 mins and then shows an error. Any tips?
You can try to copy it by using Drive Redirection. Here's a tutorial.
BTW, RDP cannot copy files larger than 2GB by using clipboard as said in Microsoft support
window rdp clipboard has limit of about 2GB if you want to copy paste more than 2 gb file then you can try any of these options.
split file into parts like 1 gb each part with help of winrar or any other software
Use any FTP software
map local pc drive for remote desktop session(for move or copy data)
File size doesn't matter - I copied folders through Remote Desktop connection with 30GB and more. While doing this I received "Unspecified error". The Problem is that you aren't allowed to use the clipboard again while you are copying. Doesn't matter if you use the clipboard for the same machine or from the remote machine. To summarize don't use Ctrl+C.
The madness is the error is delayed so you don't recognize quickly that those things relate.
format usb drive as ntfs
connect drive as local resource in remote desktop
NET USE X: \\TSCLIENT\F
robocopy c:\source x:\
net use X: /delete
If you are administrator, you can copy the files of any size over the network using Administrative Shares assuming that it is not purposefully disabled.
Enter the following url on your File Explorer and you will see all the files and folders on your C drive of that computer with read and write access:
\\computername\c$
right-click zip-file >> Properties >> Advanced >> Encrypt contents
open your one-drive or googledrive (if the secure server allows you) and park the encrypted file on there.
(you might have to one-drive space by signing up to a months 365)
https://support.microsoft.com/en-us/office/manage-your-onedrive-storage-and-limits-989fce19-ade6-4e2f-81fb-941eabefee28
I guess it would might be possible to use google datastore or something cloudy.

Shadow copy to clone system volume on Windows XP

I am looking for a program that uses shadow copy to copy the contents of a Windows XP system volume that is running.
I.e. I want to clone the system volume with the following snags:
(1) I want to be able to select which files to copy (i.e. not the entire file system)
(2) This is probably implied by (1), but I also have to avoid sector-by-sector copies
(3) I do not want to clone a file system into an image file and restore to a 3rd drive but want to do a filesystem to filesystem copy
All the backup/clone utilities I looked into stumble on one of above points. Any ideas?
Perhaps this one: Hobocopy