The following changes since commit b99670db3d6a43efe6d55ce92d7a227fb1ff41f7:
LINARO: Linaro-2.6.35.1006.11 (2010-09-16 17:17:17 -0600)
are available in the git repository at:
git://git.linaro.org/ubuntu/linux-meta-linaro.git master
John Rigby (1):
LINARO: Linaro-2.6.35.1007.12
meta-source/debian/changelog | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
Hi.
I have a Cortex A9 vexpress board and I've been trying some of the headless daily builds as described here :
https://wiki.linaro.org/Platform/QA/TestCases/HeadlessVexpress.
The instructions are based around the MMC card with uboot, kernel and rootfs all loaded via this interface.
I've had mixed results. When the box completes the boot the basic systems seem to work ok (I can get an IP and poke the filesystem). It still takes several minutes to get to a prompt as mentioned on the wiki page.
It happens quite often that the box does not get to a prompt at all. It fails to read the MMC properly. Below is two separate cases where reading the partition table fails. In the first case it finds one partition and in the second case it fails to find any partitions. The boot monitor has no problem reading uboot, kernel or initrd from the MMC when writing to internal FLASH.
I've also tried a different SD card with similar results. Sometimes it works fine and other times it reports I/O errors. I've tried the daily builds for 6, 8 and 10 October. Is this a known issue?
-----
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SD card at address 8fe4
mmcblk0: mmc0:8fe4 SD02G 1.84 GiB
mmcblk0:
Freeing init memory: 160K
p1ding, please wait...
p2
udev[497]: starting version 163
port 1 high speed
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
usb 1-1: new high speed USB device using isp1760 and address 2
port 1 high speed
usb 1-1: New USB device found, idVendor=0471, idProduct=3526
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1: Product: ISP1520
usb 1-1: Manufacturer: Philips Semiconductors
mmcblk0: retrying using single block read
mmcblk0: error -5 transferring data, sector 0, nr 8, card status 0xb00
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 3 ports detected
end_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on device mmcblk0, logical block 0
-----
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SD card at address 8fe4
mmcblk0: mmc0:8fe4 SD02G 1.84 GiB
mmcblk0:
TCP cubic registered
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
NET: Registered protocol family 17
port 1 high speed
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0
Registering SWP/SWPB emulation handler
rtc-pl031 mb:rtc: setting system clock to 2010-10-11 10:49:28 UTC (1286794168)
usb 1-1: new high speed USB device using isp1760 and address 2
Freeing init memory: 160K
port 1 high speed
mmcblk0: retrying using single block read
Loading, please wait...
usb 1-1: New USB device found, idVendor=0471, idProduct=3526
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
udev[493]: starting version 163
Begin: Loading eusb 1-1: Product: ISP1520
mmcblk0: error -5 transferring data, sector 2, nr 6, card status 0x900
end_request: I/O error, dev mmcblk0, sector 2
ssential driversusb 1-1: Manufacturer: Philips Semiconductors
... done.
Begin: Runnimmcblk0: error -5 transferring data, sector 3, nr 5, card status 0x900
ng /scripts/initend_request: I/O error, dev mmcblk0, sector 3
-premount ... done.
Begin: Mounting root file system ... hub 1-1:1.0: USB hub found
hub 1-1:1.0: 3 ports detected
Begin: Running /scripts/local-tommcblk0: error -5 transferring data, sector 5, nr 3, card status 0xb00
p ... done.
end_request: I/O error, dev mmcblk0, sector 5
unable to read partition table
-----
Thanks,
Harry
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Should be of general interest to Linaro..
----- Forwarded message from Matt Zimmerman <mdz(a)canonical.com> -----
Date: Tue, 12 Oct 2010 09:48:42 +0100
From: Matt Zimmerman <mdz(a)canonical.com>
To: canonical-tech(a)lists.launchpad.net
Subject: [Canonical-tech] Visualizing reads, writes and alignment
User-Agent: Mutt/1.5.20 (2009-06-14)
http://rwmj.wordpress.com/2010/10/05/visualizing-reads-writes-and-alignment/
This looks like pretty cool stuff. Using a patch to qemu, these tools
generate a visualization of I/O showing the location and alignment of reads
and writes.
--
- mdz
----- End forwarded message -----
--
----------------------------------------------------------------------
Amit Kucheria, Kernel Engineer
----------------------------------------------------------------------
On 10 Oct 11, Vincent Guittot wrote:
> On 11 October 2010 10:58, Amit Kucheria <amit.kucheria(a)linaro.org> wrote:
> > On 10 Oct 11, Vincent Guittot wrote:
> >> Hi,
> >>
> >> Please find attached 3 patches for :
> >> - enabling cpuidle feature on MOP500 hrefp
> >> - making cpufreq stat available for powertop
> >> - adding debugfs clock tree for powerdebug
> >>
> >> These patches have been tested on the latest
> >> //git.linaro.org/bsp/st-ericsson/linux-2.6.34-ux500
> >>
> >> Vincent
> >
> > Thanks Vincent. So with these patches, the ux500 platform can be used with
> > cpufreq and cpuidle and works correctly with the powertop and powerdebug tools
> > we have?
> >
>
> Yes it is.
>
> > Is the same true for the ux500 code in mainline? Does it support cpufreq,
> > cpuidle?
> >
>
> Not yet. it's on going
>
> > Just a brief comment below, regarding the patch.
> >
> >> From 5bd1f1a5ecc7ce6d812215a474869fcf2e10c1e4 Mon Sep 17 00:00:00 2001
> >> From: Vincent Guittot <vincent.guittot(a)stericsson.com>
> >> Date: Mon, 11 Oct 2010 09:23:18 +0200
> >> Subject: [PATCH] cpufreq_getspeed can't return negative value
> >>
> >> ---
> >> arch/arm/mach-ux500/cpufreq.c | 4 +++-
> >> 1 files changed, 3 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-ux500/cpufreq.c b/arch/arm/mach-ux500/cpufreq.c
> >> index 4454a08..ea01240 100755
> >> --- a/arch/arm/mach-ux500/cpufreq.c
> >> +++ b/arch/arm/mach-ux500/cpufreq.c
> >> @@ -100,7 +100,9 @@ unsigned int u8500_getspeed(unsigned int cpu)
> >> case ARM_50_OPP: return freq_table[1].frequency;
> >> case ARM_100_OPP: return freq_table[2].frequency;
> >> default:
> >> - return -EINVAL;
> >> + /* During boot, the returned value is undefined */
> >> + /* In this case, we set the max frequency */
> >> + return freq_table[2].frequency;
> >
> > freq_table[2] will break if another frequency is added to the table. I
> > recommend defining something like a MAX_NUM_FREQ for the table and using that
> > in the driver.
> >
>
> The idea was to return the same value than ARM_100_OPP. I could map
> the default use case to the ARM_100_OPP one instead ?
Perhaps I'm being pedantic, but I prefer using names to hard-coded numbers.
So, something like a
enum freq {
ARM_50_OPP
ARM_100_OPP
}
used with
return freq_table[ARM_100_OPP].frequency
will continue to work even if you add ARM_25_OPP and ARM_75_OPP to the enum.
/Amit
Hi,
Please find attached 3 patches for :
- enabling cpuidle feature on MOP500 hrefp
- making cpufreq stat available for powertop
- adding debugfs clock tree for powerdebug
These patches have been tested on the latest
//git.linaro.org/bsp/st-ericsson/linux-2.6.34-ux500
Vincent
Hi All,
Purpose of this email is to debate on the pros and cons of having a common
ARM context save/restore code.
Currently each SOC has its own way of saving/restoring ARM registers and
there has been a proposal to have a common code for the same instead of
duplicating the same in different places.
Though it is technically possible to save/restore common ARM registers in a
common place, there are some constraints.
1. Each of the SOC would have it's own set of trustzone implementation which
means these registers have to be saved/restored in SOC specific code.
2. Some of the ARM registers (Aux ctrl etc) can be different for different
SOCs which means they cannot be handled in common code.
So it means that, in the middle of common code, there needs to be many
platform specific hooks so that right sequence is followed. This will make
the code more unredeable and difficult to debug and maintain.
Also I am just wondering is there any other ARM SOC apart from OMAP, which
saves/restores ARM registers in SW? Atleast I could not find such code in
opensource.
Regards
Vishwa
