BBB & IMX6 Hummingboard SDIO driver

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

BBB & IMX6 Hummingboard SDIO driver

Russell Haley
Well more EBK (error behind keyboard). In the end I STILL didn't read
the entire command line in the
wiki. I missed the -E parameter for sudo, which preserves the
environment variables.

Ian remembered that he once added something to the sudoers file, which
got me to the next step, where I finally *saw* the missing sudo parameter
when reading the wiki entry for buildkernel. His more permanent
solution is to add a line via
visudo:

Defaults env_keep += "MAKEOBJDIRPREFIX MODULES_OVERRIDE SUBDIR_OVERRIDE"

which preserves the required variable of MAKEOBJDIRPREFIX.

He explains the other variables:
The other two vars are because I sometimes do a sudo make install with
SUBDIR_OVERRIDE= or MODULES_OVERRIDE= to get a quick partial install

Final build instructions:

*NOTE: My output all says hummingboard because I thought I was going
to build for that board first. I changed my mind at the last minute
and built for my BBB. I'm cross building on amd64 to a BBB.

setenv BASEDIR `pwd`
setenv MAKEOBJDIRPREFIX $BASEDIR/obj
cd $BASEDIR/src

svn checkout https://svn0.us-west.FreeBSD.org/base/head .


mkdir /mnt/memdisk
mkdir /mnt/uboot

truncate -s 1100M bbb.img #I think... I used 2048 because 1024 failed
sudo mdconfig -f bbb.img

gpart create -s mbr md0
gpart add -t fat32 -b 1M -s 50M md0
sudo newfs_msdos -F16 /dev/md0s1
gpart add -t freebsd md0
sudo newfs /dev/md0s2


make TARGET_ARCH=armv6 -j10 buildworld
make TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE-MMCCAM -j10 buildkernel

sudo mount_msdosfs /dev/md0s1 /mnt/uboot/
sudo mount /dev/md0s2 /mnt/memdisk/

#The -E is very important. It preserves the environment for sudo
sudo -E make TARGET_ARCH=armv6 DESTDIR=/mnt/memdisk installworld distribution
sudo -E make installkernel  TARGET_ARCH=armv6
KERNCONF=BEAGLEBONE-MMCCAM DESTDIR=/mnt/memdisk

cp ~/FreeBSD/hummingboard/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src/sys/boot/arm/uboot/ubldr
/mnt/uboot

#
cd ~/FreeBSD/hummingboard/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src
~/FreeBSD/hummingboard/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src%
cp ./sys/BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/am335x-boneblack.dtb
 /mnt/uboot/


cd /usr/ports/sysutils/u-boot-beaglebone/

make

cp work/u-boot-ports-v2017.01.00.2/MLO /mnt/uboot
cp work/u-boot-ports-v2017.01.00.2/u-boot.img /mnt/uboot

sudo umount /dev/md0s1
sudo umount /dev/md0s2
sudo mdconfig -du md0

sysctl kern.geom.debugflags=16
dd if=bbb.img of=/dev/da5 bs=4096k

total ufs size used: 948M

Thanks!
Russ

Now I need to find those silly little pins for the fdt cable. lolz

On Mon, Jul 17, 2017 at 5:15 PM, Russell Haley <[hidden email]> wrote:

> Sorry, I'm going to take the TARGET out and try again. It's not in the
> wiki entry for cross building.
>
> On Mon, Jul 17, 2017 at 1:57 PM, Russell Haley <[hidden email]> wrote:
>> My installworld is failing?
>>
>> Steps so far:
>> #Make a memdisk to speed things up
>> mkdir /mnt/memdisk
>> mkdir /mnt/uboot
>>
>> truncate -s 1024M bbb.img
>> sudo mdconfig -f bbb.img
>>
>> gpart create -s mbr md0
>> gpart add -t fat32 -b 1M -s 50M md0
>> newfs_msdos -F32 /dev/md0s1
>> gpart add -t freebsd md0
>> sudo newfs /dev/md0s2
>>
>> #build
>>
>> make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 -j10 buildworld
>> make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6
>> KERNCONF=BEAGLEBONE-MMCCAM -j10 buildkernel
>>
>> #install
>> sudo mount_msdosfs /dev/md0s1 /mnt/uboot/
>> sudo mount /dev/md0s2 /mnt/memdisk/
>> sudo make TARGET_ARCH=armv6 DESTDIR=/mnt/memdisk installworld distribution
>>
>> build error (full output is here: https://pastebin.com/VU3XDt5u):
>>
>> --------------------------------------------------------------
>>>>> Installing everything
>> --------------------------------------------------------------
>> cd /usr/home/russellh/FreeBSD/hummingboard/src; make -f Makefile.inc1
>> install
>> ===> lib (install)
>> ===> lib/csu (install)
>> ===> lib/csu/arm (install)
>> cc -target armv6-gnueabihf-freebsd12.0
>> --sysroot=/usr/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src/tmp
>> -B/usr/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src/tmp/usr/bin
>> -O -pipe -I/usr/home/russellh/FreeBSD/hummingboard/src/lib/csu/common
>> -I/usr/home/russellh/FreeBSD/hummingboard/src/lib/libc/include
>> -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
>> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
>> -Wnested-externs -Wredundant-decls -Wold-style-definition
>> -Wno-pointer-sign -Wthread-safety -Wno-empty-body -Wno-string-plus-int
>> -Wno-unused-const-variable  -Qunused-arguments
>> ERROR-tried-to-rebuild-during-make-install -mlong-calls -S -o crt1.s
>> /usr/home/russellh/FreeBSD/hummingboard/src/lib/csu/arm/crt1.c
>> /tmp/install.t1fF66Xy/sh: cc: not found
>> *** Error code 127
>>
>> Stop.
>> make[6]: stopped in
>> /usr/home/russellh/FreeBSD/hummingboard/src/lib/csu/arm
>> *** Error code 1
>>
>> Stop.
>> make[5]: stopped in
>> /usr/home/russellh/FreeBSD/hummingboard/src/lib/csu
>> *** Error code 1
>>
>> Stop.
>> make[4]: stopped in /usr/home/russellh/FreeBSD/hummingboard/src/lib
>> *** Error code 1
>>
>> Stop.
>> make[3]: stopped in /usr/home/russellh/FreeBSD/hummingboard/src
>> *** Error code 1
>>
>> Stop.
>> make[2]: stopped in /usr/home/russellh/FreeBSD/hummingboard/src
>> *** Error code 1
>>
>> Stop.
>> make[1]: stopped in /usr/home/russellh/FreeBSD/hummingboard/src
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /usr/home/russellh/FreeBSD/hummingboard/src
>>
>>
>>
>> Thanks,
>> Russ
>>
>> On Mon, Jul 17, 2017 at 11:39 AM, Russell Haley <[hidden email]> wrote:
>>> On Mon, Jul 17, 2017 at 11:34 AM, Ian Lepore <[hidden email]> wrote:
>>>> On Mon, 2017-07-17 at 11:32 -0700, Russell Haley wrote:
>>>>> On Sun, Jul 16, 2017 at 7:30 PM, Ian Lepore <[hidden email]> wrote:
>>>>> >
>>>>> > On Sun, 2017-07-16 at 17:41 -0700, Russell Haley wrote:
>>>>> > >
>>>>> > > Hi,
>>>>> > >
>>>>> > > I'm building for a BBB and I think I've got almost everything but
>>>>> > > I
>>>>> > > er... can't find the dtb file or the uEnv.txt file. Any help
>>>>> > > would be
>>>>> > > grand? I have a feeling I'm going to have to beg/borrow/steal a
>>>>> > > uEnv.txt file from a pre-built image.
>>>>> > >
>>>>> > > As I'm going through the process of re-learning the build steps,
>>>>> > > i
>>>>> > > thought of a couple of things that I either didn't see or
>>>>> > > couldn't
>>>>> > > find on the website:
>>>>> > >
>>>>> > > - A list of boards and their kernel config files
>>>>> > > - An easy reference on where to find the bits after the build.
>>>>> > > yes,
>>>>> > > yes, it's in the handbook.
>>>>> > > - Since u-boot has been standardised now, it would be nice to
>>>>> > > have a
>>>>> > > section on where to get u-boot and the other bits needed to boot.
>>>>> > >
>>>>> > > Anyway, I've got an unprecedented week with no work and no kids,
>>>>> > > so
>>>>> > > I'm going to do what any sane person would do during a beautiful
>>>>> > > July
>>>>> > > summer: play with FreeBSD!
>>>>> > >
>>>>> > > My end goal - and this is a stretch target - is to try and adopt
>>>>> > > Illyia's SDIO driver. I'm not sure how far I'll get, or much time
>>>>> > > I'll
>>>>> > > have after my week is up, but that's what my objective is. I've
>>>>> > > built
>>>>> > > the system using the kernel config BEAGLEBONE-MMCCAM in the blind
>>>>> > > hope
>>>>> > > that it will use his drivers? Once I get that working and can
>>>>> > > verify
>>>>> > > it in dtrace (maybe? yet another rabbit hole!) I want to get it
>>>>> > > working on my IMX6 hummingboard.
>>>>> > >
>>>>> > > oh, and I suppose I should open up some code, eh?
>>>>> > >
>>>>> > > Okay, now why isn't my PC computer seeing my sd cards? grrr... ;)
>>>>> > >
>>>>> > > Cheers,
>>>>> > >
>>>>> > > Russ
>>>>> > You don't need a uenv.txt file.  It was always optional, and with
>>>>> > the
>>>>> > latest uboot stuff it's completely gone.
>>>>> >
>>>>> > -- Ian
>>>>> Thanks Ian.
>>>>>
>>>>> DTB files are apparently generated with buildworld.
>>>>>
>>>>> https://wiki.freebsd.org/FlattenedDeviceTree
>>>>>
>>>>> I know they are generated with a specific tool (the name of which I
>>>>> forget) . I'm surprised it's not it's own target or at least part of
>>>>> buildkernel.
>>>>>
>>>>> Russ
>>>>
>>>> The DTB files installed on our distributed images are built from
>>>> sys/modules/dtb (which makes them part of the kernel build unless you
>>>> go out of your way to build them by themselves).
>>>
>>> EBK (Error Behind Keyboard): Forgot the single quotes in my find
>>> command. oops. Thanks!
>>>
>>> russellh@prescott:~/FreeBSD/hummingboard/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src/sys%
>>> find . -name '*dtb*'
>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb
>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/am335x-boneblack.dtb
>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/ufw.dtb
>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/am335x-bonegreen.dtb
>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/am335x-bone.dtb
_______________________________________________
[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: BBB & IMX6 Hummingboard SDIO driver

Russell Haley
Current Status:

Building and Installing - BBB
- Either the information about building a Beaglebone has fallen out of
date, or the beaglebone black has different requirements that should
be documented on that page. Boot pieces:
- MLO
-u-boot.img
-ubldr.bin

- The kernel I built yesterday panics during load due to a sleep lock
that has already been identified by kibab (aka Ilya). I will attempt
to patch it tomorrow.

hummingboard
- The u-boot port for cubox-hummingboard does not build from the
ports. It tries to fetch the 2013 source files and fails the checksum.
I pulled ports from svn and it builds correctly with u-boot 2017.

Source Code
The following is my examination of the code I can identify as
involving the new MMCCAM stack. I am reading first to understand how
the pieces fit and then will get into the details.

 - All mmccam functions for BBB sd cards is run through the sdhci
driver in /sys/dev/sdhci/sdhci.c which is extended by
arm/ti/ti_sdhci.c. When a custom kernel configuration is used, the
MMCCAM flag is specified and the MMCCAM specific code is compiled into
/sys/dev/sdhci/sdhci.c and .h.
 - There seems to be a implementation specific startup routine
compiled into the arm/ti/ti_sdhci.c using an ifdef. There is also a
custom read and write defined so I assume there is some board specific
things that need adjusting. Need to look closer
 - sdhci code paths seem to directly use the cam_ccb and cam_sim
rather than call any mmc specific code. It seems the sdhci uses the
cam bus but not the mmc_sdio code, nore the cam_xpt_* code.
- Note: in /sys/dev/sdhci/sdhci.c the includes on lines 51 through 55
are duplicated in an ifdef MMCCAM at lines 1979 through 1985. Is that
intentional?

cam/mmc
- mmc_sdio seems to be it's own thing. It includes both the
cam_sim/cam_ccb and the cam_xpt_* headers but I don't know yet if it
uses both sets of functionality (code is still opaque to me).

Okay, back at it tomorrow. Ilya, Warner, if you're around at all I'd
love to get a state of the union from you.

Thanks,

Russ

On Tue, Jul 18, 2017 at 7:25 AM, Russell Haley <[hidden email]> wrote:

> Well more EBK (error behind keyboard). In the end I STILL didn't read
> the entire command line in the
> wiki. I missed the -E parameter for sudo, which preserves the
> environment variables.
>
> Ian remembered that he once added something to the sudoers file, which
> got me to the next step, where I finally *saw* the missing sudo parameter
> when reading the wiki entry for buildkernel. His more permanent
> solution is to add a line via
> visudo:
>
> Defaults env_keep += "MAKEOBJDIRPREFIX MODULES_OVERRIDE SUBDIR_OVERRIDE"
>
> which preserves the required variable of MAKEOBJDIRPREFIX.
>
> He explains the other variables:
> The other two vars are because I sometimes do a sudo make install with
> SUBDIR_OVERRIDE= or MODULES_OVERRIDE= to get a quick partial install
>
> Final build instructions:
>
> *NOTE: My output all says hummingboard because I thought I was going
> to build for that board first. I changed my mind at the last minute
> and built for my BBB. I'm cross building on amd64 to a BBB.
>
> setenv BASEDIR `pwd`
> setenv MAKEOBJDIRPREFIX $BASEDIR/obj
> cd $BASEDIR/src
>
> svn checkout https://svn0.us-west.FreeBSD.org/base/head .
>
>
> mkdir /mnt/memdisk
> mkdir /mnt/uboot
>
> truncate -s 1100M bbb.img #I think... I used 2048 because 1024 failed
> sudo mdconfig -f bbb.img
>
> gpart create -s mbr md0
> gpart add -t fat32 -b 1M -s 50M md0
> sudo newfs_msdos -F16 /dev/md0s1
> gpart add -t freebsd md0
> sudo newfs /dev/md0s2
>
>
> make TARGET_ARCH=armv6 -j10 buildworld
> make TARGET_ARCH=armv6 KERNCONF=BEAGLEBONE-MMCCAM -j10 buildkernel
>
> sudo mount_msdosfs /dev/md0s1 /mnt/uboot/
> sudo mount /dev/md0s2 /mnt/memdisk/
>
> #The -E is very important. It preserves the environment for sudo
> sudo -E make TARGET_ARCH=armv6 DESTDIR=/mnt/memdisk installworld distribution
> sudo -E make installkernel  TARGET_ARCH=armv6
> KERNCONF=BEAGLEBONE-MMCCAM DESTDIR=/mnt/memdisk
>
> cp ~/FreeBSD/hummingboard/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src/sys/boot/arm/uboot/ubldr
> /mnt/uboot
>
> #
> cd ~/FreeBSD/hummingboard/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src
> ~/FreeBSD/hummingboard/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src%
> cp ./sys/BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/am335x-boneblack.dtb
>  /mnt/uboot/
>
>
> cd /usr/ports/sysutils/u-boot-beaglebone/
>
> make
>
> cp work/u-boot-ports-v2017.01.00.2/MLO /mnt/uboot
> cp work/u-boot-ports-v2017.01.00.2/u-boot.img /mnt/uboot
>
> sudo umount /dev/md0s1
> sudo umount /dev/md0s2
> sudo mdconfig -du md0
>
> sysctl kern.geom.debugflags=16
> dd if=bbb.img of=/dev/da5 bs=4096k
>
> total ufs size used: 948M
>
> Thanks!
> Russ
>
> Now I need to find those silly little pins for the fdt cable. lolz
>
> On Mon, Jul 17, 2017 at 5:15 PM, Russell Haley <[hidden email]> wrote:
>> Sorry, I'm going to take the TARGET out and try again. It's not in the
>> wiki entry for cross building.
>>
>> On Mon, Jul 17, 2017 at 1:57 PM, Russell Haley <[hidden email]> wrote:
>>> My installworld is failing?
>>>
>>> Steps so far:
>>> #Make a memdisk to speed things up
>>> mkdir /mnt/memdisk
>>> mkdir /mnt/uboot
>>>
>>> truncate -s 1024M bbb.img
>>> sudo mdconfig -f bbb.img
>>>
>>> gpart create -s mbr md0
>>> gpart add -t fat32 -b 1M -s 50M md0
>>> newfs_msdos -F32 /dev/md0s1
>>> gpart add -t freebsd md0
>>> sudo newfs /dev/md0s2
>>>
>>> #build
>>>
>>> make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 -j10 buildworld
>>> make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6
>>> KERNCONF=BEAGLEBONE-MMCCAM -j10 buildkernel
>>>
>>> #install
>>> sudo mount_msdosfs /dev/md0s1 /mnt/uboot/
>>> sudo mount /dev/md0s2 /mnt/memdisk/
>>> sudo make TARGET_ARCH=armv6 DESTDIR=/mnt/memdisk installworld distribution
>>>
>>> build error (full output is here: https://pastebin.com/VU3XDt5u):
>>>
>>> --------------------------------------------------------------
>>>>>> Installing everything
>>> --------------------------------------------------------------
>>> cd /usr/home/russellh/FreeBSD/hummingboard/src; make -f Makefile.inc1
>>> install
>>> ===> lib (install)
>>> ===> lib/csu (install)
>>> ===> lib/csu/arm (install)
>>> cc -target armv6-gnueabihf-freebsd12.0
>>> --sysroot=/usr/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src/tmp
>>> -B/usr/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src/tmp/usr/bin
>>> -O -pipe -I/usr/home/russellh/FreeBSD/hummingboard/src/lib/csu/common
>>> -I/usr/home/russellh/FreeBSD/hummingboard/src/lib/libc/include
>>> -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
>>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
>>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
>>> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
>>> -Wnested-externs -Wredundant-decls -Wold-style-definition
>>> -Wno-pointer-sign -Wthread-safety -Wno-empty-body -Wno-string-plus-int
>>> -Wno-unused-const-variable  -Qunused-arguments
>>> ERROR-tried-to-rebuild-during-make-install -mlong-calls -S -o crt1.s
>>> /usr/home/russellh/FreeBSD/hummingboard/src/lib/csu/arm/crt1.c
>>> /tmp/install.t1fF66Xy/sh: cc: not found
>>> *** Error code 127
>>>
>>> Stop.
>>> make[6]: stopped in
>>> /usr/home/russellh/FreeBSD/hummingboard/src/lib/csu/arm
>>> *** Error code 1
>>>
>>> Stop.
>>> make[5]: stopped in
>>> /usr/home/russellh/FreeBSD/hummingboard/src/lib/csu
>>> *** Error code 1
>>>
>>> Stop.
>>> make[4]: stopped in /usr/home/russellh/FreeBSD/hummingboard/src/lib
>>> *** Error code 1
>>>
>>> Stop.
>>> make[3]: stopped in /usr/home/russellh/FreeBSD/hummingboard/src
>>> *** Error code 1
>>>
>>> Stop.
>>> make[2]: stopped in /usr/home/russellh/FreeBSD/hummingboard/src
>>> *** Error code 1
>>>
>>> Stop.
>>> make[1]: stopped in /usr/home/russellh/FreeBSD/hummingboard/src
>>> *** Error code 1
>>>
>>> Stop.
>>> make: stopped in /usr/home/russellh/FreeBSD/hummingboard/src
>>>
>>>
>>>
>>> Thanks,
>>> Russ
>>>
>>> On Mon, Jul 17, 2017 at 11:39 AM, Russell Haley <[hidden email]> wrote:
>>>> On Mon, Jul 17, 2017 at 11:34 AM, Ian Lepore <[hidden email]> wrote:
>>>>> On Mon, 2017-07-17 at 11:32 -0700, Russell Haley wrote:
>>>>>> On Sun, Jul 16, 2017 at 7:30 PM, Ian Lepore <[hidden email]> wrote:
>>>>>> >
>>>>>> > On Sun, 2017-07-16 at 17:41 -0700, Russell Haley wrote:
>>>>>> > >
>>>>>> > > Hi,
>>>>>> > >
>>>>>> > > I'm building for a BBB and I think I've got almost everything but
>>>>>> > > I
>>>>>> > > er... can't find the dtb file or the uEnv.txt file. Any help
>>>>>> > > would be
>>>>>> > > grand? I have a feeling I'm going to have to beg/borrow/steal a
>>>>>> > > uEnv.txt file from a pre-built image.
>>>>>> > >
>>>>>> > > As I'm going through the process of re-learning the build steps,
>>>>>> > > i
>>>>>> > > thought of a couple of things that I either didn't see or
>>>>>> > > couldn't
>>>>>> > > find on the website:
>>>>>> > >
>>>>>> > > - A list of boards and their kernel config files
>>>>>> > > - An easy reference on where to find the bits after the build.
>>>>>> > > yes,
>>>>>> > > yes, it's in the handbook.
>>>>>> > > - Since u-boot has been standardised now, it would be nice to
>>>>>> > > have a
>>>>>> > > section on where to get u-boot and the other bits needed to boot.
>>>>>> > >
>>>>>> > > Anyway, I've got an unprecedented week with no work and no kids,
>>>>>> > > so
>>>>>> > > I'm going to do what any sane person would do during a beautiful
>>>>>> > > July
>>>>>> > > summer: play with FreeBSD!
>>>>>> > >
>>>>>> > > My end goal - and this is a stretch target - is to try and adopt
>>>>>> > > Illyia's SDIO driver. I'm not sure how far I'll get, or much time
>>>>>> > > I'll
>>>>>> > > have after my week is up, but that's what my objective is. I've
>>>>>> > > built
>>>>>> > > the system using the kernel config BEAGLEBONE-MMCCAM in the blind
>>>>>> > > hope
>>>>>> > > that it will use his drivers? Once I get that working and can
>>>>>> > > verify
>>>>>> > > it in dtrace (maybe? yet another rabbit hole!) I want to get it
>>>>>> > > working on my IMX6 hummingboard.
>>>>>> > >
>>>>>> > > oh, and I suppose I should open up some code, eh?
>>>>>> > >
>>>>>> > > Okay, now why isn't my PC computer seeing my sd cards? grrr... ;)
>>>>>> > >
>>>>>> > > Cheers,
>>>>>> > >
>>>>>> > > Russ
>>>>>> > You don't need a uenv.txt file.  It was always optional, and with
>>>>>> > the
>>>>>> > latest uboot stuff it's completely gone.
>>>>>> >
>>>>>> > -- Ian
>>>>>> Thanks Ian.
>>>>>>
>>>>>> DTB files are apparently generated with buildworld.
>>>>>>
>>>>>> https://wiki.freebsd.org/FlattenedDeviceTree
>>>>>>
>>>>>> I know they are generated with a specific tool (the name of which I
>>>>>> forget) . I'm surprised it's not it's own target or at least part of
>>>>>> buildkernel.
>>>>>>
>>>>>> Russ
>>>>>
>>>>> The DTB files installed on our distributed images are built from
>>>>> sys/modules/dtb (which makes them part of the kernel build unless you
>>>>> go out of your way to build them by themselves).
>>>>
>>>> EBK (Error Behind Keyboard): Forgot the single quotes in my find
>>>> command. oops. Thanks!
>>>>
>>>> russellh@prescott:~/FreeBSD/hummingboard/obj/arm.armv6/usr/home/russellh/FreeBSD/hummingboard/src/sys%
>>>> find . -name '*dtb*'
>>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb
>>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/am335x-boneblack.dtb
>>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/ufw.dtb
>>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/am335x-bonegreen.dtb
>>>> ./BEAGLEBONE-MMCCAM/modules/usr/home/russellh/FreeBSD/hummingboard/src/sys/modules/dtb/am335x/am335x-bone.dtb
_______________________________________________
[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: BBB & IMX6 Hummingboard SDIO driver

Ilya Bakulin-6
On 2017-07-19 05:19, Russell Haley wrote:

> Current Status:
>
> Building and Installing - BBB
> - Either the information about building a Beaglebone has fallen out of
> date, or the beaglebone black has different requirements that should
> be documented on that page. Boot pieces:
> - MLO
> -u-boot.img
> -ubldr.bin
>
> - The kernel I built yesterday panics during load due to a sleep lock
> that has already been identified by kibab (aka Ilya). I will attempt
> to patch it tomorrow.

I'm not sure what problem are you talking about. The patch on
Phabricator
tries to address a problem that there are several sleep() calls
used in the MMC/SD probe code.
This code shouldn't sleep. So I'm trying to get rid of sleeps,
but the patch I've generated so far doesn't work -- this is just a
starting point.
So if the version from -HEAD panics at boot -- this is a bug and I need
to address it. I haven't booted BBB in ages and will have sufficient
time
to debug the problem myself in two weeks (during DevSummit in
Cambridge).

> Source Code
> The following is my examination of the code I can identify as
> involving the new MMCCAM stack. I am reading first to understand how
> the pieces fit and then will get into the details.
>
>  - All mmccam functions for BBB sd cards is run through the sdhci
> driver in /sys/dev/sdhci/sdhci.c which is extended by
> arm/ti/ti_sdhci.c. When a custom kernel configuration is used, the
> MMCCAM flag is specified and the MMCCAM specific code is compiled into
> /sys/dev/sdhci/sdhci.c and .h.
Yes, that's right.

>  - There seems to be a implementation specific startup routine
> compiled into the arm/ti/ti_sdhci.c using an ifdef. There is also a
> custom read and write defined so I assume there is some board specific
> things that need adjusting. Need to look closer
Yes, initialization function for MMCCAM is different.
Also there is #ifdef'ed code in write_1 and read_1 because I need to
adjust
a 8-bit enable bit when writing to SDHC control register.
Old stack did it in ios handling, but MMCCAM doesn't allow device
drivers
to have their own ios handling.

>  - sdhci code paths seem to directly use the cam_ccb and cam_sim
> rather than call any mmc specific code. It seems the sdhci uses the
> cam bus but not the mmc_sdio code, nore the cam_xpt_* code.
This is correct -- every CAM request/response is routed by the CAM
subsystem.

> - Note: in /sys/dev/sdhci/sdhci.c the includes on lines 51 through 55
> are duplicated in an ifdef MMCCAM at lines 1979 through 1985. Is that
> intentional?
No, this should be corrected. Thanks!

>
> cam/mmc
> - mmc_sdio seems to be it's own thing. It includes both the
> cam_sim/cam_ccb and the cam_xpt_* headers but I don't know yet if it
> uses both sets of functionality (code is still opaque to me).
This code is not used yet since there is no SDIO-specific code for now.
>
> Okay, back at it tomorrow. Ilya, Warner, if you're around at all I'd
> love to get a state of the union from you.

Replying to your question on IRC wrt communication protocol: I don't
frequently
monitor all FreeBSD mailing lists and can easily miss SDIO-related stuff
unless I'm directly CC'ed.
I have a highlight setup for the #bsdmips IRC channel that notifies me
when SDIO or my nickname is mentioned, so I will know someone was
talking
about these things.

I'm in Munich (timezone is CEST), so reply times might be longer for
US-based folk.
--
Mit freundlichen Grüßen,
Ilya Bakulin
_______________________________________________
[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: BBB & IMX6 Hummingboard SDIO driver

Russell Haley
On Thu, Jul 20, 2017 at 1:56 AM, Ilya Bakulin <[hidden email]> wrote:

> On 2017-07-19 05:19, Russell Haley wrote:
>>
>> Current Status:
>>
>> Building and Installing - BBB
>> - Either the information about building a Beaglebone has fallen out of
>> date, or the beaglebone black has different requirements that should
>> be documented on that page. Boot pieces:
>> - MLO
>> -u-boot.img
>> -ubldr.bin
>>
>> - The kernel I built yesterday panics during load due to a sleep lock
>> that has already been identified by kibab (aka Ilya). I will attempt
>> to patch it tomorrow.
>
>
> I'm not sure what problem are you talking about. The patch on Phabricator
> tries to address a problem that there are several sleep() calls
> used in the MMC/SD probe code.
> This code shouldn't sleep. So I'm trying to get rid of sleeps,
> but the patch I've generated so far doesn't work -- this is just a starting
> point.
> So if the version from -HEAD panics at boot -- this is a bug and I need
> to address it. I haven't booted BBB in ages and will have sufficient time
> to debug the problem myself in two weeks (during DevSummit in Cambridge).
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

>> Source Code
>> The following is my examination of the code I can identify as
>> involving the new MMCCAM stack. I am reading first to understand how
>> the pieces fit and then will get into the details.
>>
>>  - All mmccam functions for BBB sd cards is run through the sdhci
>> driver in /sys/dev/sdhci/sdhci.c which is extended by
>> arm/ti/ti_sdhci.c. When a custom kernel configuration is used, the
>> MMCCAM flag is specified and the MMCCAM specific code is compiled into
>> /sys/dev/sdhci/sdhci.c and .h.
>
> Yes, that's right.
>
>>  - There seems to be a implementation specific startup routine
>> compiled into the arm/ti/ti_sdhci.c using an ifdef. There is also a
>> custom read and write defined so I assume there is some board specific
>> things that need adjusting. Need to look closer
>
> Yes, initialization function for MMCCAM is different.
> Also there is #ifdef'ed code in write_1 and read_1 because I need to adjust
> a 8-bit enable bit when writing to SDHC control register.
> Old stack did it in ios handling, but MMCCAM doesn't allow device drivers
> to have their own ios handling.
>
>>  - sdhci code paths seem to directly use the cam_ccb and cam_sim
>> rather than call any mmc specific code. It seems the sdhci uses the
>> cam bus but not the mmc_sdio code, nore the cam_xpt_* code.
>
> This is correct -- every CAM request/response is routed by the CAM
> subsystem.
>
>> - Note: in /sys/dev/sdhci/sdhci.c the includes on lines 51 through 55
>> are duplicated in an ifdef MMCCAM at lines 1979 through 1985. Is that
>> intentional?
>
> No, this should be corrected. Thanks!
>
>>
>> cam/mmc
>> - mmc_sdio seems to be it's own thing. It includes both the
>> cam_sim/cam_ccb and the cam_xpt_* headers but I don't know yet if it
>> uses both sets of functionality (code is still opaque to me).
>
> This code is not used yet since there is no SDIO-specific code for now.
>>
>>
>> Okay, back at it tomorrow. Ilya, Warner, if you're around at all I'd
>> love to get a state of the union from you.
>
>
> Replying to your question on IRC wrt communication protocol: I don't
> frequently
> monitor all FreeBSD mailing lists and can easily miss SDIO-related stuff
> unless I'm directly CC'ed.
> I have a highlight setup for the #bsdmips IRC channel that notifies me
> when SDIO or my nickname is mentioned, so I will know someone was talking
> about these things.
>
> I'm in Munich (timezone is CEST), so reply times might be longer for
> US-based folk.
> --
> Mit freundlichen Grüßen,
> Ilya Bakulin
_______________________________________________
[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: BBB & IMX6 Hummingboard SDIO driver

Ilya Bakulin-6
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.

--
Ilya


_______________________________________________
[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: BBB & IMX6 Hummingboard SDIO driver

Russell Haley
On Fri, Jul 21, 2017 at 12:31 PM, Ilya Bakulin <[hidden email]> 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
_______________________________________________
[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: BBB & IMX6 Hummingboard SDIO driver

Ilya Bakulin-6
On 2017-07-23 00:34, Russell Haley wrote:
> - 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).


With the debugging prints turned on it's expected that everything is
deadly slow.
So please do `camcontrol debug off` before running any performance
tests.
Even without debugging stuff the old stack might be faster on at least
UHS-I cards because
the new stack doesn't yet support UHS-I.

I've been doing some simple performance tests before, and performance
both of the old
and the new stack was limited by SD card, not by anything in code.
--
Mit freundlichen Grüßen,
Ilya Bakulin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"