On 12/19/2010 12:02 AM, Gordan Bobic wrote: > On 12/18/2010 11:37 PM, Andrew Burgess wrote: > >> another tack is to change the baudrate in minicom. try 9600 to start, >> it's common. >> >> the theory (i think) is that your kernel reprogrammed the serial >> port baudrate. > > That would imply that the kernel acquired from here: > http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6.30-sheevaplug > > > does that. Surely, if it does, somebody else would have noticed before me? > > I just tried booting the same kernel off tftp and if I do: > > setenv bootargs console=ttyS0,115200 > tftpboot 0x6400000 uimage.bin > bootm 0x6400000 > > The same thing happens - the server gets as far as decompressing OK, and > then the console gets garbaged. > > If I don't setenv bootargs with the console setting, the console stays > silent after the kernel decompresses, which implies that the problem is > indeed connected to the kernel doing something wrong with the serial > console settings. Is there an alternative kernel I could try? Sorry, replying to my own post again. OK, it's _definitely_ the kernel that is broken. How nobody noticed that I've no idea, but I just tried this kernel: http://fedora.danny.cz/arm/kirkwood/2.6.32/uImage-2.6.32.2-kw and that boots fine. Is it really, and I mean REALLY possible that nobody else noticed this before? The 2.6.30 kernel I linked earlier is the one referenced all over the place in all the different writeups and documentation I've seen. How can it possibly be broken? Is this some kind of a weird bug triggered by specific hardware? My sheevaplug is about a week old, so I suppose it is plusible that the latest batch is somehow subtly different. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
