New chain uboot and fip, but uImage and dtb separately (no fit).
Good to know that this is possibleā¦i thought new atf needs fit image
It looks like you install directly to sdcard. Imho it would be better to create img which can be ddād to sdcard
What may be good alignment settings for page and block sizes, may be bad settings for another SD card.
This will result in more read/write operations and thus is bad for performance and wear.
The script also installs sources and builds from there. After that you can build also running on R64
If you really need image you can dd from SD cardā¦ Could add this as optionā¦
Problem i see is if booting from sdcard and creating system on sd you kill existing system (if not booted from emmc or into ramdisk)
For now only kernel and boot can be build on R64.
For kernel one could use a different local version number. New kernel only installed if build is successful. Only uEnv.txt needs to be altered to switch to old kernel.
If boot is messed up, for now SD card needs to be removed and boot reinstalled from laptop or so.
Creating new rootfs (on emmc) when running on R64 is still to be implemented, but disabled for now. Everything about installing to emmc is still untested.
I have not done anything on emmc yet. Is it totally safe to mess emmc up? Can you always boot SD with the switch, no matter what is on emmc?
Have you tried the sdmmc header on emmc?
As emmc can be written from system booted from sd imho it not possible to mess up emmc (except write bruteforce or lifetime defect).
Bootswitch selects first device for booring,then the other is found. So if you have a bootable system on emmc,system can boot from it if no sdcard is inserted (bootswitch 1) or bootswitch is in position 0 (try emmc first).
Emmc needs additional setup (partition config 0x48 + bl2 in boot0 block) and different atf on userpart. Imho emmc bootheader is needed too. See my atf repo for more
Next version can use loop-device instead of sd-card.
Also function to create a cleaned up archive from sd-card or loopdev From loopdev needs some rework.
Some functions, like uboot settings in separate files.
Now available in last commit. Should work, but needs more thourough testing for bugsā¦
1 Like
Since I do not like binaries, Iāve reverse engineered echo-bpir64-mbr.c, located in the tools folder. Now every byte of the header actually makes sense.
It is possible to change the bl2 partition start and size sectors. In theory the mt7622 should start from the partition even if moved in the mbr data. Not tested jet.
1 Like
Now can build and install emmc version, running on sd version. Tested up until running in uboot, from there it should be fine. Installing to emmc automated.
Note that the rootpartition on emmc has a different partlabel then the rootpartition on sdmmc. This way uboot on emmc can find the corresponding rootfs and uboot on sdmmc can find the other rootfs as well.
Of course it can build the emmc version to image as well, but that leaves installing it to the user. (( The image will still hold the bl2 partition. This needs to be copied to mmcblk0boot0 and can be done with a few commands. ))
How about bootchain v3.0?
Why use mmcblk0boot0 when booting from emmc? Why not use mmcblk0 as boot device?
The below assumes the following:
- /dev/mmcblk0 is the emmc device
- Started up from sd-card
- EMMC boot image build and copied to /root/bl2.img
- Using mkimage instead of bromimage to make bl2.img
Booting from mmcblk0 should be as easy as the following:
mmc bootpart enable 7 1 /dev/mmcblk0
dd of=/dev/mmcblk0 if=/root/bl2.img
Make sure mmcblk0boot0 is really empty:
echo 0 >/sys/block/mmcblk0boot0/force_ro
dd of=/dev/mmcblk0boot0 if=/dev/zero
echo 1 >/sys/block/mmcblk0boot0/force_ro
And voila, we boot from mmcblk0 into BL2, but now the GPT table is overwritten, the blocks are now used by the MediaTek BootROM Loadable Image. This is a problem, since BL2 uses GPT to find the FIP image.
Since the header on LBA-0 has a field that states the size of this header, why not expand this header so it uses 34 sectors instead of just the one? This first header is not included in the sha32 check, so the extra space can be overwritten later.
diff -NarU 6 a/tools/mtk_image.h b/tools/mtk_image.h
--- a/tools/mtk_image.h 2021-06-10 20:32:04.156559289 +0200
+++ b/tools/mtk_image.h 2021-06-10 20:32:36.964722097 +0200
@@ -16,13 +16,13 @@
struct {
char name[12];
uint32_t version;
uint32_t size;
};
- uint8_t pad[0x200];
+ uint8_t pad[0x4400];
};
#define EMMC_BOOT_NAME "EMMC_BOOT"
#define SF_BOOT_NAME "SF_BOOT"
#define SDMMC_BOOT_NAME "SDMMC_BOOT"
But now mkimage runs in to a buffer overflow problem, which can be solved by adding 64kb to the buffer:
diff -NarU 1 a/tools/mtk_image.c b/tools/mtk_image.c
--- a/tools/mtk_image.c 2021-06-11 13:26:11.580666817 +0200
+++ b/tools/mtk_image.c 2021-06-11 13:29:14.024018325 +0200
@@ -262,3 +262,3 @@
/* GFH header + 2 * 4KB pages of NAND */
-static char hdr_tmp[sizeof(struct gfh_header) + 0x2000];
+static char hdr_tmp[sizeof(struct gfh_header) + 0x2000 + 0x10000];
Now we build and write the image again:
dd of=/dev/mmcblk0 if=/root/bl2.img
Test it and still boots OK.
Now restore the GPT table, Also restore the last 72 bytes of the header_emmc.bin, as it tells the system that the whole device is being used by GPT.
And voila! Perfect boot from /dev/mmcblk0, tested now until booting in to uboot.
Now in latest commit in the buildR64ubuntu script 
On the sdmmc image we can keep everything the same as emmc, but donāt forget to make atf with DEVICE_HEADER_OFFSET=0 then.
Expanding the first header may also be quite useful for openwrt and other images I thinkā¦
If i understand you right,first emmc header is booted (first byte of userpart) then boot0 (bl2) then fip?
With your changes we can skip boot0 and have nearly same image for sd and emmc (except headers,bl2 and bl31)?
Correct
BL2 for emmc is also on mmcblk0, also the same as sdmmc.
mmcblk0boot0 is totally not used anymore
BRLYT header is on sector 34 of mmcblk0, followed by BL2 . Then BL2 uses gpt to find FIP and starts FIP.
And exactly, the images are almost the same now.
Have also looked at using the header_sdmmc.bin and DEVICE_HEADER_OFFSET for emmc atf build. Then the patches would not be necessary. But it seems like emmc boot does not look at the MBR partition table to find a bootable partition. This only seems to happen with sdmmc boot. Therefore we do need these patches if you want to boot from mmcblk0
Now added a release to the repository. It has 2 pre-build images for try-out.
1 Like
Hello, Iāve tried SD and EMMC images and in both no wifi interfaces:
āiw devā or āip link showā shows nothing like wlan0 or wlp3s0b1 ā¦
also, the same with image ādebian buster with new bootchain and linux 5.10āā¦
but image āUbuntu 18.04 with kernel 5.4.0ā works.
also ādmesg |grep mt76ā shows no errors
That is really strange that in both images, from buildR64ubuntu and in the 5.10 debian image, it doesnāt work.
I have only tested the images with nothing in the pcie slots and with wifi of the board itself only 1 antenna on the WF0 connector.
What version of the board do you have?
Btw, buildR64ubuntu needs a fix still to load eeprom settings from file. The wifi therefore isnāt fully initiated correctly. But anyway, wlan0 should be there and works with limited range.
Iām not sure i have included firmware in the new image
the new R64 with mt7615 module, from this May.
I like these smooth and quick images. also it would be good to decrease idle tempreachar for easy passive cooling.
Could be firmware files are missing in my images as well. The script once in a while skipped them on error. Need to update the script thereā¦ Need to check if the files are on the image laterā¦
What is it you like to change about the temperature? There is a separate topic in this forum for that issueā¦