JTAG/ Kernel development

[Guest skywave]

In the purpose of getting away from the troubled ZTE source code and upgrading to newer kernel versions, i've ported the zte board file to version 2.6.38.7 of Code Aurora and some ZTE changes i could find. This is somewhat of a success as i got it to compile without nasty hacks and i get a ZTE device in my dmesg. But then it starts to go wrong. Lots of "device descriptor read/64, error -71" and unable to enumerate errors. Further it won't get past the green android. As there is no ADB ofcourse there is no shell.

Apparently it's possible to view a kernel console by jtagging it. Somebody who has there blade hooked up to a jtag or can tell me a linksys WRT-54G jtag cable would work? I did find a pinout on google.

[26552.230908] scsi6 : usb-storage 1-1.1:1.0

[26552.231101] usbcore: registered new interface driver usb-storage

[26552.231106] USB Mass Storage support registered.

[26553.229632] scsi 6:0:0:0: Direct-Access ZTE Mass storage 0100 PQ: 0 ANSI: 2

[26553.356556] sd 6:0:0:0: Attached scsi generic sg1 type 0

[26553.359319] sd 6:0:0:0: [sdb] Attached SCSI removable disk

[26611.739910] usb 1-1.1: USB disconnect, device number 9

[26613.730962] usb 1-1.1: new high speed USB device number 10 using ehci_hcd

[26616.297868] hub 1-1:1.0: unable to enumerate USB device on port 1

[26616.545375] usb 1-1.1: new high speed USB device number 12 using ehci_hcd

[26652.677427] usb 1-1.1: USB disconnect, device number 12

[26654.924163] usb 1-1.1: new high speed USB device number 13 using ehci_hcd

[26660.001384] usb 1-1.1: device descriptor read/64, error -71

[26665.182514] usb 1-1.1: device descriptor read/64, error -71

[26665.358461] usb 1-1.1: new high speed USB device number 14 using ehci_hcd

[26670.435660] usb 1-1.1: device descriptor read/64, error -71

[26674.249750] hub 1-1:1.0: unable to enumerate USB device on port 1

[26678.719079] usb 1-1.1: new high speed USB device number 15 using ehci_hcd

[26683.796282] usb 1-1.1: device descriptor read/64, error -71

[26688.977418] usb 1-1.1: device descriptor read/64, error -71

[26689.153301] usb 1-1.1: new high speed USB device number 16 using ehci_hcd

[26694.230467] usb 1-1.1: device descriptor read/64, error -71

[26699.411655] usb 1-1.1: device descriptor read/64, error -71

[26699.587553] usb 1-1.1: new high speed USB device number 17 using ehci_hcd

[26704.996380] usb 1-1.1: device not accepting address 17, error -71

[26705.068522] usb 1-1.1: new high speed USB device number 18 using ehci_hcd

[26710.477360] usb 1-1.1: device not accepting address 18, error -71

[26710.477618] hub 1-1:1.0: unable to enumerate USB device on port 1

[26807.927756] usb 1-1.1: new high speed USB device number 19 using ehci_hcd

[26813.004999] usb 1-1.1: device descriptor read/64, error -71

[26818.186050] usb 1-1.1: device descriptor read/64, error -71

[26818.361999] usb 1-1.1: new high speed USB device number 20 using ehci_hcd

[26823.439148] usb 1-1.1: device descriptor read/64, error -71

[26828.620321] usb 1-1.1: device descriptor read/64, error -71

[26828.796265] usb 1-1.1: new high speed USB device number 21 using ehci_hcd

[26834.205054] usb 1-1.1: device not accepting address 21, error -71

[26834.277020] usb 1-1.1: new high speed USB device number 22 using ehci_hcd

[26839.685990] usb 1-1.1: device not accepting address 22, error -71

[26839.686282] hub 1-1:1.0: unable to enumerate USB device on port 1

https://github.com/s...-blade/tree/zte

Edited February 12, 2012 by skywave

[Guest skywave]

Probably RS232 is more usable than JTAG, but is it possible to debug the kernel with it?

[Guest Davidoff59]

I am way out of my depth here but would this be of any help at all?

http://code.google.com/p/android-serialport-api/

[Guest hedgepigdaniel]

I think TomG might be able to help you

[Guest skywave]

I am way out of my depth here but would this be of any help at all?

r

Thanks but that seems more based on getting a rs232 to interface with microcontrollers, robots etcetera. Also cool stuff.

Anyway i bought a ft232r for this experiment. If we can get kernel messages it would a be much much easier to find out why it doesn't boot. Anyway if we manage to get 2.6.38 working on the blade this would be super awesome. 3.0 would be do-able then.USB accessory mode will then work too.

Edited February 13, 2012 by skywave

[Guest burstlam]

Really impressed with yr enthusiasm and what u are doing~

I have a question ~

I wonder if we could manage to get the wifi working on a .38 kernel...

In the past 2months, I try to update the current source to 2.6.35.14 with reference to nexus s kernel development and longterm linux kernel upgrade,

but the wifi module is trapped in panic status with update.

likewise, the usb gadget driver from google's contain necessary fixes and updates with PM parts,

which looks to me that there is no chance of implement without breaking the pre-build wifi module.

Edited February 13, 2012 by burstlam

[Guest skywave]

Really impressed with yr enthusiasm and what u are doing~

I have a question ~

I wonder if we could manage to get the wifi working on a .38 kernel...

In the past 2months, I try to update the current source to 2.6.35.14 with reference to nexus s kernel development and longterm linux kernel upgrade,

but the wifi module is trapped in panic status with update.

likewise, the usb gadget driver from google's contain necessary fixes and updates with PM parts,

which looks to me that there is no chance of implement without breaking the pre-build wifi module.

compat-wireless has ath6kl drivers. The touchpad dev's seem to be switching to them. https://github.com/y...9dc954042c4fcc7

I actually had these drivers compiled for the zte-turies-35 kernel which only needed a patch that was called "create pm flags" or something to successfully load the modules. Only problem was that there was no wifi socket generated.

Edited February 13, 2012 by skywave

[Guest skywave]

Meanwhile i got the FT232R and i can happily read out the bootloader. Unfortunately i haven't been able to get messages from the linux kernel. Somebody got tips or had it working at some point?

I tried a lot of bootloader cmd options and build configs, enabled DEBUG_LL, EARLY_PRINTK, MSM_SERIAL(_CONSOLE), DEBUG_UART3, and in the cmd line both earlyprintk and earlyprintk=serial,ttyMSM2,115200, console=ttyMSM2,115200n8 But nothing.

BTW, you don't have to solder it, ground is working fine via the usb cable (when connected that is) and you need (pretty sure) the rx pin connected to receive messages.

Would be a shame if we can't debug a kernel via serial, would seriously hamper if not shut down any attempt at getting some new kernels on it.

Edited February 29, 2012 by skywave

[Guest skywave]

Juding from the source code i think the board-msm7x27 file which is the base for all ZTE devices, it seems there is no serial debugger nor console functions/support. Dunno how ZTE is debugging their kernels... but so far i conclude that porting any new kernel to the blade is an absolute no go if we can't debug it...

[Guest tilal6991]

Think Tom G might be able to help you on this as he has JTAG and I think he's a pro at using it.

[Guest skywave]

Think Tom G might be able to help you on this as he has JTAG and I think he's a pro at using it.

You mean this topic?

Got the same chip or something very similar as he did, on the back of the phone. Don't think he ever got kernel output out of it, at least he doesn't mention it in that topic. I only see the same logs of the bootloader, which is the only thing i receive. What i (and TomG) wanted is the kernel output the printk's and preferably earlyprintk to the UART port.

If you check board-msm7x30 it actually intitializes that uart devices when the serial_consol is enabled, where 7x27 has no mention of any serial console or debugger. Also no ttyMSM in /dev/

For who's interested this is the same log for gen2.

welcome to lk

calling constructors

initializing heap

initializing threads

initializing dpc

initializing timers

creating bootstrap completion thread

top of bootstrap2()

initializing flash

nandcfg: 0 0 (initial)

nandcfg(Apps): a85408c0 4745e (used)

nandcfg(Modem): aa5400c0 4745e (used)

initializing platform

platform_init()

Get_Truly_ID is 0x6902

!flash_read_image: success (0 errors)

[hp@lcd&fb]:lcd module init exit

![LY] before select_1wire_mode

panel_backlight on

!\0x00initializing target

target_init()

0: 0:MIBIB offs=0x00000000 size=0x0000000a attr: 0x00ffffff

1: 0:QCSBL offs=0x0000000a size=0x00000002 attr: 0x00ffffff

2: 0:OEMSBL1 offs=0x0000000c size=0x00000005 attr: 0x00ffffff

3: 0:OEMSBL2 offs=0x00000011 size=0x00000005 attr: 0x00ffffff

4: 0:AMSS offs=0x00000016 size=0x000000d4 attr: 0x00ffffff

5: 0:APPSBL offs=0x000000ea size=0x00000003 attr: 0x00ffffff

6: 0:FOTA offs=0x000000ed size=0x00000078 attr: 0x00ffffff

7: 0:EFS2 offs=0x00000165 size=0x00000060 attr: 0x00ffffff

8: 0:APPS offs=0x000001c5 size=0x00000002 attr: 0x00ffffff

9: 0:FTL offs=0x000001c7 size=0x00000005 attr: 0x00ff0101

10: 0:EFS2APPS offs=0x000001cc size=0xffffffff attr: 0x00ffffff

smem ptable found: ver: 3 len: 11

ptn 0 name='recovery' start=000001cc len=00000028 flags=00000000 type=Apps Writable=Yes

ptn 1 name='boot' start=000001f4 len=00000028 flags=00000000 type=Apps Writable=Yes

ptn 2 name='splash' start=0000021c len=0000000c flags=00000000 type=Apps Writable=Yes

ptn 3 name='misc' start=00000228 len=00000004 flags=00000000 type=Apps Writable=Yes

ptn 4 name='cache' start=0000022c len=0000012c flags=00000000 type=Apps Writable=Yes

ptn 5 name='system' start=00000358 len=000006e0 flags=00000000 type=Apps Writable=Yes

ptn 6 name='userdata' start=00000a38 len=00000514 flags=00000000 type=Apps Writable=Yes

ptn 7 name='oem' start=00000f4c len=000000a8 flags=00000000 type=Apps Writable=Yes

ptn 8 name='persist' start=00000ff4 len=0000000c flags=00000000 type=Apps Writable=Yes

ptn 9 name='MIBIB' start=00000000 len=0000000a flags=00000000 type=Modem Writable=Yes

ptn 10 name='QCSBL' start=0000000a len=00000002 flags=00000000 type=Modem Writable=Yes

ptn 11 name='OEMSBL1' start=0000000c len=00000005 flags=00000000 type=Modem Writable=Yes

ptn 12 name='OEMSBL2' start=00000011 len=00000005 flags=00000000 type=Modem Writable=Yes

ptn 13 name='AMSS' start=00000016 len=000000d4 flags=00000000 type=Modem Writable=Yes

ptn 14 name='APPSBL' start=000000ea len=00000003 flags=00000000 type=Modem Writable=Yes

ptn 15 name='FOTA' start=000000ed len=00000078 flags=00000000 type=Modem Writable=Yes

ptn 16 name='EFS2' start=00000165 len=00000060 flags=00000000 type=Modem Writable=Yes

ptn 17 name='APPS' start=000001c5 len=00000002 flags=00000000 type=Modem Writable=Yes

ptn 18 name='FTL' start=000001c7 len=00000005 flags=00000000 type=Modem Writable=Yes

ptn 19 name='EFS2APPS' start=000001cc len=ffffffff flags=00000000 type=Modem Writable=Yes

calling apps_init()

[ZYF.BOOT] FTM NV = 2

jiangfeng: g_boot_key_exit_ftm = 0, first time

flash_read_image: success (0 errors)

flash_read_image: success (0 errors)

flash_read_image: success (0 errors)

kernel @ 2608000 (4294864 bytes)

ramdisk @ 3600000 (168099 bytes)

cmdline = 'androidboot.hardware=blade console=ttyMSM2,115200n8'

Booting Linux

booting linux @ 0x2608000, ramdisk @ 0x3600000 (168099)

cmdline: androidboot.hardware=blade console=ttyMSM2,115200n8

[Guest tilal6991]

You mean this topic? http://android.modac...2-on-the-blade/

Got the same chip or something very similar as he did, on the back of the phone. Don't think he ever got kernel output out of it, at least he doesn't mention it in that topic. I only see the same logs of the bootloader, which is the only thing i receive. What i (and TomG) wanted is the kernel output the printk's and preferably earlyprintk to the UART port.

If you check board-msm7x30 it actually intitializes that uart devices when the serial_consol is enabled, where 7x27 has no mention of any serial console or debugger. Also no ttyMSM in /dev/

For who's interested this is the same log for gen2.

Yeah. That was the topic I was referring to. It's going to nigh on impossible to port a kernel from scratch without some help from ZTE (ie. releasing a kernel for an ARM7 device which can be backported) They've made it specifically difficult with the lack of debugging and the mess of code they call a kernel.

[Guest skywave]

If someone has

CONFIG_SERIAL_MSM=y

CONFIG_SERIAL_MSM_CONSOLE=y

In their kernel could they check in ksmg if they see

1. <6>[ 2.994049] msm_serial: detected port #2
2. <6>[ 2.994110] msm_serial.2: ttyMSM2 at MMIO 0xacc00000 (irq = 71) is a MSM
3. <6>[ 2.994232] msm_serial: console setup on port #2

[Guest skywave]

http://forum.xda-developers.com/showthread.php?p=23193704#post23193704

I think ZTE disabled UART3 in GEN2, some TPT expert with knowledge?

[Guest skywave]

http://forum.xda-dev...04#post23193704

I think ZTE disabled UART3 in GEN2, some TPT expert with knowledge?

Turned out to be bullshit. Serial drivers were (deliberately?) borked. 2 lines of code and i got myself a serial console :) Now one on 2.6+

You can also write to ttyMSM2 so besides console there is more cool stuff you can do with it.

Edited March 3, 2012 by skywave

[Guest Sulthekk]

Turned out to be bullshit. Serial drivers were (deliberately?) borked. 2 lines of code and i got myself a serial console :) Now one on 2.6+

You can also write to ttyMSM2 so besides console there is more cool stuff you can do with it.

What was the borked part? Could you share a diff?

Edited March 3, 2012 by Sulthekk

[Guest skywave]

What was the borked part? Could you share a diff?

https://github.com/burstlam/zte-turies-35/pull/3

[Guest Sulthekk]

Thank you

[Guest skywave]

I am way out of my depth here but would this be of any help at all?

http://code.google.c...serialport-api/

This would be useful for someone who wants to do with these serial ports yes. Think you could easily but a remote controlled bladedroid with this.

Edited March 3, 2012 by skywave

[Guest tcpaulh]

Very cool stuff. Subscribed

[Guest Davidoff59]

So what is your next step from here Skywave? Do you have a kernel in mind that you will try to get working on the Blade?

You synced your work with Burstlam, is he going to start using JTAG or are you going to work with him on Kernel development?

Is Tom_G aware of the fix given his previous work in this area?

I also love your enthusiasm, that you kept updating this thread, and kept up with your work to enable JTAG despite not much assistance being given from this thread.

Your excitement is catching, so I apologise for all the questions.

[Guest HarryPirate]

Wonderful work!