USB udc is always inactive - embedded-linux

I have encountered a problem with a USB UDC linux driver. I'd like to connect our PXA320 based board to PC using g_ether and USB UDC.
Our board uses PXA320 with Linux-2.6.32 kernel.
I have enabled pxa27x UDC and g_ether on menuconfig and built kernel successfully.
But after I run "ifup usb0" and plug in the USB cable, PC detects the USB device (since D+ pull-up resistor is enabled) and sends "GET DESCRIPTOR" to the device. But the USB device(our board) does NOT respond.
I dumped some register values and found that the UDCCR is 0x1 which means UDC is enabled but is inactive.
The following are the debug messages I got:
ifup usb0
+++ ether - init
++++ usb_composite_register
+++ usb_gadget_register_driver
+++ dplus_pullup, on = 1
++++ composite_bind
+++ pxa_ep_alloc_request
--- pxa_ep_alloc_request
+++ eth_bind
g_ether gadget: using random self ethernet address
g_ether gadget: using random host ethernet address
usb0: MAC d6:81:e9:fa:0c:66
usb0: HOST MAC 7a:58:58:9a:bb:be
+++ eth_bind - CDC Subset/SAFE
+++ eth_bind - RNDIS plus ECM-or-Subset
+++ eth_bind - manufacturer = Linux 2.6.32.9 with pxa27x_udc
adding config #2 'RNDIS'/bf0059c0
adding 'rndis'/c7fcdf00 to config 'RNDIS'/bf0059c0
++++ composite_uevent
+++ usb_interface_id
--- usb_interface_id - id = 0
+++ usb_interface_id
--- usb_interface_id - id = 1
+++ pxa_ep_alloc_request
--- pxa_ep_alloc_request
adding config #1 'CDC Subset/SAFE'/bf00594c
+++ eth_do_config
adding 'cdc_subset'/c7fcdd80 to config 'CDC Subset/SAFE'/bf00594c
++++ composite_uevent
+++ usb_interface_id
--- usb_interface_id - id = 0
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
Memorial Day 2008, version:
g_ether gadget: g_ether ready
registered gadget driver 'g_ether'
+++ should_enable_udc
--- should_enable_udc, put_on = 1
+++ udc_enable
+++ udc_clear_mask_UDCCR - udccr = 0x0, mask = 0x1
--- udc_clear_mask_UDCCR - udccr = 0x0
clk_pxa3xx_cken_enable - clk->cken = 0x14
+++ ep0_idle
+++ set_ep0state
state=WAIT_FOR_SETUP->WAIT_FOR_SETUP, udccsr0=0x000, udcbcr=0
+++ udc_set_mask_UDCCR
+++ ep_write_UDCCSR
+++ pio_irq_enable, index = 0
--- udc_enable
UDCCR(0x0) = 0x1
UDCICR0(0x4) = 0x3
UDCICR1(0x8) = 0xb8000000
UDCISR0(0xc) = 0x0
UDCISR1(0x10) = 0x0
UDCFNR(0x14) = 0x0
UDCOTGICR(0x18) = 0x0
UP2OCR(0x20) = 0xa0
UP3OCR(0x24) = 0x0
(0x100) = 0x200
(0x200) = 0x0
(0x300) = 0x43881454
(0x400) = 0x0
ICPR = 0x0
ICPR2 = 0x0
ICIP = 0x0
ICIP2 = 0x0
ICFP = 0x0
ICFP2 = 0x0
ICMR = 0x6b24c08
ICMR2 = 0x2000
ICLR = 0x0
ICLR2 = 0x0
ICCR = 0x1
ACCR = 0x0000321f
ACSR = 0x3003321f
AICSR = 0x0
CKEN_A = 0xffbfffff
CKEN_B = 0xffffffff
From the debug message, I can see that UDC clock is enabled (CKEN_A bit20), UDC interrupt is enabled (ICMR bit11) nad UDC is enabled (UDCCR bit0). But UDC is inactive(UDCCR bit1).
I have verified hardware by running Windows CE OS on the board and I could connect to PC via activesync.
I compared UDC registers between CE OS and Linux OS. CE version shows UDCCR is 0x3 which means UDC is active.
I don't understand why UDC is inactive in Linux. That bit in UDCCR is read only.
Could anyone give me some hints on how to solve this issue?
Thanks in advance

Related

What "deleted" means in /proc/$pid/maps?

I downloaded libhugetlbfs.so and have a simple test source :
int glbarr[1024*1024]={0} ;
int main()
{
char * ptr ;
ptr = (char *) malloc( 1024 * 1024 * 1 ) ;
printf(" press any key to go on \n");
getchar() ;
for(int idx=0;idx<100;idx++){
char strtmp[64] = {0} ;
sprintf(strtmp,"%020d",idx) ;
strcpy( ptr+1024*idx , strtmp ) ;
} //for
for(int idx=0;idx<100;idx++){
glbarr[idx] = idx ;
}
printf(" press any key to go on \n");
getchar() ;
} // main
then set the env :
export LD_PRELOAD=libhugetlbfs.so
export HUGETLB_MORECORE=yes
export HUGETLB_DEBUG=1
At last , execute test_malloc.exe :
INFO: Found pagesize 2048 kB
INFO: Detected page sizes:
INFO: Size: 2048 kB (default) Mount: /mnt/SharedMem_2M
INFO: Parsed kernel version: [3] . [10] . [0]
INFO: Feature private_reservations is present in this kernel
INFO: Feature noreserve_safe is present in this kernel
INFO: Feature map_hugetlb is present in this kernel
INFO: Kernel has MAP_PRIVATE reservations. Disabling heap prefaulting.
INFO: Kernel supports MAP_HUGETLB
INFO: HUGETLB_SHARE=0, sharing disabled
INFO: HUGETLB_NO_RESERVE=no, reservations enabled
INFO: Segment 0 (phdr 2): 0x400000-0x400a04 (filesz=0xa04) (prot = 0x5)
INFO: Segment 1 (phdr 3): 0x600de0-0xa01080 (filesz=0x274) (prot = 0x3)
DEBUG: symbol to copy at 0x601060: stdin
DEBUG: Total memsz = 0x400ca4, memsz of largest segment = 0x4002a0
INFO: libhugetlbfs version: 2.20
INFO: Mapped hugeseg at 0x2aaaaac00000. Copying 0xa04 bytes and 0 extra bytes from 0x400000...done
INFO: Prepare succeeded
INFO: Mapped hugeseg at 0x2aaaaac00000. Copying 0x274 bytes and 0x14 extra bytes from 0x600de0...done
INFO: Prepare succeeded
INFO: setup_morecore(): heapaddr = 0x1c00000
INFO: hugetlbfs_morecore(2101248) = ...
INFO: heapbase = 0x1c00000, heaptop = 0x1c00000, mapsize = 0, delta=2101248
INFO: Attempting to map 4194304 bytes
INFO: ... = 0x1c00000
INFO: hugetlbfs_morecore(0) = ...
INFO: heapbase = 0x1c00000, heaptop = 0x1e01000, mapsize = 400000, delta=-2093056
INFO: ... = 0x1e01000
and the /proc/pidof test_malloc.exe/maps :
00400000-00600000 r-xp 00000000 00:2b 6019488 /mnt/SharedMem_2M/libhugetlbfs.tmp.uI55WD (deleted)
00600000-00c00000 rw-p 00000000 00:2b 6123885 /mnt/SharedMem_2M/libhugetlbfs.tmp.VUALYM (deleted)
01c00000-02000000 rw-p 00000000 00:0d 6123886 /anon_hugepage (deleted)
numastat -m showes hugepage really in use for 8M ,
What bother me is what do "deleted" means in maps output ?!
either in /mnt/SharedMem_2M or /anon_hugepage
Edit :
and the debug information :
INFO: Found pagesize 2048 kB
INFO: Detected page sizes:
INFO: Size: 2048 kB (default) Mount: /mnt/SharedMem_2M
INFO: Parsed kernel version: [3] . [10] . [0]
INFO: Feature private_reservations is present in this kernel
INFO: Feature noreserve_safe is present in this kernel
INFO: Feature map_hugetlb is present in this kernel
INFO: Kernel has MAP_PRIVATE reservations. Disabling heap prefaulting.
INFO: Kernel supports MAP_HUGETLB
INFO: HUGETLB_SHARE=0, sharing disabled
INFO: HUGETLB_NO_RESERVE=no, reservations enabled
INFO: Segment 0 (phdr 3): 0x600de0-0xa01080 (filesz=0x274) (prot = 0x3)
DEBUG: symbol to copy at 0x601060: stdin
DEBUG: Total memsz = 0x4002a0, memsz of largest segment = 0x4002a0
INFO: libhugetlbfs version: 2.20
INFO: Mapped hugeseg at 0x2aaaaac00000. Copying 0x274 bytes and 0x14 extra bytes from 0x600de0...done
INFO: Prepare succeeded
INFO: setup_morecore(): heapaddr = 0x2200000
INFO: hugetlbfs_morecore(2101248) = ...
INFO: heapbase = 0x2200000, heaptop = 0x2200000, mapsize = 0, delta=2101248
INFO: Attempting to map 4194304 bytes
INFO: ... = 0x2200000
INFO: hugetlbfs_morecore(0) = ...
INFO: heapbase = 0x2200000, heaptop = 0x2401000, mapsize = 400000, delta=-2093056
INFO: ... = 0x2401000
and the maps :
00400000 default file=/home/marschen/test/posix-memalign/test_malloc.exe mapped=1 N0=1 kernelpagesize_kB=4
00600000 default file=/mnt/SharedMem_2M/libhugetlbfs.tmp.85Y41e\040(deleted) huge anon=1 dirty=1 N0=1 kernelpagesize_kB=2048
02200000 default file=/anon_hugepage\040(deleted) huge anon=1 dirty=1 N0=1 kernelpagesize_kB=2048
Temporary file deletion (unlinking) is normal for libhugetlbfs when it uses hugetlb fs pseudo filesystem (grep hugetlbfs /proc/filesystems) for getting mmaps backed with hugetlb pages.
For example, there is hugetlbfs_unlinked_fd function of libhugetlbfs/hugeutils.c
https://github.com/libhugetlbfs/libhugetlbfs/blob/e44180072b796c0e28e53c4d01ef6279caaa2a99/hugeutils.c#L1033
int hugetlbfs_unlinked_fd_for_size(long page_size)
{
const char *path;
char name[PATH_MAX+1];
int fd;
path = hugetlbfs_find_path_for_size(page_size);
..
name[sizeof(name)-1] = '\0';
strcpy(name, path);
strncat(name, "/libhugetlbfs.tmp.XXXXXX", sizeof(name)-1);
/* FIXME: deal with overflows */
fd = mkstemp64(name);
....
unlink(name);
return fd;
}
Temporary file name is randomly generated in mkstemp function; it also creates the file and opens it. Then this file is unlinked (man 2 unlink) from the filesystem (file name is marked as deleted in the directory, there is still inode and file data, but other programs can't access this file by name).
While unlinked fd is opened, it can be used to work with hugetlb mmap and to store data. Only when this fd is closed, file data will be actually deleted by fs.
Early unlinking of mktemp files is often used: When a file created with mkstemp() is deleted?
Some useful information can be also listed in HOWTO of libhugetlbfs project
https://github.com/libhugetlbfs/libhugetlbfs/blob/master/HOWTO

How to fix tensorflow protobuf compilation errors on OSX?

I'm trying to compile TensorFlow after checking out the repo.
I've reached a point where I'm stuck with google protobuf errors:
INFO: From Compiling tensorflow/core/kernels/histogram_op_gpu.cu.cc:
./tensorflow/core/lib/core/status.h(32): warning: attribute "warn_unused_result" does not apply here
external/protobuf_archive/src/google/protobuf/arena.h(719): error: more than one instance of overloaded function "google::protobuf::Arena::CreateMessageInternal" matches the argument list:
function template "T *google::protobuf::Arena::CreateMessageInternal<T>(google::protobuf::Arena *)"
function template "T *google::protobuf::Arena::CreateMessageInternal<T,Args...>(Args &&...)"
argument types are: (google::protobuf::Arena *)
detected during:
instantiation of "Msg *google::protobuf::Arena::CreateMaybeMessage<Msg>(google::protobuf::Arena *, google::protobuf::internal::true_type) [with Msg=tensorflow::TensorShapeProto_Dim]"
(729): here
instantiation of "T *google::protobuf::Arena::CreateMaybeMessage<T>(google::protobuf::Arena *) [with T=tensorflow::TensorShapeProto_Dim]"
external/protobuf_archive/src/google/protobuf/repeated_field.h(648): here
instantiation of "GenericType *google::protobuf::internal::GenericTypeHandler<GenericType>::New(google::protobuf::Arena *) [with GenericType=tensorflow::TensorShapeProto_Dim]"
external/protobuf_archive/src/google/protobuf/repeated_field.h(675): here
instantiation of "GenericType *google::protobuf::internal::GenericTypeHandler<GenericType>::NewFromPrototype(const GenericType *, google::protobuf::Arena *) [with GenericType=tensorflow::TensorShapeProto_Dim]"
external/protobuf_archive/src/google/protobuf/repeated_field.h(1554): here
instantiation of "TypeHandler::Type *google::protobuf::internal::RepeatedPtrFieldBase::Add<TypeHandler>(TypeHandler::Type *) [with TypeHandler=google::protobuf::RepeatedPtrField<tensorflow::TensorShapeProto_Dim>::TypeHandler]"
external/protobuf_archive/src/google/protobuf/repeated_field.h(2001): here
instantiation of "Element *google::protobuf::RepeatedPtrField<Element>::Add() [with Element=tensorflow::TensorShapeProto_Dim]"
bazel-out/local_darwin-opt/genfiles/tensorflow/core/framework/tensor_shape.pb.h(471): here
....
Has anyone bumped into this issue ? Any ideas on how to tackle this issue ?
(I'm using Python 2.7 in a virtual environment on OSX 10.11.5)
Luckily someone else already no only had the same issue, but also found a fix and shared it. Thanks to Daniel Trebbien's comments on protobuf and eigen I could compile tensorflow with GPU support on OSX:
>>> import tensorflow as tf
>>> tf.__version__
'1.6.0-rc0'
>>> sess = tf.Session(config=tf.ConfigProto(log_device_placement=True))
2018-02-19 22:22:12.194516: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:859] OS X does not support NUMA - returning NUMA node zero
2018-02-19 22:22:12.195011: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1331] Found device 0 with properties:
name: GeForce GT 750M major: 3 minor: 0 memoryClockRate(GHz): 0.9255
pciBusID: 0000:01:00.0
totalMemory: 2.00GiB freeMemory: 12.58MiB
2018-02-19 22:22:12.195038: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1410] Adding visible gpu devices: 0
2018-02-19 22:22:14.563665: I tensorflow/core/common_runtime/gpu/gpu_device.cc:911] Device interconnect StreamExecutor with strength 1 edge matrix:
2018-02-19 22:22:14.563700: I tensorflow/core/common_runtime/gpu/gpu_device.cc:917] 0
2018-02-19 22:22:14.563707: I tensorflow/core/common_runtime/gpu/gpu_device.cc:930] 0: N
2018-02-19 22:22:14.563798: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1021] Creating TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 65 MB memory) -> physical GPU (device: 0, name: GeForce GT 750M, pci bus id: 0000:01:00.0, compute capability: 3.0)
Device mapping:
/job:localhost/replica:0/task:0/device:GPU:0 -> device: 0, name: GeForce GT 750M, pci bus id: 0000:01:00.0, compute capability: 3.0
2018-02-19 22:22:14.697626: I tensorflow/core/common_runtime/direct_session.cc:297] Device mapping:
/job:localhost/replica:0/task:0/device:GPU:0 -> device: 0, name: GeForce GT 750M, pci bus id: 0000:01:00.0, compute capability: 3.0
For reference, here are the patches proposed in the comments:
--- a/tensorflow/workspace.bzl
+++ b/tensorflow/workspace.bzl
## -353,11 +353,11 ## def tf_workspace(path_prefix="", tf_repo_name=""):
tf_http_archive(
name = "protobuf_archive",
urls = [
- "https://mirror.bazel.build/github.com/google/protobuf/archive/396336eb961b75f03b25824fe86cf6490fb75e3a.tar.gz",
- "https://github.com/google/protobuf/archive/396336eb961b75f03b25824fe86cf6490fb75e3a.tar.gz",
+ "https://mirror.bazel.build/github.com/dtrebbien/protobuf/archive/50f552646ba1de79e07562b41f3999fe036b4fd0.tar.gz",
+ "https://github.com/dtrebbien/protobuf/archive/50f552646ba1de79e07562b41f3999fe036b4fd0.tar.gz",
],
- sha256 = "846d907acf472ae233ec0882ef3a2d24edbbe834b80c305e867ac65a1f2c59e3",
- strip_prefix = "protobuf-396336eb961b75f03b25824fe86cf6490fb75e3a",
+ sha256 = "eb16b33431b91fe8cee479575cee8de202f3626aaf00d9bf1783c6e62b4ffbc7",
+ strip_prefix = "protobuf-50f552646ba1de79e07562b41f3999fe036b4fd0",
)
--- a/tensorflow/workspace.bzl
+++ b/tensorflow/workspace.bzl
## -120,11 +120,11 ## def tf_workspace(path_prefix="", tf_repo_name=""):
tf_http_archive(
name = "eigen_archive",
urls = [
- "https://mirror.bazel.build/bitbucket.org/eigen/eigen/get/2355b229ea4c.tar.gz",
- "https://bitbucket.org/eigen/eigen/get/2355b229ea4c.tar.gz",
+ "https://mirror.bazel.build/bitbucket.org/dtrebbien/eigen/get/374842a18727.tar.gz",
+ "https://bitbucket.org/dtrebbien/eigen/get/374842a18727.tar.gz",
],
- sha256 = "0cadb31a35b514bf2dfd6b5d38205da94ef326ec6908fc3fd7c269948467214f",
- strip_prefix = "eigen-eigen-2355b229ea4c",
+ sha256 = "fa26e9b9ff3a2692b092d154685ec88d6cb84d4e1e895006541aff8603f15c16",
+ strip_prefix = "dtrebbien-eigen-374842a18727",
build_file = str(Label("//third_party:eigen.BUILD")),
)

add_timer causes kernel stack dump for multiple PCI boards

We are using FPGA cards with PCI express drivers to move data around with DMA engines. This all works fine for a single card in a machine, however with two cards it fails. As an initial investigation, I have narrowed an error down to the add_timer function that is used to set up the polling mechanism. When insmod adds the driver modules, a stack trace is produced as the poll_timer routine is the same for both instances. The code has been reduced to
static int dat_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
struct timer_list * timer = &poll_timer;
int i;
/* Start polling routine */
log_normal(KERN_INFO "DEBUG ADD TIMER: Starting poll routine with %x\n", pdev);
init_timer(timer);
// random number added so that expires value is different for both instances of timer
get_random_bytes(&i, 1);
timer->expires=jiffies+HZ+i;
timer->data=(unsigned long) pdev;
timer->function = poll_routine;
log_verbose("DEBUG ADD TIMER: Timer expires %x\n", timer->expires);
log_verbose("DEBUG ADD TIMER: Timer data %x\n", timer->data);
log_verbose("DEBUG ADD TIMER: Timer function %x\n", timer->function);
// ***** THIS IS WHERE STACK TRACE OCCURS (WHEN CALLED FOR SECOND TIME)
add_timer(timer);
log_verbose("DEBUG ADD TIMER: Value of HZ is %d\n", HZ);
log_verbose("DEBUG ADD TIMER: End of probe\n");
return 0;
}
the stack trace produces
list_add corruption. prev->next should be next (ffffffff81f76228), but was (null). (prev=ffffffffa050a3c0).
and
list_add double add: new=ffffffffa050a3c0, prev=ffffffffa050a3c0, next=ffffffff81f76228.
Looking at the printk statements, it is clear that the add_timer is trying to add the same routine to the linked list. Is this correct?
DEBUG ADD TIMER: Timer expires fffd9cd3
DEBUG ADD TIMER: Timer data 6c0ac000
DEBUG ADD TIMER: Timer function **a0508150**
DEBUG ADD TIMER: Value of HZ is 1000
DEBUG ADD TIMER: End of probe
DEBUG ADD TIMER: Starting poll routine with 6c0ad000
DEBUG ADD TIMER: Timer expires fffd9c7d
DEBUG ADD TIMER: Timer data 6c0ad000
DEBUG ADD TIMER: Timer function **a0508150**
So my question(s) is(are), how should I configure the timer for multiple instantations of the same driver? (Assuming that is what is happening when multiple boards are inserted into the machine).
full stack trace
DEBUG ADD TIMER: Inserting driver into kernel.
DEBUG ADD TIMER: Starting poll routine with 6c0ac000
DEBUG ADD TIMER: Timer expires fffd9cd3
DEBUG ADD TIMER: Timer data 6c0ac000
DEBUG ADD TIMER: Timer function a0508150
DEBUG ADD TIMER: Value of HZ is 1000
DEBUG ADD TIMER: End of probe
DEBUG ADD TIMER: Starting poll routine with 6c0ad000
DEBUG ADD TIMER: Timer expires fffd9c7d
DEBUG ADD TIMER: Timer data 6c0ad000
DEBUG ADD TIMER: Timer function a0508150
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2201 at lib/list_debug.c:33 __list_add+0xa0/0xd0()
list_add corruption. prev->next should be next (ffffffff81f76228), but was (null). (prev=ffffffffa050a3c0).
Modules linked in: xdma_v7(POE+) xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller crc32c_intel eeepc_wmi ghash_clmulni_intel asus_wmi ftdi_sio iTCO_wdt snd_hda_codec sparse_keymap raid0 iTCO_vendor_support
snd_hda_core rfkill sb_edac ipmi_ssif video mxm_wmi edac_core snd_hwdep mei_me snd_seq snd_seq_device ipmi_msghandler snd_pcm mei acpi_pad tpm_infineon lpc_ich mfd_core snd_timer tpm_tis shpchp tpm snd soundcore i2c_i801 wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc ast drm_kms_helper ttm drm igb serio_raw ptp pps_core dca i2c_algo_bit
CPU: 0 PID: 2201 Comm: insmod Tainted: P OE 4.1.8-100.fc21.x86_64 #1
Hardware name: ASUSTeK COMPUTER INC. Z10PE-D8 WS/Z10PE-D8 WS, BIOS 1001 03/17/2015
0000000000000000 00000000ec73155d ffff880457123928 ffffffff81792065
0000000000000000 ffff880457123980 ffff880457123968 ffffffff810a163a
0000000000000246 ffffffffa050a3c0 ffffffff81f76228 ffffffffa050a3c0
Call Trace:
[<ffffffff81792065>] dump_stack+0x45/0x57
[<ffffffff810a163a>] warn_slowpath_common+0x8a/0xc0
[<ffffffff810a16c5>] warn_slowpath_fmt+0x55/0x70
[<ffffffff810f8250>] ? vprintk_emit+0x3b0/0x560
[<ffffffff813c7c30>] __list_add+0xa0/0xd0
[<ffffffff81108412>] __internal_add_timer+0xb2/0x130
[<ffffffff811084bf>] internal_add_timer+0x2f/0xb0
[<ffffffff8110a1ca>] mod_timer+0x12a/0x210
[<ffffffff8110a2c8>] add_timer+0x18/0x30
[<ffffffffa050810f>] dat_probe+0xbf/0x100 [xdma_v7]
[<ffffffff813f6da5>] local_pci_probe+0x45/0xa0
[<ffffffff812a8da2>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
[<ffffffff813f8109>] pci_device_probe+0xf9/0x150
[<ffffffff814e7e59>] driver_probe_device+0x209/0x4b0
[<ffffffff814e81db>] __driver_attach+0x9b/0xa0
[<ffffffff814e8140>] ? __device_attach+0x40/0x40
[<ffffffff814e5973>] bus_for_each_dev+0x73/0xc0
[<ffffffff814e772e>] driver_attach+0x1e/0x20
[<ffffffff814e72e0>] bus_add_driver+0x180/0x250
[<ffffffffa000a000>] ? 0xffffffffa000a000
[<ffffffff814e89d4>] driver_register+0x64/0xf0
[<ffffffff813f662c>] __pci_register_driver+0x4c/0x50
[<ffffffffa000a02c>] dat_init+0x2c/0x1000 [xdma_v7]
[<ffffffff81002148>] do_one_initcall+0xd8/0x210
[<ffffffff812094f9>] ? kmem_cache_alloc_trace+0x1a9/0x230
[<ffffffff817911bc>] ? do_init_module+0x28/0x1cc
[<ffffffff817911f5>] do_init_module+0x61/0x1cc
[<ffffffff811270bb>] load_module+0x20db/0x2550
[<ffffffff81122990>] ? store_uevent+0x70/0x70
[<ffffffff8122e860>] ? kernel_read+0x50/0x80
[<ffffffff81127766>] SyS_finit_module+0xa6/0xe0
[<ffffffff8179892e>] system_call_fastpath+0x12/0x71
---[ end trace 340e5d7ba2d89081 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2201 at lib/list_debug.c:36 __list_add+0xcb/0xd0()
list_add double add: new=ffffffffa050a3c0, prev=ffffffffa050a3c0, next=ffffffff81f76228.
Modules linked in: xdma_v7(POE+) xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller crc32c_intel eeepc_wmi ghash_clmulni_intel asus_wmi ftdi_sio iTCO_wdt snd_hda_codec sparse_keymap raid0 iTCO_vendor_support
snd_hda_core rfkill sb_edac ipmi_ssif video mxm_wmi edac_core snd_hwdep mei_me snd_seq snd_seq_device ipmi_msghandler snd_pcm mei acpi_pad tpm_infineon lpc_ich mfd_core snd_timer tpm_tis shpchp tpm snd soundcore i2c_i801 wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc ast drm_kms_helper ttm drm igb serio_raw ptp pps_core dca i2c_algo_bit
CPU: 0 PID: 2201 Comm: insmod Tainted: P W OE 4.1.8-100.fc21.x86_64 #1
Hardware name: ASUSTeK COMPUTER INC. Z10PE-D8 WS/Z10PE-D8 WS, BIOS 1001 03/17/2015
0000000000000000 00000000ec73155d ffff880457123928 ffffffff81792065
0000000000000000 ffff880457123980 ffff880457123968 ffffffff810a163a
0000000000000246 ffffffffa050a3c0 ffffffff81f76228 ffffffffa050a3c0
Call Trace:
[<ffffffff81792065>] dump_stack+0x45/0x57
[<ffffffff810a163a>] warn_slowpath_common+0x8a/0xc0
[<ffffffff810a16c5>] warn_slowpath_fmt+0x55/0x70
[<ffffffff810f8250>] ? vprintk_emit+0x3b0/0x560
[<ffffffff813c7c5b>] __list_add+0xcb/0xd0
[<ffffffff81108412>] __internal_add_timer+0xb2/0x130
[<ffffffff811084bf>] internal_add_timer+0x2f/0xb0
[<ffffffff8110a1ca>] mod_timer+0x12a/0x210
[<ffffffff8110a2c8>] add_timer+0x18/0x30
[<ffffffffa050810f>] dat_probe+0xbf/0x100 [xdma_v7]
[<ffffffff813f6da5>] local_pci_probe+0x45/0xa0
[<ffffffff812a8da2>] ? sysfs_do_create_link_sd.isra.2+0x72/0xc0
[<ffffffff813f8109>] pci_device_probe+0xf9/0x150
[<ffffffff814e7e59>] driver_probe_device+0x209/0x4b0
[<ffffffff814e81db>] __driver_attach+0x9b/0xa0
[<ffffffff814e8140>] ? __device_attach+0x40/0x40
[<ffffffff814e5973>] bus_for_each_dev+0x73/0xc0
[<ffffffff814e772e>] driver_attach+0x1e/0x20
[<ffffffff814e72e0>] bus_add_driver+0x180/0x250
[<ffffffffa000a000>] ? 0xffffffffa000a000
[<ffffffff814e89d4>] driver_register+0x64/0xf0
[<ffffffff813f662c>] __pci_register_driver+0x4c/0x50
[<ffffffffa000a02c>] dat_init+0x2c/0x1000 [xdma_v7]
[<ffffffff81002148>] do_one_initcall+0xd8/0x210
[<ffffffff812094f9>] ? kmem_cache_alloc_trace+0x1a9/0x230
[<ffffffff817911bc>] ? do_init_module+0x28/0x1cc
[<ffffffff817911f5>] do_init_module+0x61/0x1cc
[<ffffffff811270bb>] load_module+0x20db/0x2550
[<ffffffff81122990>] ? store_uevent+0x70/0x70
[<ffffffff8122e860>] ? kernel_read+0x50/0x80
[<ffffffff81127766>] SyS_finit_module+0xa6/0xe0
[<ffffffff8179892e>] system_call_fastpath+0x12/0x71
---[ end trace 340e5d7ba2d89082 ]---
DEBUG ADD TIMER: Value of HZ is 1000
DEBUG ADD TIMER: End of probe
The problem is that the second call to dat_probe is clobbering the poll_timer variable that was initialized and queued by the first call to dat_probe. You are clobbering the pointers in the kernel's timer list.
You need to get rid of the poll_timer variable and give each device its own dynamically allocated private data structure containing its own struct timer_list member. Call pci_set_drvdata to set the private data pointer for the PCI device. The other PCI driver functions can call pci_get_drvdata to retrieve that pointer.

LPC4357 jumping to external flash unstable

I have two programs, one is custom bootloader which will be located in BANK A and the other one is the main program which will be located in external spifi flash.
Both programs I load and debug from eclipse.
Currently I can jump from the bootloader to the main program, I can start debug with jtag from the reset handler in the main program but sometimes is continues to main and sometimes it breaks after the first step.
From the bootloader I do the following for jumping to main program:
halInit(); // init my hal functions
chSysInit(); // init my OS
chThdSleepMilliseconds(1000);
flashInit(); // init the spifi driver
uint32_t NewAddressOfNewVectorTable = 0x14000000;
__disable_irq();
/** Load new Vector Table **/
SCB->VTOR = AddressOfNewVectorTable;
__set_MSP(*(uint32_t*)(AddressOfNewVectorTable));
LPC_CREG->M4MEMMAP = AddressOfNewVectorTable;
/**
* Jump to Reset Vector of new Vector Table
* -> thats the second word (hence fourth byte).
*/
((user_code_pointer_t)(*((uint32_t*)(AddressOfNewVectorTable + 4))))();
This seems to work alright and it jumps to the 0x14000000 address.
Then when I start to debug with JTAG the app, it will come first in the reset handler.
I firstly had to disable __early_init() for the main app which configures the clocks, this would make all crash.
Is this correct?
Then sometimes I can step through all into the main() function.
But also regularly it crashes after doing the first step with JTAG with the following output:
SEGGER J-Link GDB Server V5.02l Command Line Version
JLinkARM.dll V5.02l (DLL compiled Nov 24 2015 09:36:30)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: on
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: LPC4357_M4
Target interface: SWD
Target interface speed: 1000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V9 compiled Oct 9 2015 20:34:47
Hardware: V9.30
S/N: 269301849
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.31 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
WARNING: Failed to read memory # address 0x00000000
Target interface speed set to 1000 kHz
Resetting target
Halting target CPU...
...Target halted (PC = 0x1A000140)
R0 = 1A000000, R1 = 1A000000, R2 = 400F1FC0, R3 = 12345678
R4 = 40045000, R5 = 1008000C, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 10000200, MSP= 10000200, PSP= 00000000
R14(LR) = 10405B25, R15(PC) = 1A000140
XPSR 41000000, APSR 40000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Select auto target interface speed (2000 kHz)
Flash breakpoints enabled
Semi-hosting enabled (Handle on BKPT)
Semihosting I/O set to TELNET Client
SWO disabled succesfully.
SWO enabled succesfully.
Downloading 276 bytes # address 0x14000000 - Verified OK
Downloading 16192 bytes # address 0x14000120 - Verified OK
Downloading 16080 bytes # address 0x14004060 - Verified OK
Downloading 16176 bytes # address 0x14007F30 - Verified OK
Downloading 16064 bytes # address 0x1400BE60 - Verified OK
Downloading 16096 bytes # address 0x1400FD20 - Verified OK
Downloading 16096 bytes # address 0x14013C00 - Verified OK
Downloading 16112 bytes # address 0x14017AE0 - Verified OK
Downloading 8492 bytes # address 0x1401B9D0 - Verified OK
Downloading 8 bytes # address 0x1401DAFC - Verified OK
Downloading 2308 bytes # address 0x1401DB08 - Verified OK
Comparing flash [....................] Done.
Verifying flash [....................] Done.
Writing register (PC = 0x14000120)
Read 4 bytes # address 0x14000120 (Data = 0x4100F081)
Read 2 bytes # address 0x14015764 (Data = 0x2300)
Read 2 bytes # address 0x140157C8 (Data = 0x2300)
Read 2 bytes # address 0x140166D8 (Data = 0x2300)
Read 2 bytes # address 0x140166DC (Data = 0x4818)
Read 2 bytes # address 0x14001370 (Data = 0xB672)
Read 2 bytes # address 0x140013E8 (Data = 0xF015)
Read 2 bytes # address 0x140166D8 (Data = 0x2300)
Read 2 bytes # address 0x1401670E (Data = 0xAB03)
Read 2 bytes # address 0x14001370 (Data = 0xB672)
Read 2 bytes # address 0x14001370 (Data = 0xB672)
Read 2 bytes # address 0x14016764 (Data = 0xF7EC)
Read 2 bytes # address 0x14016764 (Data = 0xF7EC)
Read 2 bytes # address 0x14001370 (Data = 0xB672)
Read 2 bytes # address 0x140013D4 (Data = 0xF7FF)
Read 2 bytes # address 0x14015764 (Data = 0x2300)
Read 2 bytes # address 0x140157BA (Data = 0x4850)
Read 2 bytes # address 0x1400ACB8 (Data = 0x4806)
Read 2 bytes # address 0x1400ACBA (Data = 0x4907)
Read 2 bytes # address 0x1400ACC4 (Data = 0x4B05)
Resetting target
Halting target CPU...
...Target halted (PC = 0x1A000140)
Read 2 bytes # address 0x14016764 (Data = 0xF7EC)
Read 2 bytes # address 0x14016764 (Data = 0xF7EC)
Read 2 bytes # address 0x14016764 (Data = 0xF7EC)
R0 = 1A000000, R1 = 1A000000, R2 = 400F1FC0, R3 = 12345678
R4 = 40045000, R5 = 1008000C, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 10000200, MSP= 10000200, PSP= 00000000
R14(LR) = 10405B25, R15(PC) = 1A000140
XPSR 41000000, APSR 40000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes # address 0x1A000140 (Data = 0x4C24B672)
Setting breakpoint # address 0x14001370, Size = 2, BPHandle = 0x0001
Setting breakpoint # address 0x140013D4, Size = 2, BPHandle = 0x0002
Setting breakpoint # address 0x140013E8, Size = 2, BPHandle = 0x0003
Setting breakpoint # address 0x1400ACC4, Size = 2, BPHandle = 0x0004
Setting breakpoint # address 0x140166DC, Size = 2, BPHandle = 0x0005
Setting breakpoint # address 0x1401670E, Size = 2, BPHandle = 0x0006
Setting breakpoint # address 0x14016764, Size = 2, BPHandle = 0x0007
Starting target CPU...
Erasing flash [....................] Done.
Programming flash [....................] Done.
Verifying flash [....................] Done.
...Breakpoint reached # address 0x14001370
Reading all registers
Removing breakpoint # address 0x14001370, Size = 2
Removing breakpoint # address 0x140013D4, Size = 2
Removing breakpoint # address 0x140013E8, Size = 2
Removing breakpoint # address 0x1400ACC4, Size = 2
Removing breakpoint # address 0x140166DC, Size = 2
Removing breakpoint # address 0x1401670E, Size = 2
Removing breakpoint # address 0x14016764, Size = 2
Read 4 bytes # address 0x14001370 (Data = 0x4C23B672)
Read 4 bytes # address 0x1A0025B4 (Data = 0xF8D39B03)
Read 4 bytes # address 0x1A0025B4 (Data = 0xF8D39B03)
Performing single step...
...Target halted (PC = 0xFFFFFFFE)
Reading all registers
WARNING: Failed to read memory # address 0xFFFFFFFE
Read 4 bytes # address 0x1000041C (Data = 0x00000000)
Reading 64 bytes # address 0x10000400
Read 4 bytes # address 0x00000000 (Data = 0x10000400)
Read 4 bytes # address 0x00000000 (Data = 0x10000400)
Am I missing something that is needed after the jump to external flash?
Or can anyone give me a pointer why this is not functioning properly all the time?

linux driver, port 2.6.19.2 - 2.6.38-rc2 ARM11 iMX31, amba MBX device LogicPD Litekit GLES driver

Code followed with question
#define MBX_REG_SYS_PHYS_BASE 0xC0000000
#define MBX_REG_RANGE 0x00004000
static struct resource mxc_reg_resources[] = {
{
.start = MBX_REG_SYS_PHYS_BASE,
.end = MBX_REG_SYS_PHYS_BASE + MBX_REG_RANGE - 1,
.flags = IORESOURCE_MEM }
};
mbx_reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mbx_reg)
return -EINVAL;
reg_base = ioremap(mbx_reg->start, resource_size(mbx_reg));
if (!reg_base) {
ret = -ENOMEM;
goto eremap;
}
printk(KERN_CRIT "Address: from 0x%08X to 0x%08X\n",
mbx_reg->start, reg_base);
regread = mx3reg_read_reg(mx3reg, MBX1_GLOBREG_REVISION);
printk(KERN_CRIT "MBX1_GLOBREG_REVISION: 0x%.8X\n", regread);
This code works on iMX31 from LogicPD using 2.6.19.2 with out of tree patching from freescale.
when porting it to 2.6.38-rc2 it no longer works.
here are some data results:
Working results:
Address: 0xC7860000
MBX1_GLOBREG_REVISION: 0x01010200
Failed results:
Address: 0xC48A0000
MBX1_GLOBREG_REVISION: 0x00000000
Address: 0xC48A8000
MBX1_GLOBREG_REVISION: 0x00000000
Address: 0xC48B8000
MBX1_GLOBREG_REVISION: 0x00000000
Address: 0xC48C0000
MBX1_GLOBREG_REVISION: 0x00000000
maybe interesting is on 2.6.19.2 it always gets the same address mapped
yet in 2.6.38-rc2 it does not.
Are you sure your defines are still good ? The output for this line should not change :
printk(KERN_CRIT "Address: from 0x%08X to 0x%08X\n",
mbx_reg->start, reg_base);
Since it is a physical address. However it is not printed in your output.
Check the pripheral you are accessing is clocked.
In order to have this device ready to communicate you need to setup the peripheral port remap register
/* Setup Peripheral Port Remap register for AVIC */
asm("ldr r0, =0xC0000015 \n\
mcr p15, 0, r0, c15, c2, 4");
here is the code from the original 2.6.19.2 kernel, executed from a board fixup routine.
and of course the clocks would have to be enabled as well, and this driver example is not showing that either.

Resources