microblaze console init
Hi list,
while working on fdt support for the nios2 I was reading some code for other archs I also looked at the microblaze code and I believe I found some leftovers from a copy/paste action, attached is a small patch (untested) to fix a debug print and (more important) remove a useless call to early_init_dt_check_for_initrd.
I do still have one concern, do I understand correctly that there is no way to do address-translation (the "ranges" stuff) on a flattenend tree, using the of_get_flat_dt_* functions? This would mean that this code would fail to get the correct address for a uartlite connected to a bus that has address-translation.
Greetingz
Walter
arch/microblaze/kernel/prom.c +1 -3
@@ -61,14 +61,12 @@ static int __init early_init_dt_scan_serial(unsigned long node,char *p;int *addr; -pr_debug ("search \"chosen\", depth: %d, uname: %s\n" , depth, uname); +pr_debug ("search \"serial\", depth: %d, uname: %s\n" , depth, uname);/* find all serial nodes */ if (strncmp (uname,"serial" ,6 ) !=0 )return 0 ; -early_init_dt_check_for_initrd (node); -/* find compatible node with uartlite */ p =of_get_flat_dt_prop (node,"compatible" , &l); if ((strncmp(p, "xlnx,xps-uartlite", 17) != 0) &&
_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Walter Goossens
I do still have one concern, do I understand correctly that there is no way to do address-translation (the "ranges" stuff) on a flattenend tree, using the of_get_flat_dt_* functions? This would mean that this code would fail to get the correct address for a uartlite connected to a bus that has address-translation.
Correct, none of the flat tree core code tries to do any range translation. In fact, it does very little in the way of looking at reg properties at all. Only the absolute bare minimum required to get through early boot. It could be done, but there really hasn't been a use case for it up to this point. Instead, ranges can be translated after the tree has been unflattened into the live form.
g.
A message that is not in the archive (sent off-list or not yet received): AANLkTinw3mqpmiUkzf9Drgg+f+b3hFBUoHLmtWSO75GY-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 6 lines · Grant Likely
Quoted 5 lines · Walter Goossens
I do still have one concern, do I understand correctly that there is no way to do address-translation (the "ranges" stuff) on a flattenend tree, using the of_get_flat_dt_* functions? This would mean that this code would fail to get the correct address for a uartlite connected to a bus that has address-translation.
Quoted 9 lines
Correct, none of the flat tree core code tries to do any range translation. In fact, it does very little in the way of looking at reg properties at all. Only the absolute bare minimum required to get through early boot. It could be done, but there really hasn't been a use case for it up to this point. Instead, ranges can be translated after the tree has been unflattened into the live form.
g.
thanks for the quick response!
I was afraid of this... I'm affraid I do need to use it in the nios code, well I don't need to but in order to be flexible (and use the design I'm working with right now) but I would prefer it. The way around this I currently use is a special parameter in chosen with the address of the "early uart" (it's only used for early printk). What's cleanest approach here? An extra property in "chosen" or range translation in the flatttened tree?
Walter
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 23 lines · Walter Goossens
Quoted 13 lines · Grant Likely
Quoted 9 lines · Walter Goossens
I do still have one concern, do I understand correctly that there is no way
to do address-translation (the "ranges" stuff) on a flattenend tree, using
the of_get_flat_dt_* functions? This would mean that this code would fail to
get the correct address for a uartlite connected to a bus that has address-translation.Quoted 9 lines
Correct, none of the flat tree core code tries to do any range translation. In fact, it does very little in the way of looking at reg properties at all. Only the absolute bare minimum required to get through early boot. It could be done, but there really hasn't been a use case for it up to this point. Instead, ranges can be translated after the tree has been unflattened into the live form.
g.
Quoted 8 lines
thanks for the quick response!
I was afraid of this... I'm affraid I do need to use it in the nios code, well I don't need to but in order to be flexible (and use the design I'm working with right now) but I would prefer it. The way around this I currently use is a special parameter in chosen with the address of the "early uart" (it's only used for early printk).
What's cleanest approach here? An extra property in "chosen" or range translation in the flatttened tree?
Implement ranges translation in the flat tree code. It wouldn't be very hard, and will be a lot more maintainable in the long run.
g.
Quoted 29 lines · Grant Likely
Quoted 20 lines · Walter Goossens
Quoted 10 lines · Grant Likely
Quoted 8 lines · Walter Goossens
I do still have one concern, do I understand correctly that there is no way
to do address-translation (the "ranges" stuff) on a flattenend tree, using
the of_get_flat_dt_* functions? This would mean that this code would fail to
get the correct address for a uartlite connected to a bus that has address-translation.Quoted 9 lines
Correct, none of the flat tree core code tries to do any range translation. In fact, it does very little in the way of looking at reg properties at all. Only the absolute bare minimum required to get through early boot. It could be done, but there really hasn't been a use case for it up to this point. Instead, ranges can be translated after the tree has been unflattened into the live form.
g.
Quoted 8 lines
thanks for the quick response!
I was afraid of this... I'm affraid I do need to use it in the nios code, well I don't need to but in order to be flexible (and use the design I'm working with right now) but I would prefer it. The way around this I currently use is a special parameter in chosen with the address of the "early uart" (it's only used for early printk).
What's cleanest approach here? An extra property in "chosen" or range translation in the flatttened tree?
Quoted 5 lines
Implement ranges translation in the flat tree code. It wouldn't be very hard, and will be a lot more maintainable in the long run.
g.
I'll have a stab at it.
Thanks!
Walter
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · On Sat, 11 Dec 2010 23:24:27 +0100 Walter Goossens…
Quoted 5 lines · Grant Likely
Implement ranges translation in the flat tree code. It wouldn't be very hard, and will be a lot more maintainable in the long run.
g.
I'll have a stab at it.
Some code for this exists in arch/powerpc/boot/devtree.c
-Scott
A message that is not in the archive (sent off-list or not yet received): 20101213125947.12a6db54-N/[email protected]
Quoted 12 lines · Scott Wood
Quoted 7 lines · On Sat, 11 Dec 2010 23:24:27 +0100 Walter…
Quoted 5 lines · Grant Likely
Implement ranges translation in the flat tree code. It wouldn't be very hard, and will be a lot more maintainable in the long run.
g.
I'll have a stab at it.
Some code for this exists in
arch/powerpc/boot/devtree.c
Sweet!
thnx for the pointer.
Walter
Quoted 3 lines
-Scott