On 06/29/2012 04:32 AM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 11:49 PM, Michal Simek <mon...@monstr.eu
<mailto:mon...@monstr.eu>> wrote:
On 06/28/2012 07:57 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek <mon...@monstr.eu
<mailto:mon...@monstr.eu> <mailto:mon...@monstr.eu <mailto:mon...@monstr.eu>>>
wrote:
Hi Simon,
On 06/28/2012 03:10 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek <mon...@monstr.eu <mailto:mon...@monstr.eu>
<mailto:mon...@monstr.eu <mailto:mon...@monstr.eu>> <mailto:mon...@monstr.eu <mailto:mon...@monstr.eu>
<mailto:mon...@monstr.eu <mailto:mon...@monstr.eu>>>> wrote:
Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek <mon...@monstr.eu <mailto:mon...@monstr.eu> <mailto:mon...@monstr.eu
<mailto:mon...@monstr.eu>> <mailto:mon...@monstr.eu <mailto:mon...@monstr.eu> <mailto:mon...@monstr.eu <mailto:mon...@monstr.eu>>>
<mailto:mon...@monstr.eu <mailto:mon...@monstr.eu> <mailto:mon...@monstr.eu <mailto:mon...@monstr.eu>> <mailto:mon...@monstr.eu
<mailto:mon...@monstr.eu> <mailto:mon...@monstr.eu <mailto:mon...@monstr.eu>>>>> wrote:
Hi,
can you please update me about current state of
CONFIG_OF_CONTROL for ARM?
Are there any other archs/boards which will use
this option?
Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the
Chromium tree and being upstreamed in chunks (although no fdt patches have been
sent yet).
ok.
Has someone tried to look for devices based on
compatible property?
I see that in usb driver it is based on aliases
which is not the best solution.
U-Boot doesn't yet have a device model which would
allow this in the general case. For now, drivers look for their own compatible
nodes. This works well enough until we have a device model.
There are other limitations also - for example USB
supports only a single controller type working at one time (a restriction we
may need to look at to support USB2 and USB3 together). So even if two USB
drivers decided that they both found compatible nodes, only one of them could
operate. So for now aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet
initialization and I ended with this code fragment which could be
broadly used by other drivers.
int offset = 0;
do {
offset =
fdt_node_offset_by_compatible(______gd->fdt_blob, offset,
"xlnx,xps-ethernetlite-1.00.a" );
You could check if offset < 0 here, or
!fdtdec_get_is_enabled(gd->____fdt_blob, offset)
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset,
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset,
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_int(gd->fdt_blob, offset,
"reg", 0);
Maybe fdtdec_get_addr()
yeah right.
do {
offset = fdt_node_offset_by_compatible(____gd->fdt_blob,
offset, "xlnx,xps-ethernetlite-1.00.a" );
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset,
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset,
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_addr(gd->fdt_blob, offset,
"reg");
if (reg != FDT_ADDR_T_NONE)
ret |= xilinx_emaclite_initialize(____bis,
reg, txpp, rxpp);
} while (offset != -1);
if (reg)
ret |=
xilinx_emaclite_initialize(______bis, reg, txpp, rxpp);
} while (offset != -1);
What do you think? This code is in platform file.
Seems reasonable to me.
ok.
Also I have tested code around aliases which parse DTS
aliases list for console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Great - I did send a patch to the list for fdt serial, but
haven't really got back to it.
Can you give me link to it or just subject?
WIP: fdt: Add serial port controlled by device tree
These are the related commits in the Chromium tree. I will get to
upstreaming these at some point.
1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present
2006b07 gen: fdt: Add serial port controlled by device tree
711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory
mapped reg
da92af5 gen: Fix a compiler warning in serial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent'
option
376c215 lost: gen: fdt: Add serial port controlled by device tree
Can you also send me link to Chromium tree?
Yes this should work:
https://git.chromium.org/git/chromiumos/third_party/u-boot.git
Thanks.
I have sent support for Microblaze. Currently without dts because I want to
clear this part a little bit.
Tegra is using ./arch/arm/dts/tegra20.dtsi and
board/nvidia/dts/tegra2-seaboard.dts
and they are composed together in dts/Makefile by calling preprocessor.
Microblaze will be totally different case because every Microblaze hw design is
different.
We can use two main buses (little and big endian) and cpu is also configurable.
Based on this for Microblaze is the best solution directly to use dts.
(DTS for Microblaze is also generated directly from design tool).
Anyway - here is the bug message I am getting if I use full dts in
board/<name>/dts/microblaze.dts
and empty arch/microblaze/dts/microblaze.dtsi
<stdin>:34:3: error: invalid preprocessing directive #address
<stdin>:35:3: error: invalid preprocessing directive #size
<stdin>:52:4: error: invalid preprocessing directive #address
<stdin>:53:4: error: invalid preprocessing directive #cpus
<stdin>:54:4: error: invalid preprocessing directive #size
<stdin>:155:4: error: invalid preprocessing directive #address
<stdin>:156:4: error: invalid preprocessing directive #size
<stdin>:160:5: error: invalid preprocessing directive #gpio
<stdin>:192:5: error: invalid preprocessing directive #gpio
<stdin>:209:5: error: invalid preprocessing directive #gpio
<stdin>:241:5: error: invalid preprocessing directive #gpio
<stdin>:267:5: error: invalid preprocessing directive #address
<stdin>:268:5: error: invalid preprocessing directive #size
<stdin>:394:5: error: invalid preprocessing directive #interrupt
This is error for opposite case - empty microblaze.dts and full microblaze.dtsi.
make[1]: Entering directory `/mnt/projects/u-boot/dts'
rc=$( cat /mnt/projects/u-boot/board/petalogix/dts/microblaze.dts |
microblaze-unknown-linux-gnu-gcc -E
-P -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
- | { { dtc -R 4 -p 0x1000
-O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb on file' ; }
3>&1 ) ; \
exit $rc
/bin/sh: line 1: exit: too many arguments
make[1]: *** [dt.dtb] Error 1
make[1]: Leaving directory `/mnt/projects/u-boot/dts'
I have just tried to fix it by introducing new CONFIG option for skipping that
preprocessor
part. It will be good for Microblaze (probably there is any smarter solution
for SKIP case not to have two cats there).
The same situation will happen for Xilinx ppc support and partially for
upcoming ARM zynq where
full DTS is generated for unique hw design.
Here is the patch to show you what phase I would like to skip.
diff --git a/dts/Makefile b/dts/Makefile
index 914e479..d670cb8 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -45,9 +45,15 @@ all: $(obj).depend $(LIB)
# the filename.
DT_BIN := $(obj)dt.dtb
+ifndef CONFIG_DTS_SKIP_PREPROCESSOR
+SKIP := $(CPP) -P $(DTS_CPPFLAGS) -
+else
+SKIP := cat
+endif
+
$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
rc=$$( \
- cat $< | $(CPP) -P $(DTS_CPPFLAGS) - | \
+ cat $< | $(SKIP) |\
{ { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 2>&1 ; \
echo $$? >&3 ; } | \
grep -v '^DTC: dts->dtb on file' ; \
Thanks for your comments.
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
