
On Mon, Jul 04, 2011 at 04:32:35PM -0400, Christopher Harvey wrote:
On Mon, Jul 04, 2011 at 04:13:49PM -0400, Jason wrote:
On Mon, Jul 04, 2011 at 02:55:54PM -0400, Christopher Harvey wrote:
On Mon, Jul 04, 2011 at 02:08:44PM -0400, Jason wrote:
On Mon, Jul 04, 2011 at 01:45:41PM -0400, Christopher Harvey wrote:
Hopefully there will never be this many machines.
Can't use 0 since 0 is already used as a mach-type. */
gd->bd->bi_arch_number = 0xffffffff;
gd->bd->bi_baudrate = gd->baudrate; /* Ram ist board specific, so move it to board code ... */
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 802e833..70b3b76 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -113,6 +113,12 @@ int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images) printf ("Using machid 0x%x from environment\n", machid); }
+#ifdef DEBUG
- if(machid==0xffffffff) {
debug("\nWarning: machid not set! Linux will not finish booting.\n\n");
s/finish/start/ ;-)
I'll have to disagree here. Linux will decompress and some functions will run but it will eventually stop, hence will not finish.
On further investigation, you're right, it doesn't finish starting/booting. Sorry for the noise.
Also, shouldn't the compile fail in this case (#error)? Or, at least #warn?
The compiler can't know what machid will be at runtime. Maybe a "would you like to continue?" prompt could work.
Since the kernel throws a nice fat error message when the MACH_TYPE doesn't match what it was compiled for, I don't see the point to adding another message at the same point in the development process.
I didn't see that message. Do you know what lines of code in the kernel print it? Or maybe just the message itself?
In init/main.c start_kernel() calls setup_arch()
In arch/arm/kernel/setup.c setup_arch() calls setup_machine_tags() which calls dump_machine_table()
when the value in r1 doesn't match any of the mach-types the kernel was compiled for.
If the kernel can check the value why would it need to be passed in the first place?
Because the kernel has no way of easily determining which arm board it's running on without this feature.
hth,
Jason.