9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Mack Wallace <mackbw@mapinternet.com>
To: 9front@9front.org
Subject: Re: [9front] pi 400 and cm4 mmc issues
Date: Sat, 13 Nov 2021 19:22:31 +0000	[thread overview]
Message-ID: <0100017d1ac052b7-c200f69d-3501-4cdc-a2b8-2fd80b37dbf2-000000@email.amazonses.com> (raw)
In-Reply-To: <CAHwi9by3D4vGJ4O+kgQ0goJA+nVr73+a1Qi1FP2FGAmrf44VsQ@mail.gmail.com>

(Sorry if this is a repeat, I forgot to make sure my message was plain text)

So I applied the patch to bcm/emmc.c and port/sdmmc.c, changed the config in emmc to use emmc for sdmmc rather than sdhc. - just in case it was that stupid simple as I am stupid. Apparently not.

After some searching I came upon the following:

A thread that starts to discuss 'Differences between SD card and eMMC access (CM4)?' https://forums.raspberrypi.com/viewtopic.php?t=293966
but is not very conclusive. However, it does have a reverence to a bare metal driver that the originator of the thread wrote in C++ https://github.com/rsta2/circle/blob/master/addon/SDCard/emmc.cpp 

Another individual was looking to be able to use both the eMMC and an SD card in this thread: https://forums.raspberrypi.com/viewtopic.php?t=288772 

If I understand correctly, the same EMMC2 controller is used for either the eMMC or the microSD card. One could reroute the older SDHOST which is still on the silicon to run the microSD, but then other things would be precluded… I don’t think any of that is a concern.

In emmc.cpp, there are logs of pre-compiler directive conditionals. But from what I think I understand (which I could be completely wrong), there are not many differences between using the EMMC and an SD card. (I’m assuming the USE_SDHOST directive refers to using the older SD controller). Looks like there are some minor command changes and chunks of code that are bypassed (like checking on properties of an SD card). I had started to try to compare what is in emmc.cpp with sdhc.c. Some of the defines and structures line up nicely, but I was having issues lining up the commands (i.e. CEMMCDevice::sd_commands[] and cmdinfo[64] ). 

Hope some of my babble is useful.

mackbw

…The following may have been thrown out of the mailing list as I probably did not make sure I was sending plain text.

> Begin forwarded message:
> 
> From: Mack Wallace <mackbw@mapinternet.com>
> Subject: Re: [9front] pi 400 and cm4 mmc issues
> Date: November 8, 2021 at 1:25:25 PM EST
> To: 9front@9front.org
> 
> I took the individual files from git and compiled them into a new kernel. I tried that kernel on a 4GB Pi400, an 8GB Raspberry Pi 4b, and a 1GB Pi Compute Module 4 (w/o eMMC) on the DFRobot mini router board. All were able to boot and mount the SD card with this change where previously one would boot, get errors, and not be able to mount the SD. So great catch cinap!
> 
> I did not expect any changes with a Compute Module 4 with eMMC as that is trying to boot from the eMMC and not the SD card. I tried anyway, and get the usual emmc: cmd 371a0000 arg 0 error intr 0 stat 1fff0001 that seems to indicate a missing SD card. 
> 
> I haven’t done extensive testing, but for the first three; Pi400, CM4 w/o eMMC, and 8BB PI4b; things seem to work - I can’t imagine the changes affecting much else. I have other problems (which I am sure others can affirm with pity and derision), but those are for another thread. 
> 
> Thank you!
> 
> mackbw


> On Nov 9, 2021, at 10:38 AM, Eli Cohen <echoline@gmail.com> wrote:
> 
> yo. I wrote a patch a while ago at
> https://raw.githubusercontent.com/echoline/9emmc/master/9emmc.patch
> 
> this was for the eMMC chips in the CM3+ to work (at all)
> 
> it does need more changes still... other machine architectures... it
> does not take buswidth (happy halloween!!!) into account, I wrote a
> lot of it just from looking at the linux kernel, etc...
> 
> be safe out there!
> 
> love,
> uppity 9fans
> 
> On Mon, Nov 8, 2021 at 1:54 PM <cinap_lenrek@felloff.net> wrote:
>> 
>> nice.
>> 
>> makes sense.
>> 
>> anyone with a cm4 != 1GB (with eMMC)?
>> 
>> we'd definitely need to adjust port/sdmmc.c code to deal with eMMC cards,
>> but it shouldnt be too difficult.
>> 
>> one can find the JDEC standard for eMMC in duckduckgo.
>> 
>> --
>> cinap
> 


  parent reply	other threads:[~2021-11-13 19:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-06  3:18 cinap_lenrek
2021-11-06 14:31 ` joseph turco
2021-11-06 17:12   ` cinap_lenrek
2021-11-08  9:45 ` cinap_lenrek
2021-11-08 18:25   ` Mack Wallace
2021-11-08 21:49     ` cinap_lenrek
2021-11-09 15:38       ` Eli Cohen
2021-11-09 19:17         ` cinap_lenrek
2021-11-13 18:57         ` Mack Wallace
2021-11-13 19:22         ` Mack Wallace [this message]
2021-11-14  5:34           ` cinap_lenrek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0100017d1ac052b7-c200f69d-3501-4cdc-a2b8-2fd80b37dbf2-000000@email.amazonses.com \
    --to=mackbw@mapinternet.com \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).