I have written a simple bootloader for x86 using NASM and it was converted into boot.bin,i wrote first logical sector of USB Pendrive using dd(in Windows, downloaded from chrysocome site) but it is not taken when i try to boot with actual PC(used Dell labtops),should i write it in physical first sector?
Related
I am building kernels in my company.
Currently we have asurface 3 (non pro) device here and it sould boot with our own kernel and miniroot.
so far it boots up, but doesnt detect the eMMC memory.
IN the future more eMMC devices should be supported so I added a lot of mmc drivers directly into the kernel. We are limited to 90MB miniroot size, so every driver usually is build into the kernel
here's the current mmc config
cat kernel/config-x86_64-4.4.11 | grep MMC
# CONFIG_PCI_MMCONFIG is not set
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
# MMC/SD/SDIO Card Drivers
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_MMC_TEST=y
# MMC/SD/SDIO Host Controller Drivers
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PCI=y
# CONFIG_MMC_RICOH_MMC is not set
CONFIG_MMC_SDHCI_ACPI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_WBSD=y
CONFIG_MMC_TIFM_SD=y
CONFIG_MMC_SDRICOH_CS=y
CONFIG_MMC_CB710=y
CONFIG_MMC_VIA_SDMMC=y
CONFIG_MMC_VUB300=y
CONFIG_MMC_USHC=y
CONFIG_MMC_USDHI6ROL0=y
# CONFIG_MMC_REALTEK_USB is not set
CONFIG_MMC_TOSHIBA_PCI=y
CONFIG_MMC_MTK=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PCI=y
CONFIG_MMC_SDHCI_ACPI=y
CONFIG_MMC_SDHCI_PLTFM=y
Still the mmcblk device does not show up.
any suggestions on how to make this work? Any modules I might be missing?
Cheers
Well the Surface 3 Tablet works a little bit different
After adding GPIO kernel modules the eMMC memory got recognized and usable
I'm studying boot steps on a Pandaboard. According to this how-to, they have multiple boot steps (Boot rom > X-loader or SPL > U-boot > Linux kernel). Actually, I do not understand why they have such steps inefficiently. Can't I just load u-boot instead of using file called "MLO"? What does "MLO" actually do? Are there any important reasons that they have to put "MLO" instead of loading u-boot directly?
From eLinux.org:
http://elinux.org/Panda_How_to_MLO_%26_u-boot
The first-stage bootloader runs directly on the board from power-up. I
don't know the name of this bootloader(From TI official wiki, it
called Boot Rom). This bootloader initializes a minimal amount of CPU
and board hardware, then accesses the first partition of the SD card
(which must be in FAT format), and loads a file called "MLO", and
executes it. "MLO" is the second-stage bootloader.
The second-stage bootloader can apparently be one of either the
X-loader or SPL. This bootloader apparently also just reads the first
partition of the SD card, and loads a file called "u-boot.bin", and
executes it. "u-boot.bin" is the third-stage bootloader.
The third-stage bootloader is U-boot, which is a popular bootloader
for many different embedded boards and products. This bootloader has
lots of different features, including an interactive shell, variables,
ability to access the SD card and show its contents, etc. What happens
next depends on the version of U-boot you have for the Panda board,
and how it is configured. In a very simple configuration, U-Boot will
look for the file "uImage" in the root of the first partition of the
SD card (which, again, must be formatted as a FAT partition), and
execute that. This is the Linux kernel. U-Boot passes the kernel a
command line argument. Depending on how the kernel is configured it
may accept the command line from U-Boot, or use one that was compiled
into it when it was built.
This is a "Panda Board thing", not necessarily true of Linux in general.
However, most all systems have some kind of "multi-stage" boot like the one above. For example, booting a PC running Windows, you see:
BIOS startup
Boot sector is loaded from disk or USB; or a PXE boot record is read from the network
The windows kernel starts (the stuff you see before/during the "splash screen")
Finally, "Windows" itself starts
So it's neither "inefficient", nor unusual.
PS:
This link also has a good description of the boot load sequence:
http://omappedia.org/wiki/Bootloader_Project
PPS:
"MLO" stands for "Mmc LOader"
When the board comes up, the Memory Management Unit (MMU) still needs to be setup before the CPU can start using the SDRAM. The SoC has 56KB of SRAM which can be used at that point, but it is too small for u-boot to run from. The extra step is code running from SRAM will load and start u-boot.
Problem
The problem I'm having was caused by the following action: When I had BBB connected to my PC (using USB cable), I accidentally formatted the ~92 MB partion that contained the getting started files.
Because of this, each time I apply power to BBB, the USB LEDs do not light up. It only works when I have the Angstrom image on an external microSD card.
What I've tried
I thought that this was caused because the eMMC is corrupt and for some reason is not bootable. So, I tried to boot from the external microSD card (that has the newest image running) and to use dd command where if was equal to the current microSD card and of to the target microSD card (built in on the board).
When I restarted the BBB, I looks like dd was successful (when I executed it, it told me that everything was successful). Now, there is one partition with the GettingStarted files and another with the Linux kernel.
Question
Despite this, it's not possible to boot from the internal microSD card. Does anyone know how this can be solved? Is there something to do with the boot order?
To force a boot from SD you need to remove power from the board completely, hold down S2 and then re-apply power. Keep holding the button until the four leds start turning on. You have to do this at power on, and once you've done it the board will continue to boot from SD on a reboot or reset, only removing power will change the behaviour.
You could also move R68 to R93 if you want to make the board boot from SD by default.
Also note the boot sequence in the table on page 6 of the schematics, by default if MLO can't be found on the eMMC, it'll look for it on the SD card. So deleting MLO normally causes the board to boot from SD if the appropriate files are present.
According to the Beaglebone Black Cook Book,
the card boots from the SD if available.
This is also how it work with Debian 8.3 image for BBB
(note that I am using the version of the image that does NOT
flash...).
I am using a rockchip 3188 based system on board which has 8 gb NAND flash.
I want to test the reliability of the NAND flash.
At least , I want to identify boards with bad NAND flashes shipping from factory.
I am using Ubuntu 14.04.
The NAND flash is partitioned into two parts :
1. mtd0: contains bootloader, kernel and initrd
2. mtd1: contains RFS
I tried running mtd_stresstest by "modprobe mtd_stresstest dev=1" and it never says a word. If I run it for too long, my system is getting corrupted. The corruption is expected as it is playing with the same device / is mounted on.
But the command is not returning even if I use count=1.
Please let me know what is going wrong.
I tried the following too:
Flashed a USB stick with ubuntu rfs meant for arm and plugged it to SOB.
bind mounted /proc to /media//proc
bind mounted /sys to /media/
cd /media/
chroot .
init 1
modprobe mtd_stresstest dev=1 count=1 ----> never says a word
Could you please also suggest if there is any other way test the NAND flash device reliability.
I'm reading source code of FreeBSD and found that they have 2 files which may be used to create MBR - sys/boot/i386/boot0/boot0.S and sys/boot/i386/mbr/mbr.S.
From current my understanding boot0.S is the code in MBR (first sector of boot disk drive which is loaded by BIOS) in FreeBSD.
Then what is the mbr.S? What is the relationship between them?
I'm reading source code from FreeBSD 8.2.0.
boot0.S contains the MBR for the Boot Easy boot manager, that allows selecting an OS to boot. mbr.S contains a generic MBR that just boots the active partition.
You should take a look at the FreeBSD handbook.