I'll just check it in right from my tree if it is what you need. The
part inside the '#if 0' to hardcode the values still needs to
be fixed if
someone actually uses that. In fact, I'll just fix it and push out the
change since it will work on all boards depending upon what you want.
I looked at the patch and I have a couple comments:
1. The loop that overwrites the b_enetaddr[] should check that it does not
contain any information before assigning the default. This could have been
passed in by the bios.
2. If you assume that any platform that uses CONFIG_EMBEDDEDBOOT may want to
pass in a bd_info structure, then the platform specific patch in head.S is
wrong. Based on the current architecture I believe this is a safe
assumption. You may totally ignore this parameter in embed_config.c where
the platform dependent code is located.
diff -aru devel_old/arch/ppc/boot/simple/head.S
linuxppc_2_4_devel/arch/ppc/boot/simple/head.S
--- devel_old/arch/ppc/boot/simple/head.S Wed Aug 28 00:59:37 2002
+++ linuxppc_2_4_devel/arch/ppc/boot/simple/head.S Wed Aug 28 01:00:12
2002
@@ -59,7 +59,7 @@
isync
#endif
-#if defined(CONFIG_MBX) || defined(CONFIG_RPX6)
+#if defined(CONFIG_EMBEDDEDBOOT)
mr r29,r3 /* On the MBX860, r3 is the board info pointer.
...
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Curtis, Allen wrote:
1. The loop that overwrites the b_enetaddr[] should check that it does not
contain any information before assigning the default. This could have been
passed in by the bios.
If you have a board/rom configuration where this isn't the right thing
to do, then create a new embed_config() function for it. These are not
intended to be generic functions, and if you someday have experience with
lots of different board/rom combinations, you'll understand why this is
the case.
This code is intended to be a quick and easy update for a new board without
having to worry about how you may affect someone else. There are LOTS of
boards using this code, and I don't like to be changing something that is
currently working without the ability to test everything else that may
be affected. You definitely have to take the "if it works, don't touch it"
attitude here and add something new that suits your purpose.
2. If you assume that any platform that uses CONFIG_EMBEDDEDBOOT may want to
pass in a bd_info structure,
We don't assume that at all. In fact there are only three boards now where
we make that assumption and it is clear in the code which ones they are.
There is certainly no standard way of linking information between a boot rom
and this code, and tomorrow we may find something completely different. If
you write code in embed_config() that expects something to be passed from a
boot rom (which in some cases is not a bd_t), then you must ensure it gets
passed from head.S properly.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/