Hi Jagan,
On Fri, Mar 1, 2013 at 1:21 PM, Jagan Teki <jagannadh.t...@gmail.com> wrote:
> Hi Simon,
>
> On Sat, Mar 2, 2013 at 1:54 AM, Simon Glass <s...@chromium.org> wrote:
>> Hi Jagan,
>>
>> On Fri, Mar 1, 2013 at 11:14 AM, Jagan Teki <jagannadh.t...@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Fri, Mar 1, 2013 at 10:07 AM, Simon Glass <s...@chromium.org> wrote:
>>>> Hi Jagan,
>>>>
>>>> On Thu, Feb 28, 2013 at 12:29 PM, Jagan Teki <jagannadh.t...@gmail.com>
>>>> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Thu, Feb 28, 2013 at 7:22 PM, Simon Glass <s...@chromium.org> wrote:
>>>>>> Hi Jagan,
>>>>>>
>>>>>> On Thu, Feb 28, 2013 at 3:14 AM, Jagan Teki <jagannadh.t...@gmail.com>
>>>>>> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Mon, Feb 25, 2013 at 4:40 AM, Simon Glass <s...@chromium.org> wrote:
>>>>>>>> Hi Jagan,
>>>>>>>>
>>>>>>>> On Sun, Feb 24, 2013 at 10:58 AM, Jagan Teki
>>>>>>>> <jagannadh.t...@gmail.com> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On Sun, Feb 24, 2013 at 11:55 PM, Jagan Teki
>>>>>>>>> <jagannadh.t...@gmail.com> wrote:
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 24, 2013 at 11:50 PM, Simon Glass <s...@chromium.org>
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:55 AM, Jagan Teki
>>>>>>>>>>> <jagannadh.t...@gmail.com> wrote:
>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:18 PM, Simon Glass <s...@chromium.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Hi Jegan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 9:45 AM, Jagan Teki
>>>>>>>>>>>>> <jagannadh.t...@gmail.com> wrote:
>>>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 11:08 PM, Simon Glass
>>>>>>>>>>>>>> <s...@chromium.org> wrote:
>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Feb 24, 2013 at 8:19 AM, Jagan Teki
>>>>>>>>>>>>>>> <jagannadh.t...@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
>>>>>>>>>>>>>>>> <s...@chromium.org> wrote:
>>>>>>>>>>>>>>>>> Hi Jagan,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Feb 21, 2013 at 9:03 AM, Jagan Teki
>>>>>>>>>>>>>>>>> <jagannadh.t...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
