[Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[at91_enthus]

[-- Attachment #1.1: Type: text/plain, Size: 486 bytes --]

Hi.

In order to get better accuracy with Xenomai, I modified the I-pipe timebase
(MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
Unfortunately, I cannot mount the rootfs on the MMC, since the MMC
controller is no longer functioning. I tried to change TCx in kernel
configuration to no avail.
When I switch back to a timebase of 1 MHz, the MMC works fine.


Here's the configuration of my system:
Proc: AR91SAM9G20
Kernel: 2.6.33-5 (config attached)
Xenomai: 2.5.5.2

Thanks,
R.

[-- Attachment #1.2: Type: text/html, Size: 540 bytes --]

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 29603 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.33.5
# Wed Feb  2 14:10:19 2011
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION="-xen"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TREE_PREEMPT_RCU is not set
# CONFIG_TINY_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_GROUP_SCHED is not set
# CONFIG_CGROUPS is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y

#
# Kernel Performance Events And Counters
#
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_CLK=y

#
# GCOV-based kernel profiling
#
# CONFIG_SLOW_WORK is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_INLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set

#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
CONFIG_XENO_OPT_PRIOCPL=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_SCHED_CLASSES=y
CONFIG_XENO_OPT_SCHED_TP=y
CONFIG_XENO_OPT_SCHED_TP_NRPART=4
CONFIG_XENO_OPT_SCHED_SPORADIC=y
CONFIG_XENO_OPT_SCHED_SPORADIC_MAXREPL=8
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=256
CONFIG_XENO_OPT_SYS_STACKPOOLSZ=128
CONFIG_XENO_OPT_SEM_HEAPSZ=12
CONFIG_XENO_OPT_GLOBAL_SEM_HEAPSZ=12
CONFIG_XENO_OPT_STATS=y
# CONFIG_XENO_OPT_DEBUG is not set
CONFIG_XENO_OPT_SHIRQ=y

#
# Timing
#
CONFIG_XENO_OPT_TIMING_PERIODIC=y
CONFIG_XENO_OPT_TIMING_VIRTICK=1000
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0

#
# Scalability
#
CONFIG_XENO_OPT_SCALABLE_SCHED=y
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set

#
# Machine
#
CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=y
CONFIG_XENO_HW_FPU=y
CONFIG_XENO_HW_UNLOCKED_SWITCH=y

#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_BUFFER=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
# CONFIG_XENO_OPT_POSIX_SELECT is not set
# CONFIG_XENO_OPT_DEBUG_POSIX is not set
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_SKIN_RTAI is not set
# CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
# CONFIG_XENO_OPT_RTDM_SELECT is not set

#
# Drivers
#

#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set

#
# Testing drivers
#
# CONFIG_XENO_DRIVERS_TESTING_LEGACY_NAMES is not set
CONFIG_XENO_DRIVERS_TIMERBENCH=y
# CONFIG_XENO_DRIVERS_KLATENCY is not set
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
CONFIG_XENO_DRIVERS_SWITCHTEST=y
# CONFIG_XENO_DRIVERS_SIGTEST is not set
# CONFIG_XENO_DRIVERS_RTDMTEST is not set

#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set

#
# ANALOGY drivers
#
# CONFIG_XENO_DRIVERS_ANALOGY is not set

#
# Real-time IPC drivers
#
# CONFIG_XENO_DRIVERS_RTIPC is not set
# CONFIG_FREEZER is not set

#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
CONFIG_ARCH_AT91=y
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_STMP3XXX is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_LOKI is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5PC1XX is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_ARCH_BCMRING is not set
# CONFIG_ARCH_U8500 is not set
CONFIG_HAVE_AT91_USART3=y
CONFIG_HAVE_AT91_USART4=y
CONFIG_HAVE_AT91_USART5=y

#
# Atmel AT91 System-on-Chip
#
# CONFIG_ARCH_AT91RM9200 is not set
# CONFIG_ARCH_AT91SAM9260 is not set
# CONFIG_ARCH_AT91SAM9261 is not set
# CONFIG_ARCH_AT91SAM9G10 is not set
# CONFIG_ARCH_AT91SAM9263 is not set
# CONFIG_ARCH_AT91SAM9RL is not set
CONFIG_ARCH_AT91SAM9G20=y
# CONFIG_ARCH_AT91SAM9G45 is not set
# CONFIG_ARCH_AT91CAP9 is not set
# CONFIG_ARCH_AT572D940HF is not set
# CONFIG_ARCH_AT91X40 is not set
CONFIG_AT91_PMC_UNIT=y

#
# AT91SAM9G20 Board Type
#
# CONFIG_MACH_AT91SAM9G20EK is not set
# CONFIG_MACH_AT91SAM9G20EK_2MMC is not set
# CONFIG_MACH_CPU9G20 is not set
# CONFIG_MACH_USB_A9G20 is not set
# CONFIG_MACH_QIL_A9G20 is not set
# CONFIG_MACH_SBC35_A9G20 is not set
CONFIG_MACH_ELECTRUM_100=y

#
# Adeos I-pipe Options
#
CONFIG_IPIPE_AT91_TC=1

#
# AT91 Board Options
#

#
# AT91 Feature Selections
#
CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
CONFIG_AT91_TIMER_HZ=1000
# CONFIG_AT91_EARLY_DBGU is not set
CONFIG_AT91_EARLY_USART0=y
# CONFIG_AT91_EARLY_USART1 is not set
# CONFIG_AT91_EARLY_USART2 is not set
# CONFIG_AT91_EARLY_USART3 is not set
# CONFIG_AT91_EARLY_USART4 is not set
# CONFIG_AT91_EARLY_USART5 is not set
CONFIG_IPIPE_ARM_KUSER_TSC=y

#
# Processor Type
#
CONFIG_CPU_ARM926T=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5TJ=y
CONFIG_CPU_PABRT_LEGACY=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_COPY_V4WB=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_THUMB is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
CONFIG_CPU_CACHE_ROUND_ROBIN=y
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_FCSE=y
CONFIG_ARM_FCSE_GUARANTEED=y
# CONFIG_ARM_FCSE_BEST_EFFORT is not set
CONFIG_ARM_FCSE_PREEMPT_FLUSH=y
CONFIG_ARM_FCSE_MESSAGES=y
CONFIG_ARM_FCSE_DEBUG=y

#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_IPIPE=y
CONFIG_IPIPE_DOMAINS=4
CONFIG_IPIPE_DELAYED_ATOMICSW=y
# CONFIG_IPIPE_UNMASKED_CONTEXT_SWITCH is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=1000
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
# CONFIG_HIGHMEM is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_LEDS is not set
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set

#
# Boot options
#
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="mem=64M console=ttyS0,115200"
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set

#
# CPU Power Management
#
# CONFIG_CPU_IDLE is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
# CONFIG_VFP is not set

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Power management options
#
# CONFIG_PM is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_TESTS is not set
CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_MTD_OOPS is not set

#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_SMC is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_ATMEL_ECC_SOFT=y
# CONFIG_MTD_NAND_ATMEL_ECC_HW is not set
# CONFIG_MTD_NAND_ATMEL_ECC_NONE is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set

#
# UBI - Unsorted block images
#
# CONFIG_MTD_UBI is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
CONFIG_MISC_DEVICES=y
CONFIG_ATMEL_TCLIB=y
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_IWMC3200TOP is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_MACB=y
# CONFIG_AX88796 is not set
# CONFIG_SMC91X is not set
# CONFIG_DM9000 is not set
# CONFIG_ETHOC is not set
# CONFIG_SMC911X is not set
# CONFIG_SMSC911X is not set
# CONFIG_DNET is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_B44 is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=320
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=240
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_DEVKMEM is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_ATMEL=y
CONFIG_SERIAL_ATMEL_CONSOLE=y
CONFIG_SERIAL_ATMEL_PDC=y
# CONFIG_SERIAL_ATMEL_TTYAT is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set
# CONFIG_SPI is not set

#
# PPS support
#
# CONFIG_PPS is not set
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
# CONFIG_GPIO_SYSFS is not set

#
# Memory mapped GPIO expanders:
#

#
# I2C GPIO expanders:
#

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#

#
# AC97 GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
CONFIG_MMC_TEST=y

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
CONFIG_MMC_AT91=y
# CONFIG_MMC_ATMELMCI is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
CONFIG_RTC_DRV_AT91SAM9=y
CONFIG_RTC_DRV_AT91SAM9_RTT=0
CONFIG_RTC_DRV_AT91SAM9_GPBR=0
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# TI VLYNQ
#
# CONFIG_STAGING is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FILE_LOCKING=y
# CONFIG_FSNOTIFY is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY is not set
# CONFIG_INOTIFY_USER is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=y
# CONFIG_CUSE is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
# CONFIG_MISC_FILESYSTEMS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_IPIPE_DEBUG is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
# CONFIG_OC_ETM is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_DEFAULT_SECURITY_SELINUX is not set
# CONFIG_DEFAULT_SECURITY_SMACK is not set
# CONFIG_DEFAULT_SECURITY_TOMOYO is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_AUTHENC=y
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=y

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_PCBC=y
CONFIG_CRYPTO_XTS=y

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
# CONFIG_CRYPTO_HW is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_LAST_BIT=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Gilles Chanteperdrix]

at91_enthus wrote:
> Hi.
> 
> In order to get better accuracy with Xenomai, I modified the I-pipe
> timebase (MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
> Unfortunately, I cannot mount the rootfs on the MMC, since the MMC
> controller is no longer functioning. I tried to change TCx in kernel
> configuration to no avail.
> When I switch back to a timebase of 1 MHz, the MMC works fine.

The thing is that we are a bit tight on AT91. A 16 bits counter is used
for both the timer and the tsc emulation, and this tsc must be refreshed
at least once before it wraps. The problem is that since it is a 16 bits
counter, it wraps really fast, on my AT91SAM9263 it wraps in 20 ms, and
since the Linux default period is 10ms we are actually quite close to
the limit.

Anyway, trying to get a better accuracy than 1us is kind of useless on
AT91, since even reading this counter takes more than 1us. So, you are
not in fact improving anything. The 1MHz is even a bit overkill.

-- 
                                                                Gilles.

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[at91_enthus]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> at91_enthus wrote:
> > Hi.
> >
> > In order to get better accuracy with Xenomai, I modified the I-pipe
> > timebase (MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
> > Unfortunately, I cannot mount the rootfs on the MMC, since the MMC
> > controller is no longer functioning. I tried to change TCx in kernel
> > configuration to no avail.
> > When I switch back to a timebase of 1 MHz, the MMC works fine.
>
> The thing is that we are a bit tight on AT91. A 16 bits counter is used
> for both the timer and the tsc emulation, and this tsc must be refreshed
> at least once before it wraps. The problem is that since it is a 16 bits
> counter, it wraps really fast, on my AT91SAM9263 it wraps in 20 ms, and
> since the Linux default period is 10ms we are actually quite close to
> the limit.
>
> Anyway, trying to get a better accuracy than 1us is kind of useless on
> AT91, since even reading this counter takes more than 1us. So, you are
> not in fact improving anything. The 1MHz is even a bit overkill.
>
> --
>                                                                 Gilles.
>


Thank you.

[-- Attachment #2: Type: text/html, Size: 1641 bytes --]

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Gilles Chanteperdrix]

at91_enthus wrote:
> 
> 
> On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org
> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
> 
>     at91_enthus wrote:
>     > Hi.
>     >
>     > In order to get better accuracy with Xenomai, I modified the I-pipe
>     > timebase (MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
>     > Unfortunately, I cannot mount the rootfs on the MMC, since the MMC
>     > controller is no longer functioning. I tried to change TCx in kernel
>     > configuration to no avail.
>     > When I switch back to a timebase of 1 MHz, the MMC works fine.
> 
>     The thing is that we are a bit tight on AT91. A 16 bits counter is used
>     for both the timer and the tsc emulation, and this tsc must be refreshed
>     at least once before it wraps. The problem is that since it is a 16 bits
>     counter, it wraps really fast, on my AT91SAM9263 it wraps in 20 ms, and
>     since the Linux default period is 10ms we are actually quite close to
>     the limit.
> 
>     Anyway, trying to get a better accuracy than 1us is kind of useless on
>     AT91, since even reading this counter takes more than 1us. So, you are
>     not in fact improving anything. The 1MHz is even a bit overkill.

On the other hand, the AT91SAM9G20 may be running at a better frequency.
But with latencies in the order of tens of microseconds, having a better
accuracy than 1us still does not make really much sense. Why do you need
this accuracy?

-- 
                                                                Gilles.

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[at91_enthus]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

On Wed, Feb 2, 2011 at 4:09 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> at91_enthus wrote:
> >
> >
> > On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix
> > <gilles.chanteperdrix@xenomai.org
> > <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
> >
> >     at91_enthus wrote:
> >     > Hi.
> >     >
> >     > In order to get better accuracy with Xenomai, I modified the I-pipe
> >     > timebase (MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
> >     > Unfortunately, I cannot mount the rootfs on the MMC, since the MMC
> >     > controller is no longer functioning. I tried to change TCx in
> kernel
> >     > configuration to no avail.
> >     > When I switch back to a timebase of 1 MHz, the MMC works fine.
> >
> >     The thing is that we are a bit tight on AT91. A 16 bits counter is
> used
> >     for both the timer and the tsc emulation, and this tsc must be
> refreshed
> >     at least once before it wraps. The problem is that since it is a 16
> bits
> >     counter, it wraps really fast, on my AT91SAM9263 it wraps in 20 ms,
> and
> >     since the Linux default period is 10ms we are actually quite close to
> >     the limit.
> >
> >     Anyway, trying to get a better accuracy than 1us is kind of useless
> on
> >     AT91, since even reading this counter takes more than 1us. So, you
> are
> >     not in fact improving anything. The 1MHz is even a bit overkill.
>
> On the other hand, the AT91SAM9G20 may be running at a better frequency.
> But with latencies in the order of tens of microseconds, having a better
> accuracy than 1us still does not make really much sense.




> Why do you need
> this accuracy?
>

I want to time stamp the samples from a 8 channel SPI-based ADC. I know that
a conversion takes between 3 and 5 microseconds depending on the SPI clock.
What I want is to adapt the code to acquire a fixed number of samples in
user space (I knew it was a long shot). Plain, Xenomai-free, userland
application was out of the question, so I figured that a userspace
application in Xenomai run at highest priority should do the trick.

On a second thought, a simple linux kernel module is what I want (this way I
can use interrupts and one of the platform's six timers).

R.

[-- Attachment #2: Type: text/html, Size: 3084 bytes --]

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Gilles Chanteperdrix]

at91_enthus wrote:
> On Wed, Feb 2, 2011 at 4:09 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> at91_enthus wrote:
>>>
>>> On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org
>>> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
>>>
>>>     at91_enthus wrote:
>>>     > Hi.
>>>     >
>>>     > In order to get better accuracy with Xenomai, I modified the I-pipe
>>>     > timebase (MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
>>>     > Unfortunately, I cannot mount the rootfs on the MMC, since the MMC
>>>     > controller is no longer functioning. I tried to change TCx in
>> kernel
>>>     > configuration to no avail.
>>>     > When I switch back to a timebase of 1 MHz, the MMC works fine.
>>>
>>>     The thing is that we are a bit tight on AT91. A 16 bits counter is
>> used
>>>     for both the timer and the tsc emulation, and this tsc must be
>> refreshed
>>>     at least once before it wraps. The problem is that since it is a 16
>> bits
>>>     counter, it wraps really fast, on my AT91SAM9263 it wraps in 20 ms,
>> and
>>>     since the Linux default period is 10ms we are actually quite close to
>>>     the limit.
>>>
>>>     Anyway, trying to get a better accuracy than 1us is kind of useless
>> on
>>>     AT91, since even reading this counter takes more than 1us. So, you
>> are
>>>     not in fact improving anything. The 1MHz is even a bit overkill.
>> On the other hand, the AT91SAM9G20 may be running at a better frequency.
>> But with latencies in the order of tens of microseconds, having a better
>> accuracy than 1us still does not make really much sense.
> 
> 
> 
> 
>> Why do you need
>> this accuracy?
>>
> 
> I want to time stamp the samples from a 8 channel SPI-based ADC. I know that
> a conversion takes between 3 and 5 microseconds depending on the SPI clock.
> What I want is to adapt the code to acquire a fixed number of samples in
> user space (I knew it was a long shot). Plain, Xenomai-free, userland
> application was out of the question, so I figured that a userspace
> application in Xenomai run at highest priority should do the trick.
> 
> On a second thought, a simple linux kernel module is what I want (this way I
> can use interrupts and one of the platform's six timers).

You can use interrupts and the platform's six timers in a Xenomai driver
based on the RTDM skin. The thing is, what interrupt latency is your target?

-- 
					    Gilles.

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> at91_enthus wrote:
>> On Wed, Feb 2, 2011 at 4:09 PM, Gilles Chanteperdrix <
>> gilles.chanteperdrix@xenomai.org> wrote:
>>
>>> at91_enthus wrote:
>>>> On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix
>>>> <gilles.chanteperdrix@xenomai.org
>>>> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
>>>>
>>>>     at91_enthus wrote:
>>>>     > Hi.
>>>>     >
>>>>     > In order to get better accuracy with Xenomai, I modified the I-pipe
>>>>     > timebase (MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
>>>>     > Unfortunately, I cannot mount the rootfs on the MMC, since the MMC
>>>>     > controller is no longer functioning. I tried to change TCx in
>>> kernel
>>>>     > configuration to no avail.
>>>>     > When I switch back to a timebase of 1 MHz, the MMC works fine.
>>>>
>>>>     The thing is that we are a bit tight on AT91. A 16 bits counter is
>>> used
>>>>     for both the timer and the tsc emulation, and this tsc must be
>>> refreshed
>>>>     at least once before it wraps. The problem is that since it is a 16
>>> bits
>>>>     counter, it wraps really fast, on my AT91SAM9263 it wraps in 20 ms,
>>> and
>>>>     since the Linux default period is 10ms we are actually quite close to
>>>>     the limit.
>>>>
>>>>     Anyway, trying to get a better accuracy than 1us is kind of useless
>>> on
>>>>     AT91, since even reading this counter takes more than 1us. So, you
>>> are
>>>>     not in fact improving anything. The 1MHz is even a bit overkill.
>>> On the other hand, the AT91SAM9G20 may be running at a better frequency.
>>> But with latencies in the order of tens of microseconds, having a better
>>> accuracy than 1us still does not make really much sense.
>>
>>
>>
>>> Why do you need
>>> this accuracy?
>>>
>> I want to time stamp the samples from a 8 channel SPI-based ADC. I know that
>> a conversion takes between 3 and 5 microseconds depending on the SPI clock.
>> What I want is to adapt the code to acquire a fixed numb

er of samples in
>> user space (I knew it was a long shot). Plain, Xenomai-free, userland
>> application was out of the question, so I figured that a userspace
>> application in Xenomai run at highest priority should doand the trick.
>>
>> On a second thought, a simple linux kernel module is what I want (this way I
>> can use interrupts and one of the platform's six timers).
> 
> You can use interrupts and the platform's six timers in a Xenomai driver
> based on the RTDM skin. The thing is, what interrupt latency is your target?
> 

To make myself clear:
you got:
- the AD conversion (amounts for an unknown amount of time between 3 and
5us)
- the SPI interrupt
- some unknown interrupt latency which amouunts to several tens of
microseconds with Xenomai, and to a few hundreds of microseconds with Linux.
- the interrupt handler is invoked.

What good will it make to have a timestamping precision with a
sub-microsecond range in the interrupt handler code?

-- 
					    Gilles.

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[at91_enthus]

[-- Attachment #1: Type: text/plain, Size: 4090 bytes --]

On Thu, Feb 3, 2011 at 4:28 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Gilles Chanteperdrix wrote:
> > at91_enthus wrote:
> >> On Wed, Feb 2, 2011 at 4:09 PM, Gilles Chanteperdrix <
> >> gilles.chanteperdrix@xenomai.org> wrote:
> >>
> >>> at91_enthus wrote:
> >>>> On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix
> >>>> <gilles.chanteperdrix@xenomai.org
> >>>> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
> >>>>
> >>>>     at91_enthus wrote:
> >>>>     > Hi.
> >>>>     >
> >>>>     > In order to get better accuracy with Xenomai, I modified the
> I-pipe
> >>>>     > timebase (MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
> >>>>     > Unfortunately, I cannot mount the rootfs on the MMC, since the
> MMC
> >>>>     > controller is no longer functioning. I tried to change TCx in
> >>> kernel
> >>>>     > configuration to no avail.
> >>>>     > When I switch back to a timebase of 1 MHz, the MMC works fine.
> >>>>
> >>>>     The thing is that we are a bit tight on AT91. A 16 bits counter is
> >>> used
> >>>>     for both the timer and the tsc emulation, and this tsc must be
> >>> refreshed
> >>>>     at least once before it wraps. The problem is that since it is a
> 16
> >>> bits
> >>>>     counter, it wraps really fast, on my AT91SAM9263 it wraps in 20
> ms,
> >>> and
> >>>>     since the Linux default period is 10ms we are actually quite close
> to
> >>>>     the limit.
> >>>>
> >>>>     Anyway, trying to get a better accuracy than 1us is kind of
> useless
> >>> on
> >>>>     AT91, since even reading this counter takes more than 1us. So, you
> >>> are
> >>>>     not in fact improving anything. The 1MHz is even a bit overkill.
> >>> On the other hand, the AT91SAM9G20 may be running at a better
> frequency.
> >>> But with latencies in the order of tens of microseconds, having a
> better
> >>> accuracy than 1us still does not make really much sense.
> >>
> >>
> >>
> >>> Why do you need
> >>> this accuracy?
> >>>
> >> I want to time stamp the samples from a 8 channel SPI-based ADC. I know
> that
> >> a conversion takes between 3 and 5 microseconds depending on the SPI
> clock.
> >> What I want is to adapt the code to acquire a fixed numb
>
> er of samples in
> >> user space (I knew it was a long shot). Plain, Xenomai-free, userland
> >> application was out of the question, so I figured that a userspace
> >> application in Xenomai run at highest priority should doand the trick.
> >>
> >> On a second thought, a simple linux kernel module is what I want (this
> way I
> >> can use interrupts and one of the platform's six timers).
> >
> > You can use interrupts and the platform's six timers in a Xenomai driver
> > based on the RTDM skin. The thing is, what interrupt latency is your
> target?
> >
>
> To make myself clear:
> you got:
> - the AD conversion (amounts for an unknown amount of time between 3 and
> 5us)
> - the SPI interrupt
> - some unknown interrupt latency which amouunts to several tens of
> microseconds with Xenomai, and to a few hundreds of microseconds with
> Linux.
> - the interrupt handler is invoked.
>

What good will it make to have a timestamping precision with a
> sub-microsecond range in the interrupt handler code?
>
> --
>                                             Gilles.
>

Rookie mistake. Indeed, I can have everything in userspace using Xenomai. I
wrote a simple program that did a periodic job every 100 us and the jitter
was very small (around 20 us without load and around 35 us with SSH-ing and
Xenomai compilation running on board).

Somewhat unrelated to this thread, I found that when I invoked
rt_task_set_periodic(), I got very precise timings (as expected). However,
when I tried to insert small delays using rt_timer_spin(), the errors
(t_meas - t_spin_func_argument) were not large, but noticeable. For example,
I can precisely measure a 50 us periodic task on the scope. With the same
interval in rt_timer_spin(), I get 55-60 us. As far as I understood, all
timing-related functions use the same time base, so what's the reason for
this behavior?


Regards,
R.

[-- Attachment #2: Type: text/html, Size: 5577 bytes --]

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Gilles Chanteperdrix]

at91_enthus wrote:
> On Thu, Feb 3, 2011 at 4:28 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> Gilles Chanteperdrix wrote:
>>> at91_enthus wrote:
>>>> On Wed, Feb 2, 2011 at 4:09 PM, Gilles Chanteperdrix <
>>>> gilles.chanteperdrix@xenomai.org> wrote:
>>>>
>>>>> at91_enthus wrote:
>>>>>> On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix
>>>>>> <gilles.chanteperdrix@xenomai.org
>>>>>> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
>>>>>>
>>>>>>     at91_enthus wrote:
>>>>>>     > Hi.
>>>>>>     >
>>>>>>     > In order to get better accuracy with Xenomai, I modified the
>> I-pipe
>>>>>>     > timebase (MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
>>>>>>     > Unfortunately, I cannot mount the rootfs on the MMC, since the
>> MMC
>>>>>>     > controller is no longer functioning. I tried to change TCx in
>>>>> kernel
>>>>>>     > configuration to no avail.
>>>>>>     > When I switch back to a timebase of 1 MHz, the MMC works fine.
>>>>>>
>>>>>>     The thing is that we are a bit tight on AT91. A 16 bits counter is
>>>>> used
>>>>>>     for both the timer and the tsc emulation, and this tsc must be
>>>>> refreshed
>>>>>>     at least once before it wraps. The problem is that since it is a
>> 16
>>>>> bits
>>>>>>     counter, it wraps really fast, on my AT91SAM9263 it wraps in 20
>> ms,
>>>>> and
>>>>>>     since the Linux default period is 10ms we are actually quite close
>> to
>>>>>>     the limit.
>>>>>>
>>>>>>     Anyway, trying to get a better accuracy than 1us is kind of
>> useless
>>>>> on
>>>>>>     AT91, since even reading this counter takes more than 1us. So, you
>>>>> are
>>>>>>     not in fact improving anything. The 1MHz is even a bit overkill.
>>>>> On the other hand, the AT91SAM9G20 may be running at a better
>> frequency.
>>>>> But with latencies in the order of tens of microseconds, having a
>> better
>>>>> accuracy than 1us still does not make really much sense.
>>>>
>>>>
>>>>> Why do you need
>>>>> this accuracy?
>>>>>
>>>> I want to time stamp the samples from a 8 channel SPI-based ADC. I know
>> that
>>>> a conversion takes between 3 and 5 microseconds depending on the SPI
>> clock.
>>>> What I want is to adapt the code to acquire a fixed numb
>> er of samples in
>>>> user space (I knew it was a long shot). Plain, Xenomai-free, userland
>>>> application was out of the question, so I figured that a userspace
>>>> application in Xenomai run at highest priority should doand the trick.
>>>>
>>>> On a second thought, a simple linux kernel module is what I want (this
>> way I
>>>> can use interrupts and one of the platform's six timers).
>>> You can use interrupts and the platform's six timers in a Xenomai driver
>>> based on the RTDM skin. The thing is, what interrupt latency is your
>> target?
>> To make myself clear:
>> you got:
>> - the AD conversion (amounts for an unknown amount of time between 3 and
>> 5us)
>> - the SPI interrupt
>> - some unknown interrupt latency which amouunts to several tens of
>> microseconds with Xenomai, and to a few hundreds of microseconds with
>> Linux.
>> - the interrupt handler is invoked.
>>
> 
> What good will it make to have a timestamping precision with a
>> sub-microsecond range in the interrupt handler code?
>>
>> --
>>                                             Gilles.
>>
> 
> Rookie mistake. Indeed, I can have everything in userspace using Xenomai. I
> wrote a simple program that did a periodic job every 100 us and the jitter
> was very small (around 20 us without load and around 35 us with SSH-ing and
> Xenomai compilation running on board).
> 
> Somewhat unrelated to this thread, I found that when I invoked
> rt_task_set_periodic(), I got very precise timings (as expected). However,
> when I tried to insert small delays using rt_timer_spin(), the errors
> (t_meas - t_spin_func_argument) were not large, but noticeable. For example,
> I can precisely measure a 50 us periodic task on the scope. With the same
> interval in rt_timer_spin(), I get 55-60 us. As far as I understood, all
> timing-related functions use the same time base, so what's the reason for
> this behavior?

Where do you use rt_timer_spin, in kernel-space, or in user-space? How
long do you spin?


> 
> 
> Regards,
> R.
> 


-- 
                                                                Gilles.

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[at91_enthus]

[-- Attachment #1: Type: text/plain, Size: 4606 bytes --]

On Fri, Feb 4, 2011 at 4:34 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> at91_enthus wrote:
> > On Thu, Feb 3, 2011 at 4:28 AM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> >> Gilles Chanteperdrix wrote:
> >>> at91_enthus wrote:
> >>>> On Wed, Feb 2, 2011 at 4:09 PM, Gilles Chanteperdrix <
> >>>> gilles.chanteperdrix@xenomai.org> wrote:
> >>>>
> >>>>> at91_enthus wrote:
> >>>>>> On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix
> >>>>>> <gilles.chanteperdrix@xenomai.org
> >>>>>> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
> >>>>>>
> >>>>>>     at91_enthus wrote:
> >>>>>>     > Hi.
> >>>>>>     >
> >>>>>>     > In order to get better accuracy with Xenomai, I modified the
> >> I-pipe
> >>>>>>     > timebase (MCK divider) in
> arch/arm.mach-at91/at91_ipipe_time.c.
> >>>>>>     > Unfortunately, I cannot mount the rootfs on the MMC, since the
> >> MMC
> >>>>>>     > controller is no longer functioning. I tried to change TCx in
> >>>>> kernel
> >>>>>>     > configuration to no avail.
> >>>>>>     > When I switch back to a timebase of 1 MHz, the MMC works fine.
> >>>>>>
> >>>>>>     The thing is that we are a bit tight on AT91. A 16 bits counter
> is
> >>>>> used
> >>>>>>     for both the timer and the tsc emulation, and this tsc must be
> >>>>> refreshed
> >>>>>>     at least once before it wraps. The problem is that since it is a
> >> 16
> >>>>> bits
> >>>>>>     counter, it wraps really fast, on my AT91SAM9263 it wraps in 20
> >> ms,
> >>>>> and
> >>>>>>     since the Linux default period is 10ms we are actually quite
> close
> >> to
> >>>>>>     the limit.
> >>>>>>
> >>>>>>     Anyway, trying to get a better accuracy than 1us is kind of
> >> useless
> >>>>> on
> >>>>>>     AT91, since even reading this counter takes more than 1us. So,
> you
> >>>>> are
> >>>>>>     not in fact improving anything. The 1MHz is even a bit overkill.
> >>>>> On the other hand, the AT91SAM9G20 may be running at a better
> >> frequency.
> >>>>> But with latencies in the order of tens of microseconds, having a
> >> better
> >>>>> accuracy than 1us still does not make really much sense.
> >>>>
> >>>>
> >>>>> Why do you need
> >>>>> this accuracy?
> >>>>>
> >>>> I want to time stamp the samples from a 8 channel SPI-based ADC. I
> know
> >> that
> >>>> a conversion takes between 3 and 5 microseconds depending on the SPI
> >> clock.
> >>>> What I want is to adapt the code to acquire a fixed numb
> >> er of samples in
> >>>> user space (I knew it was a long shot). Plain, Xenomai-free, userland
> >>>> application was out of the question, so I figured that a userspace
> >>>> application in Xenomai run at highest priority should doand the trick.
> >>>>
> >>>> On a second thought, a simple linux kernel module is what I want (this
> >> way I
> >>>> can use interrupts and one of the platform's six timers).
> >>> You can use interrupts and the platform's six timers in a Xenomai
> driver
> >>> based on the RTDM skin. The thing is, what interrupt latency is your
> >> target?
> >> To make myself clear:
> >> you got:
> >> - the AD conversion (amounts for an unknown amount of time between 3 and
> >> 5us)
> >> - the SPI interrupt
> >> - some unknown interrupt latency which amouunts to several tens of
> >> microseconds with Xenomai, and to a few hundreds of microseconds with
> >> Linux.
> >> - the interrupt handler is invoked.
> >>
> >
> > What good will it make to have a timestamping precision with a
> >> sub-microsecond range in the interrupt handler code?
> >>
> >> --
> >>                                             Gilles.
> >>
> >
> > Rookie mistake. Indeed, I can have everything in userspace using Xenomai.
> I
> > wrote a simple program that did a periodic job every 100 us and the
> jitter
> > was very small (around 20 us without load and around 35 us with SSH-ing
> and
> > Xenomai compilation running on board).
> >
> > Somewhat unrelated to this thread, I found that when I invoked
> > rt_task_set_periodic(), I got very precise timings (as expected).
> However,
> > when I tried to insert small delays using rt_timer_spin(), the errors
> > (t_meas - t_spin_func_argument) were not large, but noticeable. For
> example,
> > I can precisely measure a 50 us periodic task on the scope. With the same
> > interval in rt_timer_spin(), I get 55-60 us. As far as I understood, all
> > timing-related functions use the same time base, so what's the reason for
> > this behavior?
>
>

Where do you use rt_timer_spin, in kernel-space, or in user-space?


User space.


> How
> long do you spin?
>
>
50000 nsec.


R.

>

[-- Attachment #2: Type: text/html, Size: 6981 bytes --]

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Gilles Chanteperdrix]

at91_enthus wrote:
>>> Rookie mistake. Indeed, I can have everything in userspace using Xenomai.
>> I

Or in kernel-space... with Xenomai RTDM skin.

>>> wrote a simple program that did a periodic job every 100 us and the
>> jitter
>>> was very small (around 20 us without load and around 35 us with SSH-ing
>> and
>>> Xenomai compilation running on board).

Well, as we often say, benchmarking requires making more than that to
load the board, and for a long time.

>>>
>>> Somewhat unrelated to this thread, I found that when I invoked
>>> rt_task_set_periodic(), I got very precise timings (as expected).
>> However,
>>> when I tried to insert small delays using rt_timer_spin(), the errors
>>> (t_meas - t_spin_func_argument) were not large, but noticeable. For
>> example,
>>> I can precisely measure a 50 us periodic task on the scope. With the same
>>> interval in rt_timer_spin(), I get 55-60 us. As far as I understood, all
>>> timing-related functions use the same time base, so what's the reason for
>>> this behavior?
>>

Well, rt_task_set_periodic gets the hardware timer to tick exactly every
50us. So, whatever time it takes between the return of the call to
rt_task_wait_period() to the entry of the next is irrelevant. And
particularily, the jitter will not matter as long as it is smaller than 50u.

On the other hand, doing:

for(;;) {
	/* Do something */
	rt_timer_spin(50000);
}

The period of the loop will be 50us + rt_timer_spin jitter + time to "do
something". And so, will not even be constant.
You are not creating a periodic task. Besides, the system will not
execute anything else in user-space than your real-time task, and in
particular, the Linux will never run. Except of course if "do something"
contains a call to some secondary domain function, in which case, your
real-time task no longer is real-time.

So, that is not the correct way to get a periodic task.

-- 
                                                                Gilles.

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[at91_enthus]

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

On Sat, Feb 5, 2011 at 9:39 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> at91_enthus wrote:
> >>> Rookie mistake. Indeed, I can have everything in userspace using
> Xenomai.
> >> I
>
> Or in kernel-space... with Xenomai RTDM skin.
>
> >>> wrote a simple program that did a periodic job every 100 us and the
> >> jitter
> >>> was very small (around 20 us without load and around 35 us with SSH-ing
> >> and
> >>> Xenomai compilation running on board).
>
> Well, as we often say, benchmarking requires making more than that to
> load the board, and for a long time.
>
> >>>
> >>> Somewhat unrelated to this thread, I found that when I invoked
> >>> rt_task_set_periodic(), I got very precise timings (as expected).
> >> However,
> >>> when I tried to insert small delays using rt_timer_spin(), the errors
> >>> (t_meas - t_spin_func_argument) were not large, but noticeable. For
> >> example,
> >>> I can precisely measure a 50 us periodic task on the scope. With the
> same
> >>> interval in rt_timer_spin(), I get 55-60 us. As far as I understood,
> all
> >>> timing-related functions use the same time base, so what's the reason
> for
> >>> this behavior?
> >>
>
> Well, rt_task_set_periodic gets the hardware timer to tick exactly every
> 50us. So, whatever time it takes between the return of the call to
> rt_task_wait_period() to the entry of the next is irrelevant. And
> particularily, the jitter will not matter as long as it is smaller than
> 50u.
>
> On the other hand, doing:
>
> for(;;) {
>        /* Do something */
>        rt_timer_spin(50000);
> }
>
> The period of the loop will be 50us + rt_timer_spin jitter + time to "do
> something". And so, will not even be constant.
> You are not creating a periodic task. Besides, the system will not
> execute anything else in user-space than your real-time task, and in
> particular, the Linux will never run. Except of course if "do something"
> contains a call to some secondary domain function, in which case, your
> real-time task no longer is real-time.
>
> So, that is not the correct way to get a periodic task.
>
> --
>                                                                 Gilles.
>

Actually, the rt_timer_spin was included in this function that is run as a
real time task:

void spin(){

    rt_task_set_periodic(&spin_task,TM_NOW, 100000);

    while(1){

    *((unsigned int *) (piob_base + (PIO_SODR))) = 1<<0;

     rt_task_wait_period(NULL);

     *((unsigned int *) (piob_base + (PIO_CODR))) = 1<<0;

     rt_timer_spin(50000);

  }

I decided to go for simple GPIOs manipulation, so I can have a better
picture of what's happening on the scope.

R.

[-- Attachment #2: Type: text/html, Size: 3471 bytes --]

Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Gilles Chanteperdrix]

at91_enthus wrote:
> On Sat, Feb 5, 2011 at 9:39 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> at91_enthus wrote:
>>>>> Rookie mistake. Indeed, I can have everything in userspace using
>> Xenomai.
>>>> I
>> Or in kernel-space... with Xenomai RTDM skin.
>>
>>>>> wrote a simple program that did a periodic job every 100 us and the
>>>> jitter
>>>>> was very small (around 20 us without load and around 35 us with SSH-ing
>>>> and
>>>>> Xenomai compilation running on board).
>> Well, as we often say, benchmarking requires making more than that to
>> load the board, and for a long time.
>>
>>>>> Somewhat unrelated to this thread, I found that when I invoked
>>>>> rt_task_set_periodic(), I got very precise timings (as expected).
>>>> However,
>>>>> when I tried to insert small delays using rt_timer_spin(), the errors
>>>>> (t_meas - t_spin_func_argument) were not large, but noticeable. For
>>>> example,
>>>>> I can precisely measure a 50 us periodic task on the scope. With the
>> same
>>>>> interval in rt_timer_spin(), I get 55-60 us. As far as I understood,
>> all
>>>>> timing-related functions use the same time base, so what's the reason
>> for
>>>>> this behavior?
>> Well, rt_task_set_periodic gets the hardware timer to tick exactly every
>> 50us. So, whatever time it takes between the return of the call to
>> rt_task_wait_period() to the entry of the next is irrelevant. And
>> particularily, the jitter will not matter as long as it is smaller than
>> 50u.
>>
>> On the other hand, doing:
>>
>> for(;;) {
>>        /* Do something */
>>        rt_timer_spin(50000);
>> }
>>
>> The period of the loop will be 50us + rt_timer_spin jitter + time to "do
>> something". And so, will not even be constant.
>> You are not creating a periodic task. Besides, the system will not
>> execute anything else in user-space than your real-time task, and in
>> particular, the Linux will never run. Except of course if "do something"
>> contains a call to some secondary domain function, in which case, your
>> real-time task no longer is real-time.
>>
>> So, that is not the correct way to get a periodic task.
>>
>> --
>>                                                                 Gilles.
>>
> 
> Actually, the rt_timer_spin was included in this function that is run as a
> real time task:
> 
> void spin(){
> 
>     rt_task_set_periodic(&spin_task,TM_NOW, 100000);
> 
>     while(1){
> 
>     *((unsigned int *) (piob_base + (PIO_SODR))) = 1<<0;
> 
>      rt_task_wait_period(NULL);
> 
>      *((unsigned int *) (piob_base + (PIO_CODR))) = 1<<0;
> 
>      rt_timer_spin(50000);
> 
>   }
> 
> I decided to go for simple GPIOs manipulation, so I can have a better
> picture of what's happening on the scope.

So, what you are measuring is simply the length of rt_timer_spin, and
what you see is simply the rt_timer_spin jitter: time for the system
call, potential interruption by interupt handler.

Where you will see the exact 100us frequency +-jitter is measuring the
signal period at the falling edge. Because that is what is constant on
average. The rest is irrelevant.

> 
> R.
> 


-- 
                                                                Gilles.