Hi, On Thu, Nov 29, 2007 at 05:49:53PM +0100, David Sernelius wrote: > Hi, > > We are two souls in possesion of HP iPAQ rx4240:s which we are aiming at > running Linux on. As far as we understand noone has succeeded or even tried > that before. > > Our progress this far is finding and using HaRET, which seems to work > perfectly. We've been turning the screen on and off, filling the screen with > blue, playing sound, dumping registers and trying to start kernels. Great > piece of software! > > When we boot kernels, we're not completely sure what happens. I.e. how the > handover from HaRET to the kernel actually happens and how to proceed to > understand enough to make the modifications needed to succeed. What state is > the device in when HaRET hands over control to the kernel? Are there any > differences to a hardware reset, except for where code is executed? What > decides on what memory address this is? The hardware architecture? Value of > the MTYPE variable? Something else?
Lots of questions. I suggest you read the "theory of operation" blurb in the C code at: http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/haret/src/linboot.cpp The actual arm boot protocol is discussed in the linux source in: Documentation/arm/Booting Basically, haret is tasked with shutting down the mmu, shutting down dma&irqs, copying the kernel to the top of ram, and then jumping to it. There are differences between a reset because haret is programmed to just shutdown dma and irqs - where a reset will generally have other things in a shutdown state. Most of the time this doesn't matter. The kernel is supposed to go near the top of ram - top of ram is determined by the cpu maker (see the haret variable RAMADDR). > The rx4240 is powered by a Samsung s3c2442 and by default HaRET tries a > generic s3c24xx profile and tries to choose 0x30000000 as the RAM start > address. According to HaRET the framebuffer resides at 0x30100000, which is > just above that address. So when we try to boot the kernel with the defaults > we end up with a garbeled screen followed by a reset. If we try a higher > address we get the following output on the screen: I don't think you want to change the RAMADDR - I think it may confuse the linux kernel. Even if the RAMADDR overlaps with the framebuffer it shouldn't stop haret from handing control over to linux. > HaRET boot > Shutting down hardware > Turning off MMU > In preloader > Tags preloader > Kernel relocated > Initrd relocated > PSR=600000df > Jumping to kernel > > The telnet session to HaRET gives some output too, ending in "GO GO GO". The above represents a "successful" handoff from haret to linux. Right after the code writes "Jumping to kernel", haret hands control over to linux. > Since the rx3000 series are fairly similar to our platform, that is the > precompiled kernels we've been starting testing with. We've also tried > booting files filled with zeroes and random data to get some more > understanding, but those boots are of course not of much interest. What > surprised us is that only booting a kernel at 0x30000000 causes a reset, > anything else a hang. Is this the kernel performing the reset after > detecting failure or can it be some kind of watch dog that triggers? As a guess, the kernel is trying to setup things and flips a gpio or some other setting which causes the hardware to reset. You're actually doing fairly well to get a reset instead of a hang. :-) > Could we let HaRET start anything else than a kernel? Like a simple piece of > test code that merely messes with the screen in a controlled manner, for > example? Haret just takes a binary blob from disk, loads it into physically continuous ram, and jumps to it. You can load anything you want - but there isn't much point except to load linux. > Does anyone here have any information/ideas/suggestions on how to proceed? > Are there any log outputs or information we could provide that would be > useful to anyone? You will need to set an MTYPE in haret that matches what your kernel is compiled for - I'd definitely verify this. You may want to check that you have the latest version of haret. You can grab the latest from: http://www.handhelds.org/~koconnor/haret/haret-20071122.exe Please create a file "earlyharetlog.txt" in the same directory as haret and run haret. This should create a file "haretlog.txt" with early logging info. Please send this file to the mailing list. In order to run linux, you're going to need to map out what all the gpios on the device do. You'll also likely need to figure out how the keypad, touchscreen, etc. all work. Haret can help with this. There are a number of developers in the irc channel at irc.freenode.net in the #htc-linux room. They've helped a number of people get linux to boot. (It's an international chat room - you may have to try at different hours to find someone knowledgeable.) Hope this helps, -Kevin _______________________________________________ Haret mailing list [email protected] https://handhelds.org/mailman/listinfo/haret
