Hummingboard 2 Edge

I have FreeBSD running on Hummingboard 2 Edge.
It is not supported but has enough similarities with Hummingboard-Pro to work.
This board uses an interchangable iMX6 CPU and Memory module.
Called a uSOM it also can hold embedded emmc storage.
Code:
CPU: ARM Cortex-A9 r2p10 (ECO: 0x00000000)
CPU Features: 
  Multiprocessing, Thumb2, Security, VMSAv7, Coherent Walk
Optional instructions: 
  UMULL, SMULL, SIMD(ext)
LoUU:2 LoC:2 LoUIS:2 
Cache level 1:
 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc
 32KB/32B 4-way instruction cache Read-Alloc
real memory  = 2147483648 (2048 MB)
avail memory = 2089701376 (1992 MB)
 
Here is the real killer feature. It has an M.2 slot that works with mSATA.
Code:
FreeBSD generic 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr  9 06:33:09 UTC 2021     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC  arm
root@generic:~ # diskinfo -wS /dev/ada0
/dev/ada0
        512             # sectorsize
        124034899968    # mediasize in bytes (116G)
        242255664       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        240333          # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        M.2 (S80) 3MG2-P        # Disk descr.
        20170606AA0008570055    # Disk ident.
        ahcich0         # Attachment
        Yes             # TRIM/UNMAP support
        0               # Rotation rate in RPM
        Not_Zoned       # Zone Mode

Synchronous random writes:
         0.5 kbytes:   1651.0 usec/IO =      0.3 Mbytes/s
           1 kbytes:   1674.5 usec/IO =      0.6 Mbytes/s
           2 kbytes:   1711.7 usec/IO =      1.1 Mbytes/s
           4 kbytes:   1679.5 usec/IO =      2.3 Mbytes/s
           8 kbytes:   1720.6 usec/IO =      4.5 Mbytes/s
          16 kbytes:   1801.2 usec/IO =      8.7 Mbytes/s
          32 kbytes:   1889.8 usec/IO =     16.5 Mbytes/s
          64 kbytes:   2226.4 usec/IO =     28.1 Mbytes/s
         128 kbytes:   2775.3 usec/IO =     45.0 Mbytes/s
         256 kbytes:   4021.1 usec/IO =     62.2 Mbytes/s
         512 kbytes:   5830.2 usec/IO =     85.8 Mbytes/s
        1024 kbytes:   8801.6 usec/IO =    113.6 Mbytes/s
        2048 kbytes:  14639.8 usec/IO =    136.6 Mbytes/s
        4096 kbytes:  26122.4 usec/IO =    153.1 Mbytes/s
        8192 kbytes:  49125.9 usec/IO =    162.8 Mbytes/s
 
I hate fighting RTC on ARM. What a relief that SolidRun realized that and includes a RTC and battery plug.
Code:
nxprtc0: <NXP PCF8523 RTC> at addr 0xd0 on iicbus1

Cellular Modem mounted in the MiniPCIe slot on the underside of the board along with a SIM slot.
Code:
u3g0 on uhub2
u3g0: <Sierra Wireless, Incorporated MC7354, class 0/0, rev 2.00/0.06, addr 3> on usbus1
u3g0: Found 6 ports.
Autoloading module: u3g.ko
 
I have an old cubox i4 pro (with the imx 6) and it sort-of worked with FreeBSD. It looks like the support, albeit not directly, has improved. Perhaps I should dig it up and re-try with FreeBSD.
(If I recall eSata didn't work nor did HDMI and toslink/spdif.)
I think most of their products come with an RTC which is great for embedded stuff. Certainly the cuboxs did.
 
This is my first Quad Core uSOM

The bonus is they are still on sale. Not cheap but reasonable.

The cubox/hummingboard wiki has a link to a github script that puts Uboot from FreeBSD-11 on whatever you want.
That is the only way it will boot.

I plan on investigating the uboot in ports failing to work.
From a layman it appears that all uboot ports were conglomerated into uboot master tree around 2018.
Cubox and HB were using a custom SolidRun repository as the work there was not upstreamed to uboot.
This repository is from 2013 and still in use. I dunno how or why.

But when uboot slave ports were conglomerated into the same source tree we lost our support.
The uboot patches we have are for SolidRuns tree.

So I don't know what to do. Continue using old uboot in stupid hack or attempt to build and fix uboot.
That it works on Hummingboard2 is groovy.
GPIO assignments are the only fault I can find.

I need to see what it takes to use the /gnu/dtb files for HB2 instead of HB1.
 
Can anyone help me understand this port message:

U-Boot loader for SolidRun Cubox-i and Hummingboard.

Install the u-boot.imx file onto the boot disk using:

dd if=u-boot.imx of=/dev/whatever bs=1k oseek=1 conv=sync

The U-Boot built by this port expects the first 1MB of the boot media to
be reserved for the U-Boot executable and saved environment. The u-boot.imx
file begins at an offset of 1K from the start of the boot disk. The U-Boot
environment area begins at an offset of 512K.

This version is patched so that:
* ELF and API features are enabled to support ubldr.

The sources for this port were originally obtained from commit e4bc4c3ebe
at https://github.com/SolidRun/u-boot-imx6 which appears to be a highly
modified fork of the stock U-Boot 2013.10 release. As of this writing,
the changes in this fork have not been rolled back into upstream U-Boot.

What I am wondering is where is it writing u.boot.imx to? This is an unformated area of the disk right?

So when I go to make my uboot fat partition I must start it at a special spot to not overwrite u.boot.imx right?
dd if=u-boot.imx of=/dev/da0 bs=1k oseek=1 conv=sync

What would that look like? Do I have to start this command specially? Will MBR stomp on uboot without direction?
gpart create -s mbr da0

Where do I create an offset for uboot? Here?
gpart add -t \!12 -s 10m da0

This would be too late I assume:
newfs_msdos -F12 -L 'MSDOSBOOT' /dev/da0s1
gpart set -a active -i 1 da0


AllWinner wiki has more details but no example for creating partitions.

Anybody care to comment?
 
I see that Manu has done some commits for this u-boot version, so perhaps ask him on email?
He's a bit of a guru on all things SoC in NetBSD and also FreeBSD. I have a bookmark of his blog here, you might wish to read.

If you look at wandboard (which is imx.6) for crochet, here, you'll note it creates an MBR (line 16), something like:
gpart create -s MBR geom
Then it writes the u-boot image to it:
dd if=${WANDBOARD_UBOOT_SRC}/u-boot.imx of=/dev/${DISK_MD} bs=512 seek=2
So, that's seeking to 2*512 to write the image.
 
Thanks for the crochet hints.
Funny thing is I have seen mailing list post about crochet being broken because it downloads uboot instead of using ports tree uboot.
But in this case that might be good. I need to see what happened around 2017.
That was last update to SolidRuns git repository for their IMX6 uboot fork.

All of this coinsides with FreeBSD uboot moving to a master port scheme.

I understand the 1024K set aside for u-boot.imx but I am unsure why its needed.
For example my Beaglebone only required copying files from uboot port to msdos partition.
No flashing a file to first 1K of disk.

Is this just an architectural thing? iMX6 needs first 1K of boot medium for bootstrap?
Whereas Beaglebone Ti am335 just has different routine for booting where it can read a file from msdos?
 
I tried to get the Hummingboard1 to boot from mSATA. I was not successful but learned alot.
Now I have Hummingboard2 and
The work allowed me to set SATA as root without SDcard even mounting ufs.
Code:
# Custom /etc/fstab for FreeBSD embedded images
/dev/ada0s2a            /                       ufs             rw                      1       1
/dev/mmcsd0s1           /boot/msdos             msdosfs         rw,noatime              0       0
tmpfs                   /tmp                    tmpfs           rw,mode=1777,size=50m   0       0

Loaded on the SDcard is the full FreeBSD image modified with FreeBSD11 uboot partition hack

Earlier I had tried stripping it down to just the /boot directory on SDcard along with uboot fat partition.
Mounted /boot via fstab at /dev/mmcsd0s2a
That did not work. Tried to add path to kernel with /dev/mmcsd0s2a/boot . No luck
So by chance I skipped using mmcsd0s2a on sdcard in fstab and it worked.
I had the full image on ada0 so it just worked.
Amazing, I dunno what it is doing but I like the desired effect. No more depending on SDcard reads.
Code:
root@generic:~ # mount
/dev/ada0s2a on / (ufs, local, journaled soft-updates, nfsv4acls)
devfs on /dev (devfs)
/dev/mmcsd0s1 on /boot/msdos (msdosfs, local, noatime)
tmpfs on /tmp (tmpfs, local)

Downloading a ports tree heated her up some.
Code:
root@generic:~ # sysctl -a | grep temperature
hw.imx.throttle_temperature: 95.0C
hw.imx.temperature: 51.6C
 
Thanks for the crochet hints.
Funny thing is I have seen mailing list post about crochet being broken because it downloads uboot instead of using ports tree uboot.
But in this case that might be good. I need to see what happened around 2017.
That was last update to SolidRuns git repository for their IMX6 uboot fork.

All of this coinsides with FreeBSD uboot moving to a master port scheme.

I understand the 1024K set aside for u-boot.imx but I am unsure why its needed.
It's another stage that sets up the device tree and perhaps enables other stuff like the RTC? I don't know, I'm guessing, but I expect if you email Emmanuel Vadot he will know and be able to explain it or fire up a message on freebsd-arm and likely someone knows the intricacies and you can post back with the information. ;)

For example my Beaglebone only required copying files from uboot port to msdos partition.

No flashing a file to first 1K of disk.

Is this just an architectural thing? iMX6 needs first 1K of boot medium for bootstrap?

Speaking from a high degree of ignorance, yes, this seems to be architectural in that, regardless of the underlying CPU, if the SoC requires u-boot on a FAT partition or an EFI one, largely seems to depend on the design of the device.

That's why I looked at crochet for another imx.6 SoC board because I presumed it would be the same.

Whereas Beaglebone Ti336 just has different routine for booting where it can read a file from msdos?

Precisely. Look at the Wandaboard stuff. It's different again.
 
I just bought a Transcend drive from the evil borg Amazon for this box.
Cheapest preferred name brand M.2--2242 drive was 512GB@$82

I had a 2280 M.2 Innodisk stuck in her and had to duct tape her in. She was a tad too long hanging off the side..
 
What about a later build of BSD?
Please confirm with your similar box. I tested everything up the ladder. Failed.

I don't know how that's possible without someone speaking up. I do know its documented.
Ian is the iMX6 guru. The wiki is spot on and he made the latest changes.

I did not implement the changes at the very bottom of the wiki. Just what the script does.
(I did change script version to 13-RELEASE)
That might be why eMMC on SOM is not recognized.
I am not sure my rig even has any eMMC though. Never even tried the Linux distro.
 
(Although it's not HummingBoard2 if that is significantly different?)
I am using the stock images except bad uboot trick.
So thankfully Cubox/Hummingboard work transfers. The Generic 13-RELEASE arm7 image is what I am using.
I think the SOM being similar/same really helps. The rest is peripherals.
Networking worked fine for a ports tree. My temps are hot because the board is out of the case.
The fact that M.2 worked when the mSATA on original board was MiniPCIe slot is great.

I would like to see MiniPCIe bus work on iMX6. My cellular modem works because it uses USB signalling.
mSATA must use its own wiring scheme.
I tested the slot with a MiniPCIe slot Serial Port card. It was not recognized. PCIe signalling needed.

On my Hummingboard1 there is mSATA on underside and Mini-PCIe Half-Slot on top.
I have not tested USB signalling MiniPCIe half cards in Hummingboard1. No SIM so I never tried.
I do have RT3072 wireless Mini-PCIe card half length (usb signalling) I could test it with.
A GPS module would also be a good USB slot test.
 
mark_j
If you do have the cubox i4 model you may be in luck.
I was thinking in my head, cubox is too small for a mSATA slot.
So I went looking and sure enough, no mSATA slot. But....
The quad core version did have an eSATA connector.
So external SATA may be possible.

Yup here is a nice pic of the eSATA jack.

Solid Run has some good documentation. That is for sure. Plus old disk images still up. Bravo
Now if they would push upstream uboot patches we might have something.
 
Yes, it has an eSata, that was one of the problems when I tried it a LONG time ago (FreeBSD 10?) and it didn't work.
It has since been archived in a box somewhere. I will have a look around to see if I can dig it out (hopefully the battery hasn't leaked all over the contents :eek:)

My Cubox is an i4 Pro if I recall correctly. It has, from memory, 2 usb2 slots, spdif, eSata, GB network and HDMI (full size). The SPDIF is to the side of the box. It has built-in CEC support for a remote. There's absolutely no room for an mSata. LOL. :D It's basically 2inches squared.


Anyway, back to your hummingboard issue, I was thinking you could grab the version of FreeBSD 12.3 for the cubox/hummingboard and look at the structure of the image file to see if it matches what you're trying to build using the "custom" u-boot.
 
I might try and re-invigorate the old uboot-hummingboard port that pointed to Solid Runs github.
Modernize from there.

I am also looking to build dts from gnu source for Hummingboard2
/usr/src/sys/gnu/dts/arm/imx6q-hummingboard2.dts
Then copy the dtb over to my boards /boot/dtb directory and see how it acts.

I don't understand what chooses the dtb to use on these generic arm images.
In the /boot/dtb/ directory is several different boards dtbs. So what is the chooser?

The reason I ask is uboot uses cubox dtb on my Hummingboard2
Code:
U-Boot 2013.10-rc4 (Sep 29 2016 - 10:50:56)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
Reset cause: POR
Board: MX6-CuBox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Warning: failed to set MAC address

** Unable to read file uEnv.txt **
Hit any key to stop autoboot:  0 
Booting from: mmc 0 ubldr
272013 bytes read in 30 ms (8.6 MiB/s)
## Starting application at 0x12000098 ...
Consoles: U-Boot console  
Compatible U-Boot API signature found @0x8f7708a8

FreeBSD/armv6 U-Boot loader, Revision 1.2
(root@releng2.nyi.freebsd.org, Thu Sep 29 11:08:21 UTC 2016)

DRAM: 2048MB
Number of U-Boot devices: 2
U-Boot env: loaderdev='mmc 0'
Found U-Boot device: disk
  Checking unit=0 slice=<auto> partition=<auto>... good.
Booting from disk0s2a:
Loading /boot/defaults/loader.conf

Instead it should be using /boot/dtb/imx6q-hummingboard.dtb
 
on pi's latest freebsd boot procedures have the the dts compiled in the u-boot binary
freebsd loader can load dtb-s but their names should come from u-boot (you cannot set them in loader.conf)
you can specify overlays though
try to stop u-boot boot and printenv
look for fdt_* in it
for me just building the u-boot.bin from ports did not work until i added the conf option to embed the dtb
probably something wrong with my config.txt
in u-boot README
Code:
- Device tree:
                CONFIG_OF_CONTROL
                If this variable is defined, U-Boot will use a device tree
                to configure its devices, instead of relying on statically
                compiled #defines in the board file. This option is
                experimental and only available on a few boards. The device
                tree is available in the global data as gd->fdt_blob.

                U-Boot needs to get its device tree from somewhere. This can
                be done using one of the three options below:

                CONFIG_OF_EMBED
                If this variable is defined, U-Boot will embed a device tree
                binary in its image. This device tree file should be in the
                board directory and called <soc>-<board>.dts. The binary file
                is then picked up in board_init_f() and made available through
                the global data structure as gd->fdt_blob.

                CONFIG_OF_SEPARATE
                If this variable is defined, U-Boot will build a device tree
                binary. It will be called u-boot.dtb. Architecture-specific
                code will locate it at run-time. Generally this works by:

                        cat u-boot.bin u-boot.dtb >image.bin

                and in fact, U-Boot does this for you, creating a file called
                u-boot-dtb.bin which is useful in the common case. You can
                still use the individual files if you need something more
                exotic.

                CONFIG_OF_BOARD
                If this variable is defined, U-Boot will use the device tree
                provided by the board at runtime instead of embedding one with
                the image. Only boards defining board_fdt_blob_setup() support
                this option (see include/fdtdec.h file).
 
I hit a roadblock just building a DTB from source. Strange thing is I get this error with Hummingboard 1 too.

Code:
root@HB2:/usr/src/sys/gnu/dts/arm # dtc -@ -O dtb -I dts -o imx6q-hummingboard2.dtb imx6q-hummingboard2.dts
Unable to merge node: sata

I guess I could force compile. That never works out good.
My other option is to de-compile my official FreeBSD working DTB and see what is changed from this gnu dts.
 
you need to run the dts thru cpp first
cpp -x assembler-with-cpp -nostdinc -I include arch/arm/dts/imx6q-hummingboard2.dts |dtc -I dts -O dts -o /tmp/xx.dts -
 
I would have never figured that out.
I copied to Hummingboard2 the /usr/src/sys/gnu/dts directory to compile with dtc native.

My de-compiling failed too:
Code:
root@HB2:/boot/dtb # dtc -O dts -I dtb -o imx6q-cubox-i.dts imx6q-cubox-i.dtb
Failed to mmap file: Invalid argument

I had assumed the method to compile DTS to DTBO and back was similar on DTB/DTS
 
Well Thanks, your help certainly helped me find the culprit.
I need to copy more files or just download the whole source tree.

Code:
oot@HB2:/usr/src/sys/gnu/dts/arm # cpp -x assembler-with-cpp -nostdinc -I include /usr/src/sys/gnu/dts/arm/imx6q-hummingboard2.dts | dtc -O dtb -I dts -o imx6q-hummingboard2.dtb imx6q-hummingboard2.dts
Unable to merge node: sata
In file included from /usr/src/sys/gnu/dts/arm/imx6q-hummingboard2.dts:44:
./imx6q.dtsi:5:10: fatal error: 'dt-bindings/interrupt-controller/irq.h' file not found
#include <dt-bindings/interrupt-controller/irq.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
My bad. I was running this from the wrong directory.
It must be ran from the /usr/src/sys/gnu/dts/ directory.
Then all paths are correct and it compiles.

Because I was having troubles I decided to output pre-process to a file to work out the problem.
cpp -x assembler-with-cpp -nostdinc -I include /usr/src/sys/gnu/dts/arm/imx6q-hummingboard2.dts -o test.dts
 
Back
Top