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 #2057: 1bit errors in files
(Openmoko Public Trac)
2. Re: Openmoko Bug #1843: u-boot's DFU upload garbles data at
block boundary (Openmoko Public Trac)
3. Re: Openmoko Bug #1835: A better fix for host endianness of
dfu-util (Openmoko Public Trac)
4. Re: Openmoko Bug #2062: xglamo doesn't implement any power
management (Openmoko Public Trac)
5. Openmoko Bug #2062: xglamo doesn't implement any power
management (Openmoko Public Trac)
6. Openmoko Bug #2061: LCM (jbt6k74) doesn't go to
sleep/deep_standby modes (Openmoko Public Trac)
7. Re: Openmoko Bug #2061: LCM (jbt6k74) doesn't go to
sleep/deep_standby modes (Openmoko Public Trac)
8. Re: Openmoko Bug #2057: 1bit errors in files
(Openmoko Public Trac)
9. Re: Openmoko Bug #2057: 1bit errors in files
(Openmoko Public Trac)
--- 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):
Ok, it looks like a hardware bug in ram. I run attached simple memory
testing application and it indeed found 1 bit errors... I just hope I'll
be able to get a replacement...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2057#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- 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:
--------------------------------+-------------------------------------------
Changes (by laforge):
* owner: openmoko-kernel => laforge
* status: new => assigned
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1843#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1835: A better fix for host endianness of dfu-util
-------------------------------+--------------------------------------------
Reporter: wiml | Owner: openmoko-devel
Type: defect | Status: closed
Priority: normal | Milestone:
Component: host utilities | Version:
Severity: normal | Resolution: fixed
Keywords: HasPatch | Blockedby:
Reproducible: always | Blocking:
-------------------------------+--------------------------------------------
Changes (by laforge):
* status: new => closed
* resolution: => fixed
Comment:
Thanks, I've applied the patch to subversion (Rev. 4696)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1835#comment:8>
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 andy):
Last time I looked at Xglamo sources it seemed to be based on a cut and
paste of the kernel framebuffer driver for Glamo. There was stuff like
locking for modal command queue and so on that didn't cooperate with the
kernel side implementation for example.
Rather than adding things to XGlamo it might make sense to do these things
on kernel side alone, for example with a callback to machine specific
stuff whenever the backlight is enabled or disabled?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2062#comment:1>
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 | Keywords:
Blockedby: | Reproducible: always
Blocking: |
-----------------------------+----------------------------------------------
the glamo chip has very fine-grained power management features (such as
clock-gating to every hardware functional unit). None of those features
seem to be curently used in xglamo.
All I can find is a function to enable the clocking for a particular unit,
but no function to disable the clocking, and thus no code that ever
switches off any functional unit.
This is important when e.g. going to screen-blank situation. We can
switch off the clocks to 2D engine, the DAC block, even disable any output
of the high-frequency video signal.
And please don't tell me this is not worth optimizing because the system
will suspend to RAM soon after blanking the screen. Imagine your mp3/ogg
player running on the device. You will not suspend to ram, but still
don't want to waste power generating a video signal that nobody can see
due to backlight being blanked
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2062>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2061: LCM (jbt6k74) doesn't go to sleep/deep_standby modes
-----------------------------+----------------------------------------------
Reporter: laforge | Owner: [EMAIL PROTECTED]
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: blocker | Keywords:
Blockedby: | Reproducible: always
Blocking: |
-----------------------------+----------------------------------------------
The LCM itself supports three power modes, and the jbt6k74 driver exports
the switch between the power modes to userspace.
However, there seems to be no userspace power management to actually take
care of doing this.
Therefore, one suggested solution is to register with the framebuffer
notifier and switch the LCM off whenever the backlight is switched off.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2061>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2061: LCM (jbt6k74) doesn't go to sleep/deep_standby modes
--------------------------------+-------------------------------------------
Reporter: laforge | Owner: [EMAIL PROTECTED]
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: minor | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
--------------------------------+-------------------------------------------
Changes (by laforge):
* severity: blocker => minor
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2061#comment:1>
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 cedric.berger):
if you have to live with faulty ram, I guess "badram" might help.
[http://rick.vanrein.org/linux/badram/]
I did not check this since a while ago. But I do not think it is yet
included in standard kernel ?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2057#comment:2>
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):
It's the same bit wrong in both the memtest and the error seen in the
actual file too. I would contact your vendor about it for a replacement.
64MB of the RAM is in the CPU module, the other 64MB is external, it's
quite possible then half the physical memory is fine and half is broken.
As you allocate more virtual memory, it might start to use the second,
broken half after some time.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2057#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
