Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
I amd64 -> aarch64 cross built -r337347 and installed it
(and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
bootaa64.efi) as an update. My attempted synchronization
of loader.conf and ttys and devd.conf may be incorrect.
(Previous to this the Pine64+ 2GB seemed to be working
okay but it was at a very old build.)

The kernel config has GENERIC included but the various
debug features disabled. (My typical operating
environment.)

For all I know what the below shows might be expected
at this point. The kernel seems to have problems with
the MMC (that the kernel was loaded from). No other
media are attached. mmcsd0 is really an 128 GiByte
emmc on an adapter. (This historically worked for me.)

Still, the below may give other general hints about the
status of things for Pine64+ 2GB's.

The serial console shows . . .

U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1


U-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64+
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Failed (-5)
In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c30000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
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
477384 bytes read in 25 ms (18.2 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
## Starting EFI application at 40080000 ...
Consoles: EFI console  
FreeBSD/arm64 EFI loader, Revision 1.1

   Command line arguments: loader.efi
   EFI version: 2.70
   EFI Firmware: Das U-Boot (rev 0.00)
   Console: efi (0)
   Load Path: /\efi\boot\bootaa64.efi
   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
Setting currdev to disk0p1:
Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24400,0xe600000)
Setting currdev to disk0p2:
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x8ce84a data=0x148020+0x72caac syms=[0x8+0x11d000+0x8+0x1108a8]
/boot/entropy size=0x1000
/boot/kernel/umodem.ko text=0x2168 text=0x1410 data=0x102d0+0xfd40 syms=[0x8+0xf30+0x8+0xb73]

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...              
Using DTB provided by EFI at 0x47ffc000.
EHCI failed to shut down host controller.
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT  r337347M arm64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
VT: init without driver.
KLD file umodem.ko is missing dependencies
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: unblocking device.
random: entropy device external interface
MAP 47fff000 mode 2 pages 1
MAP 48003000 mode 2 pages 1
MAP b8f20000 mode 2 pages 1
MAP bdfb9000 mode 2 pages 2
kbd0 at kbdmux0
ofwbus0: <Open Firmware Device Tree>
clk_fixed0: <Fixed clock> on ofwbus0
clk_fixed1: <Fixed clock> on ofwbus0
clk_fixed2: <Fixed clock> on ofwbus0
simplebus0: <Flattened device tree simple bus> on ofwbus0
ccu_a64ng0: <Allwinner A64 Clock Control Unit NG> mem 0x1c20000-0x1c203ff on simplebus0
iichb0: <Allwinner Integrated I2C Bus Controller> mem 0x1c2b000-0x1c2b3ff irq 21 on simplebus0
iicbus0: <OFW I2C bus> on iichb0
regfix0: <Fixed Regulator> on ofwbus0
ccu_sun8i_r0: <Allwinner SUN8I_R Clock Control Unit NG> mem 0x1f01400-0x1f014ff on simplebus0
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
gic0: <ARM Generic Interrupt Controller> mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224
gpio0: <Allwinner GPIO/Pinmux controller> mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0
gpiobus0: <OFW GPIO bus> on gpio0
gpio1: <Allwinner GPIO/Pinmux controller> mem 0x1f02c00-0x1f02fff irq 26 on simplebus0
gpiobus1: <OFW GPIO bus> on gpio1
generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
rtc0: <Allwinner RTC> mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0
rtc0: registered as a time-of-day clock, resolution 1.000000s
awusbphy0: <Allwinner USB PHY> mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0
cpulist0: <Open Firmware CPU Group> on ofwbus0
cpu0: <Open Firmware CPU> on cpulist0
cpu1: <Open Firmware CPU> on cpulist0
cpu2: <Open Firmware CPU> on cpulist0
cpu3: <Open Firmware CPU> on cpulist0
aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
mmc0: <MMC/SD bus> on aw_mmc0
ehci0: <Allwinner Integrated USB 2.0 controller> mem 0x1c1b000-0x1c1b0ff irq 10 on simplebus0
usbus0: EHCI version 1.0
usbus0 on ehci0
ohci0: <Generic OHCI Controller> mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0
usbus1 on ohci0
gpioc0: <GPIO controller> on gpio0
uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0
uart0: console (115384,n,8,1)
iic0: <I2C generic I/O> on iicbus0
gpioc1: <GPIO controller> on gpio1
syscon_generic0: <syscon> mem 0x1c00000-0x1c00fff on simplebus0
awg0: <Allwinner Gigabit Ethernet> mem 0x1c30000-0x1c3ffff irq 27 on simplebus0
miibus0: <MII bus> on awg0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
awg0: Ethernet address: 02:ba:b1:c5:93:b7
cryptosoft0: <software crypto>
Timecounters tick every 1.000 msec
usbus0: 480Mbps High Speed USB v2.0
usbus1: 12Mbps Full Speed USB v1.0
AW_MMC_INT_RESP_TIMEOUT
ugen0.1: <Allwinner EHCI root HUB> at usbus0
AW_MMC_INT_RESP_TIMEOUT
uhub0: <Allwinner EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
ugen1.1: <Generic OHCI root HUB> at usbus1
uhub1: <Generic OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_DATA_END_BIT_ERR
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
mmc0: Failed to set VCCQ for card at relative address 2
uhub1: 1 port with 1 removable, self powered
uhub0: 1 port with 1 removable, self powered
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
aw_mmc0: controller timeout
aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000

mmcsd0: Error reading EXT_CSD Timeout
device_attach: mmcsd0 attach returned 6
Release APs...done
Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]...
CPU  0: ARM Cortex-A53 r0p4mountroot: waiting for device /dev/ufs/PINE64P2Grootfs...
 affinity:  0
 Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
 Instruction Set Attributes 1 = <>
         Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
         Processor Features 1 = <0>
      Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
      Memory Model Features 1 = <>
      Memory Model Features 2 = <32b CCIDX,48b VA>
             Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
             Debug Features 1 = <0>
         Auxiliary Features 0 = <0>
         Auxiliary Features 1 = <0>
CPU  1: ARM Cortex-A53 r0p4 affinity:  1
CPU  2: ARM Cortex-A53 r0p4 affinity:  2
CPU  3: ARM Cortex-A53 r0p4 affinity:  3
Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/ufs/PINE64P2Grootfs
  vfs.root.mountfrom.options=rw,noatime

Manual root filesystem specification:
  <fstype>:<device> [options]
      Mount <device> using filesystem <fstype>
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:tank
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
  <empty line>    Abort manual input

mountroot> ?

List of GEOM managed disk devices:
 

mountroot>




The "M" in -r337347M is mostly for code tied to powerpc
family experiments. (I try to have a single /usr/src/
code base.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

Emmanuel Vadot-7
On Mon, 6 Aug 2018 02:48:57 -0700
Mark Millard via freebsd-arm <[hidden email]> wrote:

> I amd64 -> aarch64 cross built -r337347 and installed it
> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
> bootaa64.efi) as an update. My attempted synchronization
> of loader.conf and ttys and devd.conf may be incorrect.
> (Previous to this the Pine64+ 2GB seemed to be working
> okay but it was at a very old build.)
>
> The kernel config has GENERIC included but the various
> debug features disabled. (My typical operating
> environment.)
>
> For all I know what the below shows might be expected
> at this point. The kernel seems to have problems with
> the MMC (that the kernel was loaded from). No other
> media are attached. mmcsd0 is really an 128 GiByte
> emmc on an adapter. (This historically worked for me.)

 emmc to sd ? that's weird ...
 Can you boot -v and post the result please ?

> Still, the below may give other general hints about the
> status of things for Pine64+ 2GB's.
>
> The serial console shows . . .
>
> U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000)
> DRAM: 2048 MiB
> Trying to boot from MMC1
>
>
> U-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology
>
> CPU:   Allwinner A64 (SUN50I)
> Model: Pine64+
> DRAM:  2 GiB
> MMC:   SUNXI SD/MMC: 0
> Loading Environment from FAT... *** Warning - bad CRC, using default environment
>
> Failed (-5)
> In:    serial
> Out:   serial
> Err:   serial
> Net:   phy interface7
> eth0: ethernet@1c30000
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB OHCI 1.0
> scanning bus 0 for devices... 1 USB Device(s) found
>        scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0(part 0) is current device
> Scanning mmc 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> 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
> 477384 bytes read in 25 ms (18.2 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> ## Starting EFI application at 40080000 ...
> Consoles: EFI console  
> FreeBSD/arm64 EFI loader, Revision 1.1
>
>    Command line arguments: loader.efi
>    EFI version: 2.70
>    EFI Firmware: Das U-Boot (rev 0.00)
>    Console: efi (0)
>    Load Path: /\efi\boot\bootaa64.efi
>    Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
> Setting currdev to disk0p1:
> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24400,0xe600000)
> Setting currdev to disk0p2:
> Loading /boot/defaults/loader.conf
> /boot/kernel/kernel text=0x8ce84a data=0x148020+0x72caac syms=[0x8+0x11d000+0x8+0x1108a8]
> /boot/entropy size=0x1000
> /boot/kernel/umodem.ko text=0x2168 text=0x1410 data=0x102d0+0xfd40 syms=[0x8+0xf30+0x8+0xb73]
>
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...              
> Using DTB provided by EFI at 0x47ffc000.
> EHCI failed to shut down host controller.
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT  r337347M arm64
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
> VT: init without driver.
> KLD file umodem.ko is missing dependencies
> Starting CPU 1 (1)
> Starting CPU 2 (2)
> Starting CPU 3 (3)
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> random: unblocking device.
> random: entropy device external interface
> MAP 47fff000 mode 2 pages 1
> MAP 48003000 mode 2 pages 1
> MAP b8f20000 mode 2 pages 1
> MAP bdfb9000 mode 2 pages 2
> kbd0 at kbdmux0
> ofwbus0: <Open Firmware Device Tree>
> clk_fixed0: <Fixed clock> on ofwbus0
> clk_fixed1: <Fixed clock> on ofwbus0
> clk_fixed2: <Fixed clock> on ofwbus0
> simplebus0: <Flattened device tree simple bus> on ofwbus0
> ccu_a64ng0: <Allwinner A64 Clock Control Unit NG> mem 0x1c20000-0x1c203ff on simplebus0
> iichb0: <Allwinner Integrated I2C Bus Controller> mem 0x1c2b000-0x1c2b3ff irq 21 on simplebus0
> iicbus0: <OFW I2C bus> on iichb0
> regfix0: <Fixed Regulator> on ofwbus0
> ccu_sun8i_r0: <Allwinner SUN8I_R Clock Control Unit NG> mem 0x1f01400-0x1f014ff on simplebus0
> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
> gic0: <ARM Generic Interrupt Controller> mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224
> gpio0: <Allwinner GPIO/Pinmux controller> mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0
> gpiobus0: <OFW GPIO bus> on gpio0
> gpio1: <Allwinner GPIO/Pinmux controller> mem 0x1f02c00-0x1f02fff irq 26 on simplebus0
> gpiobus1: <OFW GPIO bus> on gpio1
> generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
> rtc0: <Allwinner RTC> mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0
> rtc0: registered as a time-of-day clock, resolution 1.000000s
> awusbphy0: <Allwinner USB PHY> mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0
> cpulist0: <Open Firmware CPU Group> on ofwbus0
> cpu0: <Open Firmware CPU> on cpulist0
> cpu1: <Open Firmware CPU> on cpulist0
> cpu2: <Open Firmware CPU> on cpulist0
> cpu3: <Open Firmware CPU> on cpulist0
> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
> mmc0: <MMC/SD bus> on aw_mmc0
> ehci0: <Allwinner Integrated USB 2.0 controller> mem 0x1c1b000-0x1c1b0ff irq 10 on simplebus0
> usbus0: EHCI version 1.0
> usbus0 on ehci0
> ohci0: <Generic OHCI Controller> mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0
> usbus1 on ohci0
> gpioc0: <GPIO controller> on gpio0
> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0
> uart0: console (115384,n,8,1)
> iic0: <I2C generic I/O> on iicbus0
> gpioc1: <GPIO controller> on gpio1
> syscon_generic0: <syscon> mem 0x1c00000-0x1c00fff on simplebus0
> awg0: <Allwinner Gigabit Ethernet> mem 0x1c30000-0x1c3ffff irq 27 on simplebus0
> miibus0: <MII bus> on awg0
> rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0
> rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
> rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
> rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
> awg0: Ethernet address: 02:ba:b1:c5:93:b7
> cryptosoft0: <software crypto>
> Timecounters tick every 1.000 msec
> usbus0: 480Mbps High Speed USB v2.0
> usbus1: 12Mbps Full Speed USB v1.0
> AW_MMC_INT_RESP_TIMEOUT
> ugen0.1: <Allwinner EHCI root HUB> at usbus0
> AW_MMC_INT_RESP_TIMEOUT
> uhub0: <Allwinner EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
> ugen1.1: <Generic OHCI root HUB> at usbus1
> uhub1: <Generic OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
> AW_MMC_INT_RESP_TIMEOUT
> AW_MMC_INT_RESP_TIMEOUT
> AW_MMC_INT_RESP_TIMEOUT
> AW_MMC_INT_RESP_TIMEOUT
> AW_MMC_INT_RESP_TIMEOUT
> AW_MMC_INT_RESP_TIMEOUT
> AW_MMC_INT_DATA_END_BIT_ERR
> AW_MMC_INT_RESP_TIMEOUT
> AW_MMC_INT_RESP_TIMEOUT
> AW_MMC_INT_RESP_TIMEOUT
> AW_MMC_INT_RESP_TIMEOUT
> mmc0: Failed to set VCCQ for card at relative address 2
> uhub1: 1 port with 1 removable, self powered
> uhub0: 1 port with 1 removable, self powered
> aw_mmc0: controller timeout
> aw_mmc0: timeout updating clock
> aw_mmc0: controller timeout
> aw_mmc0: timeout updating clock
> aw_mmc0: controller timeout
> aw_mmc0: timeout updating clock
> aw_mmc0: controller timeout
> aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000
>
> mmcsd0: Error reading EXT_CSD Timeout
> device_attach: mmcsd0 attach returned 6
> Release APs...done
> Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]...
> CPU  0: ARM Cortex-A53 r0p4mountroot: waiting for device /dev/ufs/PINE64P2Grootfs...
>  affinity:  0
>  Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
>  Instruction Set Attributes 1 = <>
>          Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
>          Processor Features 1 = <0>
>       Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
>       Memory Model Features 1 = <>
>       Memory Model Features 2 = <32b CCIDX,48b VA>
>              Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
>              Debug Features 1 = <0>
>          Auxiliary Features 0 = <0>
>          Auxiliary Features 1 = <0>
> CPU  1: ARM Cortex-A53 r0p4 affinity:  1
> CPU  2: ARM Cortex-A53 r0p4 affinity:  2
> CPU  3: ARM Cortex-A53 r0p4 affinity:  3
> Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19.
>
> Loader variables:
>   vfs.root.mountfrom=ufs:/dev/ufs/PINE64P2Grootfs
>   vfs.root.mountfrom.options=rw,noatime
>
> Manual root filesystem specification:
>   <fstype>:<device> [options]
>       Mount <device> using filesystem <fstype>
>       and with the specified (optional) option list.
>
>     eg. ufs:/dev/da0s1a
>         zfs:tank
>         cd9660:/dev/cd0 ro
>           (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>
>   ?               List valid disk boot devices
>   .               Yield 1 second (for background tasks)
>   <empty line>    Abort manual input
>
> mountroot> ?
>
> List of GEOM managed disk devices:
>  
>
> mountroot>
>
>
>
>
> The "M" in -r337347M is mostly for code tied to powerpc
> family experiments. (I try to have a single /usr/src/
> code base.)
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"


--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:

> On Mon, 6 Aug 2018 02:48:57 -0700
> Mark Millard via freebsd-arm <[hidden email]> wrote:
>
>> I amd64 -> aarch64 cross built -r337347 and installed it
>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
>> bootaa64.efi) as an update. My attempted synchronization
>> of loader.conf and ttys and devd.conf may be incorrect.
>> (Previous to this the Pine64+ 2GB seemed to be working
>> okay but it was at a very old build.)
>>
>> The kernel config has GENERIC included but the various
>> debug features disabled. (My typical operating
>> environment.)
>>
>> For all I know what the below shows might be expected
>> at this point. The kernel seems to have problems with
>> the MMC (that the kernel was loaded from). No other
>> media are attached. mmcsd0 is really an 128 GiByte
>> emmc on an adapter. (This historically worked for me.)
>
> emmc to sd ? that's weird ...

An example of the adapter I've used for this is:

https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter

emmc is multi-mode for its allowed modes of operation. Thus
its ability to frequently be used this way, such as via HS200.
emmc is commonly more robust as I understand.

(I had to modify the case the pine64+ 2GB is in in order for
the adapter/emmc combination to fit in all the way.)

> Can you boot -v and post the result please ?

Glad to . . .

DRAM: 2048 MiB
Trying to boot from MMC1


U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000)
DU-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64+
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Failed (-5)
In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c30000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
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
477384 bytes read in 25 ms (18.2 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
## Starting EFI application at 40080000 ...
Consoles: EFI console  
FreeBSD/arm64 EFI loader, Revision 1.1

   Command line arguments: loader.efi
   EFI version: 2.70
   EFI Firmware: Das U-Boot (rev 0.00)
   Console: efi (0)
   Load Path: /\efi\boot\bootaa64.efi
   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
Setting currdev to disk0p1:
Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24400,0xe600000)
Setting currdev to disk0p2:
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x8ce84a data=0x148020+0x72caac syms=[0x8+0x11d000+0x8+0x1108a8]
/boot/entropy size=0x1000
/boot/kernel/umodem.ko text=0x2168 text=0x1410 data=0x102d0+0xfd40 syms=[0x8+0xf30+0x8+0xb73]

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 9 seconds...

Type '?' for a list of commands, 'help' for more detailed help.
OK boot -v
Booting...
Using DTB provided by EFI at 0x47ffc000.
EHCI failed to shut down host controller.
KDB: debugger backends: ddb
KDB: current backend: ddb
                   Type     Physical      Virtual   #Pages Attr
     ConventionalMemory 000040000000     40000000 00007ffc WB
               Reserved 000047ffc000     47ffc000 00000003 WB
    RuntimeServicesData 000047fff000     47fff000 00000001 WB RUNTIME
               Reserved 000048000000     48000000 00000003 WB
    RuntimeServicesData 000048003000     48003000 00000001 WB RUNTIME
     ConventionalMemory 000048005000     40000000 00068ea1 WB
             LoaderData 0000b0ea6000     b0ea6000 00000001 WB
               Reserved 0000b0ea7000     b0ea7000 00000001 WB
               Reserved 0000b0ea8000     b0ea8000 00000001 WB
             LoaderData 0000b0ea9000     b0ea9000 00004000 WB
             LoaderData 0000b4ea9000     b4ea9000 00004000 WB
             LoaderCode 0000b8ea9000     b8ea9000 00000075 WB
               Reserved 0000b8f1e000     b8f1e000 00000001 WB
               Reserved 0000b8f1f000     b8f1f000 00000001 WB
    RuntimeServicesData 0000b8f20000     b8f20000 00000001 WB RUNTIME
               Reserved 0000b8f21000     b8f21000 00000001 WB
               Reserved 0000b8f22000     b8f22000 00000001 WB
               Reserved 0000b8f23000     b8f23000 00000001 WB
               Reserved 0000b8f24000     b8f24000 00000001 WB
             LoaderData 0000b8f25000     b8f25000 00005094 WB
    RuntimeServicesCode 0000bdfb9000     bdfb9000 00000002 WB RUNTIME
             LoaderData 0000bdfbb000     b8f25000 00002045 WB
Physical memory chunk(s):
  0x40000000 - 0x47ffbfff,   127 MB (  32764 pages)
  0x47fff000 - 0x47ffffff,     0 MB (      1 pages)
  0x48003000 - 0x48003fff,     0 MB (      1 pages)
  0x48005000 - 0xb0ea6fff,  1678 MB ( 429730 pages)
  0xb0ea9000 - 0xb8f1dfff,   128 MB (  32885 pages)
  0xb8f20000 - 0xb8f20fff,     0 MB (      1 pages)
  0xb8f25000 - 0xbdfb8fff,    80 MB (  20628 pages)
  0xbdfbb000 - 0xbfffffff,    32 MB (   8261 pages)
Excluded memory regions:
  0x47ffc000 - 0x48003fff,     0 MB (      8 pages) NoAlloc
  0xb0ea7000 - 0xb0ea8fff,     0 MB (      2 pages) NoAlloc
  0xb1000000 - 0xb25e1fff,    21 MB (   5602 pages) NoAlloc
  0xb8f1e000 - 0xb8f24fff,     0 MB (      7 pages) NoAlloc
  0xbdfb9000 - 0xbdfbafff,     0 MB (      2 pages) NoAlloc
Found 4 CPUs in the device tree
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT  r337347M arm64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
VT: init without driver.
Preloaded elf kernel "/boot/kernel/kernel" at 0xffff0000013b9000.
Preloaded boot_entropy_cache "/boot/entropy" at 0xffff0000013c2020.
Preloaded elf module "/boot/kernel/umodem.ko" at 0xffff0000013c2078.
KLD file umodem.ko is missing dependencies
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: read 3840 bytes from preloaded cache
random: unblocking device.
arc4random: read 32 bytes from preloaded cache
VIMAGE (virtualized network stack) enabled
ULE: setup cpu 0
ULE: setup cpu 1
ULE: setup cpu 2
ULE: setup cpu 3
random: entropy device external interface
MAP 47fff000 mode 2 pages 1
MAP 48003000 mode 2 pages 1
MAP b8f20000 mode 2 pages 1
MAP bdfb9000 mode 2 pages 2
nfslock: pseudo-device
crypto: <crypto core>
kbd0 at kbdmux0
mem: <memory>
null: <full device, null device, zero device>
openfirm: <Open Firmware control device>
random: harvesting attach, 8 bytes (4 bits) from nexus0
ofwbus0: <Open Firmware Device Tree>
clk_fixed0: <Fixed clock> on ofwbus0
random: harvesting attach, 8 bytes (4 bits) from clk_fixed0
clk_fixed1: <Fixed clock> on ofwbus0
random: harvesting attach, 8 bytes (4 bits) from clk_fixed1
clk_fixed2: <Fixed clock> on ofwbus0
random: harvesting attach, 8 bytes (4 bits) from clk_fixed2
simplebus0: <Flattened device tree simple bus> on ofwbus0
ccu_a64ng0: <Allwinner A64 Clock Control Unit NG> mem 0x1c20000-0x1c203ff on simplebus0
ccu_a64ng0: Setting pll_periph0 as parent for ahb1
ccu_a64ng0: Setting pll_periph0 as parent for ahb2
ccu_a64ng0: Setting pll_ddr0 as parent for dram
Clock: pll_cpux, parent: osc24M(0), freq: 816000000
Clock: pll_audio, parent: osc24M(0), freq: 24571428
Clock: pll_periph0_2x, parent: osc24M(0), freq: 600000000
Clock: pll_periph1_2x, parent: osc24M(0), freq: 600000000
Clock: pll_ddr0, parent: osc24M(0), freq: 408000000
Clock: pll_ddr1, parent: osc24M(0), freq: 1344000000
Clock: pll_video0, parent: osc24M(0), freq: 30303
Clock: pll_video1, parent: osc24M(0), freq: 30303
Clock: pll_ve, parent: osc24M(0), freq: 30303
Clock: pll_gpu, parent: osc24M(0), freq: 30303
Clock: pll_de, parent: osc24M(0), freq: 30303
Clock: pll_hsic, parent: osc24M(0), freq: 1200000
Clock: apb2, parent: osc24M(1), freq: 24000000
Clock: nand, parent: osc24M(0), freq: 24000000
Clock: mmc0, parent: pll_periph0_2x(1), freq: 50000000
Clock: mmc1, parent: osc24M(0), freq: 24000000
Clock: mmc2, parent: osc24M(0), freq: 24000000
Clock: ts, parent: osc24M(0), freq: 24000000
Clock: ce, parent: osc24M(0), freq: 24000000
Clock: spi0, parent: osc24M(0), freq: 24000000
Clock: spi1, parent: osc24M(0), freq: 24000000
Clock: spdif, parent: pll_audio(0), freq: 24571428
Clock: dram, parent: pll_ddr0(0), freq: 408000000
Clock: de, parent: pll_periph0_2x(0), freq: 600000000
Clock: deinterlace, parent: pll_periph0(0), freq: 300000000
Clock: csi-sclk, parent: pll_periph0(0), freq: 300000000
Clock: csi-mclk, parent: osc24M(0), freq: 24000000
Clock: ve, parent: pll_ve(0), freq: 30303
Clock: hdmi, parent: pll_video0(0), freq: 30303
Clock: mbus, parent: pll_periph0_2x(1), freq: 200000000
Clock: gpu, parent: pll_gpu(0), freq: 30303
Clock: ahb1, parent: pll_periph0(3), freq: 300000000
Clock: ahb2, parent: pll_periph0(1), freq: 150000000
Clock: cpux, parent: pll_cpux(2), freq: 816000000
Clock: i2s0mux, parent: pll_audio-8x(0), freq: 196571424
Clock: i2s1mux, parent: pll_audio-8x(0), freq: 196571424
Clock: i2s2mux, parent: pll_audio-8x(0), freq: 196571424
Clock: axi, parent: cpux(0), freq: 204000000
Clock: apb1, parent: ahb1(0), freq: 75000000
Clock: apb, parent: cpux(0), freq: 272000000
Clock: thsdiv, parent: osc24M(0), freq: 12000000
Clock: osc12M, parent: osc24M(0), freq: 12000000
Clock: pll_periph0, parent: pll_periph0_2x(0), freq: 300000000
Clock: pll_periph1, parent: pll_periph1_2x(0), freq: 300000000
Clock: pll_audio-2x, parent: pll_audio(0), freq: 49142856
Clock: pll_audio-4x, parent: pll_audio(0), freq: 98285712
Clock: pll_audio-8x, parent: pll_audio(0), freq: 196571424
Clock: bus-mipi-dsi, parent: ahb1(0), freq: 300000000
Clock: bus-ce, parent: ahb1(0), freq: 300000000
Clock: bus-dma, parent: ahb1(0), freq: 300000000
Clock: bus-mmc0, parent: ahb1(0), freq: 300000000
Clock: bus-mmc1, parent: ahb1(0), freq: 300000000
Clock: bus-mmc2, parent: ahb1(0), freq: 300000000
Clock: bus-nand, parent: ahb1(0), freq: 300000000
Clock: bus-dram, parent: ahb1(0), freq: 300000000
Clock: bus-emac, parent: ahb2(0), freq: 150000000
Clock: bus-ts, parent: ahb1(0), freq: 300000000
Clock: bus-hstimer, parent: ahb1(0), freq: 300000000
Clock: bus-spi0, parent: ahb1(0), freq: 300000000
Clock: bus-spi1, parent: ahb1(0), freq: 300000000
Clock: bus-otg, parent: ahb1(0), freq: 300000000
Clock: bus-ehci0, parent: ahb1(0), freq: 300000000
Clock: bus-ehci1, parent: ahb2(0), freq: 150000000
Clock: bus-ohci0, parent: ahb1(0), freq: 300000000
Clock: bus-ohci1, parent: ahb2(0), freq: 150000000
Clock: bus-ve, parent: ahb1(0), freq: 300000000
Clock: bus-tcon0, parent: ahb1(0), freq: 300000000
Clock: bus-tcon1, parent: ahb1(0), freq: 300000000
Clock: bus-deinterlace, parent: ahb1(0), freq: 300000000
Clock: bus-csi, parent: ahb1(0), freq: 300000000
Clock: bus-hdmi, parent: ahb1(0), freq: 300000000
Clock: bus-de, parent: ahb1(0), freq: 300000000
Clock: bus-gpu, parent: ahb1(0), freq: 300000000
Clock: bus-msgbox, parent: ahb1(0), freq: 300000000
Clock: bus-spinlock, parent: ahb1(0), freq: 300000000
Clock: bus-codec, parent: apb1(0), freq: 75000000
Clock: bus-spdif, parent: apb1(0), freq: 75000000
Clock: bus-pio, parent: apb1(0), freq: 75000000
Clock: bus-ths, parent: apb1(0), freq: 75000000
Clock: bus-i2s0, parent: apb1(0), freq: 75000000
Clock: bus-i2s1, parent: apb1(0), freq: 75000000
Clock: bus-i2s2, parent: apb1(0), freq: 75000000
Clock: bus-i2c0, parent: apb2(0), freq: 24000000
Clock: bus-i2c1, parent: apb2(0), freq: 24000000
Clock: bus-i2c2, parent: apb2(0), freq: 24000000
Clock: bus-src, parent: apb2(0), freq: 24000000
Clock: bus-uart0, parent: apb2(0), freq: 24000000
Clock: bus-uart1, parent: apb2(0), freq: 24000000
Clock: bus-uart2, parent: apb2(0), freq: 24000000
Clock: bus-uart3, parent: apb2(0), freq: 24000000
Clock: bus-uart4, parent: apb2(0), freq: 24000000
Clock: bus-dbg, parent: ahb1(0), freq: 300000000
Clock: ths, parent: thsdiv(0), freq: 12000000
Clock: usb-phy0, parent: osc24M(0), freq: 24000000
Clock: usb-phy1, parent: osc24M(0), freq: 24000000
Clock: usb-hsic, parent: pll_hsic(0), freq: 1200000
Clock: usb-hsic-12M, parent: osc12M(0), freq: 12000000
Clock: usb-ohci0, parent: osc12M(0), freq: 12000000
Clock: usb-ohci1, parent: usb-ohci0(0), freq: 12000000
Clock: dram-ve, parent: dram(0), freq: 408000000
Clock: dram-csi, parent: dram(0), freq: 408000000
Clock: dram-deinterlace, parent: dram(0), freq: 408000000
Clock: dram-ts, parent: dram(0), freq: 408000000
Clock: csi-misc, parent: osc24M(0), freq: 24000000
Clock: ac-dig, parent: pll_audio(0), freq: 24571428
Clock: ac-dig-4x, parent: pll_audio-4x(0), freq: 98285712
Clock: avs, parent: osc24M(0), freq: 24000000
Clock: hdmi-ddc, parent: osc24M(0), freq: 24000000
random: harvesting attach, 8 bytes (4 bits) from ccu_a64ng0
iichb0: <Allwinner Integrated I2C Bus Controller> mem 0x1c2b000-0x1c2b3ff irq 21 on simplebus0
iicbus0: <OFW I2C bus> on iichb0
random: harvesting attach, 8 bytes (4 bits) from iicbus0
random: harvesting attach, 8 bytes (4 bits) from iichb0
random: harvesting attach, 8 bytes (4 bits) from simplebus0
regfix0: <Fixed Regulator> on ofwbus0
random: harvesting attach, 8 bytes (4 bits) from regfix0
random: harvesting attach, 8 bytes (4 bits) from ofwbus0
ccu_sun8i_r0: <Allwinner SUN8I_R Clock Control Unit NG> mem 0x1f01400-0x1f014ff on simplebus0
Clock: ar100, parent: osc32k(0), freq: 32768
Clock: apb0, parent: ahb0(0), freq: 32768
Clock: ahb0, parent: ar100(0), freq: 32768
Clock: ir, parent: osc32k(0), freq: 32768
Clock: apb0-pio, parent: apb0(0), freq: 32768
Clock: apb0-ir, parent: apb0(0), freq: 32768
Clock: apb0-timer, parent: apb0(0), freq: 32768
Clock: apb0-rsb, parent: apb0(0), freq: 32768
Clock: apb0-uart, parent: apb0(0), freq: 32768
Clock: apb0-i2c, parent: apb0(0), freq: 32768
Clock: apb0-twd, parent: apb0(0), freq: 32768
random: harvesting attach, 8 bytes (4 bits) from ccu_sun8i_r0
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version 0.2 compatible
random: harvesting attach, 8 bytes (4 bits) from psci0
gic0: <ARM Generic Interrupt Controller> mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224
random: harvesting attach, 8 bytes (4 bits) from gic0
gpio0: <Allwinner GPIO/Pinmux controller> mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0
gpiobus0: <OFW GPIO bus> on gpio0
random: harvesting attach, 8 bytes (4 bits) from gpiobus0
Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
random: harvesting attach, 8 bytes (4 bits) from gpio0
gpio1: <Allwinner GPIO/Pinmux controller> mem 0x1f02c00-0x1f02fff irq 26 on simplebus0
gpiobus1: <OFW GPIO bus> on gpio1
random: harvesting attach, 8 bytes (4 bits) from gpiobus1
Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
random: harvesting attach, 8 bytes (4 bits) from gpio1
generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
random: harvesting attach, 8 bytes (4 bits) from generic_timer0
rtc0: <Allwinner RTC> mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0
rtc0: Using external oscillator
rtc0: registered as a time-of-day clock, resolution 1.000000s
random: harvesting attach, 8 bytes (4 bits) from rtc0
awusbphy0: <Allwinner USB PHY> mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0
random: harvesting attach, 8 bytes (4 bits) from awusbphy0
efirtc0: cannot read EFI realtime clock
cpulist0: <Open Firmware CPU Group> on ofwbus0
cpu0: <Open Firmware CPU> on cpulist0
cpu0: missing 'clock-frequency' property
arm64_cpu0: register <0>
random: harvesting attach, 8 bytes (4 bits) from arm64_cpu0
random: harvesting attach, 8 bytes (4 bits) from cpu0
cpu1: <Open Firmware CPU> on cpulist0
cpu1: missing 'clock-frequency' property
arm64_cpu1: register <1>
random: harvesting attach, 8 bytes (4 bits) from arm64_cpu1
random: harvesting attach, 8 bytes (4 bits) from cpu1
cpu2: <Open Firmware CPU> on cpulist0
cpu2: missing 'clock-frequency' property
arm64_cpu2: register <2>
random: harvesting attach, 8 bytes (4 bits) from arm64_cpu2
random: harvesting attach, 8 bytes (4 bits) from cpu2
cpu3: <Open Firmware CPU> on cpulist0
cpu3: missing 'clock-frequency' property
arm64_cpu3: register <3>
random: harvesting attach, 8 bytes (4 bits) from arm64_cpu3
random: harvesting attach, 8 bytes (4 bits) from cpu3
random: harvesting attach, 8 bytes (4 bits) from cpulist0
aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
aw_mmc0: vmmc-supply regulator found
mmc0: <MMC/SD bus> on aw_mmc0
random: harvesting attach, 8 bytes (4 bits) from mmc0
random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached)
simplebus0: <usb@01c19000> mem 0x1c19000-0x1c193ff irq 7 compat allwinner,sun8i-a33-musb (no driver attached)
simplebus0: <usb@01c1a000> mem 0x1c1a000-0x1c1a0ff irq 8 disabled compat allwinner,sun50i-a64-ehci (no driver attached)
simplebus0: <usb@01c1a400> mem 0x1c1a400-0x1c1a4ff irq 9 disabled compat allwinner,sun50i-a64-ohci (no driver attached)
ehci0: <Allwinner Integrated USB 2.0 controller> mem 0x1c1b000-0x1c1b0ff irq 10 on simplebus0
usbus0: EHCI version 1.0
usbus0 on ehci0
ehci0: usbpf: Attached
random: harvesting attach, 8 bytes (4 bits) from usbus0
random: harvesting attach, 8 bytes (4 bits) from ehci0
ohci0: <Generic OHCI Controller> mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0
usbus1 on ohci0
ohci0: usbpf: Attached
random: harvesting attach, 8 bytes (4 bits) from usbus1
random: harvesting attach, 8 bytes (4 bits) from ohci0
gpioc0: <GPIO controller> on gpio0
random: harvesting attach, 8 bytes (4 bits) from gpioc0
simplebus0: <pwm@01c21400> mem 0x1c21400-0x1c21407 disabled compat allwinner,sun50i-a64-pwm (no driver attached)
uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0
uart0: console (115384,n,8,1)
uart0: fast interrupt
uart0: PPS capture mode: DCD
random: harvesting attach, 8 bytes (4 bits) from uart0
simplebus0: <serial@1c28400> mem 0x1c28400-0x1c287ff irq 16 disabled compat snps,dw-apb-uart (no driver attached)
simplebus0: <serial@1c28800> mem 0x1c28800-0x1c28bff irq 17 disabled compat snps,dw-apb-uart (no driver attached)
simplebus0: <serial@1c28c00> mem 0x1c28c00-0x1c28fff irq 18 disabled compat snps,dw-apb-uart (no driver attached)
simplebus0: <serial@1c29000> mem 0x1c29000-0x1c293ff irq 19 disabled compat snps,dw-apb-uart (no driver attached)
simplebus0: <i2c@1c2ac00> mem 0x1c2ac00-0x1c2afff irq 20 disabled compat allwinner,sun6i-a31-i2c (no driver attached)
iic0: <I2C generic I/O> on iicbus0
random: harvesting attach, 8 bytes (4 bits) from iic0
simplebus0: <i2c@1c2b400> mem 0x1c2b400-0x1c2b7ff irq 22 disabled compat allwinner,sun6i-a31-i2c (no driver attached)
gpioc1: <GPIO controller> on gpio1
random: harvesting attach, 8 bytes (4 bits) from gpioc1
syscon_generic0: <syscon> mem 0x1c00000-0x1c00fff on simplebus0
random: harvesting attach, 8 bytes (4 bits) from syscon_generic0
awg0: <Allwinner Gigabit Ethernet> mem 0x1c30000-0x1c3ffff irq 27 on simplebus0
simplebus0: no default resources for rid = 1, type = 3
awg0: PHY type: rgmii, conf mode: reg
awg0: EMAC clock: 0x00000006
awg0: AHB frequency 150000000 Hz, MDC div: 0x2
miibus0: <MII bus> on awg0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0
rgephy0: OUI 0x00e04c, model 0x0011, rev. 5
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
random: harvesting attach, 8 bytes (4 bits) from rgephy0
rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
rgephy1: OUI 0x00e04c, model 0x0011, rev. 5
rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
random: harvesting attach, 8 bytes (4 bits) from rgephy1
random: harvesting attach, 8 bytes (4 bits) from miibus0
awg0: bpf attached
awg0: Ethernet address: 02:ba:b1:c5:93:b7
random: harvesting attach, 8 bytes (4 bits) from awg0
cryptosoft0: <software crypto>
crypto: assign cryptosoft0 driver id 0, flags 0x6000000
crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0
crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0
random: harvesting attach, 8 bytes (4 bits) from cryptosoft0
Found SMCCC version 1.0
Device configuration finished.
procfs registered
Timecounters tick every 1.000 msec
vlan: initialized, using hash tables with chaining
lo0: bpf attached
arc4random: read 32 bytes from preloaded cache
arc4random: read 32 bytes from preloaded cache
arc4random: read 32 bytes from preloaded cache
tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384
IPsec: Initialized Security Association Processing.
usbus0: 480Mbps High Speed USB v2.0
usbus1: 12Mbps Full Speed USB v1.0
aw_mmc0: Powering up sd/mmc
mmc0: Probing bus
ugen0.1: <Allwinner EHCI root HUB> at usbus0
uhub0: <Allwinner EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
ugen1.1: <Generic OHCI root HUB> at usbus1
uhub1: <Generic OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
mmc0: SD probe: failed
mmc0: MMC probe: OK (OCR: 0x40ff8080)
mmc0: Current OCR: 0x00ff8080
mmc0: Probing cards
mmc0: New card detected (CID 150100444a4e423452079f43b2e7636f)
mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d)
aw_mmc0: error rint: 0x00008010
AW_MMC_INT_DATA_END_BIT_ERR
mmc0: Card at relative address 0x0002 added:
mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
mmc0:  quirks: 0
mmc0:  bus: 4bit, 200MHz (HS200 timing)
mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
aw_mmc0: error rint: 0x00000100
AW_MMC_INT_RESP_TIMEOUT
mmc0: setting transfer rate to 52.000MHz (dual data rate timing)
mmc0: Failed to set VCCQ for card at relative address 2
uhub1: 1 port with 1 removable, self powered
random: harvesting attach, 8 bytes (4 bits) from uhub1
uhub0: 1 port with 1 removable, self powered
random: harvesting attach, 8 bytes (4 bits) from uhub0
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
aw_mmc0: controller timeout
aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000

mmcsd0: Error reading EXT_CSD Timeout
device_attach: mmcsd0 attach returned 6
Release APs...done
Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]...
CPU  0: ARM Cortex-A53 r0p4mountroot: waiting for device /dev/ufs/PINE64P2Grootfs...
 affinity:  0
 Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
 Instruction Set Attributes 1 = <>
         Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
         Processor Features 1 = <0>
      Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
      Memory Model Features 1 = <>
      Memory Model Features 2 = <32b CCIDX,48b VA>
             Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
             Debug Features 1 = <0>
         Auxiliary Features 0 = <0>
         Auxiliary Features 1 = <0>
CPU  1: ARM Cortex-A53 r0p4 affinity:  1
CPU  2: ARM Cortex-A53 r0p4 affinity:  2
CPU  3: ARM Cortex-A53 r0p4 affinity:  3
regulator: shutting down vcc3v3
Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/ufs/PINE64P2Grootfs
  vfs.root.mountfrom.options=rw,noatime

Manual root filesystem specification:
  <fstype>:<device> [options]
      Mount <device> using filesystem <fstype>
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:tank
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
  <empty line>    Abort manual input

mountroot>



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

Emmanuel Vadot-7
On Mon, 6 Aug 2018 10:12:43 -0700
Mark Millard <[hidden email]> wrote:

> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>
> > On Mon, 6 Aug 2018 02:48:57 -0700
> > Mark Millard via freebsd-arm <[hidden email]> wrote:
> >
> >> I amd64 -> aarch64 cross built -r337347 and installed it
> >> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
> >> bootaa64.efi) as an update. My attempted synchronization
> >> of loader.conf and ttys and devd.conf may be incorrect.
> >> (Previous to this the Pine64+ 2GB seemed to be working
> >> okay but it was at a very old build.)
> >>
> >> The kernel config has GENERIC included but the various
> >> debug features disabled. (My typical operating
> >> environment.)
> >>
> >> For all I know what the below shows might be expected
> >> at this point. The kernel seems to have problems with
> >> the MMC (that the kernel was loaded from). No other
> >> media are attached. mmcsd0 is really an 128 GiByte
> >> emmc on an adapter. (This historically worked for me.)
> >
> > emmc to sd ? that's weird ...
>
> An example of the adapter I've used for this is:
>
> https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter

 So this is a passive adapter, maybe that's something that should work
but it's definitly is something that calls for problems.

> emmc is multi-mode for its allowed modes of operation. Thus
> its ability to frequently be used this way, such as via HS200.
> emmc is commonly more robust as I understand.

 I didn't understand a word.

>
> (I had to modify the case the pine64+ 2GB is in in order for
> the adapter/emmc combination to fit in all the way.)
>
> > Can you boot -v and post the result please ?
>
> Glad to . . .
>
> DRAM: 2048 MiB
> Trying to boot from MMC1
>
>
> U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000)
> DU-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology
>
> CPU:   Allwinner A64 (SUN50I)
> Model: Pine64+
> DRAM:  2 GiB
> MMC:   SUNXI SD/MMC: 0
> Loading Environment from FAT... *** Warning - bad CRC, using default environment
>
> Failed (-5)
> In:    serial
> Out:   serial
> Err:   serial
> Net:   phy interface7
> eth0: ethernet@1c30000
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB OHCI 1.0
> scanning bus 0 for devices... 1 USB Device(s) found
>        scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0(part 0) is current device
> Scanning mmc 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> 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
> 477384 bytes read in 25 ms (18.2 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> ## Starting EFI application at 40080000 ...
> Consoles: EFI console  
> FreeBSD/arm64 EFI loader, Revision 1.1
>
>    Command line arguments: loader.efi
>    EFI version: 2.70
>    EFI Firmware: Das U-Boot (rev 0.00)
>    Console: efi (0)
>    Load Path: /\efi\boot\bootaa64.efi
>    Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
> Setting currdev to disk0p1:
> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24400,0xe600000)
> Setting currdev to disk0p2:
> Loading /boot/defaults/loader.conf
> /boot/kernel/kernel text=0x8ce84a data=0x148020+0x72caac syms=[0x8+0x11d000+0x8+0x1108a8]
> /boot/entropy size=0x1000
> /boot/kernel/umodem.ko text=0x2168 text=0x1410 data=0x102d0+0xfd40 syms=[0x8+0xf30+0x8+0xb73]
>
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel] in 9 seconds...
>
> Type '?' for a list of commands, 'help' for more detailed help.
> OK boot -v
> Booting...
> Using DTB provided by EFI at 0x47ffc000.
> EHCI failed to shut down host controller.
> KDB: debugger backends: ddb
> KDB: current backend: ddb
>                    Type     Physical      Virtual   #Pages Attr
>      ConventionalMemory 000040000000     40000000 00007ffc WB
>                Reserved 000047ffc000     47ffc000 00000003 WB
>     RuntimeServicesData 000047fff000     47fff000 00000001 WB RUNTIME
>                Reserved 000048000000     48000000 00000003 WB
>     RuntimeServicesData 000048003000     48003000 00000001 WB RUNTIME
>      ConventionalMemory 000048005000     40000000 00068ea1 WB
>              LoaderData 0000b0ea6000     b0ea6000 00000001 WB
>                Reserved 0000b0ea7000     b0ea7000 00000001 WB
>                Reserved 0000b0ea8000     b0ea8000 00000001 WB
>              LoaderData 0000b0ea9000     b0ea9000 00004000 WB
>              LoaderData 0000b4ea9000     b4ea9000 00004000 WB
>              LoaderCode 0000b8ea9000     b8ea9000 00000075 WB
>                Reserved 0000b8f1e000     b8f1e000 00000001 WB
>                Reserved 0000b8f1f000     b8f1f000 00000001 WB
>     RuntimeServicesData 0000b8f20000     b8f20000 00000001 WB RUNTIME
>                Reserved 0000b8f21000     b8f21000 00000001 WB
>                Reserved 0000b8f22000     b8f22000 00000001 WB
>                Reserved 0000b8f23000     b8f23000 00000001 WB
>                Reserved 0000b8f24000     b8f24000 00000001 WB
>              LoaderData 0000b8f25000     b8f25000 00005094 WB
>     RuntimeServicesCode 0000bdfb9000     bdfb9000 00000002 WB RUNTIME
>              LoaderData 0000bdfbb000     b8f25000 00002045 WB
> Physical memory chunk(s):
>   0x40000000 - 0x47ffbfff,   127 MB (  32764 pages)
>   0x47fff000 - 0x47ffffff,     0 MB (      1 pages)
>   0x48003000 - 0x48003fff,     0 MB (      1 pages)
>   0x48005000 - 0xb0ea6fff,  1678 MB ( 429730 pages)
>   0xb0ea9000 - 0xb8f1dfff,   128 MB (  32885 pages)
>   0xb8f20000 - 0xb8f20fff,     0 MB (      1 pages)
>   0xb8f25000 - 0xbdfb8fff,    80 MB (  20628 pages)
>   0xbdfbb000 - 0xbfffffff,    32 MB (   8261 pages)
> Excluded memory regions:
>   0x47ffc000 - 0x48003fff,     0 MB (      8 pages) NoAlloc
>   0xb0ea7000 - 0xb0ea8fff,     0 MB (      2 pages) NoAlloc
>   0xb1000000 - 0xb25e1fff,    21 MB (   5602 pages) NoAlloc
>   0xb8f1e000 - 0xb8f24fff,     0 MB (      7 pages) NoAlloc
>   0xbdfb9000 - 0xbdfbafff,     0 MB (      2 pages) NoAlloc
> Found 4 CPUs in the device tree
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT  r337347M arm64
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
> VT: init without driver.
> Preloaded elf kernel "/boot/kernel/kernel" at 0xffff0000013b9000.
> Preloaded boot_entropy_cache "/boot/entropy" at 0xffff0000013c2020.
> Preloaded elf module "/boot/kernel/umodem.ko" at 0xffff0000013c2078.
> KLD file umodem.ko is missing dependencies
> Starting CPU 1 (1)
> Starting CPU 2 (2)
> Starting CPU 3 (3)
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> random: read 3840 bytes from preloaded cache
> random: unblocking device.
> arc4random: read 32 bytes from preloaded cache
> VIMAGE (virtualized network stack) enabled
> ULE: setup cpu 0
> ULE: setup cpu 1
> ULE: setup cpu 2
> ULE: setup cpu 3
> random: entropy device external interface
> MAP 47fff000 mode 2 pages 1
> MAP 48003000 mode 2 pages 1
> MAP b8f20000 mode 2 pages 1
> MAP bdfb9000 mode 2 pages 2
> nfslock: pseudo-device
> crypto: <crypto core>
> kbd0 at kbdmux0
> mem: <memory>
> null: <full device, null device, zero device>
> openfirm: <Open Firmware control device>
> random: harvesting attach, 8 bytes (4 bits) from nexus0
> ofwbus0: <Open Firmware Device Tree>
> clk_fixed0: <Fixed clock> on ofwbus0
> random: harvesting attach, 8 bytes (4 bits) from clk_fixed0
> clk_fixed1: <Fixed clock> on ofwbus0
> random: harvesting attach, 8 bytes (4 bits) from clk_fixed1
> clk_fixed2: <Fixed clock> on ofwbus0
> random: harvesting attach, 8 bytes (4 bits) from clk_fixed2
> simplebus0: <Flattened device tree simple bus> on ofwbus0
> ccu_a64ng0: <Allwinner A64 Clock Control Unit NG> mem 0x1c20000-0x1c203ff on simplebus0
> ccu_a64ng0: Setting pll_periph0 as parent for ahb1
> ccu_a64ng0: Setting pll_periph0 as parent for ahb2
> ccu_a64ng0: Setting pll_ddr0 as parent for dram
> Clock: pll_cpux, parent: osc24M(0), freq: 816000000
> Clock: pll_audio, parent: osc24M(0), freq: 24571428
> Clock: pll_periph0_2x, parent: osc24M(0), freq: 600000000
> Clock: pll_periph1_2x, parent: osc24M(0), freq: 600000000
> Clock: pll_ddr0, parent: osc24M(0), freq: 408000000
> Clock: pll_ddr1, parent: osc24M(0), freq: 1344000000
> Clock: pll_video0, parent: osc24M(0), freq: 30303
> Clock: pll_video1, parent: osc24M(0), freq: 30303
> Clock: pll_ve, parent: osc24M(0), freq: 30303
> Clock: pll_gpu, parent: osc24M(0), freq: 30303
> Clock: pll_de, parent: osc24M(0), freq: 30303
> Clock: pll_hsic, parent: osc24M(0), freq: 1200000
> Clock: apb2, parent: osc24M(1), freq: 24000000
> Clock: nand, parent: osc24M(0), freq: 24000000
> Clock: mmc0, parent: pll_periph0_2x(1), freq: 50000000
> Clock: mmc1, parent: osc24M(0), freq: 24000000
> Clock: mmc2, parent: osc24M(0), freq: 24000000
> Clock: ts, parent: osc24M(0), freq: 24000000
> Clock: ce, parent: osc24M(0), freq: 24000000
> Clock: spi0, parent: osc24M(0), freq: 24000000
> Clock: spi1, parent: osc24M(0), freq: 24000000
> Clock: spdif, parent: pll_audio(0), freq: 24571428
> Clock: dram, parent: pll_ddr0(0), freq: 408000000
> Clock: de, parent: pll_periph0_2x(0), freq: 600000000
> Clock: deinterlace, parent: pll_periph0(0), freq: 300000000
> Clock: csi-sclk, parent: pll_periph0(0), freq: 300000000
> Clock: csi-mclk, parent: osc24M(0), freq: 24000000
> Clock: ve, parent: pll_ve(0), freq: 30303
> Clock: hdmi, parent: pll_video0(0), freq: 30303
> Clock: mbus, parent: pll_periph0_2x(1), freq: 200000000
> Clock: gpu, parent: pll_gpu(0), freq: 30303
> Clock: ahb1, parent: pll_periph0(3), freq: 300000000
> Clock: ahb2, parent: pll_periph0(1), freq: 150000000
> Clock: cpux, parent: pll_cpux(2), freq: 816000000
> Clock: i2s0mux, parent: pll_audio-8x(0), freq: 196571424
> Clock: i2s1mux, parent: pll_audio-8x(0), freq: 196571424
> Clock: i2s2mux, parent: pll_audio-8x(0), freq: 196571424
> Clock: axi, parent: cpux(0), freq: 204000000
> Clock: apb1, parent: ahb1(0), freq: 75000000
> Clock: apb, parent: cpux(0), freq: 272000000
> Clock: thsdiv, parent: osc24M(0), freq: 12000000
> Clock: osc12M, parent: osc24M(0), freq: 12000000
> Clock: pll_periph0, parent: pll_periph0_2x(0), freq: 300000000
> Clock: pll_periph1, parent: pll_periph1_2x(0), freq: 300000000
> Clock: pll_audio-2x, parent: pll_audio(0), freq: 49142856
> Clock: pll_audio-4x, parent: pll_audio(0), freq: 98285712
> Clock: pll_audio-8x, parent: pll_audio(0), freq: 196571424
> Clock: bus-mipi-dsi, parent: ahb1(0), freq: 300000000
> Clock: bus-ce, parent: ahb1(0), freq: 300000000
> Clock: bus-dma, parent: ahb1(0), freq: 300000000
> Clock: bus-mmc0, parent: ahb1(0), freq: 300000000
> Clock: bus-mmc1, parent: ahb1(0), freq: 300000000
> Clock: bus-mmc2, parent: ahb1(0), freq: 300000000
> Clock: bus-nand, parent: ahb1(0), freq: 300000000
> Clock: bus-dram, parent: ahb1(0), freq: 300000000
> Clock: bus-emac, parent: ahb2(0), freq: 150000000
> Clock: bus-ts, parent: ahb1(0), freq: 300000000
> Clock: bus-hstimer, parent: ahb1(0), freq: 300000000
> Clock: bus-spi0, parent: ahb1(0), freq: 300000000
> Clock: bus-spi1, parent: ahb1(0), freq: 300000000
> Clock: bus-otg, parent: ahb1(0), freq: 300000000
> Clock: bus-ehci0, parent: ahb1(0), freq: 300000000
> Clock: bus-ehci1, parent: ahb2(0), freq: 150000000
> Clock: bus-ohci0, parent: ahb1(0), freq: 300000000
> Clock: bus-ohci1, parent: ahb2(0), freq: 150000000
> Clock: bus-ve, parent: ahb1(0), freq: 300000000
> Clock: bus-tcon0, parent: ahb1(0), freq: 300000000
> Clock: bus-tcon1, parent: ahb1(0), freq: 300000000
> Clock: bus-deinterlace, parent: ahb1(0), freq: 300000000
> Clock: bus-csi, parent: ahb1(0), freq: 300000000
> Clock: bus-hdmi, parent: ahb1(0), freq: 300000000
> Clock: bus-de, parent: ahb1(0), freq: 300000000
> Clock: bus-gpu, parent: ahb1(0), freq: 300000000
> Clock: bus-msgbox, parent: ahb1(0), freq: 300000000
> Clock: bus-spinlock, parent: ahb1(0), freq: 300000000
> Clock: bus-codec, parent: apb1(0), freq: 75000000
> Clock: bus-spdif, parent: apb1(0), freq: 75000000
> Clock: bus-pio, parent: apb1(0), freq: 75000000
> Clock: bus-ths, parent: apb1(0), freq: 75000000
> Clock: bus-i2s0, parent: apb1(0), freq: 75000000
> Clock: bus-i2s1, parent: apb1(0), freq: 75000000
> Clock: bus-i2s2, parent: apb1(0), freq: 75000000
> Clock: bus-i2c0, parent: apb2(0), freq: 24000000
> Clock: bus-i2c1, parent: apb2(0), freq: 24000000
> Clock: bus-i2c2, parent: apb2(0), freq: 24000000
> Clock: bus-src, parent: apb2(0), freq: 24000000
> Clock: bus-uart0, parent: apb2(0), freq: 24000000
> Clock: bus-uart1, parent: apb2(0), freq: 24000000
> Clock: bus-uart2, parent: apb2(0), freq: 24000000
> Clock: bus-uart3, parent: apb2(0), freq: 24000000
> Clock: bus-uart4, parent: apb2(0), freq: 24000000
> Clock: bus-dbg, parent: ahb1(0), freq: 300000000
> Clock: ths, parent: thsdiv(0), freq: 12000000
> Clock: usb-phy0, parent: osc24M(0), freq: 24000000
> Clock: usb-phy1, parent: osc24M(0), freq: 24000000
> Clock: usb-hsic, parent: pll_hsic(0), freq: 1200000
> Clock: usb-hsic-12M, parent: osc12M(0), freq: 12000000
> Clock: usb-ohci0, parent: osc12M(0), freq: 12000000
> Clock: usb-ohci1, parent: usb-ohci0(0), freq: 12000000
> Clock: dram-ve, parent: dram(0), freq: 408000000
> Clock: dram-csi, parent: dram(0), freq: 408000000
> Clock: dram-deinterlace, parent: dram(0), freq: 408000000
> Clock: dram-ts, parent: dram(0), freq: 408000000
> Clock: csi-misc, parent: osc24M(0), freq: 24000000
> Clock: ac-dig, parent: pll_audio(0), freq: 24571428
> Clock: ac-dig-4x, parent: pll_audio-4x(0), freq: 98285712
> Clock: avs, parent: osc24M(0), freq: 24000000
> Clock: hdmi-ddc, parent: osc24M(0), freq: 24000000
> random: harvesting attach, 8 bytes (4 bits) from ccu_a64ng0
> iichb0: <Allwinner Integrated I2C Bus Controller> mem 0x1c2b000-0x1c2b3ff irq 21 on simplebus0
> iicbus0: <OFW I2C bus> on iichb0
> random: harvesting attach, 8 bytes (4 bits) from iicbus0
> random: harvesting attach, 8 bytes (4 bits) from iichb0
> random: harvesting attach, 8 bytes (4 bits) from simplebus0
> regfix0: <Fixed Regulator> on ofwbus0
> random: harvesting attach, 8 bytes (4 bits) from regfix0
> random: harvesting attach, 8 bytes (4 bits) from ofwbus0
> ccu_sun8i_r0: <Allwinner SUN8I_R Clock Control Unit NG> mem 0x1f01400-0x1f014ff on simplebus0
> Clock: ar100, parent: osc32k(0), freq: 32768
> Clock: apb0, parent: ahb0(0), freq: 32768
> Clock: ahb0, parent: ar100(0), freq: 32768
> Clock: ir, parent: osc32k(0), freq: 32768
> Clock: apb0-pio, parent: apb0(0), freq: 32768
> Clock: apb0-ir, parent: apb0(0), freq: 32768
> Clock: apb0-timer, parent: apb0(0), freq: 32768
> Clock: apb0-rsb, parent: apb0(0), freq: 32768
> Clock: apb0-uart, parent: apb0(0), freq: 32768
> Clock: apb0-i2c, parent: apb0(0), freq: 32768
> Clock: apb0-twd, parent: apb0(0), freq: 32768
> random: harvesting attach, 8 bytes (4 bits) from ccu_sun8i_r0
> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
> psci0: PSCI version 0.2 compatible
> random: harvesting attach, 8 bytes (4 bits) from psci0
> gic0: <ARM Generic Interrupt Controller> mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224
> random: harvesting attach, 8 bytes (4 bits) from gic0
> gpio0: <Allwinner GPIO/Pinmux controller> mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0
> gpiobus0: <OFW GPIO bus> on gpio0
> random: harvesting attach, 8 bytes (4 bits) from gpiobus0
> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
> random: harvesting attach, 8 bytes (4 bits) from gpio0
> gpio1: <Allwinner GPIO/Pinmux controller> mem 0x1f02c00-0x1f02fff irq 26 on simplebus0
> gpiobus1: <OFW GPIO bus> on gpio1
> random: harvesting attach, 8 bytes (4 bits) from gpiobus1
> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
> random: harvesting attach, 8 bytes (4 bits) from gpio1
> generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
> random: harvesting attach, 8 bytes (4 bits) from generic_timer0
> rtc0: <Allwinner RTC> mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0
> rtc0: Using external oscillator
> rtc0: registered as a time-of-day clock, resolution 1.000000s
> random: harvesting attach, 8 bytes (4 bits) from rtc0
> awusbphy0: <Allwinner USB PHY> mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0
> random: harvesting attach, 8 bytes (4 bits) from awusbphy0
> efirtc0: cannot read EFI realtime clock
> cpulist0: <Open Firmware CPU Group> on ofwbus0
> cpu0: <Open Firmware CPU> on cpulist0
> cpu0: missing 'clock-frequency' property
> arm64_cpu0: register <0>
> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu0
> random: harvesting attach, 8 bytes (4 bits) from cpu0
> cpu1: <Open Firmware CPU> on cpulist0
> cpu1: missing 'clock-frequency' property
> arm64_cpu1: register <1>
> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu1
> random: harvesting attach, 8 bytes (4 bits) from cpu1
> cpu2: <Open Firmware CPU> on cpulist0
> cpu2: missing 'clock-frequency' property
> arm64_cpu2: register <2>
> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu2
> random: harvesting attach, 8 bytes (4 bits) from cpu2
> cpu3: <Open Firmware CPU> on cpulist0
> cpu3: missing 'clock-frequency' property
> arm64_cpu3: register <3>
> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu3
> random: harvesting attach, 8 bytes (4 bits) from cpu3
> random: harvesting attach, 8 bytes (4 bits) from cpulist0
> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
> aw_mmc0: vmmc-supply regulator found
> mmc0: <MMC/SD bus> on aw_mmc0
> random: harvesting attach, 8 bytes (4 bits) from mmc0
> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
> simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
> simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached)
> simplebus0: <usb@01c19000> mem 0x1c19000-0x1c193ff irq 7 compat allwinner,sun8i-a33-musb (no driver attached)
> simplebus0: <usb@01c1a000> mem 0x1c1a000-0x1c1a0ff irq 8 disabled compat allwinner,sun50i-a64-ehci (no driver attached)
> simplebus0: <usb@01c1a400> mem 0x1c1a400-0x1c1a4ff irq 9 disabled compat allwinner,sun50i-a64-ohci (no driver attached)
> ehci0: <Allwinner Integrated USB 2.0 controller> mem 0x1c1b000-0x1c1b0ff irq 10 on simplebus0
> usbus0: EHCI version 1.0
> usbus0 on ehci0
> ehci0: usbpf: Attached
> random: harvesting attach, 8 bytes (4 bits) from usbus0
> random: harvesting attach, 8 bytes (4 bits) from ehci0
> ohci0: <Generic OHCI Controller> mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0
> usbus1 on ohci0
> ohci0: usbpf: Attached
> random: harvesting attach, 8 bytes (4 bits) from usbus1
> random: harvesting attach, 8 bytes (4 bits) from ohci0
> gpioc0: <GPIO controller> on gpio0
> random: harvesting attach, 8 bytes (4 bits) from gpioc0
> simplebus0: <pwm@01c21400> mem 0x1c21400-0x1c21407 disabled compat allwinner,sun50i-a64-pwm (no driver attached)
> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0
> uart0: console (115384,n,8,1)
> uart0: fast interrupt
> uart0: PPS capture mode: DCD
> random: harvesting attach, 8 bytes (4 bits) from uart0
> simplebus0: <serial@1c28400> mem 0x1c28400-0x1c287ff irq 16 disabled compat snps,dw-apb-uart (no driver attached)
> simplebus0: <serial@1c28800> mem 0x1c28800-0x1c28bff irq 17 disabled compat snps,dw-apb-uart (no driver attached)
> simplebus0: <serial@1c28c00> mem 0x1c28c00-0x1c28fff irq 18 disabled compat snps,dw-apb-uart (no driver attached)
> simplebus0: <serial@1c29000> mem 0x1c29000-0x1c293ff irq 19 disabled compat snps,dw-apb-uart (no driver attached)
> simplebus0: <i2c@1c2ac00> mem 0x1c2ac00-0x1c2afff irq 20 disabled compat allwinner,sun6i-a31-i2c (no driver attached)
> iic0: <I2C generic I/O> on iicbus0
> random: harvesting attach, 8 bytes (4 bits) from iic0
> simplebus0: <i2c@1c2b400> mem 0x1c2b400-0x1c2b7ff irq 22 disabled compat allwinner,sun6i-a31-i2c (no driver attached)
> gpioc1: <GPIO controller> on gpio1
> random: harvesting attach, 8 bytes (4 bits) from gpioc1
> syscon_generic0: <syscon> mem 0x1c00000-0x1c00fff on simplebus0
> random: harvesting attach, 8 bytes (4 bits) from syscon_generic0
> awg0: <Allwinner Gigabit Ethernet> mem 0x1c30000-0x1c3ffff irq 27 on simplebus0
> simplebus0: no default resources for rid = 1, type = 3
> awg0: PHY type: rgmii, conf mode: reg
> awg0: EMAC clock: 0x00000006
> awg0: AHB frequency 150000000 Hz, MDC div: 0x2
> miibus0: <MII bus> on awg0
> rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0
> rgephy0: OUI 0x00e04c, model 0x0011, rev. 5
> rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
> random: harvesting attach, 8 bytes (4 bits) from rgephy0
> rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
> rgephy1: OUI 0x00e04c, model 0x0011, rev. 5
> rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
> random: harvesting attach, 8 bytes (4 bits) from rgephy1
> random: harvesting attach, 8 bytes (4 bits) from miibus0
> awg0: bpf attached
> awg0: Ethernet address: 02:ba:b1:c5:93:b7
> random: harvesting attach, 8 bytes (4 bits) from awg0
> cryptosoft0: <software crypto>
> crypto: assign cryptosoft0 driver id 0, flags 0x6000000
> crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0
> crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0
> random: harvesting attach, 8 bytes (4 bits) from cryptosoft0
> Found SMCCC version 1.0
> Device configuration finished.
> procfs registered
> Timecounters tick every 1.000 msec
> vlan: initialized, using hash tables with chaining
> lo0: bpf attached
> arc4random: read 32 bytes from preloaded cache
> arc4random: read 32 bytes from preloaded cache
> arc4random: read 32 bytes from preloaded cache
> tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384
> IPsec: Initialized Security Association Processing.
> usbus0: 480Mbps High Speed USB v2.0
> usbus1: 12Mbps Full Speed USB v1.0
> aw_mmc0: Powering up sd/mmc
> mmc0: Probing bus
> ugen0.1: <Allwinner EHCI root HUB> at usbus0
> uhub0: <Allwinner EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
> ugen1.1: <Generic OHCI root HUB> at usbus1
> uhub1: <Generic OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> mmc0: SD probe: failed
> mmc0: MMC probe: OK (OCR: 0x40ff8080)
> mmc0: Current OCR: 0x00ff8080
> mmc0: Probing cards
> mmc0: New card detected (CID 150100444a4e423452079f43b2e7636f)
> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d)
> aw_mmc0: error rint: 0x00008010
> AW_MMC_INT_DATA_END_BIT_ERR
> mmc0: Card at relative address 0x0002 added:
> mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
> mmc0:  quirks: 0
> mmc0:  bus: 4bit, 200MHz (HS200 timing)
> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> aw_mmc0: error rint: 0x00000100
> AW_MMC_INT_RESP_TIMEOUT
> mmc0: setting transfer rate to 52.000MHz (dual data rate timing)
> mmc0: Failed to set VCCQ for card at relative address 2

 So the driver is selecting DDR52 transfer rate but, of course,
cannot switch the IO voltage to 1.8V as on this board the IO voltage
for the SD card is tied to 3.3V

> uhub1: 1 port with 1 removable, self powered
> random: harvesting attach, 8 bytes (4 bits) from uhub1
> uhub0: 1 port with 1 removable, self powered
> random: harvesting attach, 8 bytes (4 bits) from uhub0
> aw_mmc0: controller timeout
> aw_mmc0: timeout updating clock
> aw_mmc0: controller timeout
> aw_mmc0: timeout updating clock
> aw_mmc0: controller timeout
> aw_mmc0: timeout updating clock
> aw_mmc0: controller timeout
> aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000
>
> mmcsd0: Error reading EXT_CSD Timeout

 This seems weird, I have a board with an eMMC IO voltage tied to 3.3V
(Olinuxino-A64), I'll try HEAD on this board.

> device_attach: mmcsd0 attach returned 6
> Release APs...done
> Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]...
> CPU  0: ARM Cortex-A53 r0p4mountroot: waiting for device /dev/ufs/PINE64P2Grootfs...
>  affinity:  0
>  Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
>  Instruction Set Attributes 1 = <>
>          Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
>          Processor Features 1 = <0>
>       Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
>       Memory Model Features 1 = <>
>       Memory Model Features 2 = <32b CCIDX,48b VA>
>              Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
>              Debug Features 1 = <0>
>          Auxiliary Features 0 = <0>
>          Auxiliary Features 1 = <0>
> CPU  1: ARM Cortex-A53 r0p4 affinity:  1
> CPU  2: ARM Cortex-A53 r0p4 affinity:  2
> CPU  3: ARM Cortex-A53 r0p4 affinity:  3
> regulator: shutting down vcc3v3
> Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19.
>
> Loader variables:
>   vfs.root.mountfrom=ufs:/dev/ufs/PINE64P2Grootfs
>   vfs.root.mountfrom.options=rw,noatime
>
> Manual root filesystem specification:
>   <fstype>:<device> [options]
>       Mount <device> using filesystem <fstype>
>       and with the specified (optional) option list.
>
>     eg. ufs:/dev/da0s1a
>         zfs:tank
>         cd9660:/dev/cd0 ro
>           (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>
>   ?               List valid disk boot devices
>   .               Yield 1 second (for background tasks)
>   <empty line>    Abort manual input
>
> mountroot>
>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)


--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:

> On Mon, 6 Aug 2018 10:12:43 -0700
> Mark Millard <[hidden email]> wrote:
>
>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>
>>> On Mon, 6 Aug 2018 02:48:57 -0700
>>> Mark Millard via freebsd-arm <[hidden email]> wrote:
>>>
>>>> I amd64 -> aarch64 cross built -r337347 and installed it
>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
>>>> bootaa64.efi) as an update. My attempted synchronization
>>>> of loader.conf and ttys and devd.conf may be incorrect.
>>>> (Previous to this the Pine64+ 2GB seemed to be working
>>>> okay but it was at a very old build.)
>>>>
>>>> The kernel config has GENERIC included but the various
>>>> debug features disabled. (My typical operating
>>>> environment.)
>>>>
>>>> For all I know what the below shows might be expected
>>>> at this point. The kernel seems to have problems with
>>>> the MMC (that the kernel was loaded from). No other
>>>> media are attached. mmcsd0 is really an 128 GiByte
>>>> emmc on an adapter. (This historically worked for me.)
>>>
>>> emmc to sd ? that's weird ...
>>
>> An example of the adapter I've used for this is:
>>
>> https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter
>
> So this is a passive adapter, maybe that's something that should work
> but it's definitly is something that calls for problems.
>
>> emmc is multi-mode for its allowed modes of operation. Thus
>> its ability to frequently be used this way, such as via HS200.
>> emmc is commonly more robust as I understand.
>
> I didn't understand a word.

I got the HS200 reference from the boot -v output. Such is currently from the
JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC
members have free access, others do not.)

The output reported:

mmc0: Card at relative address 0x0002 added:
mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
mmc0:  quirks: 0
mmc0:  bus: 4bit, 200MHz (HS200 timing)
mmc0:  memory: 244277248 blocks, erase sector 1024 blocks

The e.MMC bus speed modes with I/O Voltage 3V allowed are:

Backwards Compatibility with legacy MMC card, data rate single, 3V allowed, bus widths 1,4,8, 0-26 MHz

High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 MHz

High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz

(The last being the fastest for maximum transfer rate with 3V.)

There is another 1.8V/1.2V mode: HS400 that is dual data rate and always 8 bit,
unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. HS400
is optional and sufficiently old e.MMC standard vintages would likely not
even have it.

So a slower 3.? V mode of use used to be selected (based on the constraints
on the board's voltages in some way, possibly hard coded).

>>
>> (I had to modify the case the pine64+ 2GB is in in order for
>> the adapter/emmc combination to fit in all the way.)
>>
>>> Can you boot -v and post the result please ?
>>
>> Glad to . . .
>>
>> DRAM: 2048 MiB
>> Trying to boot from MMC1
>>
>>
>> U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000)
>> DU-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology
>>
>> CPU:   Allwinner A64 (SUN50I)
>> Model: Pine64+
>> DRAM:  2 GiB
>> MMC:   SUNXI SD/MMC: 0
>> Loading Environment from FAT... *** Warning - bad CRC, using default environment
>>
>> Failed (-5)
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Net:   phy interface7
>> eth0: ethernet@1c30000
>> starting USB...
>> USB0:   USB EHCI 1.00
>> USB1:   USB OHCI 1.0
>> scanning bus 0 for devices... 1 USB Device(s) found
>>       scanning usb for storage devices... 0 Storage Device(s) found
>> Hit any key to stop autoboot:  0
>> switch to partitions #0, OK
>> mmc0(part 0) is current device
>> Scanning mmc 0:1...
>> Found EFI removable media binary efi/boot/bootaa64.efi
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> 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
>> 477384 bytes read in 25 ms (18.2 MiB/s)
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> ## Starting EFI application at 40080000 ...
>> Consoles: EFI console  
>> FreeBSD/arm64 EFI loader, Revision 1.1
>>
>>   Command line arguments: loader.efi
>>   EFI version: 2.70
>>   EFI Firmware: Das U-Boot (rev 0.00)
>>   Console: efi (0)
>>   Load Path: /\efi\boot\bootaa64.efi
>>   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
>> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
>> Setting currdev to disk0p1:
>> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24400,0xe600000)
>> Setting currdev to disk0p2:
>> Loading /boot/defaults/loader.conf
>> /boot/kernel/kernel text=0x8ce84a data=0x148020+0x72caac syms=[0x8+0x11d000+0x8+0x1108a8]
>> /boot/entropy size=0x1000
>> /boot/kernel/umodem.ko text=0x2168 text=0x1410 data=0x102d0+0xfd40 syms=[0x8+0xf30+0x8+0xb73]
>>
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>> Booting [/boot/kernel/kernel] in 9 seconds...
>>
>> Type '?' for a list of commands, 'help' for more detailed help.
>> OK boot -v
>> Booting...
>> Using DTB provided by EFI at 0x47ffc000.
>> EHCI failed to shut down host controller.
>> KDB: debugger backends: ddb
>> KDB: current backend: ddb
>>                   Type     Physical      Virtual   #Pages Attr
>>     ConventionalMemory 000040000000     40000000 00007ffc WB
>>               Reserved 000047ffc000     47ffc000 00000003 WB
>>    RuntimeServicesData 000047fff000     47fff000 00000001 WB RUNTIME
>>               Reserved 000048000000     48000000 00000003 WB
>>    RuntimeServicesData 000048003000     48003000 00000001 WB RUNTIME
>>     ConventionalMemory 000048005000     40000000 00068ea1 WB
>>             LoaderData 0000b0ea6000     b0ea6000 00000001 WB
>>               Reserved 0000b0ea7000     b0ea7000 00000001 WB
>>               Reserved 0000b0ea8000     b0ea8000 00000001 WB
>>             LoaderData 0000b0ea9000     b0ea9000 00004000 WB
>>             LoaderData 0000b4ea9000     b4ea9000 00004000 WB
>>             LoaderCode 0000b8ea9000     b8ea9000 00000075 WB
>>               Reserved 0000b8f1e000     b8f1e000 00000001 WB
>>               Reserved 0000b8f1f000     b8f1f000 00000001 WB
>>    RuntimeServicesData 0000b8f20000     b8f20000 00000001 WB RUNTIME
>>               Reserved 0000b8f21000     b8f21000 00000001 WB
>>               Reserved 0000b8f22000     b8f22000 00000001 WB
>>               Reserved 0000b8f23000     b8f23000 00000001 WB
>>               Reserved 0000b8f24000     b8f24000 00000001 WB
>>             LoaderData 0000b8f25000     b8f25000 00005094 WB
>>    RuntimeServicesCode 0000bdfb9000     bdfb9000 00000002 WB RUNTIME
>>             LoaderData 0000bdfbb000     b8f25000 00002045 WB
>> Physical memory chunk(s):
>>  0x40000000 - 0x47ffbfff,   127 MB (  32764 pages)
>>  0x47fff000 - 0x47ffffff,     0 MB (      1 pages)
>>  0x48003000 - 0x48003fff,     0 MB (      1 pages)
>>  0x48005000 - 0xb0ea6fff,  1678 MB ( 429730 pages)
>>  0xb0ea9000 - 0xb8f1dfff,   128 MB (  32885 pages)
>>  0xb8f20000 - 0xb8f20fff,     0 MB (      1 pages)
>>  0xb8f25000 - 0xbdfb8fff,    80 MB (  20628 pages)
>>  0xbdfbb000 - 0xbfffffff,    32 MB (   8261 pages)
>> Excluded memory regions:
>>  0x47ffc000 - 0x48003fff,     0 MB (      8 pages) NoAlloc
>>  0xb0ea7000 - 0xb0ea8fff,     0 MB (      2 pages) NoAlloc
>>  0xb1000000 - 0xb25e1fff,    21 MB (   5602 pages) NoAlloc
>>  0xb8f1e000 - 0xb8f24fff,     0 MB (      7 pages) NoAlloc
>>  0xbdfb9000 - 0xbdfbafff,     0 MB (      2 pages) NoAlloc
>> Found 4 CPUs in the device tree
>> Copyright (c) 1992-2018 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>        The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 12.0-CURRENT  r337347M arm64
>> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
>> VT: init without driver.
>> Preloaded elf kernel "/boot/kernel/kernel" at 0xffff0000013b9000.
>> Preloaded boot_entropy_cache "/boot/entropy" at 0xffff0000013c2020.
>> Preloaded elf module "/boot/kernel/umodem.ko" at 0xffff0000013c2078.
>> KLD file umodem.ko is missing dependencies
>> Starting CPU 1 (1)
>> Starting CPU 2 (2)
>> Starting CPU 3 (3)
>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>> random: read 3840 bytes from preloaded cache
>> random: unblocking device.
>> arc4random: read 32 bytes from preloaded cache
>> VIMAGE (virtualized network stack) enabled
>> ULE: setup cpu 0
>> ULE: setup cpu 1
>> ULE: setup cpu 2
>> ULE: setup cpu 3
>> random: entropy device external interface
>> MAP 47fff000 mode 2 pages 1
>> MAP 48003000 mode 2 pages 1
>> MAP b8f20000 mode 2 pages 1
>> MAP bdfb9000 mode 2 pages 2
>> nfslock: pseudo-device
>> crypto: <crypto core>
>> kbd0 at kbdmux0
>> mem: <memory>
>> null: <full device, null device, zero device>
>> openfirm: <Open Firmware control device>
>> random: harvesting attach, 8 bytes (4 bits) from nexus0
>> ofwbus0: <Open Firmware Device Tree>
>> clk_fixed0: <Fixed clock> on ofwbus0
>> random: harvesting attach, 8 bytes (4 bits) from clk_fixed0
>> clk_fixed1: <Fixed clock> on ofwbus0
>> random: harvesting attach, 8 bytes (4 bits) from clk_fixed1
>> clk_fixed2: <Fixed clock> on ofwbus0
>> random: harvesting attach, 8 bytes (4 bits) from clk_fixed2
>> simplebus0: <Flattened device tree simple bus> on ofwbus0
>> ccu_a64ng0: <Allwinner A64 Clock Control Unit NG> mem 0x1c20000-0x1c203ff on simplebus0
>> ccu_a64ng0: Setting pll_periph0 as parent for ahb1
>> ccu_a64ng0: Setting pll_periph0 as parent for ahb2
>> ccu_a64ng0: Setting pll_ddr0 as parent for dram
>> Clock: pll_cpux, parent: osc24M(0), freq: 816000000
>> Clock: pll_audio, parent: osc24M(0), freq: 24571428
>> Clock: pll_periph0_2x, parent: osc24M(0), freq: 600000000
>> Clock: pll_periph1_2x, parent: osc24M(0), freq: 600000000
>> Clock: pll_ddr0, parent: osc24M(0), freq: 408000000
>> Clock: pll_ddr1, parent: osc24M(0), freq: 1344000000
>> Clock: pll_video0, parent: osc24M(0), freq: 30303
>> Clock: pll_video1, parent: osc24M(0), freq: 30303
>> Clock: pll_ve, parent: osc24M(0), freq: 30303
>> Clock: pll_gpu, parent: osc24M(0), freq: 30303
>> Clock: pll_de, parent: osc24M(0), freq: 30303
>> Clock: pll_hsic, parent: osc24M(0), freq: 1200000
>> Clock: apb2, parent: osc24M(1), freq: 24000000
>> Clock: nand, parent: osc24M(0), freq: 24000000
>> Clock: mmc0, parent: pll_periph0_2x(1), freq: 50000000
>> Clock: mmc1, parent: osc24M(0), freq: 24000000
>> Clock: mmc2, parent: osc24M(0), freq: 24000000
>> Clock: ts, parent: osc24M(0), freq: 24000000
>> Clock: ce, parent: osc24M(0), freq: 24000000
>> Clock: spi0, parent: osc24M(0), freq: 24000000
>> Clock: spi1, parent: osc24M(0), freq: 24000000
>> Clock: spdif, parent: pll_audio(0), freq: 24571428
>> Clock: dram, parent: pll_ddr0(0), freq: 408000000
>> Clock: de, parent: pll_periph0_2x(0), freq: 600000000
>> Clock: deinterlace, parent: pll_periph0(0), freq: 300000000
>> Clock: csi-sclk, parent: pll_periph0(0), freq: 300000000
>> Clock: csi-mclk, parent: osc24M(0), freq: 24000000
>> Clock: ve, parent: pll_ve(0), freq: 30303
>> Clock: hdmi, parent: pll_video0(0), freq: 30303
>> Clock: mbus, parent: pll_periph0_2x(1), freq: 200000000
>> Clock: gpu, parent: pll_gpu(0), freq: 30303
>> Clock: ahb1, parent: pll_periph0(3), freq: 300000000
>> Clock: ahb2, parent: pll_periph0(1), freq: 150000000
>> Clock: cpux, parent: pll_cpux(2), freq: 816000000
>> Clock: i2s0mux, parent: pll_audio-8x(0), freq: 196571424
>> Clock: i2s1mux, parent: pll_audio-8x(0), freq: 196571424
>> Clock: i2s2mux, parent: pll_audio-8x(0), freq: 196571424
>> Clock: axi, parent: cpux(0), freq: 204000000
>> Clock: apb1, parent: ahb1(0), freq: 75000000
>> Clock: apb, parent: cpux(0), freq: 272000000
>> Clock: thsdiv, parent: osc24M(0), freq: 12000000
>> Clock: osc12M, parent: osc24M(0), freq: 12000000
>> Clock: pll_periph0, parent: pll_periph0_2x(0), freq: 300000000
>> Clock: pll_periph1, parent: pll_periph1_2x(0), freq: 300000000
>> Clock: pll_audio-2x, parent: pll_audio(0), freq: 49142856
>> Clock: pll_audio-4x, parent: pll_audio(0), freq: 98285712
>> Clock: pll_audio-8x, parent: pll_audio(0), freq: 196571424
>> Clock: bus-mipi-dsi, parent: ahb1(0), freq: 300000000
>> Clock: bus-ce, parent: ahb1(0), freq: 300000000
>> Clock: bus-dma, parent: ahb1(0), freq: 300000000
>> Clock: bus-mmc0, parent: ahb1(0), freq: 300000000
>> Clock: bus-mmc1, parent: ahb1(0), freq: 300000000
>> Clock: bus-mmc2, parent: ahb1(0), freq: 300000000
>> Clock: bus-nand, parent: ahb1(0), freq: 300000000
>> Clock: bus-dram, parent: ahb1(0), freq: 300000000
>> Clock: bus-emac, parent: ahb2(0), freq: 150000000
>> Clock: bus-ts, parent: ahb1(0), freq: 300000000
>> Clock: bus-hstimer, parent: ahb1(0), freq: 300000000
>> Clock: bus-spi0, parent: ahb1(0), freq: 300000000
>> Clock: bus-spi1, parent: ahb1(0), freq: 300000000
>> Clock: bus-otg, parent: ahb1(0), freq: 300000000
>> Clock: bus-ehci0, parent: ahb1(0), freq: 300000000
>> Clock: bus-ehci1, parent: ahb2(0), freq: 150000000
>> Clock: bus-ohci0, parent: ahb1(0), freq: 300000000
>> Clock: bus-ohci1, parent: ahb2(0), freq: 150000000
>> Clock: bus-ve, parent: ahb1(0), freq: 300000000
>> Clock: bus-tcon0, parent: ahb1(0), freq: 300000000
>> Clock: bus-tcon1, parent: ahb1(0), freq: 300000000
>> Clock: bus-deinterlace, parent: ahb1(0), freq: 300000000
>> Clock: bus-csi, parent: ahb1(0), freq: 300000000
>> Clock: bus-hdmi, parent: ahb1(0), freq: 300000000
>> Clock: bus-de, parent: ahb1(0), freq: 300000000
>> Clock: bus-gpu, parent: ahb1(0), freq: 300000000
>> Clock: bus-msgbox, parent: ahb1(0), freq: 300000000
>> Clock: bus-spinlock, parent: ahb1(0), freq: 300000000
>> Clock: bus-codec, parent: apb1(0), freq: 75000000
>> Clock: bus-spdif, parent: apb1(0), freq: 75000000
>> Clock: bus-pio, parent: apb1(0), freq: 75000000
>> Clock: bus-ths, parent: apb1(0), freq: 75000000
>> Clock: bus-i2s0, parent: apb1(0), freq: 75000000
>> Clock: bus-i2s1, parent: apb1(0), freq: 75000000
>> Clock: bus-i2s2, parent: apb1(0), freq: 75000000
>> Clock: bus-i2c0, parent: apb2(0), freq: 24000000
>> Clock: bus-i2c1, parent: apb2(0), freq: 24000000
>> Clock: bus-i2c2, parent: apb2(0), freq: 24000000
>> Clock: bus-src, parent: apb2(0), freq: 24000000
>> Clock: bus-uart0, parent: apb2(0), freq: 24000000
>> Clock: bus-uart1, parent: apb2(0), freq: 24000000
>> Clock: bus-uart2, parent: apb2(0), freq: 24000000
>> Clock: bus-uart3, parent: apb2(0), freq: 24000000
>> Clock: bus-uart4, parent: apb2(0), freq: 24000000
>> Clock: bus-dbg, parent: ahb1(0), freq: 300000000
>> Clock: ths, parent: thsdiv(0), freq: 12000000
>> Clock: usb-phy0, parent: osc24M(0), freq: 24000000
>> Clock: usb-phy1, parent: osc24M(0), freq: 24000000
>> Clock: usb-hsic, parent: pll_hsic(0), freq: 1200000
>> Clock: usb-hsic-12M, parent: osc12M(0), freq: 12000000
>> Clock: usb-ohci0, parent: osc12M(0), freq: 12000000
>> Clock: usb-ohci1, parent: usb-ohci0(0), freq: 12000000
>> Clock: dram-ve, parent: dram(0), freq: 408000000
>> Clock: dram-csi, parent: dram(0), freq: 408000000
>> Clock: dram-deinterlace, parent: dram(0), freq: 408000000
>> Clock: dram-ts, parent: dram(0), freq: 408000000
>> Clock: csi-misc, parent: osc24M(0), freq: 24000000
>> Clock: ac-dig, parent: pll_audio(0), freq: 24571428
>> Clock: ac-dig-4x, parent: pll_audio-4x(0), freq: 98285712
>> Clock: avs, parent: osc24M(0), freq: 24000000
>> Clock: hdmi-ddc, parent: osc24M(0), freq: 24000000
>> random: harvesting attach, 8 bytes (4 bits) from ccu_a64ng0
>> iichb0: <Allwinner Integrated I2C Bus Controller> mem 0x1c2b000-0x1c2b3ff irq 21 on simplebus0
>> iicbus0: <OFW I2C bus> on iichb0
>> random: harvesting attach, 8 bytes (4 bits) from iicbus0
>> random: harvesting attach, 8 bytes (4 bits) from iichb0
>> random: harvesting attach, 8 bytes (4 bits) from simplebus0
>> regfix0: <Fixed Regulator> on ofwbus0
>> random: harvesting attach, 8 bytes (4 bits) from regfix0
>> random: harvesting attach, 8 bytes (4 bits) from ofwbus0
>> ccu_sun8i_r0: <Allwinner SUN8I_R Clock Control Unit NG> mem 0x1f01400-0x1f014ff on simplebus0
>> Clock: ar100, parent: osc32k(0), freq: 32768
>> Clock: apb0, parent: ahb0(0), freq: 32768
>> Clock: ahb0, parent: ar100(0), freq: 32768
>> Clock: ir, parent: osc32k(0), freq: 32768
>> Clock: apb0-pio, parent: apb0(0), freq: 32768
>> Clock: apb0-ir, parent: apb0(0), freq: 32768
>> Clock: apb0-timer, parent: apb0(0), freq: 32768
>> Clock: apb0-rsb, parent: apb0(0), freq: 32768
>> Clock: apb0-uart, parent: apb0(0), freq: 32768
>> Clock: apb0-i2c, parent: apb0(0), freq: 32768
>> Clock: apb0-twd, parent: apb0(0), freq: 32768
>> random: harvesting attach, 8 bytes (4 bits) from ccu_sun8i_r0
>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>> psci0: PSCI version 0.2 compatible
>> random: harvesting attach, 8 bytes (4 bits) from psci0
>> gic0: <ARM Generic Interrupt Controller> mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224
>> random: harvesting attach, 8 bytes (4 bits) from gic0
>> gpio0: <Allwinner GPIO/Pinmux controller> mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0
>> gpiobus0: <OFW GPIO bus> on gpio0
>> random: harvesting attach, 8 bytes (4 bits) from gpiobus0
>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
>> random: harvesting attach, 8 bytes (4 bits) from gpio0
>> gpio1: <Allwinner GPIO/Pinmux controller> mem 0x1f02c00-0x1f02fff irq 26 on simplebus0
>> gpiobus1: <OFW GPIO bus> on gpio1
>> random: harvesting attach, 8 bytes (4 bits) from gpiobus1
>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
>> random: harvesting attach, 8 bytes (4 bits) from gpio1
>> generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
>> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
>> random: harvesting attach, 8 bytes (4 bits) from generic_timer0
>> rtc0: <Allwinner RTC> mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0
>> rtc0: Using external oscillator
>> rtc0: registered as a time-of-day clock, resolution 1.000000s
>> random: harvesting attach, 8 bytes (4 bits) from rtc0
>> awusbphy0: <Allwinner USB PHY> mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0
>> random: harvesting attach, 8 bytes (4 bits) from awusbphy0
>> efirtc0: cannot read EFI realtime clock
>> cpulist0: <Open Firmware CPU Group> on ofwbus0
>> cpu0: <Open Firmware CPU> on cpulist0
>> cpu0: missing 'clock-frequency' property
>> arm64_cpu0: register <0>
>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu0
>> random: harvesting attach, 8 bytes (4 bits) from cpu0
>> cpu1: <Open Firmware CPU> on cpulist0
>> cpu1: missing 'clock-frequency' property
>> arm64_cpu1: register <1>
>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu1
>> random: harvesting attach, 8 bytes (4 bits) from cpu1
>> cpu2: <Open Firmware CPU> on cpulist0
>> cpu2: missing 'clock-frequency' property
>> arm64_cpu2: register <2>
>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu2
>> random: harvesting attach, 8 bytes (4 bits) from cpu2
>> cpu3: <Open Firmware CPU> on cpulist0
>> cpu3: missing 'clock-frequency' property
>> arm64_cpu3: register <3>
>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu3
>> random: harvesting attach, 8 bytes (4 bits) from cpu3
>> random: harvesting attach, 8 bytes (4 bits) from cpulist0
>> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
>> aw_mmc0: vmmc-supply regulator found
>> mmc0: <MMC/SD bus> on aw_mmc0
>> random: harvesting attach, 8 bytes (4 bits) from mmc0
>> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
>> simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
>> simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached)
>> simplebus0: <usb@01c19000> mem 0x1c19000-0x1c193ff irq 7 compat allwinner,sun8i-a33-musb (no driver attached)
>> simplebus0: <usb@01c1a000> mem 0x1c1a000-0x1c1a0ff irq 8 disabled compat allwinner,sun50i-a64-ehci (no driver attached)
>> simplebus0: <usb@01c1a400> mem 0x1c1a400-0x1c1a4ff irq 9 disabled compat allwinner,sun50i-a64-ohci (no driver attached)
>> ehci0: <Allwinner Integrated USB 2.0 controller> mem 0x1c1b000-0x1c1b0ff irq 10 on simplebus0
>> usbus0: EHCI version 1.0
>> usbus0 on ehci0
>> ehci0: usbpf: Attached
>> random: harvesting attach, 8 bytes (4 bits) from usbus0
>> random: harvesting attach, 8 bytes (4 bits) from ehci0
>> ohci0: <Generic OHCI Controller> mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0
>> usbus1 on ohci0
>> ohci0: usbpf: Attached
>> random: harvesting attach, 8 bytes (4 bits) from usbus1
>> random: harvesting attach, 8 bytes (4 bits) from ohci0
>> gpioc0: <GPIO controller> on gpio0
>> random: harvesting attach, 8 bytes (4 bits) from gpioc0
>> simplebus0: <pwm@01c21400> mem 0x1c21400-0x1c21407 disabled compat allwinner,sun50i-a64-pwm (no driver attached)
>> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0
>> uart0: console (115384,n,8,1)
>> uart0: fast interrupt
>> uart0: PPS capture mode: DCD
>> random: harvesting attach, 8 bytes (4 bits) from uart0
>> simplebus0: <serial@1c28400> mem 0x1c28400-0x1c287ff irq 16 disabled compat snps,dw-apb-uart (no driver attached)
>> simplebus0: <serial@1c28800> mem 0x1c28800-0x1c28bff irq 17 disabled compat snps,dw-apb-uart (no driver attached)
>> simplebus0: <serial@1c28c00> mem 0x1c28c00-0x1c28fff irq 18 disabled compat snps,dw-apb-uart (no driver attached)
>> simplebus0: <serial@1c29000> mem 0x1c29000-0x1c293ff irq 19 disabled compat snps,dw-apb-uart (no driver attached)
>> simplebus0: <i2c@1c2ac00> mem 0x1c2ac00-0x1c2afff irq 20 disabled compat allwinner,sun6i-a31-i2c (no driver attached)
>> iic0: <I2C generic I/O> on iicbus0
>> random: harvesting attach, 8 bytes (4 bits) from iic0
>> simplebus0: <i2c@1c2b400> mem 0x1c2b400-0x1c2b7ff irq 22 disabled compat allwinner,sun6i-a31-i2c (no driver attached)
>> gpioc1: <GPIO controller> on gpio1
>> random: harvesting attach, 8 bytes (4 bits) from gpioc1
>> syscon_generic0: <syscon> mem 0x1c00000-0x1c00fff on simplebus0
>> random: harvesting attach, 8 bytes (4 bits) from syscon_generic0
>> awg0: <Allwinner Gigabit Ethernet> mem 0x1c30000-0x1c3ffff irq 27 on simplebus0
>> simplebus0: no default resources for rid = 1, type = 3
>> awg0: PHY type: rgmii, conf mode: reg
>> awg0: EMAC clock: 0x00000006
>> awg0: AHB frequency 150000000 Hz, MDC div: 0x2
>> miibus0: <MII bus> on awg0
>> rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0
>> rgephy0: OUI 0x00e04c, model 0x0011, rev. 5
>> rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
>> random: harvesting attach, 8 bytes (4 bits) from rgephy0
>> rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
>> rgephy1: OUI 0x00e04c, model 0x0011, rev. 5
>> rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
>> random: harvesting attach, 8 bytes (4 bits) from rgephy1
>> random: harvesting attach, 8 bytes (4 bits) from miibus0
>> awg0: bpf attached
>> awg0: Ethernet address: 02:ba:b1:c5:93:b7
>> random: harvesting attach, 8 bytes (4 bits) from awg0
>> cryptosoft0: <software crypto>
>> crypto: assign cryptosoft0 driver id 0, flags 0x6000000
>> crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0
>> crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0
>> random: harvesting attach, 8 bytes (4 bits) from cryptosoft0
>> Found SMCCC version 1.0
>> Device configuration finished.
>> procfs registered
>> Timecounters tick every 1.000 msec
>> vlan: initialized, using hash tables with chaining
>> lo0: bpf attached
>> arc4random: read 32 bytes from preloaded cache
>> arc4random: read 32 bytes from preloaded cache
>> arc4random: read 32 bytes from preloaded cache
>> tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384
>> IPsec: Initialized Security Association Processing.
>> usbus0: 480Mbps High Speed USB v2.0
>> usbus1: 12Mbps Full Speed USB v1.0
>> aw_mmc0: Powering up sd/mmc
>> mmc0: Probing bus
>> ugen0.1: <Allwinner EHCI root HUB> at usbus0
>> uhub0: <Allwinner EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
>> ugen1.1: <Generic OHCI root HUB> at usbus1
>> uhub1: <Generic OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> mmc0: SD probe: failed
>> mmc0: MMC probe: OK (OCR: 0x40ff8080)
>> mmc0: Current OCR: 0x00ff8080
>> mmc0: Probing cards
>> mmc0: New card detected (CID 150100444a4e423452079f43b2e7636f)
>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d)
>> aw_mmc0: error rint: 0x00008010
>> AW_MMC_INT_DATA_END_BIT_ERR
>> mmc0: Card at relative address 0x0002 added:
>> mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
>> mmc0:  quirks: 0
>> mmc0:  bus: 4bit, 200MHz (HS200 timing)

The above is where I got the HS200. (I had to look up the details
for this note.)

>> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> aw_mmc0: error rint: 0x00000100
>> AW_MMC_INT_RESP_TIMEOUT
>> mmc0: setting transfer rate to 52.000MHz (dual data rate timing)
>> mmc0: Failed to set VCCQ for card at relative address 2
>
> So the driver is selecting DDR52 transfer rate but, of course,
> cannot switch the IO voltage to 1.8V as on this board the IO voltage
> for the SD card is tied to 3.3V

As I understand the following is allowed for e.MMC in all/most
vintages of the standard:

High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz

So no need for 1.8 V or 1.2 V for that much.

This is not the HS200 mode that the output references. But the
reference is probably just indicate what the e.MMC itself allows
as the fastest speed, not indicating the limitations of the context
of the connection.

>> uhub1: 1 port with 1 removable, self powered
>> random: harvesting attach, 8 bytes (4 bits) from uhub1
>> uhub0: 1 port with 1 removable, self powered
>> random: harvesting attach, 8 bytes (4 bits) from uhub0
>> aw_mmc0: controller timeout
>> aw_mmc0: timeout updating clock
>> aw_mmc0: controller timeout
>> aw_mmc0: timeout updating clock
>> aw_mmc0: controller timeout
>> aw_mmc0: timeout updating clock
>> aw_mmc0: controller timeout
>> aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000
>>
>> mmcsd0: Error reading EXT_CSD Timeout
>
> This seems weird, I have a board with an eMMC IO voltage tied to 3.3V
> (Olinuxino-A64), I'll try HEAD on this board.
>
>> device_attach: mmcsd0 attach returned 6
>> Release APs...done
>> Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]...
>> CPU  0: ARM Cortex-A53 r0p4mountroot: waiting for device /dev/ufs/PINE64P2Grootfs...
>> affinity:  0
>> Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
>> Instruction Set Attributes 1 = <>
>>         Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
>>         Processor Features 1 = <0>
>>      Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
>>      Memory Model Features 1 = <>
>>      Memory Model Features 2 = <32b CCIDX,48b VA>
>>             Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
>>             Debug Features 1 = <0>
>>         Auxiliary Features 0 = <0>
>>         Auxiliary Features 1 = <0>
>> CPU  1: ARM Cortex-A53 r0p4 affinity:  1
>> CPU  2: ARM Cortex-A53 r0p4 affinity:  2
>> CPU  3: ARM Cortex-A53 r0p4 affinity:  3
>> regulator: shutting down vcc3v3
>> Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19.
>>
>> Loader variables:
>>  vfs.root.mountfrom=ufs:/dev/ufs/PINE64P2Grootfs
>>  vfs.root.mountfrom.options=rw,noatime
>>
>> Manual root filesystem specification:
>>  <fstype>:<device> [options]
>>      Mount <device> using filesystem <fstype>
>>      and with the specified (optional) option list.
>>
>>    eg. ufs:/dev/da0s1a
>>        zfs:tank
>>        cd9660:/dev/cd0 ro
>>          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>>
>>  ?               List valid disk boot devices
>>  .               Yield 1 second (for background tasks)
>>  <empty line>    Abort manual input
>>
>> mountroot>
>>
>

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
[Fixing a confusing "slower" reference . . .]

On 2018-Aug-6, at 11:26 AM, Mark Millard <marklmi at yahoo.com> wrote:

> On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>
>> On Mon, 6 Aug 2018 10:12:43 -0700
>> Mark Millard <[hidden email]> wrote:
>>
>>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>>
>>>> On Mon, 6 Aug 2018 02:48:57 -0700
>>>> Mark Millard via freebsd-arm <[hidden email]> wrote:
>>>>
>>>>> I amd64 -> aarch64 cross built -r337347 and installed it
>>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
>>>>> bootaa64.efi) as an update. My attempted synchronization
>>>>> of loader.conf and ttys and devd.conf may be incorrect.
>>>>> (Previous to this the Pine64+ 2GB seemed to be working
>>>>> okay but it was at a very old build.)
>>>>>
>>>>> The kernel config has GENERIC included but the various
>>>>> debug features disabled. (My typical operating
>>>>> environment.)
>>>>>
>>>>> For all I know what the below shows might be expected
>>>>> at this point. The kernel seems to have problems with
>>>>> the MMC (that the kernel was loaded from). No other
>>>>> media are attached. mmcsd0 is really an 128 GiByte
>>>>> emmc on an adapter. (This historically worked for me.)
>>>>
>>>> emmc to sd ? that's weird ...
>>>
>>> An example of the adapter I've used for this is:
>>>
>>> https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter
>>
>> So this is a passive adapter, maybe that's something that should work
>> but it's definitly is something that calls for problems.
>>
>>> emmc is multi-mode for its allowed modes of operation. Thus
>>> its ability to frequently be used this way, such as via HS200.
>>> emmc is commonly more robust as I understand.
>>
>> I didn't understand a word.
>
> I got the HS200 reference from the boot -v output. Such is currently from the
> JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC
> members have free access, others do not.)
>
> The output reported:
>
> mmc0: Card at relative address 0x0002 added:
> mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
> mmc0:  quirks: 0
> mmc0:  bus: 4bit, 200MHz (HS200 timing)
> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
>
> The e.MMC bus speed modes with I/O Voltage 3V allowed are:
>
> Backwards Compatibility with legacy MMC card, data rate single, 3V allowed, bus widths 1,4,8, 0-26 MHz
>
> High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 MHz
>
> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz
>
> (The last being the fastest for maximum transfer rate with 3V.)
>
> There is another 1.8V/1.2V mode: HS400 that is dual data rate and always 8 bit,
> unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. HS400
> is optional and sufficiently old e.MMC standard vintages would likely not
> even have it.
>
> So a slower 3.? V mode of use used to be selected (based on the constraints
> on the board's voltages in some way, possibly hard coded).

"slower" lacks context: I should have said . . .

"a slower than HS200 3.? V mode"

As I remember, the 3V range is from 2.7 V to 3.6 V or some such.
So 3.3 V would be in range, at least if I remember right.

>>>
>>> (I had to modify the case the pine64+ 2GB is in in order for
>>> the adapter/emmc combination to fit in all the way.)
>>>
>>>> Can you boot -v and post the result please ?
>>>
>>> Glad to . . .
>>>
>>> DRAM: 2048 MiB
>>> Trying to boot from MMC1
>>>
>>>
>>> U-Boot SPL 2018.07 (Aug 02 2018 - 18:42:28 +0000)
>>> DU-Boot 2018.07 (Aug 02 2018 - 18:42:28 +0000) Allwinner Technology
>>>
>>> CPU:   Allwinner A64 (SUN50I)
>>> Model: Pine64+
>>> DRAM:  2 GiB
>>> MMC:   SUNXI SD/MMC: 0
>>> Loading Environment from FAT... *** Warning - bad CRC, using default environment
>>>
>>> Failed (-5)
>>> In:    serial
>>> Out:   serial
>>> Err:   serial
>>> Net:   phy interface7
>>> eth0: ethernet@1c30000
>>> starting USB...
>>> USB0:   USB EHCI 1.00
>>> USB1:   USB OHCI 1.0
>>> scanning bus 0 for devices... 1 USB Device(s) found
>>>      scanning usb for storage devices... 0 Storage Device(s) found
>>> Hit any key to stop autoboot:  0
>>> switch to partitions #0, OK
>>> mmc0(part 0) is current device
>>> Scanning mmc 0:1...
>>> Found EFI removable media binary efi/boot/bootaa64.efi
>>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>> 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
>>> 477384 bytes read in 25 ms (18.2 MiB/s)
>>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>> ## Starting EFI application at 40080000 ...
>>> Consoles: EFI console  
>>> FreeBSD/arm64 EFI loader, Revision 1.1
>>>
>>>  Command line arguments: loader.efi
>>>  EFI version: 2.70
>>>  EFI Firmware: Das U-Boot (rev 0.00)
>>>  Console: efi (0)
>>>  Load Path: /\efi\boot\bootaa64.efi
>>>  Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
>>> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x403b,0x1ffe0)
>>> Setting currdev to disk0p1:
>>> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(2,0x01,0,0x24400,0xe600000)
>>> Setting currdev to disk0p2:
>>> Loading /boot/defaults/loader.conf
>>> /boot/kernel/kernel text=0x8ce84a data=0x148020+0x72caac syms=[0x8+0x11d000+0x8+0x1108a8]
>>> /boot/entropy size=0x1000
>>> /boot/kernel/umodem.ko text=0x2168 text=0x1410 data=0x102d0+0xfd40 syms=[0x8+0xf30+0x8+0xb73]
>>>
>>> Hit [Enter] to boot immediately, or any other key for command prompt.
>>> Booting [/boot/kernel/kernel] in 9 seconds...
>>>
>>> Type '?' for a list of commands, 'help' for more detailed help.
>>> OK boot -v
>>> Booting...
>>> Using DTB provided by EFI at 0x47ffc000.
>>> EHCI failed to shut down host controller.
>>> KDB: debugger backends: ddb
>>> KDB: current backend: ddb
>>>                  Type     Physical      Virtual   #Pages Attr
>>>    ConventionalMemory 000040000000     40000000 00007ffc WB
>>>              Reserved 000047ffc000     47ffc000 00000003 WB
>>>   RuntimeServicesData 000047fff000     47fff000 00000001 WB RUNTIME
>>>              Reserved 000048000000     48000000 00000003 WB
>>>   RuntimeServicesData 000048003000     48003000 00000001 WB RUNTIME
>>>    ConventionalMemory 000048005000     40000000 00068ea1 WB
>>>            LoaderData 0000b0ea6000     b0ea6000 00000001 WB
>>>              Reserved 0000b0ea7000     b0ea7000 00000001 WB
>>>              Reserved 0000b0ea8000     b0ea8000 00000001 WB
>>>            LoaderData 0000b0ea9000     b0ea9000 00004000 WB
>>>            LoaderData 0000b4ea9000     b4ea9000 00004000 WB
>>>            LoaderCode 0000b8ea9000     b8ea9000 00000075 WB
>>>              Reserved 0000b8f1e000     b8f1e000 00000001 WB
>>>              Reserved 0000b8f1f000     b8f1f000 00000001 WB
>>>   RuntimeServicesData 0000b8f20000     b8f20000 00000001 WB RUNTIME
>>>              Reserved 0000b8f21000     b8f21000 00000001 WB
>>>              Reserved 0000b8f22000     b8f22000 00000001 WB
>>>              Reserved 0000b8f23000     b8f23000 00000001 WB
>>>              Reserved 0000b8f24000     b8f24000 00000001 WB
>>>            LoaderData 0000b8f25000     b8f25000 00005094 WB
>>>   RuntimeServicesCode 0000bdfb9000     bdfb9000 00000002 WB RUNTIME
>>>            LoaderData 0000bdfbb000     b8f25000 00002045 WB
>>> Physical memory chunk(s):
>>> 0x40000000 - 0x47ffbfff,   127 MB (  32764 pages)
>>> 0x47fff000 - 0x47ffffff,     0 MB (      1 pages)
>>> 0x48003000 - 0x48003fff,     0 MB (      1 pages)
>>> 0x48005000 - 0xb0ea6fff,  1678 MB ( 429730 pages)
>>> 0xb0ea9000 - 0xb8f1dfff,   128 MB (  32885 pages)
>>> 0xb8f20000 - 0xb8f20fff,     0 MB (      1 pages)
>>> 0xb8f25000 - 0xbdfb8fff,    80 MB (  20628 pages)
>>> 0xbdfbb000 - 0xbfffffff,    32 MB (   8261 pages)
>>> Excluded memory regions:
>>> 0x47ffc000 - 0x48003fff,     0 MB (      8 pages) NoAlloc
>>> 0xb0ea7000 - 0xb0ea8fff,     0 MB (      2 pages) NoAlloc
>>> 0xb1000000 - 0xb25e1fff,    21 MB (   5602 pages) NoAlloc
>>> 0xb8f1e000 - 0xb8f24fff,     0 MB (      7 pages) NoAlloc
>>> 0xbdfb9000 - 0xbdfbafff,     0 MB (      2 pages) NoAlloc
>>> Found 4 CPUs in the device tree
>>> Copyright (c) 1992-2018 The FreeBSD Project.
>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>>       The Regents of the University of California. All rights reserved.
>>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>>> FreeBSD 12.0-CURRENT  r337347M arm64
>>> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
>>> VT: init without driver.
>>> Preloaded elf kernel "/boot/kernel/kernel" at 0xffff0000013b9000.
>>> Preloaded boot_entropy_cache "/boot/entropy" at 0xffff0000013c2020.
>>> Preloaded elf module "/boot/kernel/umodem.ko" at 0xffff0000013c2078.
>>> KLD file umodem.ko is missing dependencies
>>> Starting CPU 1 (1)
>>> Starting CPU 2 (2)
>>> Starting CPU 3 (3)
>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>>> random: read 3840 bytes from preloaded cache
>>> random: unblocking device.
>>> arc4random: read 32 bytes from preloaded cache
>>> VIMAGE (virtualized network stack) enabled
>>> ULE: setup cpu 0
>>> ULE: setup cpu 1
>>> ULE: setup cpu 2
>>> ULE: setup cpu 3
>>> random: entropy device external interface
>>> MAP 47fff000 mode 2 pages 1
>>> MAP 48003000 mode 2 pages 1
>>> MAP b8f20000 mode 2 pages 1
>>> MAP bdfb9000 mode 2 pages 2
>>> nfslock: pseudo-device
>>> crypto: <crypto core>
>>> kbd0 at kbdmux0
>>> mem: <memory>
>>> null: <full device, null device, zero device>
>>> openfirm: <Open Firmware control device>
>>> random: harvesting attach, 8 bytes (4 bits) from nexus0
>>> ofwbus0: <Open Firmware Device Tree>
>>> clk_fixed0: <Fixed clock> on ofwbus0
>>> random: harvesting attach, 8 bytes (4 bits) from clk_fixed0
>>> clk_fixed1: <Fixed clock> on ofwbus0
>>> random: harvesting attach, 8 bytes (4 bits) from clk_fixed1
>>> clk_fixed2: <Fixed clock> on ofwbus0
>>> random: harvesting attach, 8 bytes (4 bits) from clk_fixed2
>>> simplebus0: <Flattened device tree simple bus> on ofwbus0
>>> ccu_a64ng0: <Allwinner A64 Clock Control Unit NG> mem 0x1c20000-0x1c203ff on simplebus0
>>> ccu_a64ng0: Setting pll_periph0 as parent for ahb1
>>> ccu_a64ng0: Setting pll_periph0 as parent for ahb2
>>> ccu_a64ng0: Setting pll_ddr0 as parent for dram
>>> Clock: pll_cpux, parent: osc24M(0), freq: 816000000
>>> Clock: pll_audio, parent: osc24M(0), freq: 24571428
>>> Clock: pll_periph0_2x, parent: osc24M(0), freq: 600000000
>>> Clock: pll_periph1_2x, parent: osc24M(0), freq: 600000000
>>> Clock: pll_ddr0, parent: osc24M(0), freq: 408000000
>>> Clock: pll_ddr1, parent: osc24M(0), freq: 1344000000
>>> Clock: pll_video0, parent: osc24M(0), freq: 30303
>>> Clock: pll_video1, parent: osc24M(0), freq: 30303
>>> Clock: pll_ve, parent: osc24M(0), freq: 30303
>>> Clock: pll_gpu, parent: osc24M(0), freq: 30303
>>> Clock: pll_de, parent: osc24M(0), freq: 30303
>>> Clock: pll_hsic, parent: osc24M(0), freq: 1200000
>>> Clock: apb2, parent: osc24M(1), freq: 24000000
>>> Clock: nand, parent: osc24M(0), freq: 24000000
>>> Clock: mmc0, parent: pll_periph0_2x(1), freq: 50000000
>>> Clock: mmc1, parent: osc24M(0), freq: 24000000
>>> Clock: mmc2, parent: osc24M(0), freq: 24000000
>>> Clock: ts, parent: osc24M(0), freq: 24000000
>>> Clock: ce, parent: osc24M(0), freq: 24000000
>>> Clock: spi0, parent: osc24M(0), freq: 24000000
>>> Clock: spi1, parent: osc24M(0), freq: 24000000
>>> Clock: spdif, parent: pll_audio(0), freq: 24571428
>>> Clock: dram, parent: pll_ddr0(0), freq: 408000000
>>> Clock: de, parent: pll_periph0_2x(0), freq: 600000000
>>> Clock: deinterlace, parent: pll_periph0(0), freq: 300000000
>>> Clock: csi-sclk, parent: pll_periph0(0), freq: 300000000
>>> Clock: csi-mclk, parent: osc24M(0), freq: 24000000
>>> Clock: ve, parent: pll_ve(0), freq: 30303
>>> Clock: hdmi, parent: pll_video0(0), freq: 30303
>>> Clock: mbus, parent: pll_periph0_2x(1), freq: 200000000
>>> Clock: gpu, parent: pll_gpu(0), freq: 30303
>>> Clock: ahb1, parent: pll_periph0(3), freq: 300000000
>>> Clock: ahb2, parent: pll_periph0(1), freq: 150000000
>>> Clock: cpux, parent: pll_cpux(2), freq: 816000000
>>> Clock: i2s0mux, parent: pll_audio-8x(0), freq: 196571424
>>> Clock: i2s1mux, parent: pll_audio-8x(0), freq: 196571424
>>> Clock: i2s2mux, parent: pll_audio-8x(0), freq: 196571424
>>> Clock: axi, parent: cpux(0), freq: 204000000
>>> Clock: apb1, parent: ahb1(0), freq: 75000000
>>> Clock: apb, parent: cpux(0), freq: 272000000
>>> Clock: thsdiv, parent: osc24M(0), freq: 12000000
>>> Clock: osc12M, parent: osc24M(0), freq: 12000000
>>> Clock: pll_periph0, parent: pll_periph0_2x(0), freq: 300000000
>>> Clock: pll_periph1, parent: pll_periph1_2x(0), freq: 300000000
>>> Clock: pll_audio-2x, parent: pll_audio(0), freq: 49142856
>>> Clock: pll_audio-4x, parent: pll_audio(0), freq: 98285712
>>> Clock: pll_audio-8x, parent: pll_audio(0), freq: 196571424
>>> Clock: bus-mipi-dsi, parent: ahb1(0), freq: 300000000
>>> Clock: bus-ce, parent: ahb1(0), freq: 300000000
>>> Clock: bus-dma, parent: ahb1(0), freq: 300000000
>>> Clock: bus-mmc0, parent: ahb1(0), freq: 300000000
>>> Clock: bus-mmc1, parent: ahb1(0), freq: 300000000
>>> Clock: bus-mmc2, parent: ahb1(0), freq: 300000000
>>> Clock: bus-nand, parent: ahb1(0), freq: 300000000
>>> Clock: bus-dram, parent: ahb1(0), freq: 300000000
>>> Clock: bus-emac, parent: ahb2(0), freq: 150000000
>>> Clock: bus-ts, parent: ahb1(0), freq: 300000000
>>> Clock: bus-hstimer, parent: ahb1(0), freq: 300000000
>>> Clock: bus-spi0, parent: ahb1(0), freq: 300000000
>>> Clock: bus-spi1, parent: ahb1(0), freq: 300000000
>>> Clock: bus-otg, parent: ahb1(0), freq: 300000000
>>> Clock: bus-ehci0, parent: ahb1(0), freq: 300000000
>>> Clock: bus-ehci1, parent: ahb2(0), freq: 150000000
>>> Clock: bus-ohci0, parent: ahb1(0), freq: 300000000
>>> Clock: bus-ohci1, parent: ahb2(0), freq: 150000000
>>> Clock: bus-ve, parent: ahb1(0), freq: 300000000
>>> Clock: bus-tcon0, parent: ahb1(0), freq: 300000000
>>> Clock: bus-tcon1, parent: ahb1(0), freq: 300000000
>>> Clock: bus-deinterlace, parent: ahb1(0), freq: 300000000
>>> Clock: bus-csi, parent: ahb1(0), freq: 300000000
>>> Clock: bus-hdmi, parent: ahb1(0), freq: 300000000
>>> Clock: bus-de, parent: ahb1(0), freq: 300000000
>>> Clock: bus-gpu, parent: ahb1(0), freq: 300000000
>>> Clock: bus-msgbox, parent: ahb1(0), freq: 300000000
>>> Clock: bus-spinlock, parent: ahb1(0), freq: 300000000
>>> Clock: bus-codec, parent: apb1(0), freq: 75000000
>>> Clock: bus-spdif, parent: apb1(0), freq: 75000000
>>> Clock: bus-pio, parent: apb1(0), freq: 75000000
>>> Clock: bus-ths, parent: apb1(0), freq: 75000000
>>> Clock: bus-i2s0, parent: apb1(0), freq: 75000000
>>> Clock: bus-i2s1, parent: apb1(0), freq: 75000000
>>> Clock: bus-i2s2, parent: apb1(0), freq: 75000000
>>> Clock: bus-i2c0, parent: apb2(0), freq: 24000000
>>> Clock: bus-i2c1, parent: apb2(0), freq: 24000000
>>> Clock: bus-i2c2, parent: apb2(0), freq: 24000000
>>> Clock: bus-src, parent: apb2(0), freq: 24000000
>>> Clock: bus-uart0, parent: apb2(0), freq: 24000000
>>> Clock: bus-uart1, parent: apb2(0), freq: 24000000
>>> Clock: bus-uart2, parent: apb2(0), freq: 24000000
>>> Clock: bus-uart3, parent: apb2(0), freq: 24000000
>>> Clock: bus-uart4, parent: apb2(0), freq: 24000000
>>> Clock: bus-dbg, parent: ahb1(0), freq: 300000000
>>> Clock: ths, parent: thsdiv(0), freq: 12000000
>>> Clock: usb-phy0, parent: osc24M(0), freq: 24000000
>>> Clock: usb-phy1, parent: osc24M(0), freq: 24000000
>>> Clock: usb-hsic, parent: pll_hsic(0), freq: 1200000
>>> Clock: usb-hsic-12M, parent: osc12M(0), freq: 12000000
>>> Clock: usb-ohci0, parent: osc12M(0), freq: 12000000
>>> Clock: usb-ohci1, parent: usb-ohci0(0), freq: 12000000
>>> Clock: dram-ve, parent: dram(0), freq: 408000000
>>> Clock: dram-csi, parent: dram(0), freq: 408000000
>>> Clock: dram-deinterlace, parent: dram(0), freq: 408000000
>>> Clock: dram-ts, parent: dram(0), freq: 408000000
>>> Clock: csi-misc, parent: osc24M(0), freq: 24000000
>>> Clock: ac-dig, parent: pll_audio(0), freq: 24571428
>>> Clock: ac-dig-4x, parent: pll_audio-4x(0), freq: 98285712
>>> Clock: avs, parent: osc24M(0), freq: 24000000
>>> Clock: hdmi-ddc, parent: osc24M(0), freq: 24000000
>>> random: harvesting attach, 8 bytes (4 bits) from ccu_a64ng0
>>> iichb0: <Allwinner Integrated I2C Bus Controller> mem 0x1c2b000-0x1c2b3ff irq 21 on simplebus0
>>> iicbus0: <OFW I2C bus> on iichb0
>>> random: harvesting attach, 8 bytes (4 bits) from iicbus0
>>> random: harvesting attach, 8 bytes (4 bits) from iichb0
>>> random: harvesting attach, 8 bytes (4 bits) from simplebus0
>>> regfix0: <Fixed Regulator> on ofwbus0
>>> random: harvesting attach, 8 bytes (4 bits) from regfix0
>>> random: harvesting attach, 8 bytes (4 bits) from ofwbus0
>>> ccu_sun8i_r0: <Allwinner SUN8I_R Clock Control Unit NG> mem 0x1f01400-0x1f014ff on simplebus0
>>> Clock: ar100, parent: osc32k(0), freq: 32768
>>> Clock: apb0, parent: ahb0(0), freq: 32768
>>> Clock: ahb0, parent: ar100(0), freq: 32768
>>> Clock: ir, parent: osc32k(0), freq: 32768
>>> Clock: apb0-pio, parent: apb0(0), freq: 32768
>>> Clock: apb0-ir, parent: apb0(0), freq: 32768
>>> Clock: apb0-timer, parent: apb0(0), freq: 32768
>>> Clock: apb0-rsb, parent: apb0(0), freq: 32768
>>> Clock: apb0-uart, parent: apb0(0), freq: 32768
>>> Clock: apb0-i2c, parent: apb0(0), freq: 32768
>>> Clock: apb0-twd, parent: apb0(0), freq: 32768
>>> random: harvesting attach, 8 bytes (4 bits) from ccu_sun8i_r0
>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>> psci0: PSCI version 0.2 compatible
>>> random: harvesting attach, 8 bytes (4 bits) from psci0
>>> gic0: <ARM Generic Interrupt Controller> mem 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0
>>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224
>>> random: harvesting attach, 8 bytes (4 bits) from gic0
>>> gpio0: <Allwinner GPIO/Pinmux controller> mem 0x1c20800-0x1c20bff irq 12,13,14 on simplebus0
>>> gpiobus0: <OFW GPIO bus> on gpio0
>>> random: harvesting attach, 8 bytes (4 bits) from gpiobus0
>>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
>>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
>>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
>>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
>>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
>>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
>>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
>>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
>>> random: harvesting attach, 8 bytes (4 bits) from gpio0
>>> gpio1: <Allwinner GPIO/Pinmux controller> mem 0x1f02c00-0x1f02fff irq 26 on simplebus0
>>> gpiobus1: <OFW GPIO bus> on gpio1
>>> random: harvesting attach, 8 bytes (4 bits) from gpiobus1
>>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
>>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
>>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
>>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
>>> Processing 1 pin-config node(s) in pinctrl-0 for mmc@1c0f000
>>> Processing 1 pin-config node(s) in pinctrl-0 for serial@1c28000
>>> Processing 1 pin-config node(s) in pinctrl-0 for i2c@1c2b000
>>> Processing 1 pin-config node(s) in pinctrl-0 for ethernet@1c30000
>>> random: harvesting attach, 8 bytes (4 bits) from gpio1
>>> generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on ofwbus0
>>> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
>>> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
>>> random: harvesting attach, 8 bytes (4 bits) from generic_timer0
>>> rtc0: <Allwinner RTC> mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0
>>> rtc0: Using external oscillator
>>> rtc0: registered as a time-of-day clock, resolution 1.000000s
>>> random: harvesting attach, 8 bytes (4 bits) from rtc0
>>> awusbphy0: <Allwinner USB PHY> mem 0x1c19400-0x1c19413,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on simplebus0
>>> random: harvesting attach, 8 bytes (4 bits) from awusbphy0
>>> efirtc0: cannot read EFI realtime clock
>>> cpulist0: <Open Firmware CPU Group> on ofwbus0
>>> cpu0: <Open Firmware CPU> on cpulist0
>>> cpu0: missing 'clock-frequency' property
>>> arm64_cpu0: register <0>
>>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu0
>>> random: harvesting attach, 8 bytes (4 bits) from cpu0
>>> cpu1: <Open Firmware CPU> on cpulist0
>>> cpu1: missing 'clock-frequency' property
>>> arm64_cpu1: register <1>
>>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu1
>>> random: harvesting attach, 8 bytes (4 bits) from cpu1
>>> cpu2: <Open Firmware CPU> on cpulist0
>>> cpu2: missing 'clock-frequency' property
>>> arm64_cpu2: register <2>
>>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu2
>>> random: harvesting attach, 8 bytes (4 bits) from cpu2
>>> cpu3: <Open Firmware CPU> on cpulist0
>>> cpu3: missing 'clock-frequency' property
>>> arm64_cpu3: register <3>
>>> random: harvesting attach, 8 bytes (4 bits) from arm64_cpu3
>>> random: harvesting attach, 8 bytes (4 bits) from cpu3
>>> random: harvesting attach, 8 bytes (4 bits) from cpulist0
>>> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
>>> aw_mmc0: vmmc-supply regulator found
>>> mmc0: <MMC/SD bus> on aw_mmc0
>>> random: harvesting attach, 8 bytes (4 bits) from mmc0
>>> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
>>> simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
>>> simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached)
>>> simplebus0: <usb@01c19000> mem 0x1c19000-0x1c193ff irq 7 compat allwinner,sun8i-a33-musb (no driver attached)
>>> simplebus0: <usb@01c1a000> mem 0x1c1a000-0x1c1a0ff irq 8 disabled compat allwinner,sun50i-a64-ehci (no driver attached)
>>> simplebus0: <usb@01c1a400> mem 0x1c1a400-0x1c1a4ff irq 9 disabled compat allwinner,sun50i-a64-ohci (no driver attached)
>>> ehci0: <Allwinner Integrated USB 2.0 controller> mem 0x1c1b000-0x1c1b0ff irq 10 on simplebus0
>>> usbus0: EHCI version 1.0
>>> usbus0 on ehci0
>>> ehci0: usbpf: Attached
>>> random: harvesting attach, 8 bytes (4 bits) from usbus0
>>> random: harvesting attach, 8 bytes (4 bits) from ehci0
>>> ohci0: <Generic OHCI Controller> mem 0x1c1b400-0x1c1b4ff irq 11 on simplebus0
>>> usbus1 on ohci0
>>> ohci0: usbpf: Attached
>>> random: harvesting attach, 8 bytes (4 bits) from usbus1
>>> random: harvesting attach, 8 bytes (4 bits) from ohci0
>>> gpioc0: <GPIO controller> on gpio0
>>> random: harvesting attach, 8 bytes (4 bits) from gpioc0
>>> simplebus0: <pwm@01c21400> mem 0x1c21400-0x1c21407 disabled compat allwinner,sun50i-a64-pwm (no driver attached)
>>> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 15 on simplebus0
>>> uart0: console (115384,n,8,1)
>>> uart0: fast interrupt
>>> uart0: PPS capture mode: DCD
>>> random: harvesting attach, 8 bytes (4 bits) from uart0
>>> simplebus0: <serial@1c28400> mem 0x1c28400-0x1c287ff irq 16 disabled compat snps,dw-apb-uart (no driver attached)
>>> simplebus0: <serial@1c28800> mem 0x1c28800-0x1c28bff irq 17 disabled compat snps,dw-apb-uart (no driver attached)
>>> simplebus0: <serial@1c28c00> mem 0x1c28c00-0x1c28fff irq 18 disabled compat snps,dw-apb-uart (no driver attached)
>>> simplebus0: <serial@1c29000> mem 0x1c29000-0x1c293ff irq 19 disabled compat snps,dw-apb-uart (no driver attached)
>>> simplebus0: <i2c@1c2ac00> mem 0x1c2ac00-0x1c2afff irq 20 disabled compat allwinner,sun6i-a31-i2c (no driver attached)
>>> iic0: <I2C generic I/O> on iicbus0
>>> random: harvesting attach, 8 bytes (4 bits) from iic0
>>> simplebus0: <i2c@1c2b400> mem 0x1c2b400-0x1c2b7ff irq 22 disabled compat allwinner,sun6i-a31-i2c (no driver attached)
>>> gpioc1: <GPIO controller> on gpio1
>>> random: harvesting attach, 8 bytes (4 bits) from gpioc1
>>> syscon_generic0: <syscon> mem 0x1c00000-0x1c00fff on simplebus0
>>> random: harvesting attach, 8 bytes (4 bits) from syscon_generic0
>>> awg0: <Allwinner Gigabit Ethernet> mem 0x1c30000-0x1c3ffff irq 27 on simplebus0
>>> simplebus0: no default resources for rid = 1, type = 3
>>> awg0: PHY type: rgmii, conf mode: reg
>>> awg0: EMAC clock: 0x00000006
>>> awg0: AHB frequency 150000000 Hz, MDC div: 0x2
>>> miibus0: <MII bus> on awg0
>>> rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0
>>> rgephy0: OUI 0x00e04c, model 0x0011, rev. 5
>>> rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
>>> random: harvesting attach, 8 bytes (4 bits) from rgephy0
>>> rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
>>> rgephy1: OUI 0x00e04c, model 0x0011, rev. 5
>>> rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
>>> random: harvesting attach, 8 bytes (4 bits) from rgephy1
>>> random: harvesting attach, 8 bytes (4 bits) from miibus0
>>> awg0: bpf attached
>>> awg0: Ethernet address: 02:ba:b1:c5:93:b7
>>> random: harvesting attach, 8 bytes (4 bits) from awg0
>>> cryptosoft0: <software crypto>
>>> crypto: assign cryptosoft0 driver id 0, flags 0x6000000
>>> crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0
>>> crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0
>>> random: harvesting attach, 8 bytes (4 bits) from cryptosoft0
>>> Found SMCCC version 1.0
>>> Device configuration finished.
>>> procfs registered
>>> Timecounters tick every 1.000 msec
>>> vlan: initialized, using hash tables with chaining
>>> lo0: bpf attached
>>> arc4random: read 32 bytes from preloaded cache
>>> arc4random: read 32 bytes from preloaded cache
>>> arc4random: read 32 bytes from preloaded cache
>>> tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384
>>> IPsec: Initialized Security Association Processing.
>>> usbus0: 480Mbps High Speed USB v2.0
>>> usbus1: 12Mbps Full Speed USB v1.0
>>> aw_mmc0: Powering up sd/mmc
>>> mmc0: Probing bus
>>> ugen0.1: <Allwinner EHCI root HUB> at usbus0
>>> uhub0: <Allwinner EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
>>> ugen1.1: <Generic OHCI root HUB> at usbus1
>>> uhub1: <Generic OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> mmc0: SD probe: failed
>>> mmc0: MMC probe: OK (OCR: 0x40ff8080)
>>> mmc0: Current OCR: 0x00ff8080
>>> mmc0: Probing cards
>>> mmc0: New card detected (CID 150100444a4e423452079f43b2e7636f)
>>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d)
>>> aw_mmc0: error rint: 0x00008010
>>> AW_MMC_INT_DATA_END_BIT_ERR
>>> mmc0: Card at relative address 0x0002 added:
>>> mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
>>> mmc0:  quirks: 0
>>> mmc0:  bus: 4bit, 200MHz (HS200 timing)
>
> The above is where I got the HS200. (I had to look up the details
> for this note.)
>
>>> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> aw_mmc0: error rint: 0x00000100
>>> AW_MMC_INT_RESP_TIMEOUT
>>> mmc0: setting transfer rate to 52.000MHz (dual data rate timing)
>>> mmc0: Failed to set VCCQ for card at relative address 2
>>
>> So the driver is selecting DDR52 transfer rate but, of course,
>> cannot switch the IO voltage to 1.8V as on this board the IO voltage
>> for the SD card is tied to 3.3V
>
> As I understand the following is allowed for e.MMC in all/most
> vintages of the standard:
>
> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz
>
> So no need for 1.8 V or 1.2 V for that much.
>
> This is not the HS200 mode that the output references. But the
> reference is probably just indicate what the e.MMC itself allows
> as the fastest speed, not indicating the limitations of the context
> of the connection.
>
>>> uhub1: 1 port with 1 removable, self powered
>>> random: harvesting attach, 8 bytes (4 bits) from uhub1
>>> uhub0: 1 port with 1 removable, self powered
>>> random: harvesting attach, 8 bytes (4 bits) from uhub0
>>> aw_mmc0: controller timeout
>>> aw_mmc0: timeout updating clock
>>> aw_mmc0: controller timeout
>>> aw_mmc0: timeout updating clock
>>> aw_mmc0: controller timeout
>>> aw_mmc0: timeout updating clock
>>> aw_mmc0: controller timeout
>>> aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000
>>>
>>> mmcsd0: Error reading EXT_CSD Timeout
>>
>> This seems weird, I have a board with an eMMC IO voltage tied to 3.3V
>> (Olinuxino-A64), I'll try HEAD on this board.
>>
>>> device_attach: mmcsd0 attach returned 6
>>> Release APs...done
>>> Trying to mount root from ufs:/dev/ufs/PINE64P2Grootfs [rw,noatime]...
>>> CPU  0: ARM Cortex-A53 r0p4mountroot: waiting for device /dev/ufs/PINE64P2Grootfs...
>>> affinity:  0
>>> Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
>>> Instruction Set Attributes 1 = <>
>>>        Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
>>>        Processor Features 1 = <0>
>>>     Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
>>>     Memory Model Features 1 = <>
>>>     Memory Model Features 2 = <32b CCIDX,48b VA>
>>>            Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
>>>            Debug Features 1 = <0>
>>>        Auxiliary Features 0 = <0>
>>>        Auxiliary Features 1 = <0>
>>> CPU  1: ARM Cortex-A53 r0p4 affinity:  1
>>> CPU  2: ARM Cortex-A53 r0p4 affinity:  2
>>> CPU  3: ARM Cortex-A53 r0p4 affinity:  3
>>> regulator: shutting down vcc3v3
>>> Mounting from ufs:/dev/ufs/PINE64P2Grootfs failed with error 19.
>>>
>>> Loader variables:
>>> vfs.root.mountfrom=ufs:/dev/ufs/PINE64P2Grootfs
>>> vfs.root.mountfrom.options=rw,noatime
>>>
>>> Manual root filesystem specification:
>>> <fstype>:<device> [options]
>>>     Mount <device> using filesystem <fstype>
>>>     and with the specified (optional) option list.
>>>
>>>   eg. ufs:/dev/da0s1a
>>>       zfs:tank
>>>       cd9660:/dev/cd0 ro
>>>         (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>>>
>>> ?               List valid disk boot devices
>>> .               Yield 1 second (for background tasks)
>>> <empty line>    Abort manual input
>>>
>>> mountroot>
>>>
>

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
[FYI: I duplicated the e.MMC to a microsdhc, made minor
changes, and tested booting: it did.]

On 2018-Aug-6, at 11:39 AM, Mark Millard <marklmi at yahoo.com> wrote:

> [Fixing a confusing "slower" reference . . .]
>
> On 2018-Aug-6, at 11:26 AM, Mark Millard <marklmi at yahoo.com> wrote:
>
>> On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>
>>> On Mon, 6 Aug 2018 10:12:43 -0700
>>> Mark Millard <[hidden email]> wrote:
>>>
>>>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>>>
>>>>> On Mon, 6 Aug 2018 02:48:57 -0700
>>>>> Mark Millard via freebsd-arm <[hidden email]> wrote:
>>>>>
>>>>>> I amd64 -> aarch64 cross built -r337347 and installed it
>>>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
>>>>>> bootaa64.efi) as an update. My attempted synchronization
>>>>>> of loader.conf and ttys and devd.conf may be incorrect.
>>>>>> (Previous to this the Pine64+ 2GB seemed to be working
>>>>>> okay but it was at a very old build.)
>>>>>>
>>>>>> The kernel config has GENERIC included but the various
>>>>>> debug features disabled. (My typical operating
>>>>>> environment.)
>>>>>>
>>>>>> For all I know what the below shows might be expected
>>>>>> at this point. The kernel seems to have problems with
>>>>>> the MMC (that the kernel was loaded from). No other
>>>>>> media are attached. mmcsd0 is really an 128 GiByte
>>>>>> emmc on an adapter. (This historically worked for me.)
>>>>>
>>>>> emmc to sd ? that's weird ...
>>>>
>>>> An example of the adapter I've used for this is:
>>>>
>>>> https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter
>>>
>>> So this is a passive adapter, maybe that's something that should work
>>> but it's definitly is something that calls for problems.
>>>
>>>> emmc is multi-mode for its allowed modes of operation. Thus
>>>> its ability to frequently be used this way, such as via HS200.
>>>> emmc is commonly more robust as I understand.
>>>
>>> I didn't understand a word.
>>
>> I got the HS200 reference from the boot -v output. Such is currently from the
>> JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC
>> members have free access, others do not.)
>>
>> The output reported:
>>
>> mmc0: Card at relative address 0x0002 added:
>> mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
>> mmc0:  quirks: 0
>> mmc0:  bus: 4bit, 200MHz (HS200 timing)
>> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
>>
>> The e.MMC bus speed modes with I/O Voltage 3V allowed are:
>>
>> Backwards Compatibility with legacy MMC card, data rate single, 3V allowed, bus widths 1,4,8, 0-26 MHz
>>
>> High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 MHz
>>
>> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz
>>
>> (The last being the fastest for maximum transfer rate with 3V.)
>>
>> There is another 1.8V/1.2V mode: HS400 that is dual data rate and always 8 bit,
>> unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. HS400
>> is optional and sufficiently old e.MMC standard vintages would likely not
>> even have it.
>>
>> So a slower 3.? V mode of use used to be selected (based on the constraints
>> on the board's voltages in some way, possibly hard coded).
>
> "slower" lacks context: I should have said . . .
>
> "a slower than HS200 3.? V mode"
>
> As I remember, the 3V range is from 2.7 V to 3.6 V or some such.
> So 3.3 V would be in range, at least if I remember right.
>
>>>>
>>>> (I had to modify the case the pine64+ 2GB is in in order for
>>>> the adapter/emmc combination to fit in all the way.)
>>>>
>>

I duplicated the e.MMC partition content to a microsdhc
for each partition (and u-boot but no swap), made minor
changes, and tested booting. It booted, with messages
like:

Trying to boot from MMC1
. . .
MMC:   SUNXI SD/MMC: 0
. . .
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
. . .
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 3 disks
. . .
aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
mmc0: <MMC/SD bus> on aw_mmc0
. . .
mmcsd0: 32GB <SDHC SE32G 8.0 SN 09781303 MFG 07/2017 by 3 SD> at mmc0 50.0MHz/4bit/32768-block
mmc0: ACMD42 failed, RESULT: 4
mmc0: Card at relative address 43690 failed to set bus width



Prior to the last 2 lines above looks normal to me for the
MMC material.

So the only issue seems to be having an e.MCC device and
how it is handled (mode of attempted operation, including
voltage), given the limitations of the Pine64+ 2GB board.

My hope would be for the Pine64+ 2GB with e.MMC on a MicroSD
e.MMC reader to be tried via:

High Speed DDR mode (Data rate dual), 3.3V (so in the range
allowed around 3V), full bus width that can be used (4 in my
current context), 52 MHz or so.

(At least for any vintage of e.MMC recent enough to have that
available. This e.MMC mode has been around since e.MMC 4.4
(2009). I've seen claims that at the host controller level
it is basically the same configuration used for SD DDR50,
with different arguments in CMD6 for configuration.)

But I've no clue if this fits well with the upstream status
of things or not. I've seen claims that, unlike for UHS-II
and UHS-III, Linux has e.MMC speed mode support being "quite
complete" in the more generic parts not specific to each
controller. (Only a quick summary.) So I'm hopeful for
upstream.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
On 2018-Aug-7, at 6:25 PM, Mark Millard <marklmi at yahoo.com> wrote:

> [FYI: I duplicated the e.MMC to a microsdhc, made minor
> changes, and tested booting: it did.]
>
> On 2018-Aug-6, at 11:39 AM, Mark Millard <marklmi at yahoo.com> wrote:
>
>> [Fixing a confusing "slower" reference . . .]
>>
>> On 2018-Aug-6, at 11:26 AM, Mark Millard <marklmi at yahoo.com> wrote:
>>
>>> On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>>
>>>> On Mon, 6 Aug 2018 10:12:43 -0700
>>>> Mark Millard <[hidden email]> wrote:
>>>>
>>>>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>>>>
>>>>>> On Mon, 6 Aug 2018 02:48:57 -0700
>>>>>> Mark Millard via freebsd-arm <[hidden email]> wrote:
>>>>>>
>>>>>>> I amd64 -> aarch64 cross built -r337347 and installed it
>>>>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
>>>>>>> bootaa64.efi) as an update. My attempted synchronization
>>>>>>> of loader.conf and ttys and devd.conf may be incorrect.
>>>>>>> (Previous to this the Pine64+ 2GB seemed to be working
>>>>>>> okay but it was at a very old build.)
>>>>>>>
>>>>>>> The kernel config has GENERIC included but the various
>>>>>>> debug features disabled. (My typical operating
>>>>>>> environment.)
>>>>>>>
>>>>>>> For all I know what the below shows might be expected
>>>>>>> at this point. The kernel seems to have problems with
>>>>>>> the MMC (that the kernel was loaded from). No other
>>>>>>> media are attached. mmcsd0 is really an 128 GiByte
>>>>>>> emmc on an adapter. (This historically worked for me.)
>>>>>>
>>>>>> emmc to sd ? that's weird ...
>>>>>
>>>>> An example of the adapter I've used for this is:
>>>>>
>>>>> https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter
>>>>
>>>> So this is a passive adapter, maybe that's something that should work
>>>> but it's definitly is something that calls for problems.
>>>>
>>>>> emmc is multi-mode for its allowed modes of operation. Thus
>>>>> its ability to frequently be used this way, such as via HS200.
>>>>> emmc is commonly more robust as I understand.
>>>>
>>>> I didn't understand a word.
>>>
>>> I got the HS200 reference from the boot -v output. Such is currently from the
>>> JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC
>>> members have free access, others do not.)
>>>
>>> The output reported:
>>>
>>> mmc0: Card at relative address 0x0002 added:
>>> mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
>>> mmc0:  quirks: 0
>>> mmc0:  bus: 4bit, 200MHz (HS200 timing)
>>> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
>>>
>>> The e.MMC bus speed modes with I/O Voltage 3V allowed are:
>>>
>>> Backwards Compatibility with legacy MMC card, data rate single, 3V allowed, bus widths 1,4,8, 0-26 MHz
>>>
>>> High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 MHz
>>>
>>> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz
>>>
>>> (The last being the fastest for maximum transfer rate with 3V.)
>>>
>>> There is another 1.8V/1.2V mode: HS400 that is dual data rate and always 8 bit,
>>> unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. HS400
>>> is optional and sufficiently old e.MMC standard vintages would likely not
>>> even have it.
>>>
>>> So a slower 3.? V mode of use used to be selected (based on the constraints
>>> on the board's voltages in some way, possibly hard coded).
>>
>> "slower" lacks context: I should have said . . .
>>
>> "a slower than HS200 3.? V mode"
>>
>> As I remember, the 3V range is from 2.7 V to 3.6 V or some such.
>> So 3.3 V would be in range, at least if I remember right.
>>
>>>>>
>>>>> (I had to modify the case the pine64+ 2GB is in in order for
>>>>> the adapter/emmc combination to fit in all the way.)
>>>>>
>>>
>
> I duplicated the e.MMC partition content to a microsdhc
> for each partition (and u-boot but no swap), made minor
> changes, and tested booting. It booted, with messages
> like:
>
> Trying to boot from MMC1
> . . .
> MMC:   SUNXI SD/MMC: 0
> . . .
> mmc0 is current device
> Scanning mmc 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> . . .
> Scanning disks on mmc...
> MMC Device 1 not found
> MMC Device 2 not found
> MMC Device 3 not found
> Found 3 disks
> . . .
> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
> mmc0: <MMC/SD bus> on aw_mmc0
> . . .
> mmcsd0: 32GB <SDHC SE32G 8.0 SN 09781303 MFG 07/2017 by 3 SD> at mmc0 50.0MHz/4bit/32768-block
> mmc0: ACMD42 failed, RESULT: 4
> mmc0: Card at relative address 43690 failed to set bus width
>
>
>
> Prior to the last 2 lines above looks normal to me for the
> MMC material.
>
> So the only issue seems to be having an e.MCC device and
> how it is handled (mode of attempted operation, including
> voltage), given the limitations of the Pine64+ 2GB board.
>
> My hope would be for the Pine64+ 2GB with e.MMC on a MicroSD
> e.MMC reader to be tried via:
>
> High Speed DDR mode (Data rate dual), 3.3V (so in the range
> allowed around 3V), full bus width that can be used (4 in my
> current context), 52 MHz or so.
>
> (At least for any vintage of e.MMC recent enough to have that
> available. This e.MMC mode has been around since e.MMC 4.4
> (2009). I've seen claims that at the host controller level
> it is basically the same configuration used for SD DDR50,
> with different arguments in CMD6 for configuration.)
>
> But I've no clue if this fits well with the upstream status
> of things or not. I've seen claims that, unlike for UHS-II
> and UHS-III, Linux has e.MMC speed mode support being "quite
> complete" in the more generic parts not specific to each
> controller. (Only a quick summary.) So I'm hopeful for
> upstream.

The 3V problem for e.MCC DDR @ 52 MHz looks more
generic than the Pine64's or even aarch64 or even arm
in general. Likely not your issue directly [Emmanuel].

Looking around some more I see that the card-type/device-type
bitfield had as of JESD84-A441 (March 2010) [JESD84-A44 was
apparently withdrawn, not just updated]:

Bits 7:4 reserved (defined in sufficiently more recent vintages)
Bit 3: DDR MMC @ 52 MHz 1.2 V I/O
Bit 2: DDR MMC @ 52 MHz 1.8 V or 3V I/O
Bit 1: SDR @ 52 MHz at rated device voltage(s)
Bit 0: SDR @ 26 MHz at rated device voltage(s)
(more modern has 3-0 being the same)

but the only valid bit patterns with 7:4 being zero
were(/are): 0x01, 0x03, 0x07, 0x0B, and 0x0F.

Note also that an e.MCC device can for DDR @ 52 MHz:

support 1.2 V without supporting 1.8 V/3 V
or:
support 1.8 V/3 V without supporting 1.2 V

(What I was using supports 3V and u-boot through
loading the kernel worked fine.)

Presuming the environment can supply an I/O voltage in the allowed
range around 3V, such as 3.3V being the the range 2.7 V to 3.6 V:
(The environment might not have 1.8V available as an
alternative even though E.MMC devices have 1.8V and 3V paired, for
example the Pine64+ 2GB, from what I'm told, lacks 1.8V.)

Then 0x07 implies DDR @ 52 MHz with 3V I/O is available for use
And  0x0F implies DDR @ 52 MHz with 3V I/O is available for use
(Otherwise DDR @ 52 MHz with 3V I/O is unavailable.)
If the e.MCC supports DDR @ 52 MHz with 1.8 V it also supports
3V --and the other way around.

So the code is odd/incomplete in /usr/src/sys/dev/mmc/bridge.h :

#define MMC_CAP_MMC_DDR52_120   (1 << 11) /* Can do eMMC DDR52 at 1.2 V */
#define MMC_CAP_MMC_DDR52_180   (1 << 12) /* Can do eMMC DDR52 at 1.8 V */
#define MMC_CAP_MMC_DDR52       (MMC_CAP_MMC_DDR52_120 | MMC_CAP_MMC_DDR52_180)

unless MMC_CAP_MMC_DDR52_180 implicitly also covers 3V. If so, the
comment should mention 3V, as might the macro name.

Another possibility is that there should be another macro. Something
like:

#define MMC_CAP_MMC_DDR52_120   (1 << 11) /* Can do eMMC DDR52 at 1.2 V (nominal) */
#define MMC_CAP_MMC_DDR52_180   (1 << 12) /* Can do eMMC DDR52 at 1.8 V (nominal) */
#define MMC_CAP_MMC_DDR52_300   (1 << ??) /* Can do eMMC DDR52 at 3.0 V (nominal) */
#define MMC_CAP_MMC_DDR52       (MMC_CAP_MMC_DDR52_120 | MMC_CAP_MMC_DDR52_180 | MMC_CAP_MMC_DDR52_300)

(I do not claim such is sufficient, just suggestive.)

It looks like this goes back to -r315598 (2017-Mar-19)
when the code as 1st added by marius. I've not found any
representation of the 3V DDR @ 52 MHz case for e.MMC
so far.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

Marius Strobl-2
On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote:

> On 2018-Aug-7, at 6:25 PM, Mark Millard <marklmi at yahoo.com> wrote:
>
> > [FYI: I duplicated the e.MMC to a microsdhc, made minor
> > changes, and tested booting: it did.]
> >
> > On 2018-Aug-6, at 11:39 AM, Mark Millard <marklmi at yahoo.com> wrote:
> >
> >> [Fixing a confusing "slower" reference . . .]
> >>
> >> On 2018-Aug-6, at 11:26 AM, Mark Millard <marklmi at yahoo.com> wrote:
> >>
> >>> On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
> >>>
> >>>> On Mon, 6 Aug 2018 10:12:43 -0700
> >>>> Mark Millard <[hidden email]> wrote:
> >>>>
> >>>>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
> >>>>>
> >>>>>> On Mon, 6 Aug 2018 02:48:57 -0700
> >>>>>> Mark Millard via freebsd-arm <[hidden email]> wrote:
> >>>>>>
> >>>>>>> I amd64 -> aarch64 cross built -r337347 and installed it
> >>>>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
> >>>>>>> bootaa64.efi) as an update. My attempted synchronization
> >>>>>>> of loader.conf and ttys and devd.conf may be incorrect.
> >>>>>>> (Previous to this the Pine64+ 2GB seemed to be working
> >>>>>>> okay but it was at a very old build.)
> >>>>>>>
> >>>>>>> The kernel config has GENERIC included but the various
> >>>>>>> debug features disabled. (My typical operating
> >>>>>>> environment.)
> >>>>>>>
> >>>>>>> For all I know what the below shows might be expected
> >>>>>>> at this point. The kernel seems to have problems with
> >>>>>>> the MMC (that the kernel was loaded from). No other
> >>>>>>> media are attached. mmcsd0 is really an 128 GiByte
> >>>>>>> emmc on an adapter. (This historically worked for me.)
> >>>>>>
> >>>>>> emmc to sd ? that's weird ...
> >>>>>
> >>>>> An example of the adapter I've used for this is:
> >>>>>
> >>>>> https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter
> >>>>
> >>>> So this is a passive adapter, maybe that's something that should work
> >>>> but it's definitly is something that calls for problems.
> >>>>
> >>>>> emmc is multi-mode for its allowed modes of operation. Thus
> >>>>> its ability to frequently be used this way, such as via HS200.
> >>>>> emmc is commonly more robust as I understand.
> >>>>
> >>>> I didn't understand a word.
> >>>
> >>> I got the HS200 reference from the boot -v output. Such is currently from the
> >>> JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC
> >>> members have free access, others do not.)
> >>>
> >>> The output reported:
> >>>
> >>> mmc0: Card at relative address 0x0002 added:
> >>> mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
> >>> mmc0:  quirks: 0
> >>> mmc0:  bus: 4bit, 200MHz (HS200 timing)
> >>> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
> >>>
> >>> The e.MMC bus speed modes with I/O Voltage 3V allowed are:
> >>>
> >>> Backwards Compatibility with legacy MMC card, data rate single, 3V allowed, bus widths 1,4,8, 0-26 MHz
> >>>
> >>> High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 MHz
> >>>
> >>> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz
> >>>
> >>> (The last being the fastest for maximum transfer rate with 3V.)
> >>>
> >>> There is another 1.8V/1.2V mode: HS400 that is dual data rate and always 8 bit,
> >>> unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. HS400
> >>> is optional and sufficiently old e.MMC standard vintages would likely not
> >>> even have it.
> >>>
> >>> So a slower 3.? V mode of use used to be selected (based on the constraints
> >>> on the board's voltages in some way, possibly hard coded).
> >>
> >> "slower" lacks context: I should have said . . .
> >>
> >> "a slower than HS200 3.? V mode"
> >>
> >> As I remember, the 3V range is from 2.7 V to 3.6 V or some such.
> >> So 3.3 V would be in range, at least if I remember right.
> >>
> >>>>>
> >>>>> (I had to modify the case the pine64+ 2GB is in in order for
> >>>>> the adapter/emmc combination to fit in all the way.)
> >>>>>
> >>>
> >
> > I duplicated the e.MMC partition content to a microsdhc
> > for each partition (and u-boot but no swap), made minor
> > changes, and tested booting. It booted, with messages
> > like:
> >
> > Trying to boot from MMC1
> > . . .
> > MMC:   SUNXI SD/MMC: 0
> > . . .
> > mmc0 is current device
> > Scanning mmc 0:1...
> > Found EFI removable media binary efi/boot/bootaa64.efi
> > . . .
> > Scanning disks on mmc...
> > MMC Device 1 not found
> > MMC Device 2 not found
> > MMC Device 3 not found
> > Found 3 disks
> > . . .
> > aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
> > mmc0: <MMC/SD bus> on aw_mmc0
> > . . .
> > mmcsd0: 32GB <SDHC SE32G 8.0 SN 09781303 MFG 07/2017 by 3 SD> at mmc0 50.0MHz/4bit/32768-block
> > mmc0: ACMD42 failed, RESULT: 4
> > mmc0: Card at relative address 43690 failed to set bus width
> >
> >
> >
> > Prior to the last 2 lines above looks normal to me for the
> > MMC material.
> >
> > So the only issue seems to be having an e.MCC device and
> > how it is handled (mode of attempted operation, including
> > voltage), given the limitations of the Pine64+ 2GB board.
> >
> > My hope would be for the Pine64+ 2GB with e.MMC on a MicroSD
> > e.MMC reader to be tried via:
> >
> > High Speed DDR mode (Data rate dual), 3.3V (so in the range
> > allowed around 3V), full bus width that can be used (4 in my
> > current context), 52 MHz or so.
> >
> > (At least for any vintage of e.MMC recent enough to have that
> > available. This e.MMC mode has been around since e.MMC 4.4
> > (2009). I've seen claims that at the host controller level
> > it is basically the same configuration used for SD DDR50,
> > with different arguments in CMD6 for configuration.)
> >
> > But I've no clue if this fits well with the upstream status
> > of things or not. I've seen claims that, unlike for UHS-II
> > and UHS-III, Linux has e.MMC speed mode support being "quite
> > complete" in the more generic parts not specific to each
> > controller. (Only a quick summary.) So I'm hopeful for
> > upstream.
>
> The 3V problem for e.MCC DDR @ 52 MHz looks more
> generic than the Pine64's or even aarch64 or even arm
> in general. Likely not your issue directly [Emmanuel].
>
> Looking around some more I see that the card-type/device-type
> bitfield had as of JESD84-A441 (March 2010) [JESD84-A44 was
> apparently withdrawn, not just updated]:
>
> Bits 7:4 reserved (defined in sufficiently more recent vintages)
> Bit 3: DDR MMC @ 52 MHz 1.2 V I/O
> Bit 2: DDR MMC @ 52 MHz 1.8 V or 3V I/O
> Bit 1: SDR @ 52 MHz at rated device voltage(s)
> Bit 0: SDR @ 26 MHz at rated device voltage(s)
> (more modern has 3-0 being the same)
>
> but the only valid bit patterns with 7:4 being zero
> were(/are): 0x01, 0x03, 0x07, 0x0B, and 0x0F.
>
> Note also that an e.MCC device can for DDR @ 52 MHz:
>
> support 1.2 V without supporting 1.8 V/3 V
> or:
> support 1.8 V/3 V without supporting 1.2 V
>
> (What I was using supports 3V and u-boot through
> loading the kernel worked fine.)
>
> Presuming the environment can supply an I/O voltage in the allowed
> range around 3V, such as 3.3V being the the range 2.7 V to 3.6 V:
> (The environment might not have 1.8V available as an
> alternative even though E.MMC devices have 1.8V and 3V paired, for
> example the Pine64+ 2GB, from what I'm told, lacks 1.8V.)
>
> Then 0x07 implies DDR @ 52 MHz with 3V I/O is available for use
> And  0x0F implies DDR @ 52 MHz with 3V I/O is available for use
> (Otherwise DDR @ 52 MHz with 3V I/O is unavailable.)
> If the e.MCC supports DDR @ 52 MHz with 1.8 V it also supports
> 3V --and the other way around.
>
> So the code is odd/incomplete in /usr/src/sys/dev/mmc/bridge.h :
>
> #define MMC_CAP_MMC_DDR52_120   (1 << 11) /* Can do eMMC DDR52 at 1.2 V */
> #define MMC_CAP_MMC_DDR52_180   (1 << 12) /* Can do eMMC DDR52 at 1.8 V */
> #define MMC_CAP_MMC_DDR52       (MMC_CAP_MMC_DDR52_120 | MMC_CAP_MMC_DDR52_180)
>
> unless MMC_CAP_MMC_DDR52_180 implicitly also covers 3V. If so, the
> comment should mention 3V, as might the macro name.
>
> Another possibility is that there should be another macro. Something
> like:
>
> #define MMC_CAP_MMC_DDR52_120   (1 << 11) /* Can do eMMC DDR52 at 1.2 V (nominal) */
> #define MMC_CAP_MMC_DDR52_180   (1 << 12) /* Can do eMMC DDR52 at 1.8 V (nominal) */
> #define MMC_CAP_MMC_DDR52_300   (1 << ??) /* Can do eMMC DDR52 at 3.0 V (nominal) */
> #define MMC_CAP_MMC_DDR52       (MMC_CAP_MMC_DDR52_120 | MMC_CAP_MMC_DDR52_180 | MMC_CAP_MMC_DDR52_300)
>
> (I do not claim such is sufficient, just suggestive.)
>
> It looks like this goes back to -r315598 (2017-Mar-19)
> when the code as 1st added by marius. I've not found any
> representation of the 3V DDR @ 52 MHz case for e.MMC
> so far.

It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However,
with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD
DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for
example figure 3-14 in the SD physical layer specification version
6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with
SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was
written, Linux didn't support the former either so I saw no point in
adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR
a bit later in January 2017, though).
While I have no problem with support for DDR52 at 3.0 V VCCQ being
added to mmc(4), I doubt that will solve your problem given that Linux
doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+
or any other Allwinner gear. Based on what I could figure out about
Allwinner MMC controllers, their capabilities actually differ depending
on the particular instance of MMC controller of a given SoC (apparently,
they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO).
So I guess what needs to be done is to let aw_mmc(4) announce and
support different sets of capabilities depending on which instance of
the controller it is driving. For your adapter this likely means that
high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD
slot complies with the SD physical layer specification if 1.8 V VCCQ
isn't supported by the particular board.

Marius

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
On 2018-Aug-9, at 3:00 PM, Marius Strobl <marius at freebsd.org> wrote:

> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote:
>> . . .
>
> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However,
> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD
> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for
> example figure 3-14 in the SD physical layer specification version
> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with
> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was
> written, Linux didn't support the former either so I saw no point in
> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR
> a bit later in January 2017, though).
> While I have no problem with support for DDR52 at 3.0 V VCCQ being
> added to mmc(4), I doubt that will solve your problem given that Linux
> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+
> or any other Allwinner gear. Based on what I could figure out about
> Allwinner MMC controllers, their capabilities actually differ depending
> on the particular instance of MMC controller of a given SoC (apparently,
> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO).
> So I guess what needs to be done is to let aw_mmc(4) announce and
> support different sets of capabilities depending on which instance of
> the controller it is driving. For your adapter this likely means that
> high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD
> slot complies with the SD physical layer specification if 1.8 V VCCQ
> isn't supported by the particular board.

Thanks for the notes.

Clearly there is something that I'm missing because:

*) Historically (before the switch to official dts's and such)
   I was able to boot, buildworld, buildkernel, poudreire-devel
   and the like booting from the e.MCC over the sdcard
   adapter plugged into the Pine64+ 2GB's sdcard slot.

   It had been my standard configuration for some time before
   I made the jump to a more modern environment.

As for now:

A) u-boot successfully gets the loader from the e.MCC over the sdcard
   adapter plugged into the Pine64+ 2GB's sdracard slot.

B) The loader successfully loads the kernel from the e.MCC over the
   sdcard adapter plugged into the Pine64+ 2GB's sdracard slot.

C) The first failure is from the kernel attempting to deal with
   the e.MCC (via the adapter).

I may have read into this (and the messages from boot -v and what
was said about them) the wrong assumptions about what is wrong.

What I can say is that the issue looks to be specific to the
FreeBSD kernel but not to the prior loader (nor to u-boot).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
On 2018-Aug-9, at 8:02 PM, Mark Millard <marklmi at yahoo.com> wrote:

> On 2018-Aug-9, at 3:00 PM, Marius Strobl <marius at freebsd.org> wrote:
>
>> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote:
>>> . . .
>>
>> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However,
>> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD
>> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for
>> example figure 3-14 in the SD physical layer specification version
>> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with
>> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was
>> written, Linux didn't support the former either so I saw no point in
>> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR
>> a bit later in January 2017, though).
>> While I have no problem with support for DDR52 at 3.0 V VCCQ being
>> added to mmc(4), I doubt that will solve your problem given that Linux
>> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+
>> or any other Allwinner gear. Based on what I could figure out about
>> Allwinner MMC controllers, their capabilities actually differ depending
>> on the particular instance of MMC controller of a given SoC (apparently,
>> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO).
>> So I guess what needs to be done is to let aw_mmc(4) announce and
>> support different sets of capabilities depending on which instance of
>> the controller it is driving. For your adapter this likely means that
>> high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD
>> slot complies with the SD physical layer specification if 1.8 V VCCQ
>> isn't supported by the particular board.
>
> Thanks for the notes.
>
> Clearly there is something that I'm missing because:
>
> *) Historically (before the switch to official dts's and such)
>   I was able to boot, buildworld, buildkernel, poudreire-devel
>   and the like booting from the e.MCC over the sdcard
>   adapter plugged into the Pine64+ 2GB's sdcard slot.
>
>   It had been my standard configuration for some time before
>   I made the jump to a more modern environment.
>
> As for now:
>
> A) u-boot successfully gets the loader from the e.MCC over the sdcard
>   adapter plugged into the Pine64+ 2GB's sdracard slot.
>
> B) The loader successfully loads the kernel from the e.MCC over the
>   sdcard adapter plugged into the Pine64+ 2GB's sdracard slot.
>
> C) The first failure is from the kernel attempting to deal with
>   the e.MCC (via the adapter).
>
> I may have read into this (and the messages from boot -v and what
> was said about them) the wrong assumptions about what is wrong.
>
> What I can say is that the issue looks to be specific to the
> FreeBSD kernel but not to the prior loader (nor to u-boot).

As for the Pine A64+ 2GB specifics . . .

Quoting pine6.org about the microsd support for Pine A64:

QUOTE
The Pine A64 board supports SD, SDHC, and SDXC format microSD card – this means the largest capacity is 256GB. Please note that if a microSD card is formatted as an FAT32 file format, the maximum capacity is 32GB.
END QUOTE

I would expect supporting SDHC and SDXC to mean support for
various 1.8V modes of use: Such required if UHS-I is
supported (UHS50 or UHS104). Also DDR50 is required for
microSD (but not Standard SD). This would seem to match what
the schematics suggest to me (see below).

I looked and the Power Tree page of the schematics for
the Pine A64+ 2GB at:

http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20Rev%20C-20160113_Release.pdf

and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to
"3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page
shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows
VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to
VDD. T-CARD looks to me like the sdcard slot connections.
(Yes: the mix of T-CADD and T-CARD naming is as in the
document.) (I'm not listing the capacitor and such.)



For reference, for the e.MCC adaptor for anyone that cares:
(things like "3.3V" are as labeled in those schematics,
whatever the actual voltage of use for some mode of use)

https://forum.odroid.com/download/file.php?id=1036&mode=view

shows a 49.9K resister in line between 3.3V and RSTN at the
e.MMC end of things. It also shows a 10uF capacitor between
3.3V and ground on VDD from the micrSD end of things.

The rest is direct connections.

But the connections are for using a Hardkernel eMMC module,
in my case V0.3.

http://forum.odroid.com/download/file.php?id=433

is for that module. Other than some parallel capacitors to
ground off of VDD and VDDF, and one off of VDDI, it looks
like direct connections there to the e.MMC device as well.

End "for reference".



The above does not say the the loader and u-boot are using
a 1.8 V mode instead of a 3.3V mode of operation for the
sdcard interface, even if 1.8V is possible.

From an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be
any of (for 3V):

Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V
Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device voltage(s)"
Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device voltage(s)"

that match up with one of the sdcard 3.3V modes:

UHS-I modes:
DS: Default Speed up to 25 MHz 3.3V signaling
HS: High Speed up to 50 MHz 3.3V signaling
(Looks like the signal timings are distinct from 1.8 V modes.)

So not bit 2 if 3V, unsure about the other two bits for 3V.

In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1
UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does
boot from) the kernel seems to pick the UHS-I HS mode,
instead of SDR50 or DDR50 or higher:

aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
aw_mmc0: vmmc-supply regulator found
mmc0: <MMC/SD bus> on aw_mmc0
random: harvesting attach, 8 bytes (4 bits) from mmc0
random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached)
. . .
aw_mmc0: Powering up sd/mmc
mmc0: Probing bus
. . .
mmc0: SD 2.0 interface conditions: OK
mmc0: SD probe: OK (OCR: 0x40ff8000)
mmc0: Current OCR: 0x00ff8000
mmc0: Probing cards
mmc0: New card detected (CID 0353445345333247800978130301171d)
mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3)
mmc0: Card at relative address 0xaaaa added:
mmc0:  card: SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD
mmc0:  quirks: 0
mmc0:  bus: 4bit, 50MHz (high speed timing)
mmc0:  memory: 62333952 blocks, erase sector 8192 blocks
mmc0: setting transfer rate to 50.000MHz (high speed timing)
mmcsd0: 32GB <SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD> at mmc0 50.0MHz/4bit/32768-block
random: harvesting attach, 8 bytes (4 bits) from mmcsd0
GEOM: new disk mmcsd0
mmc0: setting bus width to 4 bits high speed timing
mmc0: ACMD42 failed, RESULT: 4
mmc0: Card at relative address 43690 failed to set bus width




===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

Emmanuel Vadot-7
On Thu, 9 Aug 2018 23:39:35 -0700
Mark Millard <[hidden email]> wrote:

> On 2018-Aug-9, at 8:02 PM, Mark Millard <marklmi at yahoo.com> wrote:
>
> > On 2018-Aug-9, at 3:00 PM, Marius Strobl <marius at freebsd.org> wrote:
> >
> >> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote:
> >>> . . .
> >>
> >> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However,
> >> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD
> >> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for
> >> example figure 3-14 in the SD physical layer specification version
> >> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with
> >> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was
> >> written, Linux didn't support the former either so I saw no point in
> >> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR
> >> a bit later in January 2017, though).
> >> While I have no problem with support for DDR52 at 3.0 V VCCQ being
> >> added to mmc(4), I doubt that will solve your problem given that Linux
> >> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+
> >> or any other Allwinner gear. Based on what I could figure out about
> >> Allwinner MMC controllers, their capabilities actually differ depending
> >> on the particular instance of MMC controller of a given SoC (apparently,
> >> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO).

 Yes, the first controller is usually used for SD, second for SDIO and
the third for eMMC. I don't know if any of them can be used for any of
the function or if they are intended to be used for a specific mode.

> >> So I guess what needs to be done is to let aw_mmc(4) announce and
> >> support different sets of capabilities depending on which instance of
> >> the controller it is driving.

That seems the easiest fix.

> >> For your adapter this likely means that
> >> high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD
> >> slot complies with the SD physical layer specification if 1.8 V VCCQ
> >> isn't supported by the particular board.
> >
> > Thanks for the notes.
> >
> > Clearly there is something that I'm missing because:
> >
> > *) Historically (before the switch to official dts's and such)
> >   I was able to boot, buildworld, buildkernel, poudreire-devel
> >   and the like booting from the e.MCC over the sdcard
> >   adapter plugged into the Pine64+ 2GB's sdcard slot.

 We always used official DTS for aarch64.
 What changed recently is that I added DDR52 support to the controller.

> >   It had been my standard configuration for some time before
> >   I made the jump to a more modern environment.
> >
> > As for now:
> >
> > A) u-boot successfully gets the loader from the e.MCC over the sdcard
> >   adapter plugged into the Pine64+ 2GB's sdracard slot.
> >
> > B) The loader successfully loads the kernel from the e.MCC over the
> >   sdcard adapter plugged into the Pine64+ 2GB's sdracard slot.

 Loaded use u-boot driver and it only work with HS mode iirc.

> > C) The first failure is from the kernel attempting to deal with
> >   the e.MCC (via the adapter).
> >
> > I may have read into this (and the messages from boot -v and what
> > was said about them) the wrong assumptions about what is wrong.
> >
> > What I can say is that the issue looks to be specific to the
> > FreeBSD kernel but not to the prior loader (nor to u-boot).
>
> As for the Pine A64+ 2GB specifics . . .
>
> Quoting pine6.org about the microsd support for Pine A64:
>
> QUOTE
> The Pine A64 board supports SD, SDHC, and SDXC format microSD card ? this means the largest capacity is 256GB. Please note that if a microSD card is formatted as an FAT32 file format, the maximum capacity is 32GB.
> END QUOTE
>
> I would expect supporting SDHC and SDXC to mean support for
> various 1.8V modes of use: Such required if UHS-I is
> supported (UHS50 or UHS104). Also DDR50 is required for
> microSD (but not Standard SD). This would seem to match what
> the schematics suggest to me (see below).
>
> I looked and the Power Tree page of the schematics for
> the Pine A64+ 2GB at:
>
> http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20Rev%20C-20160113_Release.pdf
>
> and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to
> "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page
> shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows
> VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to
> VDD. T-CARD looks to me like the sdcard slot connections.
> (Yes: the mix of T-CADD and T-CARD naming is as in the
> document.) (I'm not listing the capacitor and such.)

 VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO,
VCC3V3-USB etc .... so it needs to stay at 3.3V

>
>
> For reference, for the e.MCC adaptor for anyone that cares:
> (things like "3.3V" are as labeled in those schematics,
> whatever the actual voltage of use for some mode of use)
>
> https://forum.odroid.com/download/file.php?id=1036&mode=view
>
> shows a 49.9K resister in line between 3.3V and RSTN at the
> e.MMC end of things. It also shows a 10uF capacitor between
> 3.3V and ground on VDD from the micrSD end of things.
>
> The rest is direct connections.
>
> But the connections are for using a Hardkernel eMMC module,
> in my case V0.3.
>
> http://forum.odroid.com/download/file.php?id=433
>
> is for that module. Other than some parallel capacitors to
> ground off of VDD and VDDF, and one off of VDDI, it looks
> like direct connections there to the e.MMC device as well.
>
> End "for reference".
>
>
>
> The above does not say the the loader and u-boot are using
> a 1.8 V mode instead of a 3.3V mode of operation for the
> sdcard interface, even if 1.8V is possible.

 It doesn't, see
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts#L151

 Again, 1.8V is in theory possible, but I wouldn't try that on my
boards.

> From an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be
> any of (for 3V):
>
> Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V
> Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device voltage(s)"
> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device voltage(s)"
>
> that match up with one of the sdcard 3.3V modes:
>
> UHS-I modes:
> DS: Default Speed up to 25 MHz 3.3V signaling
> HS: High Speed up to 50 MHz 3.3V signaling
> (Looks like the signal timings are distinct from 1.8 V modes.)
>
> So not bit 2 if 3V, unsure about the other two bits for 3V.
>
> In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1
> UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does
> boot from) the kernel seems to pick the UHS-I HS mode,
> instead of SDR50 or DDR50 or higher:

 Because SDR50 or DDR50 needs 1.8V signaling.
 So the maximum mode that we can select is HS at 50Mhz which is
using 3.3V signaling.

> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
> aw_mmc0: vmmc-supply regulator found
> mmc0: <MMC/SD bus> on aw_mmc0
> random: harvesting attach, 8 bytes (4 bits) from mmc0
> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
> simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
> simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached)
> . . .
> aw_mmc0: Powering up sd/mmc
> mmc0: Probing bus
> . . .
> mmc0: SD 2.0 interface conditions: OK
> mmc0: SD probe: OK (OCR: 0x40ff8000)
> mmc0: Current OCR: 0x00ff8000
> mmc0: Probing cards
> mmc0: New card detected (CID 0353445345333247800978130301171d)
> mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3)
> mmc0: Card at relative address 0xaaaa added:
> mmc0:  card: SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD
> mmc0:  quirks: 0
> mmc0:  bus: 4bit, 50MHz (high speed timing)
> mmc0:  memory: 62333952 blocks, erase sector 8192 blocks
> mmc0: setting transfer rate to 50.000MHz (high speed timing)
> mmcsd0: 32GB <SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD> at mmc0 50.0MHz/4bit/32768-block
> random: harvesting attach, 8 bytes (4 bits) from mmcsd0
> GEOM: new disk mmcsd0
> mmc0: setting bus width to 4 bits high speed timing
> mmc0: ACMD42 failed, RESULT: 4
> mmc0: Card at relative address 43690 failed to set bus width
>
>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)


--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
On 2018-Aug-9, at 11:59 PM, Emmanuel Vadot <manu at bidouilliste.com> wrote:

> On Thu, 9 Aug 2018 23:39:35 -0700
> Mark Millard <marklmi at yahoo.com> wrote:
>
>> On 2018-Aug-9, at 8:02 PM, Mark Millard <marklmi at yahoo.com> wrote:
>>
>>> On 2018-Aug-9, at 3:00 PM, Marius Strobl <marius at freebsd.org> wrote:
>>>
>>>> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote:
>>>>> . . .
>>>>
>>>> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However,
>>>> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD
>>>> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for
>>>> example figure 3-14 in the SD physical layer specification version
>>>> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with
>>>> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was
>>>> written, Linux didn't support the former either so I saw no point in
>>>> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR
>>>> a bit later in January 2017, though).
>>>> While I have no problem with support for DDR52 at 3.0 V VCCQ being
>>>> added to mmc(4), I doubt that will solve your problem given that Linux
>>>> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+
>>>> or any other Allwinner gear. Based on what I could figure out about
>>>> Allwinner MMC controllers, their capabilities actually differ depending
>>>> on the particular instance of MMC controller of a given SoC (apparently,
>>>> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO).
>
> Yes, the first controller is usually used for SD, second for SDIO and
> the third for eMMC. I don't know if any of them can be used for any of
> the function or if they are intended to be used for a specific mode.
>
>>>> So I guess what needs to be done is to let aw_mmc(4) announce and
>>>> support different sets of capabilities depending on which instance of
>>>> the controller it is driving.
>
> That seems the easiest fix.
>
>>>> For your adapter this likely means that
>>>> high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD
>>>> slot complies with the SD physical layer specification if 1.8 V VCCQ
>>>> isn't supported by the particular board.
>>>
>>> Thanks for the notes.
>>>
>>> Clearly there is something that I'm missing because:
>>>
>>> *) Historically (before the switch to official dts's and such)
>>>  I was able to boot, buildworld, buildkernel, poudreire-devel
>>>  and the like booting from the e.MCC over the sdcard
>>>  adapter plugged into the Pine64+ 2GB's sdcard slot.
>
> We always used official DTS for aarch64.
> What changed recently is that I added DDR52 support to the controller.

My quick attempt at identifying the history point was poor. It
looks like I should have referenced before and during the ccu-ng switch,
before and during the USB being temporarily unsupported in the
similar time frame. I held back to materials that allowed USB use and
did not update past that until just recently. (This is still just a summary,
not the full history of my builds based on the older materials in this area.
But it should be good enough.)

>>>  It had been my standard configuration for some time before
>>>  I made the jump to a more modern environment.
>>>
>>> As for now:
>>>
>>> A) u-boot successfully gets the loader from the e.MCC over the sdcard
>>>  adapter plugged into the Pine64+ 2GB's sdracard slot.
>>>
>>> B) The loader successfully loads the kernel from the e.MCC over the
>>>  sdcard adapter plugged into the Pine64+ 2GB's sdracard slot.
>
> Loaded use u-boot driver and it only work with HS mode iirc.

Sounds likely. Good to know. Thanks.

>>> C) The first failure is from the kernel attempting to deal with
>>>  the e.MCC (via the adapter).
>>>
>>> I may have read into this (and the messages from boot -v and what
>>> was said about them) the wrong assumptions about what is wrong.
>>>
>>> What I can say is that the issue looks to be specific to the
>>> FreeBSD kernel but not to the prior loader (nor to u-boot).
>>
>> As for the Pine A64+ 2GB specifics . . .
>>
>> Quoting pine6.org about the microsd support for Pine A64:
>>
>> QUOTE
>> The Pine A64 board supports SD, SDHC, and SDXC format microSD card ? this means the largest capacity is 256GB. Please note that if a microSD card is formatted as an FAT32 file format, the maximum capacity is 32GB.
>> END QUOTE
>>
>> I would expect supporting SDHC and SDXC to mean support for
>> various 1.8V modes of use: Such required if UHS-I is
>> supported (UHS50 or UHS104). Also DDR50 is required for
>> microSD (but not Standard SD). This would seem to match what
>> the schematics suggest to me (see below).
>>
>> I looked and the Power Tree page of the schematics for
>> the Pine A64+ 2GB at:
>>
>> http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20Rev%20C-20160113_Release.pdf
>>
>> and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to
>> "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page
>> shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows
>> VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to
>> VDD. T-CARD looks to me like the sdcard slot connections.
>> (Yes: the mix of T-CADD and T-CARD naming is as in the
>> document.) (I'm not listing the capacitor and such.)
>
> VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO,
> VCC3V3-USB etc .... so it needs to stay at 3.3V

Ahh, I see. All the control of such is at DC/DC1 and the rest follow
together.

>>
>>
>> For reference, for the e.MCC adaptor for anyone that cares:
>> (things like "3.3V" are as labeled in those schematics,
>> whatever the actual voltage of use for some mode of use)
>>
>> https://forum.odroid.com/download/file.php?id=1036&mode=view
>>
>> shows a 49.9K resister in line between 3.3V and RSTN at the
>> e.MMC end of things. It also shows a 10uF capacitor between
>> 3.3V and ground on VDD from the micrSD end of things.
>>
>> The rest is direct connections.
>>
>> But the connections are for using a Hardkernel eMMC module,
>> in my case V0.3.
>>
>> http://forum.odroid.com/download/file.php?id=433
>>
>> is for that module. Other than some parallel capacitors to
>> ground off of VDD and VDDF, and one off of VDDI, it looks
>> like direct connections there to the e.MMC device as well.
>>
>> End "for reference".
>>
>>
>>
>> The above does not say the the loader and u-boot are using
>> a 1.8 V mode instead of a 3.3V mode of operation for the
>> sdcard interface, even if 1.8V is possible.
>
> It doesn't, see
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts#L151
>
> Again, 1.8V is in theory possible, but I wouldn't try that on my
> boards.

So it looks like if the e.MMC on an adapter card were to be supported,
it would be via Bit 1 or Bit 0 below, much like u-boot is apparently
doing.

>> From an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be
>> any of (for 3V):
>>
>> Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V
>> Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device voltage(s)"
>> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device voltage(s)"
>>
>> that match up with one of the sdcard 3.3V modes:
>>
>> UHS-I modes:
>> DS: Default Speed up to 25 MHz 3.3V signaling
>> HS: High Speed up to 50 MHz 3.3V signaling
>> (Looks like the signal timings are distinct from 1.8 V modes.)
>>
>> So not bit 2 if 3V, unsure about the other two bits for 3V.
>>
>> In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1
>> UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does
>> boot from) the kernel seems to pick the UHS-I HS mode,
>> instead of SDR50 or DDR50 or higher:
>
> Because SDR50 or DDR50 needs 1.8V signaling.
> So the maximum mode that we can select is HS at 50Mhz which is
> using 3.3V signaling.

Okay. It would be nice if the e.MMC on an sdcard adapter also did so
someday, somewhat like u-boot apparently does (up to clock rate
differences?). Even going slower, I'd prefer e.MMC media.

>> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
>> aw_mmc0: vmmc-supply regulator found
>> mmc0: <MMC/SD bus> on aw_mmc0
>> random: harvesting attach, 8 bytes (4 bits) from mmc0
>> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
>> simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
>> simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached)
>> . . .
>> aw_mmc0: Powering up sd/mmc
>> mmc0: Probing bus
>> . . .
>> mmc0: SD 2.0 interface conditions: OK
>> mmc0: SD probe: OK (OCR: 0x40ff8000)
>> mmc0: Current OCR: 0x00ff8000
>> mmc0: Probing cards
>> mmc0: New card detected (CID 0353445345333247800978130301171d)
>> mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3)
>> mmc0: Card at relative address 0xaaaa added:
>> mmc0:  card: SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD
>> mmc0:  quirks: 0
>> mmc0:  bus: 4bit, 50MHz (high speed timing)
>> mmc0:  memory: 62333952 blocks, erase sector 8192 blocks
>> mmc0: setting transfer rate to 50.000MHz (high speed timing)
>> mmcsd0: 32GB <SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD> at mmc0 50.0MHz/4bit/32768-block
>> random: harvesting attach, 8 bytes (4 bits) from mmcsd0
>> GEOM: new disk mmcsd0
>> mmc0: setting bus width to 4 bits high speed timing
>> mmc0: ACMD42 failed, RESULT: 4
>> mmc0: Card at relative address 43690 failed to set bus width
>>
>>




===
Mark Millard
marklmi at yahoo.com
( dsl-only.net <http://dsl-only.net/> went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
[A note about linux booting is added.]

On 2018-Aug-10, at 1:10 AM, Mark Millard <marklmi at yahoo.com> wrote:

> On 2018-Aug-9, at 11:59 PM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>
>> On Thu, 9 Aug 2018 23:39:35 -0700
>> Mark Millard <marklmi at yahoo.com> wrote:
>>
>>> On 2018-Aug-9, at 8:02 PM, Mark Millard <marklmi at yahoo.com> wrote:
>>>
>>>> On 2018-Aug-9, at 3:00 PM, Marius Strobl <marius at freebsd.org> wrote:
>>>>
>>>>> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote:
>>>>>> . . .
>>>>>
>>>>> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However,
>>>>> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD
>>>>> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for
>>>>> example figure 3-14 in the SD physical layer specification version
>>>>> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with
>>>>> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was
>>>>> written, Linux didn't support the former either so I saw no point in
>>>>> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR
>>>>> a bit later in January 2017, though).
>>>>> While I have no problem with support for DDR52 at 3.0 V VCCQ being
>>>>> added to mmc(4), I doubt that will solve your problem given that Linux
>>>>> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+
>>>>> or any other Allwinner gear. Based on what I could figure out about
>>>>> Allwinner MMC controllers, their capabilities actually differ depending
>>>>> on the particular instance of MMC controller of a given SoC (apparently,
>>>>> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO).
>>
>> Yes, the first controller is usually used for SD, second for SDIO and
>> the third for eMMC. I don't know if any of them can be used for any of
>> the function or if they are intended to be used for a specific mode.
>>
>>>>> So I guess what needs to be done is to let aw_mmc(4) announce and
>>>>> support different sets of capabilities depending on which instance of
>>>>> the controller it is driving.
>>
>> That seems the easiest fix.
>>
>>>>> For your adapter this likely means that
>>>>> high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD
>>>>> slot complies with the SD physical layer specification if 1.8 V VCCQ
>>>>> isn't supported by the particular board.
>>>>
>>>> Thanks for the notes.
>>>>
>>>> Clearly there is something that I'm missing because:
>>>>
>>>> *) Historically (before the switch to official dts's and such)
>>>>  I was able to boot, buildworld, buildkernel, poudreire-devel
>>>>  and the like booting from the e.MCC over the sdcard
>>>>  adapter plugged into the Pine64+ 2GB's sdcard slot.
>>
>> We always used official DTS for aarch64.
>> What changed recently is that I added DDR52 support to the controller.
>
> My quick attempt at identifying the history point was poor. It
> looks like I should have referenced before and during the ccu-ng switch,
> before and during the USB being temporarily unsupported in the
> similar time frame. I held back to materials that allowed USB use and
> did not update past that until just recently. (This is still just a summary,
> not the full history of my builds based on the older materials in this area.
> But it should be good enough.)
>
>>>>  It had been my standard configuration for some time before
>>>>  I made the jump to a more modern environment.
>>>>
>>>> As for now:
>>>>
>>>> A) u-boot successfully gets the loader from the e.MCC over the sdcard
>>>>  adapter plugged into the Pine64+ 2GB's sdracard slot.
>>>>
>>>> B) The loader successfully loads the kernel from the e.MCC over the
>>>>  sdcard adapter plugged into the Pine64+ 2GB's sdracard slot.
>>
>> Loaded use u-boot driver and it only work with HS mode iirc.
>
> Sounds likely. Good to know. Thanks.
>
>>>> C) The first failure is from the kernel attempting to deal with
>>>>  the e.MCC (via the adapter).
>>>>
>>>> I may have read into this (and the messages from boot -v and what
>>>> was said about them) the wrong assumptions about what is wrong.
>>>>
>>>> What I can say is that the issue looks to be specific to the
>>>> FreeBSD kernel but not to the prior loader (nor to u-boot).
>>>
>>> As for the Pine A64+ 2GB specifics . . .
>>>
>>> Quoting pine6.org about the microsd support for Pine A64:
>>>
>>> QUOTE
>>> The Pine A64 board supports SD, SDHC, and SDXC format microSD card ? this means the largest capacity is 256GB. Please note that if a microSD card is formatted as an FAT32 file format, the maximum capacity is 32GB.
>>> END QUOTE
>>>
>>> I would expect supporting SDHC and SDXC to mean support for
>>> various 1.8V modes of use: Such required if UHS-I is
>>> supported (UHS50 or UHS104). Also DDR50 is required for
>>> microSD (but not Standard SD). This would seem to match what
>>> the schematics suggest to me (see below).
>>>
>>> I looked and the Power Tree page of the schematics for
>>> the Pine A64+ 2GB at:
>>>
>>> http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20Rev%20C-20160113_Release.pdf
>>>
>>> and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to
>>> "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page
>>> shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows
>>> VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to
>>> VDD. T-CARD looks to me like the sdcard slot connections.
>>> (Yes: the mix of T-CADD and T-CARD naming is as in the
>>> document.) (I'm not listing the capacitor and such.)
>>
>> VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO,
>> VCC3V3-USB etc .... so it needs to stay at 3.3V
>
> Ahh, I see. All the control of such is at DC/DC1 and the rest follow
> together.
>
>>>
>>>
>>> For reference, for the e.MCC adaptor for anyone that cares:
>>> (things like "3.3V" are as labeled in those schematics,
>>> whatever the actual voltage of use for some mode of use)
>>>
>>> https://forum.odroid.com/download/file.php?id=1036&mode=view
>>>
>>> shows a 49.9K resister in line between 3.3V and RSTN at the
>>> e.MMC end of things. It also shows a 10uF capacitor between
>>> 3.3V and ground on VDD from the micrSD end of things.
>>>
>>> The rest is direct connections.
>>>
>>> But the connections are for using a Hardkernel eMMC module,
>>> in my case V0.3.
>>>
>>> http://forum.odroid.com/download/file.php?id=433
>>>
>>> is for that module. Other than some parallel capacitors to
>>> ground off of VDD and VDDF, and one off of VDDI, it looks
>>> like direct connections there to the e.MMC device as well.
>>>
>>> End "for reference".
>>>
>>>
>>>
>>> The above does not say the the loader and u-boot are using
>>> a 1.8 V mode instead of a 3.3V mode of operation for the
>>> sdcard interface, even if 1.8V is possible.
>>
>> It doesn't, see
>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts#L151
>>
>> Again, 1.8V is in theory possible, but I wouldn't try that on my
>> boards.
>
> So it looks like if the e.MMC on an adapter card were to be supported,
> it would be via Bit 1 or Bit 0 below, much like u-boot is apparently
> doing.
>
>>> From an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be
>>> any of (for 3V):
>>>
>>> Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V
>>> Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device voltage(s)"
>>> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device voltage(s)"
>>>
>>> that match up with one of the sdcard 3.3V modes:
>>>
>>> UHS-I modes:
>>> DS: Default Speed up to 25 MHz 3.3V signaling
>>> HS: High Speed up to 50 MHz 3.3V signaling
>>> (Looks like the signal timings are distinct from 1.8 V modes.)
>>>
>>> So not bit 2 if 3V, unsure about the other two bits for 3V.
>>>
>>> In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1
>>> UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does
>>> boot from) the kernel seems to pick the UHS-I HS mode,
>>> instead of SDR50 or DDR50 or higher:
>>
>> Because SDR50 or DDR50 needs 1.8V signaling.
>> So the maximum mode that we can select is HS at 50Mhz which is
>> using 3.3V signaling.
>
> Okay. It would be nice if the e.MMC on an sdcard adapter also did so
> someday, somewhat like u-boot apparently does (up to clock rate
> differences?). Even going slower, I'd prefer e.MMC media.
>
>>> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
>>> aw_mmc0: vmmc-supply regulator found
>>> mmc0: <MMC/SD bus> on aw_mmc0
>>> random: harvesting attach, 8 bytes (4 bits) from mmc0
>>> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
>>> simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
>>> simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached)
>>> . . .
>>> aw_mmc0: Powering up sd/mmc
>>> mmc0: Probing bus
>>> . . .
>>> mmc0: SD 2.0 interface conditions: OK
>>> mmc0: SD probe: OK (OCR: 0x40ff8000)
>>> mmc0: Current OCR: 0x00ff8000
>>> mmc0: Probing cards
>>> mmc0: New card detected (CID 0353445345333247800978130301171d)
>>> mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3)
>>> mmc0: Card at relative address 0xaaaa added:
>>> mmc0:  card: SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD
>>> mmc0:  quirks: 0
>>> mmc0:  bus: 4bit, 50MHz (high speed timing)
>>> mmc0:  memory: 62333952 blocks, erase sector 8192 blocks
>>> mmc0: setting transfer rate to 50.000MHz (high speed timing)
>>> mmcsd0: 32GB <SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD> at mmc0 50.0MHz/4bit/32768-block
>>> random: harvesting attach, 8 bytes (4 bits) from mmcsd0
>>> GEOM: new disk mmcsd0
>>> mmc0: setting bus width to 4 bits high speed timing
>>> mmc0: ACMD42 failed, RESULT: 4
>>> mmc0: Card at relative address 43690 failed to set bus width
>>>
>>>
>


Just to see what a modern linux with a modern kernel
might do I downloaded:

https://dl.armbian.com/pine64/Ubuntu_bionic_dev_nightly.7z

which is:

nightly mainline kernel master branch 4.17.y or 4.18.y

# uname -ap
Linux pine64 4.18.0-rc4-sunxi64 #220 SMP Sun Jul 15 14:16:31 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

I put it on an e.MMC and used it to boot the pine64+ 2GB
via the e.MMC adapter and it booted fine.

# cat /sys/kernel/debug/mmc0/ios
clock:          52000000 Hz
actual clock:   50000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    8 (mmc DDR52)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)

# hdparm -t /dev/mmcblk0

/dev/mmcblk0:
 Timing buffered disk reads: 134 MB in  3.04 seconds =  44.03 MB/sec

# hdparm -T /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   1298 MB in  2.00 seconds = 649.15 MB/sec

For interpreting those (-t vs. -T):

QUOTE
       -t     Perform timings of device reads for benchmark and comparison purposes.  For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other
              active  processes)  with  at  least a couple of megabytes of free memory.  This displays the speed of reading through the buffer cache to the disk without any prior caching of data.
              This measurement is an indication of how fast the drive can sustain sequential data reads under Linux, without any filesystem overhead.  To ensure accurate measurements, the  buffer
              cache is flushed during the processing of -t using the BLKFLSBUF ioctl.

       -T     Perform  timings of cache reads for benchmark and comparison purposes.  For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other
              active processes) with at least a couple of megabytes of free memory.  This displays the speed of reading directly from the Linux buffer cache without disk access.  This measurement
              is essentially an indication of the throughput of the processor, cache, and memory of the system under test.
END QUOTE

So it appears to me that the DDR52 over 4 data bits is real,
despite the apparent 3.3V usage for VCCQ (and so VCC as well).

In other words: they are using e.MCC CARD_TYPE/DEVICE_TYPE bit 2:

Bit 2: High-speed DDR MultimediaCard @ (at most) 52 MHz - 1.8aV or 3V I/O

and were not restricted to just the microSDHC speed and I/O voltage
combinations by the Pine64+ 2GB.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

freebsd-arm mailing list
[A note about CARD_TYPE/DEVICE_TYPE is added.]

On 2018-Aug-10, at 3:53 AM, Mark Millard <marklmi at yahoo.com> wrote:

> [A note about linux booting is added.]
>
> On 2018-Aug-10, at 1:10 AM, Mark Millard <marklmi at yahoo.com> wrote:
>
>> On 2018-Aug-9, at 11:59 PM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>
>>> On Thu, 9 Aug 2018 23:39:35 -0700
>>> Mark Millard <marklmi at yahoo.com> wrote:
>>>
>>>> On 2018-Aug-9, at 8:02 PM, Mark Millard <marklmi at yahoo.com> wrote:
>>>>
>>>>> On 2018-Aug-9, at 3:00 PM, Marius Strobl <marius at freebsd.org> wrote:
>>>>>
>>>>>> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote:
>>>>>>> . . .
>>>>>>
>>>>>> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However,
>>>>>> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD
>>>>>> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for
>>>>>> example figure 3-14 in the SD physical layer specification version
>>>>>> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with
>>>>>> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was
>>>>>> written, Linux didn't support the former either so I saw no point in
>>>>>> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR
>>>>>> a bit later in January 2017, though).
>>>>>> While I have no problem with support for DDR52 at 3.0 V VCCQ being
>>>>>> added to mmc(4), I doubt that will solve your problem given that Linux
>>>>>> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+
>>>>>> or any other Allwinner gear. Based on what I could figure out about
>>>>>> Allwinner MMC controllers, their capabilities actually differ depending
>>>>>> on the particular instance of MMC controller of a given SoC (apparently,
>>>>>> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO).
>>>
>>> Yes, the first controller is usually used for SD, second for SDIO and
>>> the third for eMMC. I don't know if any of them can be used for any of
>>> the function or if they are intended to be used for a specific mode.
>>>
>>>>>> So I guess what needs to be done is to let aw_mmc(4) announce and
>>>>>> support different sets of capabilities depending on which instance of
>>>>>> the controller it is driving.
>>>
>>> That seems the easiest fix.
>>>
>>>>>> For your adapter this likely means that
>>>>>> high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD
>>>>>> slot complies with the SD physical layer specification if 1.8 V VCCQ
>>>>>> isn't supported by the particular board.
>>>>>
>>>>> Thanks for the notes.
>>>>>
>>>>> Clearly there is something that I'm missing because:
>>>>>
>>>>> *) Historically (before the switch to official dts's and such)
>>>>> I was able to boot, buildworld, buildkernel, poudreire-devel
>>>>> and the like booting from the e.MCC over the sdcard
>>>>> adapter plugged into the Pine64+ 2GB's sdcard slot.
>>>
>>> We always used official DTS for aarch64.
>>> What changed recently is that I added DDR52 support to the controller.
>>
>> My quick attempt at identifying the history point was poor. It
>> looks like I should have referenced before and during the ccu-ng switch,
>> before and during the USB being temporarily unsupported in the
>> similar time frame. I held back to materials that allowed USB use and
>> did not update past that until just recently. (This is still just a summary,
>> not the full history of my builds based on the older materials in this area.
>> But it should be good enough.)
>>
>>>>> It had been my standard configuration for some time before
>>>>> I made the jump to a more modern environment.
>>>>>
>>>>> As for now:
>>>>>
>>>>> A) u-boot successfully gets the loader from the e.MCC over the sdcard
>>>>> adapter plugged into the Pine64+ 2GB's sdracard slot.
>>>>>
>>>>> B) The loader successfully loads the kernel from the e.MCC over the
>>>>> sdcard adapter plugged into the Pine64+ 2GB's sdracard slot.
>>>
>>> Loaded use u-boot driver and it only work with HS mode iirc.
>>
>> Sounds likely. Good to know. Thanks.
>>
>>>>> C) The first failure is from the kernel attempting to deal with
>>>>> the e.MCC (via the adapter).
>>>>>
>>>>> I may have read into this (and the messages from boot -v and what
>>>>> was said about them) the wrong assumptions about what is wrong.
>>>>>
>>>>> What I can say is that the issue looks to be specific to the
>>>>> FreeBSD kernel but not to the prior loader (nor to u-boot).
>>>>
>>>> As for the Pine A64+ 2GB specifics . . .
>>>>
>>>> Quoting pine6.org about the microsd support for Pine A64:
>>>>
>>>> QUOTE
>>>> The Pine A64 board supports SD, SDHC, and SDXC format microSD card ? this means the largest capacity is 256GB. Please note that if a microSD card is formatted as an FAT32 file format, the maximum capacity is 32GB.
>>>> END QUOTE
>>>>
>>>> I would expect supporting SDHC and SDXC to mean support for
>>>> various 1.8V modes of use: Such required if UHS-I is
>>>> supported (UHS50 or UHS104). Also DDR50 is required for
>>>> microSD (but not Standard SD). This would seem to match what
>>>> the schematics suggest to me (see below).
>>>>
>>>> I looked and the Power Tree page of the schematics for
>>>> the Pine A64+ 2GB at:
>>>>
>>>> http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20Rev%20C-20160113_Release.pdf
>>>>
>>>> and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to
>>>> "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page
>>>> shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows
>>>> VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to
>>>> VDD. T-CARD looks to me like the sdcard slot connections.
>>>> (Yes: the mix of T-CADD and T-CARD naming is as in the
>>>> document.) (I'm not listing the capacitor and such.)
>>>
>>> VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO,
>>> VCC3V3-USB etc .... so it needs to stay at 3.3V
>>
>> Ahh, I see. All the control of such is at DC/DC1 and the rest follow
>> together.
>>
>>>>
>>>>
>>>> For reference, for the e.MCC adaptor for anyone that cares:
>>>> (things like "3.3V" are as labeled in those schematics,
>>>> whatever the actual voltage of use for some mode of use)
>>>>
>>>> https://forum.odroid.com/download/file.php?id=1036&mode=view
>>>>
>>>> shows a 49.9K resister in line between 3.3V and RSTN at the
>>>> e.MMC end of things. It also shows a 10uF capacitor between
>>>> 3.3V and ground on VDD from the micrSD end of things.
>>>>
>>>> The rest is direct connections.
>>>>
>>>> But the connections are for using a Hardkernel eMMC module,
>>>> in my case V0.3.
>>>>
>>>> http://forum.odroid.com/download/file.php?id=433
>>>>
>>>> is for that module. Other than some parallel capacitors to
>>>> ground off of VDD and VDDF, and one off of VDDI, it looks
>>>> like direct connections there to the e.MMC device as well.
>>>>
>>>> End "for reference".
>>>>
>>>>
>>>>
>>>> The above does not say the the loader and u-boot are using
>>>> a 1.8 V mode instead of a 3.3V mode of operation for the
>>>> sdcard interface, even if 1.8V is possible.
>>>
>>> It doesn't, see
>>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts#L151
>>>
>>> Again, 1.8V is in theory possible, but I wouldn't try that on my
>>> boards.
>>
>> So it looks like if the e.MMC on an adapter card were to be supported,
>> it would be via Bit 1 or Bit 0 below, much like u-boot is apparently
>> doing.
>>
>>>> From an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be
>>>> any of (for 3V):
>>>>
>>>> Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V
>>>> Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device voltage(s)"
>>>> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device voltage(s)"
>>>>
>>>> that match up with one of the sdcard 3.3V modes:
>>>>
>>>> UHS-I modes:
>>>> DS: Default Speed up to 25 MHz 3.3V signaling
>>>> HS: High Speed up to 50 MHz 3.3V signaling
>>>> (Looks like the signal timings are distinct from 1.8 V modes.)
>>>>
>>>> So not bit 2 if 3V, unsure about the other two bits for 3V.
>>>>
>>>> In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1
>>>> UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does
>>>> boot from) the kernel seems to pick the UHS-I HS mode,
>>>> instead of SDR50 or DDR50 or higher:
>>>
>>> Because SDR50 or DDR50 needs 1.8V signaling.
>>> So the maximum mode that we can select is HS at 50Mhz which is
>>> using 3.3V signaling.
>>
>> Okay. It would be nice if the e.MMC on an sdcard adapter also did so
>> someday, somewhat like u-boot apparently does (up to clock rate
>> differences?). Even going slower, I'd prefer e.MMC media.
>>
>>>> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
>>>> aw_mmc0: vmmc-supply regulator found
>>>> mmc0: <MMC/SD bus> on aw_mmc0
>>>> random: harvesting attach, 8 bytes (4 bits) from mmc0
>>>> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
>>>> simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
>>>> simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat allwinner,sun50i-a64-emmc (no driver attached)
>>>> . . .
>>>> aw_mmc0: Powering up sd/mmc
>>>> mmc0: Probing bus
>>>> . . .
>>>> mmc0: SD 2.0 interface conditions: OK
>>>> mmc0: SD probe: OK (OCR: 0x40ff8000)
>>>> mmc0: Current OCR: 0x00ff8000
>>>> mmc0: Probing cards
>>>> mmc0: New card detected (CID 0353445345333247800978130301171d)
>>>> mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3)
>>>> mmc0: Card at relative address 0xaaaa added:
>>>> mmc0:  card: SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD
>>>> mmc0:  quirks: 0
>>>> mmc0:  bus: 4bit, 50MHz (high speed timing)
>>>> mmc0:  memory: 62333952 blocks, erase sector 8192 blocks
>>>> mmc0: setting transfer rate to 50.000MHz (high speed timing)
>>>> mmcsd0: 32GB <SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD> at mmc0 50.0MHz/4bit/32768-block
>>>> random: harvesting attach, 8 bytes (4 bits) from mmcsd0
>>>> GEOM: new disk mmcsd0
>>>> mmc0: setting bus width to 4 bits high speed timing
>>>> mmc0: ACMD42 failed, RESULT: 4
>>>> mmc0: Card at relative address 43690 failed to set bus width
>>>>
>>>>
>>
>
>
> Just to see what a modern linux with a modern kernel
> might do I downloaded:
>
> https://dl.armbian.com/pine64/Ubuntu_bionic_dev_nightly.7z
>
> which is:
>
> nightly mainline kernel master branch 4.17.y or 4.18.y
>
> # uname -ap
> Linux pine64 4.18.0-rc4-sunxi64 #220 SMP Sun Jul 15 14:16:31 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
>
> I put it on an e.MMC and used it to boot the pine64+ 2GB
> via the e.MMC adapter and it booted fine.
>
> # cat /sys/kernel/debug/mmc0/ios
> clock:          52000000 Hz
> actual clock:   50000000 Hz
> vdd:            21 (3.3 ~ 3.4 V)
> bus mode:       2 (push-pull)
> chip select:    0 (don't care)
> power mode:     2 (on)
> bus width:      2 (4 bits)
> timing spec:    8 (mmc DDR52)
> signal voltage: 0 (3.30 V)
> driver type:    0 (driver type B)
>
> # hdparm -t /dev/mmcblk0
>
> /dev/mmcblk0:
> Timing buffered disk reads: 134 MB in  3.04 seconds =  44.03 MB/sec
>
> # hdparm -T /dev/mmcblk0
>
> /dev/mmcblk0:
> Timing cached reads:   1298 MB in  2.00 seconds = 649.15 MB/sec
>
> For interpreting those (-t vs. -T):
>
> QUOTE
>       -t     Perform timings of device reads for benchmark and comparison purposes.  For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other
>              active  processes)  with  at  least a couple of megabytes of free memory.  This displays the speed of reading through the buffer cache to the disk without any prior caching of data.
>              This measurement is an indication of how fast the drive can sustain sequential data reads under Linux, without any filesystem overhead.  To ensure accurate measurements, the  buffer
>              cache is flushed during the processing of -t using the BLKFLSBUF ioctl.
>
>       -T     Perform  timings of cache reads for benchmark and comparison purposes.  For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other
>              active processes) with at least a couple of megabytes of free memory.  This displays the speed of reading directly from the Linux buffer cache without disk access.  This measurement
>              is essentially an indication of the throughput of the processor, cache, and memory of the system under test.
> END QUOTE
>
> So it appears to me that the DDR52 over 4 data bits is real,
> despite the apparent 3.3V usage for VCCQ (and so VCC as well).
>
> In other words: they are using e.MCC CARD_TYPE/DEVICE_TYPE bit 2:
>
> Bit 2: High-speed DDR MultimediaCard @ (at most) 52 MHz - 1.8aV or 3V I/O
>
> and were not restricted to just the microSDHC speed and I/O voltage
> combinations by the Pine64+ 2GB.

I discovered another command:

# mmc extcsd read /dev/mmcblk0 | more
=============================================
  Extended CSD rev 1.8 (MMC 5.1)
=============================================
. . .
Card Type [CARD_TYPE: 0x57]
 HS200 Single Data Rate eMMC @200MHz 1.8VI/O
 HS Dual Data Rate eMMC @52MHz 1.8V or 3VI/O
 HS eMMC @52MHz - at rated device voltage(s)
 HS eMMC @26MHz - at rated device voltage(s)
. . .

Which is interesting by having 5 bits set in 0x57
but only listing 4 of the alternatives. The missing
one would be for:

HS400 DDR e.MMC @ 200 MHz - 1.8V I/O

(In essence, no 1.2V alternative is supported.)

It did not pick to attempt a 1.8V-only mode but
instead to pick the fastest of the 3V-compatibile
modes (in e.MCC terms).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"