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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox