Hi, * Woodruff, Richard <r-woodruff2@xxxxxx> [071126 09:06]: > > On Mon, 26 Nov 2007, Kyungmin Park wrote: > > > > > With recent runtime constatns patches, we can't boot the board if the > > sram is locked. > > > I'm not sure it's the proper patch enables R/W access to all omap242x. > > > But without this patch, it gives the following messages and abort on > > linefecth > > > > I am puzzled. > > > > You have definitely found a bug. It seems that TI, for some unknown > > reason, moved some SCM registers, including CONTROL_STATUS, for 34xx, > > breaking forward compatibility. And as you point out, the offset for > > CONTROL_STATUS in the recent patch is not right for 242x. (It's the > > 34xx offset.) > > 24xx is not 34xx. Among others pieces around PRCM, Security, package-configuration will be different. Trying to hide omap3 under omap2 just makes some of these things harder to rediscover as the git tree evolves. Although it's more work, making things work in a general way is the best solution in the long run. > To make OFF mode work for targeted use cases, and match with trust zone security some register groups have been split or moved. > > > I would think this would prevent 242x from booting. Indeed, you report > > that your setup doesn't boot. But when I boot current git on N800 here, > > which is 2420-based, it boots fine. Puzzling evidence. > > ** Probably your boot loader does it and his doesn't. And/Or there are a couple other bugs around Type (emu,hs,gp,tst) and ES version. > > There are real behavioral differences between GP and EMU devices and in some cases also differences between ES versions of the chip as to what mask ROM code does for you. Firewall settings are one major part. Boot testing on one GP device of one ES version is really not enough. > > I think this kind of thing also was evident in the UART clock setting. The u-boot we use is only turning on what is necessary where it seems the nokia one is configuring a lot more. > > * The Nokia boot loader should do as little as possible in clock and security regards else there is a danger the kernel will need a lot of rework when you try and use these features more optimally. I agree with that. We must (re-)initialize everything in the kernel, otherwise we'll end up with mysterious bug reports like this on things working on some boards and failing on others. Regards, Tony - To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
