On Tue, 2013-06-11 at 06:33 +0100, Sanjay Singh Rawat wrote:
> >> use cpu_do_idle for entering the wfi mode.
> >>
> >> Signed-off-by: Sanjay Singh Rawat
> >> ---
> >> arch/arm/mach-vexpress/hotplug.c |3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm
On Mon, 2013-05-27 at 15:32 +0100, Sanjay Singh Rawat wrote:
> use cpu_do_idle for entering the wfi mode.
>
> Signed-off-by: Sanjay Singh Rawat
> ---
> arch/arm/mach-vexpress/hotplug.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-vexpress/hotplug.c
On Thu, 2012-10-25 at 11:41 +0100, Viresh Kumar wrote:
> @Pawell and others: Is there a way in vexpress bootmon to load images
^^ ;-)
> directly from uSD card instead of flash?
No, sorry. The uSD card is tied to the microcontroller and there is no
"wide enough pipe" between it and the main
On Wed, 2012-10-24 at 01:40 +0100, Thomas Renninger wrote:
> > More and more of people are getting interested in the subject of power
> > (energy) consumption monitoring. We have some external tools like
> > "battery simulators", energy probes etc., but some targets can measure
> > their power usag
On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote:
> > Traditionally such data should be exposed to the user via hwmon sysfs
> > interface, and that's exactly what I did for "my" platform - I have
> > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good
> > enough to draw pretty gr
On Tue, 2012-10-23 at 19:49 +0100, Andy Green wrote:
> A thought on that... from an SoC perspective there are other interesting
> power rails than go to just the CPU core. For example DDR power and
> rails involved with other IP units on the SoC such as 3D graphics unit.
> So tying one number
On Tue, 2012-10-23 at 18:43 +0100, Steven Rostedt wrote:
> > <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361
> >
> > One issue with this is that some external knowledge is required to
> > relate a number to a processor core. Or maybe it's not an issue at all
> > because it should be l
On Tue, 2012-10-23 at 22:56 -0400, Nicolas Pitre wrote:
> The script to generate a boot script to generate an ATAGS block is a
> rather nice hack.
These days are, fortunately, long gone :-) New-ish Boot Monitors (5.x.x
versions in particular) speak initrd, ATAG _and_ DTB "natively", so one
can b
Greetings All,
More and more of people are getting interested in the subject of power
(energy) consumption monitoring. We have some external tools like
"battery simulators", energy probes etc., but some targets can measure
their power usage on their own.
Traditionally such data should be exposed
On Tue, 2012-10-09 at 12:34 +0100, Viresh Kumar wrote:
> On 9 October 2012 16:24, Pawel Moll wrote:
> > On Tue, 2012-10-09 at 11:42 +0100, Sudeep KarkadaNagesha wrote:
> >> Robin raised a valid point that this driver is TC2 specific and bL is
> >> not appropriate nam
On Tue, 2012-10-09 at 11:42 +0100, Sudeep KarkadaNagesha wrote:
> Robin raised a valid point that this driver is TC2 specific and bL is
> not appropriate name for it including the file name(my bad choice at first).
Just to be painfully precise ;-) I must say it's not TC2 specific, but
V2P-CA15_A7
On Fri, 2012-09-14 at 13:48 +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Pawel Moll wrote:
> > On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini
> > > CC: Russell King
> > > CC
On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
> CC: Russell King
> CC: Pawel Moll
> CC: Marc Zyngier
> ---
> arch/arm/mach-vexpress/v2m.c | 11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
>
On Fri, 2012-09-14 at 11:44 +0100, Hongbo Zhang wrote:
> Hi all,
> I am facing the same problem as Paul's, is there any solution?
There's a couple things you should try:
1. Upgrade to 5.11
2. Check /dev/ttyACM0 permissions (try to do "cat /dev/ttyACM0" - don't
expect any data out of it, just see
On Thu, 2012-07-19 at 19:44 +0100, Paul Larson wrote:
> So, click "Capture options" button (the cogwheel like icon,
> the middle
> one of three) and make sure that the "Energy Capture" input
> contains
> /bin/caiman -d /dev/ttyACM0
> I have 5.10 (buil
On Wed, 2012-07-18 at 17:01 -0300, Christian Robottom Reis wrote:
> On Thu, Jul 12, 2012 at 02:54:15PM -0500, Paul Larson wrote:
> > I've been looking a bit at how to get this running under DS-5, but I
> > haven't found much documentation. Best thing I've found so far has been
> > http://www.youtu
Dnia 2012-03-06, wto o godzinie 14:50 +, Rob Herring pisze:
> > What are the plans for single zImage? Where does the vexpress-a15 fit
> > in with that? Could I bump it to the front of the list?
>
> DT support for vexp A9 is going into 3.4 I believe. Pawel has been
> working on it and can prob
On Thu, 2012-01-26 at 19:20 +0100, Zygmunt Krynicki wrote:
> It also requires a license from arm for each machine
> that runs it (it binds to mac address)
This could be mitigated by setting up a Flex licence server for machines
in the farm, with floating licences instead of noded-locked ones. Aft
On Thu, 2012-01-26 at 21:19 +0100, Zygmunt Krynicki wrote:
> >>> With Pawel Moll's VExpress device tree support patches on top of
> >>> mainline, we can produce a single kernel config and a set of device
> >>> trees which allow booting on all the A15-based model variants.
>
> About device trees, d
On Wed, 2011-11-30 at 14:32 +, Arnd Bergmann wrote:
> I don't care much either way, but I think it would be good to
> use similar solutions across all hypervisors. The two options
> that I've seen discussed for KVM were to use either a virtual PCI
> bus with individual virtio-pci devices as on
> > * Ethernet
> >
> > Was buggered, is fixed now :-)
>
> When did it become un-buggered?
According to this bug log:
https://bugs.launchpad.net/linux-linaro/+bug/673820
(my own entry ;-) it was 2011-08-31.
> Tim Klein here is trying to get said
> machine to boot over TFTP with NFS root and it
> So I guess it must be no SATA because of broken PCI,
True.
> no MMC because of FPGA bugs (now fixed),
Work-arounded ;-) (hopefully really fixed in near future).
> no CF card because of (?).
CF usability depends on the card. Most of the old cards Just Work (TM).
New cards tend to have some
> > > Specifically, MMC and SATA media are unreliable and the best solution is
> > > to try USB.
BTW, what do you mean by "SATA media" here?
PCI Express doesn't work (broken test chip, not the motherboard itself),
so you can't use PCI SATA Host Controller and there is no HC on the
motherboard :-)
> I've heard that due to bugs all high bandwidth devices are flakey.
They are getting better and better though :-)
> Specifically, MMC and SATA media are unreliable and the best solution is
> to try USB.
With the latest official firmware (and IO FPGA) from the VE CD 3.0:
https://silver.arm.com/
> > PS. The number I quoted are valid when "CPU implementer" == 0x41 (ARM Ltd.)
>
> What about non-ARM implementations from e.g. Qualcomm and Marvell?
Sorry, I have no access to theirs specs and the ARM ARM (Architecture
Reference Manual) does not enforce any particular numbering scheme.
Some SA
> I actually did look for a bit and never found a definitive list. I've
> found descriptions of the bitfield and some sample values, but I haven't
> seen an actual official list.
That's correct, I don't think such a list exists (at least within
official ARM specs). What I meant is searching for th
> If you search the specs on http://infocenter.arm.com for "Main ID
> register" you should get all the numbers you wish for :-)
Apparently it's called "ID Code Register" for ARM9 and the expected (not
tested ;-) values would be:
ARM926 - 0x926
ARM946 - 0x946
ARM966 - 0x966
etc., you get the pict
> Does anybody have a list of such numbers?
If you search the specs on http://infocenter.arm.com for "Main ID
register" you should get all the numbers you wish for :-)
> Or else, perhaps people could just post any number they happen to know?
For v6 and v7 processors, the /proc/cpuinfo's "CPU par
.irq= { 73, },
};
This should be soon replaced with Device Tree entry
supplied by the simulation environment.
Signed-off-by: Pawel Moll
---
drivers/virtio/Kconfig | 11 +
drivers/virtio/Makefile |1 +
drivers/virtio/virtio_amba.c | 443 +++
rowing it into LKML fire. So here I am :-)
All comments welcome!
Paweł
Pawel Moll (2):
arm: Add VIRTUALIZATION configuration menu and virtio options
arm: Add AMBA bus driver for virtio device
arch/arm/Kconfig | 16 ++
drivers/virtio/Kconfig | 11 +
drivers/vir
This patch adds menuconfig VIRTUALIZATION to arm Kconfig
and includes virtio Kconfig in it.
Signed-off-by: Pawel Moll
---
arch/arm/Kconfig | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d9..fca5987 100644
Hi All,
As John Rigby expressed interest in having a short hands-on session on
DS-5 (covering interesting aspects like debugging in command line ;-)
during Linaro Connect in Cambourne, I was just wondering if there would
be anyone else keen on joining us? If so, let me know so I can prepare
enough
Hi Folks,
As some of you may remember, Linaro engineers have access to free DS-5
licenses.
If you don't know what DS-5 is, you can stop reading now ;-)
If you know what DS-5 is, you may also use it, either on daily basis or
just occasionally? I'd be most grateful for letting me know about it.
It
Hi,
> > Installed image is 125 Megs. (Down from 290 Meg) We're on the cusp
> > of being able to fit into 128 megs of flash.
>
> If that's seen to be interesting, we should probably discuss it with
> the emdebian folks-- there's a risk of reinventing what they do; plus
> they certainly have tools
> 2.6.38 on imx51 babbage board.
Then I won't be able to provide you with a simple hack, sorry...
Generally looks like the sched_clock implementation is missing so the
ftrace is reverting to jiffies as the timestamp source (this was the
case with mach-vexpress with kernels < 2.6.37)
Good luck!
Hello,
> When I am trying to use ftrace to measure cpuidle latency, I find that
> the timestamp is always ending with , like below.
> -0 [000]79.53: cpu_idle: state=0 cpu_id=0
What platform and kernel is it? 2.6.35 and Versatile Express by any
chance?
Cheers!
Paweł
> Regarding using V4L to communicate with DSPs/other processors: that too
> could be something for Linaro to pick up: experiment with it for one
> particular
> board, see what (if anything) is needed to make this work. I expect it to be
> pretty easy, but again, nobody has actually done the initia
> Ah I think there is a misunderstanding here, damn these TLA:s.
>
> STM in U8500 == ST-Ericsson System Trace Module
> STM in coresight == ARM System Trace Macrocell
Right... I've just nearly died laughing... ;-)
We could have discussed technical details for a looong time then :-)
Thanks for be
Morning,
> y, STM is not in the same family that xTM which trace execution & data
> flow of an ARM core (non intrusive).
> STM is more at applicative trace level like printf (output console
> only).
Well, what I mean is that xTMs - ETM/PTM tracing execution flow, ITM
behaving like mentioned prin
> This module external interface is a pad on the chip
> which complies to the MIPI System Trace Protocol v1.0,
> and the actual trace output can be read by an
> electronic probe, not by software so it cannot be intercepted by
> the CPU and reach Linux userspace.
I'm not an expert here, b
> So, I do hope that someone decides to implement something more reasonable
> if Versatile Express were to get a DMA controller. If it's another PL08x
> then it isn't worth it - it won't work.
More likely it will be DMA-330 formerly known as PL330. But as I said -
it's about the chip that Core Ti
> Have you considered switching the ISP1761 handler to
> request_threaded_irq() with IRQF_ONESHOT | IRQF_NO_SUSPEND
> so it runs in process context with that IRQ masked off, until completion?
That's something that Will suggested, but no - I didn't try it. This may
be worth discussing with the ISP1
> And to prove the point, I have MMCI running at up to 4Mbps, an 8 fold
> increase over what the current fixed upper-rate implementation does.
> The adaptive rate implementation is just a proof of concept at the
> moment and requires further work to improve the rate selection algorithm.
Great, I'v
> > Please help me figuring out the problem. Is it because I didn't create
> > uInitrd? If so, then how to create it for ARM?
> I believe you're right.
Em, not necessarily... I used both hand-made and distribution-made
Linaro kernels with Linaro filesystem but without initrd. And it did
complain a
> Anyway, any feedback appreciated, especially if all thing is absolutely
> pointless.
An interesting fact (thanks, Dave!) was brought to my attention - lack
of initrd "support"... I personally try not to use initrd at all, so I
totally forgot about it. It will be just additional flash image and
Hi Folks,
I believe that every Versatile Express board user would agree that
booting Linux kernel on it is "slightly" more complex than on, say,
Beagle...
I wrote a short text describing how do I do this:
https://wiki.linaro.org/PawelMoll/BootingVEMadeEasy
The interesting bit may be lack of U-b
> If you're flooding the system with USB traffic, enlargening the
> FIFO size won't help. Making the FIFO larger just decreases the
> _interrupt_ _latency_ requirements. It doesn't mean you can
> cope with the amount of data being transferred.
On VE both ISP and MMCI are sharing the same static
> My final mail on this subject.
Ah, and I was really enjoying our pleasant discussion...
> Take a mainline kernel. Apply the attached three patches. MMC
> will then work without any problems. No hacks required. There is
> *absolutely* *no* need to waste time with hardware modifications.
>
>
> Given that the problem is already fixed via a set of patches, I see
> no reason to mess about with the hardware, thereby making the driver
> more complicated for *no* benefit.
There will be virtually no change in the driver - all required stuff is already
there. See the STE UX500 variant - they
> I don't think enlarging the FIFO will help too much. The issue is
> whether the CPU can keep up with the data rate coming off the card.
> If it can't, then no matter how large the FIFO is, it will
> eventually overflow.
Yes, I realize that. But so far the only time when problem happens is the
> Wouldn't the ultimate solution be to simply use FIQs to service the
> MMC FIFO?
The ultimate solution is to super-size FIFO ;-) It's not impossible (as the
motherboard peripherals live in a FPGA), but according to our board people may
be tricky due to the MMCI design (it's just ancient, that'
A word of comment...
At least some of the Linaro file system images are running irqbalance
daemon, which will most likely play with MMC and USB interrupts
affiliation in runtime. To prevent it from doing so,
/etc/default/irqbalance should contain this line:
export IRQBALANCE_BANNED_INTERRUPT
the above sizes are with or without kernel?
Without.
Anyone knows how
compression of cramfs compares to tar.gz? e.g. can we compare those
sizes directly to our gzipped tarballs?
I did a quick exercise of uncramfs-ing and tar-gz-ipping the v7
versions back. Results:
49164288 filesystem_bin
FIFO under/overruns in the result - can be mitigated on
SMP system by distributing interrupts handling for these peripherals
between cores.
With this, the MMC card clock can be safely (at least it looks like
it) increased to 1.5MHz, improving performance.
Signed-off-by: Pawel Moll
---
arch/arm
* Download Size: 64M
* Download size with OMAP3 hwpack: 100M
The current thoughts are to cut this image down as much as possible
whilst still retaining the ability to boot to a command prompt. The
new image would be a 'nano' image and would be useful for verifying
that the hardware boots.
Yes,
> Texas Instruments X-Loader 1.4.4ss (Sep 30 2010 - 14:44:32)
> Beagle xM Rev A
> Reading boot sector
> not there
> u-boot.bin not found or blank nand contents - attempting serial boot . . .
> Any clue?
Just a thought - looks like your NAND got corrupted... Can you try to
boot your board holding
> Thats for Michael to do but for the meantime I'll added explicit
> download links on the https://wiki.linaro.org/Releases/1011 page.
Looks great - probably it's an even better solution than what I
suggested before.
Cheers!
Paweł
___
linaro-dev ma
> For instructions on obtaining and installing the release, you can
> visit https://wiki.linaro.org/Releases/1011/Final and click on the
> link under "Instructions"
> All this can be found by following links from "Getting started" on
> http://www.linaro.org/ ...
Well, can it? ;-)
What I see is t
> You were so close. https://wiki.linaro.org/Releases has instructions on how
> to obtain and use the Linaro images.
Oh sure! Just to be clear - I found it before, searching wiki. But this
time I just tried to pretend a fresher - say one of my Olympia
colleagues - and follow the big links :-)
>
> There's a "get started" link on the new http://www.linaro.org/ page.
> It could be clearer, but I think it's better than what used to be there.
> Any help?
Oh, it's much better only, if only with the big "Downloads" link on the
frontpage :-)
The only thing I could complain now about is that I d
60 matches
Mail list logo
