Hi guys!
So, after some pause I returned to work on BPI-R2. A bit late, but work contain generic things every one will like.
So now, U-Boot can run system (not kernel) from SD, MMC and connected hard drives (via AHCI). Even additional PCI-E card of class PCI_CLASS_STORAGE_SATA_AHCI works.
More, it boot system using modern U-Boot’s support of EFI specs.
I don’t have the preloader sourcecode…it is NDA,so i cannot change it.
But nice that you got ahci working on uboot so basicly it should be possible to load kernel from uboot
It do more, it allow start board PC way 
My tree with all that things:
Thank you,can i use sata driver also on non-efi?
the limitation of uboot size (in preloader) is a problem,but maybe in “normal” uboot sata is also possible
IIRC, removing EFI makes it smaller, but few kilos away from 300000
The preloader uboot size has been changed from 300000 to 524288, please test this .
can you guide me change the dts without 64-bit-support? your 64bit-commit adds also the pcie-nodes
i have removed the 1st and 3rd reg-value (0) like you added in other nodes, but get now these warnings:
arch/arm/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (reg_format): /pcie-phy@1a149000/pcie-phy@1a149900:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 2)
arch/arm/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (reg_format): /pcie-phy@1a14a000/pcie-phy@1a14a900:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 2)
arch/arm/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (ranges_format): /pcie-controller@1a140000:ranges: "ranges" property has invalid length (56 bytes) (parent #address-cells == 1, child #address-cells == 3, #size-cells == 2)
arch/arm/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (ranges_format): /pcie-phy@1a149000:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (ranges_format): /pcie-phy@1a149000:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)
arch/arm/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (ranges_format): /pcie-phy@1a14a000:ranges: empty "ranges" property but its #address-cells (2) differs from / (1)
arch/arm/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (ranges_format): /pcie-phy@1a14a000:ranges: empty "ranges" property but its #size-cells (2) differs from / (1)Thanks a lot! Will test soon.
I copied pcie part from original dts, but original dts defined with two cells per address (2 x 32bits) and get same messages.
So, instead of translating pci ranges, I converted whole file to original 2x.
Yup, works fine. Many thanks!
Mhm,r2 is 32 bit,strange that it uses 64bit ranges in dts
@sinovoip can you add preloader for sd too (with new uboot-range)
Anyway some devices are 64bits, like AHCI. So, 64bits way make some thing easiest.
Just dd BPI-R2-EMMC-boot0-DDR1600-20190722-0k.img.gz to SD
Both to 0 offset
then it should be split into 2 commits if we want to get it upstream…first change existing nodes to 64bit and then add the new ones
have splitted it in my repo, but still get this warning:
arch/arm/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (reg_format): /memory:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 2)
memory node is defined in skeleton.dtsi which i can not change because this is used by other devicetrees…imho we need to add a compatible memory node to bpi-r2.dts
here is the linux-pendant:
memory@80000000 {
device_type = "memory";
reg = <0 0x80000000 0 0x80000000>;
};
have added this but still the warning above 
if i leave the address after “@” there is no warning, but is this the right way?
pushed to https://github.com/frank-w/u-boot/tree/sata if anyone will test it (currently have no hdd/ssd on my test-r2 for testing it)
eMMC, just burn it once and you don’t have to burn it again. If SD can be turned on, you just need to update the preloader. Completely new SD would have to burned two head files
seems to work, btw. filename of img (inside the gz) of SD-Preloader contains also EMMC only 2k instead of 0k at the end
How do you acess harddrive in uboot? how can i verify drive is found? Why not kernel? Normally only kernel (+fdt) is loaded by uboot and rootfs is “loaded” by kernel
i tried to get some info about connected Harddrive (connected to the sata-port near wan-port)
In: serial
Out: serial
Err: serial
Net: Init HIFSYS power
Warning: ethernet@1b100000 (eth0) using random MAC address - 7e:d0:7e:a6:85:9a
eth0: ethernet@1b100000
Hit any key to stop autoboot: 0
BPI-R2> ls ahci 0:1
BPI-R2> ls scsi 0:1
BPI-R2> ls scsi 1:1
BPI-R2> ls ahci 1:1
BPI-R2> scsi reset
Reset SCSI
scanning bus for devices...
BPI-R2> scsi info
BPI-R2>
a bit further:
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> scsi info
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:0
** Unrecognized filesystem type **
BPI-R2> ls scsi 0:1
EFI/
512 BOOTSECT.BAK
1 file(s), 1 dir(s)
BPI-R2> ls scsi 0:1 EFI/ubuntu
./
../
119296 grubx64.efi
28 test.txt
2 file(s), 2 dir(s)
BPI-R2> fatload scsi 0:1 ${scriptaddr} EFI/ubuntu/test.txt
28 bytes read in 384 ms (0 Bytes/s)
BPI-R2> setexpr listend ${scriptaddr} + ${filesize};
BPI-R2> printenv scriptaddr
scriptaddr=0x83000000
BPI-R2> printenv listend
listend=8300001c
BPI-R2> mw.b ${listend} 00 2;
BPI-R2> strings ${scriptaddr};
blah
blubb
this is test.txt
BPI-R2>
now same with kernel:
BPI-R2> pci enum
mtk_pcie_preinit: PCIe Link count=2
BPI-R2> scsi scan
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/ubuntu
./
../
119296 grubx64.efi
28 test.txt
7291206 uImage_4.14.117-main
3 file(s), 2 dir(s)
BPI-R2> fatload scsi 0:1 ${loadaddr} EFI/ubuntu/uImage_4.14.117-main
7291206 bytes read in 631 ms (11 MiB/s)
BPI-R2> bootm
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Linux Kernel 4.14.117-main
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 7291142 Bytes = 7 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.14.117-bpi-r2-main (frank@frank-N56VZ) (gcc versi
on 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04)) #180 SMP Wed May 8 19:09:03 CEST
2019
....
How do you acess harddrive in uboot?
pci enum ; scsi scan fatload …
how can i verify drive is found?
pci enum ; scsi scan will report drive name and other params
Why not kernel?
I don’t care about Linux, I’m care about generic way, so *BSD, Linux and other OS devs can use it.
Normally only kernel (+fdt) is loaded by uboot and rootfs is “loaded” by kernel
Linux way is can’t be described as “Normally”.
It’s ok for Linux, but always better to make happy much pplz
i have not known these commands…a friend shows me these in your log
efi will also be a benefit, but should be separated to pci/ahci
can you bring ahci upstream? one thing which is bit confusing is the initialisation in the network-init (“kick on hifsys”), maybe maintainers can help you using another way for autoinit
Looks cute now 
gist in header updated
Rows entered: