> Being based on the i.MX21 CPU I just took the kernel from 2 > sources I could find.
That's wrong. Embedded devices are often very different. While devices with the some SoC share a considerable amount of things, they still can be quite different when it comes to RAM, Flash, address decoding CPLds etc. > After I give the command to load the kernel I get some text for > a very brief period ( I'm unable to read it ) Where do you get it, on the LCD display or on the serial port? If you get it on the serial port, then probably you've problems with programming the clocks inside the i.MX21. I had to use a very strange clock in my board-specific board-setup code (I compiled my own i.MX21 kernel). > and then I get a strange image with dots and random > colours. That's not an issue. When I boot my kernel via HaRET, I always get this display, it's just kernel code sitting inside the LCD framebuffer. As the LCD controller doesn't modify the framebuffer memory, this is no harm for the debugging case: it will executed perfectly nethertheless. > It then freezes with the same random pattern. That's probably because you didn't make your own kernel, taylored to your board. And because you probably have the wrong kernel command line. And probably because you don't have a file-system. > Should I try to establish a network connection to Harret and > will that give me more messages ? While WinCE was running on my device, I used a network connection (via synce and pppd from Linux) and uses haretconsole to poke around in my device. That migth be helpful in getting knowing your device. After all, HaRET is more a reverse-engeneering tool and less a WinCE-based bootloader. > Will that give me the kernel output ? Probably not. You'll get kernel output by finding out where your serial port is and by supplying the proper console= command line to your kernel. -- http://www.holgerschurig.de _______________________________________________ Haret mailing list [email protected] https://handhelds.org/mailman/listinfo/haret
