search

armbian / build

Armbian Linux build framework generates custom Debian or Ubuntu image for x86, aarch64, riscv64 & armhf
https://www.armbian.com
GNU General Public License v2.0
4.01k stars 2.26k forks source link

Add support for CB2-2Card (Cubieboard 2 with two cards) #114

Closed dllud closed 8 years ago

dllud commented 8 years ago

There is a version of Cubieboard 2 which brings an additional micro-SD slot instead of the NAND memory. This slot is named BOOT while the other is the DATA slot. Armbian does not run on CB2-2Card if the card is inserted in the BOOT slot. It runs flawlessly from the DATA slot but does not detect cards inserted in the BOOT slot. It would be great if either: a) Armbian could run from the BOOT slot and detect cards on the DATA slot - preferable. b) Armbian could run from the DATA slot and detect cards on the BOOT slot.

I have one CB2-2Card and can take the time to do all the testing that you need.

zador-blood-stained commented 8 years ago

It would be helpful to see:

dllud commented 8 years ago

I have no 3.3V UART-USB dongle. I'll try to get one and come back with the reading soon.

Running system with two cards plugged. Bootable in DATA and another card in BOOT. The card in BOOT is not detected:

# ls /dev/mmc*
/dev/mmcblk0  /dev/mmcblk0p1

# dmesg | grep mmc
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    1.940539] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    1.941009] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    1.976765] sunxi-mmc 1c0f000.mmc: base:0xf0160000 irq:26
[    2.023536] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.025962] mmc0: new high speed SDHC card at address b368
[    2.026493] mmcblk0: mmc0:b368       7.45 GiB 
[    2.028019]  mmcblk0: p1
[    2.436878] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    7.193909] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro
zador-blood-stained commented 8 years ago

Hmm. Since there is no DeviceTree binding for second card in mainline kernel it shouldn't be detected, now that I thought of it. now that I think of it. Old kernel needs it enabled in .fex/.bin file too.

dllud commented 8 years ago

There's a distro called Cubian X1 which can't boot from the BOOT card but is able to boot from the DATA card and detect cards in the BOOT slot (good enough). It uses the following fex: cubieboard2_argon.fex. The relevant part seems to be:

[card0_boot_para]
card_ctrl = 0
card_high_speed = 1
card_line = 4
sdc_d1 = port:PF00<2><1><default><default>
sdc_d0 = port:PF01<2><1><default><default>
sdc_clk = port:PF02<2><1><default><default>
sdc_cmd = port:PF03<2><1><default><default>
sdc_d3 = port:PF04<2><1><default><default>
sdc_d2 = port:PF05<2><1><default><default>

[card2_boot_para]
card_ctrl = 2
card_high_speed = 1
card_line = 4
sdc_cmd = port:PC06<3><1><default><default>
sdc_clk = port:PC07<3><1><default><default>
sdc_d0 = port:PC08<3><1><default><default>
sdc_d1 = port:PC09<3><1><default><default>
sdc_d2 = port:PC10<3><1><default><default>
sdc_d3 = port:PC11<3><1><default><default>

Also, I found some documentation on the official Cubieboard download site: http://dl.cubieboard.org/model/cubieboard2-dualcard/ There is a cubieez README which points to several git repos like: cubieboard/linux-sdk-card-tools. There's also a cubieez image which boots from the BOOT card.

All these use the old kernel though. I could find nothing for mainline kernel.

zador-blood-stained commented 8 years ago

I don't think that any image that boots from one slot will boot from another without changing kernel command line (rootfs=/dev/mmcblk0p1) and /etc/fstab, but we need to get kernel support first. I'll extract fex from cubian to check its config.

zador-blood-stained commented 8 years ago

We are talking here about old kernel, right? I ported mmc* values to armbian cubieboard2.fex and compiled ti, please try replacing cubieboard2.bin file in /boot or /boot/bin (I don't remember) with file from this archive, I can't attach it here.

dllud commented 8 years ago

Nope. I am using mainline kernel. But I am testing your version for the old kernel, I'm coming back with results in 10 min. Meanwhile, can you also make a try on mainline kernel?

zador-blood-stained commented 8 years ago

I can try enabling it with default values, but I have no idea if it will be safe for attached uSD card...

dllud commented 8 years ago

Working on old kernel. It boots from the DATA slot and is able to read cards in the BOOT slot.

# ls /dev/mmc*
/dev/mmcblk0  /dev/mmcblk0p1  /dev/mmcblk1  /dev/mmcblk1p1

I tried mounting an ext4 partition and it worked good. I think this can be added to the next release. :smiley:

As for mainline kernel I have some spare cards I can use for testing. Send the files and lets see how it goes.

zador-blood-stained commented 8 years ago

I'll try to find values to missing DT parameters before posting anything, I think power supply and card detection are sensitive enough to not leave them empty. In fex file I enabled 3 remaining of 4 total mmc sections (mmc0 was enabled already obviously), I think it's a good idea disabling back not used sections.

dllud commented 8 years ago

@zador-blood-stained Which parameters are you looking for? Can you post an example (e.g. from some other board)? This way I may be able to help you finding them.

zador-blood-stained commented 8 years ago

I have all what I need, I was looking in wrong place before. I just need some time to build this thing from kernel source tree.

zador-blood-stained commented 8 years ago

https://dl.dropboxusercontent.com/u/5385968/sun7i-a20-cubieboard2.dtb

dllud commented 8 years ago

Thanks @zador-blood-stained Not working though. Replaced it on /boot/dtb/sun7i-a20-cubieboard2.dtb After reboot no card is detected on the BOOT slot (nothing on dmesg either). Also cannot boot from the BOOT slot.

zador-blood-stained commented 8 years ago

No new mmc entries in dmesg at all compared to default dtb? Can you dump or archive contents of /proc/device-tree?

dllud commented 8 years ago

dmesg: nothing new, just the card on the DATA slot.

# dmesg | grep mmc
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    1.923529] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    1.923995] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    1.956850] sunxi-mmc 1c0f000.mmc: base:0xf0162000 irq:26
[    1.957254] sunxi-mmc 1c11000.mmc: No vqmmc regulator found
[    1.957881] sunxi-mmc: probe of 1c11000.mmc failed with error -16
[    2.003585] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.006011] mmc0: new high speed SDHC card at address b368
[    2.006538] mmcblk0: mmc0:b368       7.45 GiB 
[    2.008093]  mmcblk0: p1
[    2.417834] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    6.983724] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro

Device tree dump: ls -R -l /sys/firmware/devicetree/base

zador-blood-stained commented 8 years ago

You can't say that there is nothing new...

[    1.923529] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    1.957254] sunxi-mmc 1c11000.mmc: No vqmmc regulator found
[    1.957881] sunxi-mmc: probe of 1c11000.mmc failed with error -16

Second address is for mmc2 from device tree. And there is an error for mmc2. I believe -16 is BUSY error, so question is - what exactly is busy... maybe GPIO...

/sys/firmware/devicetree/base/soc@01c00000/mmc@01c11000
/sys/firmware/devicetree/base/soc@01c00000/mmc@01c0f000

what is in status in these sysfs nodes?

dllud commented 8 years ago

You're right, sorry :S. I missed the second address (1c11000).

# cat /sys/firmware/devicetree/base/soc@01c00000/mmc@01c11000/status
okay

# cat /sys/firmware/devicetree/base/soc@01c00000/mmc@01c0f000/status
okay
zador-blood-stained commented 8 years ago

Can you pastebin full dmesg, maybe it has something useful?

dllud commented 8 years ago

Here it is: http://pastebin.com/XgpESa73

dllud commented 8 years ago

(Long shot) I was doing some cats around sysfs nodes and noticed that the binary files look a bit different:

# cat /sys/firmware/devicetree/base/soc@01c00000/mmc@01c0f000/*
ahbmmcoutputsampleallwinner,sun5i-a13-mmc mmcdefault��okay

# cat /sys/firmware/devicetree/base/soc@01c00000/mmc@01c11000/*
ahbmmcoutputsample
allwinner,sun5i-a13-mmc"mmc default�okay

Don't know if it has any meaning.

zador-blood-stained commented 8 years ago

It is normal - they are using different GPIOs

zador-blood-stained commented 8 years ago

Please try recompiling kernel adding #define DEBUG before `

include <linux/device.h>todrivers/mmc/core/host.canddrivers/mmc/host/sunxi-mmc.c`. This should get us some useful info.

zador-blood-stained commented 8 years ago

Also please try new dtb: https://dl.dropboxusercontent.com/u/5385968/dtb_new/sun7i-a20-cubieboard2.dtb

dllud commented 8 years ago

With the new dtb things are still the same.

# dmesg | grep mmc
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    1.901272] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    1.901731] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    1.936638] sunxi-mmc 1c0f000.mmc: base:0xf054e000 irq:26
[    1.937055] sunxi-mmc 1c11000.mmc: No vqmmc regulator found
[    1.937634] sunxi-mmc: probe of 1c11000.mmc failed with error -16
[    1.983412] mmc0: host does not support reading read-only switch, assuming write-enable
[    1.985833] mmc0: new high speed SDHC card at address b368
[    1.986344] mmcblk0: mmc0:b368       7.45 GiB 
[    1.987883]  mmcblk0: p1
[    2.397480] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    6.820838] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro

# cat /sys/firmware/devicetree/base/soc@01c00000/mmc@01c11000/status
okay

# cat /sys/firmware/devicetree/base/soc@01c00000/mmc@01c0f000/status
okay

I'm compiling the kernel and will get back with results soon. (I'm having some trouble with the scripts which are overwriting my modifications to the C files. I've commented fetch_from_github "$LINUXKERNEL" "$LINUXSOURCE" "$LINUXDEFAULT" on main.sh but there seems to be something else updating the repo.)

Edit: The culprit must be patching_sources also on main.sh. I'm compiling without it and see how it goes.

zador-blood-stained commented 8 years ago

I believe you need to disable force_checkout option in compile.sh. Another way is enabling kernel_configure and making changes to source while kernel configuration menu is active. Either way it is totally possible that ported sunxi-mmc driver wasn't designed to work with multiple sd cards, and this problem with necessary logs and device tree changes should be redirected to kernel maintainers who ported this driver.

dllud commented 8 years ago

It was the patching, that's where drivers/mmc files come from. I was able to compile the kernel by commenting all fetch_from_github and patching_sources from main.sh (I had all sources already in good shape from a previous compilation).

I've now installed the freshly compiled kernel debs, copied your latest dtb over and rebooted. This is the output of dmesg | grep mmc. It's all about 1c0f000, which is the card in use. No sign of 1c11000, grep -r --ignore-case "1c11000" /var/log returns nothing. But it seems to be around:

# cat /sys/firmware/devicetree/base/soc@01c00000/mmc@01c11000/status
okay
zador-blood-stained commented 8 years ago

There are no initial commands. It is a ring buffer and first part of it got overwritten. You need to increase kmsg buffer or really get a hold onto a serial adapter. 5v is fine too if you connect only gnd to gnd and cubie2 tx to adapter rx. It's 1:30 am local time, I will try to look more closely at sources tomorrow.

dllud commented 8 years ago

Jeezzz, thanks for all the effort you've been putting into this @zador-blood-stained !

I recompiled the kernel with CONFIG_LOG_BUF_SHIFT set to 24 (a 16 MiB buffer). Now I was able to get the initialization commands. However the debug output doesn't bring anything new:

# dmesg | grep mmc
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    1.931431] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    1.931884] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    1.932088] sunxi-mmc 1c0f000.mmc: power on!
[    1.946512] sunxi-mmc 1c0f000.mmc: setting clk to 400000, rounded 400000
[    1.966708] sunxi-mmc 1c0f000.mmc: base:0xf015e000 irq:26
[    1.966842] sunxi-mmc 1c0f000.mmc: cmd 52(80000174) arg c00 ie 0x0000bbc6 len 0
[    1.967160] sunxi-mmc 1c11000.mmc: No vqmmc regulator found
[    1.967655] sunxi-mmc 1c0f000.mmc: irq: rq ee891e58 mi 00000100 idi 00000000
[    1.967680] sunxi-mmc 1c0f000.mmc: irq: rq ee891e58 mi 00000004 idi 00000000
[    1.967728] sunxi-mmc 1c0f000.mmc: cmd 52(80000174) arg 80000c08 ie 0x0000bbc6 len 0
[    1.967806] sunxi-mmc: probe of 1c11000.mmc failed with error -16
[    1.968538] sunxi-mmc 1c0f000.mmc: irq: rq ee891e58 mi 00000100 idi 00000000
[    1.968559] sunxi-mmc 1c0f000.mmc: irq: rq ee891e58 mi 00000004 idi 00000000
[    1.968621] sunxi-mmc 1c0f000.mmc: setting clk to 400000, rounded 400000
[    1.969674] sunxi-mmc 1c0f000.mmc: cmd 0(80008000) arg 0 ie 0x0000bbc6 len 0
[    1.970056] sunxi-mmc 1c0f000.mmc: irq: rq ee891e68 mi 00000004 idi 00000000

It then continues forever, but there are no more references to 1c11000.

I'm grabbing my Arduino Duemilanove which has a FTDI FT232RL USB-to-TTL Serial configured to 5V. Let's see if I can read anything from the serial console.

dllud commented 8 years ago

After all it was easier than I thought. I just had to take out the microcontroller and connect Arduino's RX (pin 0) to Cubie's RX, and TX (pin 1) to TX. However the serial console output is just the same as what appears on the screen. There's not much to help you out.

The most interesting output appears when turning on the Cubie with a bootable card on the BOOT slot:

U-Boot SPL 2015.07-armbian+ (Oct 10 2015 - 00:02:26)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
MMC: no card present
spl: mmc init failed with error: -16
### ERROR ### Please RESET the board ###

We get the same error code (-16) as in the kernel. Thus, it seems U-Boot SPL and mainline kernel are trying to start the BOOT slot in the same erroneous way.

When booting from a card in the DATA slot, with or without some other card in the BOOT slot, the output is the same:

U-Boot SPL 2015.07-armbian+ (Oct 10 2015 - 00:02:26)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2

U-Boot 2015.07-armbian+ (Oct 10 2015 - 00:02:26 +0100) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0

*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst 
Net:   eth0: ethernet@01c50000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found

Hit any key to stop autoboot:  2  1  0 

6944 bytes read in 272 ms (24.4 KiB/s)
RLE Bitmap unsupported in video mode 0xea000016
bmp - manipulate BMP image data
Usage:
bmp info <imageAddr>          - display image info
bmp display <imageAddr> [x y] - display image at x,y
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
1973 bytes read in 332 ms (4.9 KiB/s)
## Executing script at 43100000
0 bytes read in 251 ms (0 Bytes/s)
27303 bytes read in 716 ms (37.1 KiB/s)
5467888 bytes read in 871 ms (6 MiB/s)
Kernel image @ 0x46000000 [ 0x000000 - 0x536ef0 ]
## Flattened Device Tree blob at 49000000
   Booting using the fdt blob at 0x49000000
   Using Device Tree in place at 49000000, end 49009aa6

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Debian GNU/Linux 8 cubieboard2 ttyS0
cubieboard2 login:

Is there any other useful output I may be able to get you with the serial console?

PS. I don't understand one thing in the boot process. How is it possible that the Initial Program Loader (IPL) is able to read the SPL from the BOOT sdcard and then SPL fails to read U-Boot? For IPL to read SPL the card must be correctly initialized already (voltages applied, etc.). What does SPL do to break it?

zador-blood-stained commented 8 years ago

I don't pretend to fully understand boot process, but initial boot is done by CPU(A20 in our case) itself. It initializes hardware SD and NAND controllers and tries to find and boot SPL and U-boot with it. But u-boot is universal loader and it still needs to know about specific hardware configuration. TL;DR u-boot has its own device tree and it needs to be patched too. The error you see with card in BOOT slot - u-boot is already loaded, but it it knows only about mmc0 card, and not about mmc2.

zador-blood-stained commented 8 years ago

Please compile kernel replacing this in drivers\mmc\host https://dl.dropboxusercontent.com/u/5385968/sunxi-mmc.c You don't need previous debug defines. Dmesg with these changes will be extremely useful.

dllud commented 8 years ago

Here it is:

# dmesg | grep mmc
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    1.930792] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    1.930887] sunxi-mmc 1c0f000.mmc: No errors, requesting threaded irq
[    1.931167] sunxi-mmc 1c0f000.mmc: Resource requested OK
[    1.931281] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    1.966719] sunxi-mmc 1c0f000.mmc: base:0xf015e000 irq:26
[    1.967170] sunxi-mmc 1c11000.mmc: No vqmmc regulator found
[    1.967269] sunxi-mmc 1c11000.mmc: No errors, requesting threaded irq
[    1.967496] sunxi-mmc 1c11000.mmc: Resource requested OK
[    1.967573] sunxi-mmc 1c11000.mmc: Error in mmc_of_parse
[    1.967819] sunxi-mmc: probe of 1c11000.mmc failed with error -16
[    2.026665] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.029630] mmc0: new high speed SDHC card at address 8fe4
[    2.030154] mmcblk0: mmc0:8fe4 SU04G 3.69 GiB 
[    2.033348]  mmcblk0: p1
[    2.432819] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    6.582161] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro
zador-blood-stained commented 8 years ago

https://dl.dropboxusercontent.com/u/5385968/dts_fixed_gpio/sun7i-a20-cubieboard2.dtb

dllud commented 8 years ago

Working! 

# dmesg | grep mmc
[    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
[    1.930595] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    1.930708] sunxi-mmc 1c0f000.mmc: No errors, requesting threaded irq
[    1.930979] sunxi-mmc 1c0f000.mmc: Resource requested OK
[    1.931093] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    1.966705] sunxi-mmc 1c0f000.mmc: base:0xf015e000 irq:26
[    1.967110] sunxi-mmc 1c11000.mmc: No vqmmc regulator found
[    1.967209] sunxi-mmc 1c11000.mmc: No errors, requesting threaded irq
[    1.967437] sunxi-mmc 1c11000.mmc: Resource requested OK
[    1.967538] sunxi-mmc 1c11000.mmc: Got CD GPIO
[    2.006674] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.006707] sunxi-mmc 1c11000.mmc: base:0xf0162000 irq:27
[    2.009732] mmc0: new high speed SDHC card at address 8fe4
[    2.010369] mmcblk0: mmc0:8fe4 SU04G 3.69 GiB 
[    2.013131]  mmcblk0: p1
[    2.213710] mmc1: host does not support reading read-only switch, assuming write-enable
[    2.216132] mmc1: new high speed SDHC card at address b368
[    2.217720] mmcblk1: mmc1:b368       7.45 GiB 
[    2.219518]  mmcblk1: p1
[    2.450548] EXT4-fs (mmcblk0p1): INFO: recovery required on readonly filesystem
[    2.450589] EXT4-fs (mmcblk0p1): write access will be enabled during recovery
[    3.906915] EXT4-fs (mmcblk0p1): recovery complete
[    4.132390] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    8.391317] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro

I mounted the ext4 partition on /dev/mmcblk1p1 and was able to read and write to it. No issues so far.

On a fresh install, does one only need to paste the dtb or do we have to compile the kernel with your modified sunxi-mmc.c?

Again, thanks for all the effort you put into this!

Edit: Forget, I hadn't looked with due attention to your sunxi-mmc.c. It only has debug prints. Thus we just need the dtb.

dllud commented 8 years ago

Done some more testing and all seems good. I think your dts files are good to be added to @igorpecovnik build.

zador-blood-stained commented 8 years ago

To mount only dtb file is needed.

@igorpecovnik Patch for mainline:

diff -uNr linux-mainline.old/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts linux-mainline/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
--- linux-mainline.old/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ linux-mainline/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -142,6 +142,16 @@
    status = "okay";
 };

+&mmc2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc2_pins_a>, <&mmc2_cd_pin_cb2card>;
+   vmmc-supply = <&reg_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = <&pio 7 0 GPIO_ACTIVE_HIGH>; /* PH0 */
+   cd-inverted;
+   status = "okay";
+};
+
 &ohci0 {
    status = "okay";
 };
@@ -157,6 +167,13 @@
        allwinner,drive = <SUN4I_PINCTRL_10_MA>;
        allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
    };
+
+   mmc2_cd_pin_cb2card: mmc2_cd_pin@0 {
+       allwinner,pins = "PH0";
+       allwinner,function = "gpio_in";
+       allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+       allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+   };
 };

 &reg_ahci_5v {

Patch for legacy config (updated: disabled NAND since it is using same GPIOs):

--- cubieboard2.fex.old 2015-10-10 21:46:29.614735747 +0300
+++ cubieboard2.fex 2015-10-10 21:53:10.000000000 +0300
@@ -330,7 +330,7 @@
 ;nand flash configuration
 ;-------------------------------------------------------------------------------
 [nand_para]
-nand_used           = 1
+nand_used           = 0
 nand_we             = port:PC00<2><default><default><default>
 nand_ale            = port:PC01<2><default><default><default>
 nand_cle            = port:PC02<2><default><default><default>
@@ -845,8 +845,8 @@
 sdc_regulator       = "none"

 [mmc2_para]
-sdc_used            = 0
-sdc_detmode         = 3
+sdc_used            = 1
+sdc_detmode         = 1
 sdc_buswidth        = 4
 sdc_cmd             = port:PC06<3><1><2><default>
 sdc_clk             = port:PC07<3><1><2><default>
@@ -854,7 +854,7 @@
 sdc_d1              = port:PC09<3><1><2><default>
 sdc_d2              = port:PC10<3><1><2><default>
 sdc_d3              = port:PC11<3><1><2><default>
-sdc_det             =
+sdc_det             = port:PH0<0><1><default><default>
 sdc_use_wp          = 0
 sdc_wp              =
 sdc_isio            = 0

@dllud Compiling u-boot with this in /arch/arm/dts shoud help it detect card in this slot, but whether u-boot can properly deal with 2 available cards - it is another question...

igorpecovnik commented 8 years ago

https://github.com/igorpecovnik/lib/commit/dd8d68364e0430643ca1dc7b04e274951c703efa

Made a separate file for old kernel and build in into new one.

dllud commented 8 years ago

@zador-blood-stained Strangely the dts for u-boot is not working. I copied it to sources/u-boot/arch/arm/dts and compiled u-boot. At the end I made sure your file was still in there, it was not overwritten by anything coming from the repo. Then I copied linux-u-boot-next-cubieboard2_4.5_armhf.deb to the Cubie and proceeded with dpkg -i linux-u-boot-next-cubieboard2_4.5_armhf.deb. No errors were reported. However, when booting with the card in the BOOT slot I still get the following on serial console:

U-Boot SPL 2015.07-armbian (Oct 10 2015 - 20:47:17)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
MMC: no card present
spl: mmc init failed with error: -16
### ERROR ### Please RESET the board ###

@igorpecovnik I'm compiling it now from scratch to make sure everything is working as expected. Please remember to add a note to Armbian's Cubieboard 2 page to let people know Armbian supports the 2card version (I searched long for it).

zador-blood-stained commented 8 years ago

I looked at the source. It ignores device tree cd pin and uses config values. Try setting in u-boot .config CONFIG_MMC2_CD_PIN="PH0"

dllud commented 8 years ago

Nope :(. Still get the -16 error.

U-Boot .config was getting overwritten. I added sed -i 's/CONFIG_MMC2_CD_PIN=.*/CONFIG_MMC2_CD_PIN="PH0"/g' .config to compile_uboot in common.sh. At the end of compilation I checked .config and everything was in place:

CONFIG_MMC0_CD_PIN="PH1"
CONFIG_MMC1_CD_PIN=""
CONFIG_MMC2_CD_PIN="PH0"
CONFIG_MMC3_CD_PIN=""
CONFIG_MMC1_PINS=""
CONFIG_MMC2_PINS=""
CONFIG_MMC3_PINS=""
zador-blood-stained commented 8 years ago

Probably this is needed too. CONFIG_MMC_SUNXI_SLOT_EXTRA=2

dllud commented 8 years ago

Almost there! It now boots up the kernel but then the kernel hangs, showing no image on the screen. U-Boot says "mmc0 is current device", despite the card being inserted in the BOOT slot. Perhaps the kernel now needs a different device tree?

U-Boot SPL 2015.07-armbian (Oct 10 2015 - 22:11:52)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2

U-Boot 2015.07-armbian (Oct 10 2015 - 22:11:52 +0100) Allwinner Technology
CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 1, SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

HDMI connected: Setting up a 1024x768 hdmi console
Error: no valid bmp image at 66000000
In:    serial
Out:   vga
Err:   vga
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst 
Net:   eth0: ethernet@01c50000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0

scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 3 USB Device(s) found
scanning bus 3 for devices... 1 USB Device(s) found

Hit any key to stop autoboot:  2  1  0 

6944 bytes read in 272 ms (24.4 KiB/s)
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
1973 bytes read in 333 ms (4.9 KiB/s)
## Executing script at 43100000
0 bytes read in 251 ms (0 Bytes/s)
27039 bytes read in 716 ms (36.1 KiB/s)
5468392 bytes read in 771 ms (6.8 MiB/s)
Kernel image @ 0x46000000 [ 0x000000 - 0x5370e8 ]

## Flattened Device Tree blob at 49000000
   Booting using the fdt blob at 0x49000000
   Using Device Tree in place at 49000000, end 4900999e

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
zador-blood-stained commented 8 years ago

To get kernel messages in serial console you need to add console=/dev/ttyS0,115200 to bootargs in /boot/boot.cmd, and recompile it with mkimage. If kernel panics due to rootfs missing, try changing root=/dev/mmcblk0p1 with root=/dev/mmcblk1p1. Old sunxi-mmc driver had special boot related checks to ensure boot device always gets mmcblk0 node, new driver doesn't. If there are no console messages change loglevel=1 to loglevel=7 and add few zeros to terminal scrollback buffer size.

dllud commented 8 years ago

(Uffffff, finally finished testing everything.)

@igorpecovnik The build is working. Card on BOOT slot is now detected. This issue may now be closed depending on whichever you make of what I lay down below.

@zador-blood-stained @igorpecovnik Here is the panorama with zador's patched U-Boot.

Thus, if we wish to boot from BOOT card with the new sunxi-mmc driver, we have to: a) have a single bootable card in BOOT with root=/dev/mmcblk0p1; b) have a non-bootable card in DATA and a bootable card in BOOT with root=/dev/mmcblk1p1. This makes it difficult to create an image for CB2-2Card booting from BOOT: user would get a kernel panic just by inserting/taking out a card from the DATA slot.

IMHO the best option is to leave things as they are right now: kernel patched to detect both slots and U-Boot NOT patched. This way booting is only possible from DATA slot and root=/dev/mmcblk0p1 always works. The downside is: there must be a warning in Armbian's Cubieboard 2 page telling CB2-2Card owners to use the DATA slot for Armbian.

@zador-blood-stained I could by no means get kernel messages in serial console. /dev/ttyS0 at 115200 baud rate is right (tested it after booting) but it would never work. Only /dev/tty1, the screen, could show kernel messages. This doesn't matter much now, just letting you know. Thank you very much for all the time and effort you put into helping me out. Cheers!

zador-blood-stained commented 8 years ago

Theoretically you should be able to make your card bootable from both slots, Google "mount root by uuid", it's quite simple, but it can only be enabled by end users manually after first boot.

dllud commented 8 years ago

Yeah, well thought. But wait, can't you enable it by default? When you install Armbian you do a dd to the sdcard. Thus the ext4 partition uuid is kept the same. Later, on first boot, it is just resized right? That also keeps uuid intact. What am I missing?

zador-blood-stained commented 8 years ago

Hm. Or you can run lsblk from build script inside mounted image, parse its output and create boot.cmd and boot.scr on the fly...

dllud commented 8 years ago

Yup, with that your U-Boot patch could be included in Armbian with no severe side effects (no kernel panics) and would allow greater flexibility to users. Perhaps this is also useful on some other boards. Any thoughts @igorpecovnik?

igorpecovnik commented 8 years ago

I think we cover basic things if card is usable. I added text claiming support for dual SD card version. I also can add it to the u-boot but don't see much point in this. I hard to follow since I am doing severe testing and fixing of new release ...

Only this need to be added to u-boot CB2 config? CONFIG_MMC2_CD_PIN="PH0"