Closed humanoid2050 closed 3 years ago
humanoid2050
commented
3 years ago No success as of yet. I noted that the dunfell kernel config is missing an emmc option compared to zeus.
CONFIG_PWRSEQ_EMMC=m
CONFIG_PWRSEQ_SIMPLE=mEnabling those modules (along with dependent flags) did not solve the issue.
It's definitely something in the kernel/initrd though, as reflashing just the boot partition with zeus make the SD card accessible again.
htot
commented
3 years ago I don't remember exactly if there was an issue or not. I am working here: https://github.com/htot/meta-intel-edison (gatesgarth branch). There don't seem to be any SD card related commits there.
I have seen that sometimes on boot the SD card interface was locked up. A power cycle fixed that.
But I have Edison-Arduino board (SD card on the board). And you have Sparkfun block. Does that connect to spi bus? How does kernel know? ACPI?
ferry@chromium:~$ ssh root@edison.local
Last login: Mon Aug 30 22:47:12 2021 from 192.168.178.47
root@edison:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 14.7G 0 disk
mmcblk1 179:0 0 1.8G 0 disk
mmcblk0 179:8 0 3.6G 0 disk
|-mmcblk0p1 179:9 0 2M 0 part
|-mmcblk0p2 179:10 0 1M 0 part
|-mmcblk0p3 179:11 0 2M 0 part
|-mmcblk0p4 179:12 0 1M 0 part
|-mmcblk0p5 179:13 0 1M 0 part /factory
|-mmcblk0p6 179:14 0 24M 0 part
|-mmcblk0p7 179:15 0 64M 0 part
`-mmcblk0p8 259:0 0 3.5G 0 part /lib/modules
mmcblk0boot0 179:16 0 4M 1 disk
mmcblk0boot1 179:24 0 4M 1 disk root@edison:~# uname -a
Linux edison 5.14.0-rc1-edison-acpi-standard #1 SMP Sun Jul 11 22:07:40 UTC 2021 x86_64 x86_64 x86_64 GNU/Linuxroot@edison:~# cat /etc/os-release
ID=poky-edison
NAME="Poky (Yocto Project Reference Distro)"
VERSION="3.2.3 (gatesgarth)"
VERSION_ID=3.2.3
PRETTY_NAME="Poky (Yocto Project Reference Distro) 3.2.3 (gatesgarth)"root@edison:~# journalctl -b 0 | grep mmc1
kernel: mmc1: SDHCI controller on PCI [0000:00:01.2] using ADMA
kernel: mmc1: new high speed SD card at address e624
kernel: mmcblk1: mmc1:e624 SU02G 1.84 GiB Maybe related to https://github.com/edison-fw/meta-acpi/commit/a7f59cf4662b49d640b2ece7678c03bc5a45c746 This adds mmc support to acpi tables since gatesgarth. Question is, how did it work then before in Zeus?
humanoid2050
commented
3 years ago The Sparkfun board uses the dedicated SD pins exposed on the 70 pin connector (mmc1). Only thing inline is a bidirectional voltage level translator. I don't think SPI is related here. That looks like it might be for arduino breakout boards that have a microSD card on the SPI bus. Are there any pin-muxing configs for the Edison? That's usually where I would start looking next on ARM boards.
htot
commented
3 years ago Edison-Arduino schematic here:https://www.intel.com/content/dam/support/us/en/documents/edison/sb/edison_arduino_hvm_8_26.pdf SD card on page 8. It's probably on the same pins as in your case. I believe those are SPI and need the ACPI table for configuring. But I don't know with which kernel version that started.
humanoid2050
commented
3 years ago Looks like the schematics are functionally the same. Different part for the voltage level shift, but that's about it.
The SD interface and an SPI interface do seem to share some commonalities. In fact, it sounds like SD cards can be operated with a 1bit bus interface in a special SPI mode. Normally though, SD interfaces use a 4bit bus.
Both zeus and dunfell configs have CONFIG_MMC_SPI, unset as built. But that doesn't inherently rule out anything.
I will dig through for other SPI changes, and try the gatesgarth branch when I'm back in front of my regular computer tomorrow.
htot
commented
3 years ago The SD interface and an SPI interface do seem to share some commonalities. In fact, it sounds like SD cards can be operated with a 1bit bus interface in a special SPI mode. Normally though, SD interfaces use a 4bit bus.
Correct.
Both zeus and dunfell configs have CONFIG_MMC_SPI, unset as built. But that doesn't inherently rule out anything.
I trying to figure out what changed exactly. But it may be that some platform code was eliminated in a certain kernel and requires the acpi table to configure the SD card.
htot
commented
3 years ago You are right we are using the sdhci controller on the pci bus. And for some reason the SD card insertion is not detected. What happens if you reinsert the SD card?
andy-shev
commented
3 years ago SPI should not have anything to do about this. This, AFAIU, pure SDHCI connection. Only what I can thing about of is the kernel configuration. Have you altered it in some way?
htot
commented
3 years ago I just did a quick test (that is easy to reproduce) with Dunfell on edison-arduino with micro SD card and it worked fine. This what I did:
bmaptool)reboot sdhc (I had a running linux supporting this, but else just reboot and interrupt with <ESC> and in U-Boot type run edsboot, it's the same)What does this do:
root@edison:~# mount -t ext4
/dev/mmcblk1 on / type ext4 (rw,relatime)
/dev/mmcblk0p5 on /factory type ext4 (rw,nosuid,nodev,noatime,discard,x-systemd.automount)root@edison:~# mount -t btrfs
/dev/mmcblk0p8 on /home type btrfs (rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/,x-systemd.automount)
root@edison:~# ls /home
@ @boot @home @modules rootroot@edison:~# pwd
/rootThings to note:
bmaptool complains "WARNING: all 1.0 GiB are mapped, no holes in 'edison-image-edison.ext4'", probably due to 7zip unzipping. ~Would anybody know how to prevent that?~ Edit: I just found that fallocate -d edison-image-edison.ext4 punches holes to make the file sparse again, this make flashing the SD card 40% faster, in my case 3min vs 5.From my journal:
root@edison:~# journalctl -b -k | grep -i mmc | grep -v mmc2
kernel: Command line: quiet tty1 console=ttyS2,115200n8 root=/dev/mmcblk1 rootfstype=ext4 systemd.unit=multi-user.target hardware_id=${hardware_id}
kernel: Kernel command line: quiet tty1 console=ttyS2,115200n8 root=/dev/mmcblk1 rootfstype=ext4 systemd.unit=multi-user.target hardware_id=${hardware_id}
kernel: PCI: MMCONFIG for domain 0000 [bus 00-00] at [mem 0x3f500000-0x3f5fffff] (base 0x3f500000)
kernel: PCI: MMCONFIG at [mem 0x3f500000-0x3f5fffff] reserved in E820
kernel: acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-00] only partially covers this bridge
kernel: mmc0: SDHCI controller on PCI [0000:00:01.0] using ADMA
kernel: mmc1: SDHCI controller on PCI [0000:00:01.2] using ADMA
kernel: mmc1: new high speed SD card at address e624
kernel: mmc0: new DDR MMC card at address 0001
kernel: mmcblk1: mmc1:e624 SU02G 1.84 GiB
kernel: mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8
kernel: BTRFS: device fsid 597e7e68-035a-46af-a777-24f4ac6a6c37 devid 1 transid 184475 /dev/mmcblk0p8 scanned by udevd (87)
kernel: FAT-fs (mmcblk0p7): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
kernel: EXT4-fs (mmcblk0p5): mounted filesystem without journal. Opts: (null)
kernel: ext4 filesystem being mounted at /run/media/mmcblk0p5 supports timestamps until 2038 (0x7fffffff)
kernel: BTRFS info (device mmcblk0p8): disk space caching is enabled
kernel: BTRFS info (device mmcblk0p8): has skinny extents
kernel: BTRFS info (device mmcblk0p8): enabling ssd optimizations
kernel: EXT4-fs (mmcblk1): mounted filesystem with ordered data mode. Opts: (null)
kernel: EXT4-fs (mmcblk1): mounted filesystem with ordered data mode. Opts: (null)
kernel: BTRFS info (device mmcblk0p8): turning on sync discard
kernel: BTRFS info (device mmcblk0p8): disk space caching is enabled
kernel: BTRFS info (device mmcblk0p8): has skinny extents
kernel: BTRFS info (device mmcblk0p8): enabling ssd optimizations
kernel: EXT4-fs (mmcblk1): resizing filesystem from 482816 to 482816 blocks
kernel: EXT4-fs (mmcblk0p5): mounted filesystem without journal. Opts: discardThanks everyone for the input.
@andy-shev I started out trying to get the UVC module building, but reverted to the upstream code when I found this issue. I tried making some changes to fix this, like enabling the following configs to match zeus
CONFIG_OF=y
CONFIG_PWRSEQ_EMMC=m
CONFIG_PWRSEQ_SIMPLE=mbut that was unsuccessful.
@htot Removing and reinserting the SD card produces output for zeus, but not dunfell.
I tried gatesgarth, identical to dunfell in all respects. (except for node.js adding 30 minutes to my build time. Lol)
For some reason, U-Boot doesn't detect the SD card either. Never has.
I took another look at the edison/arduino board schematic. I noticed that the Card Detect line is connected via resistor to 1.8V in that diagram. The card socket shorts the line to ground when a card is inserted, resulting in a digital logic signal. On my SD card board, the pin is not connected to 1.8V. I'm wondering if zeus had a GPIO configuration set to internally tie the pin high, independent of the external circuit. Does this kind of hardware configuration ring a bell? I'm not sure where to look for that.
htot
commented
3 years ago After further testing I have to correct myself: At least with 5.14 on edison-arduino, card detect is not working run time. When before reboot a card is plugged, it is detected during boot. This may be a regression in the kernel.
(except for node.js adding 30 minutes to my build time. Lol)
I found that (with new MoBo) that with 8 cores + ht building Node requires 5 x 4GB during linking, while I have 16GB. Disk thrashing then is so bad mouse won't move. So for node I restricted parallel build here.
humanoid2050
commented
3 years ago Disk thrashing then is so bad mouse won't move.
Ouch. I touched about 18GB 35GB total usage, with 16 cores + ht.
I've been looking around. Is this perhaps an ACPI configuration issue? I have a vague notion of how to do these kinds of things with Device Trees, but this is new territory for me.
andy-shev
commented
3 years ago @humanoid2050 Thanks for the report, btw. I think you found a regression. Can I use your name/email in order to add Reported-by tags to the patch(es)?
So far you may try the preliminary ones, which I published in my U-Boot and kernel repositories (@htot knows already which ones are needed).
htot
commented
3 years ago @andy-shev has just pushed patches, he is asking us to test. At first glance I think support for card detect was once proposed using hard coded gpio pin and never merged. And apparently it was not needed until the SFI support in the kernel got dropped. Suggested patches to kernel bind to acpi table in U-Boot. So fix needs both change to U-Boot as well as kernel.
I will sort out and add to Gatesgarth.
Question is if we want to backport also to Dunfell. Not sure when official support for Dunfell ends and if it's worth it.
In the meanwhile, have you considered joining (low traffic) Telegram group "Intel Edison"?
humanoid2050
commented
3 years ago @andy-shev
Thanks for the report, btw. I think you found a regression. Can I use your name/email in order to add Reported-by tags to the patch(es)?
Do you need a real name or just my username and associated email?
@htot I can certainly do some testing. Which repos/branches should I be working from?
andy-shev
commented
3 years ago Thanks for the report, btw. I think you found a regression. Can I use your name/email in order to add Reported-by tags to the patch(es)?
Do you need a real name or just my username and associated email?
Real name and email. This is how Linux kernel contribution requires it (you may sent me it in private, but I don't see much sense to hide since it becomes public anyway). It's fine if you don't want to, I can drop any mention or credits. I just realized that I will add the link to this report anyway. So, up to you.
humanoid2050
commented
3 years ago I think I'm fine keeping my internet anonymity. Thanks though.
andy-shev
commented
3 years ago andy-shev
commented
3 years ago Read also comment against kernel patch. Needs more testing.
htot
commented
3 years ago I pushed https://github.com/htot/meta-intel-edison/commit/aacc5a0c2fe7b0a2b1e53d6dceb8fb0fb5830ddf on top of Gatesgarth. It modifies both U-Boot and linux. I have tested on edison-arduino and found it works. Please test.
humanoid2050
commented
3 years ago Just pulled the latest, built it, and flashed it. No success.
I have been looking at some other errors, including this one which seems related to the GPIO chip. Not sure if this is relevant.
Loading acpi tables
[ 3.904424] pca953x i2c-INT3491:00: failed writing register
[ 3.942501] pca953x i2c-INT3491:01: failed writing register
[ 3.970000] pca953x i2c-INT3491:02: failed writing register
[ 4.008233] pca953x i2c-INT3491:03: failed writing register
gpioset: at least one GPIO line offset to value mapping must be specified
gpioset: at least one GPIO line offset to value mapping must be specifiedI can post a full dmesg dump if that's helpful, or anything else.
andy-shev
commented
3 years ago Because of 2 we have either PCB to fix, i.e. by adding one transistor and couple of resistors on board to invert the signal, or create a completely separate kernel for that.
Or use GpioIo() in U-Boot and create two different U-Boot images.
Last possibility is to tell that the module is broken.
What puzzles me is what was the difference between Zeus and Dunfell in terms of handling SD card detect GPIO that covers both cases...
humanoid2050
commented
3 years ago @andy-shev I don't think the SparkFun board is an inverted signal. According to the schematic, GP77 will be shorted to ground when the card is inserted. This is the same as what happens on the edison-arudino board. The difference is what happens when no card is present. On the SparkFun board, the signal is left floating, unless the Edison itself is made to use an internal pull-up in its GPIO interface. The edison-arduino board actually puts not one, but two pull-up resistors on the line. The first is in the TXS0206-29, and the second is the dedicated resistor R45 on the edison-arduino board itself.
This leads to an interesting thought. In the event that the board is supplied power with the SD card already inserted, the input to GP77 should be 0V, regardless of the board. There would be no digital logic event to detect, just "it's already connected".
So that gets back to your question about the difference between zeus and dunfell. If it is purely an ACPI issue, then why did zeus U-Boot not detect the SD card, while Zeus kernel did? I know at least at one point U-Boot could see the SD card, unfortunately I don't recall if that was only on the original Intel software, or a pre-zeus build from this project. I have had my Edison since it came out, and it's been in and out of the spare parts drawer a few times over the years.
htot
commented
3 years ago 1. You are not supposed to load Edison/Arduino tables on non-Arduino board.That is true. And those that are loaded are listed here. You may want to load other tables, depending on your board configuration or connected devices.
htot
commented
3 years ago So that gets back to your question about the difference between zeus and dunfell. If it is purely an ACPI issue, then why did zeus U-Boot not detect the SD card, while Zeus kernel did?
Without patched U-Boot (2021.04 but I believe there is no significant change from the Zeus version) I see that U-Boot could see the SD card with ls mmc 1:1 or ls mmc 1:0 depending how disk is formatted (with or without partitions). Maybe U-Boot doesn't care about the state of CD line?
Linux 5.6 kernel in Zeus handles CD via SFI support, which got removed entirely before 5.10 iirc. But apparently booting Linux from the SD card, the card remains detected.
humanoid2050
commented
3 years ago I appreciate the work you guys are doing on this issue. Is there anything I can do to help here? I'm way out of my usual knowledge base so I feel pretty useless.
htot
commented
3 years ago Yes, please test again with the tables here removed.
But it would also be good to see the result of `ls mmc 1:1 or ls mmc 1:0 in U-Boot. I booted without card inserted, typed the command, get correct error, then insert card, type command again and get file listing. Then, removing the card, type the command again, get timeouts. So, U-Boot does not handle card removes well, but card inserts should be ok.
humanoid2050
commented
3 years ago might have gone a bit overboard on the data collection...
Gatesgarth, acpi tables removed:
Inital UBooot startup, no SD card present
******************************
PSH KERNEL VERSION: b0182b2b
WR: 20104000
******************************
SCU IPC: 0x800000d0 0xfffce92c
PSH miaHOB version: TNG.B0.VVBD.0000000c
microkernel built 11:24:08 Feb 5 2015
******* PSH loader *******
PCM page cache size = 192 KB
Cache Constraint = 0 Pages
Arming IPC driver ..
Adding page store pool ..
PagestoreAddr(IMR Start Address) = 0x04899000
pageStoreSize(IMR Size) = 0x00080000
*** Ready to receive application ***
U-Boot 2021.04 (Apr 05 2021 - 15:03:29 +0000)
CPU: Genuine Intel(R) CPU 4000 @ 500MHz
DRAM: 980.6 MiB
WDT: Started with servicing (60s timeout)
MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0mmc probing
=> mmc list
mmc@ff3fc000: 0 (eMMC)
mmc@ff3fa000: 1
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc dev 1
Card did not respond to voltage select! : -110
=> ls mmc 1:0
Card did not respond to voltage select! : -110
=> ls mmc 1:1
Card did not respond to voltage select! : -110insert SD card, reprobe
=> mmc list
mmc@ff3fc000: 0 (eMMC)
mmc@ff3fa000: 1
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc dev 1
MMC: no card present
=> ls mmc 1:0
MMC: no card present
=> ls mmc 1:1
MMC: no card presentproceed to kernel with run do_boot
=> run do_boot
Flashing already done...
10399808 bytes read in 448 ms (22.1 MiB/s)
11663207 bytes read in 504 ms (22.1 MiB/s)
Valid Boot Flag
Magic signature found
Linux kernel version 5.14.0-edison-acpi-standard (oe-user@oe-host) #1 SMP Sun Aug 29 22:04:50 UTC 2021
Building boot_params at 0x00090000
Loading bzImage at address 100000 (10385472 bytes)
Initial RAM disk at linear address 0x06000000, size 25165824 bytes
Kernel command line: "quiet root=/dev/mmcblk0p8 rootfstype=ext4 console=ttyS2,115200n8 earlyprintk=ttyS2,115200n8,keep loglevel=4 systemd.unit=multi-user.target hardware_id=00"
Kernel loaded at 00100000, setup_base=00090000
Starting kernel ...
[ 2.784665] Initramfs unpacking failed: invalid magic at start of compressed archive
Scanning for Btrfs filesystems
Starting version 246.9+
Kernel with acpi enabled detected
Loading acpi tables
gpioset: at least one GPIO line offset to value mapping must be specified
gpioset: at least one GPIO line offset to value mapping must be specified
Waiting for root device /dev/mmcblk0p8
Found device '/run/media/mmcblk0p8'
Init found, booting...
mount: can't find /boot in /etc/fstab
mount: mounting /boot on /realroot/boot failed: Invalid argument
mount: can't find /lib/modules in /etc/fstab
mount: mounting /lib/modules on /realroot/lib/modules failed: Invalid argument
[ 7.931403] systemd[1]: Failed to start Set timezone by geolocation service.
[FAILED] Failed to start Set timezone by geolocation service.
[ 9.484191] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2
[ 9.822295] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2
[ 9.859669] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 9.934980] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43340/2 wl0: Aug 29 2019 05:13:37 version 6.10.190.78 (r722178) FWID 01-e7bd1c9f
Poky (Yocto Project Reference Distro) 3.2.4 edison ttyS2
edison login:dmesg output, collapsed for brevity:
Dunfell, acpi tables removed, kernel config for CONFIG_PWRSEQ_EMMC enabled The CONFIG_PWRSEQ_EMMC flag is set in zeus, but not by default in dunfell. It's presence caused no discernable change in the dunfell behavior.
Inital UBooot startup, no SD card present
******************************
PSH KERNEL VERSION: b0182b2b
WR: 20104000
******************************
SCU IPC: 0x800000d0 0xfffce92c
PSH miaHOB version: TNG.B0.VVBD.0000000c
microkernel built 11:24:08 Feb 5 2015
******* PSH loader *******
PCM page cache size = 192 KB
Cache Constraint = 0 Pages
Arming IPC driver ..
Adding page store pool ..
PagestoreAddr(IMR Start Address) = 0x04899000
pageStoreSize(IMR Size) = 0x00080000
*** Ready to receive application ***
U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)
CPU: Genuine Intel(R) CPU 4000 @ 500MHz
DRAM: 980.6 MiB
WDT: Started with servicing (60s timeout)
MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0mmc probing
=> mmc list
mmc@ff3fc000: 0 (eMMC)
mmc@ff3fa000: 1
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc dev 1
Card did not respond to voltage select! : -110
=> ls mmc 1:0
Card did not respond to voltage select! : -110
=> ls mmc 1:1
Card did not respond to voltage select! : -110insert SD card, reprobe
=> mmc list
mmc@ff3fc000: 0 (eMMC)
mmc@ff3fa000: 1
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc dev 1
MMC: no card present
=> ls mmc 1:0
MMC: no card present
=> ls mmc 1:1
MMC: no card presentproceed to kernel with run do_boot
dmesg output from dunfell
zeus, acpi tables removed, UVC kernel module enabled
Inital UBooot startup, no SD card present
******************************
PSH KERNEL VERSION: b0182b2b
WR: 20104000
******************************
SCU IPC: 0x800000d0 0xfffce92c
PSH miaHOB version: TNG.B0.VVBD.0000000c
microkernel built 11:24:08 Feb 5 2015
******* PSH loader *******
PCM page cache size = 192 KB
Cache Constraint = 0 Pages
Arming IPC driver ..
Adding page store pool ..
PagestoreAddr(IMR Start Address) = 0x04899000
pageStoreSize(IMR Size) = 0x00080000
*** Ready to receive application ***
U-Boot 2020.10 (Sep 12 2021 - 13:33:00 +0000)
CPU: Genuine Intel(R) CPU 4000 @ 500MHz
DRAM: 980.6 MiB
WDT: Started with servicing (60s timeout)
MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0mmc probing
=> mmc list
mmc@ff3fc000: 0 (eMMC)
mmc@ff3fa000: 1
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc dev 1
Card did not respond to voltage select!
=> ls mmc 1:0
Card did not respond to voltage select!
=> ls mmc 1:1
Card did not respond to voltage select!insert SD card, reprobe
=> mmc list
mmc@ff3fc000: 0 (eMMC)
mmc@ff3fa000: 1
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc dev 1
MMC: no card present
=> ls mmc 1:0
MMC: no card present
=> ls mmc 1:1
MMC: no card presentproceed to kernel with run do_boot
=> run do_boot
Flashing already done...
9771808 bytes read in 422 ms (22.1 MiB/s)
9555937 bytes read in 414 ms (22 MiB/s)
Valid Boot Flag
Setup Size = 0x00003800
Magic signature found
Using boot protocol version 2.0f
Linux kernel version 5.6.0-edison-acpi-standard (oe-user@oe-host) #1 SMP Sun Sep 12 13:33:31 UTC 2021
Building boot_params at 0x00090000
Loading bzImage at address 100000 (9757472 bytes)
Magic signature found
Initial RAM disk at linear address 0x06000000, size 25165824 bytes
Kernel command line: "quiet root=/dev/mmcblk0p8 rootfstype=ext4 console=ttyS2,115200n8 earlyprintk=ttyS2,115200n8,keep loglevel=4 systemd.unit=multi-user.target hardware_id=00"
Magic signature found
Starting kernel ...
[ 2.409358] Initramfs unpacking failed: invalid magic at start of compressed archive
Scanning for Btrfs filesystems
Starting version 243.2+
Kernel with acpi enabled detected
Loading acpi tables
gpioset: at least one GPIO line offset to value mapping must be specified
gpioset: at least one GPIO line offset to value mapping must be specified
Waiting for root device /dev/mmcblk0p8
Found device '/run/media/mmcblk0p8'
Init found, booting...
mount: can't find /boot in /etc/fstab
mount: mounting /boot on /realroot/boot failed: Invalid argument
mount: can't find /lib/modules in /etc/fstab
mount: mounting /lib/modules on /realroot/lib/modules failed: Invalid argument
[ 10.764909] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2
[ 11.032245] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43340-sdio for chip BCM43340/2
[ 11.118745] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 11.211420] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43340/2 wl0: Oct 23 2017 08:41:23 version 6.10.190.70 (r674464) FWID 01-98d71006
Poky (Yocto Project Reference Distro) 3.0.4 edison ttyS2
edison login:dmesg output, note the events at the end corresponding to the detection SD card insertion in this one
htot
commented
3 years ago Interestingly in your case, without card inserted U-Boot says "Card did not respond to voltage select!", with card "MMC: no card present". So, it does note the difference.
Also, not related, your eMMC reports "mmcblk0: mmc0:0001 H4G1d\x04 3.64 GiB", I don't have that line at all.
But I think you are right, you seem to need a pull up on the cd line.
I don't really understand the acpi language syntax, but the pin is defined here. And while @andy-shev is on a holiday I thought to try to change PullNone to PullUp. And that has already been done in the patch we apply to U-Boot: https://github.com/htot/meta-intel-edison/blob/aacc5a0c2fe7b0a2b1e53d6dceb8fb0fb5830ddf/meta-intel-edison-bsp/recipes-bsp/u-boot/files/0001-x86-tangier-acpi-Add-GPIO-card-detection-to-SDHCI-2.patch#L35
But it appears not to help you. Would you have to possibility to solder a pull-up resistor?
humanoid2050
commented
3 years ago I am hesitant to start soldering on this board. I have no spares for any of my Edison components.
I am currently poking through the commit history, looking to bisect it until I find out which commit exactly between zeus and dunfell changed things (im guessing either the kernel or acpi updates).
I also thought I saw somewhere in the code a flag setting the pin mode to ACTIVE_HIGH or something like that. Does that ring a bell with you? The messages from U-Boot sort of imply that it is mixed up between which signal state indicates the presence or absence of the card. I.e. why make a message about the card not responding to a voltage select operation if the card is physically missing, and why instantly indicate that the card is not present when in reality it is plugged in? I'd like to find and change that as a test.
htot
commented
3 years ago I am currently poking through the commit history, looking to bisect it until I find out which commit exactly between zeus and dunfell changed things (im guessing either the kernel or acpi updates)
Must be kernel, as this was never controlled by acpi up to now.
The messages from U-Boot sort of imply that it is mixed up between which signal state indicates the presence or absence of the card.
As if inverted, like @andy-shev suggested.
If you want to test, @andy-shev suggested changing this line to false.
andy-shev
commented
3 years ago I don't think the SparkFun board is an inverted signal. According to the schematic, GP77 will be shorted to ground when the card is inserted.
Can you confirm this by checking the actual level with multimeter? Because it seems to me that the design of the slot is that CD connected to the shield (both of them) when there is no card present. This seems visible from the top of the connector.
The difference is what happens when no card is present. On the SparkFun board, the signal is left floating, unless the Edison itself is made to use an internal pull-up in its GPIO interface.
This is depends on firmware and in U-Boot we never changed that settings.
This leads to an interesting thought. In the event that the board is supplied power with the SD card already inserted, the input to GP77 should be 0V, regardless of the board. There would be no digital logic event to detect, just "it's already connected".
It shouldn't be a problem if the initial state is undefined and software tries to detect it with other means. (See mmc_rescan() for the details).
So that gets back to your question about the difference between zeus and dunfell. If it is purely an ACPI issue, then why did zeus U-Boot not detect the SD card, while Zeus kernel did? I know at least at one point U-Boot could see the SD card, unfortunately I don't recall if that was only on the original Intel software, or a pre-zeus build from this project. I have had my Edison since it came out, and it's been in and out of the spare parts drawer a few times over the years.
Can you post the output of grep gpio /proc/interrupts on the working case?
htot
commented
3 years ago | As I understand we have the following cases: | < U-Boot 21.04 | U-Boot 21.04 | U-Boot 21.04 + DT patches | Linux v5.6 | Linux >= v5.10 | Linux v5.14 + ACPI patches | |
|---|---|---|---|---|---|---|---|
| Sparkfun | N | N | N | Y | N | N | |
| Edison-Arduino | ? | Y | Y | Y | N | Y |
With Edison-Arduino at a certain U-Boot version we could load the kernel and initrd from SD card, but I don't know exactly when then started. When I found support for the SD card I added btrfs support to U-Boot (2020.01) along already supported fat and ext4. And proper support to env scripts in 2020.04.
@andy-shev are you expecting to see an interrupt being used with v5.6? I will check.
Could be seeing a switch bounce effect? We have both edge interrupt, which explain why we see an inversion.
htot
commented
3 years ago I put Zeus image from here on SD card, then booted the SD card.
root@edison:~# uname -a
Linux edison 5.6.0-edison-acpi-standard #1 SMP Sat Dec 19 17:06:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@edison:~# grep gpio /proc/interrupts
271: 0 0 gpio-merrifield 15 i2c-INT3491:00
333: 0 0 gpio-merrifield 77 sd_cd
441: 0 2 gpio-merrifield 185 host_wake
root@edison:~# gpioinfo | grep "line 77"
line 77: unnamed "sd_cd" input active-high [used]
root@edison:~# cat /sys/kernel/debug/pinctrl/INTC1002\:00/pinconf-pins | grep SD_
pin 37 (GP77_SD_CD): input bias pull up, slew rate (0)
pin 38 (GP78_SD_CLK): input bias pull down, slew rate (0)
pin 39 (GP79_SD_CMD): input bias pull up, slew rate (0)
pin 40 (GP80_SD_D0): input bias pull up, slew rate (0)
pin 41 (GP81_SD_D1): input bias pull up, slew rate (0)
pin 42 (GP82_SD_D2): input bias pull up, slew rate (0)
pin 43 (GP83_SD_D3): input bias pull up, slew rate (0)
pin 44 (GP84_SD_LS_CLK_FB): input bias pull down, slew rate (0)
pin 45 (GP85_SD_LS_CMD_DIR): input bias pull down, slew rate (0)
pin 46 (GP86_SD_LVL_D_DIR): input bias pull down, slew rate (0)
pin 47 (GP88_SD_LS_SEL): input bias pull down, slew rate (0)
pin 48 (GP87_SD_PD): input bias pull down, slew rate (0)
pin 49 (GP89_SD_WP): input bias pull down, slew rate (0)So while here did the same with unpatched 5.12 kernel
root@yuna:~# uname -a
Linux yuna 5.12.0-edison-acpi-standard #1 SMP Sun Apr 25 20:49:08 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
root@yuna:~# grep gpio /proc/interrupts
271: 0 0 gpio-merrifield 15 i2c-INT3491:00
441: 0 2 gpio-merrifield 185 host_wake
root@yuna:~# gpioinfo | grep "line 77"
line 77: unnamed unused input active-high
root@yuna:~# cat /sys/kernel/debug/pinctrl/INTC1002\:00/pinconf-pins | grep SD_
pin 37 (GP77_SD_CD): input bias pull up, slew rate (0)
pin 38 (GP78_SD_CLK): input bias pull down, slew rate (0)
pin 39 (GP79_SD_CMD): input bias pull up, slew rate (0)
pin 40 (GP80_SD_D0): input bias pull up, slew rate (0)
pin 41 (GP81_SD_D1): input bias pull up, slew rate (0)
pin 42 (GP82_SD_D2): input bias pull up, slew rate (0)
pin 43 (GP83_SD_D3): input bias pull up, slew rate (0)
pin 44 (GP84_SD_LS_CLK_FB): input bias pull down, slew rate (0)
pin 45 (GP85_SD_LS_CMD_DIR): input bias pull down, slew rate (0)
pin 46 (GP86_SD_LS_D_DIR): input bias pull down, slew rate (0)
pin 47 (GP88_SD_LS_SEL): input bias pull down, slew rate (0)
pin 48 (GP87_SD_PD): input bias pull down, slew rate (0)
pin 49 (GP89_SD_WP): input bias pull down, slew rate (0)And with ACPI patched 5.14.0:
root@yuna:~# uname -a
Linux yuna 5.14.0-edison-acpi-standard #1 SMP Sun Aug 29 22:04:50 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
root@yuna:~# grep gpio /proc/interrupts
271: 0 0 gpio-merrifield 15 i2c-INT3491:00
333: 0 0 gpio-merrifield 77 0000:00:01.2 cd
441: 0 2 gpio-merrifield 185 host_wake
root@yuna:~# gpioinfo | grep "line 77"
line 77: unnamed "cd" input active-low [used]
root@yuna:~# cat /sys/kernel/debug/pinctrl/INTC1002\:00/pinconf-pins | grep SD_
pin 37 (GP77_SD_CD): input bias pull up, slew rate (0)
pin 38 (GP78_SD_CLK): input bias pull down, slew rate (0)
pin 39 (GP79_SD_CMD): input bias pull up, slew rate (0)
pin 40 (GP80_SD_D0): input bias pull up, slew rate (0)
pin 41 (GP81_SD_D1): input bias pull up, slew rate (0)
pin 42 (GP82_SD_D2): input bias pull up, slew rate (0)
pin 43 (GP83_SD_D3): input bias pull up, slew rate (0)
pin 44 (GP84_SD_LS_CLK_FB): input bias pull down, slew rate (0)
pin 45 (GP85_SD_LS_CMD_DIR): input bias pull down, slew rate (0)
pin 46 (GP86_SD_LS_D_DIR): input bias pull down, slew rate (0)
pin 47 (GP88_SD_LS_SEL): input bias pull down, slew rate (0)
pin 48 (GP87_SD_PD): input bias pull down, slew rate (0)
pin 49 (GP89_SD_WP): input bias pull down, slew rate (0)If debugfs is telling the truth, biasing is the same in all cases. And interrupt configured the same for 5.6.0 (unpatched) and 5.14.0 (with ACPI patches). The same patched U-Boot was used in all cases. Finally "cd" is active low in 5.14.0 while "sc_cd" was active high in 5.6.0.
humanoid2050
commented
3 years ago If you want to test, @andy-shev suggested changing this line to false.
SUCCESS FROM GATESGARTH KERNEL!
The ACPI tables line is also commented out in meta-intel-edison-bsp/conf/machine/edison.conf, and U-Boot doesn't work yet, but this is a significant discovery.
I'm still going to test the board electrically and see whats going on with the CD line and try to fill in some of the other outstanding questions, but I wanted to share this immediately.
humanoid2050
commented
3 years ago I have done a little probing with the multimeter. I appears that the uSD socket used on the SparkFun board is a "normally closed" type. So when no card is present, the CD pin is shorted to ground. This is internal to the socket, and not specified in any way on the SparkFun Schematic. I'm guessing the Edison-Arduino board uses the opposite type. I didn't even know that both types existed.
In practical terms, I'm not sure what this means. Does this translate into a different set of ACPI tables that must be built and loaded for SparkFun boards?
htot
commented
3 years ago As @andy-shev wrote:
Because of 2 we have either PCB to fix, i.e. by adding one transistor and couple of resistors on board to invert the signal, or create a completely separate kernel for that. Or use GpioIo() in U-Boot and create two different U-Boot images. Last possibility is to tell that the module is broken.
I would prefer, if there are hardware specific things to put them in U-Boot, preferably in the ACPI table (the 3rd option).
I just checked the Sparkfun schematics history on github (they had card detect initially wrong, it is 2 equal CD pins, normally connected to GND) and compared with Molex connector on Edison-arduino (2 floating pins normally open). These switches are not part of the SD card specification...
But:
What puzzles me is what was the difference between Zeus and Dunfell in terms of handling SD card detect GPIO that covers both cases...
So, it appears there can be 1 code to solve both cases.
One way might be to mark mechanical card detect as broken, and use electrical detection (there is a pull up inside the SD card on CMD3/CD on plug). That might require polling the SD card. @andy-shev might know what to do when he returns from holiday.
andy-shev
commented
3 years ago The IRQ routines are different on those two cases. So, the problem may be work around pretty much in the kernel. Nevertheless, U-Boot must be updated anyway to reflect the actual CD pin in the tables. So, there is a v3 of the patch in U-Boot mailing list.
htot
commented
3 years ago ~Unless interrupt completely disabled and~ Maybe the 5.6.0 kernel polls the card periodically regardless of an interrupt occurs.
humanoid2050
commented
3 years ago Would it be possible to detect changes to the CD line, and then chain that to a software probe for the card state? That way it doesn't matter what the line state changes to, it just matters that a change is registered.
andy-shev
commented
3 years ago I will check the possibilities when come back from vacations.
htot
commented
3 years ago I checked the SD card physical layer spec (v1.01) and this is what I find:
CD/DAT3 (pin 1 of the SD/MMC card: After power up this line is input with 50KOhm pull-up (can during be used for card detection or SPI mode selection). The pull-up should be disconnected by the user, during regular data transfer, with SET_CLR_CARD_DETECT command.
This is not the switch on the card holder but the pin on the SD card itself.
Three different card detect mechanisms are defined for the SD Memory Card (e.g. mechanical insertion which can be sensed using the WP switch, Electrical insertion which can be sensed using the pull-up resistor on DAT3 and periodical attempts to initialize the card). Since some of these methods may be not relevant (or behave differently) for the MultiMediaCard, it is recommended not to depend on the preemptive card detects methods only. The host should implement a polling mechanism or allow the operator to request card identification.
What I get from this, detection through WP switch and CD/DAT3 are supplementary and the main method should be polling. But current spec is v8.0 so things might have changed since.
andy-shev
commented
3 years ago @htot, the only difference between the code of ISRs I have found so far is this line
host->trigger_card_event = true;
You may try to comment it out and see if this makes any difference in your (Edison/Arduino) case. But it might help with SparkFun one. @humanoid2050 care to test (set back override to true)?
humanoid2050
commented
3 years ago reverting the cd_override_level change and commenting out the line
host->trigger_card_event = true;in
drivers/mmc/core/slot-gpio.cresults in the original, non-functional, behavior on gatesgarth. From a code perspective, zeus hadhost->trigger_card_event = true;as well.
andy-shev
commented
3 years ago in
drivers/mmc/core/slot-gpio.cresults in the original, non-functional, behavior on gatesgarth.
Hmm... This is basically the only thing I can think of. May be debounce parameter is not set correctly? You may try to print the value of the parameter that is supplied in IRQ handler.
From a code perspective, zeus had
host->trigger_card_event = true;as well.
Yes, but that part of the code is not exercised by the old approach.
htot
commented
3 years ago Hmm... This is basically the only thing I can think of. May be debounce parameter is not set correctly? You may try to print the value of the parameter that is supplied in IRQ handler.
With the new kernel and your patches each card insert / remove gives exactly 1 interrupt. With the old kernel I have seen up to 5. I would say debounce is set correct with the new kernel.
andy-shev
commented
3 years ago Okay, we have no ->card_event() defined, or at least it has no reaction on card insertion / removal. That's why trigger_card_event doesn't affect anything. Inside mmc_rescan() the ->get_cd() is called (which is slightly different for SDHCI) and compared to 0. And the latter returns 0 or 1 depends on the actual GPIO value with cd_override_level taken into consideration.
Due to PCB bug on SparkFun, we may not use that (and I dunno [*] how at all we got it working in one or the other case, i.e. Edison/Arduino vs. SparkFun) approach. The best solution is to fix PCB. The software solutions all seems hacks to me (mark CD brokem -- no go, enable polling -- doesn't seem right, fixing U-Boot on per board -- not an option, ...).
So, I have no idea what to do, and honestly I do not want to fix SparkFun's PCB mistake in software (so far the least worse approach is to enable polling). Any ideas?
[*]: As @htot mentioned the old approach generates bunch of IRQs and maybe due to that we got it working.
htot
commented
3 years ago Poll card on positive and negative interrupts only (vs. time based)?
humanoid2050
commented
3 years ago @htot That's kind of what I was thinking. The important thing is that a change has occurred. The cost of explicitly checking the new state should not be incurred very often that way.
After building and flashing dunfell, the SD card does not work. I tried btrfs/non-btrfs, and debian/non-debian variants. In all cases, the SD card (attached via a Sparkfun microSD block) does not appear in the output of
lsblkorls /dev. The output of dmesg indicates that the kernel is detecting the hardware on some level, but not the card itself.Reverting to the zeus branch and rebuilding causes the sd card to appear without hardware changes.
Rebuilding dunfell brings back the issue.