@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;
}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.
@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.
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.
I see that 
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
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 not very fast, but enough
285.2 KiB/s
done
Bytes transferred = 47428086 (2d3b1f6 hex)Any chance to get sata-support?
any new state for r64?
Just FYI Version 2019-07 of U-boot is broken. Makes a board reset on initializing watchdog. 2019-04 works. Probable caused by generic watchdog-reset implementation
it seems this is because CONFIG_WATCHDOG is enabled
WDT: Started with servicing (60s timeout)
after that the reset happens. if i deactivate CONFIG_WATCHDOG i see this and no board-reset occours:
WDT: Started without servicing (60s timeout)
it seems that problem is here:
and get_timer seems to hang on dm_timer_init
somewhere here is the hang:
if (ofnode_valid(node) &&
uclass_get_device_by_ofnode(UCLASS_TIMER, node, &dev)) {u-boot-bug is fixed with these 2 commits (second not yet in upstream):
have already included in my repo
with the help of @ray we got sata working in uboot here
but we need some tuning before we can get it upstream (hifsys is currently initialized in ethsys where it is imho wrong placed)
@Ryder.Lee @weijiegao can you help here? where is the correct entry-point to initialize the hifsys? afaik there should be a new file using compatible “mediatek,mt2701-hifsys” to probe it and then initialize it independent from ethsys (= moving this code)…
https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/clk/mediatek/clk-mt2701-hif.c#L37
i tried moving code to new file, but it seems to not get probed:
seems i also need ops/bind
but I have not added hifsys in the driver…
Right,this change is from ray…he uses ethsys to initialize hifsys for pcie which is imho not the best way…but how to probe hifsys without ethsys-trigger (have it separated in my sata2-branch but probe is not called)?
Without this code pcie/ahci does not work
Is there any documentation about hifsys and the values used here?
@ray @Ryder.Lee send me 2 Patches for the hifsys-problem and i got it working using your Patches and adding power-domain in DTS
see https://github.com/frank-w/u-boot/commits/2019-07-bpi-r2-sata for full patches
BPI-R2> pci enum ; scsi scan
mtk_pcie_preinit: PCIe Link count=2
scanning bus for devices...
Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq stag led clo pmp pio slum part ccc sxs
Device 0: (0:0) Vendor: ATA Prod.: ST750LM022 HN-M7 Rev: 2AR1
Type: Hard Disk
Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512)
BPI-R2> ls scsi 0:1
EFI/
512 BOOTSECT.BAK
1 file(s), 1 dir(s)
BPI-R2> version
U-Boot 2019.07-bpi-r2-sata-00032-g093be1b73d-dirty (Jul 29 2019 - 15:50:56 +020)
arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) 7.4.0
GNU ld (GNU Binutils for Ubuntu) 2.30
ryder sent the Patches upstream, if they got accepted can you post your Patches too?