BBB & IMX6 Hummingboard SDIO driver

[Russell Haley]

On Fri, Jul 21, 2017 at 12:31 PM, Ilya Bakulin <ilya at bakulin.de> wrote:
> On 21.07.17 01:08, Russell Haley wrote:
>
>> In an effort to eliminate as many of MY errors as possible, I copied a
>> BB snapshot image from July 17. Once that successfully booted and I
>> had an ip address and written an echo to file, I replaced the kernel
>> with a BEAGLEBONE-MMCCAM kernel. I did not see the same results as I
>> did with my own image built using an older revision, so I am
>> discarding my kernel panic for now. The snapshot with a
>> BEAGELBONE-MMCCAM kernel (r321242) doesn't panic, but it fails to
>> mount the second slice on mmcsd0s2. My complete "lots of freakin
>> output" (you weren't kidding) is here: https://pastebin.com/CrWYPZtv
>>
>> For completeness sake I created a standard BEAGELBONE kernel and
>> installed it and everything booted fine.
>>
>> Cheers,
>>
>> Russ
>>
> MMCCAM creates the device named sdda0, not mmcsd0.
> To make the life easier just create a GEOM label for the mmcsd0s2 and
> change /etc/fstab to mount the partition by label instead of device name.
> Then the system will do the right thing (c) no matter what MMC stack you
> use.
>
> Thank you for testing the MMCCAM-enabled kernel, I appreciate this.

Progress update:
- I worked with Ian to try and get rootfs working, but am too
ham-fisted (or it's broken but I think he had it working) to get that
working.
- I tried adding options     ROOTDEVNAME=\"ufs:sdda0s2a\" first to the
BEAGELBONE-MMCCAM conf file but the BEAGLEBONE settings won out, so I
commented out options     ROOTDEVNAME=\"ufs:mmcsd0s2\" from the
BEAGLEBONE file
- The unit finally booted but ran extremely poorly due to the debug
output. Ian helped me shut that off using sysctl ... (didn't write it
down argh!). the system ran between 9 and 20% in a nominal state.
- Once debug was turned off, the system ran at 0.4% in a nominal
state. I attempted various fs related things including (groan)
downloading ports and accidentally turning the system off while it was
writing to disk! fsck recovered the slice.
- My observation is that it's slow. I have no concrete data (yet) and
quite possibly have forgotten how slow Arm and SD cards really are. I
have hesitated to add your patch as I do want to test in various
states to collect data (i.e. regular BBB kernel, MMCCAM kernel, MMCCAM
kernel with changes).

All in all I have had the hardest time trying to get working dtrace
examples. I  have contacted gnn about being unable to compile the
TeachBSD course. Perhaps someone has a working copy of the TeachBSD
presentation available?

Thanks,

Russell