yup, 32bit 
It should be 12.5Mhz, thanks.
1 Like
Thanks!
Should I bind it to dummy clock?
Or parent and Id known and you can give it to me?
eMMC/SD works fine. Environment loaded.
Code updated.
SATA works too, but small organizational issue should be resolved.
1 Like
Emmc seems to work only if pre-initialized (e.g. by previous loaded uboot or by booting from emmc). if booting directly from sd it does not work.
If anybody has an idea…
Now, we’re also developing mt7622 upstream uboot, and will share our patches with you in these two days.
-
Ethernet: todo
-
PCIe/USB: ongoing
We’ll use mt7629 as target platform first because it has uboot usptream already with similar IP.
2 Likes
have you emmc-access ready? Is it also working if booting from sdcard?
Can you share this patch (maybe pinctrl/timer)?
@moore can you please give us difference on things preloader initialized to boot form eMMC and from SD.
Because we have it worked when first uboot started from eMMC and not worked when from SD.
Boot src eMMC status SD status
eMMC works works
SD no works
So for case it boot from SD something (clk, pinctrl, power, etc) did not initialized, so eMMC won’t work. But we can’t catch yet, what is it.
Thanks.
@frank-w did you try to boot linux from SD (both uboot and linux from SD) and check if eMMC accessible?
have not get managed it…copied kernel+dtb (which i load from my older uboot) to root of sd-card and did this:
U-Boot MT7622> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk1p2 rw rootwait
U-Boot MT7622> ls mmc 1:1
bananapi/
0 sd.txt
8841288 uImage_5.4
23721 bpi-r64-5.4.dtb
3 file(s), 1 dir(s)
U-Boot MT7622> setenv kaddr 0x44000000
U-Boot MT7622> setenv dtaddr 0x47000000
U-Boot MT7622> fatload mmc 1:1 $kaddr uImage_5.4
8841288 bytes read in 785 ms (10.7 MiB/s)
U-Boot MT7622> fatload mmc 1:1 $dtaddr bpi-r64-5.4.dtb
23721 bytes read in 8 ms (2.8 MiB/s)
U-Boot MT7622> bootm $kaddr - $dtaddr
## Booting kernel from Legacy Image at 44000000 ...
Image Name: Linux Kernel 5.4.0-rc1-r64
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 8841224 Bytes = 8.4 MiB
Load Address: 40080000
Entry Point: 40080000
Verifying Checksum ... OK
## Flattened Device Tree blob at 47000000
Booting using the fdt blob at 0x47000000
Loading Kernel Image
Loading Device Tree to 7bff7000, end 7bfffca8 ... OK
Starting kernel ...
then it hangs till a board-reset occours
did same steps with my old uboot (where i have additional env-vars set) and i see kernel booting…with this running i see emmc-partitions and can access them
root@bpi-r64:~# hd /dev/mmcblk0boot0 | head -1
00000000 45 4d 4d 43 5f 42 4f 4f 54 00 00 00 01 00 00 00 |EMMC_BOOT.......|
root@bpi-r64:~#I asked: if you boot board to uboot from SD, then load kernel from SD, do running linux has access to eMMC?
If i use old uboot:yes…see the hd on boot0 output. New uboot hangs on kernel load
Ok, thanks.
Which tree used to build that kernel?
It should be 5.4-r64-rc (as it was on rc1)…why is this important?
I can send you the binaries if needed
for the not loading kernel (which was loaded from sd-card correctly) i guess it is a problem with loading ATF (missing offset/config-option)…if i load kernel with old uboot i see this:
Starting kernel ...
[ATF][ 8.776223]save kernel info
[ATF][ 8.779425]Kernel_EL2
[ATF][ 8.782181]Kernel is 64Bit
[ATF][ 8.785369]pc=0x40080000, r0=0x6bff7000, r1=0x0
INFO: BL3-1: Preparing for EL3 exit to normal world, Kernel
INFO: BL3-1: Next image address = 0x40080000
INFO: BL3-1: Next image spsr = 0x3c9
[ATF][ 8.803636]el3_exit
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]Uboot 2019.07 version on github:
1 Like
hi, it does not contain any code for r64…
it would be nice to start repo with upstream u-boot and add your Patches on top (not one commit including upstream-source mixed with your changes), so everybody can see what is changed…
as an example i’ve added content of this folder to a branch in my repo:
https://github.com/frank-w/u-boot/commits/2019-07-bpi
but good that are no objects and generated files in the folder uploaded
1 Like
Update our latest status for developing mt7622 upstream uboot
We have some major differences with Ray’s version
- We use 64-bit u-boot because it is reasonable for 7622 which is ARMv8 architecture
- We focus on Nand/Nor flash first, due to we use RFBs which are SPI-nand/SPI-nor
We will try Ray’s eMMC/SD patches to test eMMC and SD directly in BPIR64.
Status:
- Serial - done
- Timer - done
- SD - not started
- eMMC - ongoing
- SNFI - done (for nand/nor)
- Ethernet - ongoing
- Switch - ongoing
- PCI-E - todo
- USB - todo
- Clock - done (also fix some bugs in mtk-clk.c)
- Pinctrl - done
- Watchdog - ongoing
- Reset - ongoing
It seems that some works are overlapping (with Ray’s works), maybe we can integrate the patches of both sides, but we think mt7622 upstrem u-boot should be 64 bits.
1 Like