From: Geoffrey Espin <espin@idiom.com>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips@oss.sgi.com
Subject: Re: No bzImage target for MIPS
Date: Fri, 14 Dec 2001 10:52:57 -0800 [thread overview]
Message-ID: <20011214105257.A15033@idiom.com> (raw)
In-Reply-To: <1008353149.27799.144.camel@zeus>; from Pete Popov on Fri, Dec 14, 2001 at 10:05:47AM -0800
> The "original" pmon has outlived its purpose, although it's still found
> on many boards. I've become a fan of MIPS Tech's yamon; it's small, it
> works, it has just the features I need in an embedded system, and, did I
> say it works?. Unfortunately the code is released under NDA only. If
> MIPS opened the code, I think you would see it on many more boards.
I rest my case. Linux is GPL, last I checked. "LinuxMon", I'll
dub it, solves the problem... for all architectures. :-) Attached
is the trivial 'reload' script for loading linux on top of linux.
It's just a wrapper for 'dd'. Oh yeah, your reset.c:xxx_restart()
needs a quick check to see if a new kernel got loaded, and jump
to it, instead of PROM.
> > itself, as the "boot monitor" is best approach. All reusable
> > code, fastest bootstrap (i.e. no 2nd stage loading), etc... But,
> > of course, not optimal for size, though my image is 1.3M which
> > includes a 580K cramfs ramdisk.
> That's fine once you've ported the kernel to your board. What do you do
> before that point?
With a ROM Emulator, bringing up Linux is no harder than bringing
up a boot monitor or any embedded RTOS, no? A day or three, if
you are lucky and brilliant. A somewhat longer if you're not
lucky. :-) Getting serial I/O is always the first nut to crack...
with Monta Vista's dbg_io.c, this is greatly simplified. Of
course, I'm not counting all the extra drivers (Ethernet, ...)
and assuming a well supported architecture.
> patch. But I fail to see how having this code in every <board>
> directory is better than having a separate boot directory like the ppc
> arch. The ppc-like zImage support I added is a bit different from the
I quite agree that initrd stuff is not right, or rather builtin
ramdisk.o is not good for embedded. Having it attached to the
end of vmlinux, possibly padded/aligned to a nice flash sector
boundary should be the general rule. Having <board>/Boot.make
so one can customize the "make boot" target rule to do the right
thing on a board-by-board basis seems to be the way to go. E.g.
in arch/mips/boot/Makefile, simply:
#
# This file is subject to the terms and conditions of the GNU General Public
# License. See the file "COPYING" in the main directory of this archive
# for more details.
#
# Copyright (C) 1995, 1998, 2001 by Ralf Baechle
#
.S.s:
$(CPP) $(CFLAGS) $< -o $*.s
.S.o:
$(CC) $(CFLAGS) -c $< -o $*.o
...
ifdef CONFIG_NEC_KORVA
include ../korva/Boot.make
endif
all: vmlinux.ecoff addinitrd
...
BTW, does any actually build 'vmlinux.ecoff'?
And sure, cluttering up yet another Makefile with CONFIG_XXX_BOARD
is not desirable... rather some magic like:
include $?{CONFIG_BOARD:common}/Boot.make
would be nice.
Geoff
--
Geoffrey Espin espin@idiom.com
--
=reload.sh======================================================================
#!/bin/sh
IMAGE=vrvmlinux00-bfc.bin # 0M
SKIP=64 # 64K for vrboot
SEEK=8 # 8k (80002000) skip excep vecs to kernel offset
if [ `sed -n -e 's/8\([0-9]\).*bzero/\1/p' /proc/ksyms` -eq 0 ] ; then
echo "$0: kernel not running at high memory (e.g. 16M), use reboot"
exit 1
fi
if [ $# -eq 0 ] ; then
echo "usage (nfs): $0 <user>"
echo "usage (ftp): $0 <user> <password>"
exit 1
fi
USER=$1
shift
VM="/home/${USER}/linux/arch/mips/boot/${IMAGE}"
if [ $# -eq 1 ] ; then
PW=$1
shift
VMI="ftp://${USER}:${PW}@10.1.1.1${VM}"
VM=/tmp/${IMAGE}
echo wget -c ${VMI} -O ${VM}
wget -c ${VMI} -O ${VM}
if [ $? -ne 0 ] ; then
echo "wget failed"
exit 1
fi
else
# using NFS
fi
echo dd if=${VM} of=/dev/mem bs=1k skip=${SKIP} seek=${SEEK} conv=notrunc
dd if=${VM} of=/dev/mem bs=1k skip=${SKIP} seek=${SEEK} conv=notrunc
if [ $? -ne 0 ] ; then
echo "dd failed"
exit 1
fi
reboot
--
next prev parent reply other threads:[~2001-12-14 19:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-14 0:47 No bzImage target for MIPS Krishna Kondaka
2001-12-14 1:10 ` Pete Popov
2001-12-14 3:28 ` Geoffrey Espin
2001-12-14 3:51 ` Keith Owens
2001-12-14 4:12 ` Geoffrey Espin
2001-12-14 18:05 ` Pete Popov
2001-12-14 18:52 ` Geoffrey Espin [this message]
2001-12-14 19:11 ` Pete Popov
2001-12-15 8:31 ` Karsten Merker
2001-12-15 9:14 ` Keith Owens
2001-12-15 12:46 ` Florian Lohoff
2001-12-17 20:32 ` Ralf Baechle
2001-12-17 13:12 ` Maciej W. Rozycki
2001-12-15 12:42 ` Florian Lohoff
-- strict thread matches above, loose matches on Subject: below --
2001-12-14 0:55 Marc Karasek
2001-12-14 22:59 Marc Karasek
2001-12-14 23:42 ` Pete Popov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011214105257.A15033@idiom.com \
--to=espin@idiom.com \
--cc=linux-mips@oss.sgi.com \
--cc=ppopov@mvista.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.