Hi Jagan,
On Fri, Mar 1, 2013 at 11:44 PM, Jagan Teki <jagannadh.t...@gmail.com> wrote:
> 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>;
> };
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
