On Wed, Jun 8, 2011 at 8:16 AM, Chris Jones wrote: > On 08/06/2011 03:26, Wookey wrote: >> +++ Patrick Doyle [2011-06-07 14:41 -0400]: >>> Is there any way to access the NOR flash from Linux on my BalloonBoard? >> >> Not easily. It's not exposed as an mtdblock. It should be, but this is >> probably disruptive becuse it'll bump the numbers of existing >> /dev/mtdblock so bot config needs to change to match. > > There's some history to this. Way back in about 2003, the Balloon 2 > kernel was able to access NOR Flash from Linux. We had problems with the > NOR Flash getting corrupted from time to time on a couple of boards. As > part of trying to figure out what was going wrong, we disabled NOR > access from the kernel. We haven't experienced NOR corruption since, but > we have no strong evidence that this is really what fixed it. Much else > has changed, not least the method of programming NOR which is less flaky > than it has ever been. > > Nobody missed NOR access from the kernel at the time so support for it > just withered away. > > Chris Thanks... knowing the history helps. I think I'll go down the path of enabling access to the FPGA partition of the NOR flash... at least until the "too hard" LED turns on. Then I'll start looking at the bbl path recommended by Wookey. I'm avoiding the bbl path right now because my USB<->RS232 converter only works natively on my MacBook, and I deemed it more difficult (and less fun) to figure out how to make bbl run on the MacBook, than it would be to go hack kernel code. I'll pursue this path (sending patches to the list, as appropriate), until it seems fruitless, or I get distracted by something else. Speaking of getting distracted by something else... Does anybody maintain a git mirror of the svn repository? Would anybody mind if I set up a public git mirror of the repository? Does anybody have personal experience (good or bad) setting up and maintaining a public mirror of an arbitrary svn repository? (There are plenty of generic blog posts on how to do it.) I like git's idea of private "topic" branches on which one can commit, clean up, muse, set aside, come back to, and eventually publish a polished set of patches. I think that will work well with my workflow and will enable me to contribute to the codebase without messing things up too much for others. Anyway, back to my distraction, so I can get back to hacking kernel code, so I can submit a possibly useful patch back to you... --wpd