Jump to content

Hummingboard Pulse (iMX8Q) WIP


Recommended Posts

Was in dire need of Armbian on my new toy, the HBP with a iMX8Q CPU ;-) The board features dual WWAN (PCIe + M.2) sockets for highspeed 3G/4G/5G modems with a SIM socket. The Debian build from SolidRun did not have any modem drivers enabled in the kernel so there was headache. Wipped up this WIP configuration and it builds and runs with:
```
$ ./compile.sh  BOARD=hummingboardpulse-imx8q BRANCH=legacy RELEASE=buster BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no
```

NOTE: It uses the HDMI and LPDDR4 binary blobs from NXP. You will get a prompt during build to accept the license.


The board is default configured to boot from SD using the Boot Select DIPs

 

 _   _ ____    ____        _            _ __  ____  _____  
| | | | __ )  |  _ \ _   _| |___  ___  (_)  \/  \ \/ ( _ ) 
| |_| |  _ \  | |_) | | | | / __|/ _ \ | | |\/| |\  // _ \ 
|  _  | |_) | |  __/| |_| | \__ \  __/ | | |  | |/  \ (_) |
|_| |_|____/  |_|    \__,_|_|___/\___| |_|_|  |_/_/\_\___/ 
                                                           
Welcome to Armbian buster with Linux 4.19.72-imx8-sr-imx8

System load:   0.41 1.82 1.38  	Up time:       29 min		
Memory usage:  4 % of 2997MB 	IP:            192.168.10.148
CPU temp:      47°C           	
Usage of /:    18% of 7.1G   	

[ General system configuration (beta): armbian-config ]

http://ix.io/27FC
 

Link to comment
Share on other sites

Is it just me or is the SolidRun software support really messed up?

 

https://developer.solid-run.com/knowledge-base/i-mx8m-atf-u-boot-and-linux-kernel/

 

1. They're using an old u-boot release (v2018.11-solidrun, there were another 6 new official u-boot releases since then) and when you browse to SolidRun's github you'll find another version (v2018.11-solidrun-1gb, I guess that's for the 1gb RAM version of the board?!). All SolidRun u-boot branches are abandoned (last commit 1y ago...) Also they didn't seem to make any afford to bring the Hummingboard Pulse code into the official u-boot repo (https://github.com/SolidRun/u-boot/tree/v2018.11-solidrun-1gb/board/solidrun/imx8mq_hb vs. https://gitlab.denx.de/u-boot/u-boot/-/tree/master/board/solidrun; heck it's not even in the iMX custodian repo https://gitlab.denx.de/u-boot/custodians/u-boot-imx/-/tree/master/board/solidrun)

 

2. You need to use firmware blobs from NXP (developer KB above uses firmware 7.9; NXP is at version 8.7 right now) which have no official website/no changelog/no explanation what the h* they're doing/why you need them

 

3. Linux Kernel... oh boy, this is a mess. Again developer KB above will give you solidrun-imx_4.9.x_1.0.0_ga (last update 2 years ago). But the Debian images they provide ship with kernel 4.19 (I guess it's from linux-4.19.y-nxp; last commit 9 month ago, so you're stuck with version 4.19.72 forever it seems). Then there's a lone SolidRun employee playing with kernel 5.4 (no updates again, you're stuck with 5.4.3 forever)

 

Well screw them you say, I'll just use vanilla, after all they added support for the Hummingboard Pulse in 5.4 but no! They did this half-assed because your board will boot with just the Intel ethernet interface working (compare 5.8-rc1 fec_main.c with Freescale 5.4-2.0.x-imx fec_main.c); all the imx8mq-fec stuff is still missing in vanilla kernel) 

 

All I wanted was a ARM board with 2 Ethernet ports...

Edited by ARMBirdy
Added clickable links
Link to comment
Share on other sites

13 hours ago, ARMBirdy said:

They're using an old u-boot release (v2018.11-solidrun, there were another 6 new official u-boot releases since then) and when you browse to SolidRun's github you'll find another version (v2018.11-solidrun-1gb, I guess that's for the 1gb RAM version of the board?!). All SolidRun u-boot branches are abandoned (last commit 1y ago...) Also they didn't seem to make any afford to bring the Hummingboard Pulse code into the official u-boot repo (https://github.com/SolidRun/u-boot/tree/v2018.11-solidrun-1gb/board/solidrun/imx8mq_hb vs. https://gitlab.denx.de/u-boot/u-boot/-/tree/master/board/solidrun; heck it's not even in the iMX custodian repo https://gitlab.denx.de/u-boot/custodians/u-boot-imx/-/tree/master/board/solidrun)

 

This is the case with most of hardware - hardware support is based on some ancient u-boot where similar hardware was brought up. They (chip maker) extend it for the new chip. Then chip integrator ads its own changes deploys boot loader and forget about. The same is with all / most others:

https://github.com/hardkernel/u-boot/tree/odroidc-v2011.03

https://github.com/radxa/u-boot

https://github.com/orangepi-xunlong/OrangePiH3_uboot

 

Keeping things up to date is extremely expensive and only possible if we and community around this particular hw covers up. We provide mainline u-boot wherever this is possible, but we simply decided to skip imx8 boards since we have no resources to sponsor while not a single cent coverage for this job ever came from users nor from the vendor. Its a lot of work and we only lost huge amount of time. You don't even notice nor say thanks or give anything in return.

 

13 hours ago, ARMBirdy said:

You need to use firmware blobs from NXP (developer KB above uses firmware 7.9; NXP is at version 8.7 right now) which have no official website/no changelog/no explanation what the h* they're doing/why you need them


As you need them (Microsoft owned boot loader / RTOS) to boot Raspberry Pi and lots of others. Welcome to the "open source".
 

Reverse engineering is usually a part of the job to get this hardware to the mainline. Blobs are there to give them control over the hw.

 

13 hours ago, ARMBirdy said:

Linux Kernel... oh boy, this is a mess.


Its a private development kernel, a raw material. Far away from mainline Linux. Its a Linux where this device was brought up.

 

13 hours ago, ARMBirdy said:

they provide ship with kernel 4.19


This is the latest drop of development kernel which is developed by NXP for their customers (Solidrun). Due to the licence demands, they have to release the code. In whatever quality it is. Getting from here to proper stable mainline can easily cost a million. (for this particular chip I don't know how good or bad support actually is and if you need 1/4, 1/2 of that million. To know that its yet another investment into the R&D I have no plan to add on the top of existing jobs.

 

13 hours ago, ARMBirdy said:

All I wanted was a ARM board with 2 Ethernet ports...

 

https://www.armbian.com/nanopi-r2s/

https://www.armbian.com/nanopi-r1/

https://www.armbian.com/orange-pi-r1/

 

... or do something to spark development, either commercially or non-commercially.

Link to comment
Share on other sites

I'm still keeping a fork alive for the imx8mq Hummingboard Pulse over here: https://github.com/Redferne/build
It is geared towards 4G/5G modems in the mPCIe and M.2 slots. It is a CLI only image. 

 

The following target is what's being used here:

$ compile.sh BOARD=hummingboardpulse-imx8q BRANCH=dev RELEASE=bullseye BUILD_MINIMAL=no BUILD_DESKTOP=no EXPERT=yes


 

 _   _ ____    ____        _            _ __  ____  _____  
| | | | __ )  |  _ \ _   _| |___  ___  (_)  \/  \ \/ ( _ ) 
| |_| |  _ \  | |_) | | | | / __|/ _ \ | | |\/| |\  // _ \ 
|  _  | |_) | |  __/| |_| | \__ \  __/ | | |  | |/  \ (_) |
|_| |_|____/  |_|    \__,_|_|___/\___| |_|_|  |_/_/\_\___/ 
                                                           
Welcome to Armbian 21.11.0-trunk Bullseye with Linux 5.14.9-imx8

No end-user support: built from trunk

System load:   17%              Up time:       0 min
Memory usage:  4% of 2.92G      IP:            192.168.42.1 192.168.0.200
CPU temp:      84°C             Usage of /:    12% of 29G   

 

Link to comment
Share on other sites

On 10/5/2021 at 12:00 PM, Redferne said:

I'm still keeping a fork alive for the imx8mq Hummingboard Pulse over here:

 

Awesome, I didn't notice this before, I have no fewer than 3 I.MX8M boards I'd like to have builds for.  I will take a look at this.  :D

Link to comment
Share on other sites

@Redferne Hi, sorry if i'm bumping an old thread, but saw you were still making commits on the hb_pulse_imx8q-branch. 

 

Just tried a few times to build an image for our hummingboard-pulse https://www.solid-run.com/embedded-industrial-iot/nxp-i-mx8-family/hummingboard-m/#pulse

The process seems to complete without errors, but after burning/inserting SD-card there is no serial/HDMI output from the device. 

 

Unsure where to progress here, this is my reported build target after completion:

 

[ o.k. ] Repeat Build Options [ ./compile.sh  BOARD=hummingboardpulse-imx8q BRANCH=current RELEASE=bullseye BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no DESKTOP_ENVIRONMENT=xfce DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base COMPRESS_OUTPUTIMAGE=sha,gpg,img  ]

 

Thanks,
 

Link to comment
Share on other sites

Hi @maphstra

Yes. I'm still trying to keep the fork alive. Please understand that it's is somewhat customized for my use case. I'm only using headless builds and I'm only focusing on having a testbed for 4G/5G modems in the mPCI/M.2 slot.

For that reason, I'm building NetworkManager/ModemManager/iperf3 etc directly from github main/master branch and there are also some other tweaks and patches in there.

I've never gotten HDMI to work on any SolidRun board, and have not really tried. On the Hummingbard2/Gate (cubox-i) there is a u-boot boot logo working, but once the kernel boots the console never shows up or any life on HDMI.

The following two targets/config are the only ones that I'm building:

./compile.sh BOARD=cubox-i BRANCH=edge RELEASE=bullseye BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no USE_TORRENT=no  EXPERT=yes NO_HOST_RELEASE_CHECK=yes SKIP_BOOTSPLASH=yes
./compile.sh BOARD=hummingboardpulse-imx8q BRANCH=dev RELEASE=bullseye BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no USE_TORRENT=no EXPERT=yes NO_HOST_RELEASE_CHECK=yes SKIP_BOOTSPLASH=yes

 

But right now the fork is under maintenance, the builds are not error free just yet. I'll post an update once I've gotten all packages to build.

Link to comment
Share on other sites

Thanks for the quick answer!

 

I see, then our purposes doesn't overlap very much hehe,

 

We got the device hoping it could decode 1920x1080 h264 video in 60 fps, and it does do that really well with the official Solidrun builds and gstreamer. However I was also hoping to make it do some more general-purpose tasks and in the official builds apt or apt-get doesn't work, which makes everything else hard. 

Ideally I could make it run a desktop-environment with a browser to see a custom user interface but i guess i'll have to settle for some simple gstreamer overlays or such. 

 

Thanks anyway, 

maphstra

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines