[fedora-arm] Re: Introduction, Looking to help...

[Jon Masters]

On Wed, Jan 27, 2021 at 6:38 AM Peter Robinson  wrote:

Now Fedora Arm in a VM on an Apple M1 Mac is definitely something that
> I'd love to support, and while my time to actively hack on it of late
> has been limited, it's certainly something that I think is achievable
> in the short term as a step on the route to full bare metal
> enablement.
>

This one pretty much already just works. I plan to help out here.

Jon.
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Re: [Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting

[Jon Masters]

On 7/19/19 1:09 PM, Jon Masters wrote:
> On 7/4/19 6:12 PM, Jon Masters wrote:
> 
>> I think we have identified the root cause of the 32-bit builder issue.
>> Many thanks to Paul and Peter for assistance in debugging. Here's my
>> write-up, and we'll work with the vendor on a suitable mitigation to
>> workaround any errata:
>>
>> https://medium.com/@jonmasters_84473/debugging-a-32-bit-fedora-arm-builder-issue-73295d7d673d
> 
> The hardware vendor have reproduced what I believe to be an errata.
> Meanwhile, I've made a test kernel that forces CONFIG_HIGHPTE to off:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=36328838
> 
> With this kernel, you still get LPAE but leaf level PTEs are not
> allocated from high memory any longer. This is because I believe the
> errata to be caused by stage 1 page table walks in the guest trapping to
> stage 2 (hypervisor) for e.g. Access bit updates on the host. When those
> occur, I believe there is a truncation of the guest IPA (guest memory)
> address to 32-bits, but only for page table entry walks. Normal
> translation faults I think are unaffected by this (TBC).
> 
> Normally, we don't allocate PGDs (high level page table pieces) from
> high memory (we allocate those from kernel memory caches) but we DO
> allocate PTEs specifically from what might be high memory. Except when
> we force CONFIG_HIGHPTE to off. The patch I'm using is attached.
> 
> It's currently being tested. If it works, I'm curious for input on
> temporarily carrying this in Fedora. In theory it means an LPAE system
> could starve for PTEs if it has many many processes running, but in
> practice I'm willing to bet LPAE is mostly used by Fedora for the 32-bit
> builders and that few people would actually complain if we did this.

This stayed up for 3+ days. Eventually, there were a couple of faults
that I thought were a problem but it turns out that they weren't and
just generated noise on the host kernel log. So it looks good to go with
the hack that I proposed and that's going to be in Fedora's 5.2 kernel.

Detail:

The host saw a couple of exits due to speculative page walks in the
guest. It hit my previous logic due to S1 PTW but this time the HPFAR
was correct vs what we would expect due to the 32-bit range limit.

[359524.820107] JCM: WARNING: Mismatched FIPA and PA translation detected!
[359524.899630] JCM: Hyper faulting far: 0x40163000
[359524.955044] JCM: Guest faulting far: 0xb6dbbf48 (gfn: 0x4016)
[359525.025047] JCM: Guest TTBCR: 0xb5023500, TTBR0: 0x4c99ca80
[359525.092963] JCM: Guest PGD address: 0x4c99ca90
[359525.147312] JCM: Guest PGD: 0x58bf7003
[359525.193319] JCM: Guest PMD address: 0x58bf7db0
[359525.247671] JCM: Guest PMD: 0x40163003
[359525.293678] JCM: Guest PTE address: 0x40163dd8
[359525.348030] JCM: Guest PTE: 0x42367508fdf
[359525.401338] JCM: Manually translated as: 0xb6dbbf48->0x367508000
[359525.474465] JCM: Faulting IPA page: 0x40163000
[359525.528814] JCM: Faulting PTE page: 0x40163000
[359525.583166] JCM: *** debugging data ***
[359525.630215] JCM: FAR_EL2: 0xb6dbbf48
[359525.674133] JCM: HPFAR_EL2: 0x401630
[359525.718052] JCM: ESR_EL2: 0x828b
[359525.761972] JCM: FAR_EL1: 0x4f2e50005b89b4
[359525.812149] JCM: ESR_EL1: 0x20b
[359525.850852] JCM: *** debugging data ***
[359525.897899] JCM: Fault occurred while performing S1 PTW -fixing
[359525.969985] JCM: corrected fault_ipa: 0x40163000
[359526.026423] JCM: Corrected gfn: 0x4016
[359526.072427] JCM: handle access fault
[359526.116347] JCM: ret: 0x1

You can see the FAR reported pfn 4016 and that's what we expected, so
the above was just noise in my test kernel on the host monitoring a bit
too carefully and not needing to actually fix anything this time.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Re: [Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting

[Jon Masters]

On 7/4/19 6:12 PM, Jon Masters wrote:

> I think we have identified the root cause of the 32-bit builder issue.
> Many thanks to Paul and Peter for assistance in debugging. Here's my
> write-up, and we'll work with the vendor on a suitable mitigation to
> workaround any errata:
> 
> https://medium.com/@jonmasters_84473/debugging-a-32-bit-fedora-arm-builder-issue-73295d7d673d

The hardware vendor have reproduced what I believe to be an errata.
Meanwhile, I've made a test kernel that forces CONFIG_HIGHPTE to off:

https://koji.fedoraproject.org/koji/taskinfo?taskID=36328838

With this kernel, you still get LPAE but leaf level PTEs are not
allocated from high memory any longer. This is because I believe the
errata to be caused by stage 1 page table walks in the guest trapping to
stage 2 (hypervisor) for e.g. Access bit updates on the host. When those
occur, I believe there is a truncation of the guest IPA (guest memory)
address to 32-bits, but only for page table entry walks. Normal
translation faults I think are unaffected by this (TBC).

Normally, we don't allocate PGDs (high level page table pieces) from
high memory (we allocate those from kernel memory caches) but we DO
allocate PTEs specifically from what might be high memory. Except when
we force CONFIG_HIGHPTE to off. The patch I'm using is attached.

It's currently being tested. If it works, I'm curious for input on
temporarily carrying this in Fedora. In theory it means an LPAE system
could starve for PTEs if it has many many processes running, but in
practice I'm willing to bet LPAE is mostly used by Fedora for the 32-bit
builders and that few people would actually complain if we did this.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop
From 19908e5fe3e63ed2d39f0a8a9135f35fd428d766 Mon Sep 17 00:00:00 2001
From: Jon Masters 
Date: Thu, 18 Jul 2019 15:47:26 -0400
Subject: [PATCH] arm: make CONFIG_HIGHPTE optional without CONFIG_EXPERT

We will use this to force CONFIG_HIGHPTE off on LPAE for now

Signed-off-by: Jon Masters 
---
 arch/arm/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2bf1ce39a96d..e792b3e60095 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1644,9 +1644,9 @@ config HIGHMEM
 	  If unsure, say n.
 
 config HIGHPTE
-	bool "Allocate 2nd-level pagetables from highmem" if EXPERT
+	bool "Allocate 2nd-level pagetables from highmem"
 	depends on HIGHMEM
-	default y
+	default n
 	help
 	  The VM uses one page of physical memory for each page table.
 	  For systems with a lot of processes, this can use a lot of
-- 
2.17.2

___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Re: [Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting

[Jon Masters]

Hi fedora-arm,

I think we have identified the root cause of the 32-bit builder issue. Many 
thanks to Paul and Peter for assistance in debugging. Here's my write-up, and 
we'll work with the vendor on a suitable mitigation to workaround any errata:

https://medium.com/@jonmasters_84473/debugging-a-32-bit-fedora-arm-builder-issue-73295d7d673d

Jon.

-- 
Computer Architect


> On Jun 30, 2019, at 11:01, pwha...@redhat.com wrote:
> 
> Dear all,
> 
> You are kindly invited to the meeting:
>   Fedora ARM & AArch64 status meeting on 2019-07-02 from 15:00:00 to 16:00:00 
> UTC
>   At fedora-meetin...@irc.freenode.net
> 
> The meeting will be about:
> Fedora ARM & AArch64 weekly status meeting. 
> 
> More information available at:
> [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org/wiki/Architectures/ARM)
> 
> 
> Source: https://apps.fedoraproject.org/calendar/meeting/9431/
> 
> ___
> arm mailing list -- arm@lists.fedoraproject.org
> To unsubscribe send an email to arm-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Cloud image question regarding command line

[Jon Masters]

Hi Folks,

Any chance we can get the kernel command line for the Cloud images
updated to change the explicit provision of "console=" so that the
second one is "console=ttyAMA0..." and not "console=ttyS0..."?

I'm not sure who owns these, so figured I'd ask here. I'm playing with
F26 images under OpenStack (RDO) and they're booting fine. Couple of
issues that I'll followup on separately.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: KVM on Raspi3

[Jon Masters]

On 05/15/2017 11:48 AM, Marcin Juszkiewicz wrote:
> W dniu 15.05.2017 o 17:22, Jon Masters pisze:
>> Hi,
>>
>> I haven't looked into this, but the following merge for 4.12 got flagged
>> for followup:
>>
>> http://www.spinics.net/lists/kvm/msg149582.html
>>
>> Others might find this interesting. I guess it boots at EL2 these days
>> then - haven't played with the latest generation much - but I don't know
>> if there are additional weirdness beyond just the interrupt controller
>> setup (which is known to be very odd).
> 
> I read about KVM on rpi stuff some time ago. It required booting kernel
> on subset of cores and then running kvm on those 'not used' ones.

Indeed. I saw that. It just might be something else is in flight tho.


-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] KVM on Raspi3

[Jon Masters]

Hi,

I haven't looked into this, but the following merge for 4.12 got flagged for 
followup:

http://www.spinics.net/lists/kvm/msg149582.html

Others might find this interesting. I guess it boots at EL2 these days then - 
haven't played with the latest generation much - but I don't know if there are 
additional weirdness beyond just the interrupt controller setup (which is known 
to be very odd).

Jon.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] RAS userspace testing

[Jon Masters]

Hi there,

A whole bunch of RAS infrastructure patches recently went upstream. Can
I ask that those present from the ARM server vendors (or interested
other parties) assist in figuring out the userspace components so that
we can get these into future Fedora?

Thanks,

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2017-04-25

[Jon Masters]

Thanks - indeed I had already disabled via that command.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On May 1, 2017, at 19:16, Dan Callaghan  wrote:
> 
> Excerpts from Jon Masters's message of 2017-04-29 15:03 -04:00:
>>> On 04/29/2017 12:58 PM, Dennis Gilmore wrote:
>>>> El sáb, 29-04-2017 a las 02:40 -0400, Jon Masters escribió:
>>>> This was a different issue - mirrorlist entries don't work on the
>>>> test compose but Beaker doesn't know not to create a "fedora-updates" 
>>>> repo. I turned that off at the distro level on my server.
>>> 
>>> The issue is that beaker is using metalink urls but saying they are --
>>> mirrorlist the fix is to make beaker use --metalink instread of --
>>> mirrorlist. its a change in anaconda/pykickstart simplifying code
>>> paths.
>> 
>> Anyone on the Beaker team want to comment on the best fix to
>> kickstarts/default for this?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1442146
> 
> I haven't looked closely yet. I think it is a compatibility break in 
> Anaconda (but maybe intentional). We can fix the kickstart templates in 
> Beaker. In the short term, workaround is to set "no_updates_repos" 
> ksmeta in your recipes or at the distro level.
> 
> -- 
> Dan Callaghan 
> Senior Software Engineer, Products & Technologies Operations
> Red Hat
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2017-04-25

[Jon Masters]

On 04/29/2017 02:38 AM, Jon Masters wrote:
> On 04/28/2017 06:47 AM, bill peck wrote:
>> Hi Jon,
>>
>> You may want to pull this change to your beaker instance to fix the
>> anamon issue.
>>
>> https://gerrit.beaker-project.org/#/c/5661/
> 
> Thanks Bill. I did. I also noted in the review that I had to update the
> httpd config to add the Alias for /beaker/anamon3 on the lab controller.
> 
> With this change, and after turning off Beaker's generation of
> mirrorlist entries (fedora-updates), install log attached. I'll look
> into the beah deps needs side of things later - this is ok for now.

I hacked my local Fedora26 harness to add these packages for beah:

pyserial-3.1.1-1.fc23.noarch.rpm
python2-zope-event-4.2.0-3.fc25.noarch.rpm
python2-zope-interface-4.2.0-2.fc25.aarch64.rpm
python-fpconst-0.7.3-17.fc25.noarch.rpm
python-twisted-core-12.2.0-4.fc21.aarch64.rpm
python-twisted-web-12.2.0-4.fc21.aarch64.rpm
SOAPpy-0.11.6-18.fc21.noarch.rpm

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2017-04-25

[Jon Masters]

On 04/29/2017 12:58 PM, Dennis Gilmore wrote:
> El sáb, 29-04-2017 a las 02:40 -0400, Jon Masters escribió:
>> This was a different issue - mirrorlist entries don't work on the
>> test compose but Beaker doesn't know not to create a "fedora-updates" 
>> repo. I turned that off at the distro level on my server.
> 
> The issue is that beaker is using metalink urls but saying they are --
> mirrorlist the fix is to make beaker use --metalink instread of --
> mirrorlist. its a change in anaconda/pykickstart simplifying code
> paths.

Anyone on the Beaker team want to comment on the best fix to
kickstarts/default for this?

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2017-04-25

[Jon Masters]

This was a different issue - mirrorlist entries don't work on the test compose 
but Beaker doesn't know not to create a "fedora-updates" repo. I turned that 
off at the distro level on my server.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Apr 28, 2017, at 10:28, Jon Masters  wrote:
> 
> And yet they've installed ok. Weird. There's a Beaker fix I am pulling into 
> my setup shortly. Either way, this isn't a fedora bug.
> 
> -- 
> Computer Architect | Sent from my 64-bit #ARM Powered phone
> 
>>> On Apr 28, 2017, at 06:36, Peter Robinson  wrote:
>>> 
>>>> On Fri, Apr 28, 2017 at 7:43 AM, Jon Masters  wrote:
>>>>> On 04/28/2017 02:32 AM, Jon Masters wrote:
>>>>> On 04/25/2017 12:52 PM, Paul Whalen wrote:
>>>>> 
>>>>>   
>>>>> https://fedoraproject.org/wiki/Architectures/AArch64/QA/Fedora-26-20170420.n.0
>>>> 
>>>> Haven't triaged this yet but my home Beaker is failing to provision (see
>>>> the python warning, I'll check the harness, etc. later):
>>>> 
>>>> True+ fetch /tmp/anamon http://rack1.bos.jonmasters.org/beaker/anamon
>>>> + curl --retry 20 --remote-time -o /tmp/anamon
>>>> http://rack1.bos.jonmasters.org/beaker/anamon
>>>> % Total% Received % Xferd  Average Speed   TimeTime Time
>>>> Current
>>>>Dload  Upload   Total   SpentLeft
>>>> Speed
>>>> ^M  0 00 00 0  0  0 --:--:-- --:--:--
>>>> --:--:-- 0^M100  8741  100  87410 0  1261k  0 --:--:--
>>>> --:--:-- --:--:-- 1422k
>>>> + python /tmp/anamon --recipe-id 64 --xmlrpc-url
>>>> http://rack1.bos.jonmasters.org:8000/RPC2
>>>> /tmp/ks-script-i4oe8fhn: line 38: python: command not found
>>>> 06:27:19ESC[CNotESC[CaskingESC[CforESC[CVNCESC[CbecauseESC[CofESC[CanESC[CautomatedESC[Cinstall
>>>> 06:27:19ESC[CNotESC[CaskingESC[CforESC[CVNCESC[CbecauseESC[CtextESC[CmodeESC[CwasESC[CexplicitlyESC[CaskedESC[CforESC[CinESC[Ckickstart
>>>> StartingESC[CautomatedESC[Cinstall.
>>>> GeneratingESC[CupdatedESC[CstorageESC[Cconfiguration
>>>> CheckingESC[CstorageESC[Cconfiguration...
>>> 
>>> The switch to python3 means there's no "python" any more in the
>>> installer environment. I'm /hacking/ it up in my own Beaker for the
>>> moment with a snippet that manually adds python2. I hope.
>> 
>> We've not had python3 in the minimal ARM images since Fedora 24 (or
>> maybe even earlier).
>> 
>> Peter
> ___
> arm mailing list -- arm@lists.fedoraproject.org
> To unsubscribe send an email to arm-le...@lists.fedoraproject.org
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2017-04-25

[Jon Masters]

And yet they've installed ok. Weird. There's a Beaker fix I am pulling into my 
setup shortly. Either way, this isn't a fedora bug.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Apr 28, 2017, at 06:36, Peter Robinson  wrote:
> 
>> On Fri, Apr 28, 2017 at 7:43 AM, Jon Masters  wrote:
>>> On 04/28/2017 02:32 AM, Jon Masters wrote:
>>>> On 04/25/2017 12:52 PM, Paul Whalen wrote:
>>>> 
>>>>
>>>> https://fedoraproject.org/wiki/Architectures/AArch64/QA/Fedora-26-20170420.n.0
>>> 
>>> Haven't triaged this yet but my home Beaker is failing to provision (see
>>> the python warning, I'll check the harness, etc. later):
>>> 
>>> True+ fetch /tmp/anamon http://rack1.bos.jonmasters.org/beaker/anamon
>>> + curl --retry 20 --remote-time -o /tmp/anamon
>>> http://rack1.bos.jonmasters.org/beaker/anamon
>>>  % Total% Received % Xferd  Average Speed   TimeTime Time
>>> Current
>>> Dload  Upload   Total   SpentLeft
>>> Speed
>>> ^M  0 00 00 0  0  0 --:--:-- --:--:--
>>> --:--:-- 0^M100  8741  100  87410 0  1261k  0 --:--:--
>>> --:--:-- --:--:-- 1422k
>>> + python /tmp/anamon --recipe-id 64 --xmlrpc-url
>>> http://rack1.bos.jonmasters.org:8000/RPC2
>>> /tmp/ks-script-i4oe8fhn: line 38: python: command not found
>>> 06:27:19ESC[CNotESC[CaskingESC[CforESC[CVNCESC[CbecauseESC[CofESC[CanESC[CautomatedESC[Cinstall
>>> 06:27:19ESC[CNotESC[CaskingESC[CforESC[CVNCESC[CbecauseESC[CtextESC[CmodeESC[CwasESC[CexplicitlyESC[CaskedESC[CforESC[CinESC[Ckickstart
>>> StartingESC[CautomatedESC[Cinstall.
>>> GeneratingESC[CupdatedESC[CstorageESC[Cconfiguration
>>> CheckingESC[CstorageESC[Cconfiguration...
>> 
>> The switch to python3 means there's no "python" any more in the
>> installer environment. I'm /hacking/ it up in my own Beaker for the
>> moment with a snippet that manually adds python2. I hope.
> 
> We've not had python3 in the minimal ARM images since Fedora 24 (or
> maybe even earlier).
> 
> Peter
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2017-04-25

[Jon Masters]

On 04/28/2017 02:32 AM, Jon Masters wrote:
> On 04/25/2017 12:52 PM, Paul Whalen wrote:
> 
>> 
>> https://fedoraproject.org/wiki/Architectures/AArch64/QA/Fedora-26-20170420.n.0
> 
> Haven't triaged this yet but my home Beaker is failing to provision (see
> the python warning, I'll check the harness, etc. later):
> 
> True+ fetch /tmp/anamon http://rack1.bos.jonmasters.org/beaker/anamon
> + curl --retry 20 --remote-time -o /tmp/anamon
> http://rack1.bos.jonmasters.org/beaker/anamon
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
> ^M  0 00 00 0  0  0 --:--:-- --:--:--
> --:--:-- 0^M100  8741  100  87410 0  1261k  0 --:--:--
> --:--:-- --:--:-- 1422k
> + python /tmp/anamon --recipe-id 64 --xmlrpc-url
> http://rack1.bos.jonmasters.org:8000/RPC2
> /tmp/ks-script-i4oe8fhn: line 38: python: command not found
> 06:27:19ESC[CNotESC[CaskingESC[CforESC[CVNCESC[CbecauseESC[CofESC[CanESC[CautomatedESC[Cinstall
> 06:27:19ESC[CNotESC[CaskingESC[CforESC[CVNCESC[CbecauseESC[CtextESC[CmodeESC[CwasESC[CexplicitlyESC[CaskedESC[CforESC[CinESC[Ckickstart
> StartingESC[CautomatedESC[Cinstall.
> GeneratingESC[CupdatedESC[CstorageESC[Cconfiguration
> CheckingESC[CstorageESC[Cconfiguration...

The switch to python3 means there's no "python" any more in the
installer environment. I'm /hacking/ it up in my own Beaker for the
moment with a snippet that manually adds python2. I hope.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2017-04-25

[Jon Masters]

On 04/25/2017 12:52 PM, Paul Whalen wrote:

> 
> https://fedoraproject.org/wiki/Architectures/AArch64/QA/Fedora-26-20170420.n.0

Haven't triaged this yet but my home Beaker is failing to provision (see
the python warning, I'll check the harness, etc. later):

True+ fetch /tmp/anamon http://rack1.bos.jonmasters.org/beaker/anamon
+ curl --retry 20 --remote-time -o /tmp/anamon
http://rack1.bos.jonmasters.org/beaker/anamon
  % Total% Received % Xferd  Average Speed   TimeTime Time
Current
 Dload  Upload   Total   SpentLeft
Speed
^M  0 00 00 0  0  0 --:--:-- --:--:--
--:--:-- 0^M100  8741  100  87410 0  1261k  0 --:--:--
--:--:-- --:--:-- 1422k
+ python /tmp/anamon --recipe-id 64 --xmlrpc-url
http://rack1.bos.jonmasters.org:8000/RPC2
/tmp/ks-script-i4oe8fhn: line 38: python: command not found
06:27:19ESC[CNotESC[CaskingESC[CforESC[CVNCESC[CbecauseESC[CofESC[CanESC[CautomatedESC[Cinstall
06:27:19ESC[CNotESC[CaskingESC[CforESC[CVNCESC[CbecauseESC[CtextESC[CmodeESC[CwasESC[CexplicitlyESC[CaskedESC[CforESC[CinESC[Ckickstart
StartingESC[CautomatedESC[Cinstall.
GeneratingESC[CupdatedESC[CstorageESC[Cconfiguration
CheckingESC[CstorageESC[Cconfiguration...

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Proposal to CANCEL : Fedora ARM & AArch64 status meeting 2017-03-28

[Jon Masters]

On 03/27/2017 11:59 AM, Paul Whalen wrote:
> 
> Hi Folks, 
> 
> Proposing we cancel this week's status meeting. There is currently 
> nothing on the agenda, and hopefully we'll be busy with Alpha 1.3
> testing. 
> 
> If you do have something you would like to discuss and would like to 
> go ahead with the meeting please respond to this email and we can go 
> ahead as planned. 
> 
> I'll forward the Alpha 1.3 details once available. 

Ok, thanks Paul.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Qemu aarch64 install

[Jon Masters]

Suggestion: if you're somehow able to persuade folks to do a 4K kernel in 
addition, retain default 64K. Packages built for 64K will mostly be on with 4K, 
but not the inverse.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Feb 17, 2017, at 03:31, Gerd Hoffmann  wrote:
> 
>> On Do, 2017-02-16 at 19:13 +0100, Marcin Juszkiewicz wrote:
>> W dniu 16.02.2017 o 18:59, Gerd Hoffmann pisze:
>> 
>>> I think it would be more useful to offer a 4k kernel in addition to
>>> the 64k one, similar to how Fedora ships kernel with and without
>>> lpae support on armv7.
>> 
>> Some applications still check PAGE_SIZE only during compilation instead
>> of on runtime. Btrfs was also hardcoding it.
> 
> Can't be too bad.  I'm running f25 aarch64 userspace with a 4k pages
> kernel on the rpi3.  The only problem I ran into so far is that the
> swapspace format depends on the pagesize too, so you have to run "swapon
> --fixpgsz" once after switching from 64k to 4k or visa versa.
> 
> cheers,
>  Gerd
> ___
> arm mailing list -- arm@lists.fedoraproject.org
> To unsubscribe send an email to arm-le...@lists.fedoraproject.org
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Qemu aarch64 install

[Jon Masters]

On 02/16/2017 12:59 PM, Gerd Hoffmann wrote:

>> pressure on them to clean this up. RHEL (and Cent) will use 64K no
>> matter what, but there could be a (short term) case for Fedora having
>> a cycle or two with a smaller size - I would prefer to avoid that.
> 
> I think it would be more useful to offer a 4k kernel in addition to the
> 64k one, similar to how Fedora ships kernel with and without lpae
> support on armv7.

I suggested this before. I won't print what the response was :)

However, if you want to bring it up with the kernel@ team and drive...

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2017-02-14

[Jon Masters]

On 02/16/2017 10:36 AM, Christopher Covington wrote:
> Hi Peter, Paul, Laura,
> 
> Feel free to drop the QDF2432 system register access erratum workaround 
> patch at this point. Thanks for carrying it as long as you have. It has
> enabled additional testing and development that would have been much more
> difficult otherwise.

Thanks :) For everything.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: Qemu aarch64 install

[Jon Masters]

On 02/16/2017 04:10 AM, Gerd Hoffmann wrote:



> What was the reason to go 64k pages in the first place?

Several reasons:

1). Some (server) implementations have higher performance under 64K.
2). VA sizes greater than 48-bit require a 64K translation granule. I
can mention that one publicly now. There are similar reasons in the
pipeline for why 64K is going to be needed on big iron ARM systems.
3). We thought 64K was going to matter, and we wanted to make sure we
could support it (4K is "easy", those other guys do that already).

> Sure, with larger pages memory management overhead goes down.  But on
> the other hand the memory footprint goes up, and frankly I'm a bit
> surprised how much it goes up.

There's much room for optimization. I want to try to avoid throwing the
baby out with the bathwater as we push ARM and others to clean this up.
For another example, we see kernel structure ballooning caused by the
lack of support for sparse CPU masks and the like - all things that
ARM should be addressing in upstream. Our using 64K helps to keep the
pressure on them to clean this up. RHEL (and Cent) will use 64K no
matter what, but there could be a (short term) case for Fedora having
a cycle or two with a smaller size - I would prefer to avoid that.

> So I'm wondering whenever 64k pages is a net win even
> on enterprise machines.  Did people benchmark this?

It is a net win on Enterprise, required for some of the insanely large
machines being designed now. I can give you one example - Cray have
recently announced that they will be shipping a very large ARM system
in the next couple months. There are many other such machines coming.

Benchmarking was done based upon models by the RH perf team about
3-4 years ago, yes. Again, there's a lot of cleanup to do, but that's
not in and of itself a reason to throw out 64K, especially as it's the
only path to >48-bit VA support in the coming iteration.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: 48-bit support in F26?

[Jon Masters]

On 09/21/2016 02:47 PM, Jeremy Linton wrote:
> On 09/15/2016 08:15 AM, Peter Lemenkov wrote:
>> Hello All!
>>
>> 2016-09-14 23:59 GMT+02:00 Jeremy Linton :
>>
>>> js185:
>>> couchdb-0:1.6.1-16.fc25.x86_64
>> ...
>>> erlang-js-0:1.3.0-7.fc25.x86_64
>>
>> I've got patches (mostly untested) for building erlang-js with mozjs170.
>>
>> https://github.com/basho/erlang_js/pull/44#issuecomment-247323892
> 
> Hi Peter,
> 
> I've been submitting patches to pull everything forward to at least
> mozjs24 which is where gnome/etc are. Would it be possible to push from
> 17 to 24, because if erlang lands on mozjs17 when polkit gets moved to
> 24, then again mozjs17 will have a single dependency in fedora.
> 
> That said, it looks like gnome are trying to move again, but they are
> too moving to mozjs31, just as 0ad leaves it.

Any chance you can wire up a feature page for F26 with this in it?

Going forward, I would /also/ like to be 52-bit VA tolerant. I realized
that since ARMv8.2 is now public, we can at least discuss on this list
that longer term there might be some server systems needing 52-bit
support as well (which is optional, so it'll depend upon cleaver kernel
enablement - likely with a optional 4th page directory that
transparently folds onto the pud or something) so we should at least
make sure we're tolerant toward that later on.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: 48-bit support in F26?

[Jon Masters]

Great - that was my preference just didn't want to overkill it. But this sounds 
like good test run of doing the process the right way...

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On Sep 14, 2016, at 17:13, Josh Boyer  wrote:
> 
>> On Wed, Sep 14, 2016 at 3:55 PM, Jon Masters  wrote:
>> Hi Jeremy, all,
>> 
>> I was just catching up with some folks and we discussed the status of
>> 48-bit VA support. It seems to me that it would make most sense to have
>> an official coordination effort between those vendors/community members
>> who are interested, to ensure that they help with the necessary package
>> updates ahead of the kernel, and work with a test kernel to identify any
>> additional packages or issues that need resolving. I believe it would
>> make most sense to have a Fedora feature page (or something less grand,
>> but similar in concept) tracking this for F26, with the deps.
> 
> I would very much advocate for the full Feature page.  It will get the
> change the appropriate attention technically, and it will raise
> awareness of Aarch64 within Fedora from a general sense.
> 
> josh
___
arm mailing list
arm@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] 48-bit support in F26?

[Jon Masters]

Hi Jeremy, all,

I was just catching up with some folks and we discussed the status of
48-bit VA support. It seems to me that it would make most sense to have
an official coordination effort between those vendors/community members
who are interested, to ensure that they help with the necessary package
updates ahead of the kernel, and work with a test kernel to identify any
additional packages or issues that need resolving. I believe it would
make most sense to have a Fedora feature page (or something less grand,
but similar in concept) tracking this for F26, with the deps.

Perhaps Jeremy can update us on the status, and then he and others can
help drive this forward (someone should nominate themselves as the ring
leader too). I spoke with Cavium earlier today, and I know they'll be
keen to help. I know Qualcomm had expressed interest during our IRC
meetings in helping out. To that end, I'm copying at least those I know
so far who are interested here.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list
arm@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] Re: [Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting

[Jon Masters]

On 08/28/2016 11:00 AM, pwha...@redhat.com wrote:

> You are kindly invited to the meeting:
>Fedora ARM & AArch64 status meeting on 2016-08-30 from 15:00:00 to 
> 16:00:00 UTC
>At fedora-meetin...@irc.freenode.net
> 
> The meeting will be about:
> Fedora ARM & AArch64 weekly status meeting. 
> 
> More information available at:
> [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org/wiki/Architectures/ARM)

Followup: I spoke with Applied about firmware versions for Mustang and
we should have a fix available within 1-2 weeks. They'll have the exact
date for me within a few days and I will share. Meanwhile, we have test
firmware and I am about to do a test install of today's alpha release.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list
arm@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2016-05-10

[Jon Masters]

On 05/12/2016 03:06 PM, Jon Masters wrote:
> Item number 3 is the one I mentioned in reply to the beta announce mail - we 
> think it is now triaged to a specific broken commit in recent shim and will 
> be corrected by a pending update.

Do we have an updated shim landing in F24?

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] Re: Fedora ARM & AArch64 Status Meeting Minutes 2016-05-10

[Jon Masters]

Item number 3 is the one I mentioned in reply to the beta announce mail - we 
think it is now triaged to a specific broken commit in recent shim and will be 
corrected by a pending update.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On May 10, 2016, at 13:02, Paul Whalen  wrote:
> 
> 
> #fedora-meeting-2: Fedora ARM and AArch64 Status Meeting
> 
> 
> 
> Meeting started by pwhalen at 15:00:05 UTC. The full logs are available
> at
> https://meetbot.fedoraproject.org/fedora-meeting-2/2016-05-10/fedora_arm_and_aarch64_status_meeting.2016-05-10-15.00.log.html
> .
> 
> 
> 
> Meeting summary
> ---
> * 1)  Package Status & Issues    (pwhalen, 15:02:33)
>  * libreoffice is still FTBFS currently the bigggest blocker at the
>moment.  (pwhalen, 15:04:10)
>  * Eclipse bootstrap to be completed within the next week.  (pwhalen,
>15:04:47)
>  * No major issues in F24.  (pwhalen, 15:05:53)
> 
> * 2)  Kernel Status   (pwhalen, 15:05:59)
>  * Kernel 4.6 to be GA in aprx one week.  (pwhalen, 15:07:24)
>  * Latest - kernel-4.6.0-0.rc7.git1.1.fc25  (pwhalen, 15:08:07)
>  * LINK: http://koji.fedoraproject.org/koji/buildinfo?buildID=761711
>(pwhalen, 15:08:15)
>  * issue on BBone devices with crypto driver, possible on omap as well.
>(pwhalen, 15:10:35)
> 
> * 3)  Bootloader Status   (pwhalen, 15:11:47)
>  * boot fails with Synchronous Exception on aarch64 with grub2 built
>with gcc6 (BZ#1319083)  (pwhalen, 15:13:28)
>  * uboot-tools-2016.05-0.4.rc3.fc25 now available for testing. Will
>likely be GA within the next week, so important to check all devices
>and report issues.  (pwhalen, 15:21:06)
> 
> * 4)  F24 Beta   (pwhalen, 15:24:22)
>  * Beta Shipped today for both armhfp and aarch64!!  (pwhalen,
>15:24:22)
>  * Please review the install documentation.  (pwhalen, 15:24:53)
>  * LINK:
>https://fedoraproject.org/wiki/Architectures/ARM/F24/Installation
>(pwhalen, 15:24:53)
>  * LINK:
>https://fedoraproject.org/wiki/Architectures/AArch64/F24/Installation
>(pwhalen, 15:24:53)
>  * Hardware Support for F24 Beta -
>
> http://fedoraproject.org/wiki/Architectures/ARM/F24/Installation/Hardware_Status
>(pwhalen, 15:26:49)
> 
> * 5) == Open Floor ==  (pwhalen, 15:35:59)
> 
> Meeting ended at 15:43:42 UTC.
> 
> 
> 
> 
> Action Items
> 
> 
> 
> 
> 
> 
> Action Items, by person
> ---
> * **UNASSIGNED**
>  * (none)
> 
> 
> 
> 
> People Present (lines said)
> ---
> * pwhalen (59)
> * pbrobinson (39)
> * hrw (18)
> * dmarlin (7)
> * zodbot (5)
> * linuxmodder (2)
> * dgilmore (1)
> * yselkowitz (0)
> * ahs3 (0)
> * bconoboy (0)
> * jonmasters (0)
> * jsmith (0)
> 
> 
> 
> 
> Generated by `MeetBot`_ 0.1.4
> 
> .. _`MeetBot`: http://wiki.debian.org/MeetBot
> ___
> arm mailing list
> arm@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] Re: Announcing the release of Fedora 24 Beta for aarch64!

[Jon Masters]

Laszlo has tracked the shim+GRUB2 issue down to a specific broken commit in a 
recent update and a scheduled update to shim 0.9/1.0 is being coordinated by 
Peter, who will followup.

(Red Hat folks - let's keep followup public on this one since we are also 
tracking in RHEL)

-- 
Computer Architect | Sent from my 64-bit #ARM Powered phone

> On May 12, 2016, at 01:30, Jon Masters  wrote:
> 
>> On 05/10/2016 01:09 PM, Peter Robinson wrote:
>> 
>> The Fedora 24 Beta for aarch64 is here, on schedule for our planned June 
>> final
>> release. For Beta we have added Cloud and Docker base images.
>> Download the prerelease from our Get Fedora site:
>> 
>> -   Get Fedora 24 Beta Server: make use of the very latest server-based
>>technologies available in the open source community
>>
>> https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Server/aarch64/
> 
> A big (blue) hat's off to you all on this achievement. The beta boots
> fine on a Mustang here[0] and installed without issue. I am currently
> using it to investigate an issue in shim loading GRUB2 from the weekly
> meeting and will provide an update on that once I've made some progress.
> 
> Jon.
> 
> [0] Looking forward to getting the upstream SPCR in the next cycle
> (which will then mean the same boot line will boot RHELSA and Fedora)
> 
> -- 
> Computer Architect | Sent from my Fedora powered laptop
> ___
> arm mailing list
> arm@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] Re: Announcing the release of Fedora 24 Beta for aarch64!

[Jon Masters]

On 05/10/2016 01:09 PM, Peter Robinson wrote:

> The Fedora 24 Beta for aarch64 is here, on schedule for our planned June final
> release. For Beta we have added Cloud and Docker base images.
> Download the prerelease from our Get Fedora site:
> 
> -   Get Fedora 24 Beta Server: make use of the very latest server-based
> technologies available in the open source community
> 
> https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Server/aarch64/

A big (blue) hat's off to you all on this achievement. The beta boots
fine on a Mustang here[0] and installed without issue. I am currently
using it to investigate an issue in shim loading GRUB2 from the weekly
meeting and will provide an update on that once I've made some progress.

Jon.

[0] Looking forward to getting the upstream SPCR in the next cycle
(which will then mean the same boot line will boot RHELSA and Fedora)

-- 
Computer Architect | Sent from my Fedora powered laptop
___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] Re: armhf dnf is not working on aarch64 kernel

[Jon Masters]

Hi Gordan,

On 04/28/2016 05:00 PM, Gordan Bobic wrote:
> On 2016-04-28 19:49, Jon Masters wrote:

> First of all, Jon, thank you for your thoughts on this matter.

No problem :)

>> Allow me to add a few thoughts. I have been working with the ARM vendors
>> (as well as the ARM Architecture Group) since before the architecture
>> was announced, and the issue of page size and 32-bit backward
>> compatibility came up in the earliest days. I am speaking from a Red Hat
>> perspective and NOT dictating what Fedora should or must do, but I do
>> strongly encourage Fedora not to make a change to something like the
>> page size simply to support a (relatively) small number of corner cases.
> 
> IMO, the issue of backward compatibility is completely secondary to
> the issue of efficiency of memory fragmentation/occupancy when it comes
> to 64KB pages. And that isn't a corner case, it is the overwhelmingly
> primary case.

Let's keep to the memory discussion then, I agree. On the fragmentation
argument, I do agree this is an area where server/non-server uses
certainly clash. It might well be that we later decide in Fedora that 4K
is the right size once there are more 64-bit client devices.

>> Having an entire separate several ISAs just for the fairly nonexistent field 
>> of
>> proprietary non-recompilable third party 32-bit apps doesn't really make
>> sense. Sure, running 32-bit via multilib is fun and all, but it's not
>> really something that is critical to using ARM systems.
> 
> Except where there's no choice, such as closed source applications
> (Plex comes to mind) or libraries without appropriate ARM64 implementation
> such as Mono. I'm sure pure aarch64 will be supported by it all at
> some point, but the problem is real today.

It's definitely true that there are some applications that aren't yet
ported to ARMv8, though that list is fairly small (compared with IA32).

> But OK, for the sake of this discussion let's completely ignore the
> 32-bit support to simplify things.

OK :)

>> The mandatory page sizes in the v8 architecture are 4K and 64K, with
>> various options around the number of bits used for address spaces, huge
>> pages (or ginormous pages), and contiguous hinting for smaller "huge"
>> pages. There is an option for 16K pages, but it is not mandatory. In the
>> server specifications, we don't compel Operating Systems to use 64K, but
>> everything is written with that explicitly in mind. By using 64K early
>> we ensure that it is possible to do so in a very clean way, and then if
>> (over the coming years) the deployment of sufficient real systems proves
>> that this was a premature decision, we still have 4K.
> 
> The real question is how much code will bit-rot due to not being
> tested with 4KB pages

With respect, I think it's the other way around. We have another whole
architecture targeting 4K pages by default, and (regretfully perhaps,
though that's a personal opinion) it's a pretty popular choice that many
people are using in Fedora today. So I don't see any situation in which
4K bitrots over 64K. I did see the opposite being very likely if we
didn't start out with 64K as the baseline going in on day one.

>> I also asked a few of the chip
>> vendors not to implement 32-bit execution (and some of them have indeed
>> omitted it after we discussed the needs early on), and am aggressively
>> pushing for it to go away over time in all server parts. But there's
>> more to it than that. In the (very) many early conversations with
>> various performance folks, the feedback was that larger page sizes than
>> 4K should generally be adopted for a new arch. Ideally that would have
>> been 16K (which other architectures than x86 went with also), but that
>> was optional. Optionally necessarily means "does not exist". My advice
>> when Red Hat began internal work on ARMv8 was to listen to the experts.
> 
> Linus is not an expert?

Note that I never said he isn't an expert. He's one of the smartest guys
around, but he's not always right 100% of the time. Folks who run
performance numbers were consulted about the merits of 64K (as were a
number of chip architects) and they said that was the way to go. We can
always later decide (once there's a server market running fully) that
this was premature and change to 4K, but it's very hard to go the other
way around later if we settle for 4K on day one. The reason is 4K works
great out of the box as it's got 30 years of history on that other arch,
but for 64K we've only POWER to call on, and its userbase generally
aren't stressing the same workloads as on 64-bit ARM. Sometimes they

[fedora-arm] Re: armhf dnf is not working on aarch64 kernel

[Jon Masters]

Hi Gordan, Peter, all,

On 04/27/2016 03:39 PM, Gordan Bobic wrote:
> On 2016-04-27 19:12, John Dulaney wrote:
>> On Wed, Apr 27, 2016 at 05:04:38PM +0100, Gordan Bobic wrote:
>>> >
>>> >Maybe that's something that CentOS have added (don't know, haven't
>>> >looked), RHELSA doesn't support it that I'm aware of and they're
>>> >definitely only 64K page size. The biggest change is in rpm and the
>>> >arch mappings there.

>>> They might not support it, but it most certainly works. There are no
>>> changes specific to this that I can find in CentOS. All I changed was
>>> rebuilt the host kernel with 4KB pages and ARM32 support (still an
>>> aarch64 kernel). C7 armv7hl guest is completely unmodified apart from
>>> the /etc/rpm/platform being set explicitly.

Allow me to add a few thoughts. I have been working with the ARM vendors
(as well as the ARM Architecture Group) since before the architecture
was announced, and the issue of page size and 32-bit backward
compatibility came up in the earliest days. I am speaking from a Red Hat
perspective and NOT dictating what Fedora should or must do, but I do
strongly encourage Fedora not to make a change to something like the
page size simply to support a (relatively) small number of corner cases.
It is better to focus on the longer term trajectory, which the mobile
handset market demonstrates: the transition to 64-bit computing hardware
will be much faster than people thought, and we don't need to build a
legacy (we don't a 32-bit app store filled with things that can't easily
be rebuilt, and all of them have been anyway).

That doesn't mean we shouldn't love 32-bit ARM devices, which we do. In
fact, there will be many more 32-bit ARM devices over coming years. This
is especially true for IoT clients. But there will also be a large (and
rapidly growing) number of very high performance 64-bit systems. Many of
those will not have any 32-bit backward compatibility, or will disable
it in the interest of reducing the amount of validation work. Having an
entire separate several ISAs just for the fairly nonexistent field of
proprietary non-recompilable third party 32-bit apps doesn't really make
sense. Sure, running 32-bit via multilib is fun and all, but it's not
really something that is critical to using ARM systems.

The mandatory page sizes in the v8 architecture are 4K and 64K, with
various options around the number of bits used for address spaces, huge
pages (or ginormous pages), and contiguous hinting for smaller "huge"
pages. There is an option for 16K pages, but it is not mandatory. In the
server specifications, we don't compel Operating Systems to use 64K, but
everything is written with that explicitly in mind. By using 64K early
we ensure that it is possible to do so in a very clean way, and then if
(over the coming years) the deployment of sufficient real systems proves
that this was a premature decision, we still have 4K.

The choices for preferred page size were between 4K and 64K. In the
interest of transparency, I pushed from the RH side in the earliest days
(before public disclosure) to introduce an intentional break with the
past and support only 64K on ARMv8. I also asked a few of the chip
vendors not to implement 32-bit execution (and some of them have indeed
omitted it after we discussed the needs early on), and am aggressively
pushing for it to go away over time in all server parts. But there's
more to it than that. In the (very) many early conversations with
various performance folks, the feedback was that larger page sizes than
4K should generally be adopted for a new arch. Ideally that would have
been 16K (which other architectures than x86 went with also), but that
was optional. Optionally necessarily means "does not exist". My advice
when Red Hat began internal work on ARMv8 was to listen to the experts.

I am well aware of Linus's views on the topic and I have seen the rants
on G+ and elsewhere. I am completely willing to be wrong (there is not
enough data yet) over moving to 64K too soon and ultimately if it was
premature see things like RHELSA on the Red Hat side switch back to 4K.
Fedora is its own master, but I strongly encourage retaining the use of
64K granules at this time, and letting it play out without responding to
one or two corner use cases and changing course. There are very many
design optimizations that can be done when you have a 64K page size,
from the way one can optimize cache lookups and hardware page table
walker caches to the reduction of TLB pressure (though I accept that
huge pages are an answer for this under a 4K granule regime as well). It
would be nice to blaze a trail rather than take the safe default.

My own opinion is that (in the longer term, beginning with server) we
should not have a 32-bit legacy of the kind that x86 has to deal with
forever. We can use virtualization (and later, if it really comes to it,
containers running 32-bit applications with 4K pages exposed to them -
an implementation would be a bit lik

[fedora-arm] Re: 96Boards Enterprise Edition Cello

[Jon Masters]

On 03/24/2016 01:14 PM, Richard W.M. Jones wrote:
> On Tue, Mar 22, 2016 at 07:18:23AM -0400, Jon Masters wrote:
>> Hi Folks,
>>
>> I wanted to just drop a quick note that we're making *great* progress
>> toward having early 96Boards "Cello" boards for Fedora enablement
>> purposes. These are (AArch64) AMD Seattle based boards:
>>
>> http://www.lenovator.com/product/103.html
>>
>> These are SBSA/SBBR compliant boards that (from a software point of
>> view) look just like ARM servers. They're also low-ish cost (for a
>> server - $300+the cost of RAM and disk, etc.). Yes, they're not in a
>> standard ATX form factor. We know this. Before you rant about that,
>> consider that the goal here is to give developers a tiny board on their
>> desk that happens to meet the software requirements for server - we all
>> hope there will be many more server platforms that are ATX size soon.
>>
>> We ought to be in a very solid position to be able to support these
>> quickly in Fedora. I've got plans in place to get some early boards to
>> key folks needed to make that happen. I've also previously booted Fedora
>> on an early board with a couple of tweaks that need cleanup. I'll
>> followup with details, and with the individuals who are getting early
>> boards (they know who they are) to help get this moving.
> 
> This is good news, especially that they are non-junk SBSA/SBBR-
> compliant boards[1].

Thanks for the kind works :) I'm going to keep beating the SBSA drum.
Sadly on the consumer side of 64-bit ARM, vendors just don't care about
being successful in the mainstream (because they are far too naive and
not being correctly steered to do the right thing - and actively being
steered in the wrong direction by folks like Canonical who stand to
monetize the enablemement of each and every individual platform in the
wrong way for the industry overall) - they want to make hacks for the
weekend with random firmware that makes life nasty for everyone just
because they won't spend a few cents more on some damned flash with
decent firmware and do this like a real computer should be done. On the
server side, we have Red Hat influence, and I intend to keep using that
to force people to make useful, general purpose hw. that can run a
variety of Operating Systems like a real computer should be built.

In a few years, everyone else will start to wake up, once they see that
they could actually be successful with a general purpose approach. But
it's going to take 5 years for most of them to understand. And many
consumer folks never will understand how to build a real computer.

> I ordered one of these the day they were announced.  Any idea when
> they'll be delivered :-?

The goal is ramp volume production next month. I'm getting regular
updates, so once we go to volume production, I'll get you a date. I'm
also working with that team on branding for the Cello, and would like to
include Fedora as well as CentOS and RHEL(SA). I've already mentioned
that to a few folks, and we'll followup properly.

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] 96Boards Enterprise Edition Cello

[Jon Masters]

Hi Folks,

I wanted to just drop a quick note that we're making *great* progress
toward having early 96Boards "Cello" boards for Fedora enablement
purposes. These are (AArch64) AMD Seattle based boards:

http://www.lenovator.com/product/103.html

These are SBSA/SBBR compliant boards that (from a software point of
view) look just like ARM servers. They're also low-ish cost (for a
server - $300+the cost of RAM and disk, etc.). Yes, they're not in a
standard ATX form factor. We know this. Before you rant about that,
consider that the goal here is to give developers a tiny board on their
desk that happens to meet the software requirements for server - we all
hope there will be many more server platforms that are ATX size soon.

We ought to be in a very solid position to be able to support these
quickly in Fedora. I've got plans in place to get some early boards to
key folks needed to make that happen. I've also previously booted Fedora
on an early board with a couple of tweaks that need cleanup. I'll
followup with details, and with the individuals who are getting early
boards (they know who they are) to help get this moving.

Thanks,

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] Re: Gigabyte MP30-AR0

[Jon Masters]

On 11/30/2015 02:03 PM, Jon Masters wrote:
> On 11/30/2015 06:04 AM, Florian Weimer wrote:
>> On 11/09/2015 03:13 PM, Richard W.M. Jones wrote:
>>>
>>> Someone I know is after an ARM 64 bit development board, and pointed
>>> me at this.  I'd never heard of it :-(
>>>
>>> http://b2b.gigabyte.com/products/product-page.aspx?pid=5422#ov
>>>
>>> Has anyone tried it?
>>
>> I downloaded the firmware update.  It contains U-Boot and a custom Linux
>> kernel (without sources).  An UEFI update is not included, as far as I
>> can tell.  I suspect the firmware does not support UEFI as-is, and it is
>> expected that you boot a UEFI implementation through U-Boot.  The
>> release notes contain some references to TianoCore, but I couldn't find
>> any actual code matching that in the firmware update.
> 
> An updated version of the board is coming, with UEFI provided.

I have pinged the vendor concerned and received a confirmation of the
above, but I don't know if I can share the specifics here yet.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] Re: Gigabyte MP30-AR0

[Jon Masters]

On 11/30/2015 06:04 AM, Florian Weimer wrote:
> On 11/09/2015 03:13 PM, Richard W.M. Jones wrote:
>>
>> Someone I know is after an ARM 64 bit development board, and pointed
>> me at this.  I'd never heard of it :-(
>>
>> http://b2b.gigabyte.com/products/product-page.aspx?pid=5422#ov
>>
>> Has anyone tried it?
> 
> I downloaded the firmware update.  It contains U-Boot and a custom Linux
> kernel (without sources).  An UEFI update is not included, as far as I
> can tell.  I suspect the firmware does not support UEFI as-is, and it is
> expected that you boot a UEFI implementation through U-Boot.  The
> release notes contain some references to TianoCore, but I couldn't find
> any actual code matching that in the firmware update.

An updated version of the board is coming, with UEFI provided.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

Re: [fedora-arm] Customize Fedora 21 ISO

[Jon Masters]

On 01/15/2015 10:57 PM, Peter Robinson wrote:
> On Fri, Jan 16, 2015 at 3:34 AM, Brooks Hu  wrote:
>> Thanks Dennis.
>>
>> I did following experiment:
>>
>> Mounted ISO onto a local directory, changed to the directory, did nothing,
>> run "createrepo --update .", but I found the files under repodata changed,
>> including the checksum in filename. Is that expected? I suppose they
>> shouldn't be changed.
>>
>> I am readying the manual of pungi.
>>
>> One more question: do you have any good links about customizing a ISO? I
>> found a few pages, but they seem not to work.
> 
> You can't really customise a Fedora installer iso. You basically have
> two options:
> 1) Regenerate the iso from clean
> 2) Use the existing installer iso but point it to a new
> updated/changed repository.

Depending what you're doing, the latter (2) might really be what you
want. Especially if you use a Kickstart file, there is rarely a need to
actually respin the entire media.

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] gettext lock hang

[Jon Masters]

Should we do a few more to prove it?

-- 
Computer Architect | Sent from my #ARM Powered Mobile device

On Oct 29, 2014 10:43 AM, Paul Whalen  wrote:
>
>
>
> - Original Message - 
> > Hi Folks, 
> > 
> > A quick note that I i

- Original Message -
> Hi Folks,
> 
> A quick note that I identified an upstream futex barrier fix from
> Catalin that went into 3.17 late, and which might explain the problem we
> are seeing with gettext lock tests hanging. I've built a test kernel for
> the builder that was reproducing and pointed Peter and Paul at the
> necessary information. If it turns out to the the problem, will add a
> summary to this thread. But I thought I should drop a quick note.

That finished successfully, build here:
https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2761118

Paul

> 
> Jon.
> ___
> arm mailing list
> arm@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] gettext lock hang

[Jon Masters]

Hi Folks,

A quick note that I identified an upstream futex barrier fix from
Catalin that went into 3.17 late, and which might explain the problem we
are seeing with gettext lock tests hanging. I've built a test kernel for
the builder that was reproducing and pointed Peter and Paul at the
necessary information. If it turns out to the the problem, will add a
summary to this thread. But I thought I should drop a quick note.

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Meeting at Flock

[Jon Masters]

Hi Folks,

For those at Flock, a few of us are thinking of meeting for dinner around 7pm 
at the Diplomat. I will endeavor to followup with details of where we end up.

Jon.

-- 
Computer Architect | Sent from my 64-bit #ARM Powered Tablet
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] arm-temp.ausil.us is shutting down

[Jon Masters]

On 11/22/2013 05:24 PM, Brendan Conoboy wrote:
> On 11/22/2013 02:22 PM, Brendan Conoboy wrote:
>> Hi everybody,
>>
>> Dennis's email server is currently migrating so I'm sending this for
>> him.  The system we did aarch64 bootstrap on, arm-temp.ausil.us, is
>> shutting down.  If you're currently using this system to retrieve
>> packages you'll want to update your yum configuration to use
>> http://arm-temp.ausil.us/pub/fedora-arm/stage4/ instead.
> 
> Make that: http://arm.koji.fedoraproject.org/aarch64/stage4/

Handy updated stage4.repo reference file attached.

Jon.


[stage4]
name=Fedora fc19-stage4 - aarch64
failovermethod=priority
#baseurl=http://arm-temp.ausil.us/pub/fedora-arm/stage4
baseurl=http://arm.koji.fedoraproject.org/aarch64/stage4
enabled=1
#metadata_expire=7d
gpgcheck=0
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] vexpress on F20

[Jon Masters]

Hi Folks,

Quick question. Has anyone been able to successfully boot the F20
composes on a vexpress QEMU model? I've re-tested a kernel that was
listed as working, but it does not work on my local system. I am
interested in getting some data. Can I confirm that everyone is
experiencing a hang while the kernel waits to locate the rootfs?

(digging through the mmc code now)

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Rev A4 BeagleBoneBlack

[Jon Masters]

On 09/14/2013 11:47 PM, Jon Masters wrote:

> FYI I tried poking at BeagleBone last night but mine is dead. I've tried
> a bunch of different 3.3v USB/UART adapters today and I can't get any
> output at all. I'm going to replace it this week (express), but sadly I
> can only look at vexpress over the weekend. Hope someone else has more
> luck. But note, I will be looking at the BBB so there's no need to
> revert those patches unless they're really breaking other stuff.

Since I'm replacing mine, I'm going to order two and have one
sacrificial one that I'll try mounting the JTAG debug port on. I'll see
if my Flyswatter can talk to the board for debug purposes.

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Rev A4 BeagleBoneBlack

[Jon Masters]

Hey Paul,

FYI I tried poking at BeagleBone last night but mine is dead. I've tried
a bunch of different 3.3v USB/UART adapters today and I can't get any
output at all. I'm going to replace it this week (express), but sadly I
can only look at vexpress over the weekend. Hope someone else has more
luck. But note, I will be looking at the BBB so there's no need to
revert those patches unless they're really breaking other stuff.

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Fedora 19 booted on Wandboard Quad

[Jon Masters]

On 09/12/2013 07:50 AM, Steven Falco wrote:
> On 09/12/2013 04:54 AM, Matthias Runge wrote:
>> On 11/09/13 14:07, Steven Falco wrote:
>>
>>>
>>> Hit any key to stop autoboot:  0
>>> => run bootcmd
>>> mmc0 is current device
>>> Retrieving file: /boot/extlinux/extlinux.conf
>>> ** File not found /boot/extlinux/extlinux.conf **
>>> Error reading config file
>>> Retrieving file: /extlinux/extlinux.conf
>>> 524 bytes read in 194 ms (2 KiB/s)
>>> Ignoring malformed menu command:  autoboot
>>> 1:  Fedora (3.11.0-0.rc6.git4.1.fc20.armv7hl) 20 (Null)
>>> Enter choice: 1
>>> 1:  Fedora (3.11.0-0.rc6.git4.1.fc20.armv7hl) 20 (Null)
>>> Retrieving file: /initramfs-3.11.0-0.rc6.git4.1.fc20.armv7hl.img
>>> 10841835 bytes read in 643 ms (16.1 MiB/s)
>>> Retrieving file: /vmlinuz-3.11.0-0.rc6.git4.1.fc20.armv7hl
>>> 5152408 bytes read in 351 ms (14 MiB/s)
>>> append: console=ttymxc0,115200
>>> root=UUID=ac77ed30-9586-4ffe-94c0-7bd5eaebcdfa ro rhgb quiet
>>> LANG=en_US.UTF-8
>>> Retrieving file: /dtb/imx6q-wandboard.dtb
>>> 23567 bytes read in 153 ms (150.4 KiB/s)
>>> (nothing more printed out...)
>>
>> Ah yes, I've seen that a couple of times, too; I tried until it worked
>> (about 1 of 5/10 tries).
>> A later just worked for me, so I suggest you should try a later version,
>> e.g from
>> http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC2/Images/armhfp/Fedora-Minimal-armhfp-20-Alpha-2-sda.raw.xz
> 
> Thanks - I'm downloading it now.

When it does crash (which is every so many boots), I briefly (on
occasion) see output about illegal/undefined instructions. There's
perhaps a multitplatform artifact in here. Some kind of errata or other
workaround might be enabled that triggers on some boots and causes this.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] F20 Alpha RC2 Partitions

[Jon Masters]

Hi Dennis (in the main),

The partition alignment in the Alpha seems to be off slightly, e.g.:

/dev/mmcblk0p11953 1001953  50+  83  Linux

/dev/mmcblk0p2 1001954 1251953  125000   83  Linux

/dev/mmcblk0p3 1251954 3986328 1367187+  83  Linux


I believe this has actually been the case for some time, but since I've
been staring at it a bunch I wonder if you've thoughts about adjusting
the images so that the first partition is aligned?

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Fedora 19 booted on Wandboard Quad

[Jon Masters]

On 09/12/2013 04:54 AM, Matthias Runge wrote:
> On 11/09/13 14:07, Steven Falco wrote:
> 
>>
>> Hit any key to stop autoboot:  0
>> => run bootcmd
>> mmc0 is current device
>> Retrieving file: /boot/extlinux/extlinux.conf
>> ** File not found /boot/extlinux/extlinux.conf **
>> Error reading config file
>> Retrieving file: /extlinux/extlinux.conf
>> 524 bytes read in 194 ms (2 KiB/s)
>> Ignoring malformed menu command:  autoboot
>> 1:  Fedora (3.11.0-0.rc6.git4.1.fc20.armv7hl) 20 (Null)
>> Enter choice: 1
>> 1:  Fedora (3.11.0-0.rc6.git4.1.fc20.armv7hl) 20 (Null)
>> Retrieving file: /initramfs-3.11.0-0.rc6.git4.1.fc20.armv7hl.img
>> 10841835 bytes read in 643 ms (16.1 MiB/s)
>> Retrieving file: /vmlinuz-3.11.0-0.rc6.git4.1.fc20.armv7hl
>> 5152408 bytes read in 351 ms (14 MiB/s)
>> append: console=ttymxc0,115200
>> root=UUID=ac77ed30-9586-4ffe-94c0-7bd5eaebcdfa ro rhgb quiet
>> LANG=en_US.UTF-8
>> Retrieving file: /dtb/imx6q-wandboard.dtb
>> 23567 bytes read in 153 ms (150.4 KiB/s)
>> (nothing more printed out...)
> 
> Ah yes, I've seen that a couple of times, too; I tried until it worked
> (about 1 of 5/10 tries).
> A later just worked for me, so I suggest you should try a later version,
> e.g from
> http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC2/Images/armhfp/Fedora-Minimal-armhfp-20-Alpha-2-sda.raw.xz

Working great on my board here too. I've made a minor fix to your wiki
entry to update the kernel paths so that they work with the Alpha RC2.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] PandaBoard F20 U-Boot

[Jon Masters]

Hi Folks,

Out of interest, do we (Peter, Dennis?) expect the current uboot-tools
to be generating a U-Boot that works on Panda? Reverting to the F19
release (with both uboot.img and uboot.bin files) works. The current
kernel isn't booting on this older EB3 board, but I'll look at that
next. I've got a new Flyswatter so I can start poking at it again.

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] ARM Architecture Reference Manual availability

[Jon Masters]

Thanks for the forward Andy! It's great reading :)

On 09/11/2013 08:24 AM, Andrew Wafaa wrote:
> To all those interested,
> 
> ARM have finally published the reference manual for ARMv8 \o/ You can grab a 
> copy [0] now, you will need to accept the EULA first.
> 
> Regards,
> 
> Andy
> 
> 0 - 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a/index.html
> 
> 
> --
> Andrew Wafaa - Principal Engineer, Open Source - ARM Ltd.
> Tel: +44 1223 405981 Mob: +44 7974 074546
> 
> 
> 
> -- 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.
> 
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
> Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
> Registered in England & Wales, Company No:  2548782
> 
> ___
> arm mailing list
> arm@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
> 

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] KVM on Samsung Chromebook A15

[Jon Masters]

On 07/05/2013 05:07 AM, Richard W.M. Jones wrote:
> On Wed, Jul 03, 2013 at 11:59:28AM -0500, Jon wrote:
>> I'm pleased to announce the availability of Fedora 19 for the 2012 Samsung
>> Chromebook featuring ARM Exynos dual core A15 processor.
> 
> Sorry to slightly hijack this thread.  I will try your remix later.
> 
> Reading the comments on https://lwn.net/Articles/557132/#Comments
> it seems as if the news on KVM on the Chromebook is not good.  It
> doesn't boot into HYP mode, and there's no way to make it boot into
> HYP mode, so KVM won't be supported.  Is that right?

That's roughly what I'd expect to be the case. There might be a signed
U-Boot someone has hacked that does enable HYP mode, but otherwise I
suspect you're out of luck. I'll ask around during Linaro Connect.

Note that this is also specifically why I had the UEFI binding for ARMv8
modified (a long time ago, in a galaxy far far away) such that we
*always* mandate that the OS be entered at the EL2 exception level (not
privilege level in ARMv8 - different), and that we have a standard way
to install a Hypervisor. Unfortunately, on 32-bit systems, you need to
rely upon a magic SMC or similar to do it, and we can't rely on that
being available, or standardized yet. Bottom line is this goes away.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Mirabox notes

[Jon Masters]

Hey folks,

I've not had as much time as I wanted to play with the Mirabox. I'm
taking this one over to the UK to give to Peter in a few hours, and I've
ordered myself another one so that I can help get it working. It's not a
high priority, but I agree that this is a nice device for F20.

In the absence of dtb support in the U-Boot, and given the ugly way the
storage is setup via USB, I'm just hacking together a test environment
that isn't using a-b-c. I use the Minimal VFAT image with a microSD card
inside an SD Card adapter (for my laptop), delete the first two
partitions, then re-create them of even size (about 256M each). Then I
format the first partition using ext2 as the filesystem.

I prep a suitable mvebu kernel by appending the dtb (using the non-lpae
kernel as that is still in prep upstream):

sudo sh -c "cat vmlinuz-$version.fc19.armv7hl
dtb-$version.fc19.armv7hl/armada-370-mirabox.dtb
>vmlinuz-$version.fc19.armv7hl.mirabox"

sudo mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e
0x8000 -n $version.fc19.armv7hl.mirabox -d
vmlinuz-$version.fc19.armv7hl.mirabox uImage-$version.fc19.armv7hl.mirabox

Then I copy this (renamed to uImage), and the uInitrd onto the first
ext2 partition. Inserting into the Mirabox, I set the following U-Boot
environmental parameters to boot the result:

setenv bootcmd 'usb start; ext2load usb 1:1 0x0200 uImage; ext2load
usb 1:1 0x0280 uInitrd; bootm 0x0200 0x0280'
setenv bootargs 'ro rootwait root=/dev/sdb3 console=ttyS0,115200'

These are just rough notes. Ultimately, we'd want dtb support in the
U-Boot, and we'd want to have a-b-c learn about this particular
armada-370 variant. I've poked at a-b-c a couple of times but honestly
didn't go too far down that path as it's not going to be supportable
yet. You'd certainly want to change the 370 load addresses at least.

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] glibc-common install error on F19 -- Anyone else hitting?

[Jon Masters]

On 06/28/2013 04:47 PM, John Dulaney wrote:
> Is anyone else hitting an install error (1) when updating glibc and 
> glibc-common?
> 
> If it is widespread enough, I'll debug.

Check your storage media :)


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] PandaBoard on RC2

[Jon Masters]

On 06/28/2013 11:51 AM, Jeffrey Bastian wrote:

> I see the same problem with the Minimal VFAT RC3 images starting on sector 
> 1953
> instead of 2048.  Also, shouldn't the type of the second filesystem be 82 for
> Linux Swap?

Yes to both, but since it doesn't prevent booting I was going to mention
right after we said "yes" to shipping F19 :)

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Go-no-go meeting in #fedora-meeting-1 now

[Jon Masters]

$subject
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Fwd: Re: dummy_flush_tlb_a15_erratum in check_and_switch_context

[Jon Masters]

Peter,

Let's see what the explicit thought is here with regard to support and plan 
accordingly.

Jon.


 Original Message 
From: Jon Masters 
Sent: Fri Jun 28 08:54:41 EDT 2013
To: Will Deacon 
Cc: "linux-arm-ker...@lists.infradead.org" 
, catalin.mari...@arm.com
Subject: Re: dummy_flush_tlb_a15_erratum in check_and_switch_context

Hi Will,

Thanks for quick followup. Just a note (late night - top posting from 
bed...apologies!) that I wasn't necessarily considering this a bug (hence lack 
of CC), although I will be glad to see it fixed. Personally I don't like the 
idea of trying to build a multiplatform kernel that does A8/A9 and A15. I get 
the feeling most folks assume A15 means LPAE and want us (Fedora) to delineate 
accordingly, but if you in general plan to ensure multiplatform non-LPAE will 
always work across all three (and be tested by people who care about that 
combination) then this is good to know.

Thanks!

Jon.

Will Deacon  wrote:

>On Fri, Jun 28, 2013 at 04:48:14AM +0100, Jon Masters wrote:
>> Hi Folks,
>
>Hi Jon,
>
>It's usually best to CC people explicitly when reporting bugs in their
>code
>[adding Catalin] ;)
>
>> Post mostly for Google's benefit. Fedora folks were reporting the
>> following backtrace on Cortex-A8 OMAP:
>> 
>> [   12.182873] Internal error: Oops - undefined instruction: 0 [#1]
>SMP ARM
>> [   12.189971] Modules linked in: drm_kms_helper drm
>> [   12.194965] CPU: 0 PID: 153 Comm: dracut-initqueu Not tainted
>> 3.10.0-0.rc7.git0.2.fc20.armv7hl #1
>> [   12.204317] task: c9ee9b80 ti: c9f5 task.ti: c9f5
>> [   12.210025] PC is at check_and_switch_context+0x3c0/0x44c
>> [   12.215724] LR is at check_and_switch_context+0x364/0x44c
>> [   12.221424] pc : []lr : []psr:
>400f0093
>> [   12.221424] sp : c9f51e40  ip :   fp : c9ebe860
>> [   12.233532] r10: c08cb470  r9 : c08d97c8  r8 : c9ebe700
>> [   12.239044] r7 :   r6 : 0200  r5 :   r4 :
>0201
>> [   12.245929] r3 :   r2 :   r1 :   r0 :
>0001
>> [   12.252817] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
>> Segment user
>> [   12.260436] Control: 10c5387d  Table: 80004019  DAC: 0015
>> [   12.266497] Process dracut-initqueu (pid: 153, stack limit =
>0xc9f50240)
>> [   12.273568] Stack: (0xc9f51e40 to 0xc9f52000)
>> [   12.278174] 1e40: c08cb478  0200  200f0093
>> c08d853c c9f41e00 c9ebe380
>> [   12.286808] 1e60:  c9ee9b80 c0c7db80 c9f5 c9eeb700
>> c9ebe700 c9f51f24 c05994b8
>> [   12.295440] 1e80: 0004 c0250920 0004 c0047954 d6266cd2
>> 0002  
>> [   12.304074] 1ea0:  c0048854 c08cdb80 003b d6266cd2
>> 0002 6ae1 c007a670
>> [   12.312708] 1ec0: 0139  b40e b40e 6a0d
>> c007a670 f5257d14 c0079274
>> [   12.321342] 1ee0: c9f41e00  0003 081f c08ded98
>> bea94f88 c9f51fb0 000cf704
>> [   12.329976] 1f00: c9f51f84 c9f51f60 c9f50028 c9ee9b80 
>> c9f51f78 fff6 c9f5
>> [   12.338598] 1f20: c9f5 c0048854 c9ee9dcc c9eeb700 c9f51f38
>> c9ee9e14  
>> [   12.347220] 1f40: 0004   bea951a8 c9f5
>>  000d6d64 c004988c
>> [   12.355841] 1f60: 0003 0004   bea951a8
>>   c9ee9b80
>> [   12.364463] 1f80: c0047438 c9eeedd0 c9eeedd0  
>> bea951a8  0072
>> [   12.373084] 1fa0: c000e344 c000e1a0  bea951a8 
>> bea951a8  
>> [   12.381705] 1fc0:  bea951a8  0072 000cf704
>> 000d6094  000d6d64
>> [   12.390328] 1fe0: 000cf164 bea95158 00045180 b6e37ae0 600f0010
>>  2d10a02c c8542a0a
>> [   12.398987] [] (check_and_switch_context+0x3c0/0x44c)
>from
>> [] (__schedule+0x4ac/0x750)
>> [   12.409193] [] (__schedule+0x4ac/0x750) from
>[]
>> (do_wait+0x1ec/0x244)
>> [   12.417834] [] (do_wait+0x1ec/0x244) from []
>> (SyS_wait4+0xa8/0xc8)
>> [   12.426206] [] (SyS_wait4+0xa8/0xc8) from []
>> (ret_fast_syscall+0x0/0x30)
>> [   12.435116] Code: 1e082f13 f57ff04f f57ff06f e3a03000 (ee083f33)
>> [   12.441552] ---[ end trace c0816de7f5b496a8 ]---
>> 
>> I disassembled that faulting instruction manually just now, and it
>> appears to be:
>> 
>> 1110 1110 000  0 1000 0011    001  1  0011
>>   opc1   CRn  Rt   coproc opc2CRm
>> 
>> MCR cp15, 0, r3, c8, c3, 1
>> 
>> Which maps back to the call to dummt_flush_tlb_a15_erratum in
>> check_a

Re: [fedora-arm] PandaBoard on RC2

[Jon Masters]

Semi-pilot error. I should be using the -VFAT images, which I just
figured out after two hours spent trying to fix the other one. This is
not documented on the wiki obviously and is a post-beta change, so it
will urgently require attention as anyone following the instructions
from beta will fall into the same trap (and not know how to fix it).

I've pulled down the VFAT images onto a fast remote box and confirmed
with kpartx that they look better. Since it's go-no-go I will stay up
now and do some testing once they come down on ES. Assume that the below
is not a problem because the images do contain boot.scr and partitioning
looks more reasonable in the VFAT ones.

Jon.

On 06/28/2013 02:48 AM, Jon Masters wrote:
> Hey folks,
> 
> A few issues with the RC2 image running on PandaBoard (ES):
> 
> 1). It doesn't boot at all. This is because the image contains a weird
> partition layout, not aligned, etc. MLO never has a chance. The SD Card
> had this as the first partition:
> 
> /dev/sdb11953 1001953  50+  83  Linux
> 
> Which I fixed to look as it should:
> 
> /dev/sdb1   *2048  411647  2048006  FAT16
> 
> At which point the MLO actually loads, as does u-boot.img, etc.
> 
> 2). Unless I am missing something, there is nothing within boot/boot.scr
> on the root ext4 filesystem for ext4load to pull in, but that could be
> pilot error. So let me know about that one.
> 
> If it's just the first item, then there's no need to make an RC4 because
> the instructions (that have to be run anyway) can include making a
> correctly aligned filesystem with the correct constraints on size,
> filesystem type, etc. required for MLO. I did note this on IRC yesterday
> that MLO is finnicky and I did have a reason (as you see).
> 
> Jon.
> ___
> arm mailing list
> arm@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
> 

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] PandaBoard on RC2

[Jon Masters]

Hey folks,

A few issues with the RC2 image running on PandaBoard (ES):

1). It doesn't boot at all. This is because the image contains a weird
partition layout, not aligned, etc. MLO never has a chance. The SD Card
had this as the first partition:

/dev/sdb11953 1001953  50+  83  Linux

Which I fixed to look as it should:

/dev/sdb1   *2048  411647  2048006  FAT16

At which point the MLO actually loads, as does u-boot.img, etc.

2). Unless I am missing something, there is nothing within boot/boot.scr
on the root ext4 filesystem for ext4load to pull in, but that could be
pilot error. So let me know about that one.

If it's just the first item, then there's no need to make an RC4 because
the instructions (that have to be run anyway) can include making a
correctly aligned filesystem with the correct constraints on size,
filesystem type, etc. required for MLO. I did note this on IRC yesterday
that MLO is finnicky and I did have a reason (as you see).

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Fwd: dummy_flush_tlb_a15_erratum in check_and_switch_context

[Jon Masters]

 Original Message 
Subject: dummy_flush_tlb_a15_erratum in check_and_switch_context
Date: Thu, 27 Jun 2013 23:48:14 -0400
From: Jon Masters 
Organization: World Organi{s,z}ation of Broken Dreams
To: linux-arm-ker...@lists.infradead.org

Hi Folks,

Post mostly for Google's benefit. Fedora folks were reporting the
following backtrace on Cortex-A8 OMAP:

[   12.182873] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[   12.189971] Modules linked in: drm_kms_helper drm
[   12.194965] CPU: 0 PID: 153 Comm: dracut-initqueu Not tainted
3.10.0-0.rc7.git0.2.fc20.armv7hl #1
[   12.204317] task: c9ee9b80 ti: c9f5 task.ti: c9f5
[   12.210025] PC is at check_and_switch_context+0x3c0/0x44c
[   12.215724] LR is at check_and_switch_context+0x364/0x44c
[   12.221424] pc : []lr : []psr: 400f0093
[   12.221424] sp : c9f51e40  ip :   fp : c9ebe860
[   12.233532] r10: c08cb470  r9 : c08d97c8  r8 : c9ebe700
[   12.239044] r7 :   r6 : 0200  r5 :   r4 : 0201
[   12.245929] r3 :   r2 :   r1 :   r0 : 0001
[   12.252817] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment user
[   12.260436] Control: 10c5387d  Table: 80004019  DAC: 0015
[   12.266497] Process dracut-initqueu (pid: 153, stack limit = 0xc9f50240)
[   12.273568] Stack: (0xc9f51e40 to 0xc9f52000)
[   12.278174] 1e40: c08cb478  0200  200f0093
c08d853c c9f41e00 c9ebe380
[   12.286808] 1e60:  c9ee9b80 c0c7db80 c9f5 c9eeb700
c9ebe700 c9f51f24 c05994b8
[   12.295440] 1e80: 0004 c0250920 0004 c0047954 d6266cd2
0002  
[   12.304074] 1ea0:  c0048854 c08cdb80 003b d6266cd2
0002 6ae1 c007a670
[   12.312708] 1ec0: 0139  b40e b40e 6a0d
c007a670 f5257d14 c0079274
[   12.321342] 1ee0: c9f41e00  0003 081f c08ded98
bea94f88 c9f51fb0 000cf704
[   12.329976] 1f00: c9f51f84 c9f51f60 c9f50028 c9ee9b80 
c9f51f78 fff6 c9f5
[   12.338598] 1f20: c9f5 c0048854 c9ee9dcc c9eeb700 c9f51f38
c9ee9e14  
[   12.347220] 1f40: 0004   bea951a8 c9f5
 000d6d64 c004988c
[   12.355841] 1f60: 0003 0004   bea951a8
  c9ee9b80
[   12.364463] 1f80: c0047438 c9eeedd0 c9eeedd0  
bea951a8  0072
[   12.373084] 1fa0: c000e344 c000e1a0  bea951a8 
bea951a8  
[   12.381705] 1fc0:  bea951a8  0072 000cf704
000d6094  000d6d64
[   12.390328] 1fe0: 000cf164 bea95158 00045180 b6e37ae0 600f0010
 2d10a02c c8542a0a
[   12.398987] [] (check_and_switch_context+0x3c0/0x44c) from
[] (__schedule+0x4ac/0x750)
[   12.409193] [] (__schedule+0x4ac/0x750) from []
(do_wait+0x1ec/0x244)
[   12.417834] [] (do_wait+0x1ec/0x244) from []
(SyS_wait4+0xa8/0xc8)
[   12.426206] [] (SyS_wait4+0xa8/0xc8) from []
(ret_fast_syscall+0x0/0x30)
[   12.435116] Code: 1e082f13 f57ff04f f57ff06f e3a03000 (ee083f33)
[   12.441552] ---[ end trace c0816de7f5b496a8 ]---

I disassembled that faulting instruction manually just now, and it
appears to be:

1110 1110 000  0 1000 0011    001  1  0011
  opc1   CRn  Rt   coproc opc2CRm

MCR cp15, 0, r3, c8, c3, 1

Which maps back to the call to dummt_flush_tlb_a15_erratum in
check_and_switch_context:

#ifdef CONFIG_ARM_ERRATA_798181
static inline void dummy_flush_tlb_a15_erratum(void)
{
/*
 * Dummy TLBIMVAIS. Using the unmapped address 0 and ASID 0.
 */
asm("mcr p15, 0, %0, c8, c3, 1" : : "r" (0));
dsb();
}
#else
static inline void dummy_flush_tlb_a15_erratum(void)
{
}
#endif

Now I think it's personally just easier to only turn on that errata on
LPAE/A15 kernels and just leave it at that (I've requested this get
moved to the lpae config and out of the base config so this is what
should happen shortly - clearly the intention), but some folks out there
want to do exciting things...I got asked if this could be runtime
patched (which I guess in theory is possible), but I'm not going there.

Anyway, in addition, does this kind of thing need fixing with a more
specific Kconfig so that there's an explicit A15 dependency in there?
Rather just "depends on CPU_V7 && SMP"?

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Issues to solve before F19 ARM GA

[Jon Masters]

On 05/29/2013 01:20 PM, Brendan Conoboy wrote:
> On 05/25/2013 10:15 PM, Brendan Conoboy wrote:

>>   o No graphics - regression since F18 (Kernel 3.6)
> 
> Jon is looking into this for Panda only.  He should have an update later 
> today.

So I'm just using a blunt instrument one-liner to request_module the
tfp4 panel driver on module init. This is ugly, and needs testing, etc.
It'll never go upstream. We can perhaps get away with a synchronous
request_module call during module init because that happens in the
context of modprobe (kmod) and so we probably won't deadlock stuff, but
the right thing in general is probably to DECLARE_WORK a worker that can
be scheduled in the kernel at probe time based on what chips are
actually present, e.g. after parsing the devicetree for that data. This
is just stream-of-consciousness thinking here, I'll think more about it.

I'll be ordering some new Panda ES boards for myself and Peter, since
the EB3 and other engineering builds seem to generate a backtrace on
boot. It's not worth fixing that if production ES boards are working.

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] F19 Beta RC2 compose

[Jon Masters]

On 05/17/2013 08:51 AM, Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi all,
> 
> there is a Release Candidate compose for Beta at
> http://armpkgs.fedoraproject.org/mash/stage/19-Beta-RC2/
> 
> there is a install tree as well as two images, the images are a
> minimal install. the minimal image has all 3 kernels installed, kernel,
> kernel-lpae, and kernel-tegra. to install to a sdcard run 
> "xzcat  "
> 
> the OMAP image is minimal also it only has kernel installed. you will
> need to setup uboot on the first partition. 

Thanks. I'll be testing OMAP over the weekend!

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] CONFIG_LATENCYTOP

[Jon Masters]

On 05/10/2013 02:10 PM, John Brier wrote:
> Hi, it seems that somehow CONFIG_LATENCYTOP and
> CONFIG_HAVE_LATENCYTOP_SUPPORT are not even in the /boot/config-*
> generated files
> 
> [root@calxeda-arm-soc-02 SOURCES]# grep -i latency /boot/config-3.
> config-3.6.10-8.fc18.armv7l.highbank  config-3.8.11-200.fc18.armv7l
> [root@calxeda-arm-soc-02 SOURCES]# grep -i latency /boot/config-3.*
> [root@calxeda-arm-soc-02 SOURCES]#
> 
> Is this intentional or can I open a bug on it? I tried to follow the
> process that a config file is generated from during rpmbuild but it was
> not clear to me.. a pointer on how that happens would also be nice.

Currently, 32-bit ARM LATENCYTOP support is dependent upon !SMP.
Separately, I have been screening through all of the discrepancies
between x86_64 and AArch64 and have already identified this as a feature
enhancement needed for 64-bit. I have that, and a laundry list of
related features that I will be raising with ARM/Linaro elsewhere.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Friday Tech Talks

[Jon Masters]

Hi guys,

John Dulaney gave a great talk a few weeks ago on the Chromebook. Who
would like to do the next in our series of Friday "Tech Talks"? Perhaps
a little too late for today, but plenty of time for next week!

If you're interested, reply to this mail, and add here:

http://fedoraproject.org/wiki/Architectures/ARM/Talks/ARMTechTalks

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] F19: uImage load addresses with unified kernel

[Jon Masters]

On 03/27/2013 11:26 AM, Nicolas Pitre wrote:
> On Wed, 27 Mar 2013, Jon Masters wrote:
> 
>> Prior to Brendan sending that mail last night, we had an internal RH
>> meeting wherein this topic came up (and precipitated the email). I
>> explained already in that and will repeat here that the ARM kernel is
>> already relocatable. It has only two major requirements right now:
>>
>> 0). That it be loaded into actual RAM somewhere. Most boards direct map
>> physical RAM at 0. Some do it at 2GB or higher. Others have aliasing
>> where you see physical RAM in two ranges and other weirdness. The reason
>> we have these different load addresses today is that the hardware
>> platforms are not all consistent around physical map.
>>
>> 1). That it be loaded at sufficient alignment (low-order bits 0x8000 due
>> to the exception vectors). Maybe that one even can/could/is handled by
>> the uncompressor. I dunno if that limitation is relaxed somewhere.
> 
> The decompressor code takes care of that already.  If you compile your 
> kernel with CONFIG_AUTO_ZRELADDR=y then all you need is to load the 
> zImage within the first 128MB of physical RAM.

Good to know. Then we're not specifically stuck with any special
alignment requirements as long as we load within the branch limit.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] F19: uImage load addresses with unified kernel

[Jon Masters]

Hi Nico, Graeme,

On 03/27/2013 11:01 AM, Nicolas Pitre wrote:
> On Wed, 27 Mar 2013, Graeme Russ wrote:

>> Using FIT you should be able to bundle a unified uImage, initramfs and
>> FDT. You can then edit the FDT within U-Boot for device specific
>> parameters (like load address).
> 
> IMHO this is the wrong direction to take for a distribution.  If you 
> start bundling things together in a FIT image, you'll end up 
> distributing one such image per supported target which is I believe what 
> you wish to avoid in the first place.

I'm with Nico on this. We don't want to do Ubuntu-style hardware packs
and tailor per-board in the longer term any more than we need to. I
would favor just loading the kernel zImage (which is more than the
kernel anyway, it's also got the uncompressor, and it's the same concept
as how we boot x86) and having the specifics of where that is loaded
handled by U-Boot.

Prior to Brendan sending that mail last night, we had an internal RH
meeting wherein this topic came up (and precipitated the email). I
explained already in that and will repeat here that the ARM kernel is
already relocatable. It has only two major requirements right now:

0). That it be loaded into actual RAM somewhere. Most boards direct map
physical RAM at 0. Some do it at 2GB or higher. Others have aliasing
where you see physical RAM in two ranges and other weirdness. The reason
we have these different load addresses today is that the hardware
platforms are not all consistent around physical map.

1). That it be loaded at sufficient alignment (low-order bits 0x8000 due
to the exception vectors). Maybe that one even can/could/is handled by
the uncompressor. I dunno if that limitation is relaxed somewhere.

I mentioned already that I favor ignoring the uImage header and just
loading the kernel where we know it needs to be. I agree that the
easiest way to do that is to drop uImage loading and do zImage.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] vexpress 3.8 update

[Jon Masters]

On 02/28/2013 12:29 PM, Mark Langsdorf wrote:
> The highbank model is upstream but I haven't used it in a while. The midway 
> model is being used right now and is known to work, so I suspect the highbank 
> model is mostly working. I can fix bugs that people report to me.

Like I said the other day, I think we might need to consider moving to
an A15 model just because that's what people are playing with.
Meanwhile, what's the consensus on A9 qemu as a priority?

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] vexpress 3.8 update

[Jon Masters]

Hi Folks,

I've done a bunch of tests against the qemu vexpress model (based upon a
local backport rebuild of F18 qemu on F17 - can't be doing with the hit
to upgrading to F18 on this laptop this week) with the 3.8 scratch
kernel Peter built last Friday morning. The Fedora kernel as built
doesn't boot because the emulated PL011 UART IP in the qemu model is
generating a kernel backtrace. It's possible to get beyond that, at
which point the emulated PL181 MMCI trigers another backtrace as the
kernel can't determine the voltages supported by the emulated SD Card.

Additionally, I'll want to supply a vexpress-jcm.dtb that removes a
bunch of devices that are not provided by qemu in the emulated machine
so as to avoid stuff breaking in the future. Really, qemu ought to
provide the dtb directly (and be builtin) but folks still haven't got
the memo that Linux has no business owning the platform and we'll have
to wait until we get to ACPI on v8 before that message starts going in.
Until then, if we're providing a dtb, let's make sure it actually
describes the hardware that is "present" in the qemu machine.

The bottom line is that vexpress qemu model isn't getting tested
upstream. That testing that is happening is obviously on real hardware,
not the qemu emulated machine. So we have a choice here. I can fix it
(but I can't do everything, not enough time) or we can tell people not
to upgrade to 3.8 on vexpress. Initial areas that will need work will be
the PL011 driver (to avoid a divide by zero) and the MMCI. Can we
prioritize and strategize around this soon, please?

Mark Langsdorf and I met in person yesterday and he has a link to the
same kernel, which he will test on highbank today. I will assist. Once I
get to Hong Kong, I can do some more poking next week but it's going to
be another week until we have a 3.8 plan.

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] 3.9 merge window kernels

[Jon Masters]

On 02/22/2013 08:37 PM, Jon Masters wrote:
> On 02/22/2013 10:36 AM, Peter Robinson wrote:
>> On Fri, Feb 22, 2013 at 3:17 PM, Josh Boyer  wrote:
>>> Just a quick heads up that the 3.9 merge window kernels are being built
>>> in rawhide now.  I've tried to at least test boot kernels on my machine
>>> before submitting them to koji, but testers beware.  Merge window
>>> kernels can be tricky.
>>>
>>> ARM people:  the -git4 kernel build has the big ARM merge contained in
>>> it.  I've tried to go through and make a reasonable estimation of what
>>> all the ARM related config options should be set to, but you really need
>>> to look those over.  Also... the config file setup is confusing,
>>> particularly config-armv7.  That seems to be used by only
>>> kernel-armv7/kernel-armv7hl but not by the omap and tegra armv7 configs.
>>> I think that is leading to some duplication of config settings.  Anyway,
>>> look it over please.
>>
>> Thanks, it's changed a fair bit again and this round omap goes away
>> too, I'll try and get it sorted over the weekend.
> 
> I might be running a marathon on Sunday but otherwise want to assist!
> I'll make a pass tomorrow as well :) Thanks so much everyone!

So I'm not seeing 3.9 changes in the Fedora git tree. Can we sync up
tomorrow on this one guys?

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] 3.9 merge window kernels

[Jon Masters]

On 02/22/2013 10:36 AM, Peter Robinson wrote:
> On Fri, Feb 22, 2013 at 3:17 PM, Josh Boyer  wrote:
>> Just a quick heads up that the 3.9 merge window kernels are being built
>> in rawhide now.  I've tried to at least test boot kernels on my machine
>> before submitting them to koji, but testers beware.  Merge window
>> kernels can be tricky.
>>
>> ARM people:  the -git4 kernel build has the big ARM merge contained in
>> it.  I've tried to go through and make a reasonable estimation of what
>> all the ARM related config options should be set to, but you really need
>> to look those over.  Also... the config file setup is confusing,
>> particularly config-armv7.  That seems to be used by only
>> kernel-armv7/kernel-armv7hl but not by the omap and tegra armv7 configs.
>> I think that is leading to some duplication of config settings.  Anyway,
>> look it over please.
> 
> Thanks, it's changed a fair bit again and this round omap goes away
> too, I'll try and get it sorted over the weekend.

I might be running a marathon on Sunday but otherwise want to assist!
I'll make a pass tomorrow as well :) Thanks so much everyone!

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] updated mongodb atomics patch

[Jon Masters]

On 02/19/2013 11:38 AM, Andrew Haley wrote:
> On 02/19/2013 04:38 PM, Jon Masters wrote:
>> We've a few dependency issues building this on F19 just now, but it will
>> build for v7 against 2.2.3 on F18 as well locally. If someone with more
>> knowledge of mongo would like to take a poke/test, cool. I have done a
>> literal port of the x86_64 implementation (hence it contains a few
>> superfluous bits intentionally). It'll need cleaning up.
> 
> Ai!  is there any reason not to use GCC builtins for this?

None...ish. There's the newer builtins I wrote about but that would
introduce a minimal compiler dependency (in the Linux case, not sure
about the Windows case - and the x86 code is not Linux specific, though
the ARM stuff I did is because there is no other good way to do it
without the use of the helpers). For now, I went with the same theme as
they already had (doing it arch-specific) but when I ping upstream I
will suggest they strongly consider finding a way to do it generically.



Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] updated mongodb atomics patch

[Jon Masters]

Hi Folks,

This is a work in progress. It builds on v7, but I've not tested yet.

We've a few dependency issues building this on F19 just now, but it will
build for v7 against 2.2.3 on F18 as well locally. If someone with more
knowledge of mongo would like to take a poke/test, cool. I have done a
literal port of the x86_64 implementation (hence it contains a few
superfluous bits intentionally). It'll need cleaning up.

Jon.
diff -urNp mongodb-src-r2.2.3_orig/src/mongo/bson/util/atomic_int.h mongodb-src-r2.2.3/src/mongo/bson/util/atomic_int.h
--- mongodb-src-r2.2.3_orig/src/mongo/bson/util/atomic_int.h	2013-01-31 10:18:33.0 -0500
+++ mongodb-src-r2.2.3/src/mongo/bson/util/atomic_int.h	2013-02-19 00:12:16.580841779 -0500
@@ -90,7 +90,9 @@ namespace mongo {
 void AtomicUInt::signedAdd(int by) {
 __sync_fetch_and_add(&x, by);
 }
-#elif defined(__GNUC__)  && (defined(__i386__) || defined(__x86_64__))
+#elif defined(__GNUC__)  && (defined(__i386__) || defined(__x86_64__) || defined(__arm__))
+
+#if defined(__i386__) || defined(__x86_64__)
 inline void AtomicUInt::set(unsigned newX) {
 asm volatile("mfence" ::: "memory");
 x = newX;
@@ -109,6 +111,31 @@ namespace mongo {
 );
 return r;
 }
+#endif
+
+#if defined(__arm__)
+inline void AtomicUInt::set(unsigned newX) {
+	asm volatile("mcr p15, 0, r0, c7, c10, 5");
+x = newX;
+}
+
+typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr);
+#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0x0fc0)
+
+inline unsigned atomic_int_helper(volatile unsigned *x, int val) {
+{
+int old, new;
+
+do {
+old = *ptr;
+new = old + val;
+} while(__kuser_cmpxchg(old, new, ptr));
+
+return old;
+}
+
+#endif
+
 AtomicUInt AtomicUInt::operator++() {
 return atomic_int_helper(&x, 1)+1;
 }
diff -urNp mongodb-src-r2.2.3_orig/src/mongo/platform/atomic_intrinsics_gcc.h mongodb-src-r2.2.3/src/mongo/platform/atomic_intrinsics_gcc.h
--- mongodb-src-r2.2.3_orig/src/mongo/platform/atomic_intrinsics_gcc.h	2013-01-31 10:18:33.0 -0500
+++ mongodb-src-r2.2.3/src/mongo/platform/atomic_intrinsics_gcc.h	2013-02-19 11:21:29.988914574 -0500
@@ -14,14 +14,23 @@
  */
 
 /**
- * Implementation of the AtomicIntrinsics::* operations for IA-32 and AMD64 systems using a
- * GCC-compatible compiler toolchain.
+ * Implementation of the AtomicIntrinsics::* operations for IA-32, AMD64, and 32-bit ARM
+ * systems using a GCC-compatible compiler toolchain.
  */
 
 #pragma once
 
 #include 
 
+#if defined(__arm__)
+typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr);
+#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0x0fc0)
+typedef int (__kuser_cmpxchg64_t)(const int64_t *oldval,
+  const int64_t *newval,
+  volatile int64_t *ptr);
+#define __kuser_cmpxchg64 (*(__kuser_cmpxchg64_t *)0x0f60)
+#endif
+
 namespace mongo {
 
 /**
@@ -37,48 +46,106 @@ namespace mongo {
 static T compareAndSwap(volatile T* dest, T expected, T newValue) {
 
 T result;
+
+#if defined(__i386__) || defined(__x86_64__)
 asm volatile ("lock cmpxchg %[src], %[dest]"
   : [dest] "+m" (*dest),
 "=a" (result)
   : [src] "r" (newValue),
 "a" (expected)
   : "memory", "cc");
+#endif
+
+#if defined(__arm__)
+if (__kuser_cmpxchg((int)expected, (int)newValue,
+(volatile int *)dest) == 0)
+		result = newValue;
+	else
+		result = *dest;
+#endif
+
 return result;
 }
 
 static T swap(volatile T* dest, T newValue) {
 
 T result = newValue;
+
+#if defined(__i386__) || defined(__x86_64__)
 // No need for "lock" prefix on "xchg".
 asm volatile ("xchg %[r], %[dest]"
   : [dest] "+m" (*dest),
 [r] "+r" (result)
   :
   : "memory");
+#endif
+
+#if defined(__arm__)
+do {
+// nothing
+} while (__kuser_cmpxchg((int)(*dest), (int)newValue,
+ (volatile int *)dest));
+#endif
+
 return result;
 }
 
 static T load(volatile const T* value) {
+
+#if defined(__i386__) || defined(__x86_64__)
 asm volatile ("mfence" ::: "memory");
 T result = *value;
 asm volatile ("mfence" ::: "memory");
+#endif
+
+#if defined(__arm__)
+asm volatile("mcr p15, 0, r0, c7, c10, 5");
+T result = *value;
+asm volatile("mcr p15, 0, r0, c7, c10, 5");
+#endif
+
 return result;
 }
 
 static void store(volatile T* dest, T newValue) {
+
+#if d

Re: [fedora-arm] Heads up: ARM build system outage for migration

[Jon Masters]

On 02/16/2013 01:19 PM, Peter Robinson wrote:
> The migration is complete, arm.koji is back up.
> 
> We're still testing and doing some clean up bits and pieces but the
> migration has been successful.

This is epic. Note that I had a quick sync with nirik on IRC a few
minutes ago with regard to e.g. kernel 3.7 (which won't work for
builders - config is missing namespace support needed for mock). I have
asked that we have a change control process for the time being that
involves a quick review of proposed updates to builders, followed by
testing of one builder for 12/24 hours (as an example) before updates
are pushed to all of the 20 hfp and 4 sfp builders currently defined.

Tomorrow (well, almost today) I will continue the 3.7/3.8 poking, and I
will send info on config deltas that I find to Peter.

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Announcing: Fedora ARM Technical Talks

[Jon Masters]

Hey everyone,

What would you like my next talk to be on? I will do a hardware debug
session soon, but meanwhile I am open to suggestions for the topic after
this week - this week John Dulaney is talking about Chromebooks!

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Video: Porting Fedora to 64-bit ARM systems

[Jon Masters]

Hi everyone,

I would like to share the video of my talk from FOSDEM:

http://video.fosdem.org/2013/maintracks/K.1.105/Porting_Fedora_to_64_bit_ARM_systems.webm

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Announcing: Fedora ARM Technical Talks

[Jon Masters]

On 02/15/2013 02:32 PM, Jon Masters wrote:

> Please see the following link for further details:
> https://fedoraproject.org/wiki/Architectures/ARM/Talks/ARMTechTalks
> 
> Today's talk is on debugging vexpress (Versatile Express) kernels
> running under qemu models with gdb. It will simply cover setting up a
> system for tracing a kernel with gdb and is introductory in nature.
> 
> I will host another Fedora ARM technical talk this afternoon. This will
> be my second, and so I am taking the opportunity to formalize this into
> a series of technical talks. Each 1-2 weeks I will host a deep dive
> technical session, on kernel debugging, atomic operations, and covering
> gnarly issues that I have helped track down (e.g. systemd-logind issue).
> This is not limited to me - drop me a line if you would like to give a
> talk, or would like to help organize this series :)

Minutes from today's ARM Tech Talk hosted by me:

HTML:
http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-15/fedora-arm-talks.2013-02-15-20.09.html

Text:
http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-15/fedora-arm-talks.2013-02-15-20.09.txt

Raw:
http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-15/fedora-arm-talks.2013-02-15-20.09.log.html

Tune in next Friday at 20:00 UTC, when John Dulaney will tell us all
about installing Fedora onto the Samsung ARM-powered Chromebook!

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Announcing: Fedora ARM Technical Talks

[Jon Masters]

On 02/15/2013 02:32 PM, Jon Masters wrote:

> Please see the following link for further details:
> https://fedoraproject.org/wiki/Architectures/ARM/Talks/ARMTechTalks

> Today's talk is on debugging vexpress (Versatile Express) kernels
> running under qemu models with gdb. It will simply cover setting up a
> system for tracing a kernel with gdb and is introductory in nature.

For today's meeting at 20:00 UTC (15:00 EST, in 20 minutes or so from
now), you will want the following files:

* The Versatile Express images downloaded from the wiki instructions:
http://fedoraproject.org/wiki/Architectures/ARM/F18/Versatile_Express
* A debuginfo kernel for the 3.6.10-8 kernel that shipped with F18:
http://armpkgs.fedoraproject.org/packages/kernel/3.6.10/8.fc18/armv7hl/kernel-debuginfo-3.6.10-8.fc18.armv7hl.rpm

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Announcing: Fedora ARM Technical Talks

[Jon Masters]

Hi Folks,

Please see the following link for further details:
https://fedoraproject.org/wiki/Architectures/ARM/Talks/ARMTechTalks

Today's talk is on debugging vexpress (Versatile Express) kernels
running under qemu models with gdb. It will simply cover setting up a
system for tracing a kernel with gdb and is introductory in nature.

I will host another Fedora ARM technical talk this afternoon. This will
be my second, and so I am taking the opportunity to formalize this into
a series of technical talks. Each 1-2 weeks I will host a deep dive
technical session, on kernel debugging, atomic operations, and covering
gnarly issues that I have helped track down (e.g. systemd-logind issue).
This is not limited to me - drop me a line if you would like to give a
talk, or would like to help organize this series :)

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Fedora Linaro Cross-Tools

[Jon Masters]

On 02/12/2013 01:08 PM, Al Stone wrote:
> On 02/12/2013 10:58 AM, Dan Horák wrote:
>> Al Stone píše v Út 12. 02. 2013 v 10:49 -0700:
>>> Greetings.
>>>
>>> For those that have seen or heard about some of the work going
>>> on with Fedora and Linaro [0], there are times when it makes
>>> sense to do work with the cross-compilers for ARMv7/ARMv8 that
>>> Linaro provides.
>>>
>>> Unfortunately, these have not until now been packaged for Fedora.
>>
>> I think that instead of creating a new single purpose cross-tools in
>> Fedora we should put the effort into the existing cross-binutils and
>> cross-gcc packages

> I don't disagree.  The problem is that they are currently very
> different source trees; if I can reconcile that, I'll absolutely
> put them in the existing cross-binutils and cross-gcc packages.

I second both viewpoints :) The fact is, Linaro have a toolchain that
contains various bits being worked on, and it absolutely makes sense to
allow folks to leverage that work. Thanks, Al, for doing this.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] arm software floating point support going forward

[Jon Masters]

Derek,

It is less "powers that be" than a collaborative effort/decision. We do not 
have resources to justify keeping v5 alive but you are free to coordinate with 
others and pick it up, in the same way that Seneca are to own v6 support (maybe 
Seneca can even help with build system setup if you ask them). Do you have any 
interest in driving that?

You will find the ominous powers that be are in fact a bunch of us doing the 
work who are overloaded enough to keep just v7 and v8 on track :) For those who 
are devastated and have no v7 hardware, ping me off list and maybe I can look 
into getting a couple of v7 boards out there.

Jon.
-- 
Sent from my phone. Please excuse brevity.

Derek Atkins  wrote:

Quentin Armitage  writes:

> since there has been no major objection i will disable building
> armv5tel rpms in rawhide before the mass rebuild.
> 
> Dennis
> 
> I guess it's too late now, but I got a few days behind on my list emails. I
> use 2 * Sheevaplugs and 2 * Dreamplugs with Fedora, and would be very
> disappointed to see support for them being dropped from Fedora. For me, I
> still see quite a lifetime in them for what they are doing.

I've mentioned multiple times my hope to keep kirkwood support in
Fedora, but alas it feels like the powers that be just don't care about
us *plug users.  :(   If I want to continue using my plugs I guess I'll
have to learn Debuntu.  :(

> Quentin Armitage

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] IRC - PandaBoard

[Jon Masters]

Hello masta,

I tested pkexec. It worked. Yumex will be fine.

I am traveling to Brussels at this time.

Jon.

Masta wrote:

---begin log---
jonmasters [14:35:40]  jonmasters: thanks for
testing the panda, did you notice yumex was happy?
---end of log---
-- 
Sent from my phone. Please excuse brevity.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] IRC - PandaBoard

[Jon Masters]

Hello masta,

I tested pkexec. It worked. Yumex will be fine.

I am traveling to Brussels at this time.

Jon.

Masta wrote:

>---begin log---
>jonmasters [14:35:40]  jonmasters: thanks for
>testing the panda, did you notice yumex was happy?
>---end of log---

-- 
Sent from my phone. Please excuse brevity.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] OMAP F18 RC internal image test success

[Jon Masters]

http://www.flickr.com/photos/jonmasters/sets/72157632664725340/
-- 
Sent from my phone. Please excuse brevity.

Jon Masters  wrote:

Hi Folks,

I delayed leaving and changed plans this morning while I extensively tested 
OMAP. The RC image made internally within RC by David works fine, and I can 
once again confirm that the display is working. Ship it.

Jon.
-- 
Sent from my phone. Please excuse brevity.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] OMAP F18 RC internal image test success

[Jon Masters]

Obviously I am not saying to ship the internal test image. Only that it works 
just fine and I consider OMAP ready for release. It is no worse than beta.
-- 
Sent from my phone. Please excuse brevity.

Jon Masters  wrote:

Hi Folks,

I delayed leaving and changed plans this morning while I extensively tested 
OMAP. The RC image made internally within RC by David works fine, and I can 
once again confirm that the display is working. Ship it.

Jon.
-- 
Sent from my phone. Please excuse brevity.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Boot log from 3.6.10-8 PandaBoard

[Jon Masters]

Also this:

Fedora release 18 (Spherical Cow)
Kernel 3.6.10-8.fc18.armv7hl.omap on an armv7l (ttyO2)

panda-f18-v7hl login: jcm
Password:
Last login: Wed Jan 30 16:49:36 on ttyO2
[jcm@panda-f18-v7hl ~]$ pkexec ls
 AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/bin/ls' as the super user
Authenticating as: Jon Masters (jcm)
Password:
 AUTHENTICATION COMPLETE ===
anaconda-ks.cfg  install.log  install.log.syslog

:)

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Boot log from 3.6.10-8 PandaBoard

[Jon Masters]

U-Boot SPL 2012.10 (Oct 21 2012 - 02:25:07)
OMAP4460 ES1.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2012.10 (Oct 21 2012 - 02:25:07)

CPU  : OMAP4460 ES1.1
Board: OMAP4 Panda
I2C:   ready
DRAM:  1 GiB
MMC:   OMAP SD/MMC: 0
Using default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  3  2  1  0 
SD/MMC found on device 0
reading uEnv.txt

281 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
reading uInitrd

12661984 bytes read
reading uImage

3778856 bytes read
## Booting kernel from Legacy Image at 8030 ...
   Image Name:   3.6.10-8.fc18.armv7hl.omap
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3778792 Bytes = 3.6 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 8160 ...
   Image Name:   initramfs
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:12661920 Bytes = 12.1 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.6.10-8.fc18.armv7hl.omap (mockbuild@) (gcc 
version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Tue Jan 29 14:45:38 EST 
2013
[0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: OMAP4 Panda board
[0.00] Memory policy: ECC disabled, Data cache writealloc
[0.00] OMAP4460 ES1.1
[0.00] PERCPU: Embedded 9 pages/cpu @c108f000 s13568 r8192 d15104 u36864
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 258304
[0.00] Kernel command line: console=ttyO2,115200n8 vram=16M 
root=UUID=8363be44-67e2-4c98-b1cd-2a1f5632f578 ro rootwait omapdss.def_disp=dvi
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] allocated 2097152 bytes of page_cgroup
[0.00] please try 'cgroup_disable=memory' option if you don't want 
memory cgroups
[0.00] Memory: 753MB 264MB = 1017MB total
[0.00] Memory: 1009172k/1009172k available, 39404k reserved, 270336K 
highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xf000 - 0xff00   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xef80   ( 760 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc06ab10c   (6797 kB)
[0.00]   .init : 0xc06ac000 - 0xc0717500   ( 430 kB)
[0.00]   .data : 0xc0718000 - 0xc07a49d8   ( 563 kB)
[0.00].bss : 0xc07a49fc - 0xc0886120   ( 902 kB)
[0.00] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, 
Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[0.00] NR_IRQS:460
[0.00] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for 
dpll_mpu_m2_ck.
[0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
[0.00] omap_hwmod: sys_32k_ck: missing clockdomain for sys_32k_ck.
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 
131071999ms
[0.00] OMAP clocksource: 32k_counter at 32768 Hz
[0.00] Console: colour dummy device 80x30
[0.000183] Calibrating delay loop... 1392.74 BogoMIPS (lpj=5439488)
[0.070251] pid_max: default: 32768 minimum: 301
[0.070556] Security Framework initialized
[0.070587] SELinux:  Initializing.
[0.070983] Mount-cache hash table entries: 512
[0.072570] Initializing cgroup subsys cpuacct
[0.072601] Initializing cgroup subsys memory
[0.072631] Initializing cgroup subsys devices
[0.072662] Initializing cgroup subsys freezer
[0.072662] Initializing cgroup subsys net_cls
[0.072692] Initializing cgroup subsys blkio
[0.072692] Initializing cgroup subsys perf_event
[0.072875] CPU: Testing write buffer coherency: ok
[0.072937] ftrace: allocating 20030 entries in 40 pages
[0.109558] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.109771] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 
counters available
[0.109893] Setting up static identity map for 0x804c66c8 - 0x804c6720
[0.109924] L310 cache c

[fedora-arm] Photos from FUDCon - including whiteboard

[Jon Masters]

Hi everyone,

Here are the photos from the recent FUDCon that I uploaded:

http://www.flickr.com/photos/jonmasters/sets/72157632599464512/

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] ARMv8 Bootstrap rootfs cannot be cloned

[Jon Masters]

On 01/29/2013 05:24 PM, Al Stone wrote:

> Well, we now know the workaround; do the commit, then ssh into fp.o and
> run git update-server-info in the repo.  Ugly, but it works.
> 
> I'm not sure this is fixable, but I'll poke the infrastructure folks
> and see what we can do.

Thanks Al.

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Distributing DTB's for Fedora 18 RC1

[Jon Masters]

Note at this point it is only Tegra we need a solution for to get F18 GA. We 
will resolve more in F19 or even as an update but given it is just one platform 
(TrimSlice), and that platform has a pretty reasonable U-Boot, let's get 
something resolved today that works for Tegra and move on.
-- 
Sent from my phone. Please excuse brevity.

Peter Robinson  wrote:

On Sun, Jan 27, 2013 at 7:22 PM, Brendan Conoboy  wrote:
> On 01/27/2013 08:51 AM, Peter Robinson wrote:
>>
>> Basically when you do a "make dtbs" it makes the dtbs that match the
>> kernel config. So we end up with the following with the 3.7.x kernels
>> that we have in F-18 and they're in /boot/dtb-%{uname}. Note this
>> scheme can be tweaked but I figured getting something there to start
>> with was better than nothing.
>
>
> Note: This will require changes to grubby's new-kernel-pkg similar to what
> was necessary to run mkimage for uboot.  The principle benefit of having a
> separate package is that the dtbs land somewhere with a consistent name,
> enabling grubby, boot.scr and uEnv.txt to remain static.

grubby needs to deal with all of those because the kernel doesn't
install anything into uboot, the naming scheme is the same and grubby
will need to be able to deal with dtb files so I didn't see that it
added any complexity because the same scheme is already being dealt
with for both the kernel and the initrd.

Peter
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Fixed F18 remaining blocker: pkexec/etc.

[Jon Masters]

Hi everyone,

For those not on IRC, I have identified the last remaining F18 blocker.
You can read the gory details on my G+ and I'll write a blog, but
briefly the summary is that systemd-logind is used to manage user
sessions[0]. It talks over D-BUS (what doesn't these days) and is
collaborating with a custom systemd pam plugin which runs during session
setup. During a pkexec (polkit1) invocation of a binary, a call is made
to systemd-logind to setup a new session, which it does. But when it
does this, on systems without CONFIG_AUDITSYSCALL enabled[1], it cannot
see /proc/pid/sessionid, and decides that this means there cannot be an
existing session (the one you used to invoke pkexec).

When a new session is created, systemd opens a special fifo for the
session and registers to poll on this so that it can see if the session
died mysterously and needs cleaning up. In the case of a sudo-like
command, it needs to clean this fifo up ahead of time so that it won't
later (right as the new processing being driven by pkexec is spawned)
kill what you just tried to run. But if you do not have auditing setup,
systemd will never do any of these things and its "login manager" will
kill whatever you are trying to run with a SIGTERM. That's why you see
those "Terminated" messages and errors when trying to run e.g. yumex.

I'll write this up using better and more accurate language. I just
wanted to throw something out there to say that we know what the problem
is and that a fixed kernel package will be built soon.

Jon.

[0] see the FreeDesktop docs on heads and sessions, also see loginctl.

[1] This is set in the base config but is not inherited on all of the
3.6 kernel variants, and a similar though slightly different situation
exists on 3.7. Peter is fixing the kernel config with a new 3.6 kernel.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Fedora ARM VFAD - 2013-01-23

[Jon Masters]

On 01/23/2013 04:09 AM, Peter Robinson wrote:
> 
> On 23 Jan 2013 06:39, "Jens Petersen"  > wrote:
>>
>> > 3) ghc - using LLVM as compiler, as a result incorrect triplet
>>
>> Not sure what this is referring to: ghc ARM devel for F18 is
>> basically done (except for a few minor libs appearing
>> in the Branch report that need rebuilding) and working fine.
>>
>> Maybe this is referring to this Rawhide llvm issue
>> https://bugzilla.redhat.com/show_bug.cgi?id=893294
>> which I don't think should be on the F18ARMBLocker list,
>> and hopefully will be fixed in llvm-3.1-13.fc19
>> which is currently building.
> 
> I put it on the f18 blocker lust because there's currently no difference
> between the llvm in both releases and I want to be sure we don't have
> the same problem hiding in f18 too.

For completeness, I will bring this up with ARM/Linaro/upstream (fixing
the triplet) and then we'll get ghc built properly using LLVM. I will
also repeat my previous caveat that it seems we (Fedora) are building a
house of cards by growing dependencies on a second toolchain that we
don't have resources to support. But all the other distributions seem to
be quite happy to do the same in the interest of shiny shiny :)

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Distributing DTB's for Fedora 18 RC1

[Jon Masters]

On 01/22/2013 03:54 PM, Dennis Gilmore wrote:

> appending the dtb seems to work fine for a pandaboard, i've never
> personally had a pandaboard boot when loading the dtb separately

Hi Dennis, Jon, others,

It is good to know that the append option works, however since it is not
required to use a dtb on OMAP in order for it to boot both the 3.6 and
the 3.7 update kernel, I would like to remind everyone that we have
decided not to ship an OMAP dtb in F18 final. We can return to this
later, but our focus this week must be on the immediate F18 need.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] ELF reloc type defines

[Jon Masters]

Great! Thanks. I wrote up some text on relocations for an aarch64 
article...need to finish that and mention 32-bit too.
-- 
Sent from my phone. Please excuse formatting and brevity.

Petr Machata  wrote:

Jerry James  writes:

> Upstream has one problem, though.  On the other supported platforms
> (Debian, various flavors of BSD), the reloc type defines
> (R_ARM_MOVT_ABS, etc.) are available in some userspace header.  I see
> them in the Llinux kernel sources, in arch/arm/include/asm/elf.h, but
> neither GCL upstream nor I can find them in any available userspace
> header on Fedora 18.  Does anybody know if they are available
> somewhere?

The relocation numbers are generally in elf.h distributed by glibc
(elf/elf.h in the source).  R_ARM_MOVT_ABS in particular is absent from
that file though.  I see it listed in [1], so I I'll post a patch adding
these missing defines later today.

Thanks,
PM

[1] ELF for the ARM® Architecture
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] FUDCon ARM related followup

[Jon Masters]

Always was done with yaboot. Do we know if OLPC will move to UEFI?
-- 
Sent from my phone. Please excuse formatting and brevity.

Peter Robinson  wrote:

> - Original Message -
>> From: Peter Robinson 
>> To: Development discussions related to Fedora 
>> Cc: arm@lists.fedoraproject.org
>> Sent: Monday, January 21, 2013 6:28 PM
>> Subject: Re: [fedora-arm] FUDCon ARM related followup
>>
>> On Mon, Jan 21, 2013 at 1:57 PM, Bruno Wolff III  wrote:
>>>  On Sun, Jan 20, 2013 at 23:56:49 -0500,
>>>Jonathan Masters  wrote:


  We had a number of conversations about how to involve more people in
  Fedora on ARM. We also had many other conversations that are being
>> minuted
  on the wiki, with more notes and links to follow. Now is a great time
>> to
  join arm@ and add your input.
>>>
>>>
>>>  Since a number of Fedora developers where given XO 1.75s last summer,
>>>  getting Fedora builds for those people might be a way to get more testing.
>>>  (Yeah, they mostly use Fedora stuff now, but they don't use a Fedora
>>>  kernel.)
>>>
>>>  I have been testing OLPC builds, but that wipes my customizations, and
>> I'd
>>>  rather do more normal Fedora testing with it.
>>
>> Fedora kernels don't support them because they're not all up stream
>> and we don't have support for OFW even where their kernels are
>> upstream. That being said you can use Fedora relatively easily while
>> still doing an initial install with the XO image and getting XO kernel
>> updates but still receiving standard Fedora updates and installing all
>> the other standard Fedora stuff using yum. I documented it here:
>>
>> http://nullr0ute.com/2012/09/using-fedora-on-your-shiny-new-olpc-xo/
>
> It doesn't seem like OF would be that hard to support, given PPC and sparc 
> both use it, and it isn't -that- different then uBoot.

Probably not too hard to support but I believe PPC support is via
yaboot (or maybe now grub2) layered on top of OFW rather than directly
supporting OFW.

Peter
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] 3.7 kernel plan

[Jon Masters]

On 01/15/2013 05:54 PM, Peter Robinson wrote:
> On Tue, Jan 15, 2013 at 8:40 PM, Jon Masters  wrote:
>> Hi Peter,
>>
>> I am hoping to get time this evening to finish poking at the highbank
>> kernel (in an all day meeting). I apologize that is dragging out. I need
>> to figure out what's up with SATA detection. David is going to pick this
>> up from me tomorrow and I'll hand over where I get to.
>>
>> Nonetheless...I need to know what we want to do in response to the PA
>> 3.7 "zero day" update plan. I assume we can hold off an upgrade until at
>> least next week (post-FUDCon). Can you let us know your intention?
> 
> I'm awaiting for the fix you've been promising "tomorrow" for the last 3 
> weeks.

Good point :) Sadly, it went from just an errata issue to a non-booting
SATA issue as well. I'm handing it over to David after I get done this
evening as he's not at FUDCon and can pick up the slack this week.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] 3.7 kernel plan

[Jon Masters]

Hi Peter,

I am hoping to get time this evening to finish poking at the highbank
kernel (in an all day meeting). I apologize that is dragging out. I need
to figure out what's up with SATA detection. David is going to pick this
up from me tomorrow and I'll hand over where I get to.

Nonetheless...I need to know what we want to do in response to the PA
3.7 "zero day" update plan. I assume we can hold off an upgrade until at
least next week (post-FUDCon). Can you let us know your intention?

Jon.
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Announcing Fedora 18 Beta for Allwinner A10 based devices

[Jon Masters]

On 01/15/2013 03:20 PM, Peter Robinson wrote:
> On Tue, Jan 15, 2013 at 7:40 PM, Jon Masters  wrote:
>> On 01/15/2013 11:43 AM, Peter Robinson wrote:
>>> On Tue, Jan 15, 2013 at 10:50 AM, David Marlin  wrote:
>>>>
>>>> Hans de Goede wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I'm very happy to announce the availability of Fedora 18 Beta for
>>>>> Allwinner A10 based devices. This release is based on the official
>>>>> Fedora 18 beta for ARM images.
>>>>
>>>>
>>>> Do you have a kernel RPM for the A10 yet?  I know Fu Wei was working on
>>>> packaging the 3.4 A10 kernel, but I'm not sure if you have discussed this
>>>> with him.
>>>>
>>>>
>>>>>
>>>>> You can download it here:
>>>>> http://scotland.proximity.on.ca/contrib-images/hansg
>>>>
>>>>
>>>> will do.
>>>>
>>>>
>>>>>
>>>>> It is important to read the README, the image standard comes without
>>>>> u-boot pre-loaded since u-boot is board specific. The image includes
>>>>> a user-friendly simple script to install the right u-boot for
>>>>> your board, but if you simply xzcat the image to an sdcard, and then
>>>>> boot your device with the sdcard, things will *not* work.
>>>>
>>>>
>>>>
>>>> Have you considered adding support for the A10 boards (Gooseberry,
>>>> Cubieboard, etc.) to the uboot-tools package:
>>>>
>>>>   http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=98609
>>>>
>>>> There is already support for several ARM boards (beagle, origen, panda,
>>>> etc.), so there are examples of how to add a new board.  Then we can simply
>>>> install the right U-Boot when the image is created.
>>>
>>> Not possible as the support for the A10 isn't upstream in uboot as yet
>>> and it's still currently a fork. Like the kernel there are plans to do
>>> it but it's not been done as yet.
>>
>> Initial A1X is in 3.8. So we'll get to have some fun.
> 
> It's state is similar to that of mvebu in 3.7 in that it has the core
> SoC support and serial console. There's nothing else really.

Yea. Initial :) But that bodes well for 3.9 and later. I like the level
of effort going into mvebu since 3.7, for example. I'm happy to see that
this shows we'll have an upstream kernel soon for both.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Announcing Fedora 18 Beta for Allwinner A10 based devices

[Jon Masters]

On 01/15/2013 11:43 AM, Peter Robinson wrote:
> On Tue, Jan 15, 2013 at 10:50 AM, David Marlin  wrote:
>>
>> Hans de Goede wrote:
>>>
>>> Hi All,
>>>
>>> I'm very happy to announce the availability of Fedora 18 Beta for
>>> Allwinner A10 based devices. This release is based on the official
>>> Fedora 18 beta for ARM images.
>>
>>
>> Do you have a kernel RPM for the A10 yet?  I know Fu Wei was working on
>> packaging the 3.4 A10 kernel, but I'm not sure if you have discussed this
>> with him.
>>
>>
>>>
>>> You can download it here:
>>> http://scotland.proximity.on.ca/contrib-images/hansg
>>
>>
>> will do.
>>
>>
>>>
>>> It is important to read the README, the image standard comes without
>>> u-boot pre-loaded since u-boot is board specific. The image includes
>>> a user-friendly simple script to install the right u-boot for
>>> your board, but if you simply xzcat the image to an sdcard, and then
>>> boot your device with the sdcard, things will *not* work.
>>
>>
>>
>> Have you considered adding support for the A10 boards (Gooseberry,
>> Cubieboard, etc.) to the uboot-tools package:
>>
>>   http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=98609
>>
>> There is already support for several ARM boards (beagle, origen, panda,
>> etc.), so there are examples of how to add a new board.  Then we can simply
>> install the right U-Boot when the image is created.
> 
> Not possible as the support for the A10 isn't upstream in uboot as yet
> and it's still currently a fork. Like the kernel there are plans to do
> it but it's not been done as yet.

Initial A1X is in 3.8. So we'll get to have some fun.

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Createrepo update

[Jon Masters]

Hi Mark,

Please ping the Seneca folks for a copy of the RPM. Also it is in koji as a 
scratch build - see my previous email to arm@ for a link. Sorry I left my 
laptop in SF when I came down to the valley for meetings today (going to pick 
up soon) so can't grab the rpm for you right now.

Jon.

-- 
Sent from my iPad

On Jan 14, 2013, at 9:58, Jon Masters  wrote:

> ---begin log---
> jonmasters [17:57:06]  Hey, I may be running into a createrepo 
> bug that dgilmore says you fixed a while back but that might not have gotten 
> into the updates for f17. you wouldn't happen to have an armv7hl rpm that I 
> could install on my builders to get past the issue?
> ---end of log---
> 
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Quick update

[Jon Masters]

Hey guys,

I spent a bunch of time yesterday preparing for a week of travel. But I have 
mongo almost taken care of, and a scratch 3.7 kernel that I am testing. I will 
most likely need to get Mark to help diagnose a SATA issue - will followup on 
that after I do a bit more poking. Will send an update on Monday on other 
outstanding issues on my plate to keep the ball rolling as we approach FUDCon.

Jon.

-- 
Sent from my iPad
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Important for FUDCon: Airport pickup, RasPi hangout, and games

[Jon Masters]

On 01/10/2013 05:12 PM, Ruth Suehle wrote:

> -
> RASPBERRY PI MEETUP
> -
> 
> Thursday evening at 8 p.m., there is a global Raspberry Pi meetup over
> Google Hangout. MAKE is the host and guests are Matt Richardson and
> Shawn Wallace, authors of Getting Started with Raspberry Pi. All meetup
> attendees will receive a free PDF download of MAKE Magazine Volume 33.
> The guests will talk about the projects featured in that issue and
> discuss everything Pi. There's a live chat where you can ask them
> questions as well as share your own projects.
> 
> We'd like to gather to join the Hangout and then hang out amongst
> ourselves talking Pi. Please add your name here if you'd like to join us
> so that we're sure to have enough room:
> 
> https://fedoraproject.org/wiki/FUDCon:Lawrence_2013#Agenda

Hi Ruth,

Thanks for mentioning this. Alas, I will not arrive in time to attend,
but others in the Fedora ARM community will probably be able to
participate. Raspberry Pi is not an officially supported target[0], but
it is covered by a popular Remix that the team at Seneca are working on.
I believe they arrive on the Thursday afternoon, so can probably attend.
I do intend to bring a model B Raspi with me though :)

Jon.

[0] users@ folks wondering why: there is no upstream kernel yet, so it
is not within Fedora remit to provide support for this target.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Opera build?

[Jon Masters]

On 01/10/2013 04:07 PM, jonathan chetwynd wrote:
> where could I request a build of Opera?
> 
> Fedora X86/i386 nightly rpm builds are here:
> http://snapshot.opera.com/unix/latest

Hi Jonathan,

You'd have to ask Opera about Fedora ARM builds of their commercial
products.

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Status on Cubie/All Winner A10

[Jon Masters]

On 01/09/2013 10:55 PM, Daniel Veillard wrote:

> P.S.: BTW I'm in china, and can use (or rather my wife can :) the
>   taobao online shop to order boards directly in case of interest
>   ping me if that's the case
>   http://item.taobao.com/item.htm?id=16944193746

Daniel!

Thanks for the reminder that you are living in China these days :) I
hope life is delightful. I wonder if I can introduce you to Fu Wei, who
has also been looking into this (but is beginning some other work too).
He is in Shanghai, and on your timezone. Perhaps Fu Wei, you can let
Daniel know where you got to and point him to anything he can test?

Thanks,

Jon.

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] gmp issue resolution

[Jon Masters]

On 01/04/2013 03:30 AM, Peter Robinson wrote:
> On Fri, Jan 4, 2013 at 3:39 AM, Jon Masters  wrote:
>> Hi Peter,
>>
>> So the issue we have been experiencing with gmp is actually binutils
>> related. There is a known regression in binutils wherein certain
>> assembly is not recognized as ARM if it contains extraneous space!
>>
>> http://lists.gnu.org/archive/html/bug-binutils/2012-11/msg00104.html
>>
>> I'm copying Nick Clifton, because he'll want to make sure that
>> ultimately we get the fix into binutils in F19/rawhide. But in the
>> interim, you can go ahead and apply the following tested patch to gmp
>> that just removes the extraneous space in udiv.asm for ARM. Once
>> binutils is fixed, this patch is obviated and harmless.
> 
> We'll need the fix in F-18 too then as they both contain the same
> release of binutils. Upstream BZ is
> http://sourceware.org/bugzilla/show_bug.cgi?id=14887 Nick do you want
> a RHBZ too?

Great. Meanwhile, I expect my gmp patch will apply as-is to F18 also if
you want to go and apply that. It's the same 5.0.5 release of gmp.

(I'm not online yet, I just got up to check on this - back later)

Jon.


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm