Re: Help supporting Debian on a Kurobox
On Aug 22 2008, Sven Luther wrote:
> On Fri, Aug 22, 2008 at 10:43:40AM -0300, Rogério Brito wrote:
> > Here is the output:
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > cpu : 82xx
> > revision : 16.20 (pvr 8081 1014)
> > bogomips : 129.84
> > vendor : Motorola SPS
> > machine : Sandpoint
> > processor : PVID: 0x80811014, vendor: Motorola
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> It is indeed a 82xx,a powerquicc II cpu, a 8241 if i remember well.
I'm not that well informed about PowerPCs.
> Mmm, it doesn"t seem to be listed on the freescale product page anymore
> though.
It is probably not listed, as I would guess that it is an older CPU
(200MHz).
> Ok. It is possible that you could attach a serial console, but this
> involves some soldering on the board. Search the web for instructions on
> how to do this.
I don't even know if the kernel has serial support compiled in. I will
check this.
> > Right, but the current heartbeat daemon seems to be independent of the
> > kernel. Knowing how to generate a uboot image would help, though. Wouldn't
> > it be created in a usual way? Does it need extra steps?
>
> Well, i don't know the kurobox userland, but basically things go like
> this :
It's just a common ppc box, with some additional things to light up the
leds in case of a full HD and in case of shutting down the system. It seems
that using a custom kernel with uboot looses some functionality, though.
:-(
> 1) U-boot is able to boot a uimage.
Right, but how does one generate this uImage? Will it be side-by-side of a
normal kernel image?
> 2) This uimage can either be a standalone kernel, with a filesystem in
> flash (using jffs2 asfilesystem for example)
Right. I'm not sure the flash RAM has enough space for a 2.6 kernel, as
they are much bigger than 2.4 kernels with the same (or similar) configs.
> 3) or this uimage can be a a kernel with builtin ramdisk, containing
> the filesystem.
I think that this is what is the approach used by the factory default
firmware.
> 4) you could be booting the kernel with an NFS system easier for
> debugging, and before generating the flash.
Indeed.
> 5) the userland takes over, and runs various things. I ghuess that the
> heartbeat daemon is the one controlling the watchdog in the MPC8241,
> and if you don't run it, it will reset the board.
Yes, that's what I read: the watchdog will shudown the system in 30s
approximately.
> So, the first order of business is to get your kurobox modified so it
> has a serial console, and see if you can get the uboot prompt, once you
> have this, things become an order of magnitude easier.
There is one thing that the community has developed: a module called load.o
(or something like this) which basically does the job of a kexec, loading
another kernel.
> Also check if you have the 2x8 pin header for the JTAG interface
> somewhere.
I read that such interface would allow me to flash the device without fear
of it being bricked. Is that right? I would also like to have the
possibility of getting it back to the stock firmware in case that I make
some mistake.
> Maybe the kernel (or uboot) can be modified to disabled the cpu
> watchdog support, and thus not need the heartbeat daemon. Not sure
> though, because once enabled, you can't disable it.
The heartbeat daemon seems to be available, though. I hope that it
works. I'm willling to package it.
> From the debian side, you need a new kenrel flavour (it is not the
> generic MPC82xx), as well as support for generating a uImage that uboot
> can boot.
For now, I am happy to build my own image and learn things so that I can
feed things to the official Debian kernel in the future. I would be using
kernel-package for this task.
> This needs a packaged version of mkimage for powerpc, and
> probably some modifications of mkvmlinuz (or the kernel package
> directly).
Which utilities would generate an uImage?
> I have not much time today, but will help you as much as i can, altough
> i doubt i can contribute to the debian packaging directly,
I don't think that this would be a problem. We can cooperate and I can try
to submit patches, which I hope that are sensible.
> since the kernel team said that any patch, if it comes from me, is not
> acceptable, and anyway, it would be best to start trying to merge stuff
> once it is validated, and debian/lenny has been released.
No problems, I would just like to have newer tools to improve the
environment and generate images for the community. I'm not really worried
about lenny being released now or not. The way I see the development on
Debian is as a continuous process.
> I hope the above helps.
Thanks for the help so far.
> Please remove the mail followup to, so i can do a group reply without
> having only the lists in To, and thus my mail getting lost.
I think that I have fixed that.
Thanks, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
Reply to: