Yes. I’m using dd from a macbook, which is assigning /dev/disk# as identifier.
Anyway, cleaned everything, rebuild everything and attached the output. Now there are warnings, but no error. Still no u-boot after copying it to the sd card.
What do you mean with “unmodified uboot”? The one included in the ubuntu-image is working. I did not modify anything in u-boot repository from SINOVOIP yet. I just compiled the image and copied it to the sd card.
In the meantime I downloaded the bootloader from you google drive and copied it to the sd card. With your bootloader there is no problem. Did you cross-compile or compile it natively on the bpi-r2? Am I maybe using the wrong cross-compiler arm-linux-gnueabihf-gcc?
I used crosscompiler gnueabihf like mentioned in the documentations. Maybe anything in repo has changed…i remember a change of any start-address,but think it was lede-bootloader…
Have you installed u-boot-tools (mkimage)? Normally it will result in an error if not installed
Wouldn’t that write u-boot to the integrated emmc? This is not what I’m trying to achieve. I want to build u-boot from the repository on my own and load it to the SD card. Then boot the bananpi from the self-compiled u-boot.
I didn’t try to write anything to the emmc yet. So I’m pretty sure it should be empty. Just to really make sure I zeroed (dd if=/dev/zero ..) the sd card and turned on the bpi-r2. Nothing happened. I think the emmc is empty.
@frank-w I see in your post “How to extend the uboot menu” that apparently you can compile and use your own uboot. Could you please post every step (from cloning the git repository, until insterting the SD card into the bpi-r2) here?
i looked into how the BPI-R2-720P-2k.img was created…preloader is included on sdcard preloader (preloader_iotg7623Np1_emmc.bin) is at 0x800 and uboot (uboot.bin) on 0x50000 (you can dd an 1MB-image from your card and look with bless or similar hexeditor)
Since it was still not working I changed my plans. I took my old clamshell pc, installed linux, and did all your steps and it worked I just hadded to add the section from 0-2k from the ubuntu image, in order to be able to boot. I guess there is some kind of preloader on it to initialize the CPU and the memory.
dd if=ubuntu.img bs=1k count=2 of=/dev/sdb
I attached the part that I used for the sd card (0-2k). Do you have any idea what this is?
I still have no idea what went wrong in my previous tries. I’m still investigating and if I find something I will report it.
the first 10 bytes containing a magic string “SDMMC_BOOT” followed by 10Bytes (00 00 01 00 00 00 00 02 00 00) i don’t know (maybe position of preloader/uboot to jump to) followed by many FF (fill-bytes??). On byte 440 (1b8h) there is the “32-bit disk signature” followed by 0000h (for rw-state). After that Partition-Table starts (MBR 4x16byte) followed by MBR end-marker 55AAh
so i assume that it is enough copy the first 20 bytes to get SDcard to boot (partitiontable should not be involved in boot-process before uboot).
i have wrote down the steps after creating bootable emmc with only these steps, but emmc has bootloader in separate partition (boot0-block) so maybe in SD-Card there is more needed. in my image i used original image with erased partitions.
Indeed those are fill-bytes. I replaced them with 0x00 and it’s still loading uboot.
I can also confirm, that the partition table is not part of the boot process. My SD has no partition table on (i zeroed everythin) and it is still loading uboot.
Questions that are still open for me:
What do the bytes from 0-20 (SDMMC) do?
What is the BRLYT part?
Where are the addresses stored to jump from the preloader (SDMMC) to BRLYT and from BRLYT to 0x800 (uBoot)?
Spent quite a lot of time today debugging why my BPiR2 refuses to boot from SD card if this card has some partitions defined in MBR. Turned out that board seems to ignore SD card in case any entry in partition table is marked as “active” (also known as “boot” flag). In my case I was generating SD card image template using OpenWRT’s ptgen utility which by default sets first primary partition as “active”. Quick fix using fdisk and viola - board is able to boot from this SD card.
Kernel and uEnv.txt reside on /dev/mmcblk0p1 vfat partition (mounted as /boot in openwrt), rootfs is ext4 on /dev/mmcblk0p2. uUnv.txt had been modified a bit compared from your variant so it detects if the system had been booted from eMMD or SD and then it boots the kernel and rootfs from the same device. Original logic in your uEnv.txt was to check if the first partition on SD is a valid FAT filesystem and boot from it even if preloader/u-boot were booted from eMMC. It resulted in nasty behavior for the case when openwrt is installed on eMMC and hardware boot switch is set to eMMC. For such case if an SD card is inserted into the slot and have got valid FAT filesystem on the first partition then u-boot will try to boot from this SD card - which is not what I want. Instead I had implemented two bootmenu options allowing user to select what bootdevice to use.
Ah, and another change is to move u-boot saveenv target offset to be less than 1MB - default partition scheme for modern linux is the first partition to start at 1MB so if u-boot is compiled to saveenv to the first megabyte the first time saveenv is used would result in data corruption on the first partition. Good offset to store saveenv is 950k from the start of the disk: it is far enough to provide plenty room for u-boot itself (950k-320k=630k available for u-boot binary) and leaves 50k for environment storage - which is also more than enough.
Back to openwrt changes:
Had hacked in the support for built-in openwrt’s sysupgrade functionality to allow for easy system upgrades by end-user. It is a “classic openwrt sysupgrade.bin-style” system upgrade: put all known conffiles + all files listed by end-user as “save at sysupgrade” into a tarball, flash the preloader, u-boot, kernel (vfat partition containing kernel and uEnv.txt for our case) and filesystem with new ones coming from sysupgrade file, put saved configs tarball to the root of the rootfs and reboot. Pre-init script will find tarball on the first boot and restore all configuration files to original places.
Currently I’m considering implementing another way of sysupgrading system that is available in openwrt - through sysupgrade.tar. This upgrade style works a bit differently as it only allows for updating kernel and rootfs - which might be great for people who don’t want to update preloader/u-boot and loose uEnv.txt local changes each time they to a sysupgrade. Shouldn’t be that hard to implement but it is time to spend and I’ve got a lot of other things to fix that seem to be more important than this.
Had properly integrated DTS fixes into the openwrt’s kernel patch/build system (fix for second gmac, fix for memory to be 2GB instead of 1GB, add pcie entries). No more ugly “copy dts/dtsi to this directory after executing make target/linux/{clean,prepare}”.
Had created new uboot-mediatek package using openwrt’s u-boot building infrastructure coupled with u-boot patches from your u-boot 2019.01 repo.
What is left to implement is an auto-download functionality for preloader binary. What @Jackzeng had done in latest Openwrt 2018.06.2 based image is an ugly hack: he had put preloader binary files directly into the git repo at staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/image/. It is not upstreamable but it’s not the worst thing here. Main fault with this approach is the fact that staging_dir image target folder gets emptied on make clean. I.e. execute make clean once and get the sudden and surprising build failure on following make target/install. There are several ways to re-implement this properly but fist thing I need is an “official vendor source” for preloader which I can rely on to put the download URL into makefile. I believe you’ve seen my question on this matter in u-boot thread but it looks like vendor representatives have next to none incentive to provide me with an answer .
Nevertheless my end-goal for this project it to try to upstream at least some of these changes into openwrt main tree so it would be less hassle for me in future to maintain my own fork.
how have you done this? Using my getbootdev-function? afair the uboot-cmd is not in actual uboot because i don’t have pushed this part to upstream,only the saveenv-mapping.
I have adapted the original behaviour (and the offset of 1MB) to be compatible to official images. I don’t know atm how bis my current uboot-binary is,but there is a check in build.sh to not overwrite saveenv-position (prevent saveenv overwrite uboot). Original partition scheme starts with first partition at 100 mb…
I do not stick with original partition scheme and prefer to keep limitations to the bare minimum possible. As had been figured out in this thread minimal requirements for board to boot from SD are:
SDBOOT 20 byte signature at offset 0.
BRLYT 32 byte signature at offset 512 (1 sector).
Preloader binary at offset 2048 (2k == 4 sectors).
U-boot raw binary at offset 327680 (320k = 640 sectors).
Only MS-DOS MBR-style partition table label is allowed.
Having u-boot sitting at 320k offset and knowing that u-boot binary is about 300k in size (as of 2019.01 version built from your repo) leaves us with a relatively safe assumption that we may place the start of the first partition at 1MB offset - and it so happens that this offset is a default offset for modern linux-world partitioning tools like fdisk or parted. So I have this patch applied:
This code is not in 2019-01-bri-r2 branch I was basing my work on. FWIS it is in bpi-r2_v5 branch. Anyway I prefer to have direct comparison like “if itest.l *81dffff0 == 434d4d65 ; ...” in uEnv rather than relying on custom command in u-boot that is not available in upstream version. It is just more portable this way - one less patch to care about when porting to more recent version.
Frank, I’m wondering about the magic behind the address 0x81DFFFF0 that you use to determine if it was eMMC or SD card the device had booted from. Looks like this detection is not that reliable:
It is not the first time I see it fail. Sometimes I was getting “eMMC” at this offset even when I was booting from SD. That’s why I’m wondering about the “detection magic” - what was the reasoning behind using this offset as an information source?
I just hadded to add the section from 0-2k from the ubuntu image, in order to be able to boot. I guess there is some kind of preloader on it to initialize the CPU and the memory.
.