From: Milton Miller <hidden> Date: 2006-08-03 09:46:12
On Tue Aug 1 2006 11:17:41 PM CDT, Grant Likely wrote:
On 7/25/06, Clint Thomas [off-list ref] wrote:
quoted
Basically, the system I want linux running on does not require the
initialization of hardware that U-boot provides, or at least it does not
need it to boot the linux kernel. I want to load an uncompressed linux
kernel into memory and start the execution of the kernel, without using any
kind of bootloader. Is this possible? Or does linux need some kind of
firmware or other software to tell it to start executing? Thanks for any
info you might have.
Loading a kernel into memory and starting execution *is* a boot loader. :)
If it's running on the cpu, then I agreee. But he didn't say how he was loading
the image into memory, and if it is via an external agent then I would not
necessarly call that a boot loader, altough it is performing those tasks.
Actually, that may be too broad. Is kexec a boot loader?
You could use the bootwrapper that is in the kernel source tree
(zImage). If a zImage's entry point is at the execution entry point,
then it will start the Linux kernel correctly. However, it is still a
compressed image.
The boot wrapper is a reference implementation, not a required piece of the
boot sequence. As I stated in my previous post, the kernel entry conditions
are documted and loading the vmlinux raw is reasonable, asssuming that
the other conditions can be met (registers and device treee, and maybe
initrd).
If you *really* need an uncompressed image, I would start with the
bootwrapper and hack it to work with an non-gzipped kernel image.
However, why do you want to do it this way? You probably won't gain
much in boot time and it will be more difficult to maintain.
Actually, the code is aready there to just copy anything inthe kernel
section that is without the gzip header.
milton
From: Grant Likely <hidden> Date: 2006-08-03 14:35:00
On 8/3/06, Milton Miller [off-list ref] wrote:
On Tue Aug 1 2006 11:17:41 PM CDT, Grant Likely wrote:
quoted
On 7/25/06, Clint Thomas [off-list ref] wrote:
quoted
Basically, the system I want linux running on does not require the
initialization of hardware that U-boot provides, or at least it does not
need it to boot the linux kernel. I want to load an uncompressed linux
kernel into memory and start the execution of the kernel, without using any
kind of bootloader. Is this possible? Or does linux need some kind of
firmware or other software to tell it to start executing? Thanks for any
info you might have.
Loading a kernel into memory and starting execution *is* a boot loader. :)
If it's running on the cpu, then I agreee. But he didn't say how he was loading
the image into memory, and if it is via an external agent then I would not
necessarly call that a boot loader, altough it is performing those tasks.
Actually, that may be too broad. Is kexec a boot loader?
I would say it is. :)
IMHO, even the basic tasks of correctly setting up the initial
conditions can be considered a bootloader.
quoted
You could use the bootwrapper that is in the kernel source tree
(zImage). If a zImage's entry point is at the execution entry point,
then it will start the Linux kernel correctly. However, it is still a
compressed image.
The boot wrapper is a reference implementation, not a required piece of the
boot sequence. As I stated in my previous post, the kernel entry conditions
are documted and loading the vmlinux raw is reasonable, asssuming that
the other conditions can be met (registers and device treee, and maybe
initrd).
I agree. However, the original post sounded to me like he was looking
for a canned solution. I know zImage isn't exactly what he asked for
because it is a compressed image, but it does achieve the *effect* he
asked for.
I am curious as to the source of his requirements. ie. what is
loading the kernel into ram? Where is it coming from?
I've got a similar situation on my Virtex-4 platform. The FPGA takes
care of all device initialization. However, the kernel is loaded of a
CF card via a *slow* JTAG interface. Loading an uncompressed image is
more time consuming than loading a compressed image and uncompressing
it in software.
quoted
If you *really* need an uncompressed image, I would start with the
bootwrapper and hack it to work with an non-gzipped kernel image.
However, why do you want to do it this way? You probably won't gain
much in boot time and it will be more difficult to maintain.
Actually, the code is aready there to just copy anything inthe kernel
section that is without the gzip header.
Perfect!
cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
From: Milton Miller <hidden> Date: 2006-08-03 16:27:51
On Aug 3, 2006, at 9:34 AM, Grant Likely wrote:
On 8/3/06, Milton Miller [off-list ref] wrote:
quoted
On Tue Aug 1 2006 11:17:41 PM CDT, Grant Likely wrote:
quoted
On 7/25/06, Clint Thomas [off-list ref] wrote:
quoted
Basically, the system I want linux running on does not require the
initialization of hardware that U-boot provides, or at least it
does not
quoted
quoted
need it to boot the linux kernel. I want to load an uncompressed
linux
quoted
quoted
kernel into memory and start the execution of the kernel, without
using any
quoted
quoted
kind of bootloader. Is this possible? Or does linux need some
kind of
quoted
quoted
firmware or other software to tell it to start executing? Thanks
for any
quoted
quoted
info you might have.
quoted
quoted
You could use the bootwrapper that is in the kernel source tree
(zImage). If a zImage's entry point is at the execution entry
point,
quoted
then it will start the Linux kernel correctly. However, it is
still a
quoted
compressed image.
The boot wrapper is a reference implementation, not a required piece
of the
boot sequence.
...
I agree. However, the original post sounded to me like he was looking
for a canned solution. I know zImage isn't exactly what he asked for
because it is a compressed image, but it does achieve the *effect* he
asked for.
Actually the existing zImage will not do that, it requires a client
interface to allocate memory, etc. There are alternates available
but they are not yet merged.
I am curious as to the source of his requirements. ie. what is
loading the kernel into ram? Where is it coming from?
That would be useful to help suggest alternatives.
I've got a similar situation on my Virtex-4 platform. The FPGA takes
care of all device initialization. However, the kernel is loaded of a
CF card via a *slow* JTAG interface. Loading an uncompressed image is
more time consuming than loading a compressed image and uncompressing
it in software.
This is often the case. However, if its loaded via some kind of DMA
access
from a higher powered cpu then loading the uncompressed kernel could be
the fastest way. Since we don't know we can only mention things to
consider as we state what can be done.
milton
From: Grant Likely <hidden> Date: 2006-08-03 16:34:51
On 8/3/06, Milton Miller [off-list ref] wrote:
quoted
I've got a similar situation on my Virtex-4 platform. The FPGA takes
care of all device initialization. However, the kernel is loaded of a
CF card via a *slow* JTAG interface. Loading an uncompressed image is
more time consuming than loading a compressed image and uncompressing
it in software.
This is often the case. However, if its loaded via some kind of DMA
access
from a higher powered cpu then loading the uncompressed kernel could be
the fastest way. Since we don't know we can only mention things to
consider as we state what can be done.
As alwasy; the devil is in the details. :)
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
From: David H. Lynch Jr. <hidden> Date: 2006-08-03 16:49:32
Grant Likely wrote:
I've got a similar situation on my Virtex-4 platform. The FPGA takes
care of all device initialization. However, the kernel is loaded of a
CF card via a *slow* JTAG interface. Loading an uncompressed image is
more time consuming than loading a compressed image and uncompressing
it in software.
I am working with the Pico E-12. It is a CF formfactor device. It
has only a pseudo Parallel/Jtag
interface exported through the CF connector Pico calls the Keyhole
Port, and A UartLite, and TEMAC off some mini connector.
Pico has their own "monitor" program that fits in 32K of ram inside
the FPGA that loads and executes ELF files (or FPGA bit images)
from a very simple FileSystem (basically a linked list). Then they
have Host software to Read/Write the Flash, update files in Flash, ...
that works primarily through the Keyhole.
I just build the Kernel as an ELF file, update the ELF File in Flash
and tell it to boot that file and away it goes.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein