Failure to generate beagle_sd.img using linaro-media-create on Ubuntu 12.04 (64-bit)
Hi all, Below is the link for the bug-id (Bug #1135454 ) created for the issue "failure to generate beagle_sd.img using linario-media-create on ubuntu 12.04 on 64bit OS". https://bugs.launchpad.net/linaro-image-tools/+bug/1135454 Thanks & Regards RAJ KIRAN From: Rajkiran Mulugu Sent: Thursday, February 28, 2013 11:57 To: Fathi Boudra Cc: James Tunnicliffe; Amar Shankar; Prasad Raju; linaro-dev@lists.linaro.org Subject: RE: Unable to install svn on Ubuntu 12.04 (64-bit) Hi Fathi Boudra, We tried with below commands but we are getting error as follows : 1.)Getting from the Ubuntu package: sudo add-apt-repository ppa:linaro-maintainers/tools sudo apt-get update sudo apt-get install linaro-image-tools 2.)Creating the u-boot + Linux Linaro image: mkdir $(WORKROOT)/beagle_image && cd $(WORKROOT)/beagle_image wget http://releases.linaro.org/platform/linaro-m/hwpacks/final/hwpack_linaro-omap3_20101109-1_armel_supported.tar.gz wget http://releases.linaro.org/platform/linaro-m/headless/release-candidate/linaro-m-headless-tar-20101101-0.tar.gz sudo linaro-media-create --image_file beagle_sd.img --dev beagle --binary linaro-m-headless-tar-20101101-0.tar.gz --hwpack hwpack_linaro-omap3_20101109-1_armel_supported.tar.gz Installing (linaro-hwpack-install) hwpack_linaro-omap3_20101109-1_armel_supported.tar.gz in target rootfs. Unpacking hardware pack ...Done Updating apt package lists ... Ign file: ./ Release.gpg Ign file:/tmp/tmp.6XUobqnK3P/unpacked/pkgs/ ./ Translation-en Ign file: ./ Release Ign file: ./ Packages Get:1 http://ppa.launchpad.net maverick Release.gpg [316B] Ign http://ppa.launchpad.net/linaro-maintainers/overlay/ubuntu/ maverick/main Translation-en Ign http://ports.ubuntu.com maverick Release.gpg Ign http://ports.ubuntu.com/ maverick/main Translation-en Ign http://ports.ubuntu.com/ maverick/universe Translation-en Ign http://ports.ubuntu.com maverick-security Release.gpg Ign http://ports.ubuntu.com/ maverick-security/main Translation-en Ign http://ports.ubuntu.com/ maverick-security/universe Translation-en Ign http://ports.ubuntu.com maverick-updates Release.gpg Ign http://ports.ubuntu.com/ maverick-updates/main Translation-en Ign http://ports.ubuntu.com/ maverick-updates/universe Translation-en Ign http://ports.ubuntu.com maverick-proposed Release.gpg Get:2 http://ppa.launchpad.net maverick Release [9762B] Ign http://ports.ubuntu.com/ maverick-proposed/main Translation-en Ign http://ports.ubuntu.com/ maverick-proposed/universe Translation-en Ign http://ports.ubuntu.com maverick Release Ign http://ports.ubuntu.com maverick-security Release Ign http://ports.ubuntu.com maverick-updates Release Ign http://ports.ubuntu.com maverick-proposed Release Ign http://ports.ubuntu.com maverick/main armel Packages/DiffIndex Get:3 http://ppa.launchpad.net maverick/main armel Packages [11.7kB] Ign http://ports.ubuntu.com maverick/universe armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-security/main armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-security/universe armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-updates/main armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-updates/universe armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-proposed/main armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick-proposed/universe armel Packages/DiffIndex Ign http://ports.ubuntu.com maverick/main armel Packages Ign http://ports.ubuntu.com maverick/universe armel Packages Ign http://ports.ubuntu.com maverick-security/main armel Packages Ign http://ports.ubuntu.com maverick-security/universe armel Packages Ign http://ports.ubuntu.com maverick-updates/main armel Packages Ign http://ports.ubuntu.com maverick-updates/universe armel Packages Ign http://ports.ubuntu.com maverick-proposed/main armel Packages Ign http://ports.ubuntu.com maverick-proposed/universe armel Packages Err http://ports.ubuntu.com maverick/main armel Packages 404 Not Found Err http://ports.ubuntu.com maverick/universe armel Packages 404 Not Found Err http://ports.ubuntu.com maverick-security/main armel Packages 404 Not Found Err http://ports.ubuntu.com maverick-security/universe armel Packages 404 Not Found Err http://ports.ubuntu.com maverick-updates/main armel Packages 404 Not Found Err http://ports.ubuntu.com maverick-updates/universe armel Packages 404 Not Found Err http://ports.ubuntu.com maverick-proposed/main armel Packages 404 Not Found Err http://ports.ubuntu.com maverick-proposed/universe armel Packages 404 Not Found Fetched 21.8kB in 3s (6379B/s) W: Failed to fetch http://ports.ubuntu.com/dists/maverick/main/binary-armel/Packages.gz 404 Not Found W: Failed to fetch http://ports.ubuntu.com/dists/maverick/universe/binary-armel/Packages.gz 404 Not Found W: Failed to fetch http://ports.ubuntu.com/dists/maverick-security/main/bina
Re: [PATCH 1/5] clk: allow reentrant calls into the clk framework
On 28 February 2013 05:49, Mike Turquette wrote:
> Reentrancy into the clock framework from the clk.h api is highly
> desirable. This feature is necessary for clocks that are prepared and
> unprepared via i2c_transfer (which includes many PMICs and discrete
> audio chips) and it is also necessary for performing dynamic voltage &
> frequency scaling via clock rate-change notifiers.
>
> This patch implements reentrancy by adding a global atomic_t which
> tracks the context of the current caller. Context in this case is the
> return value from get_current(). The clk.h api implementations are
> modified to first see if the relevant global lock is already held and if
> so compare the global context (set by whoever is holding the lock)
> against their own context (via a call to get_current()). If the two
> match then this function is a nested call from the one already holding
> the lock and we procede. If the context does not match then procede to
> call mutex_lock and busy-wait for the existing task to complete.
>
> Thus this patch set does not increase concurrency for unrelated calls
> into the clock framework. Instead it simply allows reentrancy by the
> single task which is currently holding the global clock framework lock.
>
> Thanks to Rajagoapl Venkat for the original idea to use get_current()
> and to David Brown for the suggestion to replace my previous rwlock
> scheme with atomic operations during code review at ELC 2013.
>
> Signed-off-by: Mike Turquette
> Cc: Rajagopal Venkat
> Cc: David Brown
> ---
> drivers/clk/clk.c | 254
> ++---
> 1 file changed, 185 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index fabbfe1..b7d6a0a 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -19,9 +19,11 @@
> #include
> #include
> #include
> +#include
>
> static DEFINE_SPINLOCK(enable_lock);
> static DEFINE_MUTEX(prepare_lock);
> +static atomic_t context;
>
> static HLIST_HEAD(clk_root_list);
> static HLIST_HEAD(clk_orphan_list);
> @@ -433,27 +435,6 @@ unsigned int __clk_get_prepare_count(struct clk *clk)
> return !clk ? 0 : clk->prepare_count;
> }
>
> -unsigned long __clk_get_rate(struct clk *clk)
> -{
> - unsigned long ret;
> -
> - if (!clk) {
> - ret = 0;
> - goto out;
> - }
> -
> - ret = clk->rate;
> -
> - if (clk->flags & CLK_IS_ROOT)
> - goto out;
> -
> - if (!clk->parent)
> - ret = 0;
> -
> -out:
> - return ret;
> -}
> -
> unsigned long __clk_get_flags(struct clk *clk)
> {
> return !clk ? 0 : clk->flags;
> @@ -524,6 +505,35 @@ struct clk *__clk_lookup(const char *name)
> return NULL;
> }
>
> +/*** locking & reentrancy ***/
> +
> +static void clk_fwk_lock(void)
> +{
> + /* hold the framework-wide lock, context == NULL */
> + mutex_lock(&prepare_lock);
> +
> + /* set context for any reentrant calls */
> + atomic_set(&context, (int) get_current());
> +}
> +
> +static void clk_fwk_unlock(void)
> +{
> + /* clear the context */
> + atomic_set(&context, 0);
> +
> + /* release the framework-wide lock, context == NULL */
> + mutex_unlock(&prepare_lock);
> +}
> +
> +static bool clk_is_reentrant(void)
> +{
> + if (mutex_is_locked(&prepare_lock))
> + if ((void *) atomic_read(&context) == get_current())
> + return true;
> +
> + return false;
> +}
> +
> /***clk api***/
>
> void __clk_unprepare(struct clk *clk)
> @@ -558,9 +568,15 @@ void __clk_unprepare(struct clk *clk)
> */
> void clk_unprepare(struct clk *clk)
> {
> - mutex_lock(&prepare_lock);
> + /* re-enter if call is from the same context */
> + if (clk_is_reentrant()) {
> + __clk_unprepare(clk);
> + return;
> + }
> +
> + clk_fwk_lock();
> __clk_unprepare(clk);
> - mutex_unlock(&prepare_lock);
> + clk_fwk_unlock();
> }
> EXPORT_SYMBOL_GPL(clk_unprepare);
>
> @@ -606,10 +622,16 @@ int clk_prepare(struct clk *clk)
> {
> int ret;
>
> - mutex_lock(&prepare_lock);
> - ret = __clk_prepare(clk);
> - mutex_unlock(&prepare_lock);
> + /* re-enter if call is from the same context */
> + if (clk_is_reentrant()) {
> + ret = __clk_prepare(clk);
> + goto out;
> + }
>
> + clk_fwk_lock();
> + ret = __clk_prepare(clk);
> + clk_fwk_unlock();
> +out:
> return ret;
> }
This above code seems fine to me. The slowpath functions using the
prepare lock would be reentrant with this change, which is really
great.
> EXPORT_SYMBOL_GPL(clk_prepare);
> @@ -650,8 +672,27 @@ void clk_disable(struct clk *clk)
> {
> unsigned long flags;
>
> + /* must check both the global spinlock and the global mutex */
> + if (spin_is_locked(&enable_lock)
Re: [ANNOUNCE] linux-linaro kernel schedule for 13.02
Hi Andrey, Do you have any plans to do another respin of the ll tree before final 13.02? Regards, Liviu On Sun, Feb 10, 2013 at 06:03:49PM +, Andrey Konovalov wrote: > Greetings, > > llct has been moved to v3.8-rc7 (tag llct-20130210.0). > If the ll topics would be ready, on Feb 11, in the evening GMT there > will be the ll rebuild based on llct-20130210.0. > > Thanks, > Andrey > > On 02/04/2013 09:51 PM, Andrey Konovalov wrote: > > Greetings, > > > > The current 13.02 schedule has been published on wiki: > > > > https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule > > > > llct rebuild is planned later today. > > > > The 13.02 release would be v3.8-rc8 based (tentative). > > > > Please make sure that requests to add new topics (with the git branch to > > pull from) have been sent to me, or will be sent as soon as the topic is > > ready. I would appreciate a "heads up" like information on the new > > topics which are more complex than a couple patches on top of mainline. > > For the moment I am aware of the kvm topic only. Anything else? > > > > > > Thanks, > > Andrey > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] linux-linaro kernel schedule for 13.02
Hi Liviu, On 02/28/2013 02:18 PM, Liviu Dudau wrote: Hi Andrey, Do you have any plans to do another respin of the ll tree before final 13.02? I do plan to update the ll tree later today to pull a fix from one of the ll topics. But this update won't get into 13.02 release: the linux-linaro kernel is released one week before the "whole" release. So the 13.02 linux-linaro kernel release happened last Friday, Feb 22. Thanks, Andrey Regards, Liviu On Sun, Feb 10, 2013 at 06:03:49PM +, Andrey Konovalov wrote: Greetings, llct has been moved to v3.8-rc7 (tag llct-20130210.0). If the ll topics would be ready, on Feb 11, in the evening GMT there will be the ll rebuild based on llct-20130210.0. Thanks, Andrey On 02/04/2013 09:51 PM, Andrey Konovalov wrote: Greetings, The current 13.02 schedule has been published on wiki: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule llct rebuild is planned later today. The 13.02 release would be v3.8-rc8 based (tentative). Please make sure that requests to add new topics (with the git branch to pull from) have been sent to me, or will be sent as soon as the topic is ready. I would appreciate a "heads up" like information on the new topics which are more complex than a couple patches on top of mainline. For the moment I am aware of the kvm topic only. Anything else? Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Power Management WG schedule for LCA13
Hi, Please find a link[1] to some of the things we plan to discuss and work on in Hong Kong next week. If you're interested in some of these topics and are attending in person, please come and say hello. See you in Hong Kong! Regards, Amit --- PMWG Tech Lead, Linaro [1] https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/HK_LCA2013 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Power Management WG schedule for LCA13
On Thu, Feb 28, 2013 at 4:56 PM, Amit Kucheria wrote: > Hi, > > Please find a link[1] to some of the things we plan to discuss and > work on in Hong Kong next week. > > If you're interested in some of these topics and are attending in > person, please come and say hello. And in case you aren't able to make it in person, please make sure to participate remotely[2]. :) > See you in Hong Kong! > > Regards, > Amit > --- > PMWG Tech Lead, Linaro > > [1] https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/HK_LCA2013 [2] http://www.linaro.org/connect/remote-participation ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9 2/2] video: drm: exynos: Add pinctrl support to fimd
On Thu, Feb 28, 2013 at 11:03:57PM +0100, Sylwester Nawrocki wrote: > Please just use IS_ERR(), let's stop this IS_ERR_OR_NULL() insanity. Yes, indeed. On that topic (and off-topic for this thread, sorry) I've committed a set of patches to remove most users of IS_ERR_OR_NULL() from arch/arm. These are the last remaining ones there - and I don't want to see any more appearing: arch/arm/plat-samsung/clock.c: if (IS_ERR_OR_NULL(clk)) arch/arm/plat-samsung/clock.c: if (!IS_ERR_OR_NULL(clk) && clk->ops && clk->ops->round_rate) arch/arm/plat-samsung/clock.c: if (IS_ERR_OR_NULL(clk)) arch/arm/plat-samsung/clock.c: if (IS_ERR_OR_NULL(clk) || IS_ERR_OR_NULL(parent)) arch/arm/mach-imx/devices/platform-ipu-core.c: if (IS_ERR_OR_NULL(imx_ipu_coredev)) arch/arm/mach-imx/devices/platform-ipu-core.c: if (IS_ERR_OR_NULL(imx_ipu_coredev)) arch/arm/kernel/smp_twd.c: * We use IS_ERR_OR_NULL() here, because if the clock stubs arch/arm/kernel/smp_twd.c: if (!IS_ERR_OR_NULL(twd_clk)) They currently all legal uses of it - though I'm sure that the samsung clock uses can be reduced to just IS_ERR(). The IMX use looks "valid" in that imx_ipu_coredev really can be an error pointer (on failure) or NULL if the platform device hasn't yet been created. The TWD one is explained in the comments in the code (if people had to write explanations for using IS_ERR_OR_NULL(), we'd probably have it used correctly!) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9 2/2] video: drm: exynos: Add pinctrl support to fimd
On 02/28/2013 05:12 AM, Vikas Sajjan wrote:
Adds support for pinctrl to drm fimd
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e323cf9..21ada8d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -879,6 +880,7 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
struct resource *res;
+ struct pinctrl *pctrl;
int win;
int ret = -EINVAL;
@@ -897,6 +899,13 @@ static int fimd_probe(struct platform_device *pdev)
DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
return ret;
}
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR("failed: devm_pinctrl_get_select_default():"
+ "%d\n", PTR_RET(pctrl));
+ return PTR_ERR(pctrl);
In situations like this I really side attempts to remove IS_ERR_OR_NULL()
macro from the kernel completely ([1], [2]). What is the value returned
from
fimd_probe() when devm_pinctrl_get_select_default() returns NULL ?
What header file have you added to use struct pinctrl in this driver ?
Is this data structure fully declared there ? Are drivers supposed to
dereference struct pinctrl at all ?
I believe original intention was to have the pinctrl handle as an opaque
cookie, and as long as it is used with the pinctrl API only and tested
for errors with *IS_ERR()*, everything should be fine. The pinctrl API
should handle any NULL pointer as it returned it to a driver in the first
place.
Please just use IS_ERR(), let's stop this IS_ERR_OR_NULL() insanity.
+ }
+
} else {
pdata = pdev->dev.platform_data;
if (!pdata) {
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140543.html
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg78030.html
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 13.01 Versatile Express Android build unstable
Thanks for the suggestions, Jon! Step 1 (erasing the flash) didn't make much difference. However step 2 (new UEFI from 13.02) seemed to get me past the kernel hang and I was able to boot up Android. However, even this is either a hit or a miss, booting sometimes and hanging other times. Hopefully, later versions of Linaro releases should fare better. Regards, Dinesh On Wed, Feb 27, 2013 at 12:52 AM, Jon Medhurst (Tixy) wrote: > On Tue, 2013-02-26 at 11:27 -0800, D D wrote: > > > Yes, I have tried both the config in the release notes as well as > > configurations to boot A7. > > The configurations to boot A7 hang while executing the BOOTSCRIPT. > > The release note configurations get past that state, boot up the > > kernel and hang as shown in this thread. > > > As a first step, I am just trying to get the release note > > configuration working without the hang. > > I've just tested out the 13.01 release notes again by following them to > recreate and replacing my TC2's firmware and configure UEFI; and that > works for me to boot a fresh 13.01 Android image from an SD card. > > If you aren't having any success with that configuration, then further > things I can suggest are: > > 1) To make sure any firmware changes have really taken hold, try erasing > all the NOR flash. You can do this from the bootloader Cmd> prompt by > entering "flash" to get a Flash> prompt, then enter 'eraseall'. After > the flash has finished erasing, reboot the board and the firmware will > be reprogrammed again. > > 2) In case there is an error in the UEFI config (I know it's a bit > fiddly to enter) then you could try the Linaro firmware zip we have for > the forthcoming 13.02 release [1]. This has a UEFI version which ignores > the SD card UUID and so doesn't need reconfiguring every time you create > a new disk image. It also has the benefit that the default boot config > will work without you needing to manually set anything. If you try this > latest UEFI, I suggest you also erase the flash as above, to make extra > sure there is no old config left over from a previous version. > > [1] > https://wiki.linaro.org/ARM/VersatileExpress?action=AttachFile&do=get&target=vemsd-armlt-20130225-001.zip > > -- > Tixy > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: arm64 Debian/Ubuntu port image available
Nice work, Wookey! If experience cross-building for armhf is any guide, all you need for NSS is a host build of shlibsign; see https://github.com/mkedwards/crosstool-ng/blob/master/patches/nss/3.12.10/0001-Modify-shlibsign-wrapper-for-cross-compilation.patch. There's also scriptage in that repo for the build sequence and cross parameters: https://github.com/mkedwards/crosstool-ng/blob/master/scripts/build/cross_me_harder/510-nss.sh. It's ugly in places (cross pkgconfig was kind of wonky at the time) but may help you get past NSS and on to apt. Cheers, - Michael On Feb 26, 2013 6:11 PM, "Wookey" wrote: > State of the Debian/Ubuntu arm64 port > = > > *** Arm64 lives! *** > > Executive summary > - > > * There is now a bootable (raring) image to download and run > * Everything has been rebuilt against glibc 2.17 so it works > * A bit more work is needed to make the rootfs useable as a native buildd > * Multiarch crossbuilding and the build-profile mechanism is mature > enough to cross-build > a port from scratch (this is a big deal IMHO) > * All packages, sources and tools are in a public repo and this work > should be reproducible. > * This image is fully multiarched so co-installing armhf for a > 64/32 mix should work nicely, as should multiarch crossbuilding to > legacy x86 architectures. :-) (but I haven't tried that yet...) > > > * Linaro wants 'the distros' to take this work forward from here so > people interested in > Debian and Ubuntu on 64-bit arm hardware need to step up and help out. > > > Bootable images > --- > > A milestone was reached this week: Enough packages were built for arm64 to > debootstrap an > image which booted to a prompt! After a bit of fettling (and switching to > multistrap) I got > an image with all the packages configured which boots with upstart to a > login prompt (I > admit, I did get quite excited about this, as it represents the coming > together of nearly 3 > years work on multiarch, crossbuilding, bootstrapping, cyclic dependencies > and arm64 :-) > > The images are available for download: > http://wiki.debian.org/Arm64Port#Pre-built_Rootfs > And there are destructions there for making your own. > > All these packages were cross-built on raring, untangling cyclic > dependencies with build > profiles (see wiki.debian.org/DebianBootstrap for how that works), making > this the first > (non x86) self-bootstrapped debian port ever (so far as I know). All (?) > previous ports have > been done using something else like OpenEmbedded (armel, armhf), > RedHat/HardHat (arm, alpha, > mips), something IBMy (s390) to get an initial linux rootfs on which > debian packages are > built. > > The new bootstrap process is (almost) just a list of sbuild commands. In > practice there are > still a few rough edges around cross- build-dependencies so of the 140 > packages needed for > the bootstrap, 9 had to be built manually with 'dpkg-buildpackage -aarm64 > -d' (to skip > build-dep checks) instead of 'sbuild --host arm64 '. > > The current bootstrap packageset status is here: > > http://people.linaro.org/~wookey/buildd/raring-arm64/status-bootstrap.html > > There is no armv8 (arm64/aarch64) hardware available yet, so this image > can currently only > be run in a model. ARM provide a free-beer prorietary 'Foundation model' > so we do have > someting to test with. It's sluggish but perfectly useable. Booting the > images takes a > couple of minutes on my fairly average machine. > > The images are using the Linaro OE release kernels which seem to work fine > for this purpose. > Thanks to Marcin for modified bootloader lines in .axf files. > > > > Image status > > > I was impressed that things basically 'just worked' on first boot. There > is of course plenty > of breakage, I'm sure, and I haven't looked very hard yet, but it's a lot > better than I > expected after months of just building stuff and testing nothing. (Things > that are poorly: > nano can't parse it's own syntax-coluring files for example, and multiarch > perl has the > wrong @INC path compiled in; I'm sure there is more). Consider this > alpha-grade until it's > been used a bit more. > > Things that are not yet built which would make the images a lot more > useful are apt and a > dhcp client. apt needs gnupg needs curl needs nss. The nss cross-build > needs fixing to > unbung that. A debian chroot without apt turns out to be disappointing > quite quickly :-) > Expect an updated image with more packages very soon. > > > Multiarch crossbuilding > --- > > It's really nice to have building and crossbuilding using exactly the same > mechanisms > and tools, with all files having one canonical location, and dependency > mechanisms that > are reliable. The more I've used this, the more I've been impressed by it. > There is > still work to do to expand the set of cross-buildable stuff, but it's a > solid base to > wo
[PATCH] arm64: add support for 8250/16550 earlyprintk
This patch adds support for using earlyprintk with 8250/16550 UART ports.
The 8250/16550 UART can either have 8-bit or 32-bit aligned registers which is
HW vendor dependent.
Kernel args for 8-bit aligned regs: earlyprintk=uart8250-8bit,
Kernel args for 32-bit aligned regs: earlyprintk=uart8250-16bit,
Signed-off-by: Anup Patel
---
arch/arm64/kernel/early_printk.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/kernel/early_printk.c b/arch/arm64/kernel/early_printk.c
index 7e320a2..d57f300 100644
--- a/arch/arm64/kernel/early_printk.c
+++ b/arch/arm64/kernel/early_printk.c
@@ -24,11 +24,32 @@
#include
#include
+#include
static void __iomem *early_base;
static void (*printch)(char ch);
/*
+ * 8250/16550 (8-bit aligned registers) single character TX.
+ */
+static void uart8250_8bit_printch(char ch)
+{
+ while (!(readb_relaxed(early_base + UART_LSR) & UART_LSR_THRE))
+ ;
+ writeb_relaxed(ch, early_base + UART_TX);
+}
+
+/*
+ * 8250/16550 (32-bit aligned registers) single character TX.
+ */
+static void uart8250_32bit_printch(char ch)
+{
+ while (!(readl_relaxed(early_base + (UART_LSR << 2)) & UART_LSR_THRE))
+ ;
+ writel_relaxed(ch, early_base + (UART_TX << 2));
+}
+
+/*
* PL011 single character TX.
*/
static void pl011_printch(char ch)
@@ -47,6 +68,8 @@ struct earlycon_match {
static const struct earlycon_match earlycon_match[] __initconst = {
{ .name = "pl011", .printch = pl011_printch, },
+ { .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
+ { .name = "uart8250-32bit", .printch = uart8250_32bit_printch, },
{}
};
--
1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/5] clk: notifier handler for dynamic voltage scaling
Mike Turquette writes: > > Dynamic voltage and frequency scaling (dvfs) is a common power saving > technique in many of today's modern processors. This patch introduces a > common clk rate-change notifier handler which scales voltage > appropriately whenever clk_set_rate is called on an affected clock. For DVFS to be useful, we might need to be notified on "clk_enable" and "clk_disable" since there are cases that driver will disable or enable clock directly but not calling clk_set_rate. Do you agree that notifier in common clock need to be improved? > > There are three prerequisites to using this feature: > > 1) the affected clocks must be using the common clk framework > 2) voltage must be scaled using the regulator framework > 3) clock frequency and regulator voltage values must be paired via the > OPP library > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
