Posted by planetbeing on under grunt work, community style, boot menu, heart of the problem, optis, pixel data, collaborative community, geometries, e mail, gradients, opti, data structures, peek, proposals, peoe, proposal, linux, blog | 
I think the best way to handle this is for anyone interested to submit a proposal via e-mail to me about the boot menu. Then, I can put up the pictures on the blog for people to comment and have an opinion about. We can then figure out which one to use or maybe some combination of proposals or in any case, figure it out in a collaborative community style process.
I don't really have an opinion on what the logo should look like, whether it should be cartoony or not. I only think it should look good. =P
There are very few technical constraints on the boot menu. I'm willing to figure out whatever technical solution there needs be in order to get things to display properly. One thing to keep in mind is that space on the NOR is at a significant premium, and raw pixel data is expensive but procedurally generated stuff like gradients are possible. The only two current menu options are the iPhone OS and the openiboot console, but eventually a Linux option will be added. I can try animation as well, but again, you'd have to have an idea of how it can be done without using up a lot of NOR space.
But yeah, make us pretty!
Some progress on the NAND: Thanks to a huge amount of initial grunt work by CPICH, the NAND project is off the ground. We already have enough to get the proper drive geometries, and I've written and tested the DMA routines that are near the heart of the problem today. Hopefully, we can dump the raw NAND soon and take a peek at what kind of wear leveling data structures we're dealing with.
Tagi: grunt work, community style, boot menu, heart of the problem, optis, pixel data, collaborative community, geometries, e mail, gradients, opti, data structures, peek, proposals, peoe, proposal, linux, blog
Posted by planetbeing on under raw hardware, e care, bad blocks, locati, ftl, data structures, slew, gadget, amount of time, algorithms, kernel, sectors, ace, yaffs, proposal, benefit, linux |
We've made some progress on the USB gadget driver for Linux, and we're now running a generic serial gadget for communication. This implementation is important because USB is now a lot less laggy and things like ethernet over USB, etc., can eventually be supported, easing access.
We've also got pretty far with porting the NAND driver to Linux. Most of the read support is now there, and we've isolated the routines in the iPhone kernel where the raw hardware write occurs. CPICH and c1de0x are working on reversing it. Hopefully, it will be analogous enough to reads that it won't take a huge amount of time to work out.
This is different from reversing their FTL, however, which is a complicated slew of data structures, merge buffers and other exotic algorithms that take care of evenly distributing writes throughout the device and also making writes take less time.
I think reversing all of that would take too much time and effort. Instead, my proposal is to just reverse the hardware NAND writes. Instead of using a partition, we would have a loop-mounted root filesystem (similar to how Wubi is setup), with the root filesystem being a file on the Media partition. Since there's a non-empty file at that location, the FTL system, whatever it is, must create a one-to-one mapping from logical sectors to physical NAND pages. We can already read the mapping it creates (we have already reversed the read-side FTL code), and so all we have to do to alter the data is to write to the same pages we would've read from. Of course, this means that wear-leveling and bad block handling is not performed. However, if we use a filesystem that's aware of bad blocks and can wear-level (YAFFS or JFFS2), then it amounts to the same thing. The wear-leveling would then take place over the particular physical pages belonging to the rootfs image, rather than the entirety of the NAND. This would make the physical pages belonging to the rootfs image wear out a little faster than the rest of the NAND, but the actual effect of this should be inconsequential.
The additional benefit of this setup is that there's no repartitioning required, so setup is cinch. See
this wiki document for specific proposed implementation details.
Tagi: raw hardware, e care, bad blocks, locati, ftl, data structures, slew, gadget, amount of time, algorithms, kernel, sectors, ace, yaffs, proposal, benefit, linux
Posted by planetbeing on under th project, source release, comex, modern computer, serial cable, c code, iboot, android, descriptor, data structures, nutshell, comm, usb 2, bugs, samsung, developers |
Just a post to indicate things are inching forward slightly. I've been working on debugging USB communications and it seems a lot more stable now. I was basically forced to because my old code only works on computers without usb 2.0, so that ruled out being able to easily work on this project with anything approaching a modern computer. The problem was that I avoided reading the official USB specs (those things are usually overly locutious) and tried to learn instead from sites such as USB in a Nutshell. Unfortunately the driver then failed to properly respond to the device qualifier descriptor which led to epic fail in USB 2.0. The embarrassing thing is iBoot does send this descriptor, but I figured it must be a vendor specific one at the time.
Cmw made me a cable that let's me do serial and USB comm at the same time, which helped a lot in working out the bugs. I'd say it's fairly reliable now; enough for other developers without a serial cable to come in. So how about it, guys?
I've also started to scratch the surface of the NAND driver. Unfortunately, even the lowest level functions are enormously complex. The higher level wear leveling code and data structures even aside. A great deal of it seems to belong to Samsung, since I've found some creepily similar C code lurking around online. Unfortunately, I can't find a complete enough copy of it.
And yes, I'm aware of Android and their source release and yes, I know what you're thinking.
Tagi: th project, source release, comex, modern computer, serial cable, c code, iboot, android, descriptor, data structures, nutshell, comm, usb 2, bugs, samsung, developers
