I filed a bug against the webpage:
Bug#514101: Acknowledgement of maintainer-only report (buildd.emdebian.org confusing repositories)
I might have confused you in what I am doing and what I want to do, sorry about that. I am running emdebian-tools on a powerful pc which has debian lenny installed, so not on the actual target board. On this machine I think the emdebian-tool installation is correct now and emsetup works as well.
What I want to do is to get an emdebian demo running on a XScale PXA270 board running which has 64MByte Ram and 32MByte flash. On that board currently linux
from Elinos (an embedded linux distributor) is running and I want to replace that. The linux kernel and the Elinos root filesystem is brought up by the boot loader uboot.
So my question was if it is possible to replace the filesystem from elinos with that from emdebian I generated (the emdebian-arm.tgz) and to use the kernel already installed.
If it is not possible that easily imagine I would have a new empty device without anything. What would be the procedure to get emdebian running?
I suppose first we need a bootloader installed on the flash, which one would you recommend?
From: Neil Williams [mailto:email@example.com]
Sent: Tue 2/3/2009 8:45 PM
On Tue, 3 Feb 2009 17:57:55 +0100
"Hoefle Marco" <Marco.Hoefle@nanotronic.ch> wrote:
> Hello Neil,
> It is not a bug but my lack of knowledge in the Debian packaging handling.
I don't want someone else making the same mistake, so I need to know
what caused you to think that you needed to add those sources in the
first place. That is a bug in whatever documentation you read before
deciding on that path.
Emdebian *requires* a knowledge of Debian and Debian packaging - at
least until more changes can be made in Debian after the Lenny release.
By the time Squeeze is ready for release (next after Lenny), I'm hoping
to include debian-installer support and other measures to make Emdebian
easier to understand and easier to learn. Right now, we're stuck with
working around bugs in Debian that make our lives difficult and
therefore make Emdebian itself difficult.
Emdebian Crush is very specialised and there is no simple way of using
or installing it without knowing Debian in detail.
Emdebian Grip is the easy-to-use version of Emdebian - Crush is quite
different and much, much harder to prepare, manage and install.
> I removed all the relevant packages, deleted the wrong repositories and
> installed the packages again and after that the emdebian tools. I could file a bug to highlight that the emdebian repositories should NOT be on
> the host machine. Just give me the url and maybe point me to the bug report rules (I suppose you have some requirements, style, necessary information etc.)
reportbug does all that for you - that is why I kept asking for bug
reports. You need to be running Debian on a "typical" PC to be able
to debug or fix things in Emdebian Crush. Even Grip requires Debian if
you actually want to tweak it.
Reporting bugs without using reportbug causes the bug report to omit
the necessary information for most bug reports.
Bugs filed against website content are slightly different - you can file
those by email without reportbug. File bugs against the
buildd.emdebian.org pseudo-package. See http://www.uk.debian.org/Bugs/
> Right now I got the emdebian-arm.tgz which has a size of 25 MByte uncompressed which means it will fit into the flash of the XScale PXA270 board.
How did you generate that tarball? On the board? If so, you've still
got things messed up because you cannot reliably create an Emdebian
Crush root filesystem on Emdebian Crush itself. The process needs
things like dpkg-architecture that are perl and are not present in
Crush. There's no support for building (or packaging) Crush on Crush -
at least, not any time soon.
What are you doing about the kernel and kernel modules?
> In the emdebian how to it is mentioned that a debian like system is required to update the romfs. This is not the case for me. We have uboot running together
Debian is required to create the root filesystem - Crush cannot do it.
> with this kernel version:
> Hit any key to stop autoboot: 0
> **** Try to boot from Flash ****
> ## Booting image at 00040000 ...
> Image Name: Linux Kernel Image
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 2367256 Bytes = 2.3 MB
> Load Address: a0008000
> Entry Point: a0008000
> Verifying Checksum ... OK
> Starting kernel ...
> Linux version 188.8.131.52-ELinOS-469 (joye@hrwks7001-l) (gcc version 3.4.4 (ELinO8
> CPU: XScale-PXA270  revision 7 (ARMv5TE), cr=0000397f
> The flash is partitioned into:
> 0x00000000-0x00040000 : "Bootloader"
> 0x00040000-0x00400000 : "Kernel"
> 0x00400000-0x02000000 : "Filesystem"
> I suppose it won't work to replace the data on 0x00400000 with the packed .tgz data. Do you have any hints on how to proceed?
I've no idea. What you need to do is unpack the tarball into the
required filespace and then run ./emsecondstage within the bootloader
environment, which must support certain functionality like 'chroot'.
After that, the kernel modules need to be put into the relevant location
However, you are also going to need a machine-specific config package
along the lines of balloon3-config in order to actually get the device
to boot and use a serial terminal or whatever.