Re: MokoMakefile now supports running the Neo1973 emulator
Rod Whitby wrote:
These are now done:
I've downloaded MokoMakefile (thanks for the great work!) and run
make setup
make openmoko-devel-image
These two succeded. I'm running Ubuntu Feisty.
Then I ran
make qemu
and it seems it's broken - it complains during build, then starts the
emulator, but can't mount root fs. The last words emulated phone says are
No filesystem could mount root, tried: jffs2
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
The log of make qemu is attached. What may be the reason? Should I try
to setup neo-qemu manually?
Sincerely yours,
Dmitri
[ -e build/qemu ] || \
( cd build ; mkdir -p qemu )
[ -e build/qemu/Makefile ] || \
( . ./setup-env ; cd build/qemu ; \
${OMDIR}/openmoko/trunk/src/host/qemu-neo1973/configure \
--target-list=arm-softmmu )
[ -e build/qemu/openmoko ] || \
( . ./setup-env ; cd build/qemu ; mkdir openmoko ; \
for f in ${OMDIR}/openmoko/trunk/src/host/qemu-neo1973/openmoko/* ;
do \
ln -s $f openmoko/`basename $f` ; \
done )
[ -d stamps ] || mkdir stamps
touch stamps/qemu
( cd build/qemu ; make )
make[1]: Entering directory `/home/dmitri/moko/build/qemu'
make -C arm-softmmu all
make[2]: Entering directory `/home/dmitri/moko/build/qemu/arm-softmmu'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/dmitri/moko/build/qemu/arm-softmmu'
make[1]: Leaving directory `/home/dmitri/moko/build/qemu'
[ -e images/openmoko ] || mkdir -p images/openmoko
ln -sf `pwd`/openmoko/trunk/src/host/qemu-neo1973/openmoko/env
images/openmoko/env
( cd images ; ../openmoko/trunk/src/host/qemu-neo1973/openmoko/download.sh )
Retrieving available builds list...
Kernel is... uImage-2.6-moko9-r0_0_1754_0-fic-gta01.bin
Root filesystem is...
openmoko-devel-image-fic-gta01-20070415224624.rootfs.jffs2
U-boot is...
u-boot-gta01bv4-r4_37837828d89084879bee2f2b8c7c68d4695940df_0_1804.bin
Now use openmoko/flash.sh to install OpenMoko to NAND Flash.
rm -f images/openmoko/env
[ -d stamps ] || mkdir stamps
touch stamps/images
( cd build/qemu ; openmoko/flash.sh ../../images/openmoko )
/usr/bin/pngtopnm
/usr/bin/ppmtorgb3
make[1]: Entering directory `/home/dmitri/moko/build/qemu/openmoko'
make[1]: `splash.gz' is up to date.
make[1]: Leaving directory `/home/dmitri/moko/build/qemu/openmoko'
Using 'uImage-2.6-moko9-r0_0_1754_0-fic-gta01.bin' as the kernel image.
Using 'openmoko-devel-image-fic-gta01-20070415224624.rootfs.jffs2' as the root
filesystem image.
Using 'u-boot-gta01bv4-r4_37837828d89084879bee2f2b8c7c68d4695940df_0_1804.bin'
as bootloader.
make[1]: Entering directory `/home/dmitri/moko/build/qemu/openmoko'
# Making an empty/erased flash image. Need a correct echo behavior.
echo -en \\0377\\0377\\0377\\0377\\0377\\0377\\0377\\0377 > .8b
cat .8b .8b > .16b # OOB is 16 bytes
cat .16b .16b .16b .16b .16b .16b .16b .16b > .512b
cat .16b .16b .16b .16b .16b .16b .16b .16b >> .512b
cat .16b .16b .16b .16b .16b .16b .16b .16b >> .512b
cat .16b .16b .16b .16b .16b .16b .16b .16b >> .512b
cat .512b .16b > .sec # A sector is 512 bytes of data + OOB
cat .sec .sec .sec .sec .sec .sec .sec .sec > .8sec
cat .8sec .8sec .8sec .8sec .8sec .8sec .8sec .8sec > .64sec
cat .64sec .64sec .64sec .64sec .64sec .64sec .64sec .64sec > .512sec
cat .512sec .512sec .512sec .512sec > .2ksec
cat .2ksec .2ksec .2ksec .2ksec .2ksec .2ksec .2ksec .2ksec > .16ksec
# Neo NAND is 128k sectors big
cat .16ksec .16ksec .16ksec .16ksec .16ksec .16ksec .16ksec .16ksec >
openmoko-flash.image
rm -rf .8b .16b .512b .sec .8sec .64sec .512sec .2ksec .16ksec
make[1]: Leaving directory `/home/dmitri/moko/build/qemu/openmoko'
neo_gsm_switch: GSM disabled.
U-Boot 1.2.0-moko7 (Apr 19 2007 - 13:30:07)
DRAM: 128 MB
NAND: Bad block table not found for chip 0
Bad block table not found for chip 0
64 MiB
*** Warning - bad CRC or NAND, using default environment
Please wait, programming the NAND flash...
Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
mtdparts variable not set, see 'help mtdparts'
mtdparts variable not set, see 'help mtdparts'
mtdparts variable not set, see 'help mtdparts'
mtdparts variable not set, see 'help mtdparts'
mtdparts variable not set, see 'help mtdparts'
In:serial
Out: serial
Err: serial
pcf_write: charging in Qualification Mode.
pcf_write: charge voltage 4.20V.
neo_lcd_rst_switch: LCD reset.
jbt6k74_command: Display on.
neo_bl_switch: LCD Backlight now on.
GTA01Bv4 #
GTA01Bv4 # setenv dontask y
GTA01Bv4 # nand createbbt
Create BBT and erase everything ?
Erasing at 0x0 -- 0% complete.
Erasing at 0xa -- 1% complete.
Erasing at 0x144000 -- 2% complete.
Erasing at 0x1e8000 -- 3% complete.
Erasing at 0x28c000 -- 4% complete.
Erasing at 0x33 -- 5% complete.
Erasing at 0x3d4000 -- 6% complete.
Erasing at 0x478000 -- 7% complete.
Erasing at 0x51c000 -- 8% complete.
Erasing at 0x5c
Re: Status update on the phones?
The most recent date I have seen was "second half of April". That was awhile back. Basically they have one week from today to deliver, or we are looking at yet another delay. :( Looking at the open defect list on the bugzilla site (http://bugzilla.openmoko.org) makes it seem that they have a long way to go. Open defects include: 321 - ftdi_eeprom often fails silently 365: Openmoko dialer fails after gsmd restart 482: Phone Consumes power when turned off; causes battery to drain. 255: "Battery remaining" meter still needs work I'm sure I will get to buy a Neo, someday :) -Jason On Wednesday 18 April 2007 17:06:36 Marcel de Jong wrote: > Hi all, > > I was wondering (along, I'm sure, with many others here on this list) > what the current status is of the P1 phones. > Is there 'light at the end of the tunnel' yet, for you guys? :) > A few weeks ago, Sean mentioned some problems that might be quickly > fixed, or might need another hardware spin. I'm curious what it > eventually was/is. :) > > Also, can translators already start doing some work on (some of) the > apps (aside from the Wiki that is), or are these apps still too much in > flux? > > If we can start translating, is there somewhere a way to be able to grab > the sources, and update the translation files? > > I tried the rsync instructions on this page: > http://wiki.openmoko.org/wiki/OpenMoko#Developer_Workstations > But that didn't work out for me. (my coding skills are rusty, and I > don't have much experience working with rsync or with svn.) > > Or do I need to use the Openmoko makefile to grab these files? > > sincerely, > Marcel de Jong > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: picture viewer
That's too complicated and too slow... On 4/21/07, Karsten Ensinger <[EMAIL PROTECTED]> wrote: Why is eveyone trying to fit everything into one use case? It will be really hard to remember every special move to get a specific feature working. Why not introduce a "command mode" one can reach with the same "move" and then "entering" a letter to get a special mode where every "move" is manipulating the "item" in a comparable manner. To be more specific (the chosen taps and letters are just for example): Whenever the user does a double tap, he enters command mode signalized in the status bar. Then he uses his finger to "write" a letter "Z" (means: moving the finger horizontally to the right, diagonally from the end of the horizontally move down to the left and again horizontally to the right) to enter zoom mode. Now every move downwards zooms in and every move upwards zooms out. Another example would be letter "M" for moving. Every drag would then mean to move the underlying item. Letter "B" for browsing. Moving rigth and left means forward and backwards one item. Moving up means "a page" forward, moving down "a page" backwards. Of course the user has the ability to determine the amount of items for "a page". Several other modes could be possible, just use your imagination. Of course it's not as fast as having all commands/possibilities concurrently, because one has to change command modes. But I think it's more intuitive to learn one mode by a time than to wonder what happened when you mix several manipulation modes by accident due to making a "wrong" move. To remember a single move for changing into command mode and several letters for the specific modes is easy. Within a mode, using the moves should be intuitive enough to get learned by doing within seconds. Especially when you use opposed moves for doing one thing and reverting the result. Another advantage would be, that one is not forced to use more than one finger at the same time. Regards Karsten Ortwin Regel wrote: > Interesting... However, what about zooming out again? Also this would > take too much time while possibly being too fast for my grandparents. > Holding the second tap is a bad idea but dragging it around might be a > good one. All in all, how about this: > > drag finger --> drag viewable area > tap, then tap again, hold and drag --> zoom in and out > tap sides --> change to next/last picture (can be changed to requiring > double tap in config) > > What is missing? The gesture that brings up the on slideshow menu > where you can escape from the slideshow, rotate the picture, jump to > first/last with simple buttons. The only reasonable thing I can think > of is a double tap in the center of the screen. What to use the wheel > for in that menu? Scrolling through pictures quickly, of course! > > Ortwin > > On 4/20/07, Steven Milburn <[EMAIL PROTECTED]> wrote: >> If you want smooth scrolling, how about this mod to what I said earlier: >> >> On the double-tap to center-and-zoom, hold the the second tap. The pic >> slowly (human speed) zooms and centers to where you're touching. When >> you've zoomed in enough, lift the finger. This would be similar to >> the way >> CTRL-wheel on Adobe pdf's zooms and centers. >> >> --Steve >> >> >> ___ >> OpenMoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> >> > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
