Menu
▾
▴
linwizard-devel — Developer Mailing List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(6) |
Sep
(1) |
Oct
(6) |
Nov
|
Dec
(8) |
| 2008 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(4) |
Jun
(2) |
Jul
(1) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(22) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(9) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christopher F. <chr...@gm...> - 2011-05-18 17:45:40
|
On Wed, May 18, 2011 at 1:42 PM, Christopher Friedt
<chr...@gm...> wrote:
> =====================================================
> export PORTDIR_OVERLAY="/usr/local/portage/crossdev_overlay"
> export PORTDIR_OVERLAY="${PORTDIR_OVERLAY}
> /usr/local/portage/rockhopper_overlay"
sorry, that should read
export PORTDIR_OVERLAY="/usr/local/portage/crossdev-overlay"
export PORTDIR_OVERLAY="${PORTDIR_OVERLAY}
/usr/local/portage/gentoo-bionic-overlay"
C
|
|
From: Christopher F. <chr...@gm...> - 2011-05-18 17:42:44
|
Hi folks,
Sorry if you're receiving this on #gentoo-embedded as well, but I just
wanted to announce a small project that might be of interest for some
people on this list.
I'm introducing Android's Bionic C library into Gentoo's Portage as
new ELIBC and put together a proof of concept overlay that contains
the libc, icu4c, libxml2, libxslt, zlib, gnu-classpath and jamvm
ebuilds.
It's alpha right now, but runs on amd64 / x86 hardware. I haven't
built it yet for arm, but that arch will be my next victim.
If anyone is interested, it would be great if someone could try
building it from scratch and let me know if there are any speed-bumps.
=====================================================
#!/bin/sh
export PORTDIR_OVERLAY="/usr/local/portage/crossdev_overlay"
export PORTDIR_OVERLAY="${PORTDIR_OVERLAY}
/usr/local/portage/rockhopper_overlay"
emerge =sys-devel/crossdev-20110310 =sys-devel/gnuconfig-20100924
crossdev \
-S \
--g 4.6.0 \
--target i686-pc-linux-bionic
=====================================================
Cheers,
C
================================================
I've made tarball snapshots of the portage overlay (i.e. all source),
sysroot, and toolchain available here[1].
A gitorious project has been set up here[2], but I'm not going to
check-in the overlay until a bit more testing is done.
I've also set up a blog to make announcements here[3], and will be
making the first post after checking the overlay into gitorious and
after one or two people can reproduce the build.
Incidentally, if anyone here has an amd64 or x86 arch running Linux
and would like to do take it for a test drive, download the sysroot
from [1], unpack to /usr/i686-pc-linux-bionic and then run the
following:
===================================
#!/bin/sh
for i in proc sys dev tmp; do
mount -o bind /${i} /usr/i686-pc-linux-bionic/${i}
done
chroot /usr/i686-pc-linux-bionic /bin/sh
===================================
Cheers,
C
[1] http://code.google.com/p/gentoo-bionic
[2] https://gitorious.org/gentoo-bionic
[3] http://gentoo-bionic.blogspot.com
|
|
From: Alistair B. <a.j...@gm...> - 2011-05-01 15:41:18
|
>From de327b86a6692717ff1ec7e6becbb1b099e2ee73 Mon Sep 17 00:00:00 2001 From: Alistair Buxton <a.j...@gm...> Date: Sun, 1 May 2011 16:26:32 +0100 Subject: [PATCH] Remove two unused headers for omap. These were combined into omap7xx.h a long time ago. Any code using either of these headers (of which there is none currently in mainline) should be converted to use omap7xx.h instead. Also fix a reference to omap730.h in a comment. Signed-off-by: Alistair Buxton <a.j...@gm...> --- arch/arm/plat-omap/include/plat/mux.h | 2 +- arch/arm/plat-omap/include/plat/omap730.h | 102 ----------------------------- arch/arm/plat-omap/include/plat/omap850.h | 102 ----------------------------- 3 files changed, 1 insertions(+), 205 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/omap730.h delete mode 100644 arch/arm/plat-omap/include/plat/omap850.h diff --git a/arch/arm/plat-omap/include/plat/mux.h b/arch/arm/plat-omap/include/plat/mux.h index aeba717..3239489 100644 --- a/arch/arm/plat-omap/include/plat/mux.h +++ b/arch/arm/plat-omap/include/plat/mux.h @@ -99,7 +99,7 @@ /* * OMAP730/850 has a slightly different config for the pin mux. - * - config regs are the OMAP7XX_IO_CONF_x regs (see omap730.h) regs and + * - config regs are the OMAP7XX_IO_CONF_x regs (see omap7xx.h) regs and * not the FUNC_MUX_CTRL_x regs from hardware.h * - for pull-up/down, only has one enable bit which is is in the same register * as mux config diff --git a/arch/arm/plat-omap/include/plat/omap730.h b/arch/arm/plat-omap/include/plat/omap730.h deleted file mode 100644 index 14272bc..0000000 --- a/arch/arm/plat-omap/include/plat/omap730.h +++ /dev/null @@ -1,102 +0,0 @@ -/* arch/arm/plat-omap/include/mach/omap730.h - * - * Hardware definitions for TI OMAP730 processor. - * - * Cleanup for Linux-2.6 by Dirk Behme <dir...@de...> - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN - * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#ifndef __ASM_ARCH_OMAP730_H -#define __ASM_ARCH_OMAP730_H - -/* - * ---------------------------------------------------------------------------- - * Base addresses - * ---------------------------------------------------------------------------- - */ - -/* Syntax: XX_BASE = Virtual base address, XX_START = Physical base address */ - -#define OMAP730_DSP_BASE 0xE0000000 -#define OMAP730_DSP_SIZE 0x50000 -#define OMAP730_DSP_START 0xE0000000 - -#define OMAP730_DSPREG_BASE 0xE1000000 -#define OMAP730_DSPREG_SIZE SZ_128K -#define OMAP730_DSPREG_START 0xE1000000 - -/* - * ---------------------------------------------------------------------------- - * OMAP730 specific configuration registers - * ---------------------------------------------------------------------------- - */ -#define OMAP730_CONFIG_BASE 0xfffe1000 -#define OMAP730_IO_CONF_0 0xfffe1070 -#define OMAP730_IO_CONF_1 0xfffe1074 -#define OMAP730_IO_CONF_2 0xfffe1078 -#define OMAP730_IO_CONF_3 0xfffe107c -#define OMAP730_IO_CONF_4 0xfffe1080 -#define OMAP730_IO_CONF_5 0xfffe1084 -#define OMAP730_IO_CONF_6 0xfffe1088 -#define OMAP730_IO_CONF_7 0xfffe108c -#define OMAP730_IO_CONF_8 0xfffe1090 -#define OMAP730_IO_CONF_9 0xfffe1094 -#define OMAP730_IO_CONF_10 0xfffe1098 -#define OMAP730_IO_CONF_11 0xfffe109c -#define OMAP730_IO_CONF_12 0xfffe10a0 -#define OMAP730_IO_CONF_13 0xfffe10a4 - -#define OMAP730_MODE_1 0xfffe1010 -#define OMAP730_MODE_2 0xfffe1014 - -/* CSMI specials: in terms of base + offset */ -#define OMAP730_MODE2_OFFSET 0x14 - -/* - * ---------------------------------------------------------------------------- - * OMAP730 traffic controller configuration registers - * ---------------------------------------------------------------------------- - */ -#define OMAP730_FLASH_CFG_0 0xfffecc10 -#define OMAP730_FLASH_ACFG_0 0xfffecc50 -#define OMAP730_FLASH_CFG_1 0xfffecc14 -#define OMAP730_FLASH_ACFG_1 0xfffecc54 - -/* - * ---------------------------------------------------------------------------- - * OMAP730 DSP control registers - * ---------------------------------------------------------------------------- - */ -#define OMAP730_ICR_BASE 0xfffbb800 -#define OMAP730_DSP_M_CTL 0xfffbb804 -#define OMAP730_DSP_MMU_BASE 0xfffed200 - -/* - * ---------------------------------------------------------------------------- - * OMAP730 PCC_UPLD configuration registers - * ---------------------------------------------------------------------------- - */ -#define OMAP730_PCC_UPLD_CTRL_BASE (0xfffe0900) -#define OMAP730_PCC_UPLD_CTRL (OMAP730_PCC_UPLD_CTRL_BASE + 0x00) - -#endif /* __ASM_ARCH_OMAP730_H */ - diff --git a/arch/arm/plat-omap/include/plat/omap850.h b/arch/arm/plat-omap/include/plat/omap850.h deleted file mode 100644 index c33f679..0000000 --- a/arch/arm/plat-omap/include/plat/omap850.h +++ /dev/null @@ -1,102 +0,0 @@ -/* arch/arm/plat-omap/include/mach/omap850.h - * - * Hardware definitions for TI OMAP850 processor. - * - * Derived from omap730.h by Zebediah C. McClure <zm...@lu...> - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN - * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#ifndef __ASM_ARCH_OMAP850_H -#define __ASM_ARCH_OMAP850_H - -/* - * ---------------------------------------------------------------------------- - * Base addresses - * ---------------------------------------------------------------------------- - */ - -/* Syntax: XX_BASE = Virtual base address, XX_START = Physical base address */ - -#define OMAP850_DSP_BASE 0xE0000000 -#define OMAP850_DSP_SIZE 0x50000 -#define OMAP850_DSP_START 0xE0000000 - -#define OMAP850_DSPREG_BASE 0xE1000000 -#define OMAP850_DSPREG_SIZE SZ_128K -#define OMAP850_DSPREG_START 0xE1000000 - -/* - * ---------------------------------------------------------------------------- - * OMAP850 specific configuration registers - * ---------------------------------------------------------------------------- - */ -#define OMAP850_CONFIG_BASE 0xfffe1000 -#define OMAP850_IO_CONF_0 0xfffe1070 -#define OMAP850_IO_CONF_1 0xfffe1074 -#define OMAP850_IO_CONF_2 0xfffe1078 -#define OMAP850_IO_CONF_3 0xfffe107c -#define OMAP850_IO_CONF_4 0xfffe1080 -#define OMAP850_IO_CONF_5 0xfffe1084 -#define OMAP850_IO_CONF_6 0xfffe1088 -#define OMAP850_IO_CONF_7 0xfffe108c -#define OMAP850_IO_CONF_8 0xfffe1090 -#define OMAP850_IO_CONF_9 0xfffe1094 -#define OMAP850_IO_CONF_10 0xfffe1098 -#define OMAP850_IO_CONF_11 0xfffe109c -#define OMAP850_IO_CONF_12 0xfffe10a0 -#define OMAP850_IO_CONF_13 0xfffe10a4 - -#define OMAP850_MODE_1 0xfffe1010 -#define OMAP850_MODE_2 0xfffe1014 - -/* CSMI specials: in terms of base + offset */ -#define OMAP850_MODE2_OFFSET 0x14 - -/* - * ---------------------------------------------------------------------------- - * OMAP850 traffic controller configuration registers - * ---------------------------------------------------------------------------- - */ -#define OMAP850_FLASH_CFG_0 0xfffecc10 -#define OMAP850_FLASH_ACFG_0 0xfffecc50 -#define OMAP850_FLASH_CFG_1 0xfffecc14 -#define OMAP850_FLASH_ACFG_1 0xfffecc54 - -/* - * ---------------------------------------------------------------------------- - * OMAP850 DSP control registers - * ---------------------------------------------------------------------------- - */ -#define OMAP850_ICR_BASE 0xfffbb800 -#define OMAP850_DSP_M_CTL 0xfffbb804 -#define OMAP850_DSP_MMU_BASE 0xfffed200 - -/* - * ---------------------------------------------------------------------------- - * OMAP850 PCC_UPLD configuration registers - * ---------------------------------------------------------------------------- - */ -#define OMAP850_PCC_UPLD_CTRL_BASE (0xfffe0900) -#define OMAP850_PCC_UPLD_CTRL (OMAP850_PCC_UPLD_CTRL_BASE + 0x00) - -#endif /* __ASM_ARCH_OMAP850_H */ - -- 1.7.4.1 |
|
From: Henk M. <h.h...@gm...> - 2010-10-26 19:30:59
|
OK, I tried it on a Qtek S200 "prophet" Regards, Henk On 10/16/2010 09:12 PM, Alistair Buxton wrote: > Hi, > > Thanks to everyone who came to our sprint and tested things. We got a > basic kernel booting on several platforms. > > After looking at the results I started to look at the LCD detection > code. I would like to ask everyone to run this test and send me the > results. > > I need testers with any omap7xx phone. You only need to run a haret > script and mail me the output, no kernel boot in necessary. The test > scripts are here: > > http://al.robotfuzz.com/~al/htc/lcd1.zip > > You need a modified version of haret which is included. Unpack the zip > to the phone's internal memory and run haret. Press the "boot" button > like normal. It won't boot linux, it will run the tests instead. Your > screen will flicker during the test, it is normal. It will generate > lcdlog.txt. Mail that file to me or the list, along with any > information you have about your phone. Especially if you have an > after-market LCD, or you know what model of LCD you have for another > reason. > > The test works by rapidly switching between LCD mode and GPIO mode on > the LCD controller pins, to check which pins are tied high, low, or > are floating. It does this 30 or so times. Any pin that changes value > is deemed floating. The others are tied high or low (1 or 0). Ignoring > floating pins (zero them) and you get a code which identifies the > panel type of the phone. > > More about the LCD detection, including device database and log > processor: https://sourceforge.net/apps/trac/linwizard/wiki/LCDDetect > > Thanks > |
|
From: Christopher F. <chr...@gm...> - 2010-10-17 00:50:10
|
Please don't keep me in suspense - where can I check out the latest kernel sources? What version are they based on? Incidentally, what the heck is up with Android anyway? The last thing I've read says that it's not even in staging anymore as of '33 - is anyone doing the dirty work of keeping Android specific kernel code up to date? C |
|
From: Wayne G. <ju...@gm...> - 2010-10-16 21:25:21
|
I have a few different wizards (4 or 5 8125s and I think a qtek 9100) and a tmobile wing that I could do this testing with at some point today... glad to see there's still activity on this project! On Oct 16, 2010 2:16 PM, "Christopher Friedt" <chr...@gm...> wrote: > Tada! ... it's identified as the wizard too. > > Cheers, > > C > > On Sat, Oct 16, 2010 at 4:57 PM, Alistair Buxton <a.j...@gm...> wrote: >> On 16 October 2010 21:51, Christopher Friedt <chr...@gm...> wrote: >>> I could test it out with a QTek 9100, although I believe that's >>> essentially the same thing as a Wizard - no idea whether the LCD >>> differs or not. >>> >>> Should I? >> >> Sure, even the wizard can have different display types. >> >> -- >> Alistair Buxton >> a.j...@gm... >> |
|
From: Christopher F. <chr...@gm...> - 2010-10-16 21:19:02
|
And the output of readlcdlog.py On Sat, Oct 16, 2010 at 5:15 PM, Christopher Friedt <chr...@gm...> wrote: > Tada! ... it's identified as the wizard too. > > Cheers, > > C > > On Sat, Oct 16, 2010 at 4:57 PM, Alistair Buxton <a.j...@gm...> wrote: >> On 16 October 2010 21:51, Christopher Friedt <chr...@gm...> wrote: >>> I could test it out with a QTek 9100, although I believe that's >>> essentially the same thing as a Wizard - no idea whether the LCD >>> differs or not. >>> >>> Should I? >> >> Sure, even the wizard can have different display types. >> >> -- >> Alistair Buxton >> a.j...@gm... >> > |
|
From: Christopher F. <chr...@gm...> - 2010-10-16 21:16:10
|
Tada! ... it's identified as the wizard too. Cheers, C On Sat, Oct 16, 2010 at 4:57 PM, Alistair Buxton <a.j...@gm...> wrote: > On 16 October 2010 21:51, Christopher Friedt <chr...@gm...> wrote: >> I could test it out with a QTek 9100, although I believe that's >> essentially the same thing as a Wizard - no idea whether the LCD >> differs or not. >> >> Should I? > > Sure, even the wizard can have different display types. > > -- > Alistair Buxton > a.j...@gm... > |
|
From: Alistair B. <a.j...@gm...> - 2010-10-16 20:57:58
|
On 16 October 2010 21:51, Christopher Friedt <chr...@gm...> wrote: > I could test it out with a QTek 9100, although I believe that's > essentially the same thing as a Wizard - no idea whether the LCD > differs or not. > > Should I? Sure, even the wizard can have different display types. -- Alistair Buxton a.j...@gm... |
|
From: Christopher F. <chr...@gm...> - 2010-10-16 20:52:17
|
I could test it out with a QTek 9100, although I believe that's essentially the same thing as a Wizard - no idea whether the LCD differs or not. Should I? On Sat, Oct 16, 2010 at 3:12 PM, Alistair Buxton <a.j...@gm...> wrote: > Hi, > > Thanks to everyone who came to our sprint and tested things. We got a > basic kernel booting on several platforms. > > After looking at the results I started to look at the LCD detection > code. I would like to ask everyone to run this test and send me the > results. > > I need testers with any omap7xx phone. You only need to run a haret > script and mail me the output, no kernel boot in necessary. The test > scripts are here: > > http://al.robotfuzz.com/~al/htc/lcd1.zip > > You need a modified version of haret which is included. Unpack the zip > to the phone's internal memory and run haret. Press the "boot" button > like normal. It won't boot linux, it will run the tests instead. Your > screen will flicker during the test, it is normal. It will generate > lcdlog.txt. Mail that file to me or the list, along with any > information you have about your phone. Especially if you have an > after-market LCD, or you know what model of LCD you have for another > reason. > > The test works by rapidly switching between LCD mode and GPIO mode on > the LCD controller pins, to check which pins are tied high, low, or > are floating. It does this 30 or so times. Any pin that changes value > is deemed floating. The others are tied high or low (1 or 0). Ignoring > floating pins (zero them) and you get a code which identifies the > panel type of the phone. > > More about the LCD detection, including device database and log > processor: https://sourceforge.net/apps/trac/linwizard/wiki/LCDDetect > > Thanks > > -- > Alistair Buxton > a.j...@gm... > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > Linwizard-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linwizard-devel > |
|
From: Angelo A. <mi...@gm...> - 2010-10-16 19:39:13
|
Great Job! - Angelo ------------------------------------------------------------------ HaRET(2)# print "Machine: %s" MACHNAME Machine: Wizard HaRET(3)# print "OEM: %s" MACHOEM OEM: WIZA200 HaRET(4)# pdump 0xfffe1080 0x04 fffe1080 | 88000000 | .... HaRET(5)# pdump 0xfffe1800 0x10 fffe1800 | 00000000 00000000 00000000 00000000 | ................ HaRET(6)# pdump 0xfffe2000 0x10 fffe2000 | 03320500 1b62c02f 00010000 00000000 | ..2./.b......... HaRET(7)# pdump 0xfffec000 0x20 fffec000 | f8000089 130924ef 0202093f fe700010 | .....$..?.....p. fffec010 | ffffffd2 5c00f000 fffffc00 fffffcff | .......\........ HaRET(8)# pdump 0xfffed400 0x10 fffed400 | 03320500 1b62c02f 00010000 00000000 | ..2./.b......... HaRET(9)# pdump 0xfffee300 0x100 fffee300 | 00000000 00000000 00000000 00000000 | ................ fffee310 | 00000000 00000000 00000000 00000000 | ................ fffee320 | 00000000 00000000 00000000 00000000 | ................ fffee330 | 00000000 00000000 00000000 00000000 | ................ fffee340 | 00000000 00000000 00000000 00000000 | ................ fffee350 | 00000000 00000000 00000000 00000000 | ................ fffee360 | 00000000 00000000 00000000 00000000 | ................ fffee370 | 00000000 00000000 00000000 00000000 | ................ fffee380 | 00000000 00000000 00000000 00000000 | ................ fffee390 | 00000000 00000000 00000000 00000000 | ................ fffee3a0 | 00000000 00000000 00000000 00000000 | ................ fffee3b0 | 00000000 00000000 00000000 00000000 | ................ fffee3c0 | 00000000 00000040 00001000 0000681e | ....@........h.. fffee3d0 | 00000000 00000000 00000000 00000000 | ................ fffee3e0 | 00000000 00000000 00000000 00000000 | ................ fffee3f0 | 00000000 00000000 00005390 00000000 | .........S...... HaRET(10)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | 40400fe4 | ..@@ HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | 6040afe4 | ..@` HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7afe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | e9c7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | 7040ffe4 | ..@p HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ed43ffe4 | ..C. HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | efc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | efc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | efc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | e9c77fe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | 7040afe4 | ..@p HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7afe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc77fe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7afe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | efc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | e244ffe4 | ..D. HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | 6040afe4 | ..@` HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | 5040ffe4 | ..@P HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | e9c77fe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7afe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | efc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | efc7ffe4 | .... HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | e040ffe4 | ..@. HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | f040ffe4 | ..@. HaRET(13)# unlog HaRET(12)# pdump 0xfffbc800 0x04 fffbc800 | ffc7ffe4 | .... HaRET(13)# unlog HaRET(54)# print "End of log" End of log HaRET(55)# unlog |
|
From: Alistair B. <a.j...@gm...> - 2010-10-16 19:12:38
|
Hi, Thanks to everyone who came to our sprint and tested things. We got a basic kernel booting on several platforms. After looking at the results I started to look at the LCD detection code. I would like to ask everyone to run this test and send me the results. I need testers with any omap7xx phone. You only need to run a haret script and mail me the output, no kernel boot in necessary. The test scripts are here: http://al.robotfuzz.com/~al/htc/lcd1.zip You need a modified version of haret which is included. Unpack the zip to the phone's internal memory and run haret. Press the "boot" button like normal. It won't boot linux, it will run the tests instead. Your screen will flicker during the test, it is normal. It will generate lcdlog.txt. Mail that file to me or the list, along with any information you have about your phone. Especially if you have an after-market LCD, or you know what model of LCD you have for another reason. The test works by rapidly switching between LCD mode and GPIO mode on the LCD controller pins, to check which pins are tied high, low, or are floating. It does this 30 or so times. Any pin that changes value is deemed floating. The others are tied high or low (1 or 0). Ignoring floating pins (zero them) and you get a code which identifies the panel type of the phone. More about the LCD detection, including device database and log processor: https://sourceforge.net/apps/trac/linwizard/wiki/LCDDetect Thanks -- Alistair Buxton a.j...@gm... |
|
From: Cory M. <dar...@gm...> - 2010-07-21 20:46:09
|
On Wed, Jul 21, 2010 at 10:02 AM, Angelo Arrifano <mi...@gm...> wrote: > On 21-07-2010 18:49, Alistair Buxton wrote: >> On 19 July 2010 05:12, Cory Maccarrone <dar...@gm...> wrote: >>> On Sun, Jul 18, 2010 at 11:43 AM, Christopher Friedt >>> <chr...@gm...> wrote: >>>> Hi Cory, >>>> >>>> On Sun, Jul 18, 2010 at 3:24 AM, Cory Maccarrone <dar...@gm...> wrote: >>>>>> Now that the mainline kernel has a lot of omap850 support >>>> >>>> I'm very interested, but am submitting my msc thesis right around that >>>> time (now until then is crunch time), so I'm unfortunately out. >>>> >>>> Incidentally, what _is_ new in terms of omap850 support? I haven't >>>> really been keeping up, but it would be nice to have an overview. >>>> >>>> Cheers, >>>> >>>> Chris >>>> >> >> Don't worry, there is still plenty of work to do beyond what we can do >> in one session :) >> >> How about we set for Saturday 31st July at about 9pm-12pm UTC/2pm - 5pm PDT? > ------------- > sounds good > - Angelo >> Should work for me as well. - Cory |
|
From: Angelo A. <mi...@gm...> - 2010-07-21 17:02:53
|
On 21-07-2010 18:49, Alistair Buxton wrote:
> On 19 July 2010 05:12, Cory Maccarrone <dar...@gm...> wrote:
>> On Sun, Jul 18, 2010 at 11:43 AM, Christopher Friedt
>> <chr...@gm...> wrote:
>>> Hi Cory,
>>>
>>> On Sun, Jul 18, 2010 at 3:24 AM, Cory Maccarrone <dar...@gm...> wrote:
>>>>> Now that the mainline kernel has a lot of omap850 support
>>>
>>> I'm very interested, but am submitting my msc thesis right around that
>>> time (now until then is crunch time), so I'm unfortunately out.
>>>
>>> Incidentally, what _is_ new in terms of omap850 support? I haven't
>>> really been keeping up, but it would be nice to have an overview.
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>
> Don't worry, there is still plenty of work to do beyond what we can do
> in one session :)
>
> How about we set for Saturday 31st July at about 9pm-12pm UTC/2pm - 5pm PDT?
-------------
sounds good
- Angelo
>
|
|
From: Alistair B. <a.j...@gm...> - 2010-07-21 16:49:14
|
On 19 July 2010 05:12, Cory Maccarrone <dar...@gm...> wrote: > On Sun, Jul 18, 2010 at 11:43 AM, Christopher Friedt > <chr...@gm...> wrote: >> Hi Cory, >> >> On Sun, Jul 18, 2010 at 3:24 AM, Cory Maccarrone <dar...@gm...> wrote: >>>> Now that the mainline kernel has a lot of omap850 support >> >> I'm very interested, but am submitting my msc thesis right around that >> time (now until then is crunch time), so I'm unfortunately out. >> >> Incidentally, what _is_ new in terms of omap850 support? I haven't >> really been keeping up, but it would be nice to have an overview. >> >> Cheers, >> >> Chris >> Don't worry, there is still plenty of work to do beyond what we can do in one session :) How about we set for Saturday 31st July at about 9pm-12pm UTC/2pm - 5pm PDT? -- Alistair Buxton a.j...@gm... |
|
From: Cory M. <dar...@gm...> - 2010-07-19 04:12:53
|
On Sun, Jul 18, 2010 at 11:43 AM, Christopher Friedt <chr...@gm...> wrote: > Hi Cory, > > On Sun, Jul 18, 2010 at 3:24 AM, Cory Maccarrone <dar...@gm...> wrote: >>> Now that the mainline kernel has a lot of omap850 support > > I'm very interested, but am submitting my msc thesis right around that > time (now until then is crunch time), so I'm unfortunately out. > > Incidentally, what _is_ new in terms of omap850 support? I haven't > really been keeping up, but it would be nice to have an overview. > > Cheers, > > Chris > Adding back the linwizard list. As for what's new, at least on our 2.6.25 tree we've gotten a dozen or so devices booting and working pretty well, with a lot of hardware working. Upstream-wise, we've got almost all of our drivers ported for the HTC Herald (T-Mobile Wing) -- LCD, USB, MMC. All that works out-of-the-box on recent kernels. Bluetooth support as well as a few others (I2C, touchscreen) are submitted and need some revision still. - Cory |
|
From: Cory M. <dar...@gm...> - 2010-07-18 07:24:34
|
On Sat, Jul 17, 2010 at 6:39 PM, Alistair Buxton <a.j...@gm...> wrote: > Hi all, > > Now that the mainline kernel has a lot of omap850 support I think it > would be a good time to bring up to date all the board support files > we have for various devices. I would like to organise a kernel sprint > where we can all work on this together. I made a wiki page outlining > the idea and goals: > > http://sourceforge.net/apps/trac/linwizard/wiki/KernelSprint > > Who's interested? It could be 3-4 hours on one day, or we could make > it 1 hour per day over a few days. I guess the weekend is best for > most people. I'm thinking about 24th or 31st of July - next weekend or > the weekend after, so everyone hears about it and has a chance to > prepare. > > If you're interested then let me know what times you are available and > your timezone. > I'm in. Either of those two weekends works for me, as do most after that, mornings/afternoons only. I can't do evenings (and I'm in Seattle, so PDT here). - Cory |
|
From: Angelo A. <mi...@gm...> - 2010-07-18 00:58:21
|
On 18-07-2010 02:39, Alistair Buxton wrote: > Hi all, > > Now that the mainline kernel has a lot of omap850 support I think it > would be a good time to bring up to date all the board support files > we have for various devices. I would like to organise a kernel sprint > where we can all work on this together. I made a wiki page outlining > the idea and goals: > > http://sourceforge.net/apps/trac/linwizard/wiki/KernelSprint > > Who's interested? It could be 3-4 hours on one day, or we could make > it 1 hour per day over a few days. I guess the weekend is best for > most people. I'm thinking about 24th or 31st of July - next weekend or > the weekend after, so everyone hears about it and has a chance to > prepare. > > If you're interested then let me know what times you are available and > your timezone. > +1 I'll be available a few days between 10PM and 2 AM until 10 August. GMT here. Regards, Angelo |
|
From: Alistair B. <a.j...@gm...> - 2010-07-18 00:39:59
|
Hi all, Now that the mainline kernel has a lot of omap850 support I think it would be a good time to bring up to date all the board support files we have for various devices. I would like to organise a kernel sprint where we can all work on this together. I made a wiki page outlining the idea and goals: http://sourceforge.net/apps/trac/linwizard/wiki/KernelSprint Who's interested? It could be 3-4 hours on one day, or we could make it 1 hour per day over a few days. I guess the weekend is best for most people. I'm thinking about 24th or 31st of July - next weekend or the weekend after, so everyone hears about it and has a chance to prepare. If you're interested then let me know what times you are available and your timezone. -- Alistair Buxton a.j...@gm... |
|
From: Christopher F. <chr...@gm...> - 2010-03-31 13:54:50
|
On Wed, Mar 31, 2010 at 2:17 PM, Angelo Arrifano <mi...@gm...> wrote: > AFAIK 32k is mostly important for suspend. Wasn't the 32k also necessary for dynamic ticks? I can't remember exactly ... I just finished 2 of my last 3 exams (phew!) and should finally have a bit of time to hack at the linwizard kernel a bit more. I remember working on one thing in particular (a few months ago, can't remember right now) that was available on omap2, and theoretically also on omap1, but it relied on the 32k clock, and I couldn't get it to work properly before. It should be interesting to get back into my kernel tree and see if these patches fix my problem (whatever it was...). |
|
From: Angelo A. <mi...@gm...> - 2010-03-31 12:18:50
|
On 31-03-2010 14:13, Christopher Friedt wrote: > Hmm... very cool - were these the same ones that came up on linux-omap? Yes, these came straight from linux-omap. > > I don't have may kernel sources in front of me at the moment. Could > you remind me of the hardware / kernel components that are enabled > with the 32-k timer? AFAIK 32k is mostly important for suspend. > > On Wed, Mar 31, 2010 at 1:58 PM, Angelo Arrifano <mi...@gm...> wrote: >> Hello team, >> >> I spotted some omap1 patches for the 32k clock that might be our >> interest. They are attached. >> >> Regards, >> - Angelo >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Linwizard-devel mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linwizard-devel >> >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Linwizard-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linwizard-devel |
|
From: Christopher F. <chr...@gm...> - 2010-03-31 12:15:32
|
Hmm... very cool - were these the same ones that came up on linux-omap? I don't have may kernel sources in front of me at the moment. Could you remind me of the hardware / kernel components that are enabled with the 32-k timer? On Wed, Mar 31, 2010 at 1:58 PM, Angelo Arrifano <mi...@gm...> wrote: > Hello team, > > I spotted some omap1 patches for the 32k clock that might be our > interest. They are attached. > > Regards, > - Angelo > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Linwizard-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linwizard-devel > > |
|
From: Angelo A. <mi...@gm...> - 2010-03-31 11:59:14
|
Hello team, I spotted some omap1 patches for the 32k clock that might be our interest. They are attached. Regards, - Angelo |
|
From: Angelo A. <mi...@gm...> - 2010-03-07 00:58:33
|
-------- Forwarded Message -------- > From: Angelo Arrifano <mi...@gm...> > To: Tony Lindgren <to...@at...> > Cc: Shilimkar, Santosh <san...@ti...>, ben...@fl... > <ben...@fl...>, lin...@vg... > <lin...@vg...>, lin...@vg... > <lin...@vg...>, Syed, Rafiuddin <raf...@ti...>, > Cory Maccarrone <dar...@gm...>, ak...@li... > <ak...@li...>, lin...@so... > Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform > Date: Sun, 07 Mar 2010 01:47:28 +0100 > > On Ter, 2010-03-02 at 14:54 -0800, Tony Lindgren wrote: > > * Shilimkar, Santosh <san...@ti...> [100227 21:28]: > > > > -----Original Message----- > > > > From: Tony Lindgren [mailto:to...@at...] > > > > Sent: Sunday, February 28, 2010 2:11 AM > > > > To: Shilimkar, Santosh > > > > Cc: ben...@fl...; lin...@vg...; lin...@vg...; Syed, Rafiuddin; Cory > > > > Maccarrone; ak...@li... > > > > Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform > > > > > > > > * Shilimkar, Santosh <san...@ti...> [100226 20:05]: > > > > > Tony, > > > > > What we do with patch now? It's more almost 6 months that this patch is > > > > > floating without merge. > > > > > > > > Well first we should test it for all omaps. So let's add it into > > > > omap-testing for a few days to make sure it does not break anything. > > > > > > > > Then let's ask Ben to queue it. > > > > > > > Ok with me. > > > > I've tried it out and seems to work just fine on 2420. I've applied > > it for testing into omap-testing (and master) branches now. > > > > Would be nice to get an ack from people using 7xx too on this. > > > > Acked-by: Tony Lindgren <to...@at...> > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > > the body of a message to maj...@vg... > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > I just tested this on omap-testing with my HTC Wizard (omap850) using > board-htcherald with little modifications. > - I2C works as expected here. > > Acked-by: Angelo Arrifano <mi...@gm...> > Tested-by: Angelo Arrifano <mi...@gm...> > -- Angelo Arrifano AKA MiKNiX mi...@gm... http://www.arrifano.com MsC Student / Researcher Lab. I3S - CNRS/UNSA, France arr...@i3... http://www.i3s.unice.fr/~arrifano/ Gentoo Linux OMAP850/Embedded Official Developer http://www.gentoo.org/~miknix mi...@ge... Linwizard Project Leader/Developer mi...@us... PGP Pubkey 0x3D92BB0B |
|
From: Nisar M. <nka...@gm...> - 2009-08-14 11:02:38
|
Hi , I am trying to load the linwizard in my HTC wizard, using wing-linux package. After starting the haret linux load up and stuck at the following prompt saying unable to mount rootfs. I have the rootfs and other required files under \Storage Card\linux Please help me in fixing this. Selected: ROOT_DEVICE=/dev/ CMDLINE=debug quiet psplash=false loglevel=7 init=/sb in/init console=tty0 video=omapfb:accel fbcon=rotate: 3 gsm-wizard.noreset=1 gsm-wizard.noload=1.4 root=/de v/ initramfs: Loading /initrd.d/80-loopboot.sh module initramfs: Loading /initrd.d/85-blockboot.sh module booting from: /dev/ mount: Mounting /dev/ on /mnt failed: invalid argumen t Unable to mount rootfs device sh: can,t access tty; job control off / $ _ |
