Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #1843: u-boot's DFU upload garbles data at
block boundary (Openmoko Public Trac)
2. Re: Openmoko Bug #2062: xglamo doesn't implement any power
management (Openmoko Public Trac)
3. Re: Openmoko Bug #2029: [qtopia] +CUSD wronlgy decoded
(Openmoko Public Trac)
4. Re: Openmoko Bug #2057: 1bit errors in files
(Openmoko Public Trac)
5. Re: Openmoko Bug #2057: 1bit errors in files
(Openmoko Public Trac)
6. Re: Openmoko Bug #2057: 1bit errors in files
(Openmoko Public Trac)
7. Re: Openmoko Bug #1595: GTA02 - uboot 1.3.2rc2 terminal
s3ser0 doesn't work apparently (Openmoko Public Trac)
8. Re: Openmoko Bug #1691: [Qtopia] qpe crash happened after
flash the new image (Openmoko Public Trac)
--- Begin Message ---
#1843: u-boot's DFU upload garbles data at block boundary
--------------------------------+-------------------------------------------
Reporter: wiml | Owner: laforge
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: System Software | Version: GTA02v6
Severity: major | Resolution:
Keywords: dfu | Blockedby:
Reproducible: | Blocking: 676
--------------------------------+-------------------------------------------
Changes (by laforge):
* blocking: => 676
Comment:
thanks for the detailed analyisis, it really describes well why many
people have been experiencing various upload related problems (and it was
never working, at least not on GTA02 where the erazeblock size is much
bigger than on GTA01).
I'm right now working on altering the code. It's not as straight-forward
as you may think. We are under tight constraints by the DFU spec, i.e.
whatever amount of bytes the host asks us for, we need to deliver it. If
we'd return less than what was asked for, this would implicitly mean
the end of a transmission. I also do not want to introduce a second
buffer (for the URB), since
that would mean we always need to memcpy() and it would further increase
the memory requirements
of u-boot.
The current code structure is a result from trying to implement UPLOAD
based on the infrastructure that DOWNLOAD provided. For download it makes
sense to think in terms of nand
erase blocks. For upload it actually makes much more sense to think in
terms of whatever amount
of bytes the host requests.
I'll try to rework the logic accordingly.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1843#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2062: xglamo doesn't implement any power management
--------------------------------+-------------------------------------------
Reporter: laforge | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
--------------------------------+-------------------------------------------
Comment(by zecke):
Yes, only the kernel can know which other units of the glamo are unused
and can power them down. But I agree that it needs addressing.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2062#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2029: [qtopia] +CUSD wronlgy decoded
------------------------+---------------------------------------------------
Reporter: vnevoa | Owner: tick
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: unknown | Version: Om2008.8
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by zecke):
Okay I landed the patch but it might not fix the bug. As we still need to
properly decode the string according to the charset as Trevino pointed
out.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2029#comment:20>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2057: 1bit errors in files
---------------------------------------------+------------------------------
Reporter: Richard.Kralovic | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: file corruption, 1bit errors | Blockedby:
Reproducible: rarely | Blocking:
---------------------------------------------+------------------------------
Comment(by andy):
Hum seems U-Boot doesn't take care of its own memory footprint for the
memory test, I found I could run it in two halves missing a critical bit
out...
mtest 30000000 33c00000
mtest 34000000 38000000
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2057#comment:5>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2057: 1bit errors in files
---------------------------------------------+------------------------------
Reporter: Richard.Kralovic | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: file corruption, 1bit errors | Blockedby:
Reproducible: rarely | Blocking:
---------------------------------------------+------------------------------
Comment(by Richard.Kralovic):
Thanks. I still had problems running mtest on full 34000000 38000000
range, but 34100000 37e00000 works fine. After few hours, mtest found the
bad bits, too:
GTA02v6 # mtest 34100000 37e00000 55555555
Pattern 555555DD Writing... Reading...
Mem error @ 0x351000C0: found 55B5560D, expected 5595560D
Mem error @ 0x351198C0: found 55B5BC0D, expected 5595BC0D
Mem error @ 0x351278C0: found 55B5F40D, expected 5595F40D
Mem error @ 0x351360C0: found 55B62E0D, expected 55962E0D
Mem error @ 0x351398C0: found 55B63C0D, expected 55963C0D
Mem error @ 0x351440C0: found 55B6660D, expected 5596660D
Mem error @ 0x3515C0C0: found 55B6C60D, expected 5596C60D
Mem error @ 0x3515D8C0: found 55B6CC0D, expected 5596CC0D
Mem error @ 0x351620C0: found 55B6DE0D, expected 5596DE0D
Mem error @ 0x3516D8C0: found 55B70C0D, expected 55970C0D
Mem error @ 0x351758C0: found 55B72C0D, expected 55972C0D
Mem error @ 0x3517D8C0: found 55B74C0D, expected 55974C0D
Mem error @ 0x3517E0C0: found 55B74E0D, expected 55974E0D
Mem error @ 0x351CF8C0: found 55B8940D, expected 5598940D
Mem error @ 0x351E40C0: found 55B8E60D, expected 5598E60D
Mem error @ 0x351EC0C0: found 55B9060D, expected 5599060D
Mem error @ 0x351ED8C0: found 55B90C0D, expected 55990C0D
Mem error @ 0x351F00C0: found 55B9160D, expected 5599160D
So it definitely is bad sdram.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2057#comment:6>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2057: 1bit errors in files
---------------------------------------------+------------------------------
Reporter: Richard.Kralovic | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: file corruption, 1bit errors | Blockedby:
Reproducible: rarely | Blocking:
---------------------------------------------+------------------------------
Comment(by andy):
And as expected in the second half of it so in the external SDRAM chip. I
think it is probably related that you had to trim the extent of the test
as well, I did not have to do that. I would request a swapout from your
vendor, I'm not sure how that's handled but it does seem to be a faulty
device from our side.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2057#comment:7>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1595: GTA02 - uboot 1.3.2rc2 terminal s3ser0 doesn't work apparently
---------------------------------+------------------------------------------
Reporter: frances.albanese | Owner: laforge
Type: defect | Status: closed
Priority: normal | Milestone:
Component: System Software | Version: GTA02v6
Severity: normal | Resolution: fixed
Keywords: | Blockedby:
Reproducible: | Blocking:
---------------------------------+------------------------------------------
Changes (by laforge):
* status: assigned => closed
* resolution: => fixed
Comment:
merged to the stable branch of u-boot.git
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1595#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1691: [Qtopia] qpe crash happened after flash the new image
---------------------------+------------------------------------------------
Reporter: wendy_hung | Owner: tick
Type: defect | Status: accepted
Priority: highest | Milestone: Om2008.10
Component: Qtopia | Version:
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
---------------------------+------------------------------------------------
Comment(by goldie):
{{{
qtopia-phone-x11 -
1:4.3.2+gitr429+563d5f4c781efe1a11680c6a055b409034b528ab-r41 -
kernel - 3:2.6.24+gitr75969+a1e97c611253511ffc2d8c45e3e6d6894fa03fa3-r2 -
FDOM, testing branch
}}}
Removed the SD card, nothing changed for me.
I also attached gdb to the qpe process:
{{{
[EMAIL PROTECTED]:~# gdb --pid=1380
GNU gdb 6.8
(...)
This GDB was configured as "arm-angstrom-linux-gnueabi".
Attaching to process 1380
Reading symbols (...)
(gdb) continue
Continuing.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x41aa6570 (LWP 1380)]
0x41874df4 in raise () from /lib/libc.so.6
(gdb) backtrace
#0 0x41874df4 in raise () from /lib/libc.so.6
#1 0x418763fc in abort () from /lib/libc.so.6
Backtrace stopped: frame did not save the PC
}}}
Messages in /var/log/messages are the same.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1691#comment:18>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
