[U-Boot] FDT howto

[U-Boot] FDT howto

[Jagan Teki]

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?

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?

   In emb_common.h i am defining
   CONFIG_OF_SEPARATE is it sufficient?

   My plan is to build u-boot and then build the dtb with specific
board and then combine.

I saw that all tegra boards config files are defining
CONFIG_DEFAULT_DEVICE_TREE if ie. the case dts is a compile time
option right.
am i correct?

Please let me know your inputs.

--
Thanks,
Jagan.

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon/all,

Can anyone help me out.

Thanks,
Jagan.

On Thu, Feb 21, 2013 at 10:33 PM, Jagan Teki <jagannadh.teki@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?
>
> 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?
>
>    In emb_common.h i am defining
>    CONFIG_OF_SEPARATE is it sufficient?
>
>    My plan is to build u-boot and then build the dtb with specific
> board and then combine.
>
> I saw that all tegra boards config files are defining
> CONFIG_DEFAULT_DEVICE_TREE if ie. the case dts is a compile time
> option right.
> am i correct?
>
> Please let me know your inputs.
>
> --
> Thanks,
> Jagan.

[U-Boot] FDT howto

[Simon Glass]

Hi Jagan,

On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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.

>
> 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.

>
>    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.

>
> I saw that all tegra boards config files are defining
> CONFIG_DEFAULT_DEVICE_TREE if ie. the case dts is a compile time
> option right.
> am i correct?

Yes - see above. This is convenient for testing and development.

>
> Please let me know your inputs.

Regards,
Simon

>
> --
> Thanks,
> Jagan.

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

Thanks for your response, please find my below comments.

On Sun, Feb 24, 2013 at 9:24 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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.

>
>>
>> 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.

>
>>
>>    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.

Thanks,
Jagan.

>
>>
>> I saw that all tegra boards config files are defining
>> CONFIG_DEFAULT_DEVICE_TREE if ie. the case dts is a compile time
>> option right.
>> am i correct?
>
> Yes - see above. This is convenient for testing and development.
>
>>
>> Please let me know your inputs.
>
> Regards,
> Simon
>
>>
>> --
>> Thanks,
>> Jagan.

[U-Boot] FDT howto

[Simon Glass]

Hi Jagan,

On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>> Hi Jagan,
>>
>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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.

>
>>
>>>
>>> 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?

>
>>
>>>
>>>    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,
> Jagan.
>
>>
>>>
>>> I saw that all tegra boards config files are defining
>>> CONFIG_DEFAULT_DEVICE_TREE if ie. the case dts is a compile time
>>> option right.
>>> am i correct?
>>
>> Yes - see above. This is convenient for testing and development.
>>
>>>
>>> Please let me know your inputs.
>>
>> Regards,
>> Simon
>>
>>>
>>> --
>>> Thanks,
>>> Jagan.

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>> Hi Jagan,
>>>
>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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?

>
>>
>>>
>>>>
>>>>    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?

Thanks,
Jagan.

>
>>
>> Thanks,
>> Jagan.
>>
>>>
>>>>
>>>> I saw that all tegra boards config files are defining
>>>> CONFIG_DEFAULT_DEVICE_TREE if ie. the case dts is a compile time
>>>> option right.
>>>> am i correct?
>>>
>>> Yes - see above. This is convenient for testing and development.
>>>
>>>>
>>>> Please let me know your inputs.
>>>
>>> Regards,
>>> Simon
>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Jagan.

[U-Boot] FDT howto

[Simon Glass]

Hi Jegan,

On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Simon,
>
> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jagan,
>>
>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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.

>
>>
>>>
>>>>
>>>>>
>>>>>    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.

Regards,
Simon

>
> Thanks,
> Jagan.
>
>>
>>>
>>> Thanks,
>>> Jagan.
>>>
>>>>
>>>>>
>>>>> I saw that all tegra boards config files are defining
>>>>> CONFIG_DEFAULT_DEVICE_TREE if ie. the case dts is a compile time
>>>>> option right.
>>>>> am i correct?
>>>>
>>>> Yes - see above. This is convenient for testing and development.
>>>>
>>>>>
>>>>> Please let me know your inputs.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Jagan.

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Jegan,
>
> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Jagan,
>>>
>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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.

>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>    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..

Thanks,
Jagan.

> Regards,
> Simon
>
>>
>> Thanks,
>> Jagan.
>>
>>>
>>>>
>>>> Thanks,
>>>> Jagan.
>>>>
>>>>>
>>>>>>
>>>>>> I saw that all tegra boards config files are defining
>>>>>> CONFIG_DEFAULT_DEVICE_TREE if ie. the case dts is a compile time
>>>>>> option right.
>>>>>> am i correct?
>>>>>
>>>>> Yes - see above. This is convenient for testing and development.
>>>>>
>>>>>>
>>>>>> Please let me know your inputs.
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks,
>>>>>> Jagan.

[U-Boot] FDT howto

[Simon Glass]

Hi,

On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Simon,
>
> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jegan,
>>
>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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.

Regads,
Simon

[snip]

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi,
>
> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Jegan,
>>>
>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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

Thanks,
Jagan.

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Simon,
>
> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi,
>>
>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Jegan,
>>>>
>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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

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.

Thanks,
Jagan.

[U-Boot] FDT howto

[Simon Glass]

Hi Jagan,

On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Simon,
>
> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi,
>>>
>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi Jegan,
>>>>>
>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>> Hi Jagan,
>>>>>>>>>
>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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.

Regards,
Simon

>
> Thanks,
> Jagan.

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi,
>>>>
>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Jegan,
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>> Hi Jagan,
>>>>>>>>>>
>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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?
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?
 3) and same case for chosen also..are these implemented currently.

Request your inputs.

Thanks,
Jagan.

[U-Boot] FDT howto

[Simon Glass]

Hi Jagan,

On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Simon,
>
> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jagan,
>>
>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi,
>>>>>
>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>> Hi Jegan,
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>> Hi Jagan,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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.

> 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.

>  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().

>
> Request your inputs.
>
> Thanks,
> Jagan.

Regards,
Simon

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Simon,
>>
>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Jagan,
>>>
>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> Hi Jegan,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>> Hi Jagan,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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..?

>
>>  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.

[U-Boot] FDT howto

[Simon Glass]

Hi Jagan,

On Thu, Feb 28, 2013 at 12:29 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Simon,
>
> On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jagan,
>>
>> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>> Hi Jegan,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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.

>
>>
>>>  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

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

On Fri, Mar 1, 2013 at 10:07 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On Thu, Feb 28, 2013 at 12:29 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Simon,
>>
>> On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Jagan,
>>>
>>> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>> Hi Jegan,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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..???

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

[U-Boot] FDT howto

[Simon Glass]

Hi Jagan,

On Fri, Mar 1, 2013 at 11:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Simon,
>
> On Fri, Mar 1, 2013 at 10:07 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jagan,
>>
>> On Thu, Feb 28, 2013 at 12:29 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>> Hi Jegan,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

On Sat, Mar 2, 2013 at 1:54 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On Fri, Mar 1, 2013 at 11:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Simon,
>>
>> On Fri, Mar 1, 2013 at 10:07 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Jagan,
>>>
>>> On Thu, Feb 28, 2013 at 12:29 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>> Hi Jegan,
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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>;
>         };

I will confirm my logic here for better clarification.

typedef struct  global_data {
   phys_size_t     ram_size;       /* RAM size */
+ phys_size_t     ram_base;       /* RAM base */
} gd_t;

in boards files:
---

int ddr_init() {
//
get the memory info from dts store it on start and size
//
gd->ram_start = start;
gd->ram_size = size;

 gd->bd->bi_dram[0].start = start;
 gd->bd->bi_dram[0].size = size;
}

Please comment.

Thanks,
Jagan.

>
> 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

[U-Boot] FDT howto

[Simon Glass]

Hi Jagan,

On Fri, Mar 1, 2013 at 1:21 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Simon,
>
> On Sat, Mar 2, 2013 at 1:54 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jagan,
>>
>> On Fri, Mar 1, 2013 at 11:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Fri, Mar 1, 2013 at 10:07 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Thu, Feb 28, 2013 at 12:29 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>>> Hi Jegan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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>;
>>         };
>
> I will confirm my logic here for better clarification.
>
> typedef struct  global_data {
>    phys_size_t     ram_size;       /* RAM size */
> + phys_size_t     ram_base;       /* RAM base */
> } gd_t;
>
> in boards files:
> ---
>
> int ddr_init() {
> //
> get the memory info from dts store it on start and size
> //
> gd->ram_start = start;
> gd->ram_size = size;
>
>  gd->bd->bi_dram[0].start = start;
>  gd->bd->bi_dram[0].size = size;
> }
>
> Please comment.

That sounds reasonable. I suppose you could cope with multiple memory
regions also - I'm not sure what the device tree syntax is for that.

Regards,
Simon

>
> Thanks,
> Jagan.
>
>>
>> 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

[U-Boot] FDT howto

[Jagan Teki]

Hi Simon,

On Sat, Mar 2, 2013 at 6:30 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Jagan,
>
> On Fri, Mar 1, 2013 at 1:21 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sat, Mar 2, 2013 at 1:54 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Jagan,
>>>
>>> On Fri, Mar 1, 2013 at 11:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Fri, Mar 1, 2013 at 10:07 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On Thu, Feb 28, 2013 at 12:29 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>> Hi Jagan,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>>>> Hi Jegan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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>;
>>>         };
>>
>> I will confirm my logic here for better clarification.
>>
>> typedef struct  global_data {
>>    phys_size_t     ram_size;       /* RAM size */
>> + phys_size_t     ram_base;       /* RAM base */
>> } gd_t;
>>
>> in boards files:
>> ---
>>
>> int ddr_init() {
>> //
>> get the memory info from dts store it on start and size
>> //
>> gd->ram_start = start;
>> gd->ram_size = size;
>>
>>  gd->bd->bi_dram[0].start = start;
>>  gd->bd->bi_dram[0].size = size;
>> }
>>
>> Please comment.
>
> That sounds reasonable. I suppose you could cope with multiple memory
> regions also - I'm not sure what the device tree syntax is for that.

This is the syntax for above example:
memory {
     reg = <0x0 0x40000000>;
};

Any side effect in my previous code [snip] w.r.t multiple bank supports.

Moving CONFIG_SYS_SDRAM_BASE: to ram_start is that a good idea?, as lot
of boards were using it..

I am planning code fdtdec_get_memory_region() to move the these memory detection
code, so-that it should be a generic for u-boot if the use is using
fdt. any comments.

Thanks,
Jagan.

>
> Regards,
> Simon
>
>>
>> Thanks,
>> Jagan.
>>
>>>
>>> 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

[U-Boot] FDT howto

[Simon Glass]

Hi Jagan,

On Fri, Mar 1, 2013 at 11:44 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Simon,
>
> On Sat, Mar 2, 2013 at 6:30 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Jagan,
>>
>> On Fri, Mar 1, 2013 at 1:21 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Sat, Mar 2, 2013 at 1:54 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Fri, Mar 1, 2013 at 11:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Fri, Mar 1, 2013 at 10:07 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Thu, Feb 28, 2013 at 12:29 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>> Hi Jagan,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>>>>> Hi Jegan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki <jagannadh.teki@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@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki <jagannadh.teki@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>;
>>>>         };
>>>
>>> I will confirm my logic here for better clarification.
>>>
>>> typedef struct  global_data {
>>>    phys_size_t     ram_size;       /* RAM size */
>>> + phys_size_t     ram_base;       /* RAM base */
>>> } gd_t;
>>>
>>> in boards files:
>>> ---
>>>
>>> int ddr_init() {
>>> //
>>> get the memory info from dts store it on start and size
>>> //
>>> gd->ram_start = start;
>>> gd->ram_size = size;
>>>
>>>  gd->bd->bi_dram[0].start = start;
>>>  gd->bd->bi_dram[0].size = size;
>>> }
>>>
>>> Please comment.
>>
>> That sounds reasonable. I suppose you could cope with multiple memory
>> regions also - I'm not sure what the device tree syntax is for that.
>
> This is the syntax for above example:
> memory {
>      reg = <0x0 0x40000000>;
> };

My question was how can you handle multiple regions in device tree. Is it:

memory {
     /* 256MB at 0, 256MB at 512MB */
     reg = <0x0 0x10000000   0x20000000 0x10000000>;
};

or something else. If you can't find out you could ask on devicetree-discuss.

>
> Any side effect in my previous code [snip] w.r.t multiple bank supports.
>
> Moving CONFIG_SYS_SDRAM_BASE: to ram_start is that a good idea?, as lot
> of boards were using it..

Actually I don't see this symbol being used anywhere, although I agree
it appears in board config files.

board/emk/top860/top860.c
98:		memctl->memc_br2 = CONFIG_SYS_DRAM_BASE | BR_MS_UPMA | BR_V;

include/configs/trizepsiv.h
194:#define CONFIG_SYS_DRAM_BASE		0xa0000000

include/configs/pxa255_idp.h
273:#define CONFIG_SYS_DRAM_BASE		0xa0000000

include/configs/lubbock.h
127:#define CONFIG_SYS_LOAD_ADDR	(CONFIG_SYS_DRAM_BASE + 0x8000) /*
default load address */
158:#define CONFIG_SYS_DRAM_BASE		0xa0000000

include/configs/TOP860.h
76:#define	CONFIG_SYS_DRAM_BASE	0x00000000	/* DRAM in final mapping */

include/configs/colibri_pxa270.h
127:#define	CONFIG_SYS_DRAM_BASE		0xa0000000	/* CS0 */

include/configs/palmtc.h
145:#define	CONFIG_SYS_DRAM_BASE		0xa0000000	/* CS0 */
151:#define	CONFIG_SYS_LOAD_ADDR		CONFIG_SYS_DRAM_BASE

include/configs/balloon3.h
116:#define	CONFIG_SYS_DRAM_BASE		0xa0000000	/* CS0 */

include/configs/vpac270.h
182:#define	CONFIG_SYS_DRAM_BASE		0xa0000000	/* CS0 */

include/configs/xaeniax.h
157:#define CONFIG_SYS_DRAM_BASE		0xa0000000

include/configs/palmld.h
143:#define	CONFIG_SYS_DRAM_BASE		0xa0000000	/* CS0 */
149:#define	CONFIG_SYS_LOAD_ADDR		CONFIG_SYS_DRAM_BASE

include/configs/zipitz2.h
172:#define	CONFIG_SYS_DRAM_BASE		0xa0000000	/* CS0 */
178:#define	CONFIG_SYS_LOAD_ADDR		CONFIG_SYS_DRAM_BASE


>
> I am planning code fdtdec_get_memory_region() to move the these memory detection
> code, so-that it should be a generic for u-boot if the use is using
> fdt. any comments.

Sounds good. Then you probably want to try to fit this into the
generic board support, patches are here:

http://patchwork.ozlabs.org/patch/219174/

Regards,
Simon

>
> Thanks,
> Jagan.
>
>>
>> Regards,
>> Simon
>>
>>>
>>> Thanks,
>>> Jagan.
>>>
>>>>
>>>> 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