Re: make-kpkg and uImage/cuImage.*
Hi, Gerhard.
On Aug 4, 2009, at 12:40 PM, Gerhard Pircher wrote:
Rogério Brito wrote:
I was once unfamiliar with these uboot images, but one you get
familiar
with them, they're just another flavor of kernel images (along with
vmlinux, vmlinuz, *.coff etc).
Yes, there isn't much difference. The only problem I faced were
initramfs
uImages, which were not recognized by the kernel. initrd uImages
however
worked fine.
Actually, one has just to be careful to feed the right kind of kernel
image to the bootloader. Knowing which one is needed is half way to
the success.
Regarding the initramfs/initrd images, I'm not using them at the
moment (yes, I do loose the flexibility of, say, mounting the
filesystems via UUID, which is kind of neat if you are experimenting
with using an PATA or SATA driver for your drive), but I intend to,
as soon as I get my own copy of uBoot compiled and a recipe of how to
create them, with all the steps described (I still intend to write a
tutorial on that).
Yes, I do. I have now 2 powerpc-based kuroboxes here:
* a Kurobox HD (a simpler one, which is the one that I'm using);
* a Kurobox HG (which has more memory, but I still didn't put it
to run).
I'm quite excited to have them work out of the box with Debian, with
pure Free Software (and no non-free Software).
Same here. Debian GNU/Linux everywhere (except for the WRT54GL router
with OpenWRT). :-)
I also have another PowerPC box here which is an old iBook G3 (but
still a NewWorld mac), whose form factor I love and would instantly
buy a more powerful machine that has all the balance between battery
autonomy and the ability to play videos (these are, BTW, my most
demanding applications).
Well, in the mean time, I'm sticking to what I have and I'll wait for
the industry to catch up with necessities.
I may be getting an arm-based kurobox in the near future (and, of
course, I will be interested in getting better support for it with
Linux).
I thought arm/armel already supports U-boot images. Thus I was a
little
bit disappointed when I couldn't find any reference for arm + u-
boot in
the kernel-package sources.
I will, perhaps, get the arm-based kurobox tomorrow and investigate a
little the kernel-package sources (but not much).
If I can't figure out a solution soon, I will simply try to adapt the
script that I sent you (perhaps, polishing it a bit, for instance, to
deal with the reinstallation of a package, to be managed properly by
the postinst script, a decent preinst/postrm etc).
If you have already made some of these modifications, please let me
know and I will integrate them.
I had problems with kernel versions 2.6.26 - 2.6.30, because a lot of
things were changed in the PPC MMU and DMA code.
For the embedded platform that the kuroboxes use, I had some problems
with the MTD devices. I still have to check what their status is and,
perhaps, send one patch to the lkml (or some call to help :-)).
The ones mentioned here: http://bugs.debian.org/497738
Thanks for the link!
You're welcome.
As far as I understand it kernel-package is designed
around the old Linux ppc architecture, where every subarch (CHRP,
APUS,
PReP) needed their own kernel image. The powerpc architecture should
allow to run one kernel image on different platforms (given that they
share the same CPU type).
Yes, the change in the kernel from ppc -> powerpc brought some
unification, but I don't know many subarch'es to speak in any
authoritative way (well, far, far from it---we have some much better
informed members here in the list that are knowledgeable about
hardware design/issues).
IMHO kernel-package should define subarchs
like ppc32, ppc64, 40x, 44x, 85xx, 8xx and e200 for the powerpc
architecture (like the Kconfig option for the processor type). Then
the
BIOS or the bootloader would just select the correct dtb or a specific
cuImage file. Theoretically...
Yes, that would be a good thing in principle, but the fact that we
have many bootloaders just seem to make things a bit harder. For
instance, we would have to teach quik, yaboot and grub2 to load
appropriate kernels for ppc32 (I am not familiar with other
bootloaders for OldWorld machines, like BootX or miboot etc).
Also, I don't know what is the bootloader that ppc64 uses (if
somebody could teach me here, I would be grateful, but as I don't
have any access to this platform at all, it would be for
documentation purposes).
Regarding the bootloader choosing the correct dtb and kernel image,
that would be fine, but wasteful for embedded systems. Perhaps
generating many binary packages for different flavours, like the
kernel maintainers do would be a good thing.
Nice that the script I provided you is of use for you. Please, if you
happen to make improvements, just send me a patch.
For sure! I'll try to add cuImage support. However my bash shell
scripting
skills are a little bit rusty.
No problems with code that is less optimal. We can collaborate and,
perhaps, get something reasonable working.
Perhaps we could even get the improvements (if any) to be included
into
kernel-package itself, so that we don't have to duplicate any
effort...
That would be the ideal case!
Once we have a less primitive script, I think that we could submit it
to Manoj as inspiration, basis, and proof-of-concept for integration
with kernel-package.
Regards, Rogério Brito.
Reply to: