[U-Boot] FDT howto

Fri Mar 1 21:24:42 CET 2013

Hi Jagan,

On Fri, Mar 1, 2013 at 11:14 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> Hi Simon,
>
> On Fri, Mar 1, 2013 at 10:07 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Jagan,
>>
>> On Thu, Feb 28, 2013 at 12:29 PM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg at chromium.org> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg at chromium.org> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg at chromium.org> wrote:
>>>>>>>>>>> Hi Jegan,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg at chromium.org> wrote:
>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for your response, please find my below comments.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:24 PM, Simon Glass <sjg at chromium.org> wrote:
>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am planning to use devicetree on u-boot.
>>>>>>>>>>>>>>>> I have an experience to work with devicetree on Linux.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For u-boot, I have read doc from doc/README.fdt-control.
>>>>>>>>>>>>>>>> I see some dts usages on tegra boards.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have lot of confusions with the concept itself.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is Linux and u-boot devicetree concept and build system are same?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't really understand this question sorry. U-Boot and Linux use
>>>>>>>>>>>>>>> the device tree mainly for run-time configuration of drivers, so that
>>>>>>>>>>>>>>> the same driver code can operate on different boards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am some how confusing the fdt usage in u-boot.
>>>>>>>>>>>>>> Because when compared to Linux, u-boot fdt setup mandatory to require
>>>>>>>>>>>>>> the CONFIG_DEFAULT_DEVICE_TREE
>>>>>>>>>>>>>> on the config file [from your previous comments].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> is this the only difference when compared to Linux i guess..is it?
>>>>>>>>>>>>>> Linux defconfig file does need to hot-code
>>>>>>>>>>>>>> the dts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes - that is a difference. Linux provides a way to build .dts files
>>>>>>>>>>>>> but it is not mandatory. At present it is mandatory with U-Boot, and
>>>>>>>>>>>>> only one file is built. It can easily be ignored though.
>>>>>>>>>>>>
>>>>>>>>>>>> Ok.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Suppose I have 4 boards J1, J2, J3 & J4 on my soc "emb".of vendor "vast"
>>>>>>>>>>>>>>>>    For this requirement I have
>>>>>>>>>>>>>>>>    board/vast/dts/J1.dts
>>>>>>>>>>>>>>>>    board/vast/dts/J2.dts
>>>>>>>>>>>>>>>>    board/vast/dts/J3.dts
>>>>>>>>>>>>>>>>    board/vast/dts/J4.dts
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    include/configs/emb_common.h ==> single configuration of all SOC
>>>>>>>>>>>>>>>> needed definitions
>>>>>>>>>>>>>>>>    like defconfig in Linux.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    do I need any more files?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's enough for the basics I think.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is dtsi file require to add it on arch folder along with above.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If your architecture is not one of those already supported (like arm
>>>>>>>>>>>>> tegra/exynos and x86) then yes you need to add this file in
>>>>>>>>>>>>> arch/<arch>/dts. What architecture are you using?
>>>>>>>>>>>>
>>>>>>>>>>>> My architecture is armv7, may be for me dtsi not required as arm is
>>>>>>>>>>>> existing architecture
>>>>>>>>>>>> to support fdt on u-boot.. is it?
>>>>>>>>>>>
>>>>>>>>>>> Which sub-arch? If it is tegra/exynos5250 then you might be OK. For
>>>>>>>>>>> something else, you should get the kernel's .dtsi file for that chip.
>>>>>>>>>>
>>>>>>>>>> I am having armv7, xilinx zynq soc..but i coun't get any .dtsi on kernel source.
>>>>>>>>>> may be I will create new one.
>>>>>>>>>
>>>>>>>>> OK, well if the kernel doesn't have FDT support yet then yes you will
>>>>>>>>> need to create a new one.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    In emb_common.h i am defining
>>>>>>>>>>>>>>>>    CONFIG_OF_SEPARATE is it sufficient?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And CONFIG_OF_CONTROL
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    My plan is to build u-boot and then build the dtb with specific
>>>>>>>>>>>>>>>> board and then combine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's fine, and is how we do things on Chromium also. U-Boot tries to
>>>>>>>>>>>>>>> build an FDT even with CONFIG_OF_SEPARATE, so you need to put a
>>>>>>>>>>>>>>> default device tree file in your emb_common.h file that it can find.
>>>>>>>>>>>>>>> But you can ignore it, and for flashing your boards just use
>>>>>>>>>>>>>>> u-boot.bin plus whatever .dtb you want to select.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So I will add the fdt support and then build the u-boot.
>>>>>>>>>>>>>> Is there any separate u-boot build command to build dts file.
>>>>>>>>>>>>>> My plan is to combine both u-boot and dtb.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can run dtc yourself if you like - see Makefile/dts for how it is
>>>>>>>>>>>>> done there. Once you have the .dtb binary, the easiest thing is to add
>>>>>>>>>>>>> it to the end of u-boot.bin, as described in README.fdt-control.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks, I tried with above setup for adding dts.
>>>>>>>>>>>> I have added simple dts file on my board.
>>>>>>>>>>>>
>>>>>>>>>>>> I got the below build error
>>>>>>>>>>>> /proj/mypc/u-boot/include/asm/gpio.h:1:27: fatal error:
>>>>>>>>>>>> asm/arch/gpio.h: No such file or directory
>>>>>>>>>>>> compilation terminated.
>>>>>>>>>>>> make[1]: *** No rule to make target `.depend.fdtdec', needed by
>>>>>>>>>>>> `.depend'.  Stop.
>>>>>>>>>>>>
>>>>>>>>>>>> is gpio.h is mandatory for fdt build?
>>>>>>>>>>>
>>>>>>>>>>> Yes because basic GPIO support is included. You can create one for
>>>>>>>>>>> your sub-arch and make it #include <asm-generic/gpio.h> as a starting
>>>>>>>>>>> point.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Should I create an empty gpio.h file..it still asking some gpio
>>>>>>>>>> definitions right..
>>>>>>>>>
>>>>>>>>> It might be OK if you just have "#include <asm-generic/gpio.h>" in that file.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Finally I have created u-boot-dtb.bin.
>>>>>>>> for building dtb separately I have used
>>>>>>>> $ make DEVICE_TREE=zynq .. it creates a u-boot.dtb
>>>>>>>>
>>>>>>>> is there any option for building separate name, for example I need to
>>>>>>>> create zynq.dtb
>>>>>>
>>>>>> No - but  you can just use 'mv' in a script external to the U-Boot build system.
>>>>>>
>>>>>>>
>>>>>>> Some how I am able to create a fdt build on my target.
>>>>>>> But what is this gpio mandatory, because currently my target currently
>>>>>>> need a GPIO setup.
>>>>>>> Add ing gpio.h/ with equivalent definitions is an extra overhead is
>>>>>>> it? please explain.
>>>>>>
>>>>>> It is just a header file - unless you actually use the GPIO functions,
>>>>>> you can compile with -ffunction-sections and you won't get the GPIO
>>>>>> code included. Anyway, the overhead is small, if any.
>>>>>
>>>>> OK, Thanks for your information.
>>>>>
>>>>> I have few quires regarding getting details from devicetree nodes.
>>>>> 1) In case of drivers, I think we need add the MACROS on
>>>>>     // lib/fdtdec.c
>>>>>     static const char * const compat_names[COMPAT_COUNT] = {
>>>>>     is it?
>>>>
>>>> Yes that's what is normally done. At present it mostly just provides a
>>>> way to register existing FDT use in U-Boot.
>>>
>>> OK.
>>>
>>>>
>>>>> 2) What is the procedure for DDR base and size information getting
>>>>>      memory {
>>>>>                 reg = <0x00000000 0x40000000>;
>>>>>         };
>>>>>     I need to get the above details from memory node of dts and
>>>>> updated while doing
>>>>>     dram_init()
>>>>>     is it possible in u-boot right now?
>>>>
>>>> There is no particular support for dram_init(). You could call
>>>> fdtdec_decode_region() to get the information.
>>>
>>> Actually we may get the info through memory node using
>>> fdtdec_decode_region() for
>>> dram_init(), but the problem seems like other than this the SDRAM base
>>> and SDSIZE are using in
>>> CONFIG_SYS_MEMTEST_START and CONFIG_SYS_MEMTEST_END.
>>>
>>> As these are part of configuration macros, I don't clear how we can
>>> get the base,sizes from dts and assign these
>>> areas..any suggestions..?
>>
>> Well this is because configuration has traditionally been done with
>> CONFIG defines instead of device tree. CONFIG_OF_CONTROL is a
>> relatively new feature in U-Boot.
>>
>> If you are wanting to control the memtest area from device tree, you
>> might consider adding something to the '/config' node, since this is
>> where we tend to put general configuration. You probably can't test
>> all of memory, so you need to select the region.
>
> Thanks for your information.
>
> I am able to get the memory information using fdtdec_decode_region().
>
> So my CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_SDRAM_SIZE dependencies
> on board file got resolved. but there is a dependency for
> CONFIG_SYS_SDRAM_BASE on
> arch/arm/lib/board.c.
>
> I have some thinking about this dependency to remove can we declare
> ram_base like ram_size
> so-that in ddr_init we can assign this value.. is my thinking valid..???'

Yes that sounds reasonable. For that you could perhaps use the memory
{} node, like:

	memory {
		reg = <0x40000000 0x80000000>;
	};

Regards,
Simon

>
> Any suggestions..
>
> Thanks,
> Jagan.
>
>>
>>>
>>>>
>>>>>  3) and same case for chosen also..are these implemented currently.
>>>>
>>>> The bootargs environment variable is placed in the kernel FDT when
>>>> booting the kernel. But 'chosen' is not used in the U-Boot FDT. This
>>>> is support instead for a '/config' node - see e.g.
>>>> fdtdec_get_config_int().
>>>
>>> OK, thank you.
>>>
>>> Thanks,
>>> Jagan.
>>
>> Regards,
>> Simon