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.
--
To UNSUBSCRIBE, email to debian-powerpc-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org
FAQ
Search
Profile
Private Messages
Log in
Linux