Daily Snapshot Reviews

Peter Rasmussen plr at udgaard.com
Thu Jan 31 21:45:29 CET 2008

Kevin Dean wrote:
>> I would the like to ask if it is then possible to structure this testing
>> even more, and have the following would be great:
>> 1. A way to see what actually changes between builds.
> Subscribing to openmoko-commits will notify you whenever a new
> revision is checked in. I get daily digested logs. I think to have all
> of the developers (some of whom are not emplyed by OpenMoko Inc.) do
> daily changelogs OUTSIDE of the source itself is kind of an unfair
> requirement, but if you look at commits you'll see from a birds-eye
> view what's happening.
Thanks for the pointer.

It is however, an ever returning issue where software development takes 
place, and it has to be balanced, with who should do what to get 
somebody else become more efficient.
>> 3. Not on a personal level, but I would like to know if feature-A is
>> being worked on, and feature-B is on standby, while bug-A will have to
>> wait for bug-B to be fixed, etc.
> In general, a roadmap would be nice, I agree. Or even more than that,
> a list of who is actually doing development, so that people interested
> in hacking can contact the people to discuss and submit to. I think a
> bunch of people have good ideas and aren't willing to write them for
> fear that 13 days into a 14 day project that feature will appear in
> the builds. :( I am, however, unsure how we (as the community) could
> actually organize that in any decent manner without input from OM Inc
> and it's affiliates or at the very least developers. The problem is,
> any dev who takes that project on is now coding less. :(
It isn't just the volume of coding that is important. And it doesn't 
have to be an actual coder that implements stuff that has to do it. With 
a true open environment other people should be able to contribute. With 
that mindset, coders shouldn't go to conferences or show off the devices 
at meetings either, should they?
>> 4. Request for the following features that will help testing:
>>    A. A way to see the release version of both u-boot, kernel and
>> rootfs, on a running system. If I need to open a terminal and issue a
>> command, that will be fine.
> To see a u-Boot version, hold AUX and power on the device. You'll see
> at the top of the screen the version number. If it times out for you,
> consider connecting from your computer and issuing "setenv
> boot_menu_timeout 65000" to extend the time uBoot stays "awake".
Yes, then I can see the u-boot version, but I still have to reboot to 
get to that screen, and that is what I want to avoid. And after loading 
the kernel and the rootfs, I still don't have a way to see the release 
of what is actually loaded.
>>    B. An update (probably) to u-boot that will accept multiple kernel
>> and rootfs on the same SD/SDHC card.
>>    C. An update (probably) to u-boot that will accept upload of a tar
>> file or some other prepared image, directly to the SD/SDHC card, while
>> in bootloader more, and be able to specify the root directory from where
>> to unpack.
>> I prefer to have rootfs images put on the SD/SDHC card, as that is one I
>> can change when it is worn out, whereas I can't change the one inside
>> the Neo. Technically I would have designed the Neo (or any other mobile
>> that has flash-card capability) so all flash was on the removable card.
>> It should make production cheaper as update to units were only dependent
>> on exchanging the flash card.
> As a developer oriented device, I can see how that would have merit
> but as a consumer device I'd imagine very few people will EVER exceed
> the number of writes to the NAND considering the typical life of a
> mobile device. Also, my current uBoot snapshot has the capacity to
> boot from SD once an image is put on the card. You have to specific
> manually where this image resides but again, as a consumer device, and
> not a developer device, very few people will ever do more than boot
> their standard, pre-installed image, let alone need multiple kernel
> options, different rootfs and the ability to swap them around.
The Neo *is* a developer's device, and I would like everyone to admit 
and recognize that. And as far as I remember, that is also what it says 
on the openmoko.com pages.
We can start polishing it up for the masses when it is ready for them, 
but why not make it easier for the rest of us while it is in the present 

It would make testing easier, if I could for example set up the boot 
loader to have "System 1", "System 2", "System 3", etc. to boot from the 
SD/SDHC card, and when I want to upload a new image, I then specify 
where to put it. From the root of the mounted card, it could be 
/system1, /system2, system3.

Presently I can get an 8GB SDHC card for just $100USD, and that will 
contain many images at once. Being able to switch back and forth without 
having to also upload them again would be a nice feature for testing.
> On another note, putting the rootfs on the SD card adds the burden on
> the user. How do you advertise a device as "expandable" of expanding
> it requires the user to copy their rootfs over to the new (higher
> capacity) card just to be able to store more music? I think FIC and
> OM's decision to leave the SD card as storage, and have the OS "on the
> device" makes more sense considering over all intent.
Yes, when it becomes a mass user device, it may be limited in what can 
be used where, in order not to confuse regular users.


More information about the device-owners mailing list