Re: [Buildroot] Variscite Dart

[Neil Webster <jarraneil@gmail.com>]

Hi Arnout,

Been digging a bit more. It seems that I have an issue with my 
definition of the URL for the kernel tarball. The path I have defined 
has multiple possibilities. I will do some more research on this.

Cheers, Neil

On 2024-09-23 4:53 p.m., 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
>
> 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