I used same atf source and no compression yet.
Only changed To uboot 2022.10+v2 of patches and rebuilt.
Need to add compression later somehow to atf build chain…currently it takes the uboot.bin and builds the fip from it…do not have the bl31 alone.
When I boot ATF with v2.7 on my R64 (the default of openwrt/arm-trusted-firmware then it boots OK.
However when I reboot it get’s stuck, just before I should see the hex numbers, but I never get to see them.
Ok, I have patched it a little (see here), but branch mtksoc-20210508 boots just fine.
Any ideas why?
V2.4:
[65344.944234] shutdown[1]: All filesystems unmounted. +-----------------------------+
[65344.949190] shutdown[1]: Deactivating swaps. | |
[65344.953577] shutdown[1]: All swaps deactivated. | Cannot open /dev/ttyUSB0! |
[65344.958125] shutdown[1]: Detaching loop devices. | |
[65344.963145] shutdown[1]: All loop devices detached. +-----------------------------+
[65344.968055] shutdown[1]: Stopping MD devices.
[65344.972658] shutdown[1]: All MD devices stopped.
[65344.977294] shutdown[1]: Detaching DM devices.
[65344.981961] shutdown[1]: All DM devices detached.
[65344.986685] shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached.
[65344.995668] watchdog: watchdog0: watchdog did not stop!
[65345.005007] shutdown[1]: Syncing filesystems and block devices.
[65345.011212] shutdown[1]: Rebooting.
[65345.015497] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[65345.041227] reboot: Restarting system
F0: 102B 0000
F5: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 036D [000F]
Jump to BL
V2.7:
[ 118.715769] shutdown[1]: All filesystems unmounted.
[ 118.720725] shutdown[1]: Deactivating swaps.
[ 118.725127] shutdown[1]: All swaps deactivated.
[ 118.729677] shutdown[1]: Detaching loop devices.
[ 118.734716] shutdown[1]: All loop devices detached.
[ 118.739637] shutdown[1]: Stopping MD devices.
[ 118.744262] shutdown[1]: All MD devices stopped.
[ 118.748897] shutdown[1]: Detaching DM devices.
[ 118.753568] shutdown[1]: All DM devices detached.
[ 118.758292] shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached.
[ 118.767282] watchdog: watchdog0: watchdog did not stop!
[ 118.776579] shutdown[1]: Syncing filesystems and block devices.
[ 118.782772] shutdown[1]: Rebooting.
[ 118.787022] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 118.819974] reboot: Restarting system
And then stuck...
Only changed ATF, nothing else…
hi @hackpascal i try to get CMD_NAND in my 2022-07 uboot, but this depends on CONFIG_SYS_MAX_NAND_DEVICE (i set to 1) and CONFIG_SYS_NAND_BASE (which value should this be?)
can you help here? it is for detection if NAND or NOR is active in hardware
CMD_NAND is only available for parallel NAND framework (i.e. raw nand in mtd). Parallel NAND is not supported by MT7629/7981/7986. MT7622 does support it but never used. The only command exists in mainline to access SPI-NAND is CMD_MTD. Or you can use my customized command for NAND debugging: https://github.com/mtk-openwrt/u-boot/commit/037df45a3648d96c99d190970d315a4a89a21767
Thx for clarification. I only need a command to check if nand or nor is available and so i cannot use “nand info”. Mtd is used for both. I do not need any special debugging only need to know if nand or nor for loading right dto for linux
Or maybe i need to use sf probe for checking nor and set nand as fallback
Sf probe works. Needed to set
tick_dly = <2>;
To 1 to get nor detected on my r3…maybe r3 needs an own dts?
Still trying to get ATF v2.7 to reboot on R64… See above.
Do you guys think there is a kernel/dts patch that I’m missing, which will cause the kernel not to reboot, when starting from ATF v2.7?
Perhapse a Mhz setting in the operating-points? Or perhapse the L2 cache patch in dts? Anyone knows?
Sorry for late response…maybe this:
https://lore.kernel.org/all/[email protected]/T/#rdf4176e65da050b8125edf90ab2f0753147bff90
Do you use the ddr_flyby option for r64 (in my r64 atf repo i do not use it afaik)? I try to integrate weijis current state into my uboot repo to have one atf branch for r64 and r3…
@ericwoud can you confirm that it fixes your issue?
@dangowrt can you please repost this fix?
@hackpascal daniel mentioned that this should be fixed in TF-A too…have you done this already? it looks like we have similar issue on r3/mt7986…reboot hangs in uboot and it cannot access sdcard (but i have not tried your new source from here as i struggle with correct flags)
tried to use the new TF-A code for bpi-r3 (and created gpt with sgdisk instead of flashing the broken gpt img)
F0: 102B 0000
FA: 1040 0000
FA: 1040 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 300C 0028
F5: 480C 0000
00: 1005 0000
FA: 1040 0000
FA: 1040 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 300C 0028
01: 102A 0001
02: 1005 0000
BP: 2000 00C0 [0001]
EC: 0000 0000 [3000]
T0: 0000 0182 [010F]
System halt!
built u-boot.bin from 2022-10-r3 branch, switched to mtk-atf branch, build it and created image with createimg command (using values 100 for boot and 6144 for root to have same sectors as my current gpt created by your py2-script)
partitiontable looks good for me:
non-working:
Number Start (sector) End (sector) Size Code Name
1 34 8191 4.0 MiB 8300 bl2
2 8192 9215 512.0 KiB 8300 u-boot-env
3 9216 13311 2.0 MiB 8300 factory
4 13312 17407 2.0 MiB 8300 fip
5 17408 222207 100.0 MiB 8300 boot
6 222208 12805120 6.0 GiB 8300 rootfs
working (from py2 gpt-img):
Number Start (sector) End (sector) Size Code Name
1 34 8191 4.0 MiB 8300 bl2
2 8192 9215 512.0 KiB 8300 u-boot-env
3 9216 13311 2.0 MiB 8300 factory
4 13312 17407 2.0 MiB 8300 fip
5 17408 222207 100.0 MiB 8300 kernel
6 222208 12805120 6.0 GiB 8300 rootfs
content of bl2-partition looks a bit different (maybe caused by mkimage usage?):
non-working:
00000000 53 44 4d 4d 43 5f 42 4f 4f 54 00 ff 01 00 00 00 |SDMMC_BOOT......|
00000010 00 02 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000200 42 52 4c 59 54 00 00 00 01 00 00 00 00 4a 00 00 |BRLYT........J..|
00000210 88 51 03 00 42 42 42 42 08 00 01 00 00 06 00 00 |.Q..BBBB........|
00000220 88 51 03 00 ff ff ff ff ff ff ff ff ff ff ff ff |.Q..............|
00000230 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000600 4d 4d 4d 01 38 00 00 00 46 49 4c 45 5f 49 4e 46 |MMM.8...FILE_INF|
00000610 4f 00 00 00 01 00 00 00 01 00 05 01 00 0d 20 00 |O............. .|
00000620 88 07 03 00 88 0d 03 00 00 03 00 00 20 00 00 00 |............ ...|
00000630 00 03 00 00 01 00 00 00 4d 4d 4d 01 0c 00 01 00 |........MMM.....|
00000640 01 00 00 00 4d 4d 4d 01 14 00 02 00 00 00 00 00 |....MMM.........|
00000650 10 00 00 00 80 00 00 00 4d 4d 4d 01 14 02 03 00 |........MMM.....|
00000660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
working (old bpi-atf source):
00000000 53 44 4d 4d 43 5f 42 4f 4f 54 00 ff 01 00 00 00 |SDMMC_BOOT......|
00000010 00 02 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000200 42 52 4c 59 54 00 00 00 01 00 00 00 00 06 00 00 |BRLYT...........|
00000210 88 fd 02 00 42 42 42 42 08 00 01 00 00 06 00 00 |....BBBB........|
00000220 88 fd 02 00 ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000230 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000600 4d 4d 4d 01 38 00 00 00 46 49 4c 45 5f 49 4e 46 |MMM.8...FILE_INF|
00000610 4f 00 00 00 01 00 00 00 01 00 05 01 00 0d 20 00 |O............. .|
00000620 88 f7 02 00 88 fd 02 00 00 03 00 00 20 00 00 00 |............ ...|
00000630 00 03 00 00 01 00 00 00 4d 4d 4d 01 0c 00 01 00 |........MMM.....|
00000640 01 00 00 00 4d 4d 4d 03 64 00 07 00 90 11 00 00 |....MMM.d.......|
00000650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
mhm, flashed old bl2/fip to the new parttable, and got same system-halt…so maybe i miss something in gpt (flags??)…old gpt with new atf works…so anything i miss in gpt-creation
took me some time to read out the information, but it looks like the legacy bootable flag is needed…do not know yet how to set it with sgdisk, but gdisk prints this when i read the working gpt
Expert command (? for help): a
Partition number (1-6): 1
Known attributes are:
0: system partition
1: hide from EFI
2: legacy BIOS bootable
60: read-only
62: hidden
63: do not automount
Attribute value is 0000000000000004. Set fields are:
2 (legacy BIOS bootable)
seems that was the problem…got it set by this
sudo sgdisk --attributes=1:set:2 ${LDEV}
after that bl2 got loaded 
I’ve tried the opp 3000000 fix before, did not work. I just tried it again, to make sure, but it does not help.
I am building with DDR3_FLYBY=1
The only thing I change is the branch I build, everything else is exactly the same. v2.7 hangs at reboot while v2.4 does not.
So _gitbranch=“mtksoc” Hangs at reboot
And _gitbranch=“mtksoc-20210508” Does not hang at reboot.
On the R64 that is. And I don’t hang at u-boot, but it hangs totally not restarting from the very first visible byte on the uart output. Sounds like a different hang then the one you were experiencing.
tried this ATF on r64 (needed some time to get it working due to the strange MBR/GPT mix)…
at least after booting into uboot and issue “reset” board boots into uboot again…so i guess it is a linux setting breaking reboot in ATF (similar to the Patch from Daniel i’m pointing above). do not have a rootfs on my new card…i hope i find time to check this.
at least uboot 2022-10 with this ATF is completely build in my github for r64/r3 including sd-card images (bootchain only, no rootfs)
https://github.com/frank-w/u-boot/tree/2022-10-bpi (+ mtk-atf branch)
- Below command should miss the CROSS_COMPILE option.
make -f Makefile PLAT= BOOT_DEVICE= BL33=<path-to-u-boot.bin> all fip
ENABLE_JTAG=
This option is valid only when PLAT is mt7981/mt7988
Typo? I think it’s mt7986 instead of mt7988. Here is the grep output of ATF code.
% grep ENBLE_JTAG . -r
./plat/mediatek/mt7981/platform.mk:ENABLE_JTAG ?= 0
./plat/mediatek/mt7981/platform.mk:ifeq ($(ENABLE_JTAG), 1)
./plat/mediatek/mt7981/platform.mk:CPPFLAGS += -DENABLE_JTAG
./plat/mediatek/mt7981/platform.mk:$(call MAKE_DEP,bl2,mt7981_gpio,ENABLE_JTAG)
./plat/mediatek/mt7981/drivers/gpio/mt7981_gpio.c:#ifdef ENABLE_JTAG
./plat/mediatek/mt7986/platform.mk:ENABLE_JTAG ?= 0
./plat/mediatek/mt7986/platform.mk:ifeq ($(ENABLE_JTAG), 1)
./plat/mediatek/mt7986/platform.mk:CPPFLAGS += -DENABLE_JTAG
./plat/mediatek/mt7986/platform.mk:$(call MAKE_DEP,bl2,mt7986_gpio,ENABLE_JTAG)
./plat/mediatek/mt7986/drivers/gpio/mt7986_gpio.c:#ifdef ENABLE_JTAG
Have you tested the JTAG in the BPI-R3? I compiled the ATF with option ENABLE_JTAG=1.
I’ve tried
opp-300000000 {
- opp-hz = /bits/ 64 <30000000>;
- opp-microvolt = <950000>;
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <1000000>;
};
As here
Suggests that it may get stuck without this patch. This patch also does not work. Reboot in ATF 2.7 still gets stuck in my build on the R64.
I’ve also tried totally removing the opp-300000000 node, but it makes no difference.
I have have tried out the 2 branches of mtksoc and mtksoc-20210508. I converted them to patches. After some changes to the patches I could apply the patches to the same commit of the original ATF repo. And even then the mtksoc version still did not reboot on the R64. This for me had ruled out that this is an ATF upgrade problem. It is somewhere in the newest series of commits in the mtksoc branch. Something not compatible with R64 (when it reboots with psci?).
Anyway, I now have created a minimal fork of mtksoc/mtksoc-20210508 combined, specifically for bpir64. It is rebased to the newest ATF firmware of today, and it reboots
https://github.com/ericwoud/arm-trusted-firmware/tree/bpir64
Have you compared the rebased working version with the original with the issue?
I have kept the change from original ATF as minimal as possible. I have only applied the following commits (from 2021 v2.4 branch and 2022 v2.7 branch)
2022: build_macros.mk: add support to use prebuilt libraries
2022: mmc: do not check mmc_csd.spec_vers for eMMC
2022: mediatek: common: add MediaTek SD/eMMC controller driver
2022: mediatek: common: add generic high-speed UART console driver
2021: mediatek: mt7622: add initial BL2/BL31 support
2021: mediatek: mt7622: add DDR initialization support
There were some changes to the SPSR code, so the 64-bit U-Boot/Kernel support is moved inside the initial BL2/BL31 support commit, as it was necessary for rebasing.
So there are a lot of differences from the v2.7 branch of openwrt.
I’ve also added my own changes to the branch as well, but if you just build it, it can be used as if my patches are not applied and have it start (a 64 bit) U-Boot.
PS: I’ve ordered a R3 and I plan to add this one to my fork of ATF as well.I believe I can have it start a initrd directly from atf (as with R64 already possible). Then from the initrd load an image to ram and then switch from sd to emmc. Then finally flash the emmc from ramdisk. This way no need to use nand as an in between step… In theory…
Maybe @hackpascal can look at the diff and find reboot-breaking change?
You want to switch sd to emmc while system is running? How do you want to trigger kernel looking for device change of mmc controller with different dts-setting? I don’t think this can work…
@frank-w: I’m looking at the bl1 -> bl2 sequence. I’ve noticed that for R3 you do not write any header: It is commented out…
Does the R3 not require any header? Is it enough the set legacy boot bit of the bl2 partition in GPT table?
Before you mentioned this as the start of sector 0:
Which does seem like a header. Or did it turn out this was not necessary?
The line you mention was the binary gpt i flashed before (created by python2 script in mtk-code).
It is enough creating the gpt with bootable bl2 and writing the right bl2 binary (there is a bin and an img file) there
On the BPI-R3, there is a small side affect when only switching switch D down (and leaving the rest up).
In this combination, it is possible to load the bl2 from sector 34 an up on the EMMC, from /dev/mmcblk0. The difference is that mmcblk0boot0 is not being used. bl2 gets written together with the rest of the image.
This way the entire image needs only written to 1 device (similar to SDMMC).
In the makefile, change all declarations:
BROM_HEADER_TYPE :=
to
BROM_HEADER_TYPE ?=
and then build an emmc atf image, passing BOOT_DEVICE=emmc and BROM_HEADER_TYPE=sdmmc on the make command line.
On the BPI-R3, add new spi nand Flash(QE bit set 0 off default). but NMBM don’t support, all block be sacnned bad block, also i add spim driver .C file’s .init struct setting, not work again. Could you take me how to fix it?
startup err log:
…
spi nand driver file’s init struct:
NMBM LA data(By Acute logic analyzer): (That show nmbm set ecc off, and not set QE bit =1)
QE bit by spec.:
spi nand driver files: xtxtech.c (5.6 KB)
I get it, Add “arm-trusted-firmware/drivers/mtd/nand/spi_nand.c” new line 127,Flash ID, then QE enble set.
But one new conundrum has emerged, Error log stop that “NOTICE: NMBM has been initialized in read-only mode”
