== Progress ==
* Boot Android with u-boot on ARMv8 SoC (CARD-1049: 20 %)
* 14.05 Android release (DEVPLAT-99: 30%)
* Fix CI issues on ARMv7 LSK premerge CI - 10%.
== Plans ==
* Boot Android with u-boot on ARMv8 SoC (CARD-1049)
* Build Linaro Android on Ubuntu 14.04 (DEVPLAT-218)
== Issues ==
Was on Leave on 26th and 27th due to an emergency.
== Progress ==
* Release 14.05 166% (one holiday and one vacation day went *poof*)
== Plans ==
* Bug triage
== Issues ==
* Release slipped due to cbuildv2 and aarch64 problems
Hello,
I ran powerdebug on i386 (ubuntu 13.04) and it seems its outputting wrong
information in "Sensors" info page. Suspects are colored blue below -
# sudo ./powerdebug
PowerDebug 0.7.2 Clocks Regulators Sensors Gpio
Name Value
coretemp
temp1_crit_alarm 0.0
temp3_input 34.0
temp3_label 34.0 ----> This seems incorrect
temp2_crit_alarm 0.0
temp1_crit 99.0
temp2_crit 99.0
temp3_crit 99.0
temp4_crit 99.0
temp5_crit 99.0
temp4_input 23.0
temp4_label 23.0 ----> This seems incorrect
temp3_crit_alarm 0.0
temp4_crit_alarm 0.0
temp5_input 34.0
temp5_label 34.0 ----> This seems incorrect
temp5_crit_alarm 0.0
temp1_input 34.0
temp1_label 34.0 ----> This seems incorrect
temp1_max 80.0
temp2_max 80.0
temp3_max 80.0
temp4_max 80.0
temp5_max 80.0
temp2_input 28.0
temp2_label 28.0 ----> This seems
incorrect
The contents of these files are not any legal integer value as expected -
# cat temp*_label
Physical id 0
Core 0
Core 1
Core 2
Core 3
The problem I think is in the below code in utils.c/file_read_value()-
ret = fscanf(file, format, value) == EOF ? -1 : 0;
We are comparing with EOF. In this case fscanf is returning zero. So this
check passes and returns success. So old value is retained in "value" from
previous read.
A simple fix would be to change the line to -
ret = fscanf(file, format, value) <= 0 ? -1 : 0;
Would you care to check?
diff --git a/utils.c b/utils.c
index 4d4b780..bfe2ba3 100644
--- a/utils.c
+++ b/utils.c
@@ -46,7 +46,7 @@ int file_read_value(const char *path, const char *name,
goto out_free;
}
- ret = fscanf(file, format, value) == EOF ? -1 : 0;
+ ret = fscanf(file, format, value) <= 0 ? -1 : 0;
fclose(file);
out_free:
--
Thanks,
-Meraj
On Wed, May 28, 2014 at 2:56 PM, Chetan Nanda <chetannanda(a)gmail.com> wrote:
> Hi,
>
> I am trying to setup an open-embedded environment for ARMv8.
> And following the steps as mentioned (building from source) @
> http://releases.linaro.org/latest/openembedded/aarch64/
>
> i.e. Done follwing so far
>
> mkdir openembedded cd openembedded git clone git://
> git.linaro.org/openembedded/jenkins-setup.git cd jenkins-setup git
> checkout release-14.04 cd .. sudo bash
> jenkins-setup/pre-build-root-install-dependencies.sh bash
> jenkins-setup/init-and-build.sh
>
> Last command, is giving me error like:
>
> *jenkins-setup/init-and-build.sh: line 50: cd: poky: No such file or directory
> jenkins-setup/init-and-build.sh: line 53: oe-init-build-env: No such file or directory
> jenkins-setup/functions.sh: line 70: conf/bblayers.conf: No such file or
> directory
> *
>
> Am I missing something? Please provide some pointer to debug this further.
>
> Seems running the following script is causing some issue with repo
*sudo bash pre-build-root-install-dependencies.sh*
When I do not run this script, atleast code fetching is started.
Thanks,
> Chetan Nanda
>
>
Hi!
I wanted to ask for help on the Foundation model which becomes really
slow after a while, to the point where it is not usable anymore.
Quite often I have to kill the model (Ctrl-C) and restart it, with
corrupted files on the root FS.
I am using the latest Foundation model, kernel image, instructions
from the release page [1] but it also happens with my own mainline
kernel.
[1] http://releases.linaro.org/latest/openembedded/aarch64/
Symptoms and observations:
- after a few minutes the system looks like it is hanging but still
reacts on ping, the shell is still active but everything related to
the filesystem hangs (top, free, compiler etc.),
- there is no sign of memory exhaustion or abnormal caching as seen
from a recurrent 'free'. 90% of the memory is free,
- the problem arrives faster when working in an NFS mounted dir,
- on the visualization webpage (localhost:2001) all cores are idle all
the time and the number of instructions executed is really low (about
30K insts/s),
- the exact same setup used to work fine until my machine crashed
(lost the home dir completely), now the problems happens with both AXF
and UEFI based boot.
Is there something you already observed, is there a cure (kernel or
root FS config etc.)?
Here is the startup script:
# cat boot_fvp_uefi.sh
#!/bin/sh
# Start Foundation model >= 5206 from the Image and img images
pidof Foundation_v8 > /dev/null && echo -n 'Foundation_v8 already
running' && exit
IMAGE=vexpress64-openembedded_lamp-armv8-gcc-4.8_20140417-630.img
exec Foundation_v8 \
--cores=2 \
--network bridged \
--block-device $IMAGE \
--no-secure-memory \
--visualization \
--gicv3 \
--data=bl1.bin@0x0 \
--data=uefi_fvp-base.bin@0x8000000
Any feedback welcome!
Cheers,
Jean
Hi,
I've been having this issue with latest binary Linaro 2014.04 toolchain from
http://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-a…
It comes with own sysroot, but linker fails to locate /lib/ld-linux-armhf.so.3
$ make
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o nvs.o nvs.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o misc_cmds.o misc_cmds.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o calibrator.o calibrator.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o plt.o plt.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o wl18xx_plt.o wl18xx_plt.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o ini.o ini.c
arm-linux-gnueabihf-gcc -L/tmp/lib/ nvs.o misc_cmds.o calibrator.o plt.o wl18xx_plt.o ini.o -lm -lnl-3 -lnl-genl-3 -o calibrator
/opt/linaro-2014.04/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/ld-linux-armhf.so.3
collect2: error: ld returned 1 exit status
Makefile:26: recipe for target 'all' failed
make: *** [all] Error 1
And when I pass my own sysroot, it works fine.
Is it supposed to work as a standalone toolchain with its own bundled sysroot?
Thanks.
--
Denys
Hi,
What is the difference between cpufreq policy and governors?
Are there a different cpufreq policy structure created for each cpu?
Will policy structure change when governor changes or when will it change?
thanks,
ryan