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>> 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>>>
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?
What was the reason to use compat_names table in fdtdec.c file?
Just so there is a simple register of everything that uses fdt in U-Boot - the
enum is used by driver code. If we end up with a lot of support then we might
reconsider one day
Is it requirement that all new drivers should extend this table?
Because from my point of view is just this not necessary to do.
Based on function above this is enough for drivers to be probed.
Thanks,
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
