[U-Boot] Updating uboot from 2015.04 to 2017.03 - doubts and other questions

[U-Boot] Updating uboot from 2015.04 to 2017.03 - doubts and other questions

[Nemanja Savic]

Hi all list members,

this is my first post. I am almost new to u-boot, which means that a few
times in my life I had tasks to implement some commands and perform
initialization of GPIOS, etc. In summary very simple tasks. Now I have a
bit harder tasks - to update from version 2015.04 to 2017.03. The board is
based on i.mx6 Sabre Auto DualLite, so I am speaking of fscl u-boot.

I would like to clarify a few things:
1. When previously dealt with u-boot, the configuration of the board was
done by using #define SOMETHING. As far as I could see, u-boot is now able
to read the device tree and to load drivers based on that. Is this
preferred way of configuring u-boot now? If yes where can I find more
information about this with some examples. The thing is, my device tree has
gpio-led entry, but unfortunately i don't see debug messages I am printing
withing driver probe function (I print usinf printf, maybe other way of
printing should be used).

2. How not to use device tree for loading drivers at all? When I set
CONFIG_OF_CONTROL=n
I am not able to compile the code.

3. Is device tree used by u-boot the same device tree later used by linu
kernel?

4. How can to know if I should use menuconfig or not?

Thank you very much I hope we will have a great time in the list :D

[U-Boot] Updating uboot from 2015.04 to 2017.03 - doubts and other questions

[Adam Ford]

On Tue, Jul 23, 2019 at 12:32 PM Nemanja Savic <vlasinac@gmail.com> wrote:
>
> Hi all list members,
>
> this is my first post. I am almost new to u-boot, which means that a few
> times in my life I had tasks to implement some commands and perform
> initialization of GPIOS, etc. In summary very simple tasks. Now I have a
> bit harder tasks - to update from version 2015.04 to 2017.03. The board is
> based on i.mx6 Sabre Auto DualLite, so I am speaking of fscl u-boot.
>

If you want to look at the overall history and progression, I would
suggest looking at commit history for the defconfig file from which
your device was based.

I don't know if it's the right board, but you can try this:
https://gitlab.denx.de/u-boot/u-boot/commits/master/configs/mx6sabreauto_defconfig


> I would like to clarify a few things:
> 1. When previously dealt with u-boot, the configuration of the board was
> done by using #define SOMETHING. As far as I could see, u-boot is now able
> to read the device tree and to load drivers based on that. Is this
> preferred way of configuring u-boot now? If yes where can I find more
> information about this with some examples. The thing is, my device tree has
> gpio-led entry, but unfortunately i don't see debug messages I am printing
> withing driver probe function (I print usinf printf, maybe other way of
> printing should be used).

Much of the #defines have been migrating to Kconfig which places the
default values for a given board into _defconfig files.  If you are
looking for an option previously defined in the include/configs/, you
might find them now located in corresponding defconfig file.  If you
want to enable something, check to see if it's in the menuconfig.
>
> 2. How not to use device tree for loading drivers at all? When I set
> CONFIG_OF_CONTROL=n
> I am not able to compile the code.

CONFIG_OF_CONTROL is part of the equation, but many of the drivers
were and are still being migrated to a new driver model (DM) and
OF_CONTROL requires the DM to be enabled.  I have an imx6 board that I
am trying to maintain, and using DM has become more and more of a
requirement, and OF_CONTROL is becoming the default because you can
greatly reduce the amount of board specific code by having the system
scan the device tree.
>
> 3. Is device tree used by u-boot the same device tree later used by linu
> kernel?

On my imx6q_logic board, the device tree is appended to the code, but
it's only used for U-Boot and or SPL.  SPL is the secondary program
loader, and it has a much reduced device tree because of the limited
space.  I load a separate device tree for the kernel, because I keep
the kernels and their respecive device trees in sync to prevent
issues.
>
> 4. How can to know if I should use menuconfig or not?

I would recommend looking at the  i.mx6 Sabre Auto DualLite
configurations, both the _defconfig and the include/configs files as a
starting point.  You can always search the menuconfig for various
options.  Many of the device drivers are organized in a similar
manner.
>
> Thank you very much I hope we will have a great time in the list :D

Best wishes.

adam
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] Updating uboot from 2015.04 to 2017.03 - doubts and other questions

[Nemanja Savic]

Thank you Adam for your answer. Sounds like a good starting point for me.
Additionally I would like to ask you further questions regarding your
answers.

> 3. Is device tree used by u-boot the same device tree later used by linu
>
>> > kernel?
>>
>> On my imx6q_logic board, the device tree is appended to the code, but
>> it's only used for U-Boot and or SPL.  SPL is the secondary program
>> loader, and it has a much reduced device tree because of the limited
>> space.  I load a separate device tree for the kernel, because I keep
>> the kernels and their respecive device trees in sync to prevent
>> issues.
>>
>
Does that mean that dtb is already part of the u-boot image? After making
mx6sabreauto_defconfig, the u-boot binary is called something like (I am
not at work at the moment) uboot-dtb.imx, which might imply that dtb is
already part of the binary?

Another question is, which macro or function should I use to print simple
debug messages from the driver function such as probe, etc ...?

Cheers!