Solved BananaPI M1 problem with ahci channel 0 FreeBSD 12.2

Hi All,

Look like I'm last user of BananaPI M1 with Allwinner A20 and embeded SATA.
Somewhere between revisions 343862 (last working I have) and 370066 (not working I'm trying to use) is lost ahci channel 0.
I'm trying to report as much as possible in bug 251330 with no luck.

It look like some change in generic sys/dev/ahci/ require some additional enable/disable functionality for channel, that is not implemented in sys/arm/allwinner/ .

Working version:
Code:
ahci0: <Allwinner Integrated AHCI controller> mem 0x1c18000-0x1c18fff irq 25 on simplebus0
ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported
ahci0: quirks=0x2<NOPMP>
ahci0: Caps: NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC 1ports
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich0: Caps:

Non working one:
Code:
ahci0: <Allwinner Integrated AHCI controller> mem 0x1c18000-0x1c18fff irq 26 on simplebus0
ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported
ahci0: quirks=0x2<NOPMP>
ahci0: Caps: NCQ SNTF ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC 1ports
ahcich0: not probed (disabled)

Does anyone have any idea where to find changes?

Thank you
 
Aside from changes in the sources, it could be changes in the dtb files. Have you checked those?
Hi tingo,
Thank you for reply. dtb files is big question for me. I do not understand the structure of them :(
I know, they source version in /usr/src/gnu/dts/arm/sun7i-a20-bananapi.dts , but have no glue, how they are compiled :(
As well browsing through https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/? showing me different files :(

Should find some more documentation.
 
From 13.0 onward (that includes -CURRENT) development is done in git, not subversion.


Thank you SirDice,

OK, that is answer, where files coming from.
Little problem is, I'm not able compare files used with 12.0. But I found last working version:
FreeBSD-13.0-CURRENT-arm-armv7-BANANAPI-20190207-r343862.img
... and I can open and check used dts. But does not see any problem.

Command ofwdump -a showing:
Code:
...
          Node 0x6ae4: endpoint@0
          Node 0x6b28: endpoint@1
  Node 0x6b7c: ahci-5v
  Node 0x6c38: usb0-vbus
  Node 0x6cec: usb1-vbus
...

Command ofwdump -p /ahci-5v showing on working one:
Code:
Node 0x6b7c: ahci-5v
  compatible:
    72 65 67 75 6c 61 74 6f 72 2d 66 69 78 65 64 00
    'regulator-fixed'
  regulator-name:
    61 68 63 69 2d 35 76 00
    'ahci-5v'
  regulator-min-microvolt:
    00 4c 4b 40
  regulator-max-microvolt:
    00 4c 4b 40
  regulator-boot-on:
  enable-active-high:
  gpio:
    00 00 00 39 00 00 00 01 00 00 00 08 00 00 00 00
  status:
    64 69 73 61 62 6c 65 64 00
    'disabled'
  phandle:
    00 00 00 aa

same command on non-working:
Code:
Node 0x652c: ahci-5v
  compatible:
    72 65 67 75 6c 61 74 6f 72 2d 66 69 78 65 64 00
    'regulator-fixed'
  regulator-name:
    61 68 63 69 2d 35 76 00
    'ahci-5v'
  regulator-min-microvolt:
    00 4c 4b 40
  regulator-max-microvolt:
    00 4c 4b 40
  regulator-boot-on:
  enable-active-high:
  gpio:
    00 00 00 3b 00 00 00 01 00 00 00 08 00 00 00 00
  status:
    64 69 73 61 62 6c 65 64 00
    'disabled'
  phandle:
    00 00 00 90
 
OK, I'm one step closer to solution.
Problem is not on FreeBSD level, but on u-Boot level.

when I try scsi info on working one, I get info about one unknown device. The same on non-working will return nothing (mean no device), but command scsi scan perform scan and starting from that point I'm getting my disk as well with scsi info. After that disk is detected on FreeBSD level.

Log from non-working one, that become working after scsi scan command:
Code:
=> scsi info
=> scsi scan
scanning bus for devices...
Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
  Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SKC300S Rev: 507K
            Type: Hard Disk
            Capacity: 57241.8 MB = 55.9 GB (117231408 x 512)
=> scsi info
Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SKC300S Rev: 507K
            Type: Hard Disk
            Capacity: 57241.8 MB = 55.9 GB (117231408 x 512)
=>

The main difference is u-Boot.

Working one - detect SCSI on line 20.
Code:
U-Boot SPL 2019.01 (Feb 07 2019 - 11:10:28 +0000)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2019.01 (Feb 07 2019 - 11:10:28 +0000) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: LeMaker Banana Pi
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Setting up a 720x576i composite-pal console (overscan 32x20)
In:    serial
Out:   vga
Err:   vga
SCSI:  Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst

Net:   eth0: ethernet@1c50000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  2  1  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
41905 bytes read in 6 ms (6.7 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
7[r[999;999H[6n8Scanning disks on scsi...
Disk scsi0 not ready
Scanning disks on usb...
Disk usb0 not ready
Disk usb1 not ready
Disk usb2 not ready
Disk usb3 not ready
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 3 disks
600664 bytes read in 36 ms (15.9 MiB/s)
## Starting EFI application at 42000000 ...
[?25hConsoles: EFI console 


[?25h|/-FreeBSD/arm EFI loader, Revision 1.1





   Command line arguments: l


   EFI version: 2.70


   EFI Firmware: Das U-Boot (rev 8217.256)


   Console: efi (0)


   Load Path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x81f,0x18fa8)/\efi\boot\bootarm.efi


   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x81f,0x18fa8)


Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x81f,0x18fa8)


Setting currdev to disk0p1:


\|/-\|/-\|/-Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x197c7,0xe96839)


Setting currdev to disk0p2:


\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-Loading /boot/defaults/loader.conf

same log from non-working one - not detect disk, but configure lan
Code:
U-Boot SPL 2020.07 (Oct 23 2020 - 01:32:02 +0000)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2020.07 (Oct 23 2020 - 01:32:02 +0000) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: LeMaker Banana Pi
I2C:   ready
DRAM:  1 GiB
MMC:   mmc@1c0f000: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Setting up a 720x576i composite-pal console (overscan 32x20)
In:    serial
Out:   vga
Err:   vga
Net:   eth0: ethernet@1c50000
starting USB...
Bus usb@1c14000: USB EHCI 1.00
Bus usb@1c14400: USB OHCI 1.0
Bus usb@1c1c000: USB EHCI 1.00
Bus usb@1c1c400: USB OHCI 1.0
scanning bus usb@1c14000 for devices... 1 USB Device(s) found
scanning bus usb@1c14400 for devices... 1 USB Device(s) found
scanning bus usb@1c1c000 for devices... 2 USB Device(s) found
scanning bus usb@1c1c400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  2  1  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
37488 bytes read in 4 ms (8.9 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disk mmc@1c0f000.blk...
** Unrecognized filesystem type **
Scanning disk usb_mass_storage.lun0...
** Unrecognized filesystem type **
Found 5 disks
7[r[999;999H[6n8BootOrder not defined
EFI boot manager: Cannot load any image
622632 bytes read in 37 ms (16 MiB/s)
[?25hConsoles: EFI console 


|/-\|    Reading loader env vars from /efi/freebsd/loader.env


Setting currdev to disk0p1:


/-\|/-FreeBSD/arm EFI loader, Revision 1.1





   Command line arguments: l


   EFI version: 2.80


   EFI Firmware: Das U-Boot (rev 8224.1792)


   Console: efi (0)


   Load Path: /efi\boot\bootarm.efi


   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x81f,0x18fa8)


Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x81f,0x18fa8)


Setting currdev to disk0p1:


\|/-\|/-\|/-Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x197c7,0x1d92839)


Setting currdev to disk0p2:


\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf


/-\|/-\Loading /boot/defaults/loader.conf
 
Hi,

I solved (workarounded) this problem for me.

The issue is not in FreeBSD, but in u-Boot SPL. I found, that boot with U-Boot SPL 2019.01 (Feb 07 2019 - 11:10:28 +0000) works fine, but with U-Boot SPL 2020.07 (Oct 23 2020 - 01:32:02 +0000) does not.

I have not enough knowledge, how to compile u-Boot on FreeBSD, but I found article on lemaker wiki, how bananapi understand u-boot: http://wiki.lemaker.org/BananaPro/Pi:Setting_up_the_bootable_SD_card

Then I created my new SD card by following way:
  1. copy image of version I want to have on card: dd if=FreeBSD-12.2-RELEASE-arm-armv7-BANANAPI.img of=/dev/mmcsd0 bs=512
  2. replace uBoot from image that works for me: dd if=FreeBSD-13.0-CURRENT-arm-armv7-BANANAPI-20190207-r343862.img of=/dev/mmcsd0 bs=512 count=2077

In step 2 I assume, both images have same partition information in sector 1. If not, then first sector should be skipped. (by lemaker wiki up to 16 sectors can be skipped).
 
If you haven't already, it would help if your reported this (both the problem and the workaround) on the freebsd-arm mailing list. That's where developers hang out.
 
If you haven't already, it would help if your reported this (both the problem and the workaround) on the freebsd-arm mailing list. That's where developers hang out.
Hi tingo,
Thank you, I did not reported it yet. Yes, you are right, it can be helpful to report it. Do it for me please.
Thank you.
 
Why? I'm firmly in the camp "do your own homework". So - if you have a problem - you need to report it. If you can't be bothered to do it (or can't be bothered to learn how to do it) there is no problem; only somebody who is complaining without any evidence to back it up.

Why it is important that the person / persons that have the problem report it? Because the developers might have questions and / or tests to run in order to figure out the nature of the problem and (hopefully) a fix.

Even for a small and easily reproduced problem it is helpful to FreeBSD (the project) that you (the person who sees / discovers the problem) report it; at a minimum it shows the number of people actually using FreeBSD, and that said people are not only interested in getting bugs fixed, but also that they are willing to help in this process by reporting the bugs.
 
I have a BananaPi and it has been nothing but trouble on FreeBSD.
Many boards have a person who tends after a board. BananaPi has no one that I could find.
On top of that there are many BPI varients like Lemaker that are not supported. BPI-R2 router board is not either.

What will be interesting to see is what is going on with FreeBSD 13 and GENERICSD image.
How does it work on BPI-M1 ???
No sense didling with the past. On Arm you want to stay up to date. GenericSD image should work.
Have you tried it?
 
What will be interesting to see is what is going on with FreeBSD 13 and GENERICSD image.
How does it work on BPI-M1 ???
No sense didling with the past. On Arm you want to stay up to date. GenericSD image should work.
Have you tried it?
Yes and no.
I did a try where I simply dd image to sd card. It not boot at all. Screen remain black.
Then I decided, some more steps needs to happen as part of installation. Some adoption? I do not know.
Once dd from image to SD should be fine, then they does not work on my BPI-M1. If some more steps need to be done, then can anyone point me to some handbook? I will happily do some testing.

BTW: BPI is not listed as supported hardware for 13.0 https://www.freebsd.org/where/ oh here: https://www.freebsd.org/releases/13.0R/hardware/
 
Hi Fulda, you aren't the only Banana Pi user, left. I have 1, too and run it with FreeBSD (despite armv7 beeing tier 2 and is cumbersome to update) since 32 bit Linux doesn't offer stable ZFS :-(

I had the same problem and was happy to find a workaround. THX so far.
Since I intend to use the board as a remote backup server, I need it to boot unattended. But the 13.0 current image, mentioned by you, is not available any longer. So here is my, even easier, workaround, documented for future users with this problem:

1.) Go to U-Boot console by pressing any key but enter directly at boot.
2.) Get contents of variable "preboot" by typing: ==> printenv preboot
3.) Add "scsi scan" as mentioned above to the preboot commands by typing: ==> setenv preboot "<existing value as mentioned by 2.)>;scsi scan"
4.) Save to disk (SD card) by typing ==> saveenv
5.) reboot once to have the preeboot command executed

I'm aware that this is still a workaround but I'm not able to fix the u-boot-pkg's. But would be happy to test, if the pkg gets fixed.

Greetings from hell
Betzi
 
But the 13.0 current image, mentioned by you, is not available any longer.
13.0-RELEASE was released in the meantime. So 13.0-CURRENT stopped existing. -CURRENT actually moved on to 14.0.
 
13.0-RELEASE was released in the meantime. So 13.0-CURRENT stopped existing. -CURRENT actually moved on to 14.0.
The reason is clear. (Anyway, since I'm running 13 RELEASE on several machines:-D).
But in this case, that has the implication that the bootloader, included in the - pre13R ..-BANANAPI-Images, isn't available any more as well. BTW, I tried the bootloaders from the 12.1 and 12.2 R images to get stuck with "EHCI unable to shut down... " error. So I was not (and assumingly other BPi users in the future will not be) able to use the workaround from Fulda mentioned above. That's why I documented the "preboot"-wa, since users might not be familiar with u-boot internals as I was myself, before investing some time...
 
which package does provide the command scsi for FreeBSD 13 RELEASE?
It's part of U-boot, not part of FreeBSD. U-boot is a small environment that's used to boot FreeBSD or Linux on certain devices.
 
scsi command is not in u-boot:
Code:
=> scsi
Unknown command 'scsi' - try 'help'
=> sata
sata - SATA sub system

Usage:
sata init - init SATA sub system
sata stop [dev] - disable SATA sub system or device
sata info - show available SATA devices
sata device [dev] - show or set current device
sata part [dev] - print partition table
sata read addr blk# cnt
sata write addr blk# cnt
=>
 
Spoke too soon. It is part of u-boot but not built automatically for my devices build.
/work/u-boot-2021.07/drivers/scsi/
Code:
config SCSI
    bool "Support SCSI controllers"
    select HAVE_BLOCK_DEVICE
    help
      This enables support for SCSI (Small Computer System Interface),
      a parallel interface widely used with storage peripherals such as
      hard drives and optical drives. The SCSI standards define physical
      interfaces as well as protocols for controlling devices and
      tranferring data.

config DM_SCSI
    bool "Support SCSI controllers with driver model"
    depends on BLK
    help
      This option enables the SCSI (Small Computer System Interface) uclass
      which supports SCSI and SATA HDDs. For every device configuration
      (IDs/LUNs) a block device is created with RAW read/write and
      filesystem support.
 
Last edited:
It is strange that I do not see that setting in the U-boot source files.
/usr/ports/sysutils/u-boot-bananapi/work/u-boot-2021.07/arch/arm/dts/sun7i-a20-bananapi.dts
But searching its include file:
/usr/ports/sysutils/u-boot-bananapi/work/u-boot-2021.07/arch/arm/dts/sun7i-a20.dtsi
I find SATA setting @line 689
Code:
        };

        ahci: sata@1c18000 {
            compatible = "allwinner,sun4i-a10-ahci";
            reg = <0x01c18000 0x1000>;
            interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
            clocks = <&ccu CLK_AHB_SATA>, <&ccu CLK_SATA>;
            status = "disabled";
        };

target-supply = <0x24> is not seen here.

I also check our vendor DTS in /usr/src/sys/gnu/arm/dts/ and find the same thing.
This setting is not in the dts.

What gives?

I can do scsi scan from uboot prompt and the drive is discovered.
So it sounds like the same u-boot error.

The armbian references above seem like the same error too.

I thought of making a uboot script to fire scsi scan on bootup.
 
Well I decided to decompile the /boot/msdos/ DTB file to see what it is doing:
dtc -I dtb -O dts -o pi.dts sun7i-a20-bananapi.dtb
Code:
                sata@1c18000 {

                        compatible = "allwinner,sun4i-a10-ahci";
                        reg = <0x1c18000 0x1000>;
                        interrupts = <0x0 0x38 0x4>;
                        clocks = <0x2 0x31 0x2 0x7a>;
                        status = "okay";
                        phandle = <0x63>;
I see no target-supply there either.
 
I was just looking at the build routine for ExpressoBin and you must do some manual upgrade to SPI flash.
Looking at the commands needed I saw this u-boot line.
Code:
setenv bootcmd_sata 'setenv devnum 0; scsi scan; scsi dev 0; setenv boot_interface scsi; run scan_dev_for_boot;'

I need to look at printenv for BananaPi-M1. It looks like scsi scan should be in the env.
 
Back
Top