On Monday, December 16, 2013 10:12:08 PM Ben Wong wrote:
> > There must be some timing problem. It can be quite tricky to debug it,
> > because with logging it works and with debugging enabled it works too.
>
> Timing with the AT communications? Would that be the chat script?
No idea, i guess it
> There must be some timing problem. It can be quite tricky to debug it,
> because with logging it works and with debugging enabled it works too.
Timing with the AT communications? Would that be the chat script?
> 3/ implement better screen locking. Now if you lock screen and receive phone
> cal
On Monday, December 16, 2013 04:11:20 AM Jorge wrote:
> Me too, jffs works but had to enable modem logging to get trough the pin
> screen.
There must be some timing problem. It can be quite tricky to debug it, because
with logging it works and with debugging enabled it works too.
But with loggi
Me too, jffs works but had to enable modem logging to get trough the pin
screen.
Jorge
On 14/12/13 13:41, Francesco De Vita wrote:
Thank you Radek, the jffs2 image works on NAND!
But, as happened for the uSD version, the system stops at the PIN
screen. However, as you suggested, enabling the m
Weirdly, I'm getting a panic on boot with the JFFS2 images for rootfs
and u-boot. I'll try resending with dfu-util again.
—B
P.S. When I mentioned using 'dd' before to write directly, I meant to
say 'nandwrite'.
On Sat, Dec 14, 2013 at 7:41 AM, Francesco De Vita
wrote:
> Thank you Radek, the jf
Thank you Radek, the jffs2 image works on NAND!
But, as happened for the uSD version, the system stops at the PIN
screen. However, as you suggested, enabling the modem logging solves the
problem.
Regards
Joif
___
Openmoko community mailing list
communit
On Friday, December 13, 2013 04:18:13 PM Francesco De Vita wrote:
> > Is the tarball ok at least?
>
> Tested on the uSD and it is ok
> ...apart that I'm stuck at the PIN entry screen (that one with just the
> notice "Please wait...") no matter how many times I restart. But from
> ssh all seems to
On Friday, December 13, 2013 04:18:13 PM Francesco De Vita wrote:
> > Is the tarball ok at least?
>
> Tested on the uSD and it is ok
> ...apart that I'm stuck at the PIN entry screen (that one with just the
> notice "Please wait...") no matter how many times I restart. But from
> ssh all seems to
> Is the tarball ok at least?
Tested on the uSD and it is ok
...apart that I'm stuck at the PIN entry screen (that one with just the
notice "Please wait...") no matter how many times I restart. But from
ssh all seems to work well.
Joif
___
Openmoko co
> The size should be ok. NAND is IIRC 256MB. Would you be interested to try
> jffs2? I can do it and upload quite easily.
Sure, I'd give that a shot if it's easy for you to do. I seem to have
more corruption problems from ubifs than jffs2, so wouldn't mind going
back.
—B
On Friday, December 13, 2013 01:25:47 PM Ben Wong wrote:
> I tried qi-v58 first then qi-v56 as a test. Neither worked. Haven't
> tried the tarball; I don't have an SD card handy and (correct me if
> I'm wrong) there's no way to unpack the tarball onto the NAND unless
> you've already booted from S
On Fri 13 December 2013 13:25:47 Ben Wong wrote:
> Are you using dfu-util or dd to write to the NAND?
dd to write to NAND? :-o Don't do that!
That's prone to fail, since dd can't handle bad blocks, and NAND per
definitionem doesn't. That's why you got things like jffs2/ubifs
/j
--
() ascii rib
On Thu, Dec 12, 2013 at 11:10 PM, Radek Polak wrote:
> On Friday, December 13, 2013 02:59:01 AM Ben Wong wrote:
>
>> What's the checksum supposed to be for the QTMoko files?
>
> a76072c1c9dce4eb2b07235f7cc307fe qtmoko-debian-gta02-v58.ubi
> 50baec96657802b5a053fa0ef6b777a2 uImage.bin-2.6.39-qtmoko
> 882cc204627226ffefda4e446fae3862 qtmoko-debian-gta02-v58.tar.gz
>
> a76072c1c9dce4eb2b07235f7cc307fe qtmoko-debian-gta02-v58.ubi
>
> 50baec96657802b5a053fa0ef6b777a2 uImage.bin-2.6.39-qtmoko-v58
>
checksum ok
> This is strange - it works for me. Are you booting with qi-v58.udfu?
Yep, I also
On Friday, December 13, 2013 02:59:01 AM Ben Wong wrote:
> Hey Joif,
>
> You're not alone. I get the same message with v58 in NAND; haven't
> tried on SD yet.
>
> I thought it might be DFU transferring the file system incorrectly,
> but seeing that you have the same problem, I think perhaps the
This is my main phone, so I've reverted to v55 (the latest one I could
find on sourceforge) and it seems to be working.
—B
On Thu, Dec 12, 2013 at 6:29 PM, Jorge wrote:
> Yup, same here. No booting from NAND.
>
>
>
> On 12/12/13 23:59, Ben Wong wrote:
>>
>> Hey Joif,
>>
>> You're not alone. I ge
Yup, same here. No booting from NAND.
On 12/12/13 23:59, Ben Wong wrote:
Hey Joif,
You're not alone. I get the same message with v58 in NAND; haven't
tried on SD yet.
I thought it might be DFU transferring the file system incorrectly,
but seeing that you have the same problem, I think perhaps
Hey Joif,
You're not alone. I get the same message with v58 in NAND; haven't
tried on SD yet.
I thought it might be DFU transferring the file system incorrectly,
but seeing that you have the same problem, I think perhaps the image
on sourceforge is corrupted.
What's the checksum supposed to be f
Hello
Flashing QtMoko v58 I discovered that I'm not able to boot any more
from NAND. This is what I receive after pressing the power button:
UBI error: process_eb: bad image sequence number 1588845893 in PEB 1971,
epxected 1933142073
slab error in kmem_cache_destroy(): cache `ubi_scan_slab': Can't
19 matches
Mail list logo