Bpi-r64 quick start (boot from eMMC)

i don’t have this menuentry (“GE1 connected to” is the last one)…also see no mt7531-driver in uboot-mt/drivers/net

the 4.19-repo seems to have the mt7531-driver, but there also the menuentry is missing.

i have additional “DDR Component”

  │ │              (MT7622) Chip ID                                       │ │  
  │ │              (ASIC) Chip Type                                       │ │  
  │ │              (eMMC) Flash Type                                      │ │  
  │ │              (1024Mb) DDR Component                                 │ │  
  │ │              (GMAC1) Use GE1 or GE2                                 │ │  
  │ │              (GE_SGMII_FORCE_2500) GE1 connected to                 │ │  
  │ │              ---                                                    │ │  
  │ │              Load an Alternate Configuration File                   │ │  
  │ │              Save Configuration to an Alternate File

as far as i see mt7531 is linked in makefile but not in any kconfig…also searching in menuconfig is disabled (i cannot search with / like in Linux-Kernel-menuconfig). maybe it’s because uboot-version is 2014-04…i guess kconfig-support is added later. also the string “switch connected to” is not in config.in (which seems to be the source for the menuconfig). Interesting detail in config.in:

if [ "$CONFIG_GE1_SGMII_FORCE_2500" = "y" ]; then
    define_bool CONFIG_RTL8367 y
fi

so here old switch is always used if selecting sgmii for ge1, i tried to add a coice for switch:

choice 'switch' "RTL8367s CONFIG_RTL8367  \
                 MT7631 CONFIG_MT7631
                " RTL8367s

but compile failes on missing arm-linux-gcc

/bin/sh: 1: /opt/buildroot-gcc492_arm/usr/bin/arm-linux-gcc: not found

makefile ignores CROSS_COMPILE environment variable and set it directly

ifeq ($(MT7622), y)
CROSS_COMPILE_PATH = /opt/buildroot-gcc492_arm/usr/bin
CROSS_COMPILE = $(CROSS_COMPILE_PATH)/arm-linux-
endif

have fixed it locally, but hanging now on wrong “-march”, build.sh on top dir compiles till multiple definition of __raw_read* __raw_write* (also without my modifications to Makefile) and setting new chip per default

hi [frank-w,

please use https://github.com/BPI-SINOVOIP/BPI-R64-bsp-4.19.git for R64 mt7531 BSP.

use “./build.sh” to compile the uboot and kernel. you need install the toolchain /opt/buildroot-gcc492_arm/usr/bin/arm-linux-gcc

uboot MT7531 driver is already enabled. include/configs/autoconf.h #define CONFIG_MT7531 1

kernel’s MT7531 driver is already enabled by default kernel configuration file. you need only compile them by “build.sh” script .

I have linaro (ubuntu default crosscompiler) installed…why should i install another? Old r64-bsp was compilable with linaro-crosscompiler

it seems that adding the above choice to config.in

choice 'switch' "RTL8367s CONFIG_RTL8367  \
                 MT7531 CONFIG_MT7531
                " RTL8367s

configuring via make menuconfig (needs to be entered twice because on first start i see only SOC + ASIC, after saving first time and starting again i see the other options). then building via build.sh from top-dir with gcc6 compiles fine

for anyone interested, i forked official r64-4.19-repo and did some changes to uboot :slight_smile:

https://github.com/frank-w/BPI-R64-bsp-4.19/commits/master

@frank-w let me say, your copious and diligent efforts on the R64 and R2 have made ramping up far simpler then was to be expected.

1st - the process above for openwrt works without issue - my issue arises as soon as i attempt to use the ubuntu or debiam images.

I’m having what will likely be refered to as simple on your behalf, but I can not get my R64 to boot from eMMC for love nor money.

/dev/mmcblk0boot0 was all built from your 4.19 repo and I’ve tried the preloader_emmc.bin that’s floating around, the two that say for sd card, writing with and without headers, writing to offset 0 and 2k - I’ve got no idea what the issue is at the moment as its saying it can’t load LK, which i assume would be in ATF (Little Kernel) from the trust zone, but i really just have no idea at the moment?

I assume i just have the wrong preloader??

error below

[get_part] part->nr_sects=1, part->info->name=
[get_part] part->nr_sects=1, part->info->name=
[get_part] part->nr_sects=1, part->info->name=
[get_part] part->nr_sects=1, part->info->name=
[get_part] part->nr_sects=1, part->info->name=
[get_part] part->nr_sects=1414483778, part->info->name=
[BLDR] lk partition not found
load lk (ret=-1)
[BLDR] Second Bootloader Load Failed
PL fatal error...

F0: 102B 0000
F5: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0000 0041 [0000]
G0: 0190 0000
T0: 0000 03AE [000F]
Jump to BL

i also have not got debian working on emmc so far…it’s a similar problem i faced above

I think we need some vendor-info why it does not work

@frank-w have you gone thru the emmc preloader above and the embedded atf and conpared them from a bin/he. Perspective to whats available publicly?

im about to dolve in if no one else has?

Also - i got past the LK ISSUE - i partitioned and imaged the exact same way u mentioned in another post regard sata boot and then used your preloader above, THEN redid the partition table only and it loaded the kernel - getting closer!

Sata-boot is for r2…

And no,have not byte compared…only lokked for offsets and compared with my infos (from vendor-script) but afair atf is different in the openwrt image here

Which partition-table do you use? Kernel loads? Uboot should be first,but i expect it does…

Please tell me your complete steps

@Frank I got it done - works perfectly. I’ll upload a complete & clean image inside of 48hrs.

They use a hybrid gpt partition table that accounts fot the LK and subsequent “TRUST” boot loaders.

You actually had the magic part all along. Here’s what to do

  1. Boot the r64 with any of the 3 linux sd imgs provided
  2. Write the complete emmc_singleimage.bin (top of the page open wrt) to the beginning of the disk. dd if=emmc_singleimage.bin of=/dev/mmcblk bs=512
  3. then (another one of your snippets)
parted -s /dev/mmcblk0 unit MiB mkpart primary fat32 -- 100MiB 356MiB
parted -s /dev/mmcblk0 unit MiB mkpart primary ext2 -- 356MiB 7295MiB
partprobe /dev/mmcblk0
mkfs.vfat /dev/mmcblk0p6 -I -n BPI-BOOT
mkfs.ext4 -O ^has_journal -E stride=2,stripe-width=1024 -b 4096 /dev/mmcblk0p7 -L BPI-ROOT
sync
  1. Then edit your /etc/fstab
/dev/mmcblk1p1 /boot vfat defaults,errors=remount-ro 0 0
/dev/mmcblk1p2 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
tmpfs /tmp tmpfs defaults,nosuid 0 0
/dev/mmcblk0p6 /mnt/boot vfat defaults,errors=remount-ro,noauto 0 0
/dev/mmcblk0p7 /mnt/root ext4 defaults,noauto 0 1
  1. Manually mount and copy from the partitions on your SD card (these are your steps and i am thankful)
#unpack bootstrapped debian or copy full rootfs from sdcard

rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/boot/*"} / /mnt/root/

#copy kernel (p1) and modules (p2)

mkdir -p /mnt/emmc/boot/bananapi/bpi-r2/linux cp /boot/bananapi/bpi-r64/linux/uImage /mnt/emmc/boot/bananapi/bpi-r64/linux mkdir -p /mnt/emmc/root/lib/modules/ cp -r /lib/modules/$(uname -r) /mnt/emmc/root/lib/modules/

# configure uboot to load kernel from right partition

sed 's/mmcblk1/mmcblk0/' /boot/bananapi/bpi-r64/linux/uEnv.txt > /mnt/boot/bananapi/bpi-r64/linux/uEnv.txt

as for the u-boot, atf, etc - follow the same directions as you mentioned at the top of this thread.

IMPORTANT MTK seems to pair their preloaders to the GPT table sigs which is directly linked to the access path for the LK, the stage two loader. The only reason i knew where to dig was that I’ve had to bring up several raw boards in a previous venture - and I was lucky enough to be given really great direction from qualcomm and others.

The reason it’s so tricky is in every image we’ve been provided, once it’s mounted, it has hides the parent GPT and only exposes the hybrid MBR table - but you don’t need an MBR table at all as described above

happy hunting and I’ll (or u if you beat me too it) will upload an image within a couple of days

I seriously could not have done it anywhere near this quickly without your help and incredibly detailed posts!

here is the final GPT table

root@bpi-iot-ros-ai:~# gdisk /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/mmcblk0: 15269888 sectors, 7.3 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 9C040E2D-2415-47A1-9193-CB5BD2C34E82
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 15269854
Partitions will be aligned on 512-sector boundaries
Total free space is 490429 sectors (239.5 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            1024            1535   256.0 KiB   8300  tee1
   2            1536            2559   512.0 KiB   8300  lk
   3            2560            3583   512.0 KiB   8300  nvram
   4            3584            4095   256.0 KiB   8300  rf
   5            4096           45055   20.0 MiB    8300  boot
   6          204800          729087   256.0 MiB   0700  BPI-BOOT
   7          729088        14940159   6.8 GiB     8300  BPI-ROOT

-Jon

2 Likes

We need mbr+gpt both for emmc? This differs from sdcard where only a mbr exists.maybe thats the cause i can’t get the partitiontable via sfdisk/sgdisk? But you can display it so it should be exportable too

Can you try get it working without the singleimage? So we know whats really needed…

@Frank it’s not the “singleimage” that matters at all. It’s the signature pairing between the LK (partition 2 above, the GPT table signature (the usually hidden one) and the preloader) - those three things are married - and for whatever reaso they were only used to create a LEDE image - i’m completely removed them from their existing containers and reimplemented the process - above are the individual steps - BUT

by lunch tomorrow i’ll have our internal image to flash directly which will require no additional effort (we image via pxe boot - thank you again for the netboot work)

And you don’t need any MBR at all. I will try and get an image up tomorrow for you guys - just getting my folks into production on a new device so time is sparse.

The way i’ve broken it apart - the images are all standalone now - i’ll @ u when i upload them

jon

1 Like

Is the gpt accessible from outside (e.g. losetup the img and run partprobe on loop-dev)?

On my gdrive i have already some parts collected like uboot-binaries (currently only rtl8367-switch),atf and a bootstrapped buster

https://drive.google.com/drive/u/0/mobile/folders/1WLWAR1FC-rF4n2SgFecBlU1ym_XKqAR_/15Y5Y3NAOwg_IMmN3k6hdb7pAQj9oTVTl/1SRUhYQqs5Jg_lKqgMfUlwSX4dG5T6qPZ?sort=13&direction=a

Maybe you can use it to create a clean system. Maybe you need to set rootpw via chroot before you can login

I hope i get a new r64 board soon to test my repos with mt7531- driver

Have now added also uboot-binaries for mt7531 and emmc…rtl8367+sd is working…the others i can’t test at the moment.

you can also send me the first x MB containing gpt+mbr, bootheaders +atf and uboot. then i can try to boot it on my board till uboot

@moore why did you use 2 cards? Isn’t that card able to simultaneously provide 2,4 and 5GHz as AP? Why you did not use this card from ASIARF? https://www.asiarf.com/shop/wifi-wlan/wifi_mini_pcie/wifi-mini-pcie-module-mtk-mt7615-4x4-11ac-5g-ws3294-manufacturer/? Do you know the difference between those two cards(ASIARF WS3294 and M27615-GAE)?

Two cards solution can have AC2600 (4x4ac + 4x4n) concurrent solution, but one card is dual-band only (work at 4x4ac or 4x4n only). In addition, this card is not standard mpcie size, so it’ll cause another pcie slot cannot plug other cards, thanks.

@moore thnx for clarification. Do you know, does other non standard mpcie size wifi card support concurrent wifi solution? And what about this card, do you know anything about it? https://www.aliexpress.com/item/32842242314.html?spm=a2g0o.cart.0.0.6e813c00kSgUC1&mp=1

As far as I know, only Mediatek MT7615D support dual band concurrent feature.i.e., 5Ghz 4x4ac or 2.4Ghz 4x4n => 5Ghz 2x2ac + 2.4Ghz 2x4n, but there is no standard mpcie size MT7615D card and mt76 mac80211 wifi driver cannot support dual-band concurrent mode at this moment.

@moore thnx for clarification, btw, this is a clear statement from asiaRF:

WS3294 each RF connector is with 2.4GHz and 5GHz traces out. MT7615-GAE is with only 2.4GHz out. MT7615-AAE is with only 5.GHz out.

Can you please discuss this in another (new) thread? This is about booting from emmc and not wifi-hardware :wink:

1 Like