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 : [EMAIL PROTECTED],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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
