Hi Simon,
On Sat, Mar 2, 2013 at 6:30 AM, Simon Glass <s...@chromium.org> wrote:
> 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.
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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
