[meta-freescale] Questions on adapt yocto to a custom board

[Daiane Angolini]

On Fri, Aug 7, 2015 at 4:24 AM,  <andrea at perpic.it> wrote:
> Hello Daiane,
>
> Thank you I got the file.
> As per the other guide there is a reference to <UBOOT_DIR>/boards.cfg
> that file is not present in my u-boot dir.
> if I do bitbake -c devshell virtual/bootloader I get:
> tmp/work/av_imx-poky-linux-gnueabi/u-boot-fslc/v2014.10+gitAUTOINC
> +5fd0b607d0-r0/git
>
> I see that I was using u-boot-fslc and not a u-boot-imx as stated in the
> guide. Adding
> PREFERRED_PROVIDER_virtual/bootloader = "u-boot-imx" in local.conf
> changed the bootloader to u-boot. there's no reference to imx in the
> path
> tmp/work/av_imx-poky-linux-gnueabi/u-boot/v2013.07+gitAUTOINC
> +62c175fbb8-r0/git
> but I have a boards.cfg
>
> What is the difference from the two bootloader versions? Why should I
> choose one instead of the other? And... It's the right one? as written
> in the guide?

In my point of view, any new u-boot work should be done using mainline
as base (latest stable).

I understand the temptation to separate the world between right and
wrong, but we all know it's a gray world, not a black and white world.

Take a look in [1] to understand what our community is, and in [2] to
see the list of all u-boot forks provided by FSL Community BSP.

[1] http://freescale.github.io/doc/release-notes/1.8/
[2] http://freescale.github.io/doc/release-notes/1.8/index.html#bootloaders

I'm really trying to not be unkind (which is really difficult in plain
text only), but the definition of what is the right base of work for
your very one project is something you must answer.

What do you think is the best u-boot to base your work on?

Daiane

>
> thank you
> Andrea
>
>
> Il giorno gio, 06/08/2015 alle 18.01 +0200, Daiane Angolini ha scritto:
>> On Thu, Aug 6, 2015 at 12:20 PM,  <andrea at perpic.it> wrote:
>> > Il giorno gio, 06/08/2015 alle 16.05 +0200, Daiane Angolini ha scritto:
>> >> On Thu, Aug 6, 2015 at 4:52 AM,  <andrea at perpic.it> wrote:
>> >> > Hello everybody,
>> >>
>> >> Hi
>> >
>> > Thank you Daiane for your reply
>> >>
>> >> >
>> >> > It's some day that I'm surfing the net looking for the answer to my
>> >> > question, I don't find any useful information because it looks to me
>> >> > that all the solutions in in some way tricks and not clean solutions.
>> >> >
>> >> > My case:
>> >> > I have an IMX53 custom board that is similar to loco but I added some
>> >> > gpio and other function due to my application needs. (I think this
>> >> > situation is common for everybody that produces dedicated hardware also
>> >> > for other processors.)
>> >> >
>> >> > For adding complexity... All the documentation I can see on the net is
>> >> > related OR to LTIB OR to IMX6 that uses a different kernel version so
>> >> > files are in different locations or with different names.
>> >> >
>> >> > Finally my question:
>> >> > What is the best way for deal with a new hardware?
>> >>
>> >> Start with DDR script, go to u-boot development, go to kernel bring up.
>> > Yes, It's what I am planning to do.
>> >>
>> >>
>> >> > Adapt all the file from (u-boot / kernel) of the more similar board for
>> >> > adapt to my needs or create a new board?
>> >>
>> >> For u-boot case, use mainline and add your board in the latest stable
>> >> (or upstream it)
>> >>
>> >> For kernel, I prefer to not comment. There are several possible ways to go.
>> >>
>> >> >
>> >> > case 1: I think it's simples because what is already working continue to
>> >> > work but I expect less flexibility because if I need to have a variant
>> >> > of that board I need to manage two different layers depends on the board
>> >> > I need to compile.
>> >> >
>> >> > case 2: create a new u-boot / kernel configuration for my board.
>> >> > I expect more difficult at the beginning, find the right files to copy,
>> >> > build the new versions of the firmware etc. Also every new changes on
>> >> > the original board will be lost if I don't change them in my new files
>> >>
>> >> In case you have the original board, it can be used as a benchmark
>> >> during your bringup work.
>> > I have IMX53qsb and my own board.
>> > I can boot up the system and reach the prompt with small modifications
>> > to u-boot. The socket for the mmc is a bit different and levels for card
>> > detection are swapped. as I wrote before, I tried to keep my hardware as
>> > similar as possible to the qsb.
>> >>
>> >> If you don't have the original board. I'm not sure if the 2 cases are different.
>> >>
>> >>
>> >> > What do you usually do?
>> >> > What do you think are the problems with case 1 and case 2?
>> >> >
>> >> > Are you aware of any guide that I can follow for case 1 and / or case 2?
>> >> > I am thinking about... iomux, flexcan initialization...
>> >>
>> >> Have you read already the Porting guide for i.MX6? During the bringup,
>> >> i.mx53 and i.mx6 is not ~that much~ different. Read that document and
>> >> follow that guidelines to your board. If you don't know where to find
>> >> it, let me know.
>> > Are you referring to this one?
>> > https://community.freescale.com/docs/DOC-100203
>>
>> This one
>>
>> https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20Information&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=gz&WT_ASSET=Documentation&fileExt=.gz&Parent_nodeId=1337637154535695831062&Parent_pageType=product
>>
>> It is a bundle of several files regarding L3.14.28 GA release. One of
>> them is the porting guide.
>>
>> Daiane
>> >
>> > If it is I read it. At the moment I'm stuck with some file that are in
>> > different location. For example I can't find any boards.cfg file in the
>> > top level directory of u-boot. (Point 1 of Porting Bootloader)
>> >
>> > find . -name board
>> > ./board
>> > ./post/board
>> > ./.pc/0001-change-boot-params.patch/board
>> >
>> > maybe it was renamed?
>> > the question that came in my head after I solve this... I created a
>> > imx_(myboard) in my custom layer. How I tell to bitbake that it needs to
>> > use my own configuration of u-boot?
>> >
>> >>
>> >>
>> >> Daiane
>> >> >
>> >> > Any input will be appreciated
>> >> > thank you for reading the long post
>> >> > best regards
>> >> > Andrea
>> >> > --
>> >> > _______________________________________________
>> >> > meta-freescale mailing list
>> >> > meta-freescale at yoctoproject.org
>> >> > https://lists.yoctoproject.org/listinfo/meta-freescale
>> >
>> > Thank you again
>> > Andrea
>> >
>> >
>