Add latest U-boot support for BPI R2 & BPI R64 (not yet)

To use SD card, you should use the following command:

mmc dev 1

the ‘1’ means the second device, which is SD card.

and you will get output like this:

U-Boot> mmc dev 1
switch to partitions #0, OK
mmc1 is current device

U-Boot> mmc list
mmc@11230000: 0
mmc@11240000: 1 (SD)

U-Boot> mmc info
Device: mmc@11240000
Manufacturer ID: 11
OEM: 4499
Name: SD256
Bus Speed: 50000000
Mode : SD High Speed (50MHz)
Rd Block Len: 512
SD version 2.0
High Capacity: No
Capacity: 239 MiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes

To switch HW partitions (boot0/boot1/user), uses the following commands:

mmc dev 0 1

the second number ‘1’ means partition boot0 (according to the eMMC spec)

Read the first block to check it:

U-Boot> mmc dev 0 1
switch to partitions #1, OK
mmc0(part 1) is current device
U-Boot> mmc read 0x80000000 0 2

MMC read: dev # 0, block # 0, count 2 ... 2 blocks read: OK
U-Boot> md 0x80000000
80000000: 434d4d45 4f4f425f 00000054 00000001    EMMC_BOOT.......
80000010: 00000200 ffffffff ffffffff ffffffff    ................
80000020: ffffffff ffffffff ffffffff ffffffff    ................

right, but i asked because the emmc-command in 2014-uboot which configures emmc to have a boot0 and boot1-device which is needed to flash preloader to it and get image booted from emmc

reference: Can't boot from emmc (see step 4)

btw. is poweroff-command much work? if i enable the command i get: missing »do_poweroff«

btw. uboot-patches v2 (https://patchwork.ozlabs.org/patch/982884/) failing on 2018-11-rc1 because of missing MT7621_SPI-symbol in drivers/spi/Kconfig

You should rebase to the latest branch:

http://git.denx.de/?p=u-boot.git;a=commit;h=5eee9dee419f940ea75977df8b7ed8bb12bc029f

have v2-patches and my own ready again…waiting for ethernet-driver and the 2018-11 final release :slight_smile:

How far are you with the ethernet-driver? Btw. In old uboot mac-setting does not work,hoping here it will do.

@Ryder.Lee can you manage to add ethernet-driver for r2 before 2018-11-release (12th november)?

emmc-command seems not be needed, i’ve found out how to use uboot-internal commands to read and set the Partitionconfig:

#mmc partconf dev [boot_ack boot_partition partition_access]
# - Show or change the bits of the PARTITION_CONFIG field of the specified device
#example for mode 0x48 (needed for emmc-boot on bpi-r2)
U-Boot> mmc partconf 0
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1
PARTITION_ACCESS: 0x0

#set via
U-Boot> mmc partconf 0 1 1 0

i resetted the flags and set it with last command to get the same result as read before reset

Currently i don’t know how the 0x48 is calculated…

@Ryder.Lee i have an issue with v3-patches:

Kernel command line: earlyprintk console=ttyS0,115200 vmalloc=496M debug=7 no_console_suspend

this does not change to the value of bootargs env-variable

Boot from SD
bootargs=board=bpi-r2 console=earlyprintk console=tty1 fbcon=map:0 console=ttyS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait vmalloc=496M debug=7 initcall_debug=0 video=1920x1080 drm.debug=0x7
6473034 bytes read in 394 ms (15.7 MiB/s)
## Booting kernel from Legacy Image at 80200000 ...
   Image Name:   Linux Kernel 4.19.0-poweroff_new
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6472970 Bytes = 6.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.0-bpi-r2-poweroff_new (frank@frank-N56VZ) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04)) #172 SMP Wed Oct 24 11:38:09 CEST 2018
[    0.000000] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Bananapi BPI-R2
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 64 MiB at 0xfb800000
[    0.000000] On node 0 totalpages: 524287
[    0.000000]   Normal zone: 1170 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 133120 pages, LIFO batch:31
[    0.000000]   HighMem zone: 391167 pages, LIFO batch:63
[    0.000000] random: get_random_bytes called from start_kernel+0xac/0x49c with crng_init=0
[    0.000000] percpu: Embedded 17 pages/cpu @(ptrval) s40268 r8192 d21172 u69632
[    0.000000] pcpu-alloc: s40268 r8192 d21172 u69632 alloc=17*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 523117
[    0.000000] Kernel command line: earlyprintk console=ttyS0,115200 vmalloc=496M debug=7 no_console_suspend
  • v3-patches on rc1 giving same result, so it’s no rc3-issue
  • resetted environment (to default=builtin=uenv.txt in my uboot-repo) before loading kernel
  • builtin-env is same in v2,v3 and v3_old branch
  • uenv.txt on sdcard only contains kernel-var (and root=same as on default env)

works with v2 but not with v3 (rc1/rc3)

any idea?

@frank-w Please modify board/mediatek/mt7623/mt7623_rfb.c and replace the board_init with the following codes and have a try:

DECLARE_GLOBAL_DATA_PTR;

int board_init(void)
{
	/* address of boot parameters */
	gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;

	return 0;
}
1 Like

Have wondered why this line was dropped,but have not know its reason/function.

I try this when i’m at home

Can you tell me why swig/python-dev is now needed for building?

We have switched to binman to generate the final u-boot binary in v3 patches according to suggestions from Simon Glass. And swig and python-dev are required by binman.

1 Like

@weijiegao re-adding init-code seems to work well, thank you

any infos about the ethernet-driver? if this is working i can drop the old 2014-uboot

i tried a bit with emmc-pconfig and it seems i cannot reconfigure it…

after i’ve buyed r2 i had 0x0, after setting (with old uboot) it to 0x48 i had the boot0 and boot1 block

now i read the values with new uboot

U-Boot> mmc partconf 0      
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1
PARTITION_ACCESS: 0x0

and tried to set back to 0

U-Boot> mmc partconf 0 0 0 0
U-Boot> mmc partconf 0      
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x0
BOOT_PARTITION_ENABLE: 0x0
PARTITION_ACCESS: 0x0

thought it worked, but after bootup system i see this:

root@bpi-r2:~# cat /proc/partitions                                             
major minor  #blocks  name                                                      
                                                                                
 179        0    7974912 mmcblk0
 179        1     262144 mmcblk0p1
 179        2    7270400 mmcblk0p2
 179        8    7634944 mmcblk1
 179       32        512 mmcblk1rpmb
 179       24       4096 mmcblk1boot1
 179       16       4096 mmcblk1boot0

old uboot shows now

 [EXT_CSD] Partition config      : 0h

also after

emmc pconf 0x48

it stays 0h

isn’t it possible to repartition emmc again? and if yes, is partitioning with

U-Boot> mmc partconf 0 1 1 0

in new uboot the right way to get emmc bootable on R2? (= “emmc pconf 0x48” in old uboot)

According to the eMMC spec, there are several hw partitions that can’t be removed (but some can be resized).

The fixed hw partitions are:

Boot 1 -> shown in Linux as mmcblkXboot0

Boot 2 -> shown in Linux as mmcblkXboot1

RPMB -> shown in Linux as mmcblkXrpmb

The two boot partition can be resized. You can use

mmc bootpart-resize

to resize them.

There are also 4 optional configurable hw partitions:

General purpose 1 to 4 -> shown in Linux as mmcblkXgpY

These four partitions are not enabled by default. You can use

mmc hwpartition

to enable and configure them.

All the partitions listed above are addressing from 0.

All the spaces left is the User data partition, which shown in Linux as mmcblkX.

And mmcblkXpY is the software partition created partition table which usually stored at the beginning of the user data partition (MBR or GPT).

As for the emmc partconf command, you should know the PARTITION_CONFIG field of the EXT_CSD register first.

----------------------------------------------------------------------
|   Bit 7  |   Bit 6  | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1| Bit 0 |
----------------------------------------------------------------------
| Reserved | BOOT_ACK | BOOT_PARTITION_ENABLE |   PARTITION_ACCESS   |
----------------------------------------------------------------------

BOOT_ACK means whether to send ACK during boot.

BOOT_PARTITION_ENABLE determines which partition to access during boot. The following values are valid:

0 - Disabled
1 - Boot 1
2 - Boot 2
3 to 6 - Reserved
7 - User data

PARTITION_ACCESS determines which partition to access now:

0 - User data
1 - Boot 1
2 - Boot 2
3 - RPMB
4 to 7 - General purpose 1 to 4

So, back to your question:

emmc pconf 0x48 in the old u-boot means BOOT_ACK = 1, BOOT_PARTITION_ENABLE = 1, PARTITION_ACCESS = 0, which is the same as mmc partconf 0 1 1 0 in the new u-boot.

So

mmc partconf 0 1 1 0

is really the right way in the new u-boot.

The boot partitions always exist no matter what value you set using emmc pconf/mmc partconf.

Please note that mmc partconf 0 will display incorrect value (the PARTITION_ACCESS field) if you use mmc dev 0 1 to switch partition.

P.S. You can set BOOT_PARTITION_ENABLE = 2 if you want to burn preloader into Boot 2.

1 Like

Thanks for clarification…now i know the meaning of 0x48

01001000 = bit 3 (PARTITION_ENABLE - boot1) and bit 6 (boot_ack) set

i just wondering why emmc ecsd always showing 0x0, also after setting pconf to 0x48…i did not a partition switch via “mmc dev x y”

new uboot shows right setting after doing it…so all good :wink:

Nice,so the only thing i miss is the ethernet-driver which may be complex due the switch (mt7350) appended to soc.We do not need a dsa-driver. Imho setting hwaddress should work (maybe bypass to kernel,so this does not generate a random one)

sata+usb will be nice, but first i want to drop the old uboot.

@Ryder.Lee any progress on the ethernet-driver?

btw i have uploaded current 2018-11 uboot (v5) with my patches and environment and an example uEnv.txt to my gdrive

https://drive.google.com/open?id=1RuuN2qxgBIoENookMoDri2Ud4eXG-8xL

The initial support for mt7623 has been merged into U-Boot mainline. We’re going to submit the ethernet driver as soon as possible.

2 Likes

I see that :slight_smile: also my default-bootmenu-entry patch is merged.

are you in testing state of Ethernet driver?

Can i use offset 1MB (0x100000) savely for storing environment?

CONFIG_ENV_OFFSET=0x100000

referring to garys image

This is user data area after uboot before first partition (100MB offset) and should not be used in another way

i dd’d an official image, it seems to be empty

root@frank-N56VZ:~# dd if=/dev/sdb bs=1 count=512 skip=$((0x100000)) 2>/dev/null | xxd
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Yes. This area is safe to use.

Thank you for confirmation…i currently do some tests with it

works so far for sd and emmc :slight_smile:

note: if you booted into emmc and do only a reset (uboot-command or reset-switch of r2) next boot goes again in emmc also if SD-Card is inserted…this takes me some time figure out. i need a full power-cycle to boot again to SD-Card

I pushed patch for saveenv to uboots patchwork

good news:

@weijiegao had posted ethernet-driver to uboot-Mailinglist and i have applied it to my repo

is ready-to-compile uboot 2018-11 with ethernet-Patches

also added menu-entry for tftp boot, filename and bootopts can be changed in uEnv.txt

also tried loading a big file (46MB) and works better than old uboot :slight_smile: not very fast, but enough

         285.2 KiB/s
done
Bytes transferred = 47428086 (2d3b1f6 hex)
2 Likes