00:14.43 | *** join/#htc-linux kri5 (n=kri5@cowdy.vlmc.org) |
00:26.37 | *** part/#htc-linux exception13 (n=exceptio@testdrive.kgts.ru) |
01:04.03 | *** join/#htc-linux Patrick_Bateman (n=swc@unaffiliated/swc666/x-4934821) |
01:07.28 | *** join/#htc-linux swc|666 (n=swc@unaffiliated/swc666/x-4934821) |
01:13.55 | *** join/#htc-linux zycho_ (n=zycho@dslb-088-070-254-107.pools.arcor-ip.net) |
01:19.24 | *** join/#htc-linux zycho (n=zycho@dslb-088-070-254-107.pools.arcor-ip.net) |
03:09.02 | *** join/#htc-linux mrmoku|e` (n=mrmoku@ppp-93-104-58-5.dynamic.mnet-online.de) |
03:09.49 | *** join/#htc-linux Moult (n=Moult@60.54.42.64) |
04:16.43 | *** join/#htc-linux exception13 (n=exceptio@testdrive.kgts.ru) |
04:25.57 | *** join/#htc-linux _RZK333 (n=rzk@daemonet.ru) |
05:33.08 | *** part/#htc-linux exception13 (n=exceptio@testdrive.kgts.ru) |
07:01.03 | *** join/#htc-linux |John_A| (n=John_A@79.107.5.75) |
07:05.49 | *** join/#htc-linux pigeon (n=pigeon@60-241-137-179.static.tpgi.com.au) |
07:10.10 | *** join/#htc-linux AIVAnet (n=John_A@79.107.5.75) [NETSPLIT VICTIM] |
07:10.10 | *** join/#htc-linux lordkiwi (n=root@h60088.upc-h.chello.nl) [NETSPLIT VICTIM] |
07:51.22 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
07:51.27 | *** join/#htc-linux MethoS (n=clemens@dyndsl-085-016-161-002.ewe-ip-backbone.de) |
08:15.29 | *** join/#htc-linux lordkiwi (n=root@h60088.upc-h.chello.nl) [NETSPLIT VICTIM] |
08:19.07 | *** join/#htc-linux SockPuppet (n=X@unaffiliated/egns) |
08:22.53 | *** join/#htc-linux _chab7_3 (n=kvirc@fibhost-67-206-132.fibernet.bacs-net.hu) |
08:58.39 | *** join/#htc-linux nebi_ (n=nebi@217.142.147.19) |
09:04.19 | *** join/#htc-linux Amynecka (n=bedrunec@hellmachine.klfree.cz) [NETSPLIT VICTIM] |
09:04.19 | *** join/#htc-linux madCoder- (n=madcoder@c-71-225-238-170.hsd1.pa.comcast.net) [NETSPLIT VICTIM] |
09:04.19 | *** join/#htc-linux methril|fix_part (n=Methril@213.27.233.98) |
09:04.19 | *** join/#htc-linux bodhiand (n=bodhi@89.121.200.106) [NETSPLIT VICTIM] |
09:45.28 | *** join/#htc-linux timebomb (n=tb@d084211.adsl.hansenet.de) |
10:43.06 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87c9db.pool.einsundeins.de) |
10:45.37 | *** join/#htc-linux fnord__ (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
10:59.34 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
11:24.21 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-81-17.web.vodafone.de) |
11:26.17 | cr2 | ~ping dcordes |
11:26.18 | apt | pong dcordes |
11:26.27 | dcordes | pong |
11:26.39 | cr2 | hi |
11:26.45 | dcordes | hi there |
11:27.19 | cr2 | htcraphael_angstrom_defconfig |
11:28.09 | cr2 | i'd like to document the nand partitions , and add nand support |
11:28.28 | cr2 | but the android people should keep away from it :) |
11:29.43 | dcordes | assuming they don't want some google account info where spl is supposed to be |
11:30.19 | cr2 | it needs to be clarified |
11:30.37 | cr2 | druidu said that only the wince partition is visible |
11:30.58 | cr2 | and the rest is shadowed by MPU |
11:31.23 | dcordes | what was it that provides the partition table to msm_nand ? |
11:31.29 | cr2 | but the SPL can access the wifi eeprom and other goodies documented in wiki |
11:32.52 | cr2 | btw, i've finally mounted my backup raid, so i'll look for the arm-related docs. where should i upload them |
11:33.55 | cr2 | http://www.htc-linux.org/wiki/index.php?title=MSM_NANDID |
11:34.03 | cr2 | http://wiki.xda-developers.com/index.php?pagename=MSM_NANDID |
11:34.31 | cr2 | hm. sorry |
11:34.33 | cr2 | http://www.htc-linux.org/wiki/index.php?title=RaphaelNAND |
11:34.44 | dcordes | ok |
11:35.14 | dcordes | I proposed to create a folder in htc-linux.org for docs |
11:35.34 | dcordes | we can then link in the wiki |
11:35.43 | cr2 | ok |
11:37.40 | cr2 | i suggest to create the 512K partition for the nand driver and mount it readonly. |
11:37.58 | cr2 | if it will be SPL, then http://www.htc-linux.org/wiki/index.php?title=RaphaelNAND |
11:38.49 | cr2 | if it will be some wince nk.exe, then it's something to think about. |
11:39.44 | cr2 | because that means that the wince disables access to the upper part at boot |
11:40.03 | cr2 | it is also necessary to check the |
11:40.06 | cr2 | <PROTECTED> |
11:40.42 | dcordes | which was the case on non-A right? we were talking about "shadowed" location for the whole non wince stuff |
11:40.50 | dcordes | s/location/section/ |
11:41.12 | cr2 | no, this table is from the A spl |
11:41.18 | cr2 | A=raph100 |
11:45.03 | tmzt | http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2009-April/000960.html |
11:45.17 | tmzt | can we get msm-ts support as a .config option? |
11:45.29 | tmzt | does the experimental driver work? |
11:47.12 | cr2 | tmzt: the non-android part ? |
11:48.07 | tmzt | yes |
11:48.25 | tmzt | the link is for a tslib input driver for debian |
11:48.57 | Moult | hey guys just wondering |
11:49.03 | tmzt | hello again |
11:49.11 | Moult | will android one day evolve into something you can install over windows mobile? |
11:49.14 | Moult | that'll replace it? |
11:49.20 | tmzt | possibly |
11:49.38 | Moult | eg one day google will say "hey download this file and run it on windows mobile and it'll get rid of WM and give you android" |
11:49.45 | tmzt | cr2, cmonex says it's possible to replace oemsbl |
11:50.06 | Moult | if so, i hope that day comes sooner than later. i cannot wait to scrap WM |
11:50.35 | cr2 | Moult: it's the goal, but we have not so much people and resources as googel ;) |
11:50.41 | tmzt | do you think the android bootloader could be used there? the one with source |
11:51.10 | Moult | cr2: well, either google or you guys come first, i don't mind either :) anything'll be better than WM |
11:51.12 | tmzt | and this nand locking thing looks interesting, I'm going to read that again |
11:51.16 | cr2 | tmzt: the oemsbl is even not in this flash list. i think you can reflash any part on NAND, once you will disable the MPU |
11:51.35 | tmzt | but it runs on arm9 also? |
11:51.41 | Moult | what's the progress so far with the OS you guys are doing? |
11:51.53 | tmzt | and the parts communicate/call functions? |
11:52.06 | tmzt | kernel?, Moult |
11:52.24 | Moult | tmzt: all you've got is a working kernel? |
11:52.43 | cr2 | tmzt: the android botloader is too limited in scope. uboot may have been better. |
11:53.23 | tmzt | but it already has msm/amss support? |
11:53.27 | Moult | what about X? have you got X working on it? |
11:53.38 | tmzt | we would have to add that to uboot? |
11:53.41 | cr2 | tmzt: oemsbl is mostly non-thumb code. |
11:53.47 | tmzt | Moult: what device? |
11:53.58 | Moult | try HTC Hermes? |
11:54.05 | tmzt | oh |
11:54.23 | cr2 | tmzt: i didn't check uboot source for a long time |
11:54.27 | tmzt | Xfbdev should work I think |
11:54.53 | cr2 | Moult: hermes does not have an SD driver, that's the problem. |
11:55.01 | tmzt | the linwizard people are updating gpe |
11:55.07 | tmzt | but yeah, no sd |
11:55.23 | Moult | cr2: but other than that it can succesfully have your Linux OS installed on it with X? |
11:55.29 | cr2 | you can run Xfbdev from initrd, but hermes has 64MB ram |
11:55.39 | Moult | and calls/sms/video calls/etc will work? |
11:55.53 | dcordes | tmzt, do you know if linwizard tried framework yet? |
11:55.54 | tmzt | calls maybe with fso |
11:56.02 | cr2 | Moult: somebody should check the hermes NAND with a more recent kernel |
11:56.23 | tmzt | dcordes: no, don't know |
11:56.26 | Moult | oh, so it's still all hacked together? |
11:56.30 | Moult | in order to get things to work? |
11:56.33 | tmzt | foes it have extrom? |
11:56.36 | cr2 | Moult: if NAND will work, it should be possible to flash linux in place of wince. |
11:56.37 | tmzt | does |
11:57.02 | tmzt | or somewhere that could be replaced without damaging ce install |
11:57.04 | Moult | cr2: you're referring to the method of replacing WM with Linux? |
11:57.18 | tmzt | maybe with raw yaffs2 on the mtd |
11:57.31 | cr2 | Moult: no, NAND is your only option for storage on hermes now. |
11:58.10 | Moult | i'm sorry, can you just explain the current extent to which linux is working for htc hermes? |
11:58.14 | dcordes | I have to go. will be back later |
11:58.16 | tmzt | hard reset could still recover it? |
11:58.41 | cr2 | tmzt: no. you need to boot int SPL and reflash the wince image |
11:59.08 | tmzt | I don't mean flash imgfs partition at all |
11:59.32 | tmzt | still boot with haret, install with usbnet/initrd |
11:59.50 | cr2 | Moult: you can boot and telnet to it over usb. the keyborad works with .25 kernel from linuxtogo. the TS work afair. the rest needs some testing and minor hacking. the SD and LCD resume do not work. |
11:59.50 | tmzt | mkyaffs2 on the tfat partition |
12:00.06 | Moult | cr2: TS? |
12:00.09 | tmzt | complete linux install |
12:00.12 | cr2 | touchscreen |
12:00.20 | tmzt | but you would not be able to boot |
12:00.40 | tmzt | cmonex suggest replacing parts of uldr with haret |
12:00.49 | tmzt | not sure what she meant exactly |
12:01.22 | cr2 | uldr=update loader. |
12:01.27 | Moult | cr2: is it not yet possible to install it such that it replaces WM? or only boot and telnet to it? |
12:01.34 | cr2 | haret is wince program. what's the purpose ?? |
12:01.40 | tmzt | not yet possible |
12:01.49 | cr2 | Moult: only telnet. |
12:02.00 | tmzt | to boot linux in place of wm without replacing spl |
12:02.12 | cr2 | tmzt: uldr ~ zImage |
12:02.19 | Moult | is there another bootloader then that can replace spl? |
12:02.25 | cr2 | tmzt: ok, you mean booting from spl ? |
12:02.44 | Moult | cr2: what about X, does it have a aGUI yet? |
12:02.50 | tmzt | so the ce drivers for the ftl can be used |
12:03.16 | tmzt | X won't fit very well in the initrd that takes up ram that it needs to run |
12:03.19 | cr2 | tmzt: then it's easier to create an SD image for the older devices, or wrap the zimage+tags into .nbh |
12:03.29 | tmzt | yeah |
12:03.33 | tmzt | tags? |
12:03.52 | Moult | well, a bit useless a phone that doesn't have a GUI :P |
12:03.52 | tmzt | we need a small bootloader to setup r0/r1 etc. |
12:04.04 | cr2 | ah, you want to reuse the wince driver ? |
12:04.11 | tmzt | but openezx apprently has one that prepends zImage |
12:04.49 | tmzt | cmonex said we could replace the uldr execuatble in a small bootable ce image with haret |
12:05.01 | cr2 | tmzt: openezx is a completely different beast. it has a working bootloader with source |
12:05.12 | tmzt | what did you mean by uldr ~ zImage |
12:05.16 | cr2 | at least on a780 |
12:06.30 | tmzt | I know, but this is something WyrM I think to prepend a zImage and set the mtype |
12:06.30 | cr2 | tmzt: zimage in place of the uldr may be nice. |
12:06.30 | tmzt | s/M I/M made I/ |
12:06.32 | mickeyl | isn't there something like a lowlevel init when booting wm? I'd just hook there and leave flash alone forever |
12:06.40 | tmzt | slow |
12:06.44 | cr2 | ok, i didn't check openezx for a long time, because the only thing i'd like to check there is GPS |
12:07.23 | tmzt | gne-blob is getting nice for a bootloader that can flash the phones |
12:07.32 | cr2 | mickeyl: on hermes you can't use SD for boot. making NAND work is an easier option. |
12:07.43 | mickeyl | oh that sucks |
12:07.52 | tmzt | we were talking about something like this for the motoq, since I have a spare one now |
12:07.57 | mickeyl | i agree, for hermes it makes sense then |
12:08.00 | mickeyl | not for any other devices imo |
12:08.22 | *** join/#htc-linux tsdogs (n=tsdogs@195.32.70.17) |
12:08.25 | tmzt | and the other asic3-mmc ones |
12:08.28 | tmzt | maybe |
12:08.47 | cr2 | yes, if you have working SD then SD is a better option. |
12:09.15 | cr2 | tmzt: is there an asic3-mmc for the recent (sdio) kernels ? |
12:09.23 | mickeyl | it's likely faster, it has more space, and it always leaves you with a working system, for several definitions of "working" ;) |
12:09.54 | tmzt | cr2: don't know, I believe there was work on adapting tmio |
12:09.59 | cr2 | tmzt: ATI SD != asic3-mmc, but it should be relatively easy to modify asic3-mmc into atiw288x-sd |
12:10.14 | cr2 | tmzt: it's all 2+ years old. |
12:11.12 | cr2 | mickeyl: using NAND saves mA's :) |
12:11.38 | *** join/#htc-linux timebomb (n=tb@d027099.adsl.hansenet.de) |
12:11.49 | tmzt | the wm use of partition tables seems satble |
12:12.03 | mickeyl | cr2: ya, that might be the only advantage for nand |
12:12.20 | tmzt | it might make sense to look at a way to package the partition table as ATAG or otherwise from haret |
12:12.50 | tmzt | cr2: do you know what ftl is used on msm devices in ce? |
12:13.16 | tmzt | no2chem and cmonex didn't but suggested it wasn't trueffs |
12:14.33 | cr2 | tmzt: trueffs was mdoc-only |
12:15.18 | cr2 | tmzt: do they uses any ftl at all ? |
12:15.56 | tmzt | don't know |
12:16.08 | tmzt | I see a filter driver in the registry |
12:16.33 | tmzt | not sure what it does |
12:16.54 | cr2 | tmzt: sometimes they use ndis for a serial port or IR, but it's still an uart |
12:17.01 | tmzt | do you think reading partition table with haret makes sense? |
12:17.14 | cr2 | tmzt: how ? |
12:18.03 | cr2 | tmzt: adding the rawio call from itsutils as haret command will be a nice patch :) |
12:18.24 | tmzt | yeah |
12:18.41 | cr2 | and the fm radio control too. |
12:19.00 | tmzt | no2chem is working on that also |
12:19.07 | tmzt | but what do you mean |
12:19.16 | cr2 | tmzt: will he add it to haret ? |
12:19.17 | tmzt | oh, in haret |
12:19.37 | tmzt | he's trying to use diamond rom which has it |
12:19.57 | cr2 | the fm xda-dev guy posted the C api on my request |
12:20.04 | tmzt | he reports rssi of 240-255 |
12:20.24 | cr2 | ok |
12:20.55 | cr2 | btw, i'd like to know which extusb pin is used for the antenna. |
12:21.02 | cr2 | on raph et al. |
12:21.34 | tmzt | there must be a connection in the adapter to headphone jack |
12:21.53 | tmzt | mine is not here and no meter either |
12:22.05 | cr2 | it may be some tv/uart1 pin |
12:22.51 | cr2 | damn, i need to buy the docking station and tvout cable ;) |
12:23.40 | tmzt | neutv is supposed to attempt to enable tvout without detecting |
12:23.44 | tmzt | nue |
12:23.50 | tmzt | check his weblog |
12:23.58 | cr2 | link ? |
12:24.21 | tmzt | nuerom site |
12:24.45 | cr2 | the tvout encoder is documented in wiki. we only need to find out the right MDP setup |
12:25.05 | tmzt | that's what I was wondering |
12:25.17 | tmzt | we need a mddi dumper in haret too |
12:25.57 | tmzt | if this enables the encoder then the settings can be dumped |
12:26.04 | tmzt | find the site? |
12:26.55 | cr2 | yes |
12:27.34 | cr2 | DMOV is the DMA engine, not really the arm9-arm11 communication |
12:28.00 | cr2 | all "opcodes" are located in the *.bts files |
12:28.25 | cr2 | you can push them with hciattach -S *.bts texas |
12:29.07 | cr2 | or even with the hcitool. if you are hardcore and use the decompiled .bts contents. |
12:30.34 | cr2 | DMOV is used for the uart2DM here (uart_hs_) |
12:30.41 | tmzt | yes |
12:30.56 | cr2 | but to control the FM radio 115200 will be enough ;) |
12:30.57 | tmzt | so bts programs dma not the bt chip? |
12:31.14 | cr2 | you need dma for > 115200 |
12:31.31 | tmzt | that -S is in upstream bluez 3.x right? |
12:31.31 | cr2 | bts programms the chip |
12:31.37 | cr2 | yes |
12:31.41 | tmzt | so it would be on g1? |
12:31.44 | cr2 | but you need to talk to the chip |
12:31.45 | tmzt | cool |
12:32.06 | cr2 | if they soldered the pins, yes. |
12:32.15 | tmzt | can you explain the opcodes in .bts then |
12:32.23 | tmzt | I'm confused |
12:32.31 | cr2 | wait. |
12:32.50 | tmzt | I mean the -S option not fm |
12:32.55 | tmzt | on g1 |
12:33.31 | cr2 | check hx4700 |
12:33.52 | cr2 | FMInit_2.bts |
12:34.33 | cr2 | hmm. where is my bts decompiler... |
12:36.03 | cr2 | # Description : BRF6350 2.0 FW 2.34 FM Initialization |
12:36.21 | cr2 | # Compatibility: BRF6350 2.0 ROM w/ 2.0.34 Firmware |
12:36.49 | cr2 | # FM ON |
12:36.51 | cr2 | SEND_COMMAND: ogf=0x3f ocf=0x137 1 -> |
12:36.52 | cr2 | ACTION_SEND_COMMAND: 0x01 0x37 0xfd 0x01 0x01 |
12:36.54 | cr2 | ... |
12:37.02 | *** join/#htc-linux utter0182 (n=dk@8afbf8ee.jrs.st-andrews.ac.uk) |
12:37.03 | tmzt | is FMInit-2.bts somewhere? |
12:37.11 | cr2 | SEND_COMMAND: ogf=0x3f ocf=0x135 9 -> |
12:37.13 | cr2 | ACTION_SEND_COMMAND: 0x01 0x35 0xfd 0x09 0x65 0x06 0x00 0x00 0xde 0x06 0x16 0x01 0xf4 |
12:37.14 | cr2 | and so on |
12:37.27 | cr2 | ls *.bts in \windows |
12:37.48 | tmzt | ogf? ocf? |
12:38.16 | cr2 | FMInit_2.bts |
12:38.26 | cr2 | it's BT terminology |
12:38.39 | cr2 | FM_on_2_0.bts |
12:38.53 | cr2 | FM_on_2_1.bts |
12:39.33 | cr2 | if no2chem will write fm support for haret, it'd be nice of course :) |
12:39.41 | tmzt | fm-on-2.0 |
12:39.44 | tmzt | yes |
12:40.51 | cr2 | the api is known, and if something is missing, one can always disassemble the app. |
12:40.57 | tmzt | so there's 2.0.x and 2.1.x firmware? |
12:41.46 | tmzt | the sizes are strange |
12:41.56 | tmzt | 2.0 and fm-on are many k |
12:42.11 | cr2 | we can't mmutrace dma |
12:42.14 | tmzt | 2.1 is a 300 bytes |
12:42.20 | tmzt | yeah |
12:42.44 | cr2 | at least not reliably |
12:43.24 | tmzt | but if there a static buffers you could watch the memory? |
12:43.30 | tmzt | dump dma regs |
12:43.43 | tmzt | or dmov setup |
12:43.50 | cr2 | trapping the HCI api should be easier. |
12:44.45 | cr2 | if we will have uart2 support in linux, we can try to send .bts at 115200. |
12:45.18 | cr2 | the spl picks the btaddr in this way. |
12:45.37 | cr2 | afair also the vendor-specific ogf/ocf pair |
12:47.09 | cr2 | Vendor-specific commands (OGF=0x3f): |
12:47.18 | cr2 | http://wiki.xda-developers.com/index.php?pagename=UniversalBluetooth |
12:47.27 | *** join/#htc-linux Kheops9871 (n=KoRoS@host-77-242-217-49.telecomitalia.sm) |
12:48.07 | cr2 | 0x137 is fm on, and the 0x135 are some parameters. |
12:48.52 | cr2 | fm on begins with |
12:48.56 | cr2 | # FM ON |
12:48.58 | cr2 | SEND_COMMAND: ogf=0x3f ocf=0x137 1 -> |
12:48.59 | cr2 | ACTION_SEND_COMMAND: 0x01 0x37 0xfd 0x01 0x01 |
12:49.06 | cr2 | and the rest are 0x135 commands. |
12:49.43 | tmzt | it would drop out of dm to send the fm commands? |
12:51.20 | cr2 | #Send_HCI_VS_I2C_FM_POWER_MODE 0xFD37, 1 |
12:51.22 | cr2 | #Wait_HCI_Command_Complete_VS_I2C_FM_POWER_MODE_Event 5000, any, HCI_VS_I2C_FM_POWER_MODE, 0x00 |
12:51.33 | cr2 | it's the 0x137 command |
12:51.58 | cr2 | the spl ? |
12:52.20 | tmzt | sorry? |
12:52.42 | cr2 | wince configures uart2DM for BT "7Mbit", and uses it. |
12:53.08 | tmzt | so this like tea or si chip with interface over i2c? |
12:53.28 | cr2 | internally |
12:53.39 | tmzt | individual registers have to be set? |
12:53.41 | cr2 | brf6150 had i2c support too. |
12:54.01 | cr2 | you talk .bts over BT, that's the "api" |
12:54.16 | tmzt | orhci? |
12:54.22 | cr2 | probably, but we don't have any docs. |
12:54.36 | tmzt | or hci |
12:54.38 | cr2 | .bts is sent with hci |
12:54.46 | tmzt | yeah |
12:54.51 | cr2 | so yes, hci commands. |
12:55.42 | cr2 | if we will track single FM* api calls, we may correlate it with hci commands. |
12:56.35 | tmzt | if we identify the i2c read/write commands |
12:56.56 | tmzt | there might already be a v4l or rockbox driver for a similar chip |
12:56.58 | cr2 | it's a more difficult task. |
12:57.12 | cr2 | because the i2c bus is behind the hci |
12:57.34 | cr2 | you can't talk i2c directly. |
12:57.53 | cr2 | otherwise it will have been trivial to trace. |
13:03.23 | tmzt | yes, I mean hci commands to read/write on the i2c bus |
13:04.10 | tmzt | power mode is gpio? |
13:05.04 | cr2 | brf has own gpios |
13:05.26 | cr2 | there was a brf6150 .pdf diagramm |
13:05.56 | cr2 | btw, you need AT@AUDIOSET=3 for FM |
13:06.10 | cr2 | i think (=3), need to check |
13:06.21 | tmzt | so it's handled by amss? |
13:06.40 | *** join/#htc-linux _XD (i=t3st1fy@ircop.com) |
13:06.50 | tmzt | I guerr only on ce amrr |
13:08.10 | cr2 | amss handles audio swithcng |
13:11.50 | *** join/#htc-linux StarLite (n=nnscript@s55916ca6.adsl.wanadoo.nl) |
13:11.52 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-81-17.web.vodafone.de) |
13:12.02 | cr2 | yes, =3 |
13:28.19 | *** join/#htc-linux zycho (n=zycho@88.70.254.107) |
13:58.49 | *** join/#htc-linux nebi_ (n=nebi@217.142.147.19) |
14:10.21 | *** join/#htc-linux j0b0 (n=jobo@5ED40048.cable.ziggo.nl) |
14:13.32 | *** join/#htc-linux j0b0 (n=jobo@5ED40048.cable.ziggo.nl) |
14:14.50 | *** join/#htc-linux Shinto (n=John@f048159062.adsl.alicedsl.de) |
14:22.02 | *** join/#htc-linux fnord__ (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
14:41.36 | *** join/#htc-linux j0b0 (n=jobo@5ED40048.cable.ziggo.nl) |
14:49.12 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
14:57.10 | cr2 | hehe |
14:57.35 | cr2 | 38400, 57600 and 115200 |
15:00.34 | dcordes | possible baudrates for hci communication? |
15:01.07 | *** join/#htc-linux Othello (i=Othello@gateway/tor/x-aa33d83e3569df28) |
15:02.37 | cr2 | the uart config |
15:03.17 | cr2 | i'm going through spl and writing comments. it's very helpful. |
15:03.54 | cr2 | the usb part is interesting. |
15:04.06 | dcordes | nice. do you think usb host is possible? |
15:04.26 | dcordes | that would allow for some zaurus kind of fun |
15:04.42 | cr2 | it is possible. |
15:04.51 | cr2 | but you need an adapter. |
15:05.02 | cr2 | also for the uart1 |
15:05.20 | cr2 | it's going to be a maze |
15:05.29 | dcordes | right. did you receive your cable yet? what is necessary driver wise in order to make usb host work? |
15:06.00 | cr2 | uart1, usb host, usb client, tvout, fm, headset... |
15:06.12 | cr2 | hmm. to write the usb host driver ;) |
15:07.08 | dcordes | do we have access to all information required in order to write the usb host driver? |
15:07.30 | cr2 | tmzt: what is RAPHCONF.TXT ? |
15:08.30 | cr2 | dcordes: no. g1 does not have host driver. only looking at the spl, it is possible to identify the registers that are used, and how they are used |
15:21.00 | tmzt | raphconf? |
15:21.34 | cr2 | yes. may be on the .nbh SD |
15:22.29 | tmzt | from where? |
15:23.00 | cr2 | read by spl |
15:31.30 | *** join/#htc-linux MethoS (n=clemens@host-091-097-241-235.ewe-ip-backbone.de) |
15:32.11 | cr2 | b1d*20 |
15:33.05 | cr2 | hm. pmdh |
15:49.30 | cr2 | one more 0x24MB offset |
15:53.42 | cr2 | 0xaa55fde9 ?? |
15:54.01 | cr2 | some fat signature ? |
15:56.43 | cr2 | hm. |
15:57.29 | cr2 | 0xe9fd header 0xaa55 at 0x200 offset |
15:57.55 | cr2 | tmzt: is it the imgfs layout ? |
16:00.56 | cr2 | yeah, looks like msfls50 .nb |
16:01.33 | cr2 | ok, but then |
16:01.36 | cr2 | 0x00420000 0x2400000 storage ? |
16:02.04 | cr2 | is the wince |
16:03.30 | cr2 | makes sense. but then you can blow away everything including spl ;) |
16:04.16 | cr2 | then only oemsbl is your friend. |
16:06.44 | cr2 | dcordes: now i really want to enable nand |
16:08.09 | cr2 | offset c for serial ? |
16:08.17 | tmzt | oh I see |
16:08.38 | tmzt | so that is for a bootable goldcard? |
16:09.23 | cr2 | +0x0c UART_TF |
16:09.38 | cr2 | tmzt: no, for NAND |
16:10.05 | tmzt | what does qmat or the mkimage from eol generate? |
16:10.30 | tmzt | I mean RAPHCPNF |
16:12.02 | cr2 | RAPHCONF.TXT ? it's from the .nbh SD card |
16:14.59 | cr2 | msm_write(port, xmit->buf[xmit->tail], UART_TF); |
16:15.14 | cr2 | ok, so it was uart_write() |
16:20.25 | cr2 | 92 #define UART_MREG 0x0028 |
16:20.27 | cr2 | 93 #define UART_NREG 0x002C |
16:20.28 | cr2 | 94 #define UART_DREG 0x0030 |
16:20.30 | cr2 | 95 #define UART_MNDREG 0x0034 |
16:21.48 | *** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes) |
16:23.27 | cr2 | this one goes to a separate channel |
16:24.17 | cr2 | dcordes: back ? |
16:24.34 | *** join/#htc-linux nebi_ (n=nebi@217.142.147.19) |
16:26.14 | cr2 | okey, so it's possible to find the 38400, 57600 magic numbers too. |
16:30.52 | cr2 | c0,b2,7d -> x9600 |
16:33.13 | cr2 | and 0x1c |
16:33.20 | cr2 | ok, this is common. |
16:33.24 | cr2 | 484 msm_write(port, 0xC0, UART_MREG); |
16:33.26 | cr2 | 485 msm_write(port, 0xB2, UART_NREG); |
16:33.27 | cr2 | 486 msm_write(port, 0x7D, UART_DREG); |
16:33.29 | cr2 | 487 msm_write(port, 0x1C, UART_MNDREG); |
16:34.25 | cr2 | dd, ff and ee |
16:36.10 | cr2 | into +8 |
16:36.57 | cr2 | 42 #define UART_CSR 0x0008 |
16:36.59 | cr2 | 43 #define UART_CSR_115200 0xFF |
16:37.00 | cr2 | 44 #define UART_CSR_57600 0xEE |
16:37.02 | cr2 | 45 #define UART_CSR_38400 0xDD |
16:37.21 | cr2 | ok. so the uart code will work. |
16:37.42 | cr2 | if we will enable the uart_clk divisor... |
16:40.19 | tmzt | have you tried 2.6.29 or is this just because g1 takes the rate not individual components? |
16:40.24 | tmzt | or |
16:42.10 | cr2 | the code is identical |
16:42.23 | cr2 | raph spl does not enable the uart clock. |
16:42.34 | cr2 | it seems that it relies on oemsbl here ;) |
16:43.32 | cr2 | or maybe the M,N,D and UART_MNDREG is enough |
16:43.48 | cr2 | still, g1 calls uart_clk enable |
16:47.00 | cr2 | tmzt: what is the raph nand size ? |
16:47.47 | cr2 | ROM capacity: 512 MB |
16:48.08 | cr2 | 16*16*2 |
16:48.34 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
16:49.13 | cr2 | 0x20000000 |
16:52.22 | cr2 | interesting. |
16:52.37 | cr2 | to enable the usb serial output, the vreg5 is reset. |
16:53.09 | cr2 | 0,msleep 0x7d0, 0xb22 |
16:56.18 | cr2 | =0, sleep 2, =2.85V |
17:07.07 | cr2 | gpio0 seems to be uart1 / h2w mux |
17:08.31 | cr2 | so if you don't touch the extusb pins, and gpio0=0, then you have uart1 on extusb tvout pins. |
17:19.43 | cr2 | there are several undocumented usb registers. |
17:35.39 | no2chem | hmm uart clock |
17:35.48 | no2chem | msm_regime stuff? |
17:37.02 | *** join/#htc-linux _XD (i=t3st1fy@ircop.com) |
17:37.15 | no2chem | i notice you don't have acpu_clk documented in raph research |
17:37.34 | no2chem | you should look at G1 code for that |
17:53.16 | cr2 | no2chem: it's not raph specific, so why bother |
17:54.19 | cr2 | i'm trying to document the undocumented things, and everything raph-specific |
17:56.50 | no2chem | oh |
17:56.52 | no2chem | right |
17:57.24 | no2chem | so you have clock control functionality in linux? |
17:57.59 | cr2 | partially |
17:58.23 | cr2 | you mean cpu clock, or all other clocks ? |
18:02.23 | no2chem | cpu clock |
18:02.35 | no2chem | .. theres also this DVFM thing ive been trying to figure out |
18:02.46 | no2chem | apparently they have it working on the G1 |
18:02.55 | no2chem | cpu clock = a11 clock |
18:03.28 | cr2 | ok |
18:03.48 | cr2 | i'm more worried about the peripheral clocks |
18:03.59 | no2chem | id understand why |
18:04.09 | no2chem | i guess you are still trying to get uart and stuff working |
18:04.17 | no2chem | stable, anyway |
18:04.41 | cr2 | yes. uart2DM and bluetooth actually |
18:04.51 | no2chem | ah |
18:05.01 | no2chem | ive been messing with bluetooth uart lately.. |
18:05.13 | cr2 | then you can do funny stuff like FM, RDS and TMC |
18:05.24 | no2chem | there is something weird about bluetooth on the raph800.. |
18:05.26 | no2chem | bluetooth uart |
18:05.38 | cr2 | why ? |
18:05.53 | no2chem | well, so the FM radio doesn't work on raph800 |
18:06.03 | no2chem | but it works on the diam500... which is almost the same hardware |
18:06.33 | no2chem | for whatever reason, in CE.... when the FM driver tries to talk to the bluetooth chip |
18:06.45 | cr2 | raph500 or diam500 ? |
18:06.47 | no2chem | sending the HCI opcodes fail |
18:06.50 | no2chem | RAPH800 |
18:07.01 | no2chem | it works on DIAM500 (CDMA diamond) |
18:07.12 | cr2 | ok |
18:07.17 | no2chem | maybe its a ce thing, but i used the same ROM image.. same problem |
18:07.34 | no2chem | see, on cdma touch diamond i get this crap |
18:07.34 | no2chem | 19:19:26 [D:BT] [BTU]SystemIdleTimerReset |
18:07.35 | no2chem | +sio_rs232_dm_transmit() |
18:07.35 | no2chem | sio_rs232_dm_transmit 1 |
18:07.35 | no2chem | [BTU]sio_rs232_dm_transmit():send 7 |
18:07.36 | no2chem | sio_rs232_dm_transmit 3 |
18:07.38 | no2chem | 19:19:26 [D:BT] [BTU]SystemIdleTimerReset |
18:07.40 | no2chem | 3.sio_rs232_dm_transmit():uart_dm_imr=0x9 |
18:07.42 | no2chem | +Tx call dmov_transfer |
18:07.44 | no2chem | -Tx call dmov_transfer |
18:07.50 | no2chem | that i don't get on the cdma touch pro |
18:07.52 | cr2 | different BT firmware ? |
18:08.03 | no2chem | same, id hope |
18:08.21 | cr2 | the same bts files ? |
18:08.24 | no2chem | yeah |
18:08.32 | no2chem | i made sure they were the same |
18:08.36 | cr2 | ok |
18:08.46 | no2chem | from what it looks like.. dmov_transfer or whatever was failing |
18:09.17 | no2chem | so im guessing all this uart is done through the a9 maybe?. |
18:09.18 | cr2 | different dma dev/channel ? weird |
18:09.27 | cr2 | no |
18:09.53 | no2chem | well |
18:09.55 | no2chem | actually |
18:10.03 | cr2 | you only tell arm9 at@setaudio=3 |
18:10.07 | no2chem | oh |
18:10.23 | no2chem | uart_dm has to be working though?.. because else the bt init scripts wouldn't have worked |
18:10.39 | cr2 | yes |
18:11.01 | no2chem | so maybe it is a different BRF6350 firmware |
18:11.16 | cr2 | maybe |
18:11.17 | no2chem | maybe i can query the firmware version over HCI |
18:11.24 | cr2 | yes |
18:11.45 | *** join/#htc-linux DJWillis (n=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) |
18:11.46 | no2chem | guess ill have to figure out the opcode |
18:12.08 | no2chem | do you know if its possible to update the BRF6350 firmware? maybe it lives in nand somewhere.. |
18:12.21 | cr2 | i think hciaatach texas always reports the fw version |
18:12.51 | cr2 | no, it lives in brf6350 |
18:13.05 | cr2 | but you can patch it through .bts |
18:13.28 | cr2 | don't ask me how to do it though :) |
18:13.30 | no2chem | oh. so assuming im running the same bts |
18:13.38 | no2chem | they should be functionally same yeah?.. |
18:13.57 | *** join/#htc-linux tsdogs (n=tsdogs@net203-187-146.mclink.it) |
18:14.29 | cr2 | the bts patches are for a certain fw version |
18:14.47 | no2chem | oh |
18:14.54 | cr2 | i don't know why htc should use a different version on raph800, but who knows |
18:15.05 | no2chem | well, the script on the shipped raph800 |
18:15.10 | no2chem | and the shipped diam500 |
18:15.15 | no2chem | both say firmware 2.11 |
18:15.20 | no2chem | so im guessing they are the same. |
18:15.22 | tmzt | nand on raph500? |
18:15.34 | tmzt | size |
18:15.47 | cr2 | tmzt: do you have working FM ? |
18:15.55 | tmzt | no |
18:16.02 | cr2 | ok |
18:16.05 | tmzt | haven't tried the cabs |
18:16.12 | no2chem | they don't work =p |
18:16.24 | tmzt | just reloaded everything again |
18:16.25 | no2chem | its a very strange problem, heh. |
18:16.45 | no2chem | maybe the hardware isn't there, but i dont believe that =p |
18:17.02 | tmzt | keyboard issue is still here but I think it's s2u2 |
18:17.17 | cr2 | no2chem: the dma should not fail |
18:17.19 | tmzt | tried on vzw? |
18:17.41 | tmzt | I'm thinking the pcm link could be different |
18:17.50 | tmzt | on cdma and gsms |
18:18.23 | cr2 | 0xB1300150 |
18:18.23 | no2chem | well, like i said, it works fine on cdma diamond |
18:18.29 | no2chem | and its not the pcm link |
18:18.34 | no2chem | that connects fine |
18:18.35 | tmzt | I have the fm on scripts |
18:18.45 | *** join/#htc-linux fnord__ (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
18:19.00 | tmzt | but if it's different it could be different firmware |
18:19.06 | tmzt | but probably not |
18:19.08 | cr2 | 0xB1300180 |
18:19.15 | no2chem | it really just seems like the fm on scipts aren't working... for whatever reason |
18:20.10 | cr2 | ok, so 2 usb registers are not documented in the g1 code. |
18:31.32 | cr2 | hm. orr800 and 0rr200 |
18:31.41 | cr2 | the same 0xa00 that we see |
18:32.16 | cr2 | & e00 |
18:32.34 | cr2 | 1110.0000.0000 |
18:32.50 | cr2 | 0010.0000.0000 |
18:33.00 | cr2 | 0100.0000.0000 |
18:33.27 | cr2 | ok, the top bit is cleaned too. |
18:34.51 | kiozen | hi cr2 |
18:34.56 | kiozen | did GT compile? |
18:34.56 | cr2 | hi kiozen |
18:35.15 | cr2 | svn up did not show any patches |
18:35.50 | kiozen | did you try to remove the build path and to rebiuild |
18:36.13 | cr2 | no. not on friday |
18:37.21 | dcordes | cr2, now I'm back |
18:37.21 | cr2 | kiozen: btw, even JOSM has routing plugin now :) |
18:37.55 | cr2 | dcordes: i think that SPL & things are exposed in NAND too |
18:38.16 | cr2 | dcordes: but i just need to build the kernel with nand support and check. |
18:38.44 | kiozen | cr2: don't care, I never use routing, but I answer every request, that I wait for someone to do it |
18:38.48 | cr2 | destroying spl sounds as a big fun |
18:39.19 | kiozen | still look for a good replacement for my zire 21 |
18:39.33 | cr2 | kiozen: ok. i'm more interested in enhancing the geofererencer. |
18:39.34 | kiozen | looks like all mobile phones are crap |
18:39.41 | cr2 | hehe |
18:40.04 | kiozen | it's hillarious that a thing stuffed with features can't do the most simple things |
18:40.18 | cr2 | 16/18bit color lcds like mA |
18:40.30 | kiozen | like a decent calendar, a good address list and long term standby |
18:40.37 | cr2 | blame m$ |
18:40.47 | kiozen | no it's not m$ |
18:40.49 | tsdogs | kiozen: maybe this is of some interest http://www.gedanken.org.uk/software/routino/ |
18:40.58 | kiozen | even nokia, blackberry suck |
18:41.06 | kiozen | hi tsdogs |
18:41.10 | tsdogs | hi btw |
18:41.20 | cr2 | tsdogs: why there are no turn restrictions there ?? |
18:41.25 | cr2 | hi tsdogs |
18:41.51 | kiozen | tsdogs: can you spend 15min to update translations? |
18:41.57 | kiozen | it's not much to do :) |
18:42.04 | tsdogs | kiozen: ok. |
18:42.35 | tsdogs | Just drop me an e-mail when you plan to release and I'll update :) |
18:42.58 | tsdogs | I mean next time :) |
18:43.17 | kiozen | just did a realease, but couldn't contact you, lost you mail and you wheren't in irc |
18:43.28 | tsdogs | ok |
18:44.13 | cr2 | tsdogs: i'll resubscribe to roadmap ML with a new e-mail |
18:44.34 | kiozen | the blackberry curve 8900 is quite nice if they would lock that thing to just "our service and outlook only" |
18:44.46 | tsdogs | cr2: good, actually only danny is working on it right now ... |
18:45.00 | cr2 | ok |
18:45.17 | cr2 | tsdogs: the routino is fun, because it's plain C :) |
18:45.36 | kiozen | that's mor of a problem ;) |
18:45.37 | cr2 | it's a pity there are no turn restrictions there. |
18:45.38 | tsdogs | yep |
18:46.00 | cr2 | kiozen: the xml parser is done even without expat :) |
18:47.13 | cr2 | tsdogs: i need to locate your polygon labeling patch, so we can submit it |
18:47.45 | tsdogs | cr2: it was a hack |
18:48.28 | tsdogs | Though I have no idea if it still applies to current roadmap |
18:48.34 | cr2 | tsdogs: but a really nice hack. at least the lakes finally had the names |
18:49.06 | tsdogs | that's true, but I dubt it can go in as it is... |
18:49.35 | cr2 | tsdogs: and i will probably port the postgres and grmn/shapefile buildmap code. |
18:49.37 | cr2 | ok |
18:50.02 | tsdogs | that'll be interesting |
18:50.45 | cr2 | althougth the .mp parser will be better. |
18:51.09 | cr2 | because preparing these shapefiles is PITA |
18:51.59 | cr2 | and you can just use osm2mp.pl to create .mp |
18:52.52 | cr2 | or i will modify the osm2mp.pl to create some ssplit-friendly output :) |
18:57.50 | tsdogs | kiozen: http://195.32.70.240/tsdogs/openupload/www/?a=d&i=RxAn8i |
18:59.22 | kiozen | tsdogs: fantastic, thanks :) |
19:00.50 | tsdogs | kiozen: did you get it in german? |
19:01.05 | kiozen | I have done myself |
19:01.19 | tsdogs | no I mean was the page in German ? |
19:01.23 | tsdogs | the web page |
19:01.37 | kiozen | no english |
19:01.51 | tsdogs | hmm, your preference is english? |
19:02.03 | tsdogs | in the browser... |
19:03.04 | dcordes | cr2, are you going to try nand? |
19:05.20 | tsdogs | bbl |
19:14.13 | *** join/#htc-linux swc|666 (n=swc@unaffiliated/swc666/x-4934821) |
19:15.02 | cr2 | dcordes: need to connect one more hdd where i have the linuxtogo source |
19:15.27 | cr2 | dcordes: i've checked the oemsbl, it sets the 0xa00 for uart_clk |
20:27.07 | *** join/#htc-linux Othello (i=Othello@gateway/tor/x-49c69d113707d15f) |
20:52.38 | *** join/#htc-linux wirelessdreamer (n=dreamer@chrobd01.vailsys.com) |
20:54.12 | wirelessdreamer | is power management working on raph with android or angstrom? |
21:54.38 | *** join/#htc-linux ellisway (n=ellis@149.254.216.4) |
22:24.23 | swc|666 | hopes this will be for sale soon http://www.exedamobile.com/web/index.php |
22:26.30 | cr2 | swc|666: what about the screen resolution ? |
22:26.36 | swc|666 | wow.. 2x8GB = add $19 |
22:26.37 | swc|666 | http://www.compulab.co.il/exeda/html/exeda-price.htm |
22:26.39 | dcordes | swc|666, 'Marvell PXA270 520MB CPU' 520MB, nice clock :) |
22:26.52 | swc|666 | i think the specs are very nice overall |
22:26.57 | cr2 | swc|666: pxa270 is good, but 128M is much less than my raph :) |
22:27.02 | swc|666 | and I <3 the fact it has a qwerty |
22:27.10 | swc|666 | ya 128mb ftl |
22:27.27 | swc|666 | cr2, but still it is a fair trade off IMO |
22:27.50 | cr2 | raph has sliding qwerty, so it can use the keyboard place for lcd. |
22:28.09 | dcordes | 3Ah battery, nice |
22:28.22 | cr2 | well, htc sable aka ipaq 6915 was like that with 240x240 screen. |
22:28.34 | swc|666 | has a raph100 |
22:28.41 | cr2 | :) |
22:28.56 | swc|666 | i dont like the tnetw1251 tho :/ |
22:29.09 | cr2 | at least it has a GPL driver |
22:29.28 | cr2 | i don't like the gps receiver performance on raph100 |
22:29.46 | swc|666 | yea the gps sucks |
22:29.48 | cr2 | because it's ultimate junk compared to sirf3. |
22:30.02 | swc|666 | yep |
22:30.46 | cr2 | i have 6915 too, but the 240x240 screen is too little ... |
22:31.08 | cr2 | <PROTECTED> |
22:31.26 | swc|666 | cr2, I bet the screen res on the Exeeda is 480 x 480 |
22:31.36 | cr2 | RS-232 port :D |
22:31.55 | cr2 | it's not square |
22:31.59 | swc|666 | 2 x USB is my interest .. host + device |
22:32.02 | cr2 | lookign at the screenshot |
22:32.13 | swc|666 | 480 x 420 maybe :p |
22:32.18 | cr2 | pxa usbh, that's good. |
22:32.26 | swc|666 | yep |
22:32.31 | cr2 | my pna is 480x272 |
22:32.41 | cr2 | but pxa usbh is 1.1 |
22:33.10 | cr2 | this one is not 480x272 |
22:33.39 | cr2 | hmm. need to find out the aspect ratio from the screenshot |
22:34.34 | swc|666 | nice...exeda NAVMAN Jupiter32 receiver module, Sirf-III chipset |
22:35.01 | swc|666 | ah 640 x 480 VGA, |
22:35.06 | swc|666 | http://www.compulab.co.il/exeda/html/exeda-datasheet.htm |
22:35.59 | swc|666 | grr I wonder why they do not offer => 256mb |
22:36.10 | cr2 | bah, gimp-2.6 has a different gui ;) |
22:37.49 | swc|666 | really |
22:38.49 | cr2 | wtf, how do i copy selection to a new window ?? |
22:39.40 | swc|666 | LoL |
22:42.47 | cr2 | 284x212pixels |
22:43.04 | cr2 | i found a more brutal way to do it :) |
22:43.58 | cr2 | 1.33962 |
22:44.20 | swc|666 | 640x480.. basically the same as raph in landscape |
22:44.33 | cr2 | 480x360 |
22:44.57 | cr2 | yes, 640x480 |
22:46.10 | cr2 | but i think it's 320x240 |
22:47.21 | swc|666 | specs say its 640x480 vga |
22:47.29 | swc|666 | http://www.compulab.co.il/exeda/html/exeda-datasheet.htm |
22:47.37 | cr2 | yes, i see :) |
22:47.46 | cr2 | 3.5" it's huge |
22:47.51 | cr2 | +the keyboard. |
22:48.02 | cr2 | it's more an industrial computer. |
22:48.04 | swc|666 | <PROTECTED> |
22:48.07 | swc|666 | yep |
22:48.32 | cr2 | more like athena |
22:48.49 | cr2 | also pxa270 624 +128MB ram, vga screen |
22:49.14 | cr2 | but this one is gsm phone |
22:49.39 | swc|666 | si |
22:50.02 | swc|666 | i'm definitely going to purchase one |
22:51.19 | cr2 | Connector for optional external antenna |
22:51.39 | cr2 | but pxafb |
22:53.07 | cr2 | Shock-resistant protection |
22:54.27 | swc|666 | "Passed drop on concrete from a height of 6 feet testc" :0 |
22:54.42 | swc|666 | s/testc/test |
22:54.50 | cr2 | wifi+minisd socket are muxed. that's not nice. |
22:56.00 | cr2 | which wifi chip it uses ? |
22:56.25 | cr2 | developer resources link does not work |
22:56.53 | cr2 | .py |
22:56.55 | cr2 | heh |
22:56.57 | cr2 | http://www.compulab.co.il/exeda/html/exeda-developer.htm |
22:57.27 | cr2 | Android - kernel and run-time image |
22:57.29 | cr2 | wow |
22:57.41 | cr2 | The requested URL /exeda/download/exeda-linux.zip was not found on this server |
22:58.04 | cr2 | download is empty |
23:01.14 | cr2 | lol. wince is cheap http://www.compulab.co.il/all-products/html/sw-package-price.htm |
23:03.54 | swc|666 | Wi2Wi W2SW0001... based off of marvell 88W8686 :/ |
23:04.24 | cr2 | where is the kernel source ? |
23:04.52 | swc|666 | i dont see it anywhere yet |
23:05.11 | swc|666 | only thing i can find is http://www.compulab.co.il/mediawiki/files/Linux/x270cm/linux-2.6.24-cm-x270.tar.gz |
23:06.54 | swc|666 | cr2, question - was it ever determined ith the raph has usb host mode ability |
23:06.55 | swc|666 | ? |
23:07.14 | swc|666 | s/ith/if |
23:07.50 | swc|666 | i saw the patches for the vogue, but obviously != msm72xxA |
23:09.17 | *** join/#htc-linux Moult (n=Moult@60.54.126.114) |
23:11.15 | dcordes | swc|666, you probably saw the htc-vogue branch patches that enables usb ethernet and mass storage |
23:11.47 | dcordes | cr2 said host mode is possible on -A |
23:11.57 | dcordes | we just need a driver (see today's log) |
23:12.04 | swc|666 | loooks |
23:12.40 | swc|666 | ah! :D |
23:13.07 | swc|666 | cr2, get to coding! |
23:13.09 | swc|666 | :D |
23:13.30 | Dunedan | For me working audio, wifi and bluetooth would be more important. ;-) |
23:13.54 | dcordes | msm7xxx and msm7xxxA have a different usb chip |
23:14.02 | swc|666 | well if usb host driver is in place, then an external usb wlan card is possible |
23:14.09 | dcordes | non-A only has full speed |
23:14.10 | swc|666 | i already have a power injector |
23:14.38 | dcordes | Dunedan, :) how's debian? |
23:14.59 | Dunedan | well, it works so far, including fso. But I couldn't get X working until now. |
23:16.09 | swc|666 | Dunedan, which device |
23:16.15 | Dunedan | blackstone |
23:16.22 | swc|666 | nice |
23:16.47 | dcordes | Dunedan, did you try the uptodate fso? mickey|tv pushed some msm related patches |
23:17.01 | cr2 | swc|666: tiacx driver is already there, for usb host i have found 2 unknown registers, and probably even more unknown bits in the known registers. |
23:17.05 | Dunedan | dcordes: give me 10 minutes and I'll try |
23:17.50 | cr2 | the usb host is used in spl to attach a miniUSB stick with RAPH*.nbh |
23:18.18 | swc|666 | i c |
23:18.26 | cr2 | the detection protocol is tricky, but should be doable. the usb host driver is more difficult. |
23:18.29 | dcordes | Dunedan, it would be nice to have a debian with armv6-novfp binaries |
23:18.57 | Dunedan | novfp? |
23:19.09 | cr2 | dcordes: can we add the vodafone ppp script to initrd ? |
23:19.48 | dcordes | cr2, we could add one that is provider independent and accepts apn user pass as parameter just like the old ginge script |
23:20.33 | cr2 | i don't have a pass |
23:21.28 | dcordes | cr2, you can pass one anyhow |
23:21.37 | cr2 | ok |
23:21.48 | Dunedan | access to the full ram would be also helpful :-/ |
23:22.12 | cr2 | Dunedan: it works on non-android |
23:22.19 | Dunedan | how? |
23:22.28 | Dunedan | I can only acces around 100MB of ram. |
23:22.32 | dcordes | Dunedan, http://en.wikipedia.org/wiki/ARM_architecture#VFP |
23:22.51 | cr2 | *cough* current git has it enabled. |
23:23.03 | cr2 | i guess the android people are screwed. |
23:23.23 | cr2 | that's why i want a non-android defconfig |
23:23.35 | Dunedan | cr2: well, but shouldn't I need to configure the location via haret? |
23:23.45 | dcordes | do you have one handy? |
23:23.49 | cr2 | remove the mem= |
23:23.52 | cr2 | it's enough |
23:24.48 | Dunedan | dcordes: No updates for fso in debian available. But I can ask nomeata if he can push the latest fso-version into debian. |
23:25.33 | Dunedan | cr2: nice. do you know since which revision it is enabled? |
23:25.45 | cr2 | the non-android defconfig will be able to use nand too. |
23:26.19 | dcordes | Dunedan, does the current debian package have a build from the unstable branch? afaik now there is only one branch used |
23:26.32 | cr2 | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=commitdiff;h=e202233f0b8e7156fa68f4d6bcd624f6e72514de |
23:26.52 | cr2 | -#if 0 |
23:26.53 | cr2 | +#if 1 |
23:26.55 | cr2 | <PROTECTED> |
23:26.59 | dcordes | cr2, can you paste the config somehwere so I can push it |
23:26.59 | Dunedan | cr2: thanks |
23:27.31 | cr2 | dcordes: i'll test nand, and then do a patch. probably tomorrow aka today |
23:27.46 | dcordes | ok |
23:28.11 | Dunedan | hm, is this change also for blackstone, because the file is named *raphael* ... |
23:28.14 | swc|666 | if you need a test rat for the raph100... |
23:28.14 | cr2 | dcordes: i have a vacation for the next week. |
23:28.16 | swc|666 | is here |
23:28.52 | cr2 | swc|666: hehe. imvho you can destroy spl if nand goes crazy. |
23:29.19 | swc|666 | :s |
23:29.31 | cr2 | dcordes: btw, we need a solution for the poor 128MB sdram people. |
23:29.48 | cr2 | and for the raph500 people with 64MB sram. |
23:30.10 | dcordes | we can do it via machine type |
23:30.31 | cr2 | hmm... |
23:30.36 | cr2 | if it will work |
23:30.44 | dcordes | but we lack raph500 machine type |
23:30.48 | dcordes | there is only cdma raphael |
23:31.08 | cr2 | aka raph800 |
23:33.11 | cr2 | the sram size is not really worth adding new mtype |
23:33.20 | Dunedan | dcordes: I currently have fso 0.8.4.9-20 |
23:33.36 | Dunedan | 20090130 |
23:35.58 | Dunedan | dcordes: And why do we want armv6-novfp? Don't the devices support it? |
23:36.40 | dcordes | the binaries run faster when they are opti |
23:36.48 | dcordes | ..mized for the correct arch |
23:37.23 | dcordes | you could benchmark a bit angstrom vs debian on the blackstone. that would be very interesting |
23:37.59 | Dunedan | but isn't vfp an optimization? |
23:38.20 | cr2 | isn't it hardware fp ? |
23:38.25 | cr2 | which msm does not have ? |
23:38.39 | Dunedan | That has been my question. |
23:39.00 | Dunedan | So they don't have it and so we don't need it enabled? |
23:39.16 | cr2 | the kernel does not use fp, so it's not really an issue |
23:39.38 | cr2 | but the userland may profit from fp. |
23:39.43 | cr2 | if your cpu has it ;) |
23:41.20 | cr2 | dcordes: what is the purpose and usage pattern of GPU0 and GPU1 ? do we have a chance to use it in non-android setup ? |
23:41.35 | cr2 | the ADSP and MDP are more of less clear. |
23:41.46 | cr2 | s/ of/ or/ |
23:42.28 | dcordes | Dunedan, the fp is the one thing. the current 'official' debian arm builds are for armv4 afaik. we have armv6 so the extra instructions are not used |
23:42.30 | cr2 | if not, these are 16MB more for something more useful. |
23:43.07 | dcordes | I have no idea about gpu |
23:43.56 | dcordes | what I do know is it would be very useful to have the full accerlation available for X |
23:44.02 | cr2 | static allcation of 16MB may be good for some java stuff, but i don't really see a point right now. |
23:44.36 | Dunedan | Seems like VFP should work with Debian armel: http://wiki.debian.org/ArmEabiPort |
23:44.38 | cr2 | hehe. then you should disassemble the respective .so |
23:45.00 | cr2 | i've already done it, and it's not fun to reimplement. |
23:45.32 | dcordes | so it would be nothing ground breaking, only more 'vram' ? |
23:45.35 | cr2 | i'd simply say f*ck 3D. |
23:45.41 | cr2 | unless somebody will do it. |
23:46.26 | cr2 | yes, some double buffer, place for rotated images & such. |
23:46.58 | cr2 | and, actually, i'd like to switch fb to 565. if it's possible with raph100 panel. |
23:47.16 | cr2 | makes one more free megabyte. |
23:53.40 | cr2 | default 7000 if MSM_AMSS_VERSION_WINCE |
23:53.53 | cr2 | isn'T 5200 a better choice ? |
23:57.47 | cr2 | <PROTECTED> |
23:58.37 | cr2 | the tag can be added to haret though. |
23:59.27 | cr2 | 64*2048=128K blocks |