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