Re: [Buildroot] Variscite Dart

[Neil Webster <jarraneil@gmail.com>]

Hi Arnout,

I was using an incorrect version and the url was not correct.

The Yocto build uses 6.1.36-2.1.0 and I changed the three tarballs to 
that. I also disabled the hash checking as per your previous comment. 
The download now works but I hit this error ...

INSTALL 
/home/neil/buildroot-2024.08/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/include
if ! support/scripts/check-kernel-headers.sh 
/home/neil/buildroot-2024.08/output/build 
/home/neil/buildroot-2024.08/output/host/aarch64-buildroot-linux-gnu/sysroot 
6.6 strict; then exit 1; fi
Incorrect selection of kernel headers: expected 6.6.x, got 6.1.x

Regards, Neil


On 2024-09-24 2:23 a.m., Arnout Vandecappelle wrote:
>
>
> On 23/09/2024 22:53, Neil Webster wrote:
>> Hi Arnout,
>>
>> Thanks for the quick response.
>>
>> I looked through the yocto build directory and it seems that they are 
>> using 6.1.1-1.0.0 for all of the below.
>>
>> BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_TARBALL_LOCATION
>>
>> BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION
>>
>> BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION
>>
>> So I changed them (.config attached).
>>
>> The build failed with the following ...
>>
>> ERROR: No hash found for linux-imx-lf-6.1.1-1.0.0.tar.gz
>> make[1]: *** [package/pkg-generic.mk:179: 
>> /home/neil/buildroot-2024.08/output/ 
>> build/linux-headers-custom/.stamp_downloaded] Error 1
>
>  You probably have BR2_DOWNLOAD_FORCE_CHECK_HASHES=y turned on because 
> you started from a defconfig that has a hash file. Either disable this 
> option, or update board/freescale/imx8mmevk/patches/linux/linux.hash 
> with the hash of the tarball.
>
>  Regards,
>  Arnout
>
>>
>> Thoughts on next steps appreciated.
>>
>> Thanks for your patience in working through this with a newbie.
>>
>> Cheers, Neil
>>
>> On 2024-09-23 3:36 p.m., Arnout Vandecappelle wrote:
>>>
>>>
>>> On 23/09/2024 21:30, Neil Webster wrote:
>>>> Hi Arnout,
>>>>
>>>> Thank you for the response.
>>>>
>>>> I will work through each of your suggestions and I started with the 
>>>> one that you stated was definitely incorrect i.e. The DTS name.
>>>>
>>>> The Variscite device trees are described here
>>>>
>>>> https://www.variscite.com/blog/getting-started-with-variscite-device-trees/ 
>>>>
>>>>
>>>> I found and copied three DTS(I) files
>>>>
>>>> imx8mm-var-dart-dt8mcustomboard.dts
>>>>
>>>> which #includes ...
>>>>
>>>> imx8mm-var-dart.dtsi
>>>>
>>>> which #includes ...
>>>>
>>>> imx8mm.dtsi
>>>
>>>  This one, at least, should be in the kernel source itself. If 
>>> you're using a kernel that doesn't already have imx8mm.dtsi, it's 
>>> probably going to be wildly incompatible with Variscite's device tree.
>>>
>>>
>>>> I referenced the location of these files in 
>>>> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH and I see it copies them to 
>>>> output/build/linux-custom/arch/arm64/boot/dts/
>>>>
>>>> The subsequent build complained about missing dependencies and I 
>>>> also had to add imx8mm-pinfunc.h and mxl-8611x.h to 
>>>> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH. Is that 
>>>
>>>  Again, these should normally be part of the  kernel already.
>>>
>>>> the correct way to add .h dependencies or is there a cleaner way or 
>>>> doing this i.e. should the BR2_LINUX_KERNEL_CUSTOM_DTS_PATH be 
>>>> reserved for DTS files only as the name suggests?
>>>
>>>  Not really - the header files are shared between device tree and 
>>> corresponding drivers. So they should already be part of the kernel 
>>> source. If they are not, it's quite likely that things are not going 
>>> to work.
>>>
>>>  There may be situations where it makes sense to add header files to 
>>> CUSTOM_DTS_PATH, but that's squarely You Must Know What You're Doing 
>>> territory...
>>>
>>>
>>>>
>>>> Anyway the build succeeded after adding those .h files but sadly 
>>>> still no console. I will now move onto looking at the other items 
>>>> you mentioned.
>>>
>>>  Well, I'd start with concentrating on getting output from TF-A and 
>>> U-Boot. Right now you don't even know if the kernel is loaded!
>>>
>>>
>>>  Regards,
>>>  Arnout
>>>
>>>
>>>>
>>>> Cheers, Neil
>>>>
>>>> On 2024-09-19 7:53 a.m., Arnout Vandecappelle wrote:
>>>>> [You don't often get email from arnout@mind.be. Learn why this is 
>>>>> important at https://aka.ms/LearnAboutSenderIdentification ]
>>>>>
>>>>>  Hi Neil,
>>>>>
>>>>> On 19/09/2024 00:19, Neil Webster wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am new to Buildroot and have been struggling for a couple of 
>>>>>> days with
>>>>>> something and wondering if I could get some pointers. Please let 
>>>>>> me know
>>>>>> if this is not the appropriate place to post such questions.
>>>>>>
>>>>>> I want to get an embedded Linux image running on a Variscite Dart 
>>>>>> Mini
>>>>>> (link below)
>>>>>>
>>>>>> https://www.variscite.com/product/system-on-module-som/cortex-a53-krait/ 
>>>>>> dart- mx8m-mini-nxp-i-mx8m-mini/
>>>>>>
>>>>>> I have the SOM connected to a dev kit referenced in the same link 
>>>>>> above.
>>>>>>
>>>>>> I wanted to use the opportunity to get familiar with Buildroot 
>>>>>> but sadly
>>>>>> Variscite do not support Buildroot and instead they steered me 
>>>>>> towards
>>>>>> Yocto.
>>>>>
>>>>>  :sad-face:
>>>>>
>>>>>
>>>>>> I have been able to get an image running with Yocto following their
>>>>>> recipes but I found the whole process to be obscure and opaque 
>>>>>> and I am
>>>>>> therefore back to my original objective of using Buildroot.
>>>>>
>>>>>  Please make sure to give this feedback to Variscite!
>>>>>
>>>>>
>>>>>>
>>>>>> I have been able to follow the tutorials and get a build working 
>>>>>> on a
>>>>>> Raspberry Pi.
>>>>>>
>>>>>> However, as mentioned above there is no support available from 
>>>>>> Variscite
>>>>>> and there is no specific defconfig for my hardware, so I tried to 
>>>>>> start
>>>>>> with freescale_imx8mmevk_defconfig as this seems to be close with 
>>>>>> what
>>>>>> appear to be correct settings under the "target options" menu.
>>>>>
>>>>>  Yes, that's an excellent start!
>>>>>
>>>>>  ... but not enough to get a working board...
>>>>>
>>>>>
>>>>>> However I am not getting anything at the console.
>>>>>>
>>>>>> I noticed that the freescale_imx8mmevk_defconfig sets the getty 
>>>>>> TTY port
>>>>>> to ttymxc1, so I tried changing this to ttymxc0 as that is the port
>>>>>> mapped to the debug interface on the development board. Still 
>>>>>> nothing at
>>>>>> the console.
>>>>>
>>>>>  That is one of the things you need to change indeed. However, 
>>>>> things already
>>>>> went wrong way before that, because you should have gotten U-Boot 
>>>>> and kernel
>>>>> debug output on the console.
>>>>>
>>>>>  There are a number of things you have to change in a defconfig 
>>>>> when you switch
>>>>> to a different (but similar) board. I'm going to list them below 
>>>>> with the symbol
>>>>> names, not how they appear in the menu. You can always search for 
>>>>> those symbols
>>>>> in `make menuconfig` by typing /
>>>>>
>>>>> BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_TARBALL_LOCATION="$(call
>>>>> github,nxp-imx,imx-atf,lf-6.6.23-2.0.0)/imx-atf-lf-6.6.23-2.0.0.tar.gz" 
>>>>>
>>>>>
>>>>> You should check Variscite's yocto layer to see if they use the 
>>>>> NXP TF-A or if
>>>>> they fork it even more. They may also use a different version.
>>>>>
>>>>>
>>>>> BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="imx8mm"
>>>>>
>>>>> I expect that this will be OK for the Variscite board as well, but 
>>>>> it is
>>>>> possible that they have defined their own platform.
>>>>>
>>>>>
>>>>>
>>>>> BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION="$(call
>>>>> github,nxp-imx,uboot-imx,lf-6.6.23-2.0.0)/uboot-imx-lf-6.6.23-2.0.0.tar.gz" 
>>>>>
>>>>>
>>>>> You should check Variscite's yocto layer to see if they use the 
>>>>> NXP U-Boot or if
>>>>> they fork it even more. They may also use a different version.
>>>>>
>>>>>
>>>>> BR2_TARGET_UBOOT_BOARD_DEFCONFIG="imx8mm_evk"
>>>>>
>>>>> This needs to change to the U-Boot defconfig. That defconfig could 
>>>>> be in NXP's
>>>>> U-Boot fork already, or it could be in Variscite's fork, or 
>>>>> Variscite may supply
>>>>> it in their u-boot yocto recipe.
>>>>>
>>>>>
>>>>> BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call
>>>>> github,nxp-imx,linux-imx,lf-6.6.23-2.0.0)/linux-imx-lf-6.6.23-2.0.0.tar.gz" 
>>>>>
>>>>> BR2_LINUX_KERNEL_DEFCONFIG="imx_v8"
>>>>> BR2_LINUX_KERNEL_INTREE_DTS_NAME="freescale/imx8mm-evk
>>>>> freescale/imx8mm-evk-revb-qca-wifi"
>>>>>
>>>>> You probably start to know the drill, right? The defconfig is 
>>>>> probably OK,
>>>>> although it's possible that Variscite appends a fragment to it in 
>>>>> their
>>>>> bbappend. The DTS name is most definitely not OK, but it might 
>>>>> come from
>>>>> Variscite's metalayer instead of NXP's kernel. The kernel is 
>>>>> unlikely to be
>>>>> forked by Variscite so that one is probably OK, but it may be a 
>>>>> different version.
>>>>>
>>>>>
>>>>>> I tried changing the init system from busybox to systemd. Still 
>>>>>> nothing.
>>>>>
>>>>>  No, busybox init should work fine.
>>>>>
>>>>>
>>>>>> I feel like I am poking around in the dark. Any thoughts on what I
>>>>>> should try next?
>>>>>
>>>>>  If you do manage to advance with this, there are two 
>>>>> contributions you could make:
>>>>> - You can add a defconfig for the Variscite board.
>>>>> - You could update the documentation with a "how to add support 
>>>>> for a new board"
>>>>> section that explains what I wrote above in a better (more 
>>>>> generic) way.
>>>>>
>>>>>
>>>>>  Regards,
>>>>>  Arnout
>>>>>
>>>
>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot