the network HW architecture of mt7623 and mt7620 are different, so you cannot apply this patch directly, thanks.
1 Like
I see that new patches are available.
https://patchwork.ozlabs.org/project/uboot/list/?series=69709
Is there anything new or only whitespaces (eol) updated? Ethernet seems not yet included
We’re working on Ethernet driver now.
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
+config MTK_QSPI
+ bool "Mediatek QSPI driver"
+ help
+ Enable the Mediatek QSPI driver. This driver can be
+ used to access the SPI NOR flash on platforms embedding this
+ Mediatek QSPI IP core.
+
it seems that another patch-series is needed to apply this patch directly, but i didn’t find which one
have it applied here:
problem-patch is here:
i don’t know yet how to answer in patchwork…
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 
How far are you with the ethernet-driver? Btw. In old uboot mac-setting does not work,hoping here it will do.
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 
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