[linuxkernelnewbies] New and Updated Processor Specifications - The ChipList 2
http://www.chiplist.com/new/processor_specifications/ Fri 20 Feb 2009, 11:59 Sun 25 Jan 2009, 16:29 Intel Core 2 Quad Q9xxx series processor (Yorkfield) Fri 23 Jan 2009, 11:38 Intel Core 2 Quad Q9xxx/Q8xxx series processor (Yorkfield-6M) Fri 23 Jan 2009, 11:36 Intel Core 2 Quad processor Mon 11 Aug 2008, 0:39 Intel Pentium 4 Xeon DP processor Mon 11 Aug 2008, 0:38 Intel Pentium 4 Xeon DP processor (Prestonia B, Standard Voltage, Socket 604) Wed 6 Aug 2008, 13:59 Intel Pentium 4 Xeon DP processor (Prestonia A, Standard Voltage, Socket 603) Tue 5 Aug 2008, 15:15 Intel Pentium 4 Xeon MP processor (Foster MP) Sat 2 Aug 2008, 9:45 Intel Pentium 4 Xeon DP processor (Foster) Fri 1 Aug 2008, 10:40 Intel Pentium III Xeon processor Fri 1 Aug 2008, 10:40 Intel Pentium III Xeon processor (Cascades 2MB) Mon 28 Jul 2008, 21:39 Intel Pentium III Xeon processor (Cascades) Sun 27 Jul 2008, 19:18 Intel Pentium III Xeon processor (Tanner) Sun 27 Jul 2008, 19:14 Intel Pentium III processors Sun 27 Jul 2008, 13:07 Sun 27 Jul 2008, 11:06 Intel Pentium II Xeon processor (Drake) Sun 27 Jul 2008, 11:04 Intel Pentium II processors Sun 27 Jul 2008, 11:03 Intel Pentium II Xeon processor Sat 26 Jul 2008, 22:49 AMD Mobile Sempron processor (Albany, revision E6, Desktop Replacement) Sat 26 Jul 2008, 19:38 AMD Opteron 4P-8P HE 8300 series Quad-Core processor (Barcelona, High Efficiency) Sat 26 Jul 2008, 19:26 AMD Opteron 4P-8P 8300 series Quad-Core processor (Barcelona) Sat 26 Jul 2008, 19:02 AMD Opteron 2P HE 2300 series Quad-Core processor (Barcelona, High Efficiency) Sat 26 Jul 2008, 18:44 AMD Opteron 2P 2300 series Quad-Core processor (Barcelona) Sat 26 Jul 2008, 17:22 AMD Opteron MP HE 8000 series Dual-Core processor (Santa Rosa, Rev. F, High Efficiency) Sat 26 Jul 2008, 17:21 AMD Opteron MP 8000 series Dual-Core processor (Santa Rosa, Rev. F) Sat 26 Jul 2008, 17:19 AMD Opteron DP HE 2000 series Dual-Core processor (Santa Rosa, Rev. F, High Efficiency) Sat 26 Jul 2008, 17:17 AMD Opteron DP 2000 series Dual-Core processor (Santa Rosa, Rev. F) Sat 26 Jul 2008, 17:16 AMD Opteron UP HE 1000 series Dual-Core processor (Santa Ana, Rev. F, High Efficiency) Sat 26 Jul 2008, 17:13 AMD Opteron UP 1000 series Dual-Core processor (Santa Ana, Rev. F) Sat 26 Jul 2008, 17:09 AMD Sempron X2 Dual-Core processor (Brisbane, Rev. G) Sat 26 Jul 2008, 17:05 AMD Turion 64 X2 TL/TK series Dual-Core processor (Tyler, Rev. G) Sat 26 Jul 2008, 16:59 AMD Turion 64 X2 TL series Dual-Core processor (Trinidad, Rev. F) Sat 26 Jul 2008, 16:57 AMD Turion 64 X2 TL series Dual-Core processor (Taylor, Rev. F) Sat 26 Jul 2008, 16:52 AMD Quad FX platform (Windsor 2MB, Rev. F; 4x4, QuadFather) Sat 26 Jul 2008, 16:50 AMD Athlon 64 FX Dual-Core processor (Windsor 2MB, Rev. F) Sat 26 Jul 2008, 16:41 AMD Athlon X2 EE 4xxx series Dual-Core processor (Brisbane, Rev. G, Energy Efficient, 45 W TDP) Sat 26 Jul 2008, 16:36 AMD Athlon X2 EE BE-2xxx series Dual-Core processor (Brisbane, Rev. G, Energy Efficient, 45 W TDP) Sat 26 Jul 2008, 16:33 AMD Athlon 64 X2 EE Dual-Core processor (Brisbane, Rev. G, Energy Efficient, 65 W TDP) Sat 26 Jul 2008, 16:30 AMD Athlon 64 X2 EE SFF Dual-Core processor (Windsor 1MB, Rev. F, Energy Efficient Small Form Factor) Sat 26 Jul 2008, 16:27 AMD Athlon 64 X2 EE Dual-Core processor (Windsor 1MB, Rev. F, Energy Efficient) Sat 26 Jul 2008, 16:23 AMD Athlon 64 X2 Dual-Core processor (Windsor 1MB, Rev. F) Sat 26 Jul 2008, 16:21 AMD Athlon 64 X2 EE Dual-Core processor (Windsor 2MB, Rev. F, Energy Efficient) Sat 26 Jul 2008, 16:17 AMD Athlon 64 X2 Dual-Core processor (Windsor 2MB, Rev. F) Sat 26 Jul 2008, 15:48 AMD Mobile Sempron processor (Sherman, revision G, Low Power) Sat 26 Jul 2008, 14:57 AMD Sempron processor (Sparta, revision G, Energy Efficient) Sat 26 Jul 2008, 14:52 AMD Sempron processor (Manila, revision F, Energy Efficient Small Form Factor) Sat 26 Jul 2008, 14:49 AMD Sempron processor (Manila, revision F) Sat 26 Jul 2008, 14:13 AMD Athlon 64 processor (Lima, revision G, Energy Efficient) Sat 26 Jul 2008, 14:10 AMD Athlon 64 processor (Orleans, revision F, Energy Efficient Small Form Factor) Sat 26 Jul 2008, 14:07 AMD Athlon 64 processor (Orleans, revision F, Energy Efficient) Sat 26 Jul 2008, 14:04 AMD Athlon 64 processor (Orleans, revision F) Mon 23 Jun 2008, 20:16 AMD Mobile Sempron processor Mon 23 Jun 2008, 20:14 AMD Mobile Sempron processor (Keene, revision F2, Low Power) Mon 23 Jun 2008, 19:42 AMD Mobile Sempron processor (Roma, revision E6, Low Power) Sun 22 Jun 2008, 23:39 AMD Mobile Sempron processor (Sonora, revision D0, Low Power) Sun 22 Jun 2008, 23:21 AMD Mobile Sempron processor (Georgetown, revision D0, Desktop Replacement) Sat 21 Jun 2008, 23:53
[linuxkernelnewbies] Multiqueue networking [LWN.net]
http://lwn.net/Articles/289137/ Multiqueue networking By Jonathan Corbet July 8, 2008 One of the fundamental data structures in the networking subsystem is the transmit queue associated with each device. The core networking code will call a driver's hard_start_xmit() function to let the driver know that a packet is ready for transmission; it is then the driver's job to feed that packet into the hardware's transmit queue. The result is a data structure which looks vaguely like this: "Vaguely" because the list of sk_buff structures (SKBs - the internal representation of packets) does not exist in this form within the kernel; instead, the driver maintains the queue in a way that the hardware can process it. This is a scheme which has worked well for years, but it has run into a fundamental limitation: it does not map well to devices which have multiple transmit queues. Such devices are becoming increasingly common, especially in the wireless networking area. Devices which implement the Wireless Multimedia Extensions, for example, can have four different classes of service: video, voice, best-effort, and background. Video and voice traffic may receive higher priority within the device - it is transmitted first - and the device can also take more of the available air time for such packets. On the other hand, the queues for this kind of traffic may be relatively short; if a video packet doesn't get sent on its way quickly, the receiving end will lose interest and move on. So it might be better to just drop video packets which have been delayed for too long. On the other hand, the "background" level only gets transmitted if there is nothing else to do; it is well-suited to low-priority traffic like bittorrent or email from the boss. It would make sense to have a relatively long queue for background packets, though, to be able to take full advantage of a lull in higher-priority traffic. Within these devices, each class of service has its own transmit queue. This separation of traffic makes it easy for the hardware to choose which packet to transmit next. It also allows independent limits on the size of each queue; there is no point in filling the device's queue space with background traffic which is not going to be transmitted in any case. But the networking subsystem does not have any built-in support for multiqueue devices. This hardware has been driven using a number of creative techniques which have gotten the job done, but not in an optimal way. That may be about to change, though, with the advent of David Miller's multiqueue transmit patch series. The current code treats a network device as the fundamental unit which is managed by the outgoing packet scheduler. David's patches change that idea somewhat, since each transmit queue will need to be scheduled independently. So there is a new netdev_queue structure which encapsulates all of the information about a single transmit queue, and which is protected by its own lock. Multiqueue drivers then set up an array of these structures. So the new data structure can, with sufficient imagination, be seen to look something like this: Once again, the actual lists of outgoing packets normally exist in the form of special data structures in device-accessible memory. Once the device has these queues set up for it, the various policies associated with each class of service can be implemented. Each queue is managed independently, so more voice packets can be queued even if some other queue (background, say) is overflowing. David would appear to have worked hard to avoid creating trouble for network driver developers. Drivers for single-queue devices need not be changed at all, and the addition of multiqueue support is relatively straightforward. The first step is to replace the alloc_etherdev() call with a call to: struct net_device *alloc_etherdev_mq(int sizeof_priv, unsigned int queue_count); The new queue_count parameter describes the maximum number of transmit queues that the device might support. The actual number in use should be stored in the real_num_tx_queues field of the net_device structure. Note that this value can only be changed when the device is down. A multiqueue driver will get packets destined for any queue via the usual hard_start_xmit() function. To determine which queue to use, the driver should call: u16 skb_get_queue_mapping(struct sk_buff *skb); The return value is an index into the array of transmit queues. One might well wonder how the networking core decides which queue to use in the first place. That is handled via a new net_device callback: u16 (*select_queue)(struct net_device *dev, struct sk_buff *skb); The patch set includes an implementation of select_queue() which can be used with WME-capable devices. About the only other required change is for multiqueue drivers to inform the networking core about the status of specific queues. To that end, there
[linuxkernelnewbies] The Twisted networking framework version 9.0.0 [LWN.net]
http://lwn.net/Articles/365806/ The Twisted project is building a Pythonic networking engine with many uses. >From the Twisted home page: "Twisted is an event-driven networking engine written in Python and licensed under the MIT license." Also: "Twisted projects variously support TCP, UDP, SSL/TLS, multicast, Unix sockets, a large number of protocols (including HTTP, NNTP, IMAP, SSH, IRC, FTP, and others), and much more." See the twisted advantage for an explanation of why one would want to use Twisted to develop network applications. LWN last looked at the Twisted project in January, 2007 when version 2.5.0 was released, the project has matured a lot since then. The current version of Twisted is organized into the following categories: Twisted core - the project's top level Twisted conch - implements the SSH protocol Twisted lore - the Twisted documentation Twisted mail - implements the SMTP protocol Twisted names - implements the DNS protocol Twisted trail - the twisted testing framework Twisted web - implements the HTTP protocol Twisted web2 - implements the HTTP protocol (redux) Twisted words - implements instant messaging See the project documentation for more detailed descriptions of the various components. Christopher Armstrong recently announced Twisted 9.0.0: "I'm happy to announce Twisted 9, the first (and last) release of Twisted in 2009. The previous release was Twisted 8.2 in December of 2008. Given that, a lot has changed! This release supports Python 2.3 through Python 2.6, though it is the last one that will support Python 2.3. The next release will support only Python 2.4 and above. Twisted: the framework of the future!" Looking at the release notes for version 9.0.0, one can see that a large amount of work has gone into cleaning up the code and fixing bugs, with 285 bug tickets resolved. New capabilities are summed up in the release announcement: In the core: - The Windows IOCP reactor now supports SSL. - The memcache protocol implementation got some nice new features. In Twisted Web: - There's a new HTTP client API and protocol implementation, starting at twisted.web.client.Agent. It's still pretty low-level, but much more flexible than the old API. - There were many improvements to the WSGI support. In Twisted Conch: - PyASN1 is now used to parse SSH keys (which means you now need to install it to use Conch). - SFTP servers (especially on Windows) now behave a lot better. In Twisted Mail: - The IMAP server and client protocol implementations had many fixes. For example, SASL PLAIN credentials now work. In Twisted Words: - XMPP clients now support the ANONYMOUS SASL authentication type. - The IRC protocol implementations had many fixes. The Twisted project appears to be alive and thriving as it continues in its evolution. This is indicated by the numerous Success Stories and the growing list of projects that use Twisted. Congratulations to the Twisted developers for continuing to make progress on this useful framework. -- To unsubscribe, reply using remove me as the subject.
[linuxkernelnewbies] Research Results | Analysis and Test of Real-Time Linux Operating Systems
http://sarpresults.ivv.nasa.gov/ViewResearch/7.jsp Analysis and Test of Real-Time Linux Operating Systems Point of Contact Kalynnda Berens kalynnda.m.ber...@grc.nasa.gov Dates October 2001 - September 2004 Problem In an era of reduced budgets, many projects are considering versions of the Linux operating system to lower cost. Some of these versions are modified to operate in a real-time and embedded environment. However, the safety, reliability, and applicability of these operating systems has not been thoroughly categorized. Objective The objective of this research is to characterize 3 to 5 real-time Linux operating systems from a safety, reliability, and applicability perspective. This includes determining the strengths and weaknesses of the various operating systems, cataloging their error and fault and performing functional analysis and testing to compare the with the VxWorks operating system. Results End Of Year Report Real time Linux Evaluation.ppt Function Catalog With Known Errors Exceptions Side Effects And Results.zip Generic Test Plan.doc Selection of Real-time Linux.doc RTLinux (free version) Testing Report.doc Paper on Real-time Linux results (Updated).doc Report - RTAI results, comparison with RTLinux.doc Report - RTLinuxPRO results, comparison.doc Final Test Report (all variants).doc Keywords real-time, VxWorks, safety critical, mission critical Categories Domain-Specific Analysis Dynamic Analysis Interface Analysis Software Architecture Assessment -- To unsubscribe, reply using remove me as the subject.
[linuxkernelnewbies] thread_info/linux - 株式会 社ひらコンサルティング
http://hira-consulting.com/linux/index.php?thread_info%2Flinux 最新の100件 2010-03-28 RecentDeleted 0-関数・マクロの雛形/linux 2010-03-23 Linux詳説 2010-02-14 percpu_read_stable()/linux 2010-02-13 percpu_write()/linux percpu_from_op()/linux __percpu_arg()/linux percpu_to_op()/linux percpu_read()/linux linux/arch/x86/include/asm/percpu.h 解説 find_next_bit()/linux BITOP_WORD()/linux 2010-02-12 BITS_PER_LONG/linux linux/include/asm-generic/bitsperlong.h linux sourcefile linux/lib/find_next_bit.c cpumask_next()/linux cpumask_bits()/linux __ffs()/linux linux/include/linux/cpumask.h cpumask/linux cpumask_check()/linux for_each_cpu()/linux for_each_possible_cpu()/linux per_cpu()/linux setup_per_cpu_areas()/linux 2010-02-10 PER_CPU()/linux DEFINE_PER_CPU()/linux DEFINE_PER_CPU_SECTION()/linux __PCPU_ATTRS()/linux PER_CPU_BASE_SECTION/linux linux/include/asm-generic/percpu.h 2010-02-09 linux/include/linux/percpu-defs.h 解説：percpu/linux __percpu_seg/linux __percpu_mov_op/linux __do_softirq()/linux set_softirq_pending()/linux 2010-02-08 linux/arch/x86/include/asm/hardirq.h softirq_action/linux linux/include/linux/interrupt.h 2010-02-07 thread_info/linux _local_bh_enable()/linux WARN_ON()/linux sub_preempt_count()/linux trace_softirqs_on()/linux softirq_count()/linux irqs_disabled()/linux WARN_ON_ONCE()/linux in_irq()/linux linux/kernel/softirq.c 2010-02-05 in_interrupt()/linux do_softirq()/linux _local_bh_enable_ip()/linux irq_count()/linux NMI_MASK/linux NMI_SHIFT/linux linux/include/linux/hardirq.h NMI_BITS/linux 0-構造体・共用体・列挙型の雛形/linux 2010-01-29 preempt_count()/linux 2010-01-28 dec_preempt_count()/linux inc_preempt_count()/linux add_preempt_count()/linux linux/include/linux/preempt.h memo __stringify()/linux __stringify_1()/linux linux/include/linux/stringify.h 2010-01-27 local_softirq_pending()/linux local_irq_enable()/linux native_irq_enable()/linux raw_local_irq_enable()/linux linux/arch/x86/include/asm/irqflags.h trace_hardirqs_on()/linux linux/include/linux/irqflags.h __local_bh_disable()/linux hardirq_count()/linux start_critical_timing()/linux local_irq_disable()/linux smp_processor_id()/linux call_softirq()/linux linux/arch/x86/kernel/entry_64.S 2010-01-26 local_irq_restore()/linux local_irq_save()/linux linux/arch/x86/kernel/irq_64.c linux/kernel/trace/trace_irqsoff.c trace_hardirqs_off()/linux raw_local_irq_disable()/linux raw_irqs_disabled_flags()/linux raw_local_save_flags()/linux unlikely()/linux 2010-01-25 local_bh_enable_ip()/linux __raw_spin_unlock_bh()/linux preempt_enable_no_resched()/linux do_raw_spin_unlock()/linux spin_release()/linux linux/include/linux/spinlock_api_smp.h linux/kernel/spinlock.c -- To unsubscribe, reply using remove me as the subject.
[linuxkernelnewbies] Ticket spinlocks [LWN.net]
http://lwn.net/Articles/267968/?format=printable
Ticket spinlocks
By Jonathan Corbet
February 6, 2008
Spinlocks are the lowest-level mutual exclusion mechanism in the Linux
kernel. As such, they have a great deal of influence over the safety
and
performance of the kernel, so it is not surprising that a great deal of
optimization effort has gone into the various (architecture-specific)
spinlock implementations. That does not mean that all of the work has
been
done, though; a patch merged for 2.6.25 shows that there is always more
which can be done.
On the x86 architecture, in the 2.6.24 kernel, a
spinlock is represented by
an integer value. A value of one indicates that the lock is available.
The spin_lock() code works by decrementing the value (in a
system-wide atomic manner), then looking to see whether the result is
zero; if so, the lock has been successfully obtained. Should, instead,
the
result of the decrement option be negative, the spin_lock()
code
knows that the lock is owned by somebody else. So it busy-waits
("spins")
in a tight loop until the value of the lock becomes positive; then it
goes
back to the beginning and tries again.
Once the critical section has been executed, the owner
of the lock releases
it by setting it to1.
This implementation is very fast, especially in the
uncontended case (which
is how things should be most of the time). It also makes it easy to see
how bad the contention for a lock is - the more negative the value of
the
lock gets, the more processors are trying to acquire it. But there is
one
shortcoming with this approach: it is unfair. Once the lock is
released,
the first processor which is able to decrement it will be the new
owner.
There is no way to ensure that the processor which has been waiting the
longest gets the lock first; in fact, the processor which just released
the
lock may, by virtue of owning that cache line, have an advantage should
it
decide to reacquire the lock quickly.
One would hope that spinlock unfairness would not be a
problem; usually, if
there is serious contention for locks, that contention is a performance
issue even before fairness is taken into account. Nick Piggin recently
revisited this issue, though, after noticing:
On an 8 core (2 socket) Opteron,
spinlock unfairness is extremely noticable, with a userspace test
having a difference of up to 2x runtime per thread, and some threads
are starved or "unfairly" granted the lock up to 100(!) times.
This sort of runtime difference is certainly undesirable. But lock
unfairness can also create latency issues; it is hard to give latency
guarantees when the wait time for a spinlock can be arbitrarily long.
Nick's response
was a new spinlock implementation which he calls "ticket spinlocks."
Under the initial version of this patch, a spinlock became a
16-bit quantity, split into two bytes:
Each byte can be thought of as a ticket number. If you have ever been
to a
store where customers take paper tickets to ensure that they are served
in
the order of arrival, you can think of the "next" field as being the
number
on the next ticket in the dispenser, while "owner" is the number
appearing
in the "now serving" display over the counter.
So, in the new scheme, the value of a lock is
initialized (both fields) to
zero. spin_lock() starts by noting the value of the lock,
then
incrementing the "next" field - all in a single, atomic operation. If
the
value of "next" (before the increment) is equal to "owner," the lock
has
been obtained and work can continue. Otherwise the processor will spin,
waiting until "owner" is incremented to the right value. In this
scheme,
releasing a lock is a simple matter of incrementing "owner."
The implementation described above does have one small
disadvantage in that
it limits the number of processors to 256 - any more than that, and a
heavily-contended lock could lead to multiple processors thinking they
had
the same ticket number. Needless to say, the resulting potential for
mayhem is not something which can be tolerated. But the 256-processor
limit is an unwelcome constraint for those working on large systems,
which
already have rather more processors than that. So the add-on "big
ticket" patch - also merged for 2.6.25 - uses 16-bit values when
the
configured maximum number of processors exceeds 256. That raises the
maximum system size to 65536 processors - who could ever want more than
that?
With the older spinlock
[linuxkernelnewbies] Paravirtual spinlocks [LWN.net]
http://lwn.net/Articles/289039/
At the most recent Xen Summit, Thomas Friebel presented a paper
("Preventing Guests from Spinning Around",
http://xen.org/files/xensummitboston08/LHP.pdf) investigating the
interactions between spinlocks and virtual machines. Specifically, he
looked at what happens when a lock-holding VCPU gets involuntarily
preempted.
The obvious first order effect is that while the VCPU is not running,
the effective critical region time goes from being microseconds to
milliseconds, until it gets scheduled again. This increases the
chance that there will be be contention, and the contending VCPU will
waste time spinning.
This is a measurable effect, but not terribly serious. After all,
since Linux tends to hold locks for very short periods of time,
the likelihood of being preempted while holding a lock is low.
The real eye-opener is the secondary effects specific to ticket locks.
Clearly ticket locks suffer the same problem as all spinlocks. But
when the lock holder releases the lock, the real fun begins.
By design, ticket locks are strictly fair, by imposing a FIFO order
lock holders. The micro-architectural effect of this is that the
lock cache line will bounce around between the contending CPUs until
it finds the next in line, who then takes the lock and carries on.
When running in a virtual machine, a similar effect happens at the
VCPU level. If all the contending VCPUs are not currently running on
real CPUs, then VCPU scheduler will run some random subset of them.
If it isn't a given VCPUs turn to take the lock, it will spin, burning
a VCPU timeslice. Eventually the next-in-line will get scheduled,
take the lock, release it, and the remaining contending VCPUs will
repeat the process until the next in line is scheduled.
This means that the effective contention time of the lock is not
merely the time if takes the original lock-holder to take and release
the lock - including any preemption it may suffer - but the
spin-scheduling storm that follows to schedule the right VCPU to next
take the lock. This could happen if the original contention was not
as a result of preemption, but just normal spinlock level contention.
One of the results Thomas presents is a kernbench run which normally
takes less than a minute going for 45 minutes, with 99+% spent in
ticket lock contention. I've reproduced similar results.
This series has:
- a paravirt_ops spinlock interface, which defaults to the standard
ticket lock algorithm,
- a second spinlock implementation based on the pre-ticket-lock
"lock-byte" algorithm,
- And a Xen-specific spinlock algorithm which voluntarily preempts a
VCPU if it spins for too long. [FOR REFERENCE ONLY: will not apply
to a current git tree.]
When running on native hardware, the overhead of enabling
CONFIG_PARAVIRT is an extra direct call/return on the lock/unlock
paths; the paravirt-ops patching machinery eliminates any indirect
calls. With a small amount of restructuring, this overhead could be
eliminated (by making spin_lock()/unlock() inline functions,
containing calls to __raw_spin_lock/unlock).
My experiments show that using a Xen-specific lock helps guest
performance a bit (reduction in elapsed and system time in a kernbench
run), but most significantly, reduces overall physical CPU consumption
by 10%, and so increases overall system scalability.
J
--
--
To unsubscribe, reply using remove me as the subject.
[linuxkernelnewbies] MIPS Address Space
http://www.johnloomis.org/microchip/pic32/memory/memory.html MIPS Address Space With a MIPS CPU the addresses you put in your programs are never the same as the physical addresses that come out of the chip (sometimes they are simply related, but they're not not same). We can refer to them as program addresses [note] and physical addresses, respectively. A MIPS CPU runs at one of two privilege levels: user and kernel. We may talk about user mode and kernel mode, but changing from one mode to the other never makes anything work differently; it just sometimes makes it illegal. In user mode, any program address with the most significant bit of the address set is illegal and causes a trap. Also, some instructions cause a trap in user mode. Inte the MIPS memory map, shown below, the program address space is divided into four big areas with traditional (and thoroughly meaningless) names. Different things happen according to the area in which an address lies. 0xF000. Mapped (kseg2) 0xE000. 0xD000. 0xC000. 0xB000. Unmapped uncached (kseg1) 0xA000. 0x9000. Unmapped cached (kseg0) 0x8000. 0x7000. 32-bit user space kuseg 0x6000. 0x5000. 0x4000. 0x3000. 0x2000. 0x1000. kseg2 0xC000.-0x. 1GB This area is only accessible in kernel mode but is translated by through the MMU. Unless you are writing a serious operating system, you will probably never have to use kseg2 kseg1 0xA.-0xBFF. 512MB These addresses are mapped into physical addresses by stripping off the leading 3 bits, giving a duplicate mapping of the low 512 MB of physical memory. Access to this area of memory does not use the MMU or the cache. This area is most often used for I/O addresses and boot ROM. kseg0 0x8000.-0x9FFF. 512MB These addresses are translated into physical addresses by stripping off the top bit and mapping the remainder into the low 512 MB of physical memory. Addresses in this region are almost always accessed through the cache, so they may not be used until the caches are properly initialized. kuseg 0x.0-0x7FFF. 2GB These are addresses permitted in user mode. They are always mapped through an MMU if one is implemented. Notes A program address in this sense is exactly the same as a virtual address -- but for many people virtual address suggests operating system complications, such as mapping disk space to memory, that aren't relevant here. Reference Sweetman, Dominic, See MIPS Run, Second Edition, Morgan Kaufman, 2007. ISBN 0-12-088421-6 p 47-48. PIC32MX Memory Mapping The MIPS core at the heart of the PIC32 has a number of advanced features designed to allow the separation of memory space dedicated to an application or applications from that of an operating system via the use of a memory management unit (MMU) and two distinct modes of operation: user and kernel. Since the PIC32MX family of devices is clearly targeting embedded-control applications that most likely would not require much of that complexity, the PIC32 designers replaced the MMU with a simpler fixed mapping translation (FMT) unit and a bus matrix (BMX) control mechanism. The FMT allows the PIC32 to conform to the programming model used by all other MIPS-based designs so that standardized address spaces are used. This fixed but compatible scheme simplifies the design of tools and applications and the porting of code to the PIC32 while considerabley reducing the size and therefore the cost of the device. The PIC32 physical addressing space includes four separate elements: RAM, Flash, Special Function Registers (SFR), and Boot ROM. These are physically assigned addresses as follows: The FMT translates between physical addresses and virtual (or program) addresses. Currently the PIC32
[linuxkernelnewbies] Dr Nikolai Bezroukov. Solaris vs. Linux: Framework for the Comparison. Part 11: Webliography
http://www.softpanorama.org/Articles/Linux_vs_Solaris/webliography.shtml Solaris vs. Linux: Framework for the Comparison by Dr Nikolai Bezroukov Prev Contents Next 11. Webliography [AlmondBrown2006] Chris Almond, Mark Brown, Chuck Davis, William Dy, Paul Ionescu, Jeff Richardson, Kurt Taylor, Robbie Williamson. IBM Redbooks Solaris to Linux Migration A Guide for System Administrators IBM Redbook. 02 February 2006. [Barr2006] Joe Barr. Torvalds comments on kernel overhaul May 08, 2006 Linux.com URL: http://www.linux.com/article.pl?sid=06/05/08/1439236 [Bertoni1998] J. L. Bertoni. Understanding Solaris Filesystems and Paging. Technical Report TR-98-55, Sun Microsystems Research, November 1998. http://research.sun.com/research/techrep/1998/abstract-55.html. [Bezroukov1999a] Nikolai Bezroukov. "Open Source Development as a Special Type of Academic Research (Critique of Vulgar Raymondism)," First Monday, volume 4, number 10 (October), URL: http://firstmonday.org/issues/issue4_10/bezroukov/, accessed 4 March 2004. [Bezroukov1999b] Nikolai Bezroukov, "A Second Look at the Cathedral and the Bazaar," First Monday, volume 4, number 12 (December), at http://firstmonday.org/issues/issue4_12/bezroukov/, accessed 4 March 2004. [Bezroukov2004a] Labyrinth of Software Freedom. Chapter 1: Social Roots, Complexity and Never Ending Process of Interpretation of GPL [Bezroukov2005a] Nikolai Bezroukov. Portraits of Open Source Pioneers. Ch 4: A Slightly Skeptical View on Linus Torvalds [Bezroukov2005b] Nikolai Bezroukov. Solaris vs Linux Security in Large Enterprise Environment [Bezroukov2005b] Nikolai Bezroukov. Softpanorama (Slightly Skeptical) Sun Solaris Security and Hardening Page [Bezroukov2005c] Nikolai Bezroukov. Sun under the Linux siege Part of the Ch 4: A Slightly Skeptical View on Linus Torvalds of the ebook Portraits of Open Source Pioneers. [Bruning2005a] Max Bruning. A Comparison of Solaris, Linux, and FreeBSD Kernels at OpenSolaris.org Max Bruning is teaching Solaris internals and is a more qualified reviewer for the subject. Accessed October 18, 2005 [Bruning2006] Max Bruning. Comparison of Solaris OS and Linux for Application Developers Sun Developer Network, June 2006. Accessed June 21, 2006 URL://http://developers.sun.com/solaris/articles/solaris_linux_app.html [CardTso1994] Rmy Card, Theodore Ts'o, Stephen Tweedie Design and Implementation of the Second Extended Filesystem, First Dutch International Symposium on Linux. Amsterdam (December, 1994) [ChengHuang2002] Lee Cheng, Wayne Huang , Paul Sutera, Nam Keung. Technical guide for porting applications from Solaris to Linux, Version 1.0 IBM DeveloperWorks, 12 Feb 2002 [Chisnall2006] David Chisnall. Alternatives to LAMP. Informit.com. Jun 2, 2006. URL http://www.informit.com/articles/article.asp?p=472693rl=1 [Drepper] Ulrich Drepper. Solaris-to-Linux Porting Guide . [FarberDignan2007] Dan Farber Larry Dignan Ian Murdock Making Solaris more like Linux Between the Lines ZDNet.com, March 27th, 2007 URL: http://blogs.zdnet.com/BTL/?p=4743 [FreeBSD_Architecture_Handbook] FreeBSD Architecture Handbook The FreeBSD Documentation Project 2000-2005. Accessed October 20, 2005 [FoxwellRozenfeld2005] Harry Foxwell, Isaac Rozenfeld Slicing and Dicing Servers: A Guide to Virtualization and Containment Technologies [GleditschGjermshus2004] Arne Georg and Per Kristian Linux-Documentation-Submitting Patches [Groklaw2005] Comments for the article How The Kernel Development Process Works, by Greg Kroah-Hartman [Haff2007] Gordon Haff. Illuminata Perspectives Blog Archive Predatory Open Source [Hanrahan2004] Tom Hanrahan, Linux Engineering, OSDL http://www.internetnews.com. Interview by Jim Wagner [IBM2006] developerWorks Migration station Linux track [Intel2002a] [PDF] Intel Compilers for Linux* - Compatibility with the GNU [Intel2002b] Compatibility with the GNU* Compilers. Version 8.x Intel C++ Compiler 8.1 for Linux [Intel2005] Compatibility with the GNU* Compilers. Version 9.0 Intel C++ Compiler 9.0 for Linux [Katcher] Katcher. Postmark- A new file system benchmark Technical Report TR3022, Network Appliance. [Kroach-Hartman2004] Greg Kroach-Hartman. Presentation about Linux development OSCON 2004 [EcommerceTimes] Ecommerce Times. Solaris vs. Linux This two part article has part 1 here and part 2 here. September 15, 2003. [Kapitsa1980] PL Kapitsa Experiment, Theory, Practice: articles and addresses - 1980 - books.google.com. Original in Russian 1974, Moscow, Nauka (Science Publishing House). [LeonardNieh2002] Ozgur Can Leonard, Jason Nieh, Erez Zadok, Jeffrey Osborn, Ariye Shater, and Charles Wright The Design and Implementation of Elastic Quotas A System for Flexible File System Management Columbia University Technical Report CUCS-014-02, June 2002 [Lin2007] Frank Liang Lin Developing Applications on
[linuxkernelnewbies] How to enable L2 cache for overdrive CPUs
http://lkml.org/lkml/2003/2/26/88
Some CPU overdrives (such as those made by powerleap) mean
that we get a CPU with L2 cache disabled by default, and
a BIOS that doesn't know how to turn it on.
The patch below is untested, and I'd like some feedback
from folks (preferably those with these wacky overdrives,
but also from regular intel CPUs too - disable L2 in your
bios and try booting with 'enable-l2' and see what happens).
Dave
diff -urpN --exclude-from=/home/davej/.exclude bk-linus/arch/i386/kernel/cpu/intel.c linux-2.5/arch/i386/kernel/cpu/intel.c
--- bk-linus/arch/i386/kernel/cpu/intel.c 2003-02-25 13:10:08.0 -0100
+++ linux-2.5/arch/i386/kernel/cpu/intel.c 2003-02-25 13:07:52.0 -0100
@@ -8,6 +8,7 @@
#include asm/processor.h
#include asm/msr.h
#include asm/uaccess.h
+#include asm/system.h
#include "cpu.h"
@@ -75,6 +76,36 @@ static int __init P4_disable_ht(char *s)
}
__setup("noht", P4_disable_ht);
+/*
+ * Some 'overdrive' boards, such as those from Powerleap don't have
+ * the L2 cache enabled, and the BIOS doesn't know about it, so we
+ * have this option to 'force' it on.
+ */
+static int __init P2_enable_L2(char *s)
+{
+ unsigned long cr0, lo, hi;
+
+ printk ("CPU: Enabling L2 cache.\n");
+
+ __asm__ ("cli");
+
+ cr0 = read_cr0();
+ cr0 |= 130;
+ write_cr0 (cr0);
+
+ rdmsr (0x11e, lo, hi);
+ lo |= 0x40101;
+ wrmsr (0x11e, lo, hi);
+
+ cr0 = ~(130);
+ write_cr0 (cr0);
+
+ wbinvd();
+ __asm__("sti");
+ return 0;
+}
+__setup("enable-l2", P2_enable_L2);
+
#define LVL_1_INST 1
#define LVL_1_DATA 2
#define LVL_2 3
-
--
To unsubscribe, reply using remove me as the subject.
[linuxkernelnewbies] Re: File in Kernel Module
how about sys_unlink()? or sys_unlinkat()? if u strace rm command, u can see that unlinkat() is being called. On Mar 28, 2:25 pm, perumal316 perumal...@gmail.com wrote: Hi All, In my kernel module I am writing log messages to a text file by using sys_open eg. sys_open(filename, O_WRONLY|O_RDONLY|O_APPEND|O_CREAT,00777) So I want to delete this file each time the module unloads. Is it possible? I can't seem to find any resources online explaining this. Now I can write the log messages to the textfile but how do I delete it to prevent it from becoming too big. Is there any code I must include under void cleanup_module() to delete the file? Thanks In Advance, Perumal To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] RTOS - Real-Time Operating Systems for Embedded Development, Real Time System By Express Logic
http://www.rtos.com/page/imgpage.php?id=211 RTOS Interrupt Architectures RTOS Interrupt Architectures Two Approaches - Unified and Segmented 1. Background Like stand-alone systems, embedded applications running on top of real-time operating systems (RTOSes) require Interrupt Service Routines (ISRs) to handle interrupts generated by external events. External events can be caused by just about anything, from an asynchronous character arrival on a UART to a periodic timer interrupt. ISRs have the responsibility of acknowledging the hardware condition and provide the initial handling of data sent or received as required by the interrupt. An ISR often is responsible for providing the RTOS with information necessary to provide services to application threads. Examples include moving data into a buffer for processing, adding an entry to a queue for processing, setting a value to indicate that an event has occurred, and so on. Since application code execution is interrupted (delayed) during the execution of an ISR, most applications minimize the amount of code in the ISR and rely instead on non-ISR code (an application Thread or Task) to complete the processing. This allows the highest priority application code to be executed as quickly as possible, and delayed as little as possible, even in situations with intense interrupt activity. 2. RTOS Interrupt Architectures A fundamental challenge in RTOS design is supporting asynchronous access to internal RTOS data structures by interrupt routines and RTOS services. It cannot be allowed that, while modifying a data structure, a service or ISR gets interrupted and a different service or ISR makes unrelated modifications to the same structure, leaving it in a changed state for the original code to (unknowingly) continue modifying. The results can be catastrophic. All RTOSes must address this challenge and prevent multiple ISRs (or system calls) from modifying the same structure at the same time. Figure-1 In a Unified Interrupt Architecture, all interrupt-related processing is done in a single ISR, including any required system service calls There are at least two approaches, one used by the majority of RTOSes, and another used by a few. The more popular approach is to briefly lockout interrupts while an ISR or system service is modifying critical data structures inside the RTOS. This reliably prevents any other program from jumping in and making uncoordinated changes to the critical area being used by the executing code. This approach is called the Unified Interrupt Architecture because all interrupt processing is performed at one time, in a single, unified service routine (ISR). Figure-2 In a Segmented Interrupt Architecture, interrupt processing is split into multiple parts, to avoid system services from within an ISR Another, less popular approach is not to disable interrupts in system service routines, but instead (by rule or convention) not allow any asynchronous access to critical data structures by ISRs or other service calls. Service call access to critical data structures from an ISR is deferred to a secondary routine we denote ISR2, which gets executed along with application threads under scheduler control. This approach also reliably prevents interference with the actions of an executing system service call, by not allowing any threads or ISR2 routines, which might make system service calls, to execute until processing of critical data structures is completed. This approach is called a Segmented Interrupt Architecture, because it breaks up the processing required in response to an interrupt into multiple (usually 2) segments executed at different priorities. In this paper, we examine the performance implications of each approach on real-time system responsiveness. 2.1 Terminology The following is a list of symbols used to represent the processing performed in each type of RTOS interrupt architecture: Symbol Meaning CC: Context Create. Create context for ISR2. This typically involves creating a stack frame and alerting the scheduler to schedule it next. CR: Context Restore. Restore context of scheduled entity CS: Context Save. Saves the context of the running thread. ID: Interrupt Dispatcher. Applicable in single interrupt vector architectures like PowerPC, MIPS, and ARM. On architectures like ColdFire, this item is done in hardware. ISR: Interrupt Service Routine. Traditional ISR, allowed to interact with application threads through RTOS services. ISR1: Interrupt Service Routine, Part-1. Similar to traditional ISR, but not allowed to interact with RTOS. ISR2: Interrupt Service Routine, Part-2. Scheduled entity run in a thread or super-thread context. Allowed to interact with RTOS services and threads. ITRA:
[linuxkernelnewbies] RTOS Products for DSCs, DSPs and Microcontrollers | RoweBots
http://www.rowebots.com/embedded_system_software/rtos RTOS Products for DSCs, DSPs and Microcontrollers Embedded Operating Systems and Real-Time Operating Systems are really universally called an RTOS although strictly speaking they are slightly different. A real-time operating system has characteristics which allow it to respond in a minimal amount of time which is deterministic or bounded. In comparison, an embedded operating system is designed to run on an embedded system, which generally means that it runs from Flash memory. Unison and DSPnano are both real-time and embedded operating systems. By definition an operating system includes multi-threading or multi-tasking to share the processor, interrupt handling to speed device I/O, I/O abstractions for a broad set of devices to make programs independent of the underlying hardware, and resource management for memory and other forms of storage. It may also include other libraries for graphics, buffered character and file I/O, and a broad set of other devices. Often, users confuse the difference between a real-time kernel and a real-time operating system. A kernel has a subset of the real-time operating system capabilities, often not offering a universal I/O model and other associated buffered I/O libraries. The I/O subsystem is expected to be designed by the user in a proprietary way in a kernel based system. The reinvention of the I/O subsystem to build an RTOS from a kernel is very expensive in a variety of ways including: Learning required by each new developer Lack of documentation and clear semantics leading to errors using the environment Proprietary lock in Need to redevelop higher level libraries Inconsistent error codes and error handling in the I/O subsystem Internal maintenance requirements In the same way that an MCU is only 20% processor and 80% peripherals today, a complete RTOS is 20% kernel and 80% I/O, so by choosing only a kernel and building your own RTOS (or building the whole environment) you are undertaking 80% of the development and maintenance cost. Today, standards prevail in the world of operating systems of all types. From the Mac OSX through Windows to Linux, all operating systems today support POSIX standards and because Linux supports POSIX to the exclusion of other approaches, Linux compatibility becomes the standard. With RTOS products which use MMUs, this is also true with Wind River, Greenhills, QNX and others all supporting POSIX and moving towards Linux. In the smaller MCU world, where MMUs are not used, there is a problem. GPL excludes the use of Linux in this environment (loss of application code). The net result is that users have been using proprietary kernels and building their own I/O models, or using proprietary systems here. It is very expensive because it involves vendor lock in or internal expense for development. Rowebots provides very high quality RTOS products for DSPs, DSCs and microcontrollers which have the following characteristics: A complete embedded and real-time operating system No lock in Open source and commercial licenses Ultra tiny memory footprint Modularity and scalability POSIX compatibility Linux compatibility For open systems based RTOS products, see the Unison RTOS for 32 bit MCUs, DSCs and DSPs and see DSPnano for 8/16 bit MCUs, DSCs and DSPs. To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] Random LLVM Notes
http://nondot.org/sabre/LLVMNotes/ Random LLVM Notes About These documents are a random collection of notes that I have made while working on LLVM. None of them are official, they may be gibberish and not make sense, but they also might be useful. Many of these ideas will find their way into LLVM in some form or another, but nothing is guaranteed. :) If there is something here that interests you, and you would like to see it in LLVM sooner, rather than later, send an email to the LLVMdev list. We would be happy to help you when/if you run into trouble implementing it. Core IR Notes Sep 24, 2009 - Debug info for variables when optimizing. Jun 29, 2009 - Global Register Variables. Jun 15, 2009 - __builtin_unreachable for value assertion information - Implemented in Clang Sep 20, 2009. May 18, 2009 - Memory lifeness/immutability markers. Mar 25, 2009 - Extended Integer Function Results. Sep 19, 2008 - Improving Metadata in LLVM IR (debug info, annotations, TBAA, and front-end extensions). Apr 26, 2008 - Eliminating the 'Void' Type. Aug 25, 2004 - Improvements to EH support (PR1269). Aug 18, 2004 - "Relaxed" Floating Point support. Completed: [2.8] Half-Precision Floating Point. [2.7] Extensible Metadata in LLVM IR. [2.7] Indirect Goto Design. [2.6] Representing and optimizing arithmetic based on integer overflow. [2.6] LLVM Debug Info Line Numbers when optimization is enabled. [2.4] Aggregates as First Class Values - Finished July 2008. [2.3] Adding support for functions with multiple return values (and inline asm) (PR2095) - Finished Apr 2008. [2.0] Capturing alignment information in LLVM - Finished Apr 2007. [2.0] Core LLVM Type System Changes - Implemented Dec 2006. [1.7] Inline Assembly Support - Implemented Feb 2006. [1.7] CallGraph class cleanups - Implemented Dec 21, 2005. [1.5] Guaranteed Efficient Tail Calls - Implemented May 14, 2005. [1.5] Target-specific calling conventions - Implemented May 6, 2005. [1.4] The new LLVM 'unreachable' instruction - Implemented Oct 18, 2004. [1.4] New LLVM 'undef' value - Implemented Oct 16, 2004. Code Generator Notes Completed: [2.3] Revamping the LLVM code generator [1.4] Autogenerated asmwriter notes - Implemented Aug 11, 2004 Optimization Notes Stuff -instcombine should handle. Symbolic Constant Folding Opportunities: lib/VMCore/ConstantFolding.cpp Completed: [2.0] PassManager improvements and loop optimizer infrastructure notes - Implementation completed in Mar 2007. [2.0] PassManager improvements for an amazing Inliner - Implementation completed Jan 5, 2007. [1.5] Notes for interprocedural SCCP (LLVM PR#415) - Implemented Dec 11, 2004. [1.6] Evaluating static ctors at compile time - Implemented Sep 26, 2005.. Random Source Language Implementation Notes Jun 24, 2005 - Implementing Portable sizeof, offsetof, and Variable Sized Structures in LLVM Jul 27, 2004 - MSIL Object Model Implementation - vtables and typeinfo Jul 27, 2004 - MSIL Object Model Implementation - interfaces Sep 5, 2004 - Explicitly managed stack frames - e.g. GC'd stack frames. Benchmarks to add to llvm-test A variety of C++ benchmarks BioPerf SciMark 2.0 (C and Java) LLC bench nbench Robert Scott Ladd's more. DDJ benchmarks. DSPstone. UTDSP: restricted? Netbench CAD stuff MediaBench SPLASH parallel benchmarks MiBench Sparc Benchmarks SUSAN program C++ vs Java more more To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] Developer Guides and Manuals | AMD Developer Central
http://developer.amd.com/documentation/guides/Pages/default.aspx BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh Processors PDF 10/31/2009 BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h Processors PDF 09/09/2009 Software Optimization Guide for AMD Family 10h Processors (Quad-Core, Six-Core) PDF 05/21/2009 Basic Performance Measurements for AMD Athlon 64, AMD Opteron and AMD Phenom Processors (Paul J. Drongowski) PDF 09/25/2008 BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors PDF 07/30/2008 Compiler Usage Guidelines for AMD64 Platforms PDF 09/12/2007 ATI Radeon HD2000 Programming Guide (Emil Persson) PDF 07/03/2007 Surviving and Thriving in a Multi-Core World (Peter Aitken, Alan Zeichick) PDF 11/08/2006 BIOS and Kernel Developer's Guide for AMD Athlon 64 and AMD Opteron Processors PDF 02/01/2006 AMD Athlon 64 FX-60 Processor Competitive Performance Guide PDF 01/01/2006 Software Optimization Guide for AMD64 Processors PDF 10/25/2005 AMD Athlon 64 Processor Competitive Performance Guide PDF 10/19/2004 Builder's Guide for AMD Athlon 64 Processor-Based Desktops and Workstations PDF 09/16/2004 Mobile AMD Athlon 64 Processor 3400+ Competitive Performance Guide PDF 08/01/2004 AMD CoolnQuiet Technology Installation Guide PDF 06/01/2004 Builders guide for AMD Opteron Processor-Based Servers and Workstations PDF 02/06/2004 Back to top Manuals Format Date AMD64 Architecture Programmer's Manual Volume 5: 64-Bit Media and x87 Floating-Point Instructions PDF 12/14/2009 AMD64 Architecture Programmer's Manual Volume 6: 128-Bit and 256-Bit XOP and FMA4 Instructions PDF 11/01/2009 AMD64 Architecture Programmer's Manual Volume 3: General Purpose and System Instructions PDF 11/01/2009 AMD64 Architecture Programmer's Manual Volume 2: System Programming PDF 11/01/2009 AMD64 Architecture Programmer's Manual Volume 1: Application Programming PDF 11/01/2009 AMD64 Architecture Programmer's Manual Volume 4: 128-Bit Media Instructions PDF 09/30/2007 Back to top Revision Guides Format Date Revision Guide for AMD Family 10h Processors PDF 02/12/2010 Revision Guide for AMD NPT Family 0Fh Processors PDF 09/22/2009 Revision Guide for AMD Athlon 64 and AMD Opteron Processors PDF 07/20/2009 Revision Guide for AMD Family 11h Processors PDF 07/30/2008 AMD-8132 HyperTransport PCI-X 2.0 Tunnel Revision Guide PDF 05/15/2008 AMD-8151 HyperTransport AGP3.0 Graphics Tunnel Revision Guide PDF 08/31/2005 AMD-8131 HyperTransport PCI-X Tunnel Revision Guide PDF 08/31/2005 AMD-8111 HyperTransport I/O Hub Revision Guide PDF 08/31/2005 AMD-8131 HyperTransport PCI-X Tunnel Revision Guide PDF 08/31/2005 Back to top Chipset Guides and Datasheets Format Date AMD RS780 Register Programming Requirements PDF 07/08/2009 AMD RS780 ASIC Family Register Reference Guide PDF 07/08/2009 AMD RS780 ASIC Family BIOS Developers Guide PDF 07/08/2009 AMD RS780E Databook PDF 07/08/2009 AMD SB700/710/750 Register Reference Guide PDF 07/08/2009 AMD SB700/710/750 BIOS Developers Guide PDF 07/08/2009 AMD SB700/710/750 Register Programming Requirements PDF 07/08/2009 AMD SB710 Databook PDF 07/08/2009 Back to top ATI Stream SDK Documentation Format Date ATI Stream SDK Installation Notes (v2.01) PDF 2010 ATI Stream SDK Developer Release Notes (v2.01) PDF 2010 ATI Stream SDK Samples Release Notes (v2.01) PDF 2010 ATI Stream SDK Frequently Asked Questions (FAQ) (v2.01) PDF 2010 ATI Stream SDK Getting Started Guide (v2.01) PDF 2010 OpenCL 1.0 Specification (revision 48) PDF 2010 ATI Stream SDK
[linuxkernelnewbies] kprobes: Kprobes jump optimization support [LWN.net]
http://lwn.net/Articles/373314/ Here are the patchset of the kprobes jump optimization v9 (a.k.a. Djprobe). This version includes some bugfixes, enhancements, and applicable for 2.6.33-rc6-tip. This version of patch series uses text_poke_smp() which update kernel text by stop_machine(). That is 'officially' supported on Intel's processors. text_poke_smp() can't be used for modifying NMI code, but, fortunately:), kprobes also can't probe NMI code. Thus, kprobes jump-optimization can use it. Int3-bypassing method (text_poke_fixup()) is still unofficial and we need to get more official answers from x86 vendors. I'd like to push it after this series of patches are merged. Anyway, thanks Mathieu and Peter, for helping me to implement it and organizing discussion points about int3-bypass XMC! These patches can be applied on the latest -tip. Changes in v9: - Fix a bug to optimize probe when enabling. - Check nearby probes can be optimize/unoptimize when disarming/arming kprobes, instead of registering/unregistering. This will help kprobe-tracer because most of probes on it are usually disabled. - Use *_text_reserved() for checking the probe can be optimized. - Verify jump address range is in 2G range when preparing slot. - Backup original code when switching optimized buffer, instead of preparing buffer, because there can be int3 of other probes in preparing phase. - Check kprobe is disabled in arch_check_optimized_kprobe(). - Strictly check indirect jump opcodes (ff /4, ff /5). And kprobe stress test didn't found any regressions - from kprobes, under kvm/x86. TODO: - Support NMI-safe int3-bypassing text_poke. - Support preemptive kernel (by stack unwinding and checking address). How to use it = The jump replacement optimization is transparently done in kprobes. So, if you enables CONFIG_KPROBE_EVENT(a.k.a. kprobe-tracer) in kernel config, you can use it via kprobe_events interface. e.g. # echo p:probe1 schedule /sys/kernel/debug/tracing/kprobe_evnets # cat /sys/kernel/debug/kprobes/list c069ce4c k schedule+0x0[DISABLED] # echo 1 /sys/kernel/debug/tracing/events/kprobes/probe1/enable # cat /sys/kernel/debug/kprobes/list c069ce4c k schedule+0x0[OPTIMIZED] Note: Which probe can be optimized is depends on the actual kernel binary. So, in some cases, it might not be optimized. Please try to probe another place in that case. Jump Optimized Kprobes == o Concept Kprobes uses the int3 breakpoint instruction on x86 for instrumenting probes into running kernel. Jump optimization allows kprobes to replace breakpoint with a jump instruction for reducing probing overhead drastically. o Performance An optimized kprobe 5 times faster than a kprobe. Optimizing probes gains its performance. Usually, a kprobe hit takes 0.5 to 1.0 microseconds to process. On the other hand, a jump optimized probe hit takes less than 0.1 microseconds (actual number depends on the processor). Here is a sample overheads. Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (without debugging options, with text_poke_smp patch, 2.6.33-rc4-tip+) x86-32 x86-64 kprobe: 0.80us 0.99us kprobe+booster: 0.33us 0.43us kprobe+optimized: 0.05us 0.06us kprobe(post-handler): 0.81us 1.00us kretprobe : 1.10us 1.24us kretprobe+booster: 0.61us 0.68us kretprobe+optimized: 0.33us 0.30us jprobe: 1.37us 1.67us jprobe+booster: 0.80us 1.10us (booster skips single-stepping, kprobe with post handler isn't boosted/optimized, and jprobe isn't optimized.) Note that jump optimization also consumes more memory, but not so much. It just uses ~200 bytes, so, even if you use ~10,000 probes, it just consumes a few MB. o Usage Set CONFIG_OPTPROBES=y when building a kernel, then all *probes will be optimized if possible. Kprobes decodes probed function and checks whether the target instructions can be optimized(replaced with a jump) safely. If it can't be, Kprobes just doesn't optimize it. o Optimization Before preparing optimization, Kprobes inserts original(user-defined) kprobe on the specified address. So, even if the kprobe is not possible to be optimized, it just uses a normal kprobe. - Safety check First, Kprobes gets the address of probed function and checks whether the optimized region, which will be replaced by a jump instruction, does NOT straddle the function boundary, because if the optimized region reaches the next function, its caller causes unexpected results. Next, Kprobes decodes whole body of probed function and checks there is NO indirect jump, NO instruction which will cause exception by checking exception_tables (this will jump to fixup code and fixup code jumps into same function body) and NO near jump which jumps into the optimized region (except the 1st byte of jump), because if some jump instruction jumps into the middle of another instruction, it causes unexpected results too. Kprobes also measures the length of
[linuxkernelnewbies] Herzelinux - Herzelia Linux Developers User Group (Linux programming, embedded Linux, Linux kernel)
http://tuxology.net/herzelinux/ Forums Courses Programming Embedded Linux Advanced Embedded Linux Debugging Linux Applications Linux Internals Linux Network Internals Lectures Google Android Open Source Phone Stack Initramfs boot your Linux WELL Linux Virtualization from Xen to KVM Soft, Hard and Ruby Hard Real Time Approaches with Linux The Good, the bad and the ugly: on threads, processes and coprocesses Crash and burn: Writing Linux application fault handlers Splice, Tee VMsplice: zero copy in Linux Schedule News Contact Herzelinux Herzelinux lectures Accerciser 15 Minutes A Day For Better Accessibility Adjusting Eclipse/CDT for your needs GCC Profile Guided Optimization IPv6 in the Linux kernel Linux Kernel Networking Routing Subsystem Linux Wireless The Strinx Library To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] Tuxology - a Linux embedded, kernel and training blog
http://tuxology.net/courses/linux-internals/ Linux Internals Tuxology team May 15th, 2008 Overview This course focuses on the basic elements of the Linux kernel, which allow programmers to build modules and device drivers. The students will gain a general understanding of the basic tools and interfaces, in order to successfully modify features and develop new aspects of the kernel. Major topics include full code examples and hands on exercises. The course is based on kernel 2.6. Skills On completion, delegates will be able to: Explain the core elements of the Linux kernel Be able to modify and build a new modified kernel Be able to modify the Linux boot loader Build complex kernel modules Debug a kernel module and a kernel oops Explain the way the kernel manages memory Explain the use of interrupt handlers Understand the flow between user space and kernel space Write character device modules Write simple block device modules Write network device modules Audience Programmers, software designers, and technical managers who plan to use Linux below the application level and to develop kernel space modules and device drivers Prerequisites Advanced UNIX Programming is recommended. Strong C programming skills and an intermediate knowledge of UNIX/Linux shell commands are required UNIX/Linux application development experience is recommended Content Introduction to the Linux kernel The system boot process LILO, GRUB and the MBR Linux kernel session overview What is a device driver Kernel configuration and compilation Building the kernel Programming concepts The sysctl utility Ways of debugging a module and a kernel oops Writing a Simple Kernel Module A simple kernel module structure Implicit steps of compiling modules in Linux kernel version 2.6 Using shell commands to manipulate modules Using the printk function The do-while(0) idiom Runtime Information Passing parameters to the module Exporting symbols The /proc file system Memory Management Memory areas Memory page frames Requesting and releasing page frames Allocating contiguous virtual memory area The slab allocator Memory caches and allocations Managing slabs Creating and destroying caches User space memory access Interrupt Handling Hardware interrupt handling basics Interrupt handler and control Low level handling Wait queues technique Bottom Halves Differing work Using software interrupts Tasklets Timers RTC Work queues Locking Mechanisms Locking requirements Preemption Atomic bit operations Interrupt disabling Spin locks Semaphores Implementing a character device file The VFS structure Initialization and termination Opening the device file IOCTL Implementing base operations Block Device Drivers Registration and un-registration RAMFS manipulations Adding a new simple file system Low level hardware geometry Network device drivers The layer model Registration and un-registration Socket buffers, allocations and manipulations Network headers Softnet basics Packet reception Packet transmission Network device allocation Device initialization NAPI Writing a simple dummy device module Detecting a PCI device Finding hardware registration information Hardware considerations Initializing device operation MAC address The xmit function Network queues Slides Linux Internals Upload a Document to Scribd Read this document on Scribd: Linux Internals Usage Rights The course materials were created by the following authors: Original course slides Michael Opdenacker from Free Electrons Networking slides Oron Peled Additional slides and material by Gilad Ben-Yossef, Codefidence ltd. Tux Image Copyright: 1996 Larry Ewing Linux is a registered trademark of Linus Torvalds. All other trademarks are property of their respective owners. To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] Linux Skb PDF | Download Free Ebook Linux Skb
http://openpdf.com/ebook/linux-skb-pdf.html
Linux TX Multiqueue
Implementation
New Design. Implementation Notes. Linux TX Multiqueue
Implementation. David S. Miller. Red Hat Inc. Seattle, 2008 ...
Implementation Notes. PICTURE OF TX ENGINE. QDISC. dev_queue_xmit()
-. dev-queue_lock. hard_start_xmit. TX lock. set SKB
queue mapping. DRIVER. TXQ TXQ TXQ ... Existing Design. New Design.
Implementation Notes. PICTURE WITH NON-TRIVIAL QDISC. TXQ. TXQ. TXQ.
qdisc. -q.lock. TX lock. TX lock. TX lock. SKB. skb.
driver. SKB ...
File name: davem_seattle08.pdf
Search: linux multiqueue implementation
Linux-Kernel:
[PATCH][RFC] 2.6.6 ppp_synctty.c
skb_trim(skb, 0);. + skb_queue_tail(aprqueue, skb);.
} } . To unsubscribe from this list: send the line "unsubscribe linuxkernel"
in ...
File name: 0531.pdf
Search: linux kernel patch synctty
ANALYZING
AND OPTIMIZING THE LINUX NETWORKING STACK
by R Bolla - Related articlesin this work is to analyze and to
optimize the Linux networking stack perfor-. mance, trying to
evaluate the impact of networking functionalities on the whole. system.
To ... Analyzing and Optimizing the Linux Networking Stack.
191. A packet is processed in the same NET RX SoftIRQ, till it is
enqueued in an ... [12] Skb recycling patch,
ftp://robur.slu.se/pub/Linux/net-development/skb
recycling/. [13] K. Wehrle, F. Phlke, H. Ritter, D. Mller, M ...
File name: V482G53118598173.pdf
Search: analyzing
optimizing linux networking stack
Microsoft PowerPoint - linux-ip
salu...@lut.fi. 2. Preface. We will study linux
networking for the. following case: Intel x86 architecture. IP
packets. Recent stable linux kernel series 2.4.x ... Linux
Network Layers. BSD sockets layer. provides standard UNIX. sockets
API. INET layer manages. communication end. points for the IP based
... journey-2.4.html. 5. H. Welte. Skb Linux
network buffers. 2000. http://www.gnumonks.org/ftp/pub/doc/skb-.
doc.html.
File name: linux-ip.pdf
Search: microsoft
powerpoint linux
Discover
>From Your Favorite Topic or Web Page: www.ecsl.cs.sunysb
[Discover] Linux Kernel Newbies - Linux Kernel
Newbies http://kernelnewbies.org/ (programming kernel tutorial linux)
[Discover] Linux Device Drivers, 3rd ... [Discover] Something
like a home page http://people.redhat.com/drepper/ (linux
programming kernel architecture) [Discover] The Linux kernel
http ... [Discover] skb - Linux network buffers
http://ftp.gnumonks.org/pub/doc/skb-doc.html (kernel linux
skb network) [Discover] Linux Cross-Reference http ...
File name: LinuxKernel.pdf
Search: discover
favorite topic sunysb
Performance
Analysis of Embedded Linux ATM for MPC8260 and Derivatives
by AN Meliones - 2006 - Cited by 1 - Related articlesLinux
ATM on the MPC8260 communications proces-. sor and derivative CPUs.
UTOPIA and serial ATM. performance is extensively evaluated, including
IP. routing/forwarding between LAN and WAN ... The engineering analysis
of Embedded Linux ATM. for the MPC8260 family of network
processors is pre-. sented in [2]. There ... skb to Linux
ATM vcc. Set BD empty sending. of irq after refilling. Report
reception errors . update channel statistics. Push skb up
to ATM ...
File name: 01691014.pdf?arnumber=1691014
Search: performance
analysis embedded linux derivatives
Using
Uncacheable Memory to Improve Unity Linux Performance
by N Qu - Cited by 1 - Related articlesin Unity Linux.
Second it helps avoiding cache pollution. during TCP/IP processing. We
apply uncacheable memory in. two aspects, the uncacheable page table
and the uncacheable. socket buffer (skb) in our operating system
... IMPROVE UNITY LINUX PERFORMANCE USING. UNCACHEABLE MEMORY.
In Unity Linux we solve the cache coherency problem ... 2)
Uncacheable skb: The socket buffer (skb) is used to.
represent a packet in the TCP/IP stack of Linux. In general ...
File name: paper5.pdf
Search: using uncacheable memory improve unity linux performance
The journey of a
packet through the linux 2
This document describes the journey of a network packet inside the linux
kernel 2.4.x. This has. changed drastically since 2.2 because the
globally serialized bottom half was abandoned in favor of ... If the
driver didn't already timestamp the skb, it is timestamped now.
Afterwards the skb gets enqueued ... After enqueuing the skb
the receive softinterrupt is marked for execution via. include/linux/interrupt.h:__cpu_raise_softirq().
...
File name:
The%20Journey%20of%20a%20Packet%20Through%20the%20Linux%20Network%20Stack.pdf
Search: journey
packet through linux
IP
Layer Input Packet Processing (continuation) The ip_rcv_finish
The value of skbdst will typically (always?) be NULL if
the packet was received from the. outside world. When this is the case,
ip_route_input() is called ... It describes how the packet travels.
inside Linux networking. 317 */. 318 if (skbdst ==
NULL) {. 319. if
[linuxkernelnewbies] Linux TX Multiqueue Implementation
http://vger.kernel.org/~davem/davem_seattle08.pdf To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] WIOV 2010 - Accepted Papers
http://sysrun.haifa.il.ibm.com/hrl/wiov2010/accepted.html Redesigning Xen's Memory Sharing Mechanism for Safe and Efficient I/O Virtualization Kaushik Kumar Ram (Rice University), Jose Renato Santos and Yoshio Turner (HP Labs). A Network Interface Card Architecture for I/O Virtualization in Embedded Systems Holm Rauchfuss, Thomas Wild and Andreas Herkersdorf (Technische Universitat Munchen). SLIM: Network Decongestion for Storage Systems Madalin Mihailescu, Gokul Soundararajan and Cristiana Amza (University of Toronto). Ally: OS-Transparent Packet Inspection Using Sequestered Cores Jen-Cheng Huang (Georgia Tech), Matteo Monchiero and Yoshio Turner (HP Labs). I/O Virtualization Bottlenecks in Cloud Computing Today Jeffrey Shafer (Rice University). On Disk I/O Scheduling in Virtual Machines Mukil Kesavan, Ada Gavrilovska and Karsten Schwan (Georgia Institute of Technology). Architectural support for user-level network interfaces in heavily virtualized systems Florian Auernhammer and Patricia Sagmeister (IBM Research). Power Aware I/O Virtualization Kun Tian and Yaozu Dong (Intel). To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] Linux kernel documents at vger.kernel.org
PDF] XFRM Interface Experiences, Dislikes and Suggested Changes File Format: PDF/Adobe Acrobat - Quick View Motivation. Frustration with the structuring came as a result of looking at: MIBS, Forces LFB semantics. Other Vendors who map nicely to the above ... vger.kernel.org/netconf2005_jamal.pdf - Similar [PDF] Netfilter:Making large iptables rulesets scale File Format: PDF/Adobe Acrobat - Quick View 10Gbit/s Bi-Directional Routing on standard hardware running Linux by. Jesper Dangaard Brouer h...@comx.dk. Master of Computer Science ... vger.kernel.org/.../LinuxCon2009_JesperDangaardBrouer_final.pdf - Similar [PDF] recvmmsg File Format: PDF/Adobe Acrobat - Quick View Why? . Finantial Institutions . Trading . Lots of small packets . Multicast . Reducing cost of net stack entry/exit. Page 3. How? ... vger.kernel.org/netconf2009_slides/recvmmsg.pdf - Similar [PDF] Linux Multiqueue Networking File Format: PDF/Adobe Acrobat - Quick View Linux. Multiqueue. Networking. David. S. Miller. Background. RX. Multiqueue. TX. Multiqueue. Application- based and. SW Steering ... vger.kernel.org/~davem/davem_nyc09.pdf - Similar [PDF] IPv6 Development Status 2005 File Format: PDF/Adobe Acrobat - Quick View IPv6 Development Status 2005. YOSHIFUJI Hideaki. yoshf...@linux-ipv6.org. Keio University / USAGI/WIDE Project. Copyright (C)2005 USAGI/WIDE Project. ... vger.kernel.org/netconf-2005-usagi.pdf [PDF] Netconf 2005 File Format: PDF/Adobe Acrobat - Quick View What we hear/got dst cache overflow reports. RCU related mistuned, misunderstod etc. fib_lookup complaints what to expect. BSD comparisons. Radix-tree ... vger.kernel.org/netconf-RO-2005.pdf [PDF] Horizonatal Scaling and it's Implications for the Linux Networking File Format: PDF/Adobe Acrobat - Quick View Microprocessor History. Network Principles. Implications. Linux Kernel Horizontal Network Scaling. Horizonatal Scaling and it's Implications for the ... vger.kernel.org/~davem/davem_tokyo08.pdf [PDF] Linux TX Multiqueue Implementation File Format: PDF/Adobe Acrobat - Quick View Background. Existing Design. New Design. Implementation Notes. Linux TX Multiqueue Implementation. David S. Miller. Red Hat Inc. Seattle, 2008 ... vger.kernel.org/~davem/davem_seattle08.pdf - Similar [PDF] Bridging - 7:58am File Format: PDF/Adobe Acrobat - Quick View RSTP. Rapid Spanning Tree Protocol. Code based on rstplib. Stagnant. No distro. Code from EMC. Certification tested ... vger.kernel.org/netconf2009_slides/bridge-netconf2009.pdf [PDF] Single-flow, uni-directional workload, 64-byte frame size, 100 ... - 7:58am File Format: PDF/Adobe Acrobat - Quick View 0 to 0. 0 to 1. 0 to 2. 0 to 7. 0 to 8. 0 to 9 0 to 15 8 to 0. 8 to 1. 8 to 7. 8 to 8. 8 to 9 8 to 10 8 to 15. IRQ affinity: rx to tx ... vger.kernel.org/netconf2009_slides/nehalem_pps_comparison.pdf [PDF] Microsoft PowerPoint - netconf2006-v1.5 File Format: PDF/Adobe Acrobat - Quick View Linux TCP/IP Performance on Long Fat-pipe Network toward. Internet2 Land Speed Record. Junji Tamatsukuri, Takeshi Yoshino,. Yutaka Sugawara, Mary Inaba, ... vger.kernel.org/netconf2006-junji-v1.5.pdf [PDF] DCCP update File Format: PDF/Adobe Acrobat - View as HTML Background. DCCP is thanks to Arnaldo (OLS 2005). pluggable framework. based on TCP abstractions. since then many different contributors ... vger.kernel.org/netconf2009_slides/dccp_nc_slides.pdf [PDF] Following is the data that I was able to collect last week ... File Format: PDF/Adobe Acrobat - Quick View Following is the data that I was able to collect last week regarding our 64-bit/NUMA agenda. Observe the trending in the last two lines of the table: unless ... vger.kernel.org/netconf2009_slides/update.pdf [PDF] Directions in SELinux Networking File Format: PDF/Adobe Acrobat - View as HTML Directions in SELinux Networking. Linux Kernel Networking Summit. Montral, Canada. July 2005. James Morris jmor...@redhat.com ... vger.kernel.org/ns2005.pdf You have removed results from this search. Hide them Loading... To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] Re: Process ID and App Name
not sure how u wrote your module.want to post your code here?
From kernel/timer.c:
373 void __timer_stats_timer_set_start_info(struct timer_list *timer,
void *addr)
374 {
375 if (timer-start_site)
376 return;
377
378 timer-start_site = addr;
379 memcpy(timer-start_comm, current-comm, TASK_COMM_LEN);
380 timer-start_pid = current-pid;
381 }
the answer is obvious..i suspect u got your global variable
current wrongly.
look into:
./arch/x86/kernel/cpu/common.c:
EXPORT_PER_CPU_SYMBOL(current_task);
u can see that current_task is per-CPU and is exported, ie,
different CPU may be executing different task.
so, from ./Documentation/uml/UserModeLinux-HOWTO.txt:
(gdb) p current_task.pid
(gdb) p current_task.prev_task.comm
(gdb) p current_task.prev_task.thread
Or inside your kernel modulejust do current_task-comm will do, as
the symbol is exported.
But I cannot find EXPORT declaration for current, so your kernel
module cannot access the global variable directly - roundabout way
needed.
But if you compile your codes + kernel together, NOT USING KERNEL
MODULE, then access any global variable (eg, current) is possible.
On Mar 22, 10:42 am, perumal316 perumal...@gmail.com wrote:
Hi,
Is there any way to get the current process ID and the corresponding
name of the application from the kernel module?
I have tried using task-comm ,task-pid, current-pid etc But I am
not getting the correct process ID.
I want to printk the process ID and the application name each time a
system call is called. System call should have a way to identify which
process ID or application is calling it.
Any other way to printk the process ID and the application name?
Thanks In Advance,
Perumal
To unsubscribe from this group, send email to
linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.
[linuxkernelnewbies] WWW Computer Architecture Page
http://pages.cs.wisc.edu/~arch/www/ What's Computer Architecture? Computer Architecture is the science and art of selecting and interconnecting hardware components to create computers that meet functional, performance and cost goals. Computer architecture is not about using computers to design buildings. What's New Updates 2009.11: Call for papers: JPDC NoCs - Special Issue in Journal of Paralllel and Distributed Computing (JPDC) on Network-on-Chips (NoCs) PACT 2010 - Parallel Architectures and Compilation Techniques (PACT) in Vienna CAC 2010 - 10th Workshop on Communication Architecture for Clusters MCSoC-1 - 5th International Symposium on Embedded Multicore Systems-on-Chip, in conjuction with ICPP-2010 SOCC 2010 ACM Symposium on Cloud Computing NOCS 2010 - 4th ACM/IEEE International Symposium on Networks-on-Chip Call for participation: Tutorial: Integrated Multi-core Modeling Updates 2009.08: Call for papers: LCTES 2010 - ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems ISCA 2010 - ISCA 2010: International Symposium on Computer Architecture ANCS 2009 - ACM/IEEE Symposium on Architectures for Networking and Communications Systems CGO 2010 - 8th International IEEE/ACM International Symposium on Code Generation and Optimization Embedded Systems at 25th ACM SAC - Track on Embedded Systems at 25th ACM Symp. on Applied Computing CBHPC 2009 - 2009 Workshop on Component-Based High Performance Computing (CBHPC 2009) GROW 2010 - 2nd International Workshop on GCC Research Opportunities (GROW'10) IJHPSA - Special Issue on Power-Efficient, High Performance General Purpose and Application Specific Computing Architectures WBIA 2009 - Workshop on Binary Instrumentation Systems and Analaysis Multiprog 2010 - Third Hipeac Workshop on Programmability Issues for Multi-Core Computers CF 2010 - ACM International Conference on Computing Frontiers LCA-GPGPU I - First workshop on language, compiler, and architecture support for GPGPU NoCArc 2009 - Second International Workshop on Network on Chip Architectures Call for posters: CF 2010 - ACM International Conference on Computing Frontiers Call for participation: Call for Posters: PACT'09 - Call for Posters at PACT'09 and students research competition Updates 2009.06: Call for papers: HPCA 2010 - 16th International Symposium on High-Performance Computer Architecture CFP: PDP 2010 - 18th Euromicro Parallel, Distributed and network-based Processing 2010, Pisa, Italy 10th MEDEA Workshop - MEmory performance: DEaling with Applications, systems and architecture CARD-2009 - Workshop on Computer Architecture Research Directions (with ISCA-09) StreamPPOT - Embedded Streaming: Parallel Programming, Optimizations and Tools ASPLOS XV - Fifteenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS '10) HiPEAC 2010 - 5th International Conference on High Performance and Embedded Architectures and Compilers Books: Synthesis Lecture on Fault Tolerant Computer Architecture - A new Synthesis Lecture on "Fault Tolerant Computer Architecture", by Daniel J. Sorin Call for posters: Call for Posters: PACT'09 - Call for Posters at PACT'09 and students research competition Updates 2009.04: Call for papers: AMAS-BT - Arch/Uarch support for binary translation workshop (with ISCA) ICCD 2009 - Int'l Conf. on Computer Design (ICCD) HeteroPar'2009 - 7th International Workshop on Algorithms, Models and Tools for Parallel Computing on Heterogeneous Platforms (CFP) The Computer Journal - Special Issue on Architecture/OS Support for Embedded Multi-Core Systems Call for participation: ISPASS 2009 - IEEE International Symposium on Performance Analysis of Systems and Software Tools: TD-Bench - framework for design space exploration (DSE) of embedded processors Updates 2009.03: Call for papers: NetEval-1 - The First Workshop on Performance Evaluation of Next-Generation Networks WDDD - 2009 - The Annual Workshop on Duplicating, Deconstructing, and Debunking Call For Papers: PESPMA 2009 - 2nd Workshop on Parallel Execution of Sequential Programs on Multi-core Architectures HPPC 2009 - 3rd full-day Workshop on Highly Parallel
[linuxkernelnewbies] Main Page - ARM Linux Internet Platform
http://linux.onarm.com/index.php/Main_Page ARM Linux Internet Platform This site provides Open Source components, middleware and utilities used to build a Linux Mobile software stack on ARM. These include Linux kernel, libraries, utilities, multimedia components and Mozilla and Webkit web browsers to provide a rich Internet experience on ARM powered devices. News 2010-03-08: We released the fourth version of the ARM Linux Internet Platform (ALIP): generic-4, with Updated software components (aligned with GMAE 2.28.2). Qt 4.6.2 with NEON support Xorg 7.5 support for Zoom2 See the generic-4 Release notes See older news in the News archives. Software The software provided on this site includes patches and source code used to generate images that can be run on ARM reference platforms listed in section Platforms, including: Linux operating system Application framework based on the GNOME Mobile Platform Multimedia framework (GStreamer) WebKit and Mozilla web browsers and plug-ins Base user interface Components available on this site are available under the terms of an open source license as defined in http://www.opensource.org/docs/osd. Please consult TermsAndConditions for the terms of use of this website. Components have their own homepage, discussion forums and developer community to which developers are encouraged to participate and contribute. This site does not intend to duplicate or replace this. Please visit the User Guide page for instructions on how to get started with building software for the Platforms listed on this site. Related projects Busybox: http://www.busybox.net/ Cairo: http://cairographics.org/ D-BUS http://www.freedesktop.org/Software/dbus Debian: http://www.debian.org GNOME http://www.gnome.org GStreamer http://gstreamer.freedesktop.org/ GTK http://www.gtk.org/ HAL: http://www.freedesktop.org/wiki/Software/hal Linux http://www.kernel.org/ Maemo http://maemo.org MatchBox Windows Manager: http://projects.o-hand.com/matchbox/ Mozilla http://www.mozilla.org and http://wiki.mozilla.org/Mobile Webkit http://webkit.org/ OpenEmbedded: http://www.OpenEmbedded.org SCIM: http://www.scim-im.org/ Scratchbox http://www.scratchbox.org Xserver: http://www.freedesktop.org/wiki/Software/Xserver Credits This site has been created in cooperation with Movial. To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] Re: CPU Status and temperature
David Gutierrez wrote:
Hello,
Do any one knows where I can get some tools which measure the CPU
Temperature.
David
Hotmail is redefining busy with tools for the New Busy. Get more
from your inbox. Sign up now.
Temperature reporting is dependent on the specific capabilities of the
motherboard, see Documentation/hwmon/adm1021 for an example - this
documents the temperature sensors for Intel Xeon processors.
Under the hwmon subdirectories are the implementation for the different
temperature sensing for different CPUs:
In drivers/hwmon:
coretemp.c k10temp.c k8temp.c via-cputemp.c
Via ACPI you can also get the temperature for the CPU, for example
drivers/acpi/thermal.c:
249 static int acpi_thermal_get_temperature(struct acpi_thermal *tz)
250 {
251 acpi_status status = AE_OK;
252 unsigned long long tmp;
253
254 if (!tz)
255 return -EINVAL;
256
257 tz-last_temperature = tz-temperature;
258
259 status = acpi_evaluate_integer(tz-device-handle,
"_TMP", NULL, tmp);
260 if (ACPI_FAILURE(status))
261 return -ENODEV;
262
263 tz-temperature = tmp;
264 ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Temperature is %lu dK\n",
265 tz-temperature));
266
267 return 0;
268 }
This is because ACPI specs has a requirement:
24 *
25 * This driver fully implements the ACPI thermal policy as
described in the
26 * ACPI 2.0 Specification.
27 *
28 * TBD: 1. Implement passive cooling hysteresis.
29 * 2. Enhance passive cooling (CPU) states/limit interface
to support
30 * concepts of 'multiple limiters', upper/lower limits,
etc.
31 *
32 */
33
51
52 #define ACPI_THERMAL_CLASS "thermal_zone"
53 #define ACPI_THERMAL_DEVICE_NAME "Thermal Zone"
54 #define ACPI_THERMAL_FILE_STATE "state"
55 #define ACPI_THERMAL_FILE_TEMPERATURE "temperature"
56 #define ACPI_THERMAL_FILE_TRIP_POINTS "trip_points"
57 #define ACPI_THERMAL_FILE_COOLING_MODE "cooling_mode"
58 #define ACPI_THERMAL_FILE_POLLING_FREQ "polling_frequency"
59 #define ACPI_THERMAL_NOTIFY_TEMPERATURE 0x80
60 #define ACPI_THERMAL_NOTIFY_THRESHOLDS 0x81
61 #define ACPI_THERMAL_NOTIFY_DEVICES 0x82
62 #define ACPI_THERMAL_NOTIFY_CRITICAL 0xF0
63 #define ACPI_THERMAL_NOTIFY_HOT 0xF1
64 #define ACPI_THERMAL_MODE_ACTIVE 0x00
65
66 #define ACPI_THERMAL_MAX_ACTIVE 10
67 #define ACPI_THERMAL_MAX_LIMIT_STR_LEN 65
68
69 #define _COMPONENT ACPI_THERMAL_COMPONENT
70 ACPI_MODULE_NAME("thermal");
71
72 MODULE_AUTHOR("Paul Diefenbaugh");
73 MODULE_DESCRIPTION("ACPI Thermal Zone Driver");
74 MODULE_LICENSE("GPL");
75
etc etc.
Not sure if these are enough to get you going?
To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] uprobes patch - Google Search
LKML: Srikar Dronamraju: [RFC] [PATCH 0/7] UBP, XOL and Uprobes 11 Jan 2010 ... Subject: [RFC] [PATCH 6/7] Uprobes Documentation Subject: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes This patchset is based on ... lkml.org/lkml/2010/1/11/92 - Cached LKML: Srikar Dronamraju: [RFC] [PATCH 6/7] Uprobes Documentation 11 Jan 2010 ... Subject, [RFC] [PATCH 6/7] Uprobes Documentation ... +Uprobes enables you to dynamically break into any routine in a ... lkml.org/lkml/2010/1/11/99 - Cached Show more results from lkml.org [PDF] Uprobes: User-Space Probes File Format: PDF/Adobe Acrobat - Quick View quiesce callback for breakpoint insertion/removal. Uprobes patch modifies only Makefiles and Kconfigs. Uprobes is currently packaged with the ... events.linuxfoundation.org/slides/lfcs09_keniston.pdf [PDF] utrace: a new in-kernel API for debugging and tracing user tasks File Format: PDF/Adobe Acrobat - Quick View utrace patch touches tracehook.h (#ifdef CONFIG_UTRACE) ... Uprobes (Jim Keniston et al). Systemtap. kmview (Renzo Davoli) ... events.linuxfoundation.org/slides/lfcs09_mcgrath.pdf Show more results from events.linuxfoundation.org Re: [RFC] [PATCH 4/7] Uprobes Implementation - msg#00089 - linux ... This patch provides the core implementation of uprobes. This patch builds on utrace infrastructure. You need to follow this up with the uprobes patch ... osdir.com/ml/linux-kernel/2010-01/msg00089.html - Cached Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes - msg#00081 ... This patch implements ftrace plugin for uprobes. Right, like others have said, trace events is a much saner interface. ... osdir.com/ml/linux-kernel/2010-01/msg00081.html - Cached Show more results from osdir.com Re: [RFC] [PATCH 4/7] Uprobes Implementation You need to follow this up with the uprobes patch for yourarchitecture. So all this is basically some glue between what you call ubp (the ... www.mail-archive.com/utrace-de...@redhat.com/msg02191.html - Cached Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP) This patch provides core implementation of ubp and also wrappers for architecture dependent ... [RFC] [PATCH 0/7] UBP, XOL and Uprobes Srikar Dronamraju ... www.mail-archive.com/utrace-de...@redhat.com/msg02184.html - Cached Show more results from www.mail-archive.com [PATCH 0/7] UBP, XOL and Uprobes [LWN.net] 11 Jan 2010 ... This patchset provides Subject: [RFC] [PATCH 0/7] UBP, XOL and Uprobes Subject: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer ... lwn.net/Articles/369358/ - Cached Uprobes patches. [LWN.net] 18 Mar 2010 ... Subject: [PATCH v1 0/10] Uprobes patches. ... uprobes: X86 details for Uprobes 9. uprobes: Uprobes Documentation patch 10. samples: Uprobes ... lwn.net/Articles/379659/ Show more results from lwn.net PATCH v1 7/10 - Uprobes Implementation Uprobes Implementation The uprobes infrastructure enables a user to dynamically establish probepoints in user applic. www.pubbs.net/kernel/201003/45181/ - 22 hours ago Get more results from the past 24 hours PATCH v1 10/10 - Uprobes samples. Uprobes Samples This provides an example uprobes module in the samples directory. To run this module run (as root) www.pubbs.net/kernel/201003/45185/ - 22 hours ago Show more results from www.pubbs.net Get more results from the past 24 hours [PATCH v1 7/10] Uprobes Implementation 20 Mar 2010 ... You need to follow this up with the uprobes patch for your architecture. For more information: please refer to Documentation/uprobes.txt ... linux.derkeiler.com/Mailing-Lists/Kernel/.../msg08418.html - 23 hours ago Get more results from the past 24 hours [PATCH v1 10/10] Uprobes samples. 20 Mar 2010 ... Next by Date: [PATCH v1 9/10] Uprobes Documentation patch; Previous by thread: [PATCH v1 8/10] X86 details for uprobes. ... linux.derkeiler.com/Mailing-Lists/Kernel/.../msg08396.html - 23 hours ago Show more results from linux.derkeiler.com Get more results from the past 24 hours [PDF] Ptrace, Utrace, Uprobes:
[linuxkernelnewbies] LKML: Srikar Dronamraju: [RFC] [PATCH 0/7] UBP, XOL and Uprobes
http://lkml.org/lkml/2010/1/11/92 This patchset implements Uprobes which enables you to dynamically break into any routine in a user space application and collect information non-disruptively. Uprobes is based on utrace and uses x86 instruction decoder. When a uprobe is registered, Uprobes makes a copy of the probed instruction, stops the probed application, replaces the first byte(s) of the probed instruction with a breakpoint instruction and allows the probed application to continue. (Uprobes uses the same copy-on-write mechanism so that the breakpoint affects only that process.) When a CPU hits the breakpoint instruction, Uprobes intercepts the SIGTRAP and finds the associated uprobe. It then executes the associated handler. Uprobes single-steps its copy of the probed instruction and resumes execution of the probed process at the instruction following the probepoint. Instruction copies to be single-stepped are stored in a per-process "single-step out of line (XOL) area," Uprobes can be used to take advantage of static markers available in user space applications. Advantages of uprobes over conventional debugging include: 1. Non-disruptive. 2. Uses Execution out of line(XOL), 3. Much better handling of multithreaded programs because of XOL. 4. No context switch between tracer, tracee. Here is the list of TODO Items. - Provide a perf interface to uprobes. - Return probes. - Support for Other Architectures. - Jump optimization. This patchset provides Subject: [RFC] [PATCH 0/7] UBP, XOL and Uprobes Subject: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP) Subject: [RFC] [PATCH 2/7] x86 support for UBP Subject: [RFC] [PATCH 3/7] Execution out of line (XOL) Subject: [RFC] [PATCH 4/7] Uprobes Implementation Subject: [RFC] [PATCH 5/7] X86 Support for Uprobes Subject: [RFC] [PATCH 6/7] Uprobes Documentation Subject: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes This patchset is based on git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git If and when utrace gets accepted into tip tree or Mainline, I will rebase this patchset. Please do provide your valuable comments. To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] utrace by roland mcgrath
http://events.linuxfoundation.org/slides/lfcs09_mcgrath.pdf To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] uprobes by jim keniston
http://events.linuxfoundation.org/slides/lfcs09_keniston.pdf To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] kprobes
http://www-users.cs.umn.edu/~boutcher/kprobes/
kprobes tutorial
This tutorial was developed for the 2006 Ottawa
Linux Symposium. I'm hoping it will be useful as a general
resource.
There is documentation in Documentation/kprobes.txt
in the kernel source.
Why?
kprobes is both useful and cool. Unfortunately most of the kernel
developers I've talked to are confused both about why its useful and
how to use it. I'm hoping to answer both of those here. I should
add that I have no skin in the game personally, I'm not a kprobes
developer. I should probably turn this into a HOWTO...
What is kprobes?
Simply, kprobes allows you to write modules that can add debug
information to the kernel. It is an alternative to building custom
kernels or custom modules. I think the most useful case is when you
are dealing with some remote machine (your grandmother or a tester)
who hits some bug that you can't figure out by looking at
/var/log/messages. Build a kprobes module and have them insmod it on
their kernel.
This tutorial deals with kernel kprobing. There is
additional work around user-land kprobing that will not be discussed
here.
There are three kinds of kprobes:
jprobes
Call a function on the entry to a routine. All the
arguments to the routine are passed.
kretprobes
Call a function on the exit from a routine. The registers
are passed
kprobe
The guts of kprobes. Any arbitrary kernel instruction can be
probed. A function is called passing the registers.
kprobes prerequisites
kprobes has been in mainline since 2.6.9. There are some kernel
configuration flags that need to be set to
use kprobes. Current enterprise kernels (such as SLES 10) have these
turned on, and so does FC5. Some others (cough, Ubuntu, cough) do not.
The flags that are required are:
CONFIG_KPROBES
duh
CONFIG_MODULES and CONFIG_MODULE_UNLOAD
kprobes do not require any code changes to the source kernel
(thats kind of the idea.) They are loaded into existing kernels as
modules. Obviously you need modules configured. You don't actually
require MODULE_UNLOAD, but it makes life easier.
CONFIG_KALLSYMS and CONFIG_KALSYMS_ALL
You can set a kprobe by using an address from System.map, but it
is easier to code kallsyms_lookup_name().
To build a module (any module) you need to have access to the
kernel headers and a suitable compiler.
Simple Case #1
The simplest case, useful in 99% of cases is the jprobe
case, where your function gains control on the entry to some arbitrary
routine in the kernel.
In this example we will trace do_execve in the kernel. Start from
the makefile and source in Documentation/kprobes.txt.
1: /* Trace do_execv. Taken basically from Documentation/kprobes.txt */
2: #include linux/kernel.h
3: #include linux/module.h
4: #include linux/sched.h
5: #include linux/kprobes.h
6: #include linux/kallsyms.h
7:
8: /*
9: * Pre-entry point for do_execve.
10: */
11: static int my_do_execve(char * filename,
12: char __user *__user *argv,
13: char __user *__user *envp,
14: struct pt_regs * regs)
15: {
16: printk("do_execve for %s from %s\n", filename, current-comm);
17: /* Always end with a call to jprobe_return(). */
18: jprobe_return();
19: /*NOTREACHED*/
20: return 0;
21: }
22:
23: static struct jprobe my_jprobe = {
24: .entry = (kprobe_opcode_t *) my_do_execve
25: };
26:
27: int init_module(void)
28: {
29: int ret;
30: my_jprobe.kp.addr =
31: (kprobe_opcode_t *) kallsyms_lookup_name("do_execve");
32: if (!my_jprobe.kp.addr) {
33: printk("Couldn't find %s to plant jprobe\n", "do_execve");
34: return -1;
35: }
36:
37: if ((ret = register_jprobe(my_jprobe)) 0) {
38: printk("register_jprobe failed, returned %d\n", ret);
39: return -1;
40: }
41: printk("Planted jprobe at %p, handler addr %p\n",
42:my_jprobe.kp.addr, my_jprobe.entry);
43: return 0;
44: }
45:
46: void cleanup_module(void)
47: {
48: unregister_jprobe(my_jprobe);
49: printk("jprobe unregistered\n");
50: }
51:
52: MODULE_LICENSE("GPL");
Note line 11
Give YOUR routine a different
name than the one you are tracing, otherwise kallsyms_lookup_name will
get confused.
Note line 18
where the jprobe handler calls
jprobe_return(). I mean REALLY note that (don't just return from a
jprobe.)
The Makefile (also straight out of Documentation/kprobes.txt) is
# This is taken straight from Documentation/kprobes.txt
obj-m := trace-exec.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
clean:
rm -f *.mod.c *.ko *.o
Easy. insmod the module and away you go! Here's the output on my
thinkad
Jul 16 19:20:46 hound
[linuxkernelnewbies] How does SATA worked and handled in Linux kernel
Looking up the datasheet:
http://www.seagate.com/support/disc/manuals/sata/100402371a.pdf
Looking further into page 47:
Supported ATA commands
The following table lists Serial ATA standard commands that the drive
supports. For a detailed description of the ATA commands, refer to the
Serial ATA: High Speed Serialized AT Attachment specification. See
S.M.A.R.T. commands on page 44.for details and subcommands used in
the S.M.A.R.T. implementation.
A list of all the command supported is listed:
Identify Device
ECH
Idle
97H or E3H
which is inside drivers/ata/libata-eh.c:
2135 const char *ata_get_cmd_descript(u8 command)
2136 {
2137 #ifdef CONFIG_ATA_VERBOSE_ERROR
2138 static const struct
2139 {
2140 u8 command;
2141 const char *text;
2142 } cmd_descr[] = {
2143 { ATA_CMD_DEV_RESET, "DEVICE RESET" },
2144 { ATA_CMD_CHK_POWER, "CHECK POWER MODE"
},
2145 { ATA_CMD_STANDBY, "STANDBY" },
2146 { ATA_CMD_IDLE, "IDLE" },
2147 { ATA_CMD_EDD, "EXECUTE DEVICE
DIAGNOSTIC" },
2148 { ATA_CMD_DOWNLOAD_MICRO, "DOWNLOAD
MICROCODE" },
2149 { ATA_CMD_NOP, "NOP" },
2150 { ATA_CMD_FLUSH, "FLUSH CACHE" },
2151 { ATA_CMD_FLUSH_EXT, "FLUSH CACHE EXT"
},
2152 { ATA_CMD_ID_ATA, "IDENTIFY DEVICE"
},
2153 { ATA_CMD_ID_ATAPI, "IDENTIFY PACKET
DEVICE" },
and this is called inside libata-acpi.c:
663 /**
664 * ata_acpi_run_tf - send taskfile registers to host controller
665 * @dev: target ATA device
666 * @gtf: raw ATA taskfile register set (0x1f1 - 0x1f7)
667 *
668 * Outputs ATA taskfile to standard ATA host controller using MMIO
669 * or PIO as indicated by the ATA_FLAG_MMIO flag.
670 * Writes the control, feature, nsect, lbal, lbam, and lbah
registers.
671 * Optionally (ATA_TFLAG_LBA48) writes hob_feature, hob_nsect,
672 * hob_lbal, hob_lbam, and hob_lbah.
673 *
674 * This function waits for idle (!BUSY and !DRQ) after writing
675 * registers. If the control register has a new value, this
676 * function also waits for idle after writing control and before
677 * writing the remaining registers.
678 *
679 * LOCKING:
680 * EH context.
681 *
682 * RETURNS:
683 * 1 if command is executed successfully. 0 if ignored, rejected
or
684 * filtered out, -errno on other errors.
685 */
686 static int ata_acpi_run_tf(struct ata_device *dev,
687 const struct ata_acpi_gtf *gtf,
688 const struct ata_acpi_gtf *prev_gtf)
689 {
690 struct ata_taskfile *pptf = NULL;
691 struct ata_taskfile tf, ptf, rtf;
692 unsigned int err_mask;
693 const char *level;
694 const char *descr;
695 char msg[60];
696 int rc;
697
698 if ((gtf-tf[0] == 0) (gtf-tf[1] == 0)
(gtf-tf[2] == 0)
699 (gtf-tf[3] == 0)
(gtf-tf[4] == 0) (gtf-tf[5] == 0)
700 (gtf-tf[6] == 0))
701 return 0;
702
703 ata_acpi_gtf_to_tf(dev, gtf, tf);
704 if (prev_gtf) {
705 ata_acpi_gtf_to_tf(dev, prev_gtf, ptf);
706 pptf = ptf;
707 }
708
709 if (!ata_acpi_filter_tf(dev, tf, pptf)) {
710 rtf = tf;
711 err_mask = ata_exec_internal(dev, rtf, NULL,
712 DMA_NONE, NULL, 0, 0);
713
714 switch (err_mask) {
715 case 0:
716 level = KERN_DEBUG;
717 snprintf(msg, sizeof(msg), "succeeded");
718 rc = 1;
719 break;
720
721 case AC_ERR_DEV:
722 level = KERN_INFO;
723 snprintf(msg, sizeof(msg),
724 "rejected by device (Stat=0x%02x
Err=0x%02x)",
725 rtf.command, rtf.feature);
726 rc = 0;
727 break;
728
729 default:
730 level = KERN_ERR;
731 snprintf(msg, sizeof(msg),
732 "failed (Emask=0x%x Stat=0x%02x
Err=0x%02x)",
733 err_mask, rtf.command,
rtf.feature);
734 rc = -EIO;
735 break;
736 }
737 } else {
738 level = KERN_INFO;
739 snprintf(msg, sizeof(msg), "filtered out");
740 rc = 0;
741 }
742 descr = ata_get_cmd_descript(tf.command);
743
And the systemtap tracing:
ata_scsi_queuecmd
0x8162c26d : ata_scsi_queuecmd+0x0/0x98 [kernel]
0x81515625 : scsi_dispatch_cmd+0x1e1/0x25f [kernel]
0x8151b43b : scsi_request_fn+0x3f2/0x53b [kernel]
0x813bb641 : __generic_unplug_device+0x35/0x39 [kernel]
0x813bb673 : generic_unplug_device+0x2e/0x3e [kernel]
0x813b63a6 : blk_unplug+0x48/0x4d [kernel]
0x813b63bd : blk_backing_dev_unplug+0x12/0x14 [kernel]
0x8114084f : sync_buffer+0x3e/0x47 [kernel]
0x81d9b33c : __wait_on_bit+0x4c/0x7e [kernel]
0x81d9b3dd : out_of_line_wait_on_bit+0x6f/0x7c [kernel]
0x81140774 : __wait_on_buffer+0x24/0x26 [kernel]
0x81205523 : wait_on_buffer+0x3d/0x41 [kernel]
0x81206138 : journal_commit_transaction+0xb42/0x117a [kernel]
0x8120961a : kjournald+0x102/0x25f [kernel]
0x81083c43 : kthread+0x9d/0xa5 [kernel]
0x81030634 : kernel_thread_helper+0x4/0x10 [kernel]
0x81d9d53c : restore_args+0x0/0x30 [kernel] (inexact)
0x81083ba6 : kthread+0x0/0xa5 [kernel] (inexact)
0x81030630 : kernel_thread_helper+0x0/0x10 [kernel] (inexact)
ata_scsi_find_dev
0x816292b1 : ata_scsi_find_dev+0x0/0x39 [kernel]
0x8162c2b6 : ata_scsi_queuecmd+0x49/0x98 [kernel]
0x81515625 : scsi_dispatch_cmd+0x1e1/0x25f [kernel]
0x8151b43b
[linuxkernelnewbies] [Phoronix] Nouveau To Go Into Linux 2.6.33 Kernel!
http://www.phoronix.com/scan.php?page=news_itempx=Nzc5NQ Nouveau To Go Into Linux 2.6.33 Kernel! Posted by Michael Larabel on December 11, 2009 Wow, the day has come, open-source fans with NVIDIA hardware that run Linux have quite the present this holiday season. Yesterday there was the first DRM pull request for the Linux 2.6.33 kernel that brought many changes to the ATI/AMD and Intel DRM along with other core DRM improvements (such as to the TTM memory manager). These changes were quite significant and we even called it a great present in the Linux 2.6.33 kernel. These DRM changes were accepted, but Linus Torvalds went off on a bit of rant wanting Nouveau merged into the kernel. A discussion ensued and after blaming Nouveau's lack of upstreaming on wanting the kernel/user-space API to potentially change in the future and then with Red Hat disclosing the Nouveau microcode problem that seemed to be pretty much that and we had not expected any immediate activity on the matter. This morning though, David Airlie and Ben Skeggs of Red Hat are delivering one grand present to NVIDIA Linux users for Christmas: the Nouveau DRM. Less than 24 hours ago David Airlie was writing on the mailing list how Red Hat would not sign off on the Nouveau work even though they ship it in Fedora due to these ctx_voodoo microcode issues, but they have worked around that in drm-nouveau-pony. In this pull request, there is the Nouveau driver that is set to go in the Linux 2.6.33 kernel under the staging area. The Nouveau driver no long carries the ctx_voodoo microcode directly within the driver, but those mysterious files have been extracted from the code and are now loaded through the kernel's firmware interface loader. The Nouveau DRM driver is around 36,000 lines of code which is quite huge, but it supports nearly every NVIDIA GPU to date. Stay tuned as we will have many more stories coming up on the Nouveau driver with this surprise change to push it in the Linux 2.6.33 kernel, which will be publicly released in February. What is finding its way into the Linux 2.6.33 kernel is the Nouveau DRM driver, which is the underlying component that is needed for kernel mode-setting as well as the foundations of the 3D support. Kernel mode-setting is great, but the xf86-video-nouveau DDX driver will need to be released in 2010 when the Linux 2.6.33 kernel is available so that there is support within the X.Org server too. The Gallium3D driver for Nouveau will need to be released to provide any usable form of OpenGL acceleration with this open-source stack, but it will likely be some months before the Gallium3D driver is completed and ready for release. However, this may very well mean the death of the xf86-video-nv driver in 2010. Up to this point unless building the Nouveau components from source or using separate packages, the only place to find this free software NVIDIA driver in action by default has been with Fedora. Red Hat has been shipping Nouveau (with kernel mode-setting support) for a while now as part of their Fedora package set. However, Canonical is preparing to backport Nouveau into the Ubuntu 10.04 LTS kernel to provide support for the Lucid Lynx. With the Nouveau DRM entering the Linux kernel, more distributions will likely be shipping this NVIDIA driver rather than the xf86-video-nv mess in 2010. Many thanks go out to Red Hat (particularly David Airlie and Ben Skeggs) along with Stephane Marchesin who had founded the Nouveau driver project and all of the other contributors to this free software NVIDIA graphics driver. To unsubscribe from this group, send email to linuxkernelnewbies+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[linuxkernelnewbies] [Phoronix] Part 2 Of Nouveau Saga: The Microcode
http://www.phoronix.com/scan.php?page=news_itempx=Nzc5Mg Part 2 Of Nouveau Saga: The Microcode Posted by Michael Larabel on December 10, 2009 Following a feature-packed DRM pull request this morning for the Linux 2.6.33 kernel, Linus Torvalds became frustrated that the Nouveau driver for supporting NVIDIA hardware was still not to be found in this most recent pull request. Linus wants Nouveau in the mainline kernel especially as Red Hat has already been shipping this free software driver in Fedora for two releases. Only a few hours have passed since that second news article, but more messages surrounding the Nouveau status have been sent on the kernel mailing list and dri-devel. Maarten Maathuis who has worked on the Nouveau project responded saying that Nouveau isn't in the kernel yet (as far as he knows) because the project is unsure over the legal status of some microcode. You assume that Red Hat has full control over the project, which i don't think is the case. The reason it isn't in staging yet (as far as i know) is because of some questions over the copyright of some (essential) microcode. Either the question needs to be answered, or it has to be reverse engineered to the point that it's possible to generate it. Like most graphics drivers, the Nouveau driver is reliant upon loading in some microcode/firmware for it to work. In the case of Nouveau they load up this big batch of microcode for the GPU initialization, but the problem is they are unsure of what this microcode even does or what is its legal status is with regards to copyright and redistribution. This microcode can be obtained when using REnouveau to (cleanly) reverse-engineer NVIDIA's display drivers using memory mapped I/O register traces, with the steps to fetching the ctx_voodoo being documented on their Wiki. Without ctx_voodoo, the Nouveau driver cannot function. Legal situations can be messy, especially when there is no support from NVIDIA for this project, but they stand neutral on the matter of Nouveau. NVIDIA's Andy Ritger had said the following when we had interviewed him at Phoronix, "The guys working on nouveau have done a really incredible job so far. However, our policy remains the same: we won't try to hinder their efforts, but we have no plans to help them." In response to this "excuse" of microcode uncertainty, Linus replied: I think people are just making up excuses, as evidenced by the fact that you're quoting a different excuse than I've heard before. The fact is, if there are license questions, then Fedora had better not be distributing the code either. And they clearly are. And don't tell me about "full control". There's absolutely full control over it being included or not. When I brought this up at the kernel summit, there were various other random excuses. I think one of them was that it wasn't part of an official Fedora release (which is sure as hell not true at least as of Fedora 12). I've heard the "but it's hard to merge" excuse too - which I also know is bullshit, because I can look at the git tree Fedora apparently uses, and it merges without any conflicts what-so-ever. The most common excuse is the "oh, but it might change" crap. But that's not even a very good excuse to start with, and it's what staging is for anyway. Somebody even made the crazy comment that "but Fedora isn't a real distribution, so it doesn't need to follow the rules everybody agreed to several _years_ ago wrt merging stuff to mainline". I _think_ that last one was meant as a joke. But it's damn hard to tell, because the ones that are apparently sincere are equally crazy. People just seem to make up total crap to make excuses for something that everybody knows is wrong. Linus This microcode issue is also why Nouveau support had not shipped with FreeBSD 8.0 in its kernel, as was shared in the thread by the FreeBSD X/Mesa maintainer, Robert Noland. Alan Cox has called upon Linus to just merge the code seeing as he is the maintainer of the Linux kernel master branch. Just minutes ago, however, David Airlie who is the DRM maintainer and a Red Hat developer that is involved with the Nouveau project, has provided his response. Due to this troubled microcode, Red Hat cannot provide a "Signed-off" copy of Nouveau for inclusion into the Linux kernel due to this legal uncertainty. As David went on to mention, if the Nouveau driver supported the kernel's firmware loader interface, this ctx_voodoo microcode could be separated from the driver so that this potentially troublesome work would not land in the kernel but could be redistributed separately, it may help in this situation. However, no one has done this firmware loading work yet. This microcode issue for the Nouveau project could certainly be a legal problem, but as of last check, no one has actually approached the Linux Foundation, Free Software Foundation, or Software Freedom Law Center for any assistance
[linuxkernelnewbies] ATA 4 KiB sector issues. [LWN.net]
http://lwn.net/Articles/377897/?format=printable From: Tejun Heo tj-AT-kernel.org To: "linux-ide-AT-vger.kernel.org" linux-ide-AT-vger.kernel.org, lkml linux-kernel-AT-vger.kernel.org, Daniel Taylor Daniel.Taylor-AT-wdc.com, Jeff Garzik jeff-AT-garzik.org, Mark Lord ker...@t Subject: ATA 4 KiB sector issues. Date: Mon, 08 Mar 2010 12:48:35 +0900 Archive-link: Article, Thread Hello, guys. It looks like transition to ATA 4k drives will be quite painful and we aren't really ready although these drives are already selling widely. I've written up a summary document on the issue to clarify stuff as it's getting more and more confusing and develop some consensus. It's also on the linux ata wiki. http://ata.wiki.kernel.org/index.php/ATA_4_KiB_sector_issues I've cc'd people whom I can think of off the top of my head but I surely have missed some people who would have been interested. Please feel free to add cc's or forward the message to other MLs. Especially, I don't know much about partitioners so the details there are pretty shallow and could be plain wrong. It would be great if someone who knows more about this stuff can chime in. Thanks. === Document follows === ATA 4 KiB sector issues Background ="" Up until recently, all ATA hard drives have been organized in 512 byte sectors. For example, my 500 GB or 477 GiB hard drive is organized of 976773168 512 byte sectors numbered from 0 to 976773167. This is how a drive communicates with the driver. When the operating system wants to read 32 KiB of data at 1 MiB position, the driver asks the drive to read 64 sectors from LBA (Logical block address, sector number) 2048. Because each sector should be addressable, readable and writable individually, the physical medium also is organized in the same sized sectors. In addition to the area to store the actual data, each sector requires extra space for book keeping - inter-sector space to enable locating and addressing each sector and ECC data to detect and correct inevitable raw data errors. As the densities and capacities of hard drives keep growing, stronger ECC becomes necessary to guarantee acceptable level of data integrity increasing the space overhead. In addition, in most applications, hard drives are now accessed in units of at least 8 sectors or 4096 bytes and maintaining 512 byte granularity has become somewhat meaningless. This reached a point where enlarging the sector size to 4096 bytes would yield measurably more usable space given the same raw data storage size and hard drive manufacturers are transitioning to 4 KiB sectors. Anandtech has a good article which illustrates the background and issues with pretty diagrams[1]. Physical vs. Logical Because the 512 byte sector size has been around for a very long time and upto ATA/ATAPI-7 the sector size was fixed at 512 bytes, the sector size assumption is scattered across all the layers - controllers or bridge chips snooping commands, BIOSs, boot codes, drivers, partitioners and system utilities, which makes it very difficult to change the sector size from 512 byte without breaking backward compatibility massively. As a workaround, the concept of logical sector size was introduced. The physical medium is organized in 4 KiB sectors but the firmware on the drive will present it as if the drive is composed of 512 byte sectors thus making the drive behave as before, so if the driver asks the hard drive to read 64 sectors from LBA 2048, the firmware will translate it and read 8 4 KiB sectors from hardware sector 256. As a result, the hard drive now has two sector sizes - the physical one which the physical media is actually organized in, and the logical one which the firmware presents to the outside world. A straight forward example mapping between physical sector and LBA would be LBA = 8 * phys_sect Alignment problem on 4 KiB physical / 512 logical drives === This workaround keeps older hardware and software working while allowing the drive to use larger sector size internally. However, the discrepancy between physical and logical sector sizes creates an alignment issue. For example, if the driver wants to read 7 sectors from LBA 2047, the firmware has to read hardware sector 255 and 256 and trim leading 7*512 bytes and tailing 512 bytes. For reads, this isn't an
[linuxkernelnewbies] HelenOS project
http://www.helenos.org/ About HelenOS Rather sooner than later, HelenOS will become a complete and usable modern operating system, offering room for experimenting and research. HelenOS uses its own microkernel written from scratch and supports SMP, multitasking and multithreading on both 32-bit and 64-bit, little-endian and big-endian processor architectures, among which are AMD64/EM64T (x86-64), ARM, IA-32, IA-64 (Itanium), 32-bit MIPS, 32-bit PowerPC and SPARC V9. Thanks to the relatively high number of supported architectures and suitable design, HelenOS is very portable. On top of the microkernel, HelenOS provides services such as file systems, networking, device drivers and user interface. Most of these services are composed of multiple independent server processes, which makes HelenOS one of the most modular operating systems. As of now, HelenOS is being developed mostly by faculty members, and former and contemporary students of Faculty of Mathematics and Physics at Charles University in Prague. Nonetheless, the project is open for everyone, so we also have developers with different backgrounds from various places around the world. The source code is open and available under the BSD license. Some third party components, and components based on GPL software, are licensed under GPL. In case you are interested in our project or have any questions about it, feel free to subscribe to our mailing list or chat with us on our IRC channel. The HelenOS operating system is, as of today, feature incomplete and the project is currently under heavy development (see roadmap). We are looking for people to join our team as co-developers or to merely try out our system and become our beta testers. If you have the skills and enthusiasm, you may consider making a contribution. HelenOS 0.4.2 (Skewer) Released! Submitted by jermar on Wed, 03/10/2010 - 23:39. After seven months since the previous release, the HelenOS team is proud to announce the immediate availability of our newest and greatest release: HelenOS 0.4.2 codenamed Skewer. This version fixes many bugs and introduces many new features such as a modular TCP/IP networking stack, support for the UltraSPARC T1 and T2 processors, improved debugging capabilities and of course a couple of new servers and applications. A more detailed summary can be found in our release notes. Staging branches for sun4v and networking Submitted by jermar on Wed, 01/13/2010 - 12:13. According to our roadmap, the next release, which is not that far away, will introduce support for the sun4v sub-architecture of sparc64, and the long awaited and wished-for TCP/IP networking stack. Early adopters and testers can preview both features in their staging branches (sun4v and networking). HelenOS switches to Bazaar VCS Submitted by jermar on Thu, 08/06/2009 - 16:30. After the 0.4.1 release, we abandoned our Subversion repository, leaving all change history behind, and moved on to Bazaar. The new repository is located at bzr://bzr.helenos.org/head and seamlessly continues where HelenOS 0.4.1 stopped. The old repository was made read-only and will stay around for the sake of searching the code history which predates HelenOS 0.4.1. We hope to be able to work more effectively with the new distributed version control system and look forward to the new cooperation possibilities it opens to the new potential developers. HelenOS 0.4.1 (Escalopino) Released! Submitted by jermar on Tue, 08/04/2009 - 00:38. After months of hard work and with great excitement, we are releasing HelenOS 0.4.1 to the wild today. The new version is codenamed Escalopino and brings a great deal of new features and improvements, as well as a large number of bug fixes. Because the enhancements are already too numerous to fit in this brief announcement, HelenOS 0.4.1 is the first release for which we are providing detailed release notes. HelenOS 0.4.1 can be downloaded from our download page. HelenOS 0.4.0 (Sinister Valentine) Released! Submitted by Anonymous on Sat, 02/14/2009 - 00:32. We are pleased to announce the immediate availability of HelenOS 0.4.0. This is the list of major improvements since the previous release: bdsh shell (simple CLI) task loader task tracer RAM disk support FAT file system support ia64 improvements ppc32 improvements sparc64 improvements better configuration system console speedups and improvements lots of bug fixes and other improvements For download, see our download page. Improved support for UltraSPARC processors Submitted by Anonymous on Sun, 12/07/2008 - 11:14. Pavel Rimsky, a new core contributor, has recently added support for the newer UltraSPARC processors so that besides the already supported UltraSPARC I, II and IIi processors, HelenOS runs also on the newer SPARC V9 subarchitecture of UltraSPARC III, IIIi and IV. Pavel made it run on the simulated Serengeti machine and the real world
[linuxkernelnewbies] Archives | HOT CHIPS 21
http://www.hotchips.org/archives/hc21/
HOT CHIPS 21 Archives (2009)
General Information
HOT CHIPS 21 (2009)
Date
August 23-25, 2009
Place
Memorial Auditorium, Stanford University
Committees
HC 21 Committees and Sponsors
Tutorials
Tutorials
Sunday, August 23, 2009
Morning
System Interconnect
Chair: Chuck Moore (AMD) and Ralph Wittig
(Xilinx)
Introduction
Part I:
HyperTransportTechnology Tutorial: Jos Duato (HyperTransport
Consortium TU Valencia)
Part II:
PCI Express 3.0 Overview: Jasmin Ajanovic (Intel)
Part III:
Intel QuickPath Interconnect Overview:
Bob Safranek (Intel)
Afternoon
OpenCL
Chair: John Nickolls (NVIDIA)
OpenCL Introduction
OpenCL Presenter Bios
OpenCL Quick Reference Card
Khronos and the
OpenCL Standard: Neil Trevett (Khronos)
The OpenCL 1.0 Specification; Affie Munshi (Khronos)
Khronos OpenCL Parallel Computing for Heterogeous Devices
AMD and OpenCL:
Mike Houston (AMD)
OpenCL, Heterogeneous Computing, and the CPU: Tim Mattson
(Intel)
OpenCL for
NVIDIA GPUS: Chris Lamb (NVIDIA)
Game Developers'
Perspective on OpenCL: Eric Schenk (Electronic Arts)
OpenCL in
Handheld Devices: Kari Pulli (Nokia)
Conference Day One
Session
Monday, August 24, 2009
Session 1
Session One: Server Systems I
Session Chair: Christos Kozyrakis, Stanford
Presentations:
Blade Computing with the AMD Opeteron Processor ("Magny
Cours"): Pat Conway, AMD
Nehalem-EX CPU Architecture: Sailesh Kottapalli and Jeff
Baxter, Intel
Innovation Envelope: Hot Chips in Blades: Kevin Leigh, HP
Keynote 1
Keynote I
Keynote Chair: John Nickolls, NVIDIA
Presentation: The GPU Computing Tipping
Point
Jen-Hsun Huang, CEO, NVIDIA
Session 2
Session Two: I/O
Session Chair: Norm Jouppi, HP
Presentations:
The World's First USB3.0 Storage Controller
Author(s): Gideon Intrater, Symwave
40Gb/s Optical Active Cable Using Monolithic Transceivers
Implemented in Silicon Photonics Enabled 0.13-m SOI CMOS Technology
Author(s): Daniel Kucharski,
Sherif Abdalla, Behnam Analui, Colin Bradbury, Peter De Dobbelaere,
Dennis Foltz, Steffen Gloeckner, Drew Guckenberger, Mark Harrison,
Steve Jackson, Michael Mack, Gianlorenzo Masini, Attila Mekis, Adit
Narasimha, Mark Peterson, Thierry Pinguet, Subal Sahni, Will Wang,
Brian Welch and Jeremy Witzens , Luxtera
Intel 5520 Chipset: An I/O Hub Chipset for Server,
Workstation, and High End Desktop
Author(s): Debendra Das Sharma, Intel
Session 3
Session Three: Parallel Computing Centers
Session Chair: Dean Tullsen, UC
San Diego and Alan Jay Smith, UC Berkeley
Presentations:
Overview of the UC Berkeley Par Lab
Author(s): David Patterson, UC
Berkeley
Universal Parallel Computing Research Center at Illinois:
Making Parallel Programming Synonymous with Programming
Author(s): Sarita Adve, Vikram
Adve, Gul Agha, Maria Garzaran, John Hart, Wen-mei Hwu, Ralph Johnson,
Laxmikant Kale, Darko Marinov, Klara Nahrstedt, David Padua, Madhusudan
Parthasarathy, Sanjay Patel, Grigore Rosu, Dan Roth, Marc Snir, Josep
Torrellas and Craig Zilles , UIUC
The Stanford Pervasive Parallelism Laboratory (PPL)
Author(s): Kunle Olukotun, Alex
Aiken, Bill Dally, Ron Fedkiw, Pat Hanrahan, John Hennessy, Mark
Horowitz, Vladlen Koltun, Christos Kozyrakis, Mendel Rosenblum and
Sebastian Thrun, Stanford University
Session 4
Session Four: Client Processors
Session Chair: Jan-Willem van de Waerdt, NXP
Presentations:
Moorestown
Platform: Based on Lincroft SoC Designed for Next Generation
Smartphones
Author(s): Rajesh Patel, Intel
OMAP4430
Architecture and Development
Author(s): David Witt, TI
ION: A
single-chip platform that energizes balanced PC architectures
Author(s): Sridhar Pursai, NVIDIA
Tranisitioning the Intel Next Generation Microarchitectures
(Nehalem and Westmere) Into the Mainstream
Author(s): Stephan
Jourdan, Intel
Panel Discussion
Panel Discussion: Technology Scaling at an Inflection
Point: What next?
Moderator: Krste Asanovic (UC Berkeley)
[linuxkernelnewbies] armslack: how to install sheevaplug
ftp://ftp.armedslack.org/armedslack/armedslack-12.2/INSTALL_SHEEVAPLUG.TXT
##
# Document: INSTALL_SHEEVAPLUG.TXT
# Purpose : How to install Slackware ARM on the Marvell SheevaPlug
# Author : Stuart Winter mo...@slackware.com
# Date: 16-May-2009
##
#
# References:
# http://computingplugs.com/index.php/Booting_entirely_off_an_external_USB_device
# http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html
# http://dev.gentoo.org/~armin76/arm/sheevaplug/install.xml
##
1.0 Assumptions
---
Several assumptions -- in the form of IP addresses and
directory paths -- are made to help writing the examples
for this documentation. These values are easy to modify
to suit your environment.
Environment:
- You have a host machine running an existing Slackware system. Any other
Unix/Linux system will suffice, but each Linux distribution is different so
you'll have to make some adjustments.
This machine will house the Slackware ARM tree, NFS TFTP server.
- Your host machine has Internet access, or some method of obtaining
the Slackware ARM tree.
- You have a secure (you trust the people using it)
LAN, on 192.168.1.0/24
- Your host machine has the IP 192.168.1.1
- You can NFS export the Slackware ARM tree
- You can run a TFTP daemon on your host
- You want to use /export to house the Slackware ARM tree.
Marvell SheevaPlug:
- You want to install the OS onto a USB flash stick, or a USB
hard drive.
You have at least an 8GB hard disk or USB flash stick - a full
installation of Slackware is approximately 4GB.
- You want to retain the stock Ubuntu installation.
2.0 Configuring your environment
2.1 NFS export
--
On your Slackware host, add a line similar to the example
below:
/export/armedslack 192.168.1.0/255.255.255.0(ro,nohide,root_squash,sync,no_subtree_check)
If you don't have an NFS server already running:
# chmod +x /etc/rc.d/{rc.rpc,rc.nfsd}
# /etc/rc.d/rc.nfsd restart
If you have an NFS server already running:
# exportfs -va
2.2 Setting up your TFTP boot server
Slackware ships a tftpd (TFTP boot daemon) in the 'tftp-hpa'
package which can be found in the 'n/' package series.
Ensure that inetd is running:
# chmod +x /etc/rc.d/rc.inetd
# /etc/rc.d/rc.inetd restart
By default, the line in /etc/inetd.conf that loads the TFP server
is commented out.
# tftp dgram udp waitroot/usr/sbin/in.tftpd in.tftpd -s /tftpboot -r blksize
Uncomment that line.
Note:
If you want to use a directory other than /tftpboot to house
the data, you may do so - but note that the instructions in this
document refer to /tftpboot, so please remember to adjust the paths
as you go.
Cause inetd to re-load its configuration file:
# killall -HUP inetd
2.3 Downloading Slackware ARM
--
Assumptions:
[ ] Your current user has read/write/execute access to /export
Make the directory that we'll download Slackware ARM into:
# mkdir -p /export/armedslack
# cd /export/armedslack
Download:
The easiest way to download Slackware ARM is to use rsync.
# rsync \
--exclude '*/source/*' \
--delete -Pavv \
ftp.armedslack.org::armedslack/armedslack-12.2 .
Download speed will depend on the bandwidth speed of your
Internet connection. Whilst it is possible to use the
FTP installation inside the installer, it's recommended to
download the full tree first, as in this example, and
install off an NFS host on your LAN.
The full download will be approximately 2GB.
You may choose a mirror site - some are listed on the
Slackware ARM web page: http://www.armedslack.org
2.4 Populating the /tftpboot directory
--
Assumptions:
[ ] Your current user has read/write/execute access to /tftpboot
To begin the installation on the SheevaPlug unit, we'll boot
the Linux Kernel and Initial RAM disk via TFTP.
It *is* possible to place these two files onto an ext2 or FAT
partition on USB stick/drive (even the one you'll be installing
Slackware onto), but during development I've found it beneficial
to have the images available by TFTP -- as you'll read later,
the
[linuxkernelnewbies] Slackware Linux for ARM
http://www.armedslack.org/ Slackware Linux for ARM ARMedslack is the official port of the Slackware Linux distribution to the ARM architecture. Currently, the project focuses its efforts on supporting the ARM Versatile platform (emulated by QEMU) and the Marvell SheevaPlug. Slackware ARM version 12.2 packages are compiled for ARMv4, little endian, old/legacy ABI. Slackware ARM "current" (development tree) is built for ARMv4t, little endian, EABI. Contact If you would like to help with the project, please join the mailing list. Installation Installation ARMedslack officially supports two platforms: ARM Versatile platform (via the QEMU emulator) and the Marvell SheevaPlug. Full documentation - including download instructions: Instructions for a QEMU installation Instructions for installation to the SheevaPlug Mirrors Incase the primary site is busy, you may use the following mirrors in place of "ftp.armedslack.org" rsync rsync slackware.mirror.zen.co.uk::armedslack rsync mirrors.vbi.vt.edu::armedslack rsync rsync.slackware.pl::armedslack rsync ftp.slackware.org.uk::armedslack FTP ftp://slackware.mirror.zen.co.uk/armedslack ftp://ftp.slackware.pl/pub/armedslack ftp://mirrors.vbi.vt.edu/linux/armedslack ftp://ftp.slackware.org.uk/armedslack Mailing list There is an ARMedslack mailing list. Click here to subscribe. Click here for the list archives. Current progress 7th-Feb-2010 A mini root filesystem of Slackware ARM "current" is now available from the FTP site. 21-September-2009 I'm really pleased to announce that Slackware ARM current is now available, and is using the EABI. Please check the announcement in the changelog. 11-September-2009 The Slackware ARM EABI port is almost complete and is up to date with Slackware-current (13.0) -- just waiting for KDE to finish building. It'll probably be another month before I upload the tree since I want to do some in depth testing and rebuild some packages and libraries to ensure everything is linked against what it should be, but I'm very happy to report this progress! 31-August-2009 The ARM EABI port is coming along very quickly! I'm currently experimenting with installing the Kernel initrd to the SheevaPlug's NAND flash U-Boot's flaky USB support. 16-August-2009 Important notice: ARMedslack 12.2 JFS is not working on the SheevaPlug -- writing to a JFS formatted filesystem produces a Kernel panic. Any standing JFS partitions should be mounted read-only for safety, and an alternate filesystem chosen. A new installer will be available shortly. In other news, the EABI port is going well - all of a, x, n and most of l/ is built! :-) 13-July-2009 A few people have been asking about ARMedslack using Linux 2.6.30 when Slackware is - at the time of writing - using 2.6.29. This is because support for the SheevaPlug only came in 2.6.30. 05-July-2009 Work has started on an EABI port for Slackware ARM current. Currently I'm building and upgrading the base packages in armedslack-12.2 to bootstrap the new port. I expect to open a new -current branch with this work in the next few months. 29-June-2009 Slackware ARM version 12.2 is released! I'm really happy to finally make the release - it's been a long time in the making. Thanks to everybody who has helped throughout the development cycle! The next step is to begin on the EABI port -- it'll take a while to get a base set of packages together for this, so a new "-current" won't be open for some time yet, so you have plenty of time to enjoy this release :-)
[linuxkernelnewbies] Kneuro.net : Linux Virtual Memory Subsystem : bootmem
http://kneuro.net/linux-mm/index.php?file=bootmem.html The Boot-time Allocator The bootmem allocator is used during the boot process to allocate memory before the kernel MM subsystem is usable. It is quite simple, though not as simple as its predecessor. The bootmem allocator is used, for example, to allocate the mem_map - the array of page structs used by the VM subsystem to keep track of the disposition of physical pages. The bootmem allocator lives only until the kernel has set up the data structures necessary to support the zone allocator. The 2.2 Method The symbol _end represents the end of the loaded kernel data - that is, the next usable byte after the kernel code loaded by the bootloader. (_end, along with a number of other important addresses, is defined in the linker script arch/i386/vmlinux.lds.) This address is in the kernel's virtual memory space at address PAGE_OFFSET+physical_kernel_end. Pages _end are, naturally, reserved for the kernel's use, and are never used by the VM subsystem. In the 2.2 kernel, the kernel would reserve memory at boot time by simply incrementing _end as required, in PAGE_SIZE chunks. This was somewhat inefficient, as it wasn't often the case that the size of the data in question was a multiple of PAGE_SIZE; thus many sub-page chunks were unrecoverably lost during the boot process. The 2.4 Method 2.4 uses a dramatically refined version of the same basic idea. The bootmem allocator in the 2.4 kernel is capable both of performing sub-page-size allocations efficiently, and (when appropriate) of reclaiming pages for the zone allocator after boot. For example, the bootmem allocator's data itself is not used after the zone allocator is initialized, so those pages can be released and given to the zone allocator as free pages. Bootmem Allocator Data Memory is organized into "nodes", each node being a (more or less) contiguous chunk of physical RAM; on normal, non-NUMA machines, there is only one node. Each node is represented by a pg_data_t structure, and of course on non-NUMA machines, there is only one of these, contig_page_data. Each pg_data_t has a member bdata of type bootmem_data_t that contains the bootmem allocator's data. The bootmem_data_t struct contains a pointer (node_bootmem_map) to a bitmap representing all the pages in the node, one bit per page. If a page's boot-map bit is 1, the page is reserved and will not be touched by the VM system during normal system operations; otherwise the page will be given to the zone allocator as a free page when early boot is complete. bootmem_data_t-node_boot_start is the physical address of the start address of the node. bootmem_data_t-node_low_pfn is the maximum low page frame number on the node -- the bootmem allocator never allocates high memory. The last_pos member is the offset of the last-allocated page, and last_offset is the offset of the next free address within the page. Overview of Bootmem Allocator Operation When the system BIOS memory map is interrogated by the kernel in setup_arch(), all nodes are given to the bootmem allocator as "reserved" memory; subsequently, those pages which correspond to real, usable RAM are bootmem-freed and are available to kernel subsystems that need to do boot-time allocations before the zone allocator is enabled. Those allocations are done either by returning an address within a bootmem-reserved page that is not fully utilized, or by reserving new pages as necessary in the bootmem bitmaps. Bootmem-allocated memory can also be freed as long as it is done before the zone allocator is enabled. Once the zone allocator is functional, all non-reserved bootmem pages are given to it as free memory, and the bootmem allocator is henceforth unusable. The bootmem code is in the __init link area, so it is itself released to the zone allocator when system boot is complete. Note that there may be "holes" in a node's address space; for example, there is frequently a 384K hole between (physical address) 640K and 1024K on PCs. In such cases, setup_arch() simply doesn't free the bootmem pages associated with the holes. This ensures that the nonexistent pages remain reserved, both at boot time and during normal system operation. Bootmem Allocator Code We first meet the bootmem allocator (on Intel platforms) in arch/i386/kernel/setup.c in the setup_arch() function. Here, the size of the low and high memory areas is computed, and init_bootmem() is called in order to initialize the bootmem data. On non-NUMA machines, init_bootmem() just calls init_bootmem_core() passing contig_page_data as the pg_data_t. init_bootmem_core() The first argument to init_bootmem_core(pg_data_t *pgdat,u nsigned long mapstart, unsigned long start, unsigned long end) is the pg_data_t pointer whose contents are to be initialized. The second argument is the address of the page struct within the system memory map corresponding to the first page of the node. The last to arguments are the
[linuxkernelnewbies] MMDOC. Linux Memory Management Documentation.
http://mmdoc.sourceforge.net/mmdoc/mmdoc.html MMDOC. Linux Memory Management Documentation. S. Mohan Kumar mohan_...@yahoo.com, http://mmdoc.sourceforge.net Abstract Introduction A overview of the MM system Various terms used in Linux MM Sub-System initialization. Memory categorization Paging start Start Paging Bootmem Handling Page table setup paging_init() pagetable_init() free_area_init() About this document ... MM Sub-System initialization. This section discusses in detail how the MM subsystem is initialized. SMP initialization is not discussed here.The mm sub system initialization takes place at the very beginning of the boot process itself. This is understandable as, usage of memory starts right from the boot process. Subsections Memory categorization Paging start Start Paging Bootmem Handling Page table setup paging_init() pagetable_init() free_area_init()
[linuxkernelnewbies] DMA
http://www.ganssle.com/articles/adma.htm DMA DMA is an important part of many embedded systems, yet far too many of us don't really understand it. Read on... Published in Embedded Systems Programming, October 1994 For hints, tricks and ideas about better ways to build embedded systems, subscribe to The Embedded Muse, a free biweekly e-newsletter. No hype, just down to earth embedded talk. 23,000 other engineers subscribe. It takes just a few seconds (all we need is your email address, which is shared with absolutely no one) to subscribe to the Embedded Muse. Engineers love to torture the English language, using words in convoluted ways, verbizing the most passive of nouns, and inventing strange new words that might embarrass your mother (the word "dikes", referring to diagonal cutters - wire cutters - comes to mind). Acronyms are our special bane. Every three word noun phrase is immediately shortened to its initials, even when this may make an acronym of an acronym. The passage of time dulls ones memory till the original words referred to by the letters slip away, so the acronym becomes its own word. For example, though "CRT" really refers only to a large tube, it has come to stand for a complete monitor, electronics, tube, and all. Even names of corporations reflect our reliance on verbal shorthand. IBM, GE, SAIC - an alphabet soup of letters dances in front of our eyes. CACI even reincorporated themselves some years back to make the acronym the new, real corporate name, consigning the words the letters stood for to eternal obscurity. Many embedded systems make use of DMA controllers. How many of us remember that DMA stands for Direct Memory Access? What idiot invented this meaningless phrase? I figure any CPU cycle directly accesses memory. This is a case of an acronym conveniently sweeping an embarrassing piece of verbal pomposity under the rug where it belongs. Regardless, DMA is nothing more than a way to bypass the CPU to get to system memory and/or I/O. DMA is usually associated with an I/O device that needs very rapid access to large chunks of RAM. For example - a data logger may need to save a massive burst of data when some event occurs. DMA requires an extensive amount of special hardware to managing the data transfers and to arbitrating access to the system bus. This might seem to violate our desire to use software wherever possible. However, DMA makes sense when the transfer rates exceed anything possible with software. Even the fastest loop in assembly language comes burdened with lots of baggage. A short code fragment that reads from a port, stores to memory, increments pointers, decrements a loop counter, and then repeats based on the value of the counter takes quite a few clock cycles per byte copied. A hardware DMA controller can do the same with no wasted cycles and no CPU intervention. Admittedly, modern processors often have blindingly fast looping instructions. The 386's REPS (repeat string) moves data much faster than most applications will ever need. However, the latency between a hardware event coming true, and the code being ready to execute the REPS, will surely be many microseconds even in the most carefully crafted program - far too much time in many applications. How it Works Processors provide one or two levels of DMA support. Since the dawn of the micro age just about every CPU has had the basic bus exchange support. This is quite simple, and usually consists of just a pair of pins. "Bus Request" (AKA "Hold" on Intel CPUs) is an input that, when asserted by some external device, causes the CPU to tri-state it's pins at the completion of the next instruction. "Bus Grant" (AKA "Bus Acknowledge" or "Hold Acknowledge") signals that the processor is indeed tristated. This means any other device can put addresses, data, and control signals on the bus. The idea is that a DMA controller can cause the CPU to yield control, at which point the controller takes over the bus and initiates bus cycles. Obviously, the DMA controller must be pretty intelligent to properly handle the timing and to drive external devices through the bus. Modern high integration processors often include DMA controllers built right on the processor's silicon. This is part of the vendors' never-ending quest to move more and more of the support silicon to the processor itself, greatly reducing the cost and complexity of building an embedded system. In this case the Bus Request and Bus Grant pins are connected to the onboard controller inside of the CPU package, though they usually come out to pins as well, so really complex systems can run multiple DMA controllers. It's a scary thought Every DMA transfer starts with the software programming the DMA controller, the device (either on-board a integration CPU chip or a discrete component) that manages these transactions. The code must typically set up destination and source pointers to tell the controller
[linuxkernelnewbies] The Embedded Muse Back Issues
http://www.ganssle.com/tem-back.htm For hints, tricks and ideas about better ways to build embedded systems, subscribe to The Embedded Muse, a free biweekly e-newsletter. No hype, just down to earth embedded talk. 23,000 other engineers subscribe. It takes just a few seconds (all we need is your email address, which is shared with absolutely no one) to subscribe to the Embedded Muse. Here's a complete set of back issues of The Embedded Muse, all in .PDF format. Go here to subscribe Muse 190 - Thoughts on the word "embedded,"and more on Toyota and compiler optimizations Muse 189 - Toyota Brakes, Optimization and a newParadigm Muse 188 - Stop bailing, the danger of Volatile, tools, and are debuggers evil? Muse 187 - Restoring from old backups, a story about EPROMs, more on corrosion, tools and tips. Muse 186 - Book review, thoughts on corrosion in switches, more tools and tips. Muse 185 - I'm History!, Tools and Tips, More, Better, Faster Muse 184 - Tools and Tips, Book Review (Statistics in a Nutshell), Salary Survey Muse 183 - Tools and Tips, Static Analysis, Optimism and Naming Conventions Muse 182 - Tools and Tips, Too Much Optimism, Naming Conventions Muse 181 - Tools and Tips, Book Review, Naming Conventions Muse 180 - Job Hunting Article, Tools and Tips, Book Review Muse 179 - Readers Respond Muse 178 - Tools, Naming Conventions, and CS Education Muse 177 - Multiprocessing, CS Education, Naming Conventions Muse 176 - Tools, Naming Conventions, Book Review and CS Education Muse 175 - Visualizing ICs, Past and Present and Responses to Computer Science Education Muse 174 - Computer Science Education Muse 173 - Responses to Quotes and Thoughts and Funny Datasheet Muse 172 - Comments on My Microchip Comments and more on Criminal Coding Muse 171 - Criminal Coding, Reuse, and Dot Com Muse 170 - Reuse and Dot Com Muse 169 - About Microchip, a book review, header guards and funny datasheets Muse 168 - Another Book Review and More on Reuse Muse 167 - Book Review and The Failure of Reuse Muse 166 - MSP430 Microcontroller Basics, Coders vs. Programmers Muse 165 - Inheritance, Code Inspections and Comm Monitors Muse 164 - Debugging and Datasheets Muse 163 - Hacking HP and More on Multicore Muse 162 - A Discussion on Multicore Muse 161 - Firmware's Best Practices Muse 160 - Firmware - Best Practices, and VDC Survey results Muse 159 - A VDC Survey, Great Engineer Responses and reasons for a valuable seminar Muse 158 - Tin Whiskers and a response to Great Engineers Muse 157 - Great Engineers, some history and contest results Muse 156 - Low ESR Capacitor Issue and more War Stories Muse 155 - A Salary Survey and another War Story Muse 154 - Nuggets, a War Story and the ESD - 20 Years Old Muse 153 - A Book Review (Serial Port Complete),Open Spaces, Tips Muse 152 - A Book Review (A Guide For the Perplexed), Tools + Tips Muse 151 - The Future of Engineering and More on Open Spaces Muse 150 - A Book Review (First Break all the Rules) and Open Spaces Muse 149 - Agile 2007, and Multitasking Muse 148 - Secure Software Muse 147 - Dependable Software and more Tools + Tips Muse 146 - My Readers' Rants on Cubicles Muse 145 - Security, Rant on Cubicles, and Tools + Tips Muse 144 - Baudot and TTY Corrections and Bit Banging Muse 143 - A Software Disaster and Embedded Linux Books Muse 142 - English as a First Language, and Tools and Tips Muse 141 - The Embedded World 2007, and Book Reviews Muse 140 - Free Books and Tools Tips Muse 139 - Engineering as a Process and More Tool Guardians Muse 138 - A salary Survey, Tool Guardians and Stack Overflows Muse 137 - Book Reviews and Does Expensive = Good Quality Muse 136 - Reading Code and Beautiful C++ and more on Debugging Tools Muse 135 - New Kinds of Debugging Tools and Starting with the Manual Muse 134 - Reading Code, Debouncing and Preserving Design Decisions Muse 133 - Preserving Design Decisions Muse 132 - Survey Results, More on Tools and Another Failure Story Muse 131 - EDN Turns 50, The Show Myth Muse 130 - Computer History and another Failure Story Muse 129 - A Failure Story, Disasters and More Computer History Muse 128 - Live From the ESC, Computer History and Tidbits Muse 127 - Test Driven Development and Yet More on Tools Muse 126 - Getting Better Firmware: A shameless Promotion Muse 125 - A Book Review - How Do Computers Do Math, and Pre Cad Muse 124 - Transistor-Free Computing, Firmware is Cheap and More Tools Muse 123 - Tools and More Tools Muse 122 - Rounding, More on Tools and Testing Muse 121 - Tools and Unmaintainable Code Muse 120 - Interesting Articles, Tools and Bucks not Tech Muse 119 - Windows Turns 20 Muse 118 - More on Naming Conventions and Engineering Washouts Muse 117 - Engineering Washouts and Variable Function Naming Muse 116 -
[linuxkernelnewbies] Software and Hardware Fault Handling
http://www.eventhelix.com/RealtimeMantra/FaultHandling/ Fault Handling and Fault Tolerance Software Fault Tolerance Software Fault Tolerance We discuss techniques to make Realtime systems more tolerant to software bugs. Handling Processor Reboot Processor reboot and recovery techniques is Realtime systems are described here. Hardware Fault Tolerance Hardware Fault Tolerance Hardware fault tolerance and redundancy techniques are covered in this document. Fault Handling Techniques This article describes the fault handling lifecycle and fault detection techniques. Hardware Diagnostics Hardware Diagnostics and Power On Self Tests are covered here. Hardware Basics Processor Bus Cycles Fault Tolerance software design requires basic knowledge of hardware. Here we cover some basic bus cycles performed by processors. DMA and Interrupt Handling We continue our discussion with a look at DMA operations and Interrupt Handling. Reliability and Availability Reliability and Availability Basics Basics of hardware and software reliability and availability System Reliability and Availability Computing the availability of system from the availability of its components.
[linuxkernelnewbies] InterNiche: Robust and Efficient TCP/IP Protocol Stack Source Code for Altera's Nios-II
http://www.iniche.com/nios.php Altera-based Platforms Altera's premium FPGA products help to demonstrate that custom logic design can support high performance networking. The Altera NiosII processor core offers an optimized set of microcontroller design IP that can be easily deployed at the heart of economical FPGA logic designs. When used in combination with high performance network interface logic and NicheStack TCP/IP protocols, these FPGA based platforms can offer near wire-speed communications performance for networked device designs. Cost effective custom logic and high performance embedded TCP/IP software enable device connectivity for many new and exciting markets. InterNiche Network Evaluation Kits (NEKs) for Altera platforms are pre-integrated systems of complementary networking technologies that demonstrate and exercise the capability of a Nios II based device design and can be targeted at different types of networking application profiles. Each NEK that we offer is a fully capable, integrated and optimized networked device application that has been tailored to the interfaces and memory configuration of the chosen hardware environment. A typical Altera NEK would feature: High performance TCP/IPv4 stack, DHCP or static IP configuration SNMP v1 network management agent FTP server Telnet server PPP client IGMP support for multicasting Virtual File System HTTP web server interface The web server pages consist of static and dynamic information displays drawn from the NicheTool internal stack diagnostics and monitoring databases. For evaluation purposes, for each of these platforms, a run-time image or library is available that has been tested for development tool compatibility and run-time interoperability with the other network and device management components.
[linuxkernelnewbies] Hardware Interfacing | Netrino
http://www.netrino.com/taxonomy_menu/3/5 Hardware Interfacing A Framework for Safe Motion Control Firmware Submitted by webmaster on Mon, 07/20/2009 - 10:36. Hardware Interfacing Processes and Tools by Michael Wilk and Michael Barr An object-oriented framework can be used to create safe, testable and tunable motion control systems. Writing the software to handle motion control is a critical job on any real-time system design project. Safety is of the utmost importance. And, of course, it is also important that the code work precisely and allow for testing and performance tuning. An object-oriented framework can be used to create safe, testable and tunable motion control systems. webmaster's blog Login or register to post comments Read more Firmware-Friendly DMA Module Design Tips Submitted by webmaster on Thu, 02/05/2009 - 09:26. Hardware Interfacing Processes and Tools by Gary Stringham These built-in troubleshooting resources for DMA controllers can pave the way for smoother firmware integration. webmaster's blog Login or register to post comments Read more Firmware-Friendly FPGA (and ASIC) Design Tips Submitted by webmaster on Wed, 02/04/2009 - 13:18. Hardware Interfacing Processes and Tools by Gary Stringham Designing firmware-accessible debugging resources into embedded systems provides a valuable supplement to hardware test and analysis tools. Think ahead about what could go wrong during hardware testing or firmware integration, and add the hardware resources needed to troubleshoot those issues. webmaster's blog Login or register to post comments Read more How to Protect Non-Volatile Data Submitted by webmaster on Tue, 08/19/2008 - 07:15. Hardware Interfacing by Niall Murphy Unexpected power loss and software bugs can undermine the reliability of non-volatile data. Fortunately, there are various ways to make non-volatile data resilient to such corruption. webmaster's blog Login or register to post comments Read more Lock Up Your Software Submitted by webmaster on Mon, 05/12/2008 - 08:45. Hardware Interfacing User Interface Design by Niall Murphy When it comes to safety-critical applications, sometimes you have to protect users from the software. And sometimes you have to protect users from themselves. webmaster's blog 1 comment Read more Watchdog Timers Submitted by webmaster on Wed, 04/30/2008 - 09:55. Embedded C/C++ Hardware Interfacing by Niall Murphy To keep a watchdog timer from resetting your system, you've got to kick it regularly. But that's not all there is to watchdog science. We will examine the use and testing of a watchdog, as well as the integration of a watchdog into a multitasking environment. webmaster's blog Login or register to post comments Read more Software Matters for Power Consumption Submitted by webmaster on Tue, 12/11/2007 - 14:51. Embedded C/C++ Hardware Interfacing by Nathan Tennies Whether you are creating an operating system, firmware, or even device drivers, the way you write the software could affect the power consumption of the resulting product. Here are four approaches to minimizing power consumption through software. webmaster's blog Login or register to post comments Read more Calibrating Mechanical Inputs Submitted by webmaster on Tue, 12/04/2007 - 00:23. Embedded C/C++ Hardware Interfacing by Michael Barr Embedded software developers operate in a perfect digital environment but must interact with the imperfect analog real world. To do this it's essential to know how to perform calibration of inputs and sensors. webmaster's blog Login or register to post comments Read more Reconfigurable Computing Primer Submitted by webmaster on Sun, 12/02/2007 - 13:09. Hardware Interfacing by Michael Barr Designers of embedded systems face three significant challenges in today's ultra-competitive marketplace. Products must always: do more, cost less, and arrive to market faster. Fortunately, new flexible hardware design techniques are emerging from the study of reconfigurable computing. webmaster's blog Login or register to post comments Read more Embedded Systems Memory Types Submitted by webmaster on Sun, 12/02/2007 - 12:51. Hardware Interfacing by Michael Barr SRAM or DRAM? EEPROM or flash? What types of memory will you use in your next embedded systems design? Introduction to Closed-Loop Control Submitted by webmaster on Sun, 12/02/2007 - 12:40. Hardware Interfacing Programming Algorithms by Michael Barr Most control systems utilize feedback in some manner. Here's a look at several fundamental feedback mechanisms, culminating in a description of a basic PID controller. webmaster's blog Login or register to post comments Read more Introduction to Endianness Submitted by webmaster on Sun, 12/02/2007 - 12:08. Hardware
[linuxkernelnewbies] Embedded Systems Glossary: A | Netrino
http://www.netrino.com/Embedded-Systems/Glossary-A Embedded Systems Glossary: A Submitted by webmaster on Thu, 11/29/2007 - 14:17. A/D converter (ay to dee converter) n. A hardware device that reads an analog signaltypically a voltagecompares it to a reference signal, and converts the resulting percentage to a digital value. Short for analog-to-digital converter. Abbreviated ADC. The reference signal represents 100%. An n-bit A/D converter has a maximum value of 2n - 1 and a resolution of Vref/2n. [more] See also D/A converter. ABEL (like Cain's brother) abbr. A design language for creating the logic to be implemented in a simple programmable logic device. Short for Advanced Boolean _expression_ Language. Programs created with ABEL are compiled into the binary pattern necessary to create the PLD with a device programmer. [more] active low adj. Denotes a logic device or circuit where a logic 1 is a lower voltage than a logic 0. address bus n. A set of wires connected to a processor and all of the peripherals with which it communicates, for the purpose of selecting a specific memory location or register within a particular peripheral. If the address bus contains n electrical lines, the processor can address up to 2n unique locations. Address decoding logic between the processor and the devices connected to the bus select the proper device, typically based on the uppermost bits. aliasing 1. n. Allowing one memory location or register to be accessible at more than one address. Aliasing is a result of address decoding and often happens with peripheral control and status registers. For example, if an I/O device has just four byte-wide registers but is mapped into a 256-byte region of memory, aliasing will occur. In this case, the same four registers can be read or written at any of 64 different locations within that region. 2. n. An effect, because of undersampling, where a time-varying signal appears to be running, at a much lower frequency than it really is. Aliasing is a common effect of using a digital oscilloscope to view fast waveforms, like clocks. If the scope's sampling rate is low, the perfect 20-MHz clock could appear to be oscillating at 10 kHz. 3. n. Different variables reference the same physical memory location. In languages that support pointers, it is common for a program to maintain multiple references to the same storage. Each of these references is an alias. Aliasing can create problems when optimizing compilers and pipelined processors because it becomes more difficult for them to identify and analyze data dependencies within the program. analog adj. Describes data represented by a continuous range of values. The opposite of digital, in which all information is quantized. Analog is the way the world beyond the quantum level works. Part of the challenge of digital engineering is to convert noisy, inaccurate, and ugly real-world data to the pristine purity of 1s and 0s. The last two decades have seen a massive growth in digital signal processors, partly because they allow us to replace analog circuits with digital. Ultimately, the goal is to push the digital components all the way back to all systems' front ends--essentially connecting a radio's antenna, for example, directly into a DSP input. anode n. The element of a semiconductor device that accepts electrons. In a diode, for example, current passes from the anode to the cathode. On a diode, the anode is the terminal not marked by a band. aperiodic adj. Lacking periodicity; random. The term is most often used in the embedded context when scheduling periodictasks via RMA. The issue of what to do about aperiodic tasks and interrupts inevitably arises in real-world systems. Aperiodic tasks become ready to run on the occurrence of unpredictable events. EXAMPLE: The arrival of interrupts is often aperiodic. See also sporadic. aperiodic server n. A task that responds to events of an application software n. Software that is specific to a particular embedded system. Such application-specific code is generally built on a layered architecture of reusable components, such as a real-time operating system and network protocol stack or other middleware. If there is no such architecture, then this term may not be used. The application software is unlikely to be reusable across embedded platforms, simply because each embedded system has a different application. application-specific integrated circuit n. A piece of custom-designed hardware in a mass-produced chip. Abbreviated ASIC. Ariane 5 n. An infamous European rocket (made by Aerospatiale) that demonstrates the flawed principle of redundancy based on duplicated software. Unlike hardware subsystems, which either work or fail and can be made more reliable through duplication, software is either right or wrong in its logic. If software fails once, it will fail again given the same inputs; merely duplicating the code does not add redundancy. In the case of Ariane 5, some code borrowed form the
[linuxkernelnewbies] Embedded Systems Design - Embedded.com
http://www.embedded.com/design/archive/?howMany=100sort=publish_date+sort+desccontent_type=design ICE debugging: The end of the battleship game Lauro Rizzatti Mar 10, 2010 Getting disciplined about embedded software development: Part 3 - The value of postmortems Jack Ganssle Mar 10, 2010 Preventing dynamic allocation Dan Saks Mar 09, 2010 Getting disciplined about embedded software development: Part 2 - The Seven Step Plan Jack Ganssle Mar 09, 2010 Getting disciplined about embedded software development: Part 1 - Any idiot can write code Jack Ganssle Mar 08, 2010 Designing high-temp electronics for auto and other apps Pierre Delatte Mar 08, 2010 The Non-Quality Revolution Jack Ganssle Mar 08, 2010 How to ensure you are developing a world-class capacitive touch product Steve Kolokowsky Trevor Davis, Cypress Semiconductor Corp. Mar 08, 2010 Ensuring the thermal integrity of your IC package/PC board design Stephen Taranovich, Texas Instruments Mar 08, 2010 Decompiling the ARM architecture code Serge Sourjko and Robert Krten Mar 08, 2010 Designing intelligent smart grid systems that promote energy efficiency Ronn Kliger, Energy Group Director, Analog Devices, Inc. Mar 05, 2010 Enhancing MCU performance with a DMA-based event system controller Kristian Saether Mar 05, 2010 Getting basic utility meter designs ready for the Smart Grid Sunil Deep Maheshwari Mar 04, 2010 IC makers need to get smart Mark LaPedus Mar 03, 2010 The importance of FPGA-to-ASIC solutions to accelerate CPU-based protocols Joe Rash, CebaTech Mar 03, 2010 New standard takes COM to the extreme Barbara Schmitz Mar 01, 2010 An MSO for the masses Jack Ganssle Mar 01, 2010 Bridge Architecture: revolutionizing dual-mode 4G cellular-modem dongle design Ming Hoong Chong, Cypress Semiconductor Corp. Mar 01, 2010 Watch That Capacitor RMS Ripple Current Rating! Robert Kollman, Texas Instruments Mar 01, 2010 Random thoughts Jack W. Crenshaw Mar 01, 2010 Oversampling with averaging to increase ADC resolution Franco Contadini, Maxim Mar 01, 2010 PRODUCT HOW-TO - Incorporating quality into reusable IP Somnath Viswanath, Arasan Chip Systems, Inc. Feb 26, 2010 PRODUCT HOW TO: Improving switch maintenance in PXI with BIRST Bob Stasonis and David Owen Feb 25, 2010 Dodging Amdahl's Law with message passing, FPGA-based, parallel processing Dave Strenski and Brian Durwood Feb 24, 2010 Network Engineering for Audio Engineers - Part 3: Wide area networks (WANs) and the Internet Steve Church and Skip Pizzi Feb 24, 2010 ESC Silicon Valley: A semester-worth of embedded education in 4 days Bernard Cole Feb 23, 2010 Why did you become an Engineer? Jack Ganssle Feb 22, 2010 High-level synthesis, verification and language John Sanguinetti, CTO of Forte Design Systems Inc. Feb 22, 2010 Rethinking MEMS sensor design for the masses Peter G. Hartwell Feb 22, 2010 Forget ICT--Use MDI Testing with 10GBASE-T PHY John Dring and Jose Tellado Feb 21, 2010 Tuning C/C++ compilers for optimal parallel performance in multicore apps: Part 2 Max Domeika Feb 21, 2010 Tuning C/C++ compilers for optimal parallel performance in multicore apps: Part 1 Max Domeika Feb 18, 2010 CMOS history repeating again in power amplifiers Jim Nohrden, Black Sand Technologies Feb 18, 2010 CMOS is the right technology for 3G handset PAs Brad Fluke, Javelin Semiconductor Feb 18, 2010 CMOS is the wrong technology for 3G handset PAs Mario Rivas, Anadigics Inc. Feb 18, 2010 Leveraging FPGA and CPLD digital
[linuxkernelnewbies] CELF Embedded Linux Conference 2010
http://www.embeddedlinuxconference.com/elc_2010/program.html SESSION SCHEDULE Monday, April 12 Tuesday, April 13 Wednesday, April 14 Session Schedule Monday, April 12 Time Imperial A Osaka Spring 8:00-9:15 Registration and Breakfast Imperial Ballroom Foyer 9:15-9:30 Welcome Tim Bird 9:30-10:20 No Crash Dump? No Problem! David VomLehn Real-Time Linux Failure Frank Rowand Supporting SoC video subsystems in video4linux Hans Verkuil 10:30-11:20 A Consideration of Memory Saving by Efficient Mapping of Shared Libraries Masahiko Takahashi Effective Use of RT-Preempt Kevin Dankwardt An Introduction to the Qt Development Framework Jeremy Katz 11:30-12:15 Effective use of Scripting in Embedded Devices Steve Bennett Using Interrupt Threads to Prioritize Interrupts Mike Anderson Understanding and Developing Applications for the Maemo Platform Leandro Melo de Sales 12:15-1:30 Lunch Imperial B 1:30-2:20 Keynote: Android: a case study of an embedded Linux project Greg Kroah-Hartman 2:30-3:20 Experiences in Android Porting, Lessons learned, tips and tricks Mark Gross GeeXboX Enna: embedded Media Center Benjamin Zores FSCE: Reducing context switching time on ARM Gilles Chanterperdrix 3:20-3:40 Afternoon Break 3:40-4:30 Engaging Developer Communities: Lessons and Opportunity from webOS Matthew Tippett Strategies for Migrating Uniprocessor Code to Multi-Core Mike Anderson Measuring Responsiveness of Linux Kernel on Embedded System YungJoon Jung and DongHyouk Lim 4:40-5:30 Evaluation of Data Reliability on Linux File Systems Yoshitake Kobayashi Polishing Dirt: Porting RTOS code to Linux userspace driver framework Vitaly Wool GPIO: Talking to the Outside World Gene Sally 5:30-7:30 Break for Dinner 7:30-9:00 Small Business Owners BOF Grant Likely BOF: eLinux.org wiki present future Bill Traynor Session Schedule Tuesday, April 13 Time Imperial A Osaka Spring 8:00-9:00 Registration and Breakfast Imperial Ballroom Foyer 9:00-9:50 Keynote: Embedded in 2010: An End to the Entropy? Matt Asay 10:00-10:50 Runtime Power Management: Overview and Platform Implementation Kevin Hillman Creating a Secure Router Using SELinux Mike Anderson Porting the Linux Kernel to x86 MID platforms Jacob Pan 11:00-11:50 Embedded Multi-core with Adeos Dan Malek Understanding threat models for embedded devices Jake Edge DVFS for the Embedded Linux Yong Bon Koo, Youngbin Seo 12:00-1:30 Lunch Imperial B 1:30-2:20 Ftrace embedded edition Steven Rostedt Wake-ups effect on idle power for Intel's Moorestown MID and smartphone platform German Monroy Lock-free algorithm for Multi-core architecture Hiromasa Kanda 2:30-3:20 State of Embedded Linux Tim Bird Linux toolchain overview with advanced debugging and tracing features Dominique Toupin Implementing asynchronous zero-copy API for embedded IVR appliction Alexey Volkov 3:20-3:40
[linuxkernelnewbies] Porting device drivers to the 2.6 kernel [LWN.net]
http://lwn.net/Articles/driver-porting/ Porting device drivers to the 2.6 kernel [Posted February 11, 2003 by corbet] The 2.6 kernel contains a long list of changes which affect device driver writers. As part of the task of porting the Linux Device Drivers sample code to 2.6, your humble LWN Kernel Page author is producing a set of articles describing the changes which must be made. The articles are Kernel Page as they are written; they will also be collected here. With luck, this page will be a useful reference for those who must port drivers to the new kernel. The creation of these articles is funded by LWN.net subscribers. If you find this material useful, please consider subscribing to LWN to help ensure that more of it gets written. Except when otherwise specified, all of the articles below are written by LWN editor Jonathan Corbet. The date and kernel version attached to each article notes when the article was last updated. Recent changes The most recent changes to this series are: (April 28, 2004) The Workqueue Interface updated to include create_singlethread_workqueue(), which was merged in 2.6.6. (January 6, 2004) Supporting mmap() and Dealing with interrupts have been updated to reflect API changes in 2.6.1. (November 25, 2003) The entire set of articles has been updated to reflect the 2.6.0-test10 kernel. Getting started Porting 'hello world' (February, 2003); which covers the changes required to update the simplest possible module to the 2.5 kernel. Compiling external modules (November, 2003; 2.6.0-test9); how to build modules with the new module loader and kernel build scheme. More module changes (November, 2003, 2.6.0-test9) covers other changes to the module loading subsystem, including module parameters, use count management, exporting symbols, and more. Miscellaneous changes is a collection point for changes which are too small to justify their own article. Currently covered topics include kdev_t, designated initializers, and min() and max(). It was last updated on November3, 2003 (2.6.0-test9). Support interfaces Char drivers and large dev_t (November 2003, 2.6.0-test9); registration and management of char drivers in the new, large dev_t environment. The seq_file interface (September 2003; 2.6.0-test6); the easy way to implement virtual files correctly. A standalone example module is provided to demonstrate the use of this interface. Low-level memory allocation (November, 2003; 2.6.0-test9); changes to functions for allocating chunks of memory and pages, and a description of the new mempool interface. Per-CPU variables (November, 2003; 2.6.0-test9); the 2.6 interface for maintaining per-CPU data structures. Timekeeping changes (November, 2003; 2.6.0-test9); changes to how the kernel manages time and time-related events. The workqueue interface (April, 2004; 2.6.6-rc3); a description of the new deferred execution mechanism which replaces task queues (and bottom halves in general). Creating virtual filesystems with libfs (November, 2003; 2.6.0-test9). This article, which looks at how a kernel module can create its own virtual filesystem, predates the driver porting series but fits in well with it. DMA Changes (November, 2003, 2.6.0-test9); changes to the DMA support layer. There is also a quick reference page for the new generic DMA API. Sleeping and mutual exclusion Mutual exclusion with seqlocks (November, 2003, 2.6.0-test9); a description of how to use the seqlock (formerly frlock) capability which was merged into 2.5.60. The preemptible kernel (November, 2003; 2.6.0-test9); a look at how kernel preemption affects driver code and what can be done to work safely in the preemptible environment. Sleeping and waking up (November, 2003; 2.6.0-test9); new ways of putting processes to sleep with better performance and without race conditions. Completion events (November, 2003; 2.6.0-test9); documentation for the completion event mechanism. Using read-copy-update (November, 2003; 2.6.0-test9); working with the read-copy-update mutual exclusion scheme. Advanced driver tasks Dealing with interrupts (January, 2004; 2.6.1-rc2); interrupt handling changes which are visible to device drivers. Supporting asynchronous I/O (November, 2003; 2.6.0-test9); how to write drivers which support the 2.6 asynchronous I/O interface. Network drivers (November 2003, 2.6.0-test9); porting network drivers, with an emphasis on the new dynamic net_device allocation functions and NAPI support. USB driver API changes (July 2003; 2.5.75); how USB drivers have changed in the 2.5 development series. This article was contributed by USB maintainer Greg Kroah-Hartman. Block drivers Block layer overview (November, 2003; 2.6.0-test9). The block layer has seen extensive changes in the 2.5 development series; this article gives an overview of what has been done while deferring the details for subsequent articles. A simple block driver (November, 2003; 2.6.0-test9);
[linuxkernelnewbies] Broadcom.com - Ethernet NIC Resource Documents
http://www.broadcom.com/support/ethernet_nic/resource_documents.php Ethernet NIC Resource Documents The following collateral documents are available in support of Broadcom's Ethernet Controller products: E-Books Architecting Next Generation Networks E-book Technical Briefs NetXtreme II Converged Interface Controller ASF 2.0: Improving Client Manageability Whitepapers 1-Gigabit TCP Offload Engine Power Savings iSCSI Boot Functionality: Diskless Booting Enables SAN-like Benefits at Lower Costs Windows TCP Chimney: Network Protocol Offload for Optimal Application Scalability and Manageability From Ethernet Ubiquity to Ethernet Convergence: The Emergence of the Converged Network Interface Controller Moving Towards an Agile, High ROI Data Center: The Value of the Converged Network Interface Controller Supporting the Alert Standards Format (ASF) 2.0 Specification Broadcom Ethernet Network Controller Enhanced Virtualization Functionality
[linuxkernelnewbies] Broadcom.com - Ethernet NIC Open Source Developer Resources
http://www.broadcom.com/support/ethernet_nic/open_source.php Ethernet NIC Open Source Developer Resources Broadcom has made the following documents available to assist open source developers who are writing software for Broadcom's NetLink, NetXtreme, and NetXtreme II family of wired Ethernet controllers. This page will be regularly updated as additional devices or resources are released. Product Resources Part # Product Brief Programmer's Guide BCM4401 N/A * 440X-PG02-R BCM5700 N/A * 57XX-PG105-R BCM5701 N/A * 57XX-PG105-R BCM5702 N/A * 57XX-PG105-R BCM5703 N/A * 57XX-PG105-R BCM5703S N/A * 57XX-PG105-R BCM5704C 5704C-PB05-R 57XX-PG105-R BCM5705 N/A * 57XX-PG105-R BCM5705M 5705M-PB03-R 57XX-PG105-R BCM5706 5706-PB04-R NetXtremeII-PG203-R BCM5708C 5708C-PB09-R NetXtremeII-PG203-R BCM5708S 5708S-PB08-R NetXtremeII-PG203-R BCM5709C 5709C-PB02-R NetXtremeII-PG203-R BCM5709S 5709S-PB02-R NetXtremeII-PG203-R BCM5716 N/A * NetXtremeII-PG203-R BCM5721 N/A * 57XX-PG105-R BCM5722 N/A * 5722-PG101-R BCM5723 5723-PB01-R 5723-PG100-R BCM5751 5751-PB03-R 57XX-PG105-R BCM5751M 5751M-PB02-R 57XX-PG105-R BCM5752 5752-PB02-R 57XX-PG105-R BCM5752M 5752M-PB01-R 57XX-PG105-R BCM5754 5754-PB01-R 5722-PG101-R BCM5755 N/A * 5722-PG101-R BCM5756M N/A * 5756M-PG101-R BCM5764M 5764M-PB01-R 5764M-PG100-R BCM5788 5788-PB01-R 57XX-PG105-R BCM5788M N/A * 57XX-PG105-R BCM5789 5789-PB01-R 57XX-PG105-R
[linuxkernelnewbies] Nouveau patches
Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Francisco Jerez curroje...@riseup.net but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say "staging", but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable.
[linuxkernelnewbies] 软件工程: 个人实验
http://soft.buaa.edu.cn/linux/content/singleexperiment.htm 个人实验 实验一 内核的配置编译和安装。 该实验需要先获取内核源代码，再配置内核、编译生成新内核、安装新内核、引导系统 ，从而让学生了解源代码结构、内核的配置方法，掌握内核的编译方法，理解内核的安 装过程，初步理解系统的引导过程。 详细内容请参见实 验01 内核的配置编译和安装.ppt。 实验二 内核模块 编写一个内核模块，分别实现函数init_module()、cleanup_module()，并向模块中添加新 的函数并编写测试程序，从而让学生深入理解Linux内核的模块机制及其特点、学习模块 编程的基本技能，掌握对内核模块加载、卸载、查看等管理操作。 详细内容请参见实 验02 内核模块 .ppt。 实验三 系统调用 该实验需要获取一份最新的内核源代码，在源代码中增加一个新的系统调用，编 译生成 新内核并引导，编写用户态程序测试新增的系统调用，从而使学生理解内核态和用户态概念，理解中断及其原理，理解内核及系统调用的原理，学习内核编程。 详细内容请参见实 验03 系统调用.ppt。 实验四 同步机制 本实验要设计并实现一个新的内核同步原语，它允许多个进程等待一个事件而阻塞，直到其他进程产生这个事件的信号为止，还要具体实现几个系统调 用，并编写测试程序。为了验证以上四个自己添加的系统调用的正确性，还需要另外编写一个用户态的应用程 序来测试。该测试程序应该显示内核函数在通用情况下的工作。从而使学生了解进程间同步技术，学习Linux同步原语，掌握进程间同步的实现技术。 详细内容请参见实 验04 同步机制.ppt。 实验五 共享内存 本实验要编写一个调用标准系统调用来使用共享内存程序，学习标准内核中共享 内存机制的实现，修改标准内核实现动态数据结构管理内存段，编译新内核，并进行测试，从 而使学生理解共享内存概念及机制，学习共享内存机制的实现及使用，修改标准内核实现动态数据结构管理内存段。 详细内容请参见实 验05 共享内存.ppt。 实验六 虚拟存储 本实验要用软件模拟硬件对给定的地址进行转换工作，用软件模拟硬件对缺页进 行缺页中断处理，并编写测试程序进行测试。以使学生理解虚拟地址空间和物理地址概念，理解页式存储管理如何实现地址转换，了解页式虚拟存储管理中如何处理 缺页中断，理解页面置换算法。 详细内容请参见实 验06 虚拟存储.ppt。 实验七 字符设备驱动程序 本 实验要求编写一个简单的字符设备驱动程序，要求该字符设备包括open()、write()、read()、ioctl()和release()五个基本 操作，并编写一个测试程序,验证驱动程序的正确性，以使学生理解Linux操作系统中的字符设备驱动程序结构，掌握简单的字符设备的驱动程 序的设计与编写方法，理解设备驱动程序的工作过程，理解Linux内核关于字符型设备的管理方法。 详细内容请参见实 验07 字符设备驱动程序.ppt。 实验八 块设备驱动程序 本实验要求编写一个简单的ramdisk块设备驱动程序。要求该块设备包括 open()、 request()、ioctl()和release()等基本操作，并编写测试程序,验证驱动程序的工作正确性。 以使学生了解Linux操作系统中的设备驱动程序的组成，编写简单的块设备驱动，并进行 测试，理解Linux操作系统的设备管理机制，了解USB设备驱动编程。 详细内容请参见实 验08 块设备驱动程序.ppt。
[linuxkernelnewbies] 软件工程: 源代码分析
http://soft.buaa.edu.cn/linux/content/analyse.htm
源代码分析
一. 从以下几个Linux内核关键部分源代码中选择2项进行分析和论述。
1．内核的启动。主要代码位置：Init/main.c。
2．内存映射。主要代码位置：mm/mmap.c,mm/mremap.c。
3．进程的创建。主要代码位置：kernel/fork.c：包含了get_pid和do_fork；
fs/exec.c：包含了do_execve。
4．打开文件。主要代码位置：fs/open.c。
5．信号量的实现。主要代码位置：ipc/sem.c
二. 针对所选择的主题，按以下内容写出分析报告。
1．所选内容的技术背景和应用价值
2．所使用的算法和数据结构
3．具体实现时函数的调用关系，并对各函数的基本功能进行说明
4．从操作系统原理的角度对所选择技术的优缺点及可能存在的改进方法进行分析。
三. 分析报告的内容、格式及要求
1．题目：根据自己所选内容自行拟定
2．摘要、关键词
3．技术的背景、特点和应用价值
4．数据结构表及变量说明
5．完成功能的主要函数表
6．重要程序段代码注释
7．代码阅读框图
8．功能说明
9．剖析体会：
① 结合操作系统的理论学习，谈操作系统具体功能如何实现。
② 阅读程序模块后有什么收获。
10．参考文献
分析报告要严格按要求内容撰写。根据论文的项目评分，缺项要减相应的分。
分析文档的篇幅应在8000字以上。
四. 流程概述
fork
linux通过clone()系统调用实现fork().这个调用通过一系
列的参数标志来指明父、子进程需要共享的资源.fork()、
vfork()和_clone()库函数都根据各自需要的参数标志去调用clone()。然后由clone()去调用do_fork()。
do_fork()完成了创建中的大部分工作，它的定义在kernel/fork.c文件中。该函
数调用copy_process()函数，然后让进程开始运行。
mmap
在用户空间可以通过mmap()系统调用获取内核函数do_mmap()的
功能。
mmap()系统调用定义如下：
void*mmap2(){void * start,
size_t length,
int prot,
int flags,
int fd,
off_t pgoff}
启动
当用户打开PC的电源，BIOS开机自检，按BIOS中设置的启动设备(通常是硬盘)启动，接
着启动设备上安装的引导程序lilo或grub开始引导Linux，Linux首先进行内核的引导，接
下来执行init程序，init程序调用了rc.sysinit和rc等程序，rc.sysinit和rc当完成系统初始化
和运行服务的任务后，返回init；init启动了mingetty后，打开了终端供用户登录系统，用
户登录成功后进入了Shell，这样就完成了从开机到登录的整个启动过程。
open
函数 int open( const char *
pathname, int flags); 参数pathname 指向欲打开的文件路径字符串。下列是参数flags 所能使用的旗
标.返回值 若所有欲核查的权限都通过了检查则返回0 值，表示成功，只要有一个权限被
禁止则返回-1。
信号量
Linux中的信号量是一种睡眠锁。如果有一个任务试图获得一个已经被占用的信号量时，
信号量会将其推进一个等待队列，然后将其睡眠。这时处理器能获自由，从而去执行其
他代码。当持有信号量的进程将信号量释放后，处于等待队列中的那个任务将被唤醒，
并获得该信号量。
[linuxkernelnewbies] Advogato: How Linux suspend and resume works in the ACPI age
http://www.advogato.org/article/913.html How Linux suspend and resume works in the ACPI age Posted 7 Feb 2007 at 11:16 UTC by mjg59 Back in the APM days, everything was easy. You called an ioctl on /dev/apm, and the kernel made a BIOS call. After that, it was all up to the hardware. Sure, it never really worked properly, and it was basically impossible to debug what the hardware actually did. And then ACPI came along, and nothing worked at all. Several years later, we're almost back to where we were with APM. But what's actually happening when you hit that sleep key? Without the ability to suspend and resume, laptop users are doomed to spend several hours of their lives waiting for machines to boot and shutdown. This is, clearly, suboptimal. APM made it fairly easy to implement this, because almost everything was handled by the BIOS. And that, in a nutshell, is one of the primary reasons why ACPI ended up in charge. The biggest problem with APM is that it left policy in hardware. Don't want to suspend on lid closure? The OS doesn't get any say in the matter, though if you're lucky there might be a BIOS option to control it. Would prefer it if the BIOS didn't scribble all over the contents of your video registers while it tries to reprogram them (probably back to the defaults of the Windows drivers...)? Sucks to be you. Want the sleep button to trigger suspend to disk, not suspend to RAM? A-ha ha ha. ACPI deals with that problem, by moving almost all the useful functionality out of hardware. The downside of this is that the functionality needs to be reimplemented in the OS. Which, given that the ACPI spec is around 600 pages long, has taken a little time. (Of course, it turns out that most of the ACPI spec is entirely uninteresting for suspend and resume purposes, but that's not really the point right now) So, firstly, lets have some ACPI jargon. ACPI itself stands for "Advanced Configuration and Power Interface". It's not just a power management spec - it provides the OS with a description of all the built-in hardware in your system, along with a certain degree of abstraction. It gives you information about interrupt routing, tells you if someone's just removed a hot-pluggable DVD drive from a laptop and may even let you control which video output is being used. This information is provided in a table called the DSDT (Discrete System Descriptor Table). The DSDT is in a bytecode called AML (ACPI Machine Language), compiled from a simple language called ASL (ACPI Source Language, shockingly enough). At boot time, the system reads the DSDT, parses it and executes various methods. These can do pretty much anything, but on the bright side they're being executed in kernel context and (in principle) you can filter out anything that you really don't want to do (such as scribbling all over CMOS or something). The final relevant piece of ACPI information is something called the FADT, or Fixed Address Descriptor Table. This gives the OS information about various register addresses. It's a static structure, and doesn't contain any executable code. So, how does all of this stuff actually work? First of all, the user hits the sleep key. This triggers a hardware interrupt, which is caught by the embedded controller. That pokes a register in the southbridge, which flags that a general purpose event has just occured. The OS notices this, and checks the DSDT for what's supposed to happen next. Generally, this just calls a notification event. This is bounced back out to userspace via /proc/acpi/events (currently, though it's going to be moved to the input layer in future) and userspace gets to choose what happens next. Let's concentrate on the common scenario, which is that someone hitting the sleep button wants to suspend to RAM. Via some abstraction (either acpid, gnome-power-manager or kpowersave or something), userspace makes that decision and initiates the suspend to RAM process by either calling a suspend script directly or bouncing via HAL. Depending on distribution, this ends up running a shell script or binary which attempts to prepare the system for suspend. Right now, this tends to involve a bunch of bandaids around various broken drivers - unloading modules and reloading them is one of the easiest workarounds for breakage. Finally, the string "mem" is written to /sys/power/state. This jumps back into the kernel. First, userspace is stopped. This stops it getting horribly confused when a load of hardware mysteriously stops working. Then the kernel goes through the device tree and calls suspend methods on each bound driver. Individual drivers have responsibility for storing enough state in order to be able to reprogram the device on resume - ACPI doesn't make guarantees about what the hardware state is going to be when we come back. Once the kernel-side suspend code has been run, we execute a couple of ACPI methods - PTS (Prepare To Sleep) and GTS (Going To Sleep). These tend to poke
[linuxkernelnewbies] Forensic Recovery and the Blackberry
http://gse-compliance.blogspot.com/2009/04/forensic-recovery-and-blackberry.html Sunday, 5 April 2009 Forensic Recovery and the Blackberry It is possible to acquire an image of a bit-by-bit backup using the Blackberry Software Development Kit (SDK). The SDK is available from RIM at http://www.blackberry.com. The SDK utility dumps the contents of the Flash RAM into a file. Once the Flash RAM is dumped, it can be examined and reviewed using traditional methods with your favourite hex editor or other tool. At this point it is basically a raw image file. This is a memory image of course, so you cannot carve files in the same manner as from an NTFS partition, but it is similar to memory forensics. Strings are available and the image will hold binary files and a number of databases. As for commercial tools, I do not think that there are a great deal to choose from. A few do exist, but I generally have been sticking to the SDKs as the commercial tools are not as mature as they could be. In addition to reviewing the evidence with traditional methods, you can use the Simulator from the SDK to match the network and model of the investigated unit. The simulator crashes on a number of non-standard calls as RIM have not thought of things that are not designed for the Blackberry in the first place. It does act as a Blackberry for the most part and you can copy image files such that you do not alter evidence. The SDKs are a good start if you have some programming skills. E.g. http://www.blackberry.com/developers/downloads/jde/index.shtml I used to have a link to the Blackberry C++ Software Development Kit, but it seems to have changed and moved or have been deleted. I have a copy of the C++ SDK, but the link has moved. The Java SDK is active and this is what I have been using. There is a Yahoo developer group with a few people working in this area- http://tech.groups.yahoo.com/group/BB386dev/ This group has no commercial quality code, but there is source that you can use to do the following: View the contents of any file in the user flash area Dump Flash memory The group is primarily focused on the older versions. There are some tools in the SDK that you can use to dump flash. Also the Yahoo site used to have a tool hosted called "programmer.exe" that would dump the complete flash (bit wise) from a BB and save it as a raw image. I have not checked the link location for a while and have a copy anyway. The SDK has replaced the programmer.exe file with the javaloader application (javaloader.exe). I do not know which versions support which phone off the top of my head and would have to look up the SDK documentation. The newer Blackberries certainly use the Java version. There are several places where you can hide information in a Blackberry. It is possible to create hidden databases and hide information in partition gaps. Data can also be hidden in the gap between the OS/application and file partitions. Alternatively, numerous tools and methods to attack a Blackberry are available. Firstly, there is a toolset called the Blackberry Attack Toolkit, which along with the BBProxy software can be used to Load exploitable Web site vulnerabilities and hence attack the BlackBerry using a number of _javascript_ and Java code issues.. The next Attack Vector involves downloading (what is generally) malicious software to the Blackberry. Such a method is the method of hijacks (or blackjacks). As the name implies, this allows someone to hijack a legal users Blackberry and replace them on the network with potentially harmful devices. The Presentation and toolkit for blackjacking are available at: http://www.praetoriang.net/presentations/blackjack.html They have also developed Metasploit patches for those who cannot run code manually. BBScreenShooter and BBScreenStream use javaloader.exe from RIM to function. They can provide screen shots and captures Have a look at (http://na.blackberry.com/eng/developers/started/) for more information. On top of this, there are a number of other tools that are of use. One such program is JL_Cmder. This is short for the JavaLoader Commander. The JavaLoader commander is the blackberry command line tool (from RIM and not a random internet source). The JL_Cmder programme simplifies the process of accessing most of the common JavaLoader.exe commands. It can also be scripted and used in Java .cab files and even in _javascript_ from a website. JL_Cmder will allow you to issue the following commands: deviceinfo - Displays information about the handheld. eventlog - Retrieves and displays the handheld event log. screenshot - Takes a picture of the handheld screen. (OS 4.0.2+ required) wipe - Erases the handheld OS. Not really, but that is the simpliest way to explain it. resettofactory - Removes the IT Policy from the device. (OS 4.3+ required). JL_Cmder can be used to automatically export data from the device into a text file for easier reading/imaging. It
[linuxkernelnewbies] BlackBerry - Presenter Open Source Components
http://na.blackberry.com/eng/support/accessories/opensourcecomponents.jsp BlackBerry Presenter Open Source Components Open Source Components Name Version Changes BlueZ 4.22 [bluez_part1.diff] [bluez_part2.diff] bluez-hcidump 1.4.2 pkg-config 0.2 GLib 2.16.0 Expat 2.0.1 D-Bus 1.0.2 D-Bus-GLib 0.74 GNU Libtool 1.4.2 BusyBox 1.2.2.1 libgcc1 (libgcc2.c) 4.2.0 [LICENSE-GPL2-LIBGCC-exception.TXT] glibc 2.5.90 [LICENSE-BSD-LIBM.TXT] [LICENSE-BSD-LIBUTIL.TXT] Linux-PAM 0.79 [LICENSE-BSD-LIBPAMC.TXT] [LICENSE-BSD-LIBPAM_MISC.TXT] libwrap 0.7.6 [LICENSE-BSD-LIBWRAP.TXT] e2fsprogs 1.39 [LICENSE-BSD-LIBUUID.TXT] Das U-Boot 1.2.0 [uboot_part1.diff] [uboot_part2.diff] Bitstream Vera 1.1 [LICENSE-BITSTREAM-VERA.TXT] FreeType 2 2.3.9 Open Source Drivers Name Changes VESA gpio [vesa_gpio.diff] I2C gpio [i2c-gpio.c] push_button [push_button.diff] board-dm355-evm [board-dm355-evm.diff] fs455_encoder [fs455_encoder.diff] davinci_enc_mngr [davinci_enc_mngr.diff] davinci_osd [davinci_osd.diff] davinci_platform [davinci_platform.diff] file_storage [file_storage.diff] Learn More Download all components and drivers listed above (.rar) View the GNU General Public License (PDF) View the GNU Lesser General Public License (PDF)
[linuxkernelnewbies] NI Developer Zone :: Tutorials - Results for National Instruments Search
http://search.ni.com/nisearch/app/main/p/ap/tech/lang/en/pg/1/ps/30/sn/catnav:tu,ssnav:dzn Tutorial: Arrays and Clusters This tutorial examines array and cluster data types and gives you an introduction to creating and manipulating arrays and clusters. zone.ni.com/devzone/cda/tut/p/id/7571 Spread-Spectrum Clocking Spread-spectrum clocking is a fundamental way that electronic devices can contain oscillators but not produce more electromagnetic interference than allotted by ... zone.ni.com/devzone/cda/tut/p/id/4154 Measuring Strain with Strain Gages This tutorial is part of the National Instruments Measurement Fundamentals series. Each tutorial in this series will teach you a specific topic of common measurement ... zone.ni.com/devzone/cda/tut/p/id/3642 How to Do a Serial Loopback Test A loopback test allows you to send and receive data from the same serial port to verify that the port is operational. To perform this test, you need to temporarily ... zone.ni.com/devzone/cda/tut/p/id/3450 Design and Simulation of ECC Circuits Using NI Electronics Workbench Group Software Author: Prof. M. Altaf Mukati, Hamdard University ECC (error control coding) circuits have been used since 1961 for correcting errors in various telecommunications ... zone.ni.com/devzone/cda/tut/p/id/6480 Field Wiring and Noise Considerations for Analog Signals Unfortunately, measuring analog signals with a data acquisition device is not always as simple as wiring the signal source leads to the data acquisition device. ... zone.ni.com/devzone/cda/tut/p/id/3344 Remotely Controlled Automobile - iPhone, Power Wheels, Laptop The goal of this project is to be able to remotely control an automobile. This involves building an automobile control system (ACS), and a remote system that sends ... zone.ni.com/devzone/cda/tut/p/id/10488 An Introduction to Peer-to-Peer Streaming Introduction to Peer-to-Peer Streaming NI peer-to-peer (P2P) streaming technology uses PCI Express to enable direct, point-to-point transfers between multiple instruments ... zone.ni.com/devzone/cda/tut/p/id/10801 PCI Express An Overview of the PCI Express Standard This document examines the success of the widely adopted PCI bus and describes the higher-performance next generation of I/O interconnect technology PCI Express ... zone.ni.com/devzone/cda/tut/p/id/3767 Creating a Distributed System With NI VeriStand 2009 Large distributed control systems, such as those found in airplanes or cars, often require more computational power and I/O to simulate and test than a single PXI ... zone.ni.com/devzone/cda/tut/p/id/11060 Schedule Your Personal Online LabVIEW Demo with a NI Engineer Discuss the basics of graphical programming with an applications engineer and explore how LabVIEW can meet your specific application needs. In this free one-hour ... zone.ni.com/devzone/cda/tut/p/id/10864 The Fundamentals of FFT-Based Signal Analysis and Measurement in LabVIEW and LabWindows/CVI **NOTE: The content in this document might not reflect the most updated information available. Refer to the LabVIEW Help for the most updated information. The Fast ... zone.ni.com/devzone/cda/tut/p/id/4278 Vibration Fatigue Analysis in LabVIEW Fatigue is localized damage to a material or component as a result of cyclic loading. As a material experiences an increasing number of loading cycles, minute cracks ... zone.ni.com/devzone/cda/tut/p/id/10991 Choosing the Right Hardware for Your Vision Applications National Instruments offers a range of hardware options that support image acquisition and processing. In this document, explore how to choose among these different ... zone.ni.com/devzone/cda/tut/p/id/10895 What Is RIO Technology? NI reconfigurable I/O (RIO) technology is an integral part of the NI graphical system design platform. A modern approach to designing, prototyping, and deploying ... zone.ni.com/devzone/cda/tut/p/id/10894 01-Iniciando un Nuevo Proyecto Virtaul 01-Iniciando un Nuevo Proyecto Virtaul is a Tutorial - Introduction 1.- Crear un VI con la interfaz de Simulacim de Elicas. 2.- Hacer las pruebas de Funcionamiento. ... decibel.ni.com/content/docs/DOC-9947 2009 Medical Grant Report In 2009, the National Instruments Medical Device Grant Committee awarded 34 companies more than $600,000 USD in software, training, and services. A few of the companies ... zone.ni.com/devzone/cda/tut/p/id/10992 3D -Video: One of Seven New Features to Test in HDMI 1.4 This document addresses the introduction of 3D video with the HDMI 1.4 standard and what it means for Test Engineers. zone.ni.com/devzone/cda/tut/p/id/11077 Relay Forms Relays are classified by their number of poles and number of throws. The pole of a relay is the terminal common to every path. Each position that the pole can connect ... zone.ni.com/devzone/cda/tut/p/id/4782 Automation of the calibration process of longitudinal pattern according to ISO 3650 Automation of the calibration process of longitudinal pattern according to
[linuxkernelnewbies] The optimized SIMD library for x86 processors
http://simdx86.sourceforge.net/ libSIMDx86 v0.4.0 The optimized SIMD library for x86 processors. Jump to: Reference Building Roadmap Homepage: www.sourceforge.net/projects/simdx86 What is libSIMDx86? libSIMDx86, also know as just SIMDx86, is an optimized math library meant for developers of 3D games engines, 3D visualizations, 3D software rasterizers, and other simulations that uses SIMD instructions, that is Single Instruction, Multiple Data. Later it will support pixel operations for images, and digital signal processing. How does it work? The simple answer is with SIMD instructions: Ever since the Pentium MMX, x86 microprocessors have had special instructions that perform operations that cannot be represented by a single operation in C/C++, as well as many other programming languages. Often times these instructions can be used to unroll a loop, or do many operations per clock cycle, such as operate on four values (vector processing) instead of just one (scalar processing). The end result is code that runs anywhere from 0% to 2000% faster, depending on the circumstance and processor. But I already wrote my library in C/C++, why use this? Code written in C/C++ must be translated in assembly language by your compiler. Since the compiler often misses the larger picture and focuses on a per-line or per-element basis, it often outputs instructions that are scalar operations (i.e. work on a single value at a time) even when, to a human, the parallelism is apparent. Very few compilers output vector, or SIMD instructions because it requires an extremely sophisticated compiler. libSIMDx86 however is about 95% written in assembly language using vector (SIMD) instructions and does not need to be translated into a lower level language. Also, since humans can think on a problem, some interesting solutions that aren't available to the non-thinking compilers have been come up with. Why create this library? Let's face it, compilers are getting much better. Even before these special SIMD instructions, people use to write the most critical parts of their code in assembly language in order to get as much performance out of their processor as possible. Now, it seems that using basic assembly language for things gets you code that is on-par with the compiler. Compilers such as the GNU C Compiler have mastered the i386 instruction set and all of its quirks. However, while a rather large mastery of this has been obtained, SIMD output has always been a difficult task for compilers since the constructs of SIMD capable code is usually quite difficult to translate, much less see the author's intent. Efforts have been made, but even the simplest SIMD constructions still baffle compilers. Until that day far in the future where compilers output SIMD code correctly and efficiently, this library will allow programmers take advantage of SIMD operations that have been lying dormant in their processors since the Pentium MMX (1997). The results can be from no to mild to dramatic improvements in performance. Another problem is that high levels of abstractions often cause the programmer to forget the hardware the program is running on. Learning assembly language is considered obsolete for all but the most esoteric reasons, such as writing an OS kernel or hacking programs. However, knowledge of the machine's architecture and instruction set allows people to take advantage of the true power of their processor and squeeze every ounce of performance out of it. In short, for those of us who do not want to learn SIMD assembly language but want to take advantage of a powerfully optimized library without sweating, this is for you. A thing to note is that out of all of Sourceforge, there are not any relatively complete libraries available that use SIMD instructions. What about Intel and AMD? Don't they make a similar library? Indeed they do, and I wouldn't be half surprised if they outperformed libSIMDx86 right now. However, one has to also understand that each company has not only a team of extremely diligent programmers, but that they also have written a library that is optimal for their implementation of the x86 architecture. That means, given two processors, one from Intel and one from AMD, that perform perfectly equal in everything else, running the Intel math library will work better for the Intel processor and the AMD library will work for the AMD processor better! Why is this? AMD/Intel know the best way of doing things for their architecture. Sometimes the optimization is at a hardware level, others at a software. Hardware level optimizations, i.e. programming for a single processor such as the Athlon64, is one optimization that the Intel/AMD math libraries will have over this one. However, this library will attempt to blend performance for many processors, even support for older processors, not just the latest and greatest Pentium IV or Athlon64 (at the time of this writing). Another thing to note is that their libraries are not
[linuxkernelnewbies] Reference_CDROM_Essays_on_Kernel_Design(): Classic papers on BSD Unix Design
http://www.386bsd.org/past/essays
void
Reference_CDROM_Essays_on_Kernel_Design() {
/*
* Modular Kernel Design
*/
e1994_11a();
/*
* So You Want to Write a UNIX Paper
*/
e1994_11b();
/*
* CPU Kernel Facilities
*/
e1994_11c();
/*
* Process Creation
*/
e1994_11d();
/*
* Process Termination
*/
e1994_11e();
/*
* Process Exceptions via Signals
*/
e1994_11f();
/*
* Process Protection
*/
e1994_11g();
/*
* Process Privileges
*/
e1994_11h();
/*
* Executable File Format Emulator
*/
e1994_11i();
/*
* File Descriptors
*/
e1994_11j();
/*
* Kernel Memory Allocator
*/
e1994_11k();
/*
* Configuration in Kernel Design
*/
e1994_11l();
/*
* Process Scheduling
*/
e1994_11m();
/*
* Memory Maps
*/
e1994_11n();
/*
* Memory Objects
*/
e1994_11o();
/*
* Paging Mechanism
*/
e1994_11p();
/*
* Page Reclamation
*/
e1994_11q();
/*
* Fault Handling
*/
e1994_11r();
/*
* Filesystem Cache Management
*/
e1994_11s();
/*
* Filesystem Lookup
*/
e1994_11t();
/*
* Assembly Entry and Primitives
*/
e1994_11u();
return();
/* list of all items by williamlynne;
jolitz */
}
[linuxkernelnewbies] NI Developer Zone :: Tutorials
http://search.ni.com/nisearch/app/main/p/ap/tech/lang/en/pg/1/ps/30/sn/catnav:tu,ssnav:dzn Tutorial: Arrays and Clusters This tutorial examines array and cluster data types and gives you an introduction to creating and manipulating arrays and clusters. zone.ni.com/devzone/cda/tut/p/id/7571 Spread-Spectrum Clocking Spread-spectrum clocking is a fundamental way that electronic devices can contain oscillators but not produce more electromagnetic interference than allotted by ... zone.ni.com/devzone/cda/tut/p/id/4154 Measuring Strain with Strain Gages This tutorial is part of the National Instruments Measurement Fundamentals series. Each tutorial in this series will teach you a specific topic of common measurement ... zone.ni.com/devzone/cda/tut/p/id/3642 How to Do a Serial Loopback Test A loopback test allows you to send and receive data from the same serial port to verify that the port is operational. To perform this test, you need to temporarily ... zone.ni.com/devzone/cda/tut/p/id/3450 Design and Simulation of ECC Circuits Using NI Electronics Workbench Group Software Author: Prof. M. Altaf Mukati, Hamdard University ECC (error control coding) circuits have been used since 1961 for correcting errors in various telecommunications ... zone.ni.com/devzone/cda/tut/p/id/6480 Field Wiring and Noise Considerations for Analog Signals Unfortunately, measuring analog signals with a data acquisition device is not always as simple as wiring the signal source leads to the data acquisition device. ... zone.ni.com/devzone/cda/tut/p/id/3344 Remotely Controlled Automobile - iPhone, Power Wheels, Laptop The goal of this project is to be able to remotely control an automobile. This involves building an automobile control system (ACS), and a remote system that sends ... zone.ni.com/devzone/cda/tut/p/id/10488 An Introduction to Peer-to-Peer Streaming Introduction to Peer-to-Peer Streaming NI peer-to-peer (P2P) streaming technology uses PCI Express to enable direct, point-to-point transfers between multiple instruments ... zone.ni.com/devzone/cda/tut/p/id/10801 PCI Express An Overview of the PCI Express Standard This document examines the success of the widely adopted PCI bus and describes the higher-performance next generation of I/O interconnect technology PCI Express ... zone.ni.com/devzone/cda/tut/p/id/3767 Creating a Distributed System With NI VeriStand 2009 Large distributed control systems, such as those found in airplanes or cars, often require more computational power and I/O to simulate and test than a single PXI ... zone.ni.com/devzone/cda/tut/p/id/11060 Schedule Your Personal Online LabVIEW Demo with a NI Engineer Discuss the basics of graphical programming with an applications engineer and explore how LabVIEW can meet your specific application needs. In this free one-hour ... zone.ni.com/devzone/cda/tut/p/id/10864 The Fundamentals of FFT-Based Signal Analysis and Measurement in LabVIEW and LabWindows/CVI **NOTE: The content in this document might not reflect the most updated information available. Refer to the LabVIEW Help for the most updated information. The Fast ... zone.ni.com/devzone/cda/tut/p/id/4278 Vibration Fatigue Analysis in LabVIEW Fatigue is localized damage to a material or component as a result of cyclic loading. As a material experiences an increasing number of loading cycles, minute cracks ... zone.ni.com/devzone/cda/tut/p/id/10991 Choosing the Right Hardware for Your Vision Applications National Instruments offers a range of hardware options that support image acquisition and processing. In this document, explore how to choose among these different ... zone.ni.com/devzone/cda/tut/p/id/10895 What Is RIO Technology? NI reconfigurable I/O (RIO) technology is an integral part of the NI graphical system design platform. A modern approach to designing, prototyping, and deploying ... zone.ni.com/devzone/cda/tut/p/id/10894 01-Iniciando un Nuevo Proyecto Virtaul 01-Iniciando un Nuevo Proyecto Virtaul is a Tutorial - Introduction 1.- Crear un VI con la interfaz de Simulacim de Elicas. 2.- Hacer las pruebas de Funcionamiento. ... decibel.ni.com/content/docs/DOC-9947 2009 Medical Grant Report In 2009, the National Instruments Medical Device Grant Committee awarded 34 companies more than $600,000 USD in software, training, and services. A few of the companies ... zone.ni.com/devzone/cda/tut/p/id/10992 3D -Video: One of Seven New Features to Test in HDMI 1.4 This document addresses the introduction of 3D video with the HDMI 1.4
[linuxkernelnewbies] Linux Customization with MontaVista's Platform Developer Kit
http://www.mvista.com/platform_developers_kit.php Customize MontaVista Linux with the Platform Developer Kit The MontaVista Linux Platform Developer Kit (PDK) provides everything required to create and deliver a MontaVista Linux-based development platform: Including DevRocket, our industry-standard Eclipse IDE, broad CPU and board support, advanced analysis tools, and target application packages. The MontaVista PDK is the ultimate embedded Linux development solution. The MontaVista Linux Platform Developer Kit includes: Linux Support Package (LSP) Board support package targeting a wide range of hardware platforms. Includes a rich set of pre-built and tested drivers for on-chip and on-board devices. Target Application Packages Preconfigured, tested library of over 200 application and utility software packages such as Apache, FTP, and SSH, to support virtually any development need. Analysis Tools Include Platform Image Builder, System Trace, and System Profile, Memory Leak Detection, and Memory Usage Analysis delivered through an intuitive, interactive, and accessible Eclipse-based interface. CPU Architecture cross tool chain Complete set of Linux cross tools, including compliers debuggers, and run-time libraries required to build platforms and application binaries for specific CPU architectures - x86, ARM, MIPS, XScale, and Power Architecture (PPC). Continuity with Previous Versions of MontaVista Linux Many application development teams already have a significant code base on MontaVista Linux. The backward-compatible, MontaVista PDK allows developers to use the tool-chains from these previous versions, supporting easy discovery and porting of existing MontaVista Linux installations and making all editions dynamically available from within one interface. Streamlined Creation of Target File System Images Platform developers need to integrate and install dozens, sometimes hundreds of separate software components, but creating a target file system by hand is time-consuming, difficult, and complex. The MontaVista PDK radically simplifies this task. Platform Image Builder offers developers an easy-to-use graphical interface for selecting MontaVista Linux target packages, integrated custom packages, and kernels, dynamically determining file system size and automatically resolving dependencies and conflicts, then generating the file-system in several standard formats. Best-of-Breed Analysis Tools Linux platform analysis tools require specialized expertise and persistent maintenance to keep current with the Linux kernel and other open source technologies - generic open source versions or tools originally meant for RTOS analysis come up short in real-world Linux development. The MontaVista PDK features analysis tools targeted specifically for working with embedded Linux. delivering must-have capabilities like system-level statistical profiling, trace analysis, and memory leak detection and usage analysis. The PDK packages these tools in an intuitive and interactive user interface, simplifying and streamlining analysis and optimization. Graphical, Intuitive System Characterization Traditional Linux command line interface (CLI) tools can make it difficult to characterize a target system over time. The MontaVista PDK meets this challenge by integrating the best-of-breed CLI-based Linux Trace Tookit (LTTng) into an intuitive and accessible graphical user interface, enabling developers to measure and characterize target systems more quickly and easily. Broad Target and Host Support Protects Developer Investment The MontaVista PDK supports board-level platforms across five major CPU architectures. By providing a common look and feel across Linux, Windows, and Solaris development hosts, PDK provides a cross-development platform for development teams working across diverse environments. This broad platform and host support gives development teams the flexibly, continuity and interoperability to tailor their development platforms to their technical needs and team logistics.
[linuxkernelnewbies] Re: Managing Files through Module
why not you let Linux do the job? Inside the kernel module, u just have to call printk() and all output will go to file called /var/log/ dmesg, as overtime, as u can see below: -rw-r- 1 root adm 54121 2010-03-03 07:08 /var/log/dmesg -rw-r- 1 root adm 54656 2010-03-02 07:25 /var/log/dmesg.0 -rw-r- 1 root adm 13975 2010-03-01 07:20 /var/log/dmesg.1.gz -rw-r- 1 root adm 13922 2010-02-28 20:01 /var/log/dmesg.2.gz -rw-r- 1 root adm 14119 2010-02-28 15:23 /var/log/dmesg.3.gz -rw-r- 1 root adm 13974 2010-02-28 12:01 /var/log/dmesg.4.gz the userspace daemon klogd will check that the size of the file is too large, and autoarchive it via gzipping. The output of klogd is also viewable via dmesg command. If you output to a customized file, u can use logrotate (man logrotate) to archive the file automatically. checkout more about logging: http://www.linuxjournal.com/article/4036 And if u insist on creating a different output file for your applicationit is still via klogdman klogd to see more. But your application is still consistently using printk() as the API. On Mar 2, 11:09 am, perumal316 perumal...@gmail.com wrote: Hi, I am writing a kernel module which does logging. Currently I am writing the messages to a textfile. But I don't want this file to become too big. Is there any way I can specify to delete the file if it exceeds a certain size or write to a new file through kernel module? Thanks In Advance, Perumal
[linuxkernelnewbies] Multiple write to the same memory location problem
http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka4160.html If multiple masters write to the same memory location, what would be the result of a following read ? Applies to: GX175 Memory Controller GX175 and most memory controllers in general only ensurethat on the same AHB port, reads and writes are completed in the order they aresent. So, when an AHB master sends a write request to a memory location and then a read request to the same memory location, the write is completed first and then the read is serviced.However, write requests from multiple ports that write to the same memory locationwould not go through this check. If at the system level it needs to be ensured that the data read back from one memory location is the data written tothis location by another master, then this timing should be ensured at the system level. The memory controller will not take care of this. GX175 takes requests from its various AHBports and services these requests in a performance efficient manner. This might entail servicing a read request from ahigher priority port before a write request from a lower priority port. Hence it can not guarantee that accessrequests from different masters on different ports will getserviced in the order they are received. Article last edited on: 2008-09-09 15:47:51
[linuxkernelnewbies] Index of /~ngunton/foils2
http://www.cems.uwe.ac.uk/~ngunton/foils2/ Index of /~ngunton/foils2 Parent Directory c-code0.pdf c1.pdf ch4.pdf dir_roadmap.pdf drivers1.pdf drivers2.pdf error3.pdf errors1.5.pdf errors1.pdf errors2.pdf intro.pdf knr_argv1.pdf knr_argv2.pdf knr_argv3.pdf knr_argv4.pdf ls.pdf mem_alloc1.pdf mem_alloc1.ps mem_alloc2.pdf mem_alloc2.ps mem_alloc3.pdf mem_alloc3.ps mem_alloc4.pdf mem_alloc4.ps mem_alloc5.5.pdf mem_alloc5.5.ps mem_alloc5.pdf mem_alloc5.ps mem_alloc6.pdf mem_alloc6.ps mem_alloc7.pdf mem_alloc7.ps mem_alloc8.pdf mem_alloc8.ps mem_alloc9.pdf mem_alloc9.ps pcb_list.pdf process_info1.pdf process_info1.ps.pdf process_info2.pdf process_info3.pdf process_states.pdf processes0.pdf processes1.pdf processes2.pdf processes3.pdf processes4.pdf processes5.pdf structs0.pdf structs1.pdf syscall1.pdf syscall2.pdf syscall3.pdf taskstruct.pdf tokens_n_jumps1.pdf tokens_n_jumps2.pdf tokens_n_jumps3.pdf tokens_n_jumps4.pdf tokens_n_jumps5.pdf ttystuff.txt
[linuxkernelnewbies] S Like Suska
http://www.experiment-s.de/en/ S Like Suska Do you think, the Suska project is cool? Are you interested in software programming or modeling digital circuits? If thats the case we are proud to announce the opening of our Suska Shop. Check it out!. An Open Source Atari ST(E) IP-Core written in VHDL This is a fun project that has been started because of my interests in modelling digital logic. Suska has grown to a nearly full functional Atari ST(E) using VHDL as modelling language. At the very beginning it was just the address decoder of the GLUE custom chip which was replaced by a simple model. That was back in February 2003. Many hundreds of hours later all custom chips found in the Atari ST(E) have been replaced with a single FPGA. Even the 68000 CPU has been integrated. A big challenge after each modelling step was to test the results directly with the Atari main board keeping the same functionality as if they were original chips. For that we used Sphinx modules from Inventronik with a piggy-back and an adapter to replace each custom chip. We have pictures in our gallery if you are interested. More and more functions of the ST machines have been integrated into a single FPGA. Floppy Disk Controller, Blitter and last but not least the 68000 CPU found its way into the Suska FPGA. Thanks to a few donations we created the Suska main board. The circuit board includes an Altera (Cyclone II in BGA housing), Flash-Prom, RAM, as well as two Atmel MCs for the boot loader and for programming the FPGAs boot device. The board integrates all the typical Atari ST(E) interfaces. Using other FPGAs from different manufacturers like Actel, Lattice or Xilinx would have been an option too. The completion of the board lead us to another aspect: The operating system. For debugging purposes and because of copyrights we decided to go with EmuTOS an open source TOS. Thanks to Jens, debugging became pretty pain free. Suska is a long term project. The current state can be found in the blog or the progress list. Have fun with Suska Wolfgang
[linuxkernelnewbies] GNOME Project Listing
http://projects.gnome.org/ This page is a listing of GNOME-related projects and their related web pages. For a more complete, searchable list of applications, check out the GNOME Software Map. A a11y, GNOME Accessibility for people with disabilities Abiword, Word Processor Accerciser, Interactive accessibility explorer Agnubis, Presentation Program Anjuta, Integrated Development tool B Balsa, e-mail client Baobab, a directory tree analyzer Beagle, content indexer and search tool Beast/BSE, audio synthesis framework BillReminder, a small and quick desktop accounting application. Brasero, Burning Disc Application Buzztard, Music composer C Cheese, Take photos and videos with your webcam, with fun graphical effects Chronojump, jump and run timetracking and statistics Conduit, synchronization solution for GNOME desktop D Dj Dup, simple backup Deskbar-Applet, is a quick access and search applet DesktopWiki, Wiki integrated with the GNOME desktop Devhelp, API documentation browser GNOME Devtools, GNOME Development tools Dia, diagram creation program E Easy Publish and Consume Library, network-aware key/value store using HTTPS, DNS-SD and authentication Epiphany, Web Browser Evince, A Document Viewer Evolution, Groupware client Eye of GNOME, Image viewer F Fantasdic, dictionary application (DICT client) F-Spot, personal photo manager G Galeon, Web Browser GARNOME, build utility for the GNOME Desktop GB, GNOME Basic GCalctool, Desktop Calculator GConf, GNOME Configuration Daemon gDesklets, Desktop widgets framework GDM, GNOME Display Manager gdome2, GNOME DOM Engine gedit, Text Editor gevice, GNOME Network Device Manager GGet, Download Manager GNOME Commander, Light and fast file manager for GNOME GNOME Fax, Faxing Software GNOME Format, Simple Formatting Tool Gimp, Graphics package Glade, Interface Builder Glom, Database designer and user interface Gnac, Multimedia converter gnocl, Tcl binding GNOME DB, Generic database Interface GNOME Games, fun for your desktop GNOME-GCJ, Java bindings GNOME Usability Project GNOME Meeting, Video conferencing Software GNOME Network, Client Network-oriented Tools Gnome Python, Python Bindings GNOME Print, GNOME printing library GNOME System Tools, System Configuration GNOME Power Manager, System Configuration GNOME Scan, Scan as simple as you print Gnome Subtitles, Video subtitling for the GNOME desktop GNOME VFS, Filesystem Abstraction library Gnomeradio, a FM tuner application for GNOME GNU, GNU for which GNOME is sub-project Gnucash, Personal Finance Manager Gnumeric, Spreadsheet GOB, GNOME Object Builder Gossip, GNOME Jabber chat client Guppi, Charting application GStreamer, Multimedia Architecture gthumb, Image viewer and browser GTK+, Graphical Toolkit Library GTK-Doc, API documentation tool gtkmm, C++ bindings gtksourceviewmm, C++ bindings of gtksourceview. Extends the gtkmm API. GtkPerl, Perl Bindings Gtranslator, translation file editor Gucharmap, the GNOME Character Map, based on the Unicode Character Database Guikachu, resource editor for PalmOS applications GtkMathView, widget for MathML rendering, editing, interaction Gwget, Download Manager gyrus, IMAP/Cyrus administrator H Hipo, iPod Management Tool HotSSH, Secure Shell interface I Inkscape, Scalable Vector graphics Editor J Java-GNOME, Java bindings L libchamplain, Clutter/GTK+ map widget LibXML, XML library LibXSLT, XSLT library LinuxConf, System Administration Linux Screen Reader, Extensible assistive technology M Memprof, Dev. memory profiler Metacity, Window Manager Midnight Commander, File Manager Moleskin, Code Editor Mozilla, Browser and HTML rendering widget mpterm, Multi-tabbed terminal application Meld, Diff Merge and Source Control N Nanny, Gnome Parental Control Nautilus, File Manager Nautilus-actions, Add custom actions in Nautilus popup menu Nemiver, A GNOME C/C++ graphical debugger. Nemo, File Manager Netspeed, a
[linuxkernelnewbies] CompSysTech - International Conference on Computer Systems and Technologies
http://www.compsystech.org/index.php?cmd=dPagepid=cpr09 Conference Proceedings from 2009 PLENARY SESSION P.1. CompSysTech Ten Years after the Beginning Boris Rachev P.2. IPv6: The Next Big Bail-Out. Will IPv6 Save the Internet? Latif Ladid P.3. ICT infrastructure and Scientific Research Kiril Boyanov, Dimitar Todorov P.4. Polymorphic Architectures from Media Processing to Supercomputing Georgi Kuzmanov P.5. Advanced Scalable Algorithms for Advanced Architectures Vassil Alexandrov P.6. National Broadband Program of the Republic of Bulgaria Roumen Trifonov SESSION I Computer Systems I.1. Non-contact ultrasound method for identification of yogurt according to its butter content Nikolay Shopov, Raycho Ilarionov, Ivan Simeonov, Hristo Kilifarev I.2. Model Approach in the Design of Devices for 3D Information Input into Computing Environment Raycho Ilarionov I.3. Hardware implementation of strategies for servicing queues Stoyan Prokopov, Dimitar Tyanev I.4. Micro-pipeline Section For Condition-Controlled Loop Dimitar Tyanev, Stamen Kolev, Dragomir Yanev I.5. Outline of RISC-based Core for Multiprocessor on Chip Architecture Supporting Moving Threads Jani Paakkulainen, Jari-Matti Mkel, Ville Leppnen, Martti Forsell I.6. Photonic Crystal Fibers challenge Jordan Urumov, Zhejno Zhejnov I.7. Programming and applying of the multiple product distribution system by using PIC 16F877A microcontroller zcan Varul, Melih nal SESSION II Computer Technologies II.1. Experiences with Embedding MPL Security Monitors into Java Programs Jari-Matti Mkel, Ville Leppnen II.2. MVTsim -- Software Simulator for Multicore on Chip Parallel Computer Architectures Jari-Matti Mkel, Jani Paakkulainen, Ville Leppnen II.3. Dynamic reconfiguration of Multimodal Architectures Hicham Djenidi, Amar Ramdane-Cherif, Nicole Lvy, Chakib Tadj II.4. Evaluating the Method of the Transforming Ontology Axioms to Application Domain Rules Diana Kalibatiene, Olegas Vasilecas II.5. Cyclic Histogram Thresholding and Multithresholding Dimo Dimov, Lasko Laskov II.6. Researching product tiles in eBay using the eBay API Nikolaj Cholakov II.7. Security Assurance during the Software Development Cycle Isaac Agudo, Jose L. Vivas, Javier Lopez II.8. A practical approach for software project management Violeta Bozhikova, Mariana Stoeva, Krasimir Tsonev II.9. Spider vs. Prolog: Simulating Prolog in Spider Tzanko Golemanov, Kostadin Kratchanov, Emilia Golemanova II.10. Spider vs. Prolog: Computation Control Emilia Golemanova, Kostadin Kratchanov, Tzanko Golemanov II.11. Architectural Design of a Software Engine for Adaptation Control in the ADOPTA Elearning Platform Boyan Bontchev, Dessislava Vassileva, Boryana Chavkova, Vladimir Mitev II.12. Approach for data replication on MS SQL Server Dessislava Petrova-Antonova, Ivelina Vacheva II.13. Design of Service Level Agreements for Software Services Diana Berberova, Boyan Bontchev SESSION IIIA Application Aspects of Computer Systems and Technologies IIIA.1. Application of contemporary measurement and analysis techniques to human cardiovascular system Maja Brai Lotri, Aneta Stefanovska IIIA.2. A Bayesian Approach to Recognise Facial Expressions using Vector Flows Xiaofan Sun, Leon Rothkrantz, Dragos Datcu, Pascal Wiggers IIIA.3. A bottom-up approach of fusion of events in surveillance systems Leon Rothkrantz, Zhenke Yang, Michael Jepson, Pascal Wiggers, Dragos Datcu IIIA.4. FACS-coding of Facial Expressions Leon Rothkrantz, Dragos Datku, Pascal Wiggers IIIA.5. Controlling the Speed of Coding Line Conveyor Using Fuzzy Logic Atanas Atanassov IIIA.6. XPDL - Bringing Business and Software Together - a Case Study Orlin Genchev, John Galletly IIIA.7. A Vision-Based Attentive User Interface with (Semi-)Automatic Parameter Calibration Fabio Fosso, Marco Porta IIIA.8. A Design of an Integrated Document System for Project Management Iulian Intorsureanu, Rodica Mihalca, Adina Uta, Anca Andreescu IIIA.9. A General Software Development Process Suitable for Explicit Manipulation of Business Rules Anca Andreescu IIIA.10. Web based portfolio optimization Todor Stoilov, Krasimira Stoilova IIIA.11. Learning by Negation of the Negative Examples Single Model versus Double Model Zekie Shevked, Ludmil Dakovski IIIA.12. 12. Executable Petri Nets: Towards Modelling and Management of e Learning Processes Hristo Indzhov, Dimitar Blagoev, George Totkov IIIA.13. Implementation Design of Access Control System. Local Database in Flash Memory Array. Radoslav Mladenov, Sava Ivanov IIIA.14. Open Source Solution for a Workflow Execution Architecture Martin Tsenov, Krasimir Trichkov, Simeon Tsvetanov IIIA.15. One approach to HTML wrappers creation: using Document Object Model tree Viera Rozinajova, Ondrej Hluchy IIIA.16. Keeping Artifacts Alive: Towards a Knowledge Management System Hilda Tellioglu IIIA.17. 1-Wire Based Data Acquisition System Georgi Georgiev IIIA.18. Personalized
[linuxkernelnewbies] CompSysTech'08 - International Conference on Computer Systems and Technologies
http://ecet.ecs.ru.acad.bg/cst08/index.php?cmd=dPagepid=cpr CONFERENCE PROCEEDINGS PLENARY SESSION P.1. Computer Technologies for 3D Video Delivery for Home and Mobile Entertaiment Atanas Gotchev P.2. Electronic Governance Act Plamen Vachkov, Roumen Trifonov P.3. From eLearning to eUniversity Roumen Nikolov SESSION I Computer Systems I.1. Formation of Attribute Spaces Using Wavelets in Automatic Classification of Explosives Nikolai Shopov, Rajcho Ilarionov, Ivan Simeonov, Hristo Kilifarev I.2. Improvement and optimization of an embedded system for shorttime weather forecasting Hristo Kilifarev, Ivan Simeonov, Raycho Ilarionov SESSION II Computer Technologies II.1. Emotion Recognition Using Brain Activity Robert Horlings, Dragos Datcu, Leon J. M. Rothkrantz II.2. Address Block Segmentation Using Ensemble-Clustering Techniques Leon J. M. Rothkrantz, Mustafa Idrissi II.3. An Adaptable FSA Simulator Stoyan Bonev II.4. Computer Assisted Active Learning System Development for Critical Thinking and Flow Dilek Karahoca, Adem Karahoca, Ali Gngr, Ilker Yengin II.5. Text Search in Document Images Based on Hausdorff Distance Measures Andrey Andreev, Nikolay Kirov II.6. Innovative Concept of Open Source Enterprise Resource Planning (ERP) System Svilen Valkov II.7. On Some Drawbacks of the PHP Platform Nikolaj Cholakov II.8. Ontology-Based Examinational Students Work Retrieval Dilyana Budakova, Lyudmil Dakovski II.9. Development of Applications with Service Oriented Architecture for Grid Vladimir Dimitrov II.10. Architectural Framework for Dynamic Web-applications Aleksandar Stoev, Aleksandar Dimov II.11. Adaptable Evaluation Approach for Software Architecture Olfa Lamouchi, Amar Ramdan-Cherif, Nicole Lvy II.12. Comparison of Parallel Metaheuristics for Solving the TSP Milena Lazarova, Plamenka Borovska II.13. Parallel Simulated Annealing for Solving the Room Assignment Problem on Shared and Distributed Memory Platforms Milena Lazarova II.14. The Impact of Fragmentation over Streaming Video Traffic Delyan Genkov II.15. Algorithm and Testing Software for Avoiding Fragmentation at the Application Layer Delyan Genkov SESSION IIIA Application Aspects of Computer Systems and Technologies IIIA.1. F Function Based Identification of Affected Components in Cross-Domain Engineering Jivka Ovtcharova, Milan Marinov IIIA.2. Mobile Application for Determination of Users Text Entry Speed Tsvetozar Georgiev, Evgeniya Georgieva IIIA.3. Time Synchronization of Multimedia Streams and Objects Yordan Shterev IIIA.4. Performance of Multimedia Presentation with Branches by Synchronized Multimedia Integrated Language Yordan Shterev IIIA.5. Partitioning Parallel Discrete Event Simulation Hristo Valchanov, Nadezhda Ruskova, Dimitar Genov, Nedjalko Nikolov IIIA.6. Overheads Reduction of the Distributed Time Warp Simulation Hristo Valchanov, Nadezhda Ruskova, Trifon Ruskov IIIA.7. Parameter Estimation for Finite Mixtures of Generalized Partial Credit Models Dimiter Tsvetkov, Lyubomir Hristov IIIA.8. Modelling of Network Traffic With Self-Similar Process Evgeniya Gospodinova, Mitko Gospodinov IIIA.9. Comparison of Bees Algorithm, Ant Colony Optimisation and Particle Swarm Optimisation for PID Controller Tuning Karl O. Jones, Andr Bouffet IIIA.10. An Algorithm for Complex Spread Spectrum in Downlink Line of Mobile Link Systems CDMA2000 and UMTS Petar Petrov, Valentin Mutkov IIIA.11. Complex Spread Spectrum in Uplink Line of Mobile Link Systems CDMA2000 and UMTS Petar Petrov, Valentin Mutkov IIIA.12. Time-Delay Simulation Analysis of Local Controller Networks Nikolay Kakanakov, Mitko Shopov, Grisha Spasov IIIA.13. ABC - Alphabetical Computer-Based Handwriting Investigation System Dobrin Nestorov, Stefan Benchev, Stefan Bonchev, Georgi Gluhchev IIIA.14. Diagnosis Modelling of Urethral Obstructions Using Fuzzy Expert System Krat Zhtoullari, Ismail Sarita, Nihat Arikan IIIA.15. The Design of Fuzzy Expert System for
[linuxkernelnewbies] The First OpenSolaris Project: GCC Support : Edicts from CLUSTRON
http://blogs.sun.com/wesolows/entry/the_first_opensolaris_project_gcc1 DTrace is part of... | Main | OpenSolaris at OSCON Tuesday Jun 14, 2005 The First OpenSolaris Project: GCC Support OpenSolaris is (finally) available. I've been working on this every day I've been with Sun, though others have spent years on the effort, and it's an amazing milestone. Unlike most launches, though, this is the beginning of a new effort rather than the end of one. As much as we've done already, there's far more left to be done before OpenSolaris can fulfil all our promises and achieve all our goals. One promise we have fulfilled today is our commitment to make OpenSolaris accessible to people without the money or desire to buy compilers. Since most of Solaris is normally built with the Sun Studio compilers, this meant we'd need either to provide the compilers on the same terms as Solaris (also required to build OpenSolaris sources), or modify the sources to build and work with the GNU C compiler, available with source and free of charge under the terms of the GNU GPL. For reasons more illustrative of bureaucracy and human nature than of technological difficulties, we were unsure almost until the moment of launch whether we would be able to provide the Studio compilers under acceptable terms; therefore, another engineer and I have spent the last two and a half months porting OpenSolaris to gcc. At this point I had a nice writeup on inline assembly differences between the Studio and GNU compilers. But it relies on source code that isn't available yet - namely, the gcc-specific inline assembly files. So instead I'll talk about why it happened that way and why it's actually a good thing. I'll also talk about some straight-up bugs we found in the process of porting. We received word that a final Studio license had been agreed upon on June 3 - just 11 days ago! The license is free-as-in-beer and although somewhat vague seems reasonable enough. Of course, I prefer using only Free Software and promoting it whenever possible (as we're going with OpenSolaris), so I'd really rather use gcc. Our plan of record was to make a merged workspace available as "official" OpenSolaris. There were three sets of changes that needed to be merged together in the last three days leading up to launch: the gcc changes, which edit about 2500 files (mostly to fix compiler warnings), a large wad of renames to support the separation of code we're releasing now from that which we're hoping to release later (thousands of renames), and the coup d'grace, the addition of the CDDL license block to over 24,000 files. In the end, this gigantic 3-way merge proved impractical: there were over 1700 conflicts to resolve. Most are trivial and can easily be automerged by TeamWare, our revision control system, but the sheer volume and shortened schedule would have made adequate testing impossible. Instead of the three-way merge, then, we elected to take the minimum amount of change we could: the addition of the CDDL blocks and the separation of released from unreleasable source. That meant gcc support would not ship in the "official" sources - but it could still be made available to the developer community. This is important for several reasons - first, it illustrates an important principle: FCS quality all the time. That is, if it's not good enough for a customer, it's not good enough to be putback. Since there was no doubt in anyone's mind that the gcc work was not ready for either, that meant it also wasn't good enough to call OpenSolaris. Second, it offers us an opportunity to provide a glimpse into the way projects work. One of the most common questions we get is "so, if the gate always has to be golden, how does any major work ever get done?" Like most people, we do major work in "branches" off the trunk. TeamWare supports children of children and merging of independent workspaces with common ancestry, so that no complicated branching apparatus is needed as for CVS. What will be available on the gcc project page will be that project gate. You're invited to participate - there are over 300 mostly very small bugs to fix. One of the most significant kinds of bug we found were programs writing into string constants, confirming Osborne's Law. These programs ordinarily work properly because the Studio compilers place the string constants in the .data section or some other writable data section. The flag -xstrconst changes this behaviour, placing the strings in .rodata or a similar read-only segment and thus also allowing them to be shared. This reduces runtime memory usage but comes at a cost: buggy programs that attempt to write to the constant strings will trigger a
[linuxkernelnewbies] All About Circuits : Video Lectures
http://www.allaboutcircuits.com/videos/index.html Video Lectures The following video lectures were generously provided by Tim Fiegenbaum at North Seattle Community College. They are based on the text, Electronics for Computer Technology by David Terrell. 2003 Delmar Learning, a part of Cengage Learning, Inc. All rights reserved. Reproduced by permission. Text/images may not be modified or reproduced in any way without prior written permission of the publisher (www.cengage.com/permissions). Electronic Systems Representative Systems (10:36) System Notations (19:33) Physical System Hierarchy (13:34) System Connectivity (9:32) Elements of System Level Troubleshooting (14:50) Circuit Simulation (2:14) Basic Electronics and Units of Measure Electrical Quantities A (25:57) Electrical Quantities B (20:05) Light and Other Waves (6:53) Magnetism and Electromagnetism (14:48) Basic Components and Technical Notation Technical Notation (16:58) Wire and Cable (19:31) Electronic Components A (7:46) Electronic Components Resistors (23:40) Electronic Components (14:46) Circuits Basic Requirements for Current (8:15) Series Circuits A (13:21) Series Circuits B (9:52) Series Circuits C (6:28) Parallel Circuits (15:56) Series Parallel Circuits (9:10) Complex Circuits (5:28) Ground and Other Reference Points (5:42) Circuit Troubleshooting Troubleshooting Series Circuits (13:54) Troubleshooting Series Circuits (9:53) Troubleshooting Parallel Circuits (8:33) Troubleshooting Series-Parallel Circuits (8:26) Troubleshooting Strategies (8:33) Alternating Current Generation of Alternating Voltage (14:26) Sine Wave Characteristics (10:43) Sine Wave Characteristics (cont) (16:48) Working with Phase Angles (11:53) Working with Phase Angles (cont) (19:47) Circuit Analysis of AC Resistive Circuits (15:37) Alternating Voltage Applications (9:11) Inductors,Capacitors,Transformers Inductors (Part 1) (25:28) Inductors (Part 2) (16:27) Inductors (Part 3) (4:00) Transformers (Part 1) (20:28) Transformers (Part 2) (15:03) Capacitors (Part 1) (14:22) Capacitors (Part 2) (10:18) Capacitors (Part 3) (10:12) RC and RL Circuits (4:40) Parallel RC Circuits (4:55) RC Time Constants (Part 1) (13:56) RC Time Constants (Part 2) (7:25) Semiconductor Technology Basic Atomic Theory (3:36) Semiconductor Theory (Part 1) (8:57) Semiconductor Theory (Part 2) (12:31) Semiconductor Theory (Part 3) (7:16) Semiconductor Junctions (11:30) Troubleshooting Semiconductors (3:13) Diodes and Diode Circuits Diode Characteristics (10:03) Power supplies (24:39) Miscellaneous Diode Applications (17:55) AM Circuit Detector (3:43) Special Diodes (zener) (7:38) Special Diodes (10:57) Transistors and Transistor Circuits Bipolar Transistors (intro) (6:35) Transistor Biasing (14:13) Transistor Biasing (cont) (5:55) Decibels (8:37) Amplifier Basics (7:59) Amplifier Configurations (11:01) Junction Field Effect Trans (8:10) JFET Amplifiers (8:42) MOSFETS (11:21) MOSFET Amplifiers (11:10) Digital Applications (14:46) Linear Transistor Applications (19:32) Troubleshooting Transistor Circuits (17:02) Op Amps and Op Amp Circuits Op Amps Characteristics (part 1) (5:40) Op Amps Characteristics (Part 2) (10:25) Op Amps Characteristics (Part 3) (10:37) Op Amps Characteristics (Part 4) (12:57) Basic Amplifier Configuration (Part 1) (11:16) Basic Amplifier Configuration (Part 2) (8:07) Op Amp Applications (6:47) Op Amp Applications (Integrator) (6:47) Op Amp Applications (filters) (12:21) Op Amp Applications (filters cont.) (8:56) Op Amp Applications (comparator) (10:53) Digital Digital Concepts Terms (15:48) Binary Conversion (11:53) Logic Gates (12:58) Boolean Algebra (15:59) Combinational Logic (7:33) Gate Array Logic (5:12) Boolean expressions (11:32) Truth Tables (5:52) Sequential Logic (12:46) Flip Flops (6:51) Counters (20:45) Counters, Asynchronous (10:25) Digital to Analog Conversion (8:27) Analog to Digital Conversion (12:17) Microprocessors Microprocessors and Computers (7:39) Microprocessor bus Networks (8:12) Microprocessor Internal Structure (8:14) Internal Registers and ALU (4:57) Representative System (Part 1) (5:12)
[linuxkernelnewbies] Free 101 ARM PROJECT IDEAS
http://101armprojectideas.blogspot.com/2009/04/available-projects-and-information.html
Available Projects and Information (Content)
WinARM.
The
gnu-toolchain and several tools and samples for ARM
controller/processors for MS-Windows-Platforms. (last Update of the
package 28. Mar 2008 (Testing), last Update of additional
information/add-ons/bug-fixes 6. Feb. 2008)
WinXSCALE
precompiled GNU-Toolchain for xscale-elf targets (last Update 22. Sept.
2006)
OpenOCD
as flash-programming Software for AT91SAM7, LPC2000 and STR7 (last
Update 31. Aug. 2008)
Using
OpenOCD with ARMv7 / Cortex-M3 / LMI Stellaris (last update 9. Apr.
2008)
A short
introduction into ARM-JTAG debugging using Wiggler(-clones) and the
gnu-Debuggers (last Update 4. June 2005)
A
small demo for the LPC2106 and LPC2129 (ARM7TDMI) controllers - LED and
button interfaceing (GPIO) (last Update 19. March 2007)
A
small demo for the LPC2106 and LPC2129 (ARM7TDMI) controllers - LED and
button interfaceing (GPIO) and Timer-Interrupt(via VIC)
(last Update 19. March 2007)
A
small demo for the LPC2106 (ARM7TDMI) controller - UART-Programming
(last Update 26. Oct 2004)
A
small demo for the LPC2106, LPC2129, LPC2138, LPC2368 and LPC2378
(ARM7TDMI) controllers - interrupt-driven UART (last Update
2. May 2007)
Controller
Area Network (CAN) with Philips LPC2129 (last Update 17.
May 2005)
arm-elf-gcc
and newlib stdio/"printf"-Interface and LPC2129 ADC example
(last Update 13. March 2007)
arm-elf-gcc
Example Application with some Functions in RAM
("fastrun"/"ramfunc") (last Update 17. May 2005)
C++
with LPC ARM7TDMI/newlib/newlib-lpc (inheritance, polymorphism)
(last Update 11. July 2006)
Port
of the Philips LPC213x/214x example-colletion for the gnu-toolchain
(last update 5. Dec. 2006)
GPIO,
UART and interrupt example for the NXP LPC2378 / NXP LPC2368
(last update 29. June 2007)
Interfacing
Philips LPC2000 ARM7TDMI-S with memory-cards (SD/MMC) (last
Update 14. Sept. 2008)
FreeRTOS
example with LPC2138 (last Update 19. May 2006)
AT91SAM7S
GPIO Example (last Update 22. July 2006)
AT91SAM7S
Timer interrupt Example (last Update 22. July 2006)
AT91SAM7S
UART Example (last Update 21. Sept. 2007)
AT91SAM7S
GPIO/interrupt/UART Example with a lot of "gcc specials" (last
Update 3. Dec. 2005)
AT91SAM7S
USB Examples (last Update 10. Mar. 2007)
Interfacing
ATMEL AT91SAM7S ARM7TDMI with memory-cards (SD/MMC) (last
Update 27. Apr. 2007)
GNU-Port
of the Atmel "MIPS" example with "gcc/as specials" (last Update 15.
July 2006)
AT91SAM7
SWI, Remap, GPIO, PIT and stdio Example ("gamma") (last Update 30.
Aug 2007)
C++
with the GNU-Toolchain on an AT91SAM7 (last Update 14. Sept. 2006)
Analog
Devices ADC7000 ARM7TDMI controller Examples (last Update 5. Dec.
2007)
STR71x
GPIO, Interrupt, Timer Example (last Update 25. Apr. 2007)
STMicroelectronics
ARM Controller Examples (last Update 22. Sept. 2006)
GNU
port of the STR7 UART-Bootloader (last Update 24. Sept. 2007)
ARMv7
Cortex M3 examples for LM3S and STM32 (last update 27. July
2008)
Interfacing
Maxim/Dallas DS18x20 Temperature Sensors with an LPC2106
(ARM7TDMI) (last Update 26. Nov 2004)
Interfacing
Graphics-LCDs with the ARM controllers (KS0108, SED1520)
(last Update 17. Oct 2007)
"T"-Clock:
DCF77 radio-clock-receiver with Graphics-LCD display for LPC2106
(ARM7TDMI) (last Update 23. Dec 2005)
Machine-to-Machine
(M2M) communication A data-logger with GPRS-connection
(last update 1. Mar. 2006)
A
patched version of the ULINK Windows-driver (last Update 7. Sept.
2005)
"Last
updated" may be just additional information not always a new version of
a software-package. All presented LPC2106, LPC2129 and LPC2138 projects
should work with minimal modifications in the linker-scripts and
source-code on all Philips LPC2xxx controllers. Most of the code should
also work on other ARM7TDMI controllers after small modifications.
If you think that I could help you with your projects: just send an
e-mail. I'm looking for "freelance"-jobs.
If
you send me an e-mail: Please use your full name (your _real_ full
name). And it's always nice to get some kind of feedback if an answer
to a question did help or did not help. I often spend a lot of time
answering e-mails and would at least like to know if my suggestions did
or did not help solving a problem.
WinARM
WinARM
is a collection of GNU and other tools to develop software for the
ARM-family of controllers/processors on MS-Windows-hosts. Unlike other
collections WinARM does not depend on a cygwin or mingw-environment.
All needed tools are in the distribution-package. WinARM has been
tested with Philips LPC2106, Philips LPC2129, Philips LPC2138, Philips
LPC2148 and Atmel AT91SAM7S64, AT91SAM7S256, AT91RM9200 ARM7TDMI(-S)
controllers (the list is based on own tests and user feedback). The
gnu-toolchain and the supplied tools should work with all
microcontrollers based on ARM(-TDMI/Thumb etc.) architecture. WinARM
has
[linuxkernelnewbies] S Like Suska: An Open Source Atari ST(E) IP-Core written in VHDL
http://www.experiment-s.de/en/ S Like Suska Do you think, the Suska project is cool? Are you interested in software programming or modeling digital circuits? If thats the case we are proud to announce the opening of our Suska Shop. Check it out!. An Open Source Atari ST(E) IP-Core written in VHDL This is a fun project that has been started because of my interests in modelling digital logic. Suska has grown to a nearly full functional Atari ST(E) using VHDL as modelling language. At the very beginning it was just the address decoder of the GLUE custom chip which was replaced by a simple model. That was back in February 2003. Many hundreds of hours later all custom chips found in the Atari ST(E) have been replaced with a single FPGA. Even the 68000 CPU has been integrated. A big challenge after each modelling step was to test the results directly with the Atari main board keeping the same functionality as if they were original chips. For that we used Sphinx modules from Inventronik with a piggy-back and an adapter to replace each custom chip. We have pictures in our gallery if you are interested. More and more functions of the ST machines have been integrated into a single FPGA. Floppy Disk Controller, Blitter and last but not least the 68000 CPU found its way into the Suska FPGA. Thanks to a few donations we created the Suska main board. The circuit board includes an Altera (Cyclone II in BGA housing), Flash-Prom, RAM, as well as two Atmel MCs for the boot loader and for programming the FPGAs boot device. The board integrates all the typical Atari ST(E) interfaces. Using other FPGAs from different manufacturers like Actel, Lattice or Xilinx would have been an option too. The completion of the board lead us to another aspect: The operating system. For debugging purposes and because of copyrights we decided to go with EmuTOS an open source TOS. Thanks to Jens, debugging became pretty pain free. Suska is a long term project. The current state can be found in the blog or the progress list. Have fun with Suska Wolfgang
[linuxkernelnewbies] FreeRTOS-A Free RTOS for ARM7, ARM9, Cortex-M3, MSP430, MicroBlaze, AVR, x86, PIC32, PIC24, dsPIC, H8S, HCS12 and 8051
http://www.freertos.org/index.html?http://www.freertos.org/a00106.html Upgrading to V5.x.x Configuration API Usage Task Creation Task Control Kernel Control Task Utilities FreeRTOS-MPU Specific Queue Management Semaphores Co-routine specific
[linuxkernelnewbies] Writing ARM interrupt handler
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3709.html
[linuxkernelnewbies] VHDL Online resources
http://www.vhdl-online.de/tutorial/englisch/inhalt.htm Content 1. VHDL - Overview and Application Field 1.1 Application of HDLs (1) 1.1.1 Application of HDLs (2) 1.1.2 Range of Use 1.2 VHDL - Overview 1.2.1 VHDL - History 1.2.2 VHDL - Application Field 1.2.3 ASIC Development 1.3 Concepts of VHDL 1.3.1 Abstraction 1.3.2 Abstraction Levels in IC Design 1.3.3 Abstraction levels and VHDL 1.3.4 Description of Abstraction Levels 1.3.5 Behavioural Description in VHDL 1.3.6 RT Level in VHDL 1.3.7 Gate Level in VHDL 1.3.8 Information Content of Abstraction Levels 1.4 Modularity and Hierarchy 1.5 Summary 2. VHDL Language and Syntax 2.1 General 2.1.1 Identifier 2.1.2 Naming Convention 2.2 VHDL Structural Elements 2.2.1 Declaration of VHDL Objects 2.2.2 Entity 2.2.3 Architecture 2.2.4 Architecture Structure 2.2.5 Entity Port Modes 2.2.6 Hierarchical Model Layout 2.2.7 Component Declaration 2.2.8 Component Instantiation 2.2.9 Component Instantiation: Named Signal Asscociation 2.2.10 Configuration 2.2.11 Configuration: Task and Application 2.2.12 Configuration: Example (1) 2.2.13 Configuration: Example (2) 2.2.14 Process 2.2.15 VHDL Communication Model 2.2.16 Signals 2.2.17 Package 2.2.18 Library 2.2.19 Design Structure: Example 2.2.20 Sequence of Compilation 2.2.21 Outlook: Testbench 2.2.22 Simple Testbench Example 2.2.23 Summary 2.2.24 Questions 2.2.25 Questions 2.2.26 Questions 2.3 Data Types 2.3.1 Standard Data Types 2.3.2 Datatype 'time' 2.3.3 Definition of Arrays 2.3.4 'integer' and 'bit' Types 2.3.5 Assignments with Array Types 2.3.6 Types of Assignment for 'bit' Data Types 2.3.7 Concatenation 2.3.8 Aggregates 2.3.9 Slices of Arrays 2.3.10 Questions 2.3.11 Questions 2.4 Extended Data Types 2.4.1 Type Classification 2.4.2 Enumeration Types 2.4.3 Enumeration Types - Example 2.4.4 BIT Type Issues 2.4.5 Multi-valued Types 2.4.6 IEEE Standard Logic Type 2.4.7 Resolved and Unresolved Types 2.4.8 Std_Logic_1164 Package 2.4.9 Resolution Function 2.4.10 STD_LOGIC vs STD_ULOGIC 2.4.11 The NUMERIC_STD Package 2.4.12 Arrays 2.4.13 Multidimensional Arrays 2.4.14 Aggregates and Multidimensional Arrays 2.4.15 Records 2.4.16 Type Conversion 2.4.17 Subtypes 2.4.18 Aliases 2.5 Operators 2.5.1 Logical Operators 2.5.2 Logical Operations with Arrays 2.5.3 Shift Operators: Examples 2.5.4 Relational Operators 2.5.5 Comparison Operations with Arrays 2.5.6 Arithmetic Operators 2.5.7 Questions 2.5.8 Questions 2.6 Sequential Statements 2.6.1 IF Statement 2.6.2 IF Statement: Example 2.6.3 CASE Statement 2.6.4 CASE Statement: Example 2.6.5 Defining Ranges 2.6.6 FOR Loops 2.6.7 Loop Syntax 2.6.8 Loop Examples 2.6.9 WAIT Statement 2.6.10 WAIT Statement: Examples 2.6.11 WAIT Statements and Behavioural Modeling 2.6.12 Variables 2.6.13 Variables vs. Signals 2.6.14 Use of Variables 2.6.15 Variables: Example 2.6.16 Global Variables (VHDL'93) 2.7 Concurrent Statements 2.7.1 Conditional Signal Assignment 2.7.2 Conditional Signal Assignment: Example 2.7.3 Selected Signal Assignment 2.7.4 Selected Signal Assignment: Example 2.7.5 Concurrent Statements: Summary 2.8 RTL-Style 2.8.1 Combinational Process: Sensitivity List 2.8.2 WAIT Statement - Sensitivity List 2.8.3 Combinational Process: Incomplete Assignments 2.8.4 Combinational Process: Rules 2.8.5 Clocked Process: Clock Edge Detection 2.8.6 Detection of a Rising Edge by Use of Functions 2.8.7 Register Inference 2.8.8 Asynchronous Set/Reset 2.8.9 Clocked Process: Rules 2.8.10 Questions 2.8.11 Questions 2.8.12 Questions 2.9 Subprograms 2.9.1 Parameters and Modes 2.9.2 Functions 2.9.3 Procedures 2.10 Subprogram Declaration and Overloading 2.10.1 Overloading Example 2.10.2 Overloading - Illegal Redeclarations 2.10.3 Overloading - Ambiguity 2.10.4 Operator Overloading 2.10.5 Operator Overloading - Example 2.10.6 Questions 3. Simulation 3.1 Sequence of Compilation Example Changes in ... recompile files ...
[linuxkernelnewbies] ARM: Writing interrupt handlers
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3709.html
Writing interrupt handlers
Applies to: Software
Development Toolkit (SDT)
Description
armcc provides the '__irq'
declaration keyword to allow writing interrupt handlers in C. However
this was only designed for 'simple' (non re-entrant) interrupt
handlers. This is because it does not store all of the state
information required for re-entrant interrupts.
The level of complexity of your 'top-level' interrupt handler
depends on whether it needs to call subroutines (with theBLinstruction)
and whether it needs to be re-entrant. In a typical system, there may
be several interrupt sources, with different priorities, connected viaIRQ. A re-entrant interrupt handler would
allow e.g. a higher priorityIRQto
interrupt the processing of a lower-priorityIRQ.
A re-entrant interrupt handler (at least its 'top-level') *must* be
written in assembler.
Solution
To allow subroutines to be called from the top-level handler, theLR_IRQmust be saved (e.g. stacked) before
theBLcall and restored afterwards,
otherwise theBLwill
corrupt the 'return address' of the interrupt handler by overwriting it
with the return address of the subroutine. Additionally, registersr0-r3andr12are not preserved by the called function
(as specified by the APCS), so must be preserved by the caller.
The__irqfunction handles all these
details, for example,
__irq void IRQHandler (void)
{
volatile unsigned int *base = (unsigned int *) 0x8000;
if (*base == 1) // which interrupt was it?
{
C_int_handler(); // process the interrupt
}
*(base+1) = *base;// clear the interrupt
}
compiled witharmccgives:
IRQHandler
0x00: STMFDsp!,{r0-r4,r12,lr}
0x04: MOV r4,#0x8000
0x08: LDR r0,[r4,#0]
0x0c: CMP r0,#1
0x10: BLEQ C_int_handler
0x14: LDR r0,[r4,#0]
0x18: STR r0,[r4,#4]
0x1c: LDMFDsp!,{r0-r4,r12,lr}
0x20: SUBS pc,lr,#4
It is important to clear the source of the interrupt somewhere
within the interrupt handler, otherwise the current pending interrupt
will be taken again immediately after returning from the interrupt
handler, creating an endless loop. This is typically done by accessing
an 'interrupt acknowledged' register in the interrupt controller
hardware.
TheIRQHandlerC function above must
be compiled with armcc, however, C_int_handler()may
be a C function compiled for ARM or Thumb. The linker can add any
necessary ARM/Thumb interworking veneers to perform the change of state.
Re-entrant interrupt handlers, however, are rather more complex.
If an interrupt handler re-enables interrupt, and another interrupt
occurs during execution of aBLinstruction,
then the return address of the subroutine (stored inLR_IRQ) WILL BE CORRUPTED when the 2ndIRQexception is taken.
Before theBLto
the subroutine/C function, you should switch to another mode, typically
System mode (supported in architecture 4 onwards, e.g. in ARM7TDMI) by
changing theCPSR, so that the User
mode registers are used with privileged protection, then immediately
push the User modeLRon the User mode
stack. It is then safe to call the subroutine withBL. On return you can restore the User modeLR, switch back toIRQmode
and leave as normal. For more information on System mode see SDT 2.11
User Guide, section 11.13, orSDT 2.50 User Guide, section 9.12.
Again,
it is important to clear the source of the interrupt before re-enabling
interrupts, otherwise the current pending interrupt will be taken again
immediately after re-enabling interrupts, creating an endless loop.
On entry:
save (adjusted)LRandSPSR
clear the source of the interrupt
switch to System mode and re-enable core interrupts
save more registers if needed
call C interrupt dispatch function
switch back toIRQmode and
disable interrupts
restoreSPSR
return
This is best implemented in ARM assembler. Try this:
AREA INTERRUPT, CODE, READONLY
IMPORT C_irq_handler
IRQ
SUBlr, lr, #4
STMFD sp!, {lr}; save adjusted LR_IRQ
MRSr14, SPSR
STMFD sp!, {r12, r14} ; save workreg SPSR_IRQ
; add instructions to clear the interrupt here
MSRCPSR_c, #0x1F; go to System mode, IRQ FIQ enabled
STMFD sp!, {r0-r3, lr} ; save LR_USR and non-callee saved registers
BL C_irq_handler; call C irq handler
LDMFD sp!, {r0-r3, lr} ; restore
MSRCPSR_c, #0x92; go back to IRQ mode, disable IRQ (FIQ still enabled)
LDMFD sp!, {r12, r14} ; restore workreg SPSR_IRQ
MSRSPSR_cf, r14
LDMFD sp!, {PC}^ ; and return
END
Again, C_irq_handler()may be
a C function compiled for ARM or Thumb. The linker can add any
necessary ARM/Thumb interworking veneers to perform the change of state.
As
an additional note, please be aware that if an interrupt occurs at the
same time when the interrupt is disabled by the program, the ARM7
[linuxkernelnewbies] fo...@moderndevice.com • View topic - hex loaded on Rev D m168 BBB
http://forum.moderndevice.com/phpBB3/viewtopic.php?f=15t=177sid=329434a9e8a03ffbf7ff5e42534d9e90 hex loaded on Rev D m168 BBB Questions and Discussion concerning the Bare Bones Board Post a reply 4 posts • Page 1 of 1 hex loaded on Rev D m168 BBB by pstretz on Sat Jul 11, 2009 11:23 am I am trying to put a new m168 in my Rev D BBB so that I can use the one already programmed in a project. I have 2 problems: 1) I can't seem to program a chip from the ISP header on the board with a usbtinyISP. If I put the new chip in my target board I can load a hex without a problem. 2) When I put the chip I programmed on the target board into the BBB I can't load sketches. I have tried loading the ATmegaBOOT_168_diecimila.hex from the latest arduino-016 download and also the ATmegaBOOT_168_ng.hex downloaded from your site. Any help would be appreciated. -Petyr pstretz Posts: 2 Joined: Sat Jul 11, 2009 10:43 am Top Re: hex loaded on Rev D m168 BBB by paul on Sat Jul 11, 2009 9:24 pm Petyr, Unfortunately I don't have a tinyISP so can't test it on the BBB. I use the board for burning bootloaders though, with a zif socket installed instead of the regular socket, so I know there's no issue with it. I use the AVRISP mkII, and AVR studio on a PC. This setup is fast and easy, but the AVR mkII is around $40. Here are some things to check on. Check the solder joints around the ISP header and also the chip socket, make sure the chip is firmly seated in the socket. Check the resistor on the resest line - the resistors are 10K,1K,10K. Check continuity with a meter, between ISP pins and Atmega pins. That's what I can think of right now. As to question 2, if you are using tinyISP to upload sketches, then you've written over the bootloader, so no serial upload is going to work. Maybe this is not what you are trying to do? Burn a new bootloader onto the chip, then serial uploading will work again. Also make sure you have the correct chip setting in the Arduino IDE. Write back if none of this seems to help, Paul paul Site Admin Posts: 335 Joined: Mon May 12, 2008 4:19 pm Top Re: hex loaded on Rev D m168 BBB by pstretz on Sun Jul 12, 2009 9:51 am Hey Paul, Thanks for the reply. I will double check my solderwork and pinout the connector with a DVM. I'll check to see if there are any differences between the BBB lines to the m168 and my target board. It's entirely possible there is some subtle difference here that is hosing me up. The target board I'm using works for sure, because I used it to program this, http://www.instructables.com/id/Microco ... in-C-code/. I am trying to upload a boot loader to the chip through my ISP and then using a TTL for uploading sketches. My issue is when I use the chip that was pre-programmed in my BBB kit sketches upload through the TTL and execute fine. No problems at all. When I take a chip that I load a bootloader on through ISP, and put the chip in the BBB I can't upload sketches through the TTL. I get an "stk500_recv(): programmer is not responding" error. When I put the original chip in everything is happy again. For reference, I have 1 BBB and 2 m168 chips. What Hex should I be loading with the ISP? Should I resort to compiling my own code from source? Are there any fuses I have to set? Is there anything you have to do with a new chip out of the box to set it up for Arduino? My goal is to take the chip from this project, http://www.instructables.com/id/Control ... ased-MIDI/, and put it in an Altoids tin. There is just not enough room for the whole board and batteries in the tin so I was going to just use the m168 chip and a regulator hot glued the the lid then put the batteries in the base. I need to figure out how to set up a fresh chip with a bootloader and my sketch so that I can get it working. pstretz Posts: 2 Joined: Sat Jul 11, 2009 10:43 am Top Re: hex loaded on Rev D m168 BBB by paul on Sun Jul 12, 2009 9:59 pm I am trying to upload a boot loader to the chip through my ISP and then using a TTL for uploading sketches. My issue is when I use the chip that was pre-programmed in my BBB kit sketches upload through the TTL and execute fine. No problems at all. When I take a chip that I load a bootloader on through ISP, and put the chip in the BBB I can't upload sketches through the TTL. I get an "stk500_recv(): programmer is not responding" error. When I put the original chip in everything is happy again. For reference, I have 1 BBB and 2 m168 chips. It sounds like fuses could be the issue. If you're doing this in the Arduino IDE though - they should be set for you, and you just need to make sure you get the right chip/board selected in the Tools - Board menu (that conforms most closely to your homebrew setup). If you're doing this through another piece of software then you need to confirm you have fuses set correctly. See the hacking page on the Arduino site. I'd try and burn the
[linuxkernelnewbies] Security-related patches
https://lwn.net/Articles/375071/bigpage 2.6.32.9 Release notes By Jonathan Corbet February 21, 2010 Stable kernel update announcements posted on LWN have a certain tendency to be followed by complaints about the amount of information which is made available. It seems that there is a desire for a description of the changes which is more accessible than the patches themselves, and for attention to be drawn to the security-relevant fixes. As an exercise in determining what kind of effort is being asked of the kernel maintainers, your editor decided to make a pass through the proposed 2.6.32.9 update and attempt to describe the impact of each of the changes - all 93 of them. The results can be found below. Disclaimers: there is no way to review 93 patches in a finite time and fully understand each of them. So there are probably certainly errors in what follows. The simple truth of the matter is that it is very hard to say which fixes have security implications; a determined attacker can find a way to exploit some very obscure bugs. Your editor would also like to discourage anybody from thinking that this will become a regular LWN feature. The amount of work required is considerable; it's not something we're able to commit to doing for every release. That said, here's a look at what's in this update. Security-related fixes #2: futex_lock_pi() key refcnt fix. It's possible to create dangling futex references, leading to a user-triggerable BUG_ON() oops. It's thus a denial of service vulnerability; it has been present since 2.6.28. #3: futex: Handle user space corruption gracefully. Malicious programs can cause a null pointer dereference or hijack somebody else's futex. #4: futex: Handle futex value corruption gracefully. User-space processes can cause warning floods, spamming the system logs. #5: Fix race in tty_fasync() properly. Possible (if unlikely) deadlock, and thus denial of service. #22: regulator: Fix display of null constraints for regulators. Fixes an information disclosure issue in the regulator code. #23: ALSA: hda-intel: Avoid divide by zero crash. Papers over a user-triggerable divide-by-zero crash; the real cause of the problem remains unknown. #26: cciss: Make cciss_seq_show handle holes in the h-drv[] array. Null pointer dereference in the cciss driver; probably not triggerable without privilege. #35: NFS: Fix an Oops when truncating a file. User-triggerable oops when truncating a file on an NFS filesystem. #36: NFS: Fix a umount race. Dangling pointer dereference on NFS filesystem unmount. Maybe triggerable in situations where users can cause mounts and unmounts to happen. #40: V4L/DVB: dvb-core: fix initialization of feeds list in demux filter. User-triggerable dereference of a corrupted pointer, with an oops being the best-case scenario. #47: netfilter: nf_conntrack: per netns nf_conntrack_cachep. Fixes a potential leak of information between network namespaces. Probably very hard to exploit in any useful way. #50: netfilter: nf_conntrack: fix hash resizing with namespaces. Changing the conntrack hash size in one namespace causes that size to be incorrect for all others, leading to unsightly kernel oops issues. #54: [S390] dasd: remove strings from s390dbf. Stale pointer dereference bugs in the S390 DASD driver. #57: dell-wmi, hp-wmi, msi-wmi: check wmi_get_event_data() return value. Fix a potential null pointer dereference on memory allocation failure. #75: ALSA: usb-audio - Avoid Oops after disconnect. Fixes a user-triggerable oops in the USB audio driver. #79: USB: usbfs: only copy the actual data received. Usbfs was copying more data than actually existed in some situations, leading to a potential information disclosure problem. #82: ACPI: Add NULL pointer check in acpi_bus_start. A null pointer dereference in the ACPI code. #92: dm log: userspace fix overhead_size calculations. A couple of structure-size miscalculations make both buffer overruns and information disclosure possible, though it's not at all clear that either is readily exploitable. Other bug fixes #1: Fix potential crash with sys_move_pages. Fix an unreliable test which could cause a crash in the page migration code. [Update: as has been pointed out in the comments, this one is exploitable and should have been in the security list above.] #6: hwmon: (w83781d) Request I/O ports individually for probing. More robust access to hardware monitoring ports. #7: hwmon: (lm78) Request I/O ports individually for probing. More robust access to hardware monitoring ports. #8: hwmon: (adt7462) Wrong ADT7462_VOLT_COUNT. Fixes a bug which could cause one voltage measurement to be passed over. #9: ALSA: ctxfi - fix PTP address initialization. Fixes an alignment bug in the ctxfi sound
[linuxkernelnewbies] specs - Linux Wireless
http://linuxwireless.org/en/developers/Documentation/specs#Atherosspecifications About specifications This page contains a list of specifications used to write Linux drivers for several wireless cards, and which, alternatively, can be used to write drivers for any other platforms. Broadcom hardware specifications The b43 driver was written based on the reverse engineered specification. This device currently is known to use two different firmware types, each of which changes the behavior of the driver. Because of this we have two different drivers for each handle each firmware. Fortunately we have specifications written for both firmwares. Specifications for v3 firmware Specifications for V4 firmware Atheros specifications Atheros Legacy-HAL Atheros has released their legacy under the ISC license Atheros legacy HAL for their 802.11abg chipsets Sam Leffler's HAL Atheros has worked with Sam Leffler to allow him to release his HAL. You can get it through svn: svn co http://svn.freebsd.org/base/projects/ath_hal Further documentation Atheros engage further with active upstream developers. Airgo hardware This is new and ongoing project. Airgo specifications Ralink documentation Ralink has provided EEPROM channel documentation on two of their chipsets. RT61 EEPROM Channels RT2460 EEPROM Channels RT2560 EEPROM Channels RT2571 EEPROM Channels RT2860 EEPROM Channels STMicroelectronics hardware This is a p54 variant used in some mobile devices. lmac_longbow.h STSW45x0C_LMAC_API_ED1P4.pdf
[linuxkernelnewbies] Frozen Cache
http://frozencache.blogspot.com/
Frozen Cache
A blog about the development of a
general-purpose solution for mitigating cold-boot attacks on
Full-Disk-Encryption solutions.
The concept
Cold boot attacks are a major risk for the protection that
Full-Disk-Encryption solutions provide. Any powered-on computer is
vulnerable to this attack and until now there has been no
general-purpose solution to this problem.
This
entry details my solution for mitigating cold boot attacks. Future
posts will delve into additional details and describe what other ideas
(and problems) were considered on the path to finding a general-purpose
solution.
Why is this blog called "Frozen Cache"? Because we're
proposing the use of the CPU cache for thwarting cold boot attacks (at
least on most X86 systems). In contrast to most blogs, the entries of
this blog will appear in normal chronological order on the website (for
a more paper-like reading). Feeds however, will be sorted as expected
(reverse chronological order).
The concept is easy: by switching
the cache into a special mode one can force that data remains in the
cache and is not written to the backing RAM locations. Thus, the
encryption key can't be extracted from RAM. This technique is actually
not new: LinuxBIOS/CoreBoot calls this Cache-as-RAM.
They use it to allow "RAM access", even before the memory controller is
initialized.
The
following (simplified and technically not 100% correct/complete) steps
load and maintain a 256 bit encryption key in the CPU cache. The demo
assembly code assumes the encryption key is stored at linear address X
in RAM on a page boundary for simplicity:
Load the encryption key from RAM into some CPU registers (like
the SSE registers)
movq [X], %xmm0
movq [X+8], %xmm1
movq [X+16], %xmm2
movq [X+24], %xmm3
Overwrite the encryption key in RAM with a zero-value
movq 0, [X]
movq 0, [X+8]
movq 0, [X+16]
movq 0, [X+24]
Flush the cache (thus truly overwriting the encryption key in RAM)
wbinvd
Add the desired RAM region to the CPU's MTRR (the 4K segment
containing the key)
movl (X | MEMORY_TYPE_WRITEBACK), %eax
xorl %edx, %edx
movl 0x200, %ecx
wrmsr
movl ( ~(1) | MTRR_VALID ), %eax
movl 0x1, %edx
movl 0x201, %ecx
wrmsr
Disable/freeze the CPU's cache (CR0.CD=1)
movl %cr0, %eax
orl 0x4000, %eax
movl %eax, %cr0
Write the encryption key from the CPU registers to RAM (data
remains in the cache, doesn't get written to memory)
movq %xmm0, [X]
movq %xmm1, [X+8]
movq %xmm2, [X+16]
movq %xmm3, [X+24]
"Disabling/freezing"
the CPU's cache severely degrades the performance. However, this seems
acceptable if one considers that this special mode only needs to be set
whenever the screen is locked (all efforts are pretty much worthless if
an unlocked laptop is stolen). A very first proof-of-concept test on
Linux shows that there's quite a bit of performance optimization
necessary to make even just the act of unlocking the GUI an acceptable
experience (from a performance/usability perspective).
Please
note that this post only described the very basic concept, there are
many aspects that haven't been covered. Upcoming posts will address
things like multi-CPU/Core issues, performance
considerations/optimizations and lots of other stuff.
Posted by
Jrgen Pabel
on
Tuesday, January 13, 2009
0
comments
Performance
aspects
As previously mentioned,
performance is a major concern when the cache is switched into no-fill
mode ("frozen"). The broad range of CPU architectures (multi-CPU,
multi-core, multi-threads) and respective cache configurations makes
the matter even more complex.
First
off: only a single CPU's cache needs to be "frozen" in order to
effectively protect the encryption key; other CPUs are allowed to
operate in normal cache mode. This is true for as long as each
(logical/virtual) CPU uses its own cache exclusively: CPUs that employ
threading technology (like Intel's HyperThreading) appear as two (or
potentially more) logical CPUs, but these two CPUs share the same cache
and because of this must both change into no-fill cache mode. The
situation may be different for multi-core CPUs, if the cores all have
their own (L1 and L2) caches.
The encryption key resides only in
a single CPU's cache. Only this CPU must therefore execute the
encryption and decryption routines. The most prevalent architecture
among Full-Disk-Encryption solutions is to employ a kernel module,
which spawns a designated kernel thread for the encryption and
decryption logic. Kernel threads are schedulable entities and are
therefore bindable onto the CPU, which holds the encryption key in its
cache.
Back to more "traditional" performance aspects. What can
be done to minimize the impact of freezing the CPU cache? Loading the
most frequently used memory areas into the cache (before freezing it)
is a great start. Among the highest
[linuxkernelnewbies] wifi-test-nl80211 - Linux Wireless
http://linuxwireless.org/en/developers/GSoC/2010/wifi-test-nl80211 Extending wifi-test with nl80211 support wifi-test is an open project aimed at assisting automation of testing using scripts for Linux 802.11 drivers. This project currently uses the old wireless-extensions which are now deprecated. We have moved to a much better 802.11 configuration and userspace kernel communication API with cfg80211 and nl80211. The goal of this project is to add an initial basic C framework to help test specific tasks on 802.11 drivers. Last year we had a similar project but it was really ambitious and aimed at creating both the test framework and to enable automation of testing using an 802.11 testbed. That project failed to gain traction and not a single line of code was published even though the project was accepted and we had three extremely qualified students apply for the project. This year we lighten the load with small focus and aim at only building a very simple nl80211 test framework. The effort is expected to enable the community to further extend this and use it for more advanced tests. Contents Extending wifi-test with nl80211 support 2010 mentors and students Student requirements What you should start with Resources 2010 mentors and students 2010 mentors Luis R. Rodriguez 2010 interested students Sign up here Student requirements Good knowledge of C Familiarity with 802.11 basics Comfortable with git or willing to learn it Feels perfectly comfortable in engaging with the community on a public mailing list Experience working with the community on any open projects is a plus What you should start with After reading the cfg80211 and nl80211, and iw documentation, check out iw code from git: http://git.sipsolutions.net/iw.git Then glance over the event.c file. That is the key to our entry into enabling testing. The kernel sends out events upon specific errors or task completions, or asynchronous events of different types. Read over all known events and read then the documentation about them on the nl80211.h file. This file is the header upstream on the Linux kernel. It gets synchronized to userspace. The iw package ships its own nl80211.h file to allow further commands to be compilable and available on older kernels. When a user upgrades to a newer kernel the idea is that userspace will know about the new commands already. A simple test case would be to use iw to trigger an action, and prior to that write some simple C code to register for nl80211 events and see if that command you issued through iw completed. An example would be if association completed to an AP. This itself would be a good first step. We will build on this and build more complicated tests cases. Your ideas are welcomed for both writing new events upstream in the kernel, and for also coming up with new tests cases. Resources You can read all the documentation on the links below. cfg80211 nl80211 iw wifi-test Quick tutorial on git
[linuxkernelnewbies] Re: Identify Application
yes.your answer is strace for userspace.but if inside the kernel, and u want to identify the name of the process...it is comm: http://lxr.free-electrons.com/source/kernel/cred.c 21 #if 0 22 #define kdebug(FMT, ...) \ 23 printk([%-5.5s%5u] FMT\n, current-comm, current- pid ,##__VA_ARGS__) 24 #else On Feb 25, 10:42 am, perumal316 perumal...@gmail.com wrote: Hi, I am writing an kernel module to log a message each time a particular system call is being done. Is there any way for me to identify which application is using the system call? I want to log which application is performing which system call.I not sure if there is some kind of ID to identify which is the current application calling the system call. Thanks In Advance, Perumal
[linuxkernelnewbies] LAUTERBACH DEVELOPMENT TOOLS - TRACE32 Microprocessor Development Tools, Emulators, Debuggers, Simulators
http://www.lauterbach.com/frames.html?doclist.html Basic Concept 223k Apr-11-2007 main.pdf Adapters Document Comment Size Date Download File Adaption for ST10F280 66k Jun-13-2007 adf280.pdf Adapter for SOC Trace 123k Jun-13-2007 adsoccon.pdf Target Adaption for XCORE 73k Jun-13-2007 adxcore.pdf Connector for RISC-Trace PowerQuiccII 74k Jun-13-2007 adestcon.pdf Target Adaption for MPC8240 78k Jun-13-2007 admpc8240.pdf Target Adaption for MPC8260 73k Jun-13-2007 admpc8260.pdf BDM/JTAG Debugger Document Comment Size Date Download File BDM Debugger for MPC5xx/8xx 259k Jan-21-2010 bdmppc.pdf JTAG Debugger for PPC400 232k Jan-21-2010 bdmppc400.pdf JTAG Debugger for PPC440 254k Jan-21-2010 bdmppc440.pdf BDM/JTAG Debuggers 695k Jun-13-2007 bdm.pdf PCP Debugger 152k Jan-21-2010 bdmpcp.pdf FIRE Emulator Document Comment Size Date Download File FIRE Emulator for Motorola 68HC12 / MCS12 / S12X 1038k Jan-21-2010 fire12.pdf FIRE Emulator for C166 Family 703k Jan-21-2010 fire166.pdf FIRE Emulator for ARM7 376k Jan-21-2010 firearm.pdf FIRE Emulator for C166 Cell-Based-Core 478k Jan-21-2010 firecbc.pdf FIRE Emulation Controller 454k Jan-21-2010 fireemu.pdf FIRE Emulator for H8S and H8/300H 880k Jan-21-2010 fireh8s.pdf FIRE Portanalyzer 216k Jan-21-2010 fireport.pdf FIRE Emulator MPC8XX 598k Jan-21-2010 fireppc.pdf FIRE Emulation Memory 223k Jan-21-2010 fireram.pdf FIRE Emulator for SH2 949k Jan-21-2010 firesh2.pdf FIRE Emulator for ST10 825k Jan-21-2010 firest10.pdf FIRE System Controller 188k Jan-21-2010 firesys.pdf FIRE Emulator for NEC V850 525k Jan-21-2010 firev850.pdf FIRE Emulator for C166S V2 Family 585k Jan-21-2010 firexc166.pdf FIRE Fully Integrated RISC Emulator 306k Jan-21-2010 fire.pdf In-Circuit Debugger Document Comment Size Date Download File EPROM/FLASH Simulator 368k Jan-21-2010 esi.pdf PODBUS Ethernet Controller 189k Jan-21-2010 eth.pdf PowerIntegrator - Logic and Bus Analyzer 398k Jan-21-2010 pi.pdf PowerProbe - Logic and Protocol Analyzer 463k Jan-21-2010 pp.pdf PowerTrace 1105k Jan-21-2010 powertrace.pdf Stimuli Generator 203k Jan-21-2010 stg.pdf
[linuxkernelnewbies] Selection Guide of Low Cost Tools for Cortex-M3 | Your Electronics Open Source
http://dev.emcelettronica.com/selection-guide-low-cost-tools-cortex-m3 As I mentioned in another article, ARM Cortex-M3 is not compatible with ARM7TDMI in interrupt, ISA, bus structure and JTAG protocol (SWD). You have to upgrade ARM7TDMI tools to support Cortex-M3 microcontrollers. After a small research, I summarize following tool related information for your reference. Although, there are some high-end professional development tools, I only recommend those open source or low cost tools to reduce the R+D investment. Some tool vendors have offered stable tools for a while. These suppliers are Keil/ARM, IAR/Segger, Code Red Technologies and CodeSourcery (GCC). Each tool vendors are trying to offer a complete tool chain for a new microcontroller, ranges from compiler, starter kit, and debugger to JTAG interface. That means once you pick one tool and get used to it, you have to invest more money on it in the following project. I am not trying to promote on open source in tools, since it is totally a commercial ecosystem. The issue is not how much you pay for it, but how much you can get support from the suppliers. Sometimes we spend too much, and we can not get enough support at all. It is up to you to make decision between proprietary tools and open source tools. In general, proprietary tools are usually verified on targeted platforms. They are usually relatively expensive with promised technical support. Silicon suppliers usually offer low-cost starter board with feature limited evaluation tools. That means you have to spend more in case you are going to develop a serious project with richer feature set. On the other hand, you can open source tools or build it by yourself. But you should explore and solve problem by yourself. Recently some open source tool vendors also support professional kit, so you can buy their so-called Freenium service. Compilers The compiler is the first issue for a new microcontroller. You can pick the proprietary compilers from Keil, IAR, Raisonance, or GCC from CodeSourcery and Code Red Technologies. IAR (EWARM-32K 30day) Keil (MDK 16K) Raisonance (RIDE) CodeSourcey (30 day, GCC) Code Red Technologies (90 day, GCC) Among these vendors, Keil, as an ARM company, offers MDK for Cortex-M3 in standard and basic (256KB) variants, and an evaluation version for 16KB limitation without license key. According to some reports, MDK is strong in code optimization and speed optimization, but it is quite expensive. I believe in Keil, because its 80C51 is indeed the best compiler I have used. And Keil definitely focus on limited platforms, so it must put a lot of effort on it. However, Keil is a complete proprietary kit. And its 16KB limited version can not be used in a ordinary project. IAR, another active supplier, offers 32KB limitation and 30 day full functional evaluation compilers, which can be used in a medium size project. Raisonance RKIT-ARM has not limitation on its compiler and RLINK-Pro debugger, but it has 32KB limitation on debug facilities. As a result, you either compile your code and download it, or develop your project within 32KB. CodeSourcery offers 30 day full functional GCC compiler and a free command line version. Alternatively, Code Red Technologies offers 90 day full functional GCC compiler. Boards Most of the semiconductor and its partners offer all kinds of boards in different names, starter kit, evaluation kit, demo kit, reference kit, development kit, professional kits. That makes things worse, because each kit is a bundle of a whole evaluation component. Luminary micro and ST releases different kits with many combinations. These kits are really a good resource to evaluation and start a simple project. Some boards have already mounted the JTAG interface on board, so you can save your effort to find one. On the other hand, you can not use the on board debugger for another new board as well. STM3210B/E-EVAL Keil MCBSTM32/E IAR STM32-SK Manley-STM32F Raisonance-STM32 Primer JTAG Interfaces and Debuggers Since JTAG has been used in firmware development and device programming, it reduces the development cost. JTAG is only an interface between target microcontroller and debugger software running in PC. Here I hesitate to use a legacy word, emulator. An emulator is working to simulate a microcontroller in the target board, which is why it is called as ICE, In-Circuit-Emulator. JTAG is only not working in that way. Each microcontroller works as itself, only listens to the command from debugger via JTAG interface. An ordinary JTAG interface is only a USB microcontroller with JTAG protocol. That is also an important reason why the developers think the JTAG interface is over-charged at all. There are so many hacked versions on sell. However, hacked version usually stands for no support at all and sometimes it is also a beginning of a fraud. Of course, some JTAG probes are equipped with advanced features, such as trace buffer and logical
[linuxkernelnewbies] A Scheme Interpreter for ARM Microcontrollers
http://armpit.sourceforge.net/ A Scheme Interpreter for ARM Microcontrollers ARMPIT SCHEME is an interpreter for the Scheme language (lexically-scoped dialect of Lisp) that runs on RISC microcontrollers with ARM core. It is based on the description in the Revised^5 Report on the Algorithmic Language Scheme (r5rs), with some extensions (for I/O) and some omissions (to fit within MCU memory). It is further designed to support multitasking and multiprocessing. Armpit Scheme is expected to be well suited to educational settings, including student projects in courses on control and instrumentation, or capstone design courses where microcontrollers are needed. It is meant to enrich the spectrum of interpreted languages available for MCUs (eg. BASIC and FORTH) and can be an alternative to MCU-based bytecode interpreters (eg. for Scheme or Java) and to compiled languages (eg. C). The name "Armpit" was selected for this project because it includes "ARM" (as in ARM core MCU) and "pit" (as in kernel, noyau, the core of an Operating System (OS)). Armpit Scheme, once loaded, governs the operation of the MCU, and is "Scheme to the metal" in the sense of running without any other OS. It may be thought of as turning the MCU into a rudimentary Scheme machine. The screenshot below shows the system running on a NewMicros Tiny2106 board. Minicom is used to communicate with the board which reads, evaluates and prints the result of the entered expressions. The number in front of the "armpit" prompt indicates the number of bytes of heap space that remain available. Figure 1: Sample Interaction with Armpit Scheme The latest development snapshot of Armpit Scheme is 00.0215 and the current stable version is 00.0160. Both are distributed under the MIT License and are beta releases with both known bugs and unknown bugs. The source code, and pre-assembled (ready-to-upload) Intel Hex and binary image files, can be downloaded from the armpit project summary page or the download site at SourceForge. Alternatively, you can view and download the source code from your web browser. The system is documented in several web pages: Documentation for Armpit Scheme Snapshot 00.0215: ChangeLog Known bugs and "features" Common Program Examples (including I2C multiprocessing) Console Examples (PS/2 keyboard and on-board or 'Nokia'-like LCD, with ARMSchembly source) Compilation and ARMSchembly Examples Documentation for Armpit Scheme Snapshot 00.0186: ChangeLog Known bugs and "features" Common Program Examples (GPIO, Threads, FFT, Expert System, ARMSchembler, Ports, ...) R5RS Conformance Documentation for Armpit Scheme Snapshot 00.0171: ChangeLog Known bugs and "features" TI OMAP 3530 BeagleBoard (rev. B7) Examples (GPIO, Threads, Expert System, ARMSchembler, Ports, ...) Documentation for Armpit Scheme Version 00.0160: ChangeLog Known bugs and "features" Common Program Examples (GPIO, Threads, Expert System, ARMSchembler, Ports, ...) Stellaris LM3S-EVB Examples (Boot, OLED, ADC, PWM, ...) Console Examples (PS/2 keyboard and on-board or 'Nokia'-like LCD) File writing (bug fix) and native USB device for the LPC2478-STK Performance R5RS Conformance Language Extensions Implementation Reference Documentation for prior snapshots and versions of Armpit Scheme. How To: upload, communicate with and re-assemble Armpit Scheme, and some additional notes. It is designed to run on the following boards: Table 1: Armpit Scheme Development MCU Board Specifications BOARD MANUFACTURER MCU CORE MHZ RAM FLASH USB LCD (*) LPC-H2103 Olimex LPC2103 ARM7TDMI 60 8 KB 32 KB - - Tiny2106 Newmicros LPC2106 ARM7TDMI 60 64 KB 128 KB - - Tiny2131 Newmicros LPC2131 ARM7TDMI 60 8 KB 32 KB - - Tiny2138 Newmicros LPC2138 ARM7TDMI 60 32 KB 512 KB - - Logomatic V1.0 SparkFun LPC2138 ARM7TDMI 60 32 KB 512 KB - - Logomatic V2.0 SparkFun LPC2148 ARM7TDMI 60 32 KB 512 KB Native - LPC-H2148 Olimex LPC2148 ARM7TDMI 60 32 KB 512 KB Native - LCDDemo-LPC2158 Future Designs LPC2158 ARM7TDMI 60 32 KB 512 KB Native Text SAM7-H256 Olimex AT91SAM7 ARM7TDMI 48 64 KB 256 KB Native - STR-H711 Olimex STR711 ARM7TDMI
[linuxkernelnewbies] USBTemp - mikrowerk - Project Hosting on Google Code
http://code.google.com/p/mikrowerk/wiki/USBTemp mikrowerk A wonderful stack of microcontroller projects. ProjectHome Downloads Wiki Issues Source Search Search within: All wiki pages Featured pages Current pages Deprecated pages for Updated Feb 04, 2010 by dalheimer USBTemp USBTemp measures the temperature and connects via USB to your computer. Introduction USBTemp provides a thermometer. It is based on the DS18S20 digital thermometers. In addition, the thermometer connects to an USB port - you can read the temperature using a commandline tool. In combination with RRDTool you can easily create temperature graphs: This is a live graph of the temperature in Kaiserslautern, Germany - at least if my server at home is up and running. I describe my setup at home here: USBTemp: Continuous Temperature Monitoring. Features At this time, USBTemp provides these features: Attaches to USB, powered over USB Cheap hardware Based on an ATMega168 (although an ATMega8 should work also) No SMD components Simple commandline tool for querying the sensors Support for five DS18S20 temperature sensors (extensible) Parasite-power mode for the DS18S20 - a single 2-wire cable is sufficient to connect all sensors Download The current version can be downloaded from the "Download" page. The tarball contains the firmware, the host software and the schematic. Hardware The hardware consists of an ATMega168, the DS18S20 temperature sensors and some support elements. It is described on the USBTempHardware page. Software The host software uses libusb to connect to the hardware. You can query the device for available temperature sensors: $ ./usbtemp sensors 2 sensor(s) found, querying sensor 0: ID 9F17A5010800 type: (DS18S20) sensor 1: ID B46865010800 type: (DS18S20) The IDs are the actual unique hardware IDs of the DS18S20 sensors. Afterwards you can use the ID to query a sensor: /usbtemp temp B46865010800 searching sensor with id B46865010800 - using sensor handle 1 reading sensor 1 (C): +1.1875 If you want to use the raw temperature value in a script, simply discard stderr: $ ./usbtemp temp B46865010800 2/dev/null +1. The host software only depends on libusb and has been tested on Linux and Mac systems. With libusb-win32 it should be possible to compile it on Windows as well - but this is currently untested. Building the software TODO. Credits The microcontroller firmware uses several libraries: The AVR-USB software-only USB driver from Objective Development The DS18X20 code example of Martin Thomas which in turn uses code of Peter Fleury (uart-library) and Colin O'Flynn (CRC-code). Comment by josheeg, Aug 11, 2009 so did you get the mega168 working? Would the new arduino mega3xx work it is similar to the 168? If so is it a usb keyboard? that would be easy to get keys in c. What speed logging? I have a 24 bit adc at 10ksps
[linuxkernelnewbies] Understanding Arduino Internals
processing.app.SerialException: Serial port '/dev/ttyUSB0' not found. Did you select the right one from the Tools Serial Port menu? at processing.app.Serial.init(Serial.java:153) at processing.app.Serial.init(Serial.java:76) at processing.app.debug.Uploader.flushSerialBuffer(Uploader.java:71) at processing.app.debug.AvrdudeUploader.uploadViaBootloader(AvrdudeUploader.java:78) at processing.app.debug.AvrdudeUploader.uploadUsingPreferences(AvrdudeUploader.java:53) at processing.app.Sketch.upload(Sketch.java:1460) at processing.app.Sketch.exportApplet(Sketch.java:1427) at processing.app.Sketch.exportApplet(Sketch.java:1382) at processing.app.Editor$45.run(Editor.java:2165) at java.lang.Thread.run(Thread.java:619) processing.app.debug.RunnerException: Serial port '/dev/ttyUSB0' not found. Did you select the right one from the Tools Serial Port menu? at processing.app.debug.Uploader.flushSerialBuffer(Uploader.java:91) at processing.app.debug.AvrdudeUploader.uploadViaBootloader(AvrdudeUploader.java:78) at processing.app.debug.AvrdudeUploader.uploadUsingPreferences(AvrdudeUploader.java:53) at processing.app.Sketch.upload(Sketch.java:1460) at processing.app.Sketch.exportApplet(Sketch.java:1427) at processing.app.Sketch.exportApplet(Sketch.java:1382) at processing.app.Editor$45.run(Editor.java:2165) at java.lang.Thread.run(Thread.java:619) processing.app.debug.RunnerException: Serial port '/dev/ttyUSB0' not found. Did you select the right one from the Tools Serial Port menu? at processing.app.debug.Uploader.flushSerialBuffer(Uploader.java:91) at processing.app.debug.AvrdudeUploader.uploadViaBootloader(AvrdudeUploader.java:78) at processing.app.debug.AvrdudeUploader.uploadUsingPreferences(AvrdudeUploader.java:53) at processing.app.Sketch.upload(Sketch.java:1460) at processing.app.Sketch.exportApplet(Sketch.java:1427) at processing.app.Sketch.exportApplet(Sketch.java:1382) at processing.app.Editor$45.run(Editor.java:2165) at java.lang.Thread.run(Thread.java:619) BuildProcess The process the Arduino environment uses to build a sketch. Overview A number of things have to happen for your Arduino code to get onto the Arduino board. First, the Arduino environment performs some small transformations to make sure that the code is correct C++. It then gets passed to a compiler (avr-gcc), which turns the human readable code into machine readable instructions (or object files). Then, your code gets combined with (linked against), the standard Arduino libraries that provide basic functions like digitalWrite() or Serial.print(). The result is a single Intel hex file, which contains the specific bytes that need to be written to the program memory of the chip on the Arduino board. This file is then uploaded to the board: transmitted over the USB or serial connection via the bootloader already on the chip or with external programming hardware. Pre-Processing The Arduino environment performs a few transformations to your main sketch file (the concatenation of all the tabs in the sketch without extensions) before passing it to the avr-gcc compiler. When your sketch is compiled, all tabs with no extension are concatenated together to form the "main sketch file" (C++). Then, #include "WProgram.h" is added to your sketch. This header file (found in the core folder for the currently selected board) includes all the definitions needed for the standard Arduino core. Next, the environment searches for function definitions within your main sketch file and creates declarations (prototypes) for them. The #include statement and function prototypes are inserted after any comments or pre-processor statements (#includes or #defines), but before any other statements (including type declarations). This means that if you want to use a custom type as a function argument, you should declare it within a separate header file. Also, this generation isn't perfect: it won't create prototypes for functions that have default argument values, or which are declared within a namespace or class. Compilation Sketches are compiled by avr-gcc and avr-g++ according to the variables in the boards.txt file of the selected board's platform. The include path includes the sketch's directory, the core folder (e.g. the hardware/arduino/core/arduino/ sub-folder of the Arduino application) and the avr include directory (hardware/tools/avr/avr/include/), as well as any library directories (in hardware/libraries/) which contain a header file which is included by the main sketch file. Note that libraries referenced only by another library (and not the main sketch file) are not placed in the include path or linked against the sketch. All libraries used (even indirectly by another library) must be #included by the main sketch file. When you verify or upload a sketch, it is built in a temporary directory in the system-wide temporary directory (e.g. /tmp on Linux). The .c and .cpp files of the target are compiled and output with .o
[linuxkernelnewbies] ePanorama.net - Links
http://www.epanorama.net/links/serialbus.html Index General information I2C SPI Microwire Maxim 3-wire Maxim/Dallas 1-Wire bus Interfacing techniques and questions on them Serial buses information page General information This page concentrates on links to inter-IC serial buses. When this page talks about 2-wire or 3-wire interfaces, this wire number is the number of control lines. In addition to this those interfaces generally need a common ground, which is the ground plane in circuit board applications and a seprate wire in inter-circuit-board connections. The serial bus interfaces are widely used for interfacing EEPROMs, data converters and many peripheral chips to microcontrollers. They are also often used for inter-microcontroller communication. Serial bus system are also used to build control buses inside equipments like TV receivers, AV amplifiers and cellular phones. The major advantage of usign s serial bus is the small number of wires needed. A major disadvantage of serial interfacing is the tradeoff of speed for space. The processor???s I/O port spends a relatively large amount of time communicating with a serial device. Consequently, serial converters with throughput rates above 500 ksps are uncommon. I2C What Is the I2C Interface? I2C is an acronym for Inter Integrated Circuit bus. I2C is a 2-wire serial interface standard defined by Philips Semiconductor in the early 1980's. It's purpose was to provide an easy way to connect a CPU to peripheral chips in a TV-set. The BUS physically consists of 2 active wires and a ground connection. The active wires, SDA and SCL, are both bidirectional. Where SDA is the Serial DAta line and SCL is the Serial CLock line. The key advantage of this interface is that only two lines (clock and data) are required for full duplexed communication between multiple devices. The interface typically runs at a fairly low speed (100kHz to 400kHz). With I2C, each IC on the bus has a unique address. Chips can act as a receiver and/or transmitter depending on it's functionality. The I??C-bus is devoloped by Philips to maximize hardware efficiency and circuit siplicity. The I2C interface is a simple master/slave type interface. Simplicity of the I??C system is primarily due to the bidirectional 2-wire design, a serial data line (SDA) and serial clock line (SCL), and to the protocol format. Bi-directional communication is facilitated through the use of wire and connection (the lines are either active-low or passive high). The I2C Bus protocol also allows collision detection, clock synchronization and hand-shaking for multi-master systems. The clock is always generated by the master, but the slave may hold it low to generate a wait state. In most systems the microcontroller is the master and the external peripheral devices are slaves. The maximum number of devices connected to the I2C bus is dictated by the maximum allowable capacitance on the lines, 400 pF, and the protocol's addressing limit of 16k; typical device capacitance is 10 pF. The I2C protocol has 127 addresses available. The original vision was to assign addresses by device function, but when Philips began to sell microcontrollers for I2C, the address could be programmed, eliminating the need for a Philips-assigned address. A device that controls signal transfers on the line in addition to controlling the clock frequency is the master and a device that is controlled by the master is the slave. The master can transmit or receive signals to or from a slave, respectively, or control signal transfers between two slaves, where one is the transmitter and the other is the receiver. I2C bus support more than one master connected to one bus. The I2C bus is an innovative hardware interface which provides the software designer the flexibility to create a truly multi-master environment. It is possible to combine several masters, in addition to several slaves, onto an I??C-bus to form a multimaster system. If more than one master simultaneously tries to control the line, an arbitration procedure decides which master gets priority. To begin communication, the bus master (typically a microcontroller) places the address of the device with which it intends to communicate (the slave) on the bus. All ICs monitor the bus to determine if the master device is sending their address. Only the device with the correct address communicates with the master. Philips' has over 150 CMOS and bipolair chips who are I??C-bus compatible, and also some other companies make ICs with I2C control interface. The I2C master is generally implemented with special I2C controller (sometimes integrated to microcontroller) or sometimes using a microcontroller and some software running on it. Both approaches are possible in typical one master I2C system. The multi-master system is not generally implemented with microcontroller software because it is extremely difficult to meet all the I2C Bus timing spec-ifications
[linuxkernelnewbies] How To Connect a PS/2 Keyboard to the iPhone
http://www.instructables.com/id/How-To-Connect-a-PS2-Keyboard-to-the-iPhone/?download=pdf How To Connect a PS/2 Keyboard to the iPhone intro step 1 step 2 step 3 step 4 step 5 step 6 step 7 step 8 step 9 step 10 step 11
[linuxkernelnewbies] PS/2 Mouse Interfacing
How to interface the PS2 mouse to Arduino directly? http://www.computer-engineering.org/ps2mouse/ The PS/2 Mouse Interface Source: http://www.Computer-Engineering.org Author: Adam Chapweske Last Updated: 04/01/03 Legal Information All information within this article is provided "as is" and without any express or implied warranties, including, without limitation, the implied warranties of merchantibility and fitness for a particular purpose. This article is protected under copyright law. This document may be copied only if the source, author, date, and legal information is included. Abstract This article attempts to explain every aspect of the PS/2 mouse interface including the physical and electrical interface, low-level protocol, modes of operation, commands, and extensions. General Description There are many types of pointing devices available for the modern PC including mice, trackballs, touchpads, electronic whiteboards, etc. Virtually all of these devices communicate on one of two interfaces: Universal Serial Bus (USB) or the PS/2 mouse interface. Older pointing device interfaces include the Apple Desktop Bus (ADB), RS-232 serial port, and the bus mouse interface. These are obsolete and are not covered in this article. The PS/2 mouse interface originally appeared in IBM's "Personal System/2" computers in the late 80's and it remains a widely-supported interface. However, USB has quickly caught on these last few years and will eventually replace the PS/2 interface entirely. The PS/2 mouse interface utilizes a bidirectional serial protocol to transmit movement and button-state data to the computer's auxiliary device controller (part of the keyboard controller). The controller, in turn, may send a number of commands to the mouse to set the report rate, resolution, reset the mouse, disable the mouse, etc. The host provides the mouse with a 5V ~100 mA power supply. Electrical Interface / Protocol The PS/2 mouse uses the same protocol as the PS/2 keyboard (a.k.a. AT keyboard). Click here for detailed information on this protocol. Inputs, Resolution, and Scaling The standard PS/2 mouse interface supports the following inputs: X (right/left) movement, Y (up/down) movement, left button, middle button, and right button. The mouse periodically reads these inputs and updates various counters and flags to reflect movement and button states. There are many PS/2 pointing devices that have additional inputs and may report data differently than described in this document. One popular extension covered later in this document is the Microsoft Intellimouse, which includes support for the standard inputs as well as a scrolling wheel and two additional buttons. The standard mouse has two counters that keep track of movement: the X movement counter and the Y movement counter. These are 9-bit 2's complement values and each has an associated overflow flag. Their contents, along with the state of the three mouse buttons, are sent to the host in the form of a 3-byte movement data packet. The movement counters represent the mouse's offset relative to its position when the previous movement data packet was issued, or when the last non-"Resend" (0xFE) command was successfully sent to the host. When the mouse reads its inputs it records the current state of its buttons and increments/decrements the movement counters according to the amount of movement that has occurred since the last input sample. If either of the counters has overflowed, the appropriate overflow flag is set. Futher modification of the counter is disabled until it the counters are reset (due to a packet being sent). The parameter that determines the amount by which the movement counters are incremented/decremented is the resolution. The default resolution is 4 counts/mm and the host may change that value using the "Set Resolution" (0xE8) command. There is a parameter that does not affect the movement counters, but does affect the reported value of these counters. This parameter is scaling. By default, the mouse uses 1:1 scaling, which has no effect on the reported mouse movement. However, the host may select 2:1 scaling by issuing the "Set Scaling 2:1" (0xE7) command. If 2:1 scaling is enabled, the mouse will apply the following algorithm to the movement counters before sending their contents to the host: Movement Counter Reported Movement 0 0 1 1 2 1 3 3 4 6 5 9 N 5 2 * N 2:1 scaling only applies to the automatic data reporting in stream mode. It does not affect the reported data sent in response to the "Read Data" (0xEB) command. Movement Data Packet The standard PS/2 mouse sends movement/button information to the host using the following 3-byte packet:
[linuxkernelnewbies] Embedded.com - Introduction to Serial Peripheral Interface
http://embedded.com/columns/beginerscorner/9900483?_requestid=421616
Introduction to Serial Peripheral
Interface
By David Kalinsky and Roee Kalinsky
Embedded Systems
Design
(02/01/02, 11:33:00 AM EST)
Another
option for low-cost, low-speed communication "inside the box" is the
serial peripheral interface.
Several months ago
in Beginner's Corner, we covered the inter-integrated circuit bus. I2C
is a popular technology for low-cost, low-speed, communication "inside
the box" ("I2C,"
August 2001, p. 87 ). Another choice to consider is the serial
peripheral interface (SPI).
SPI vs. I2C
Both SPI and I2C
provide good support for communication with slow peripheral devices
that are accessed intermittently. EEPROMs and real-time clocks are
examples of such devices. But SPI is better suited than I2C
for applications that are naturally thought of as data streams (as
opposed to reading and writing addressed locations in a slave device).
An example of a "stream" application is data communication between
microprocessors or digital signal processors. Another is data transfer
from analog-to-digital converters.
SPI can also
achieve significantly higher data rates than I2C.
SPI-compatible interfaces often range into the tens of megahertz. SPI
really gains efficiency in applications that take advantage of its
duplex capability, such as the communication between a "codec"
(coder-decoder) and a digital signal processor, which consists of
simultaneously sending samples in and out.
SPI devices
communicate using a master-slave relationship. Due to its lack of
built-in device addressing, SPI requires more effort and more hardware
resources than I2C when more than one slave is involved. But
SPI tends to be simpler and more efficient than I2C
in point-to-point (single master, single slave) applications for the
very same reason; the lack of device addressing means less overhead.
Inside the box
SPI is a serial bus
standard established by Motorola and supported in silicon products from
various manufacturers. SPI interfaces are available on popular
communication processors such as the MPC8260 and microcontrollers such
as the M68HC11. It is a synchronous serial data link that operates in
full duplex (signals carrying data go in both directions
simultaneously).
Devices communicate
using a master/slave relationship, in which the master initiates the
data frame. When the master generates a clock and selects a slave
device, data may be transferred in either or both directions
simultaneously. In fact, as far as SPI is concerned, data are always
transferred in both directions. It is up to the master and slave
devices to know whether a received byte is meaningful or not. So a
device must discard the received byte in a "transmit only" frame or
generate a dummy byte for a "receive only" frame.
Figure 1: Single master, single slave SPI implementation
SPI specifies four
signals: clock (SCLK); master data output, slave data input (MOSI);
master data input, slave data output (MISO); and slave select (SS).
Figure 1 shows these signals in a single-slave configuration. SCLK is
generated by the master and input to all slaves. MOSI carries data from
master to slave. MISO carries data from slave back to master. A slave
device is selected when the master asserts its SS signal.
If multiple slave
devices exist, the master generates a separate slave select signal for
each slave. These relationships are illustrated in Figure 2.
Figure 2: Single master, multiple slave SPI implementation
The master
generates
slave select signals using general-purpose discrete input/output pins
or other logic. This consists of old-fashioned bit banging and can be
pretty sensitive. You have to time it relative to the other signals and
ensure, for example, that you don't toggle a select line in the middle
of a frame.
While SPI doesn't
describe a specific way to implement multi-master systems, some SPI
devices support additional signals that make such implementations
possible. However, it's complicated and usually unnecesary, so it's not
often done.
A pair of
parameters
called clock polarity (CPOL) and clock phase (CPHA) determine the edges
of the clock signal on which the data are driven and sampled. Each of
the two parameters has two possible states, which allows for four
possible combinations, all of which are incompatible with one another.
So a master/slave pair must use the same parameter pair values to
communicate. If multiple slaves are used that are fixed in different
configurations, the master will have to reconfigure itself each time it
needs to communicate with a different slave.
At a higher level
SPI does not have
an
acknowledgement mechanism to confirm receipt of data. In fact, without
a communication protocol, the SPI master has no knowledge of whether a
slave even exists. SPI also offers no flow control. If you need
hardware flow control, you might need to do something outside of SPI.
Slaves can be
[linuxkernelnewbies] Arduino playground - PS2Keyboard
http://www.arduino.cc/playground/Main/PS2Keyboard
General
The PS2Keyboard library uses one of
the two available external interrupts to react on keyboard input. Once
such input is received, it's stored in a one-byte buffer and is
available to be read.
The following schematic shows how to connect a PS/2 connector:
Make sure you connect the Clock PIN to the digital
PIN 3 on the Arduino. Otherwise the interrupt, and therefore the whole
library, won't work.
Usage
Below is a simple example on how to use the library. For more
keycode constants have a look at the PS2Keyboard.h
file.
#include PS2Keyboard.h
#define DATA_PIN 4
PS2Keyboard keyboard;
void setup() {
keyboard.begin(DATA_PIN);
Serial.begin(9600);
Serial.println("hi");
delay(1000);
}
void loop() {
if(keyboard.available()) {
byte dat = keyboard.read();
byte val = dat - '0';
if(val = 0 val = 9) {
Serial.print(val, DEC);
} else if(dat == PS2_KC_ENTER) {
Serial.println();
} else if(dat == PS2_KC_ESC) {
Serial.println("[ESC]");
}
}
}
Download
This library is at a very early stage. If anyone wants to
revise/rewrite it, feel free to do so (published under the LGPL).
Attach:PS2Keyboard002.zip
FULL KEYBOARD IMPLEMENTATION CONTAINED IN PS2Keyboard_014A
Attach:PS2Keyboard_014A.zip
NOTE: PS2Keyboard_014A
is the library to use beginning with Arduino 0013. ** It contains a
full complement of letters, numbers and punctuation (excluding shifted
characters/symbols). **
Further readings
http://www.beyondlogic.org/keyboard/keybrd.htm
http://www.computer-engineering.org/ps2keyboard/scancodes2.html
BarcodeScanner
PS2KeyboardExt
Suggestions
Rename charAvailable() to available() and readChar() to read() for
consistency with other libraries.
Thanks for the hint. I've changed the names and
updated the example. I didn't know how to reupload the file, so I
changed its name. The old one (PS2Keyboard.zip)
is hereby obsolete.
Bug
Missing 'byte' declaration
Can be fixed by adding
#include "binary.h"
typedef uint8_t boolean;
typedef uint8_t byte;
[linuxkernelnewbies] BeagleBoardRecovery - eLinux.org
http://elinux.org/BeagleBoardRecovery
From eLinux.org
Jump to: navigation,
search
This page is how to recover ("unbrick") a broken BeagleBoard.
It should help you if you messed your boot configuration and
BeagleBoard doesn't boot any more the normal way ("bricked").
Contents
[hide]
1 Symptoms
2 What has happened?
3 What to do now?
3.1 MMC recovery
3.2 MMC recovery
Troubleshooting
3.3 USB recovery
3.4 UART recovery
Symptoms
Normally, if you boot from MMC, you will get something like
...40T...
in terminal program connected to UART (115200 8N1). This is
output
from OMAP3's bootrom while scanning the UART for boot source before
trying to boot from MMC card. If you don't get this, but want to boot
from MMC, most probably bootrom doesn't reach the MMC boot stage any
more. If you played with NAND before getting this, most probably NAND
contains some broken content.
What has happened?
Depending on user
button OMAP3 on BeagleBoard uses different boot order. Normal order
if user button isn't pressed at power up is boot from
NAND - USB - UART - MMC
in this order. Depending on the boot medium (e.g. MMC)
this might fail if something bad is in NAND flash which confuses OMAP3
bootrom thus stopping it to reach MMC boot stage.
This might happen if you e.g. mess your NAND, e.g. something
went wrong with NAND boot.
What to do now?
First, we have to press user
button at power up to switch boot order to
USB - UART - MMC - NAND
to have option to boot from other sources than broken NAND
(which is first if user button is not pressed).
Then, there are three options to boot from:
MMC
USB
UART
Below, MMC and USB recovery will be done in detail. Goal of all
ways is to get an U-Boot prompt again to erase the bad NAND
content.
MMC recovery
The procedure to put your board into the "factory fresh state"
used on all boards being made now is at http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidation.
The original recovery method is described below.
MMC recovery should be straight forward. Press user
button
at power up and according to above boot order MMC boot is before NAND.
With this, we should be able to boot as we did without pressing the
user button before bricking the board. But:
There are some broken MLO (x-loader) out there which fail to boot
if something wrong is in NAND. E.g.:
...40T.
Texas Instruments X-Loader 1.41
Starting on with MMC
Reading boot sector
150832 Bytes Read from MMC
Starting OS Bootloader from MMC...
U-Boot 1.3.3 (Jun 20 2008 - 17:06:22)
OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle Board + LPDDR/NAND
RAM Configuration:
Bank #0: 8000 128 MB
Bank #1: 8800 0 kB
NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0x01 ( AND 128MiB 3,3V 8-bit)
NAND bus width 16 instead 8 bit
0 MiB
hang, no prompt
This seems to happen with both MLO's from Beagle source code page (381MHz and 500MHz one)
independent of U-Boot version.
Thus, you have to use a special (?) MLO for recovery to get a
U-Boot prompt. Replacing MLO used above on MMC/SD card with this recovery MLO we get a U-Boot prompt while pressing
the user button at power up:
...40T.
Texas Instruments X-Loader 1.41
Starting on with MMC
Reading boot sector
150832 Bytes Read from MMC
Starting OS Bootloader from MMC...
U-Boot 1.3.3 (Jun 20 2008 - 17:06:22)
OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle Board + LPDDR/NAND
RAM Configuration:
Bank #0: 8000 128 MB
Bank #1: 8800 0 kB
NAND: 256 MiB
In:serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
OMAP3 beagleboard.org #
U-Boot version doesn't seem to matter. Then you can erase NAND
start:
OMAP3 beagleboard.org # nand unlock
device 0 whole chip
nand_unlock: start: , length: 268435456!
NAND flash successfully unlocked
OMAP3 beagleboard.org # nand erase 0 8
NAND erase: device 0 offset 0x0, size 0x8
Erasing at 0x6 -- 100% complete.
OK
OMAP3 beagleboard.org #
If you now re-power your board without pressing the
user button it should work as before. Happily unbricked!
MMC recovery Troubleshooting
Some have encountered problems with trying to boot from MMC,
but it
wasn't booting from MMC because of a bad formating and/or copy of the
MLO. This example demonstrates booting from NAND even if the user
button (40T) has been pressed.
...40T...
Texas Instruments X-Loader 1.41
Starting OS Bootloader...
Instead, the correct and expected result with user button
pressed is booting from MMC and this should be printed:
...40T...
Texas Instruments X-Loader 1.41
Starting on with MMC
Reading boot sector
150832 Bytes Read from MMC
Starting OS Bootloader from MMC...
If MMC is not displayed, this means that the MLO
(x-loader
for the MMC) has not been properly copied or the partition has
[linuxkernelnewbies] BBB Assembled and Tested | Modern Device
http://www.moderndevice.com/products/bbb-assembled
[linuxkernelnewbies] Arduino playground - MIDILibrary
http://www.arduino.cc/playground/Main/MIDILibrary MIDI Library v2.5 This library enables MIDI I/O communications on the Arduino serial ports. You can send and receive messages of (almost) all kind (including System Exclusive). The purpose of this library is not to make a big synthetizer out of an Arduino board, the application remains yours. v2.5 Features: Improved handling of System messages (Exclusive, but also RealTime, Clock...). Now the library can read every message ! (but you will have to sort them in your sketch). v2 Features: The version 2 of the MIDI library greatly simplifies its use, by removing advanced options such as opto pin powering, fast mode ect.. v1 Features: Sending every kind of MIDI messages (no Clock or Sync messages) Reading (almost) every kind (no Clock or Sync messages) OMNI input reading Thru-like input mirroring Fast transmission mode automatic handling (see below) on input output Input message saving Optocoupler power pin handling (enable/disable hardware MIDI input) Download the library here (with documentation) Download the library here (without documentation) - Update (14/12/2009): Version 2.5 released. - Update (28/07/2009): Version 2 released. - Update (28/03/2009): Simplified version of MIDI.begin, Fast mode is now on by default. - Update (08/03/2009): Thru method operationnal. Added some features to enable thru. Warning: this library requires Arduino 13 or more recent versions. What do I need to do? After downloading the library, unzip it to the libraries folder (arduino-00xx/hardware/libraries), then reboot the Arduino IDE or compile your sketch, it will compile the library. Include the library using the menu in the IDE, or type #include MIDI.h You are now ready to use the library. look at the reference page to learn how to use it, or the examples given. Don't forget to enable the I/O communications with MIDI.begin... if you have any comment or notification to make, feel free to contact me at francoisbest (at) gmail (dot) com. Reference See the extended reference here, or download it as PDF. A few things... Using MIDI.begin In the setup() function of the Arduino, you must call the MIDI.begin method. If you don't give any argument to this method, the input channel for MIDI in will be set to 1 (channels are going from 1 to 16). This method will: Start the serial port at the MIDI baudrate (31250) Set the input channel at the argument given (if any, 1 else) Enable the Thru, with no filtering (everything caught is sent back) MIDI Thru The MIDI Thru allows you to mirror your incoming messages to the MIDI output. It replaces the need of a MIDI Thru connector, as it copies every valid incoming message from the input. For good performance, you might want to call read() in a fast loop, for low latency. Incoming unread bytes/messages are kept in the Arduino serial buffer, in order not to flood it, check regularily with MIDI.read. See the reference for Thru explanations. Thru is default enabled, you can turn it off using appropriate methods. Hardware Take a look at the MIDI.org schematic
[linuxkernelnewbies] deadhacker.com (good articles)
http://deadhacker.com/ 02.03 JTAGEnumeration 11.08 Workflow for hardware securityanalysis 07.26 Targeting the Panasonic HVX200 HDcamera 05.06 The Subterfugue processsandbox 05.13 finding entropy in binaryfiles 02.28 Cryptology ePrint ArchiveRSS 02.22 Formal aspects of mobile code security Chapter5 02.21 SHA-1Illustrated 02.06 An Illustrated Guide to Cryptographic HashesIntro. 02.05 VB Reversed A decompilingapproach
[linuxkernelnewbies] JTAG Enumeration « deadhacker. com
http://deadhacker.com/2010/02/03/jtag-enumeration/ JTAGEnumeration JTAGenum is an open source Arduino based hardware platform I built last year with three primary goals: [1.Given a large set of pins on a device determine which are JTAG lines2. Enumerate the Instruction Register to find undocumented functionality 3. be easy to build and apply] The development of a device hasvariousdistinct stages handled by different people/companies that each assume the other has properly secured their part. The security of devices often rely onobfuscation which makes it dificult for any part of the chain to evaluate the security of the whole. This is a problem that JTAGenum helps address. This was built for personal research and while working on various projects atRecurity Labs. Please feel free tocontact me with any questions, problems, targets or updates. I would be more than happy to share credit. Related work: There are two other tools for finding JTAG pins:JTAGScan presented by Benedikt Heinz (hunz) atph-neutral which inspiredArduinull by Sbastien Bourdeauducq (lekernel). JTAGenum is most similar to the latter with the added feature of finding undocumented functionality. Felix Domke(tmbinc) recently gave a lecture on enumarating undocumented JTAG instructions and anyone considering using JTAGenum would do well to check hispaper(cache)/lecture from the26c3. About JTAG JTAG is a common hardware debugging interface. It is used throughout the development chain of a device. Layout designers and board manufactures that employpick-and-place machines will use JTAG to test interconnectivity of components.ASIC designers use it to test the internal state of the chips they build. Software developers often use it to load firmware onto the device and to debug software. For a varity of reasons JTAG is often left in the final product. As such each stage of the development chain will attempt toobfuscate its existence or functionality. ASIC manufactures often build in added functionality (such as logic analysis tools) and avoid mentioning both extended and often basic functionality from their final documentation. Layout designers might remove JTAG pins from the board, spread their contacts throughout on the board, remove contacts and hide JTAG lines on inner layers of the board. As mentioned before, this can make itdifficultfor any one part of the development chain to evaluate the security of the device as a whole. If you are unfamiliar with the inner workings of JTAG skip to theA bit more about JTAG section for the basics. Hardware To use JTAGenumyou need an arduino compatiblemicrocontroller.Arduino is a simple development enviornment (IDE) for various microcontrollers. At the moment AVR and PIC variants are available and can be purchased anywhere from $10 to $50. JTAGenum has been tested on the official ArduinoDuemilanove,RBBB clone andTeensy++. When picking your microcontroller platform consider two issues: 1. How many pins do you want to check on your target. 2. what voltage level does your target device require. Concerning voltage most Arduinos work at 5 volts. Some are switchable but even those that are not can be modified. For example revision 1.0 of the Teensy++ with over 30 pins of i/o can be modified by hand to operate at 3.3 volts. I show where to cut lines and install a voltage regulatorover here. For voltages other than 3.3v and 5v there are avarietyof solutions that depend on if you need uni-directional or bi-directional support on your i/o lines. When connecting the microcontroller to the pins of your target one thing tobe awareof is possible cross-talk between wires. Ive been using a patch cable from Amontec that has a lot of cross talk. JTAGenum has a mode that helps check for this which I will get into more detail later. Usage Download the JTAGenum code and open it in the Arduino IDE. The following needs to be changed in the code depending on your microcontroller: pins[]define which pins on the microcontroller are being used to connect to the target pinname[]is aconvenientway to map the pins to names whichcorrespondto the names of pins on your target IR_LENdefines the length of the JTAG instruction register. If you change this you should also add 0s to each of the corespondingIR_**instruction definitions. You can find the IR_LEN in the documentation for your target. If you cannot find it just guess. (10 is the current value, 8 is also common) Upload the sketch to your microcontroller and open the serial console with a baud of 115200. Sending a h to the console will print usage information that describes each function. Each function is enacted by sending the defined onecharactercode: v verbose Toggles verbose output. At times verbose might present too much information or without it too little. l loopback check Find loopback pairs that will generate false-positives for other tests. After running you should remove any loopback pairs from yourpins[]/pinnames[].Looback pairs are found by sending a
[linuxkernelnewbies] How to set up an Ethernet over USB connection between the Sharp Zaurus SL-5000D and a Linux machine
http://www.ruault.com/Zaurus/ethernet-over-usb-howto.html Version: 1.13, 07/17/2003 Author: Charles-Edouard Ruault Credits: Thanks to Stuart Lynne for allowing me to distribute Lineo's new driver Thanks to the people who sent me remarks and asked questions, they helped me improve this document ! This Document assumes that the Linux machine is running a Linux kernel 2.4.x, with x=17. This document describes the setup for a Zaurus ROM version = 1.10, for older ROMs versions, check this page. NEW If you're using a kernel version =2.4.21 then read this. DISCLAIMER: Use this patch at your own risk, it comes with no warranty ! To get information on specific distributions, follow these links : Mandrake 8.2 Suse 7.1 and 8.0 Debian Kernel version =2.4.21 1) Patch the linux kernel The patch has been tested against kernel 2.4.17 and up. I've received patches for some specific kernel version shipped with common distributions, see in the download area listed below if there is one for yours ! Download the patch corresponding to your kernel version from here Assuming your Linux sources are in /usr/src/linux do the following : cp usbdnet-2.4.x.patch.gz /usr/src cd /usr/src zcat usbdnet-2.4.x.patch.gz | patch -p0 Now reconfigure the kernel to support : cd /usr/src/linux make menuconfig in "Code maturity level options", select "Prompt for development and/or incomplete code/drivers" in "USB support", section "USB Network adaptors", select (as a module) "USBD Network (Encapsulated) Host-to-Host Link (EXPERIMENTAL)" Then enter 04dd in USBD Network idVendor and 8004 in USBD Network idProduct Now rebuild and install the modules ( note : this supposes that a kernel had already been build in this source tree, if it's not the case, do a make bzImage before the make modules ) cd /usr/src/linux make clean dep modules modules_install. Make sure that the core usb support is already active in your kernel : modules usbcore and usb-uhci or usb-ohci should be loaded, if not run modprobe usb-uhci/usb-ohci), otherwise rebuild the kernel and reboot. If you don't know which usb module to use for your machine ( usb-uhci or usb-ohci ) then check this page, it contains instructions on how to find out. NOTES: If you had previously compiled in the patched CDCEther driver, remove it from the kernel, having both drivers compiled will prevent the new driver from working. As mentioned by many people, make sure you've compiled in the correct driver into the kernel in the USB Controllers subsection of the USB configuration. Some people report that they're getting the following message when loading the usbdnet module echo_tx not found it looks like you can safely ignore it since it does not prevent the driver from working. Some people have reported file transfer problem on file larger than 65kB, it appears that is was due to the fact that they where using the uhci module instead of the usb-uhci. If you're having this kind of problem and you are using the uhci module, try using usb-uhci instead. I've also received reports of kernel crashes when transferring large files with some motherboards ( at least Gigabyte X71 ) and kernel versions ( 2.4.10 and 2.4.18 ). The solution seems to update to a kernel 2.4.19pre8 or higher. 2) Put the Zaurus on the cradle. You should see a message like this in /var/log/messages : hub.c: USB new device connect on bus1/1, assigned device number 38 usb.c: USB device 38 (vend/prod 0x4dd/0x8004) is not claimed by any active driver. v0.4b s...@lineo.com, t...@lineo.com usbdnet.c: v0.4b s...@lineo.com, t...@lineo.com usbdnet.c: USB Host to Device Network - for Linux USB Devices using MDLM/CDC usb.c: registered new driver usbdnet If you don't see this, try to push the sync button on the craddle, it should help ! now do ifconfig -a you should see a new ethernet interface ( probably usb0 ), you can now configure it : ifconfig usb0 192.168.129.1 netmask 255.255.255.255 up route add -host 192.168.129.201 usb0 then try : ping 192.168.129.201 , if you've got a reply, you've won ! 3) If you want to be able to connect to the internet from the Zaurus You'll need to masquerade the Zaurus's IP from your machine. Let's say that the ethernet interface that connects you to the internet is ethX and that it's IP is MY_IP, you would need to do the following : make sure you enable the following options in the kernel : in "Networking options", select : Network packet filtering (replaces ipchains) in "IP: Netfilter Configuration" select at least "IP tables support (required for filtering/masq/NAT)" (as a module if you want) "Connection tracking (required for masq/NAT)" (as a module if you want) "Full NAT" (as a module if you want) "MASQUERADE target support (NEW)" (as a module if you want) Then recompile your kernel modules and reboot then do the following : ifconfig usb0 192.168.129.1 netmask
