[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 <dcall...@redhat.com> 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 <dcall...@redhat.com>
> 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 <j...@redhat.com> 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 <pbrobin...@gmail.com> wrote:
>>> 
>>>> On Fri, Apr 28, 2017 at 7:43 AM, Jon Masters <j...@redhat.com> 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 <pbrobin...@gmail.com> wrote:
> 
>> On Fri, Apr 28, 2017 at 7:43 AM, Jon Masters <j...@redhat.com> 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 <jwbo...@fedoraproject.org> wrote:
> 
>> On Wed, Sep 14, 2016 at 3:55 PM, Jon Masters <j...@redhat.com> 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 <j...@redhat.com> 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
are, and that's been helpful with obscure things like emacs crashing due
to a page size assumption or two on arrow pres

[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 

[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 brooks...@gmail.com 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 pwha...@redhat.com 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

[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] 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

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] 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 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

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] 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

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] 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 jonat...@jonmasters.org
Sent: Fri Jun 28 08:54:41 EDT 2013
To: Will Deacon will.dea...@arm.com
Cc: linux-arm-ker...@lists.infradead.org 
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 will.dea...@arm.com 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 : [c001dbd4]lr : [c001db78]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] [c001dbd4] (check_and_switch_context+0x3c0/0x44c)
from
 [c05994b8] (__schedule+0x4ac/0x750)
 [   12.409193] [c05994b8] (__schedule+0x4ac/0x750) from
[c0048854]
 (do_wait+0x1ec/0x244)
 [   12.417834] [c0048854] (do_wait+0x1ec/0x244) from [c004988c]
 (SyS_wait4+0xa8/0xc8)
 [   12.426206] [c004988c] (SyS_wait4+0xa8/0xc8) from [c000e1a0]
 (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

Yep, the -IS variants are only available on SMP cores.

 Now I think it's personally just easier to only turn on that errata

[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

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

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

[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 jonat...@jonmasters.org
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 : [c001dbd4]lr : [c001db78]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] [c001dbd4] (check_and_switch_context+0x3c0/0x44c) from
[c05994b8] (__schedule+0x4ac/0x750)
[   12.409193] [c05994b8] (__schedule+0x4ac/0x750) from [c0048854]
(do_wait+0x1ec/0x244)
[   12.417834] [c0048854] (do_wait+0x1ec/0x244) from [c004988c]
(SyS_wait4+0xa8/0xc8)
[   12.426206] [c004988c] (SyS_wait4+0xa8/0xc8) from [c000e1a0]
(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] 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 image sdcard
 
 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]

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] 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] 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 jwbo...@redhat.com 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 jwbo...@redhat.com 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

[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 AtomicIntrinsicsT::* operations for IA-32 and AMD64 systems using a
- * GCC-compatible compiler toolchain.
+ * Implementation of the AtomicIntrinsicsT::* operations for IA-32, AMD64, and 32-bit ARM
+ * systems using a GCC-compatible compiler toolchain.
  */
 
 #pragma once
 
 #include boost/utility.hpp
 
+#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 defined(__i386__) || 

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.

/stream of consciousness...

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

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

[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

[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] 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

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] 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] 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 j...@redhat.com 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]

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

Jon Masters j...@redhat.com 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

[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] masta:#fedora-arm 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] masta:#fedora-arm 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] 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 warl...@mit.edu wrote:

Quentin Armitage quen...@armitage.org.uk 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] 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] 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 pbrobin...@gmail.com wrote:

On Sun, Jan 27, 2013 at 7:22 PM, Brendan Conoboy b...@redhat.com 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

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] 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 peter...@redhat.com
 mailto:peter...@redhat.com 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] 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 pbrobin...@gmail.com wrote:

 - Original Message -
 From: Peter Robinson pbrobin...@gmail.com
 To: Development discussions related to Fedora de...@lists.fedoraproject.org
 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 br...@wolff.to wrote:
  On Sun, Jan 20, 2013 at 23:56:49 -0500,
Jonathan Masters j...@redhat.com 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] 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 pmach...@redhat.com wrote:

Jerry James loganje...@gmail.com 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] 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] 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 dmar...@redhat.com 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] 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] 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 j...@redhat.com 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] 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 j...@edison.jonmasters.org wrote:

 ---begin log---
 jonmasters [17:57:06] mlangsdorf 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] 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] 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] 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 j...@redhat.com 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

[fedora-arm] gmp issue resolution

[Jon Masters]

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.

Jon.
diff -urNp gmp-5.0.5_orig/mpn/arm/udiv.asm gmp-5.0.5/mpn/arm/udiv.asm
--- gmp-5.0.5_orig/mpn/arm/udiv.asm	2012-05-06 07:19:50.0 -0400
+++ gmp-5.0.5/mpn/arm/udiv.asm	2013-01-03 21:36:06.780775997 -0500
@@ -48,7 +48,7 @@ L(oop):	divstep(n1,n0,d)
 	teq	r12, #0
 	bne	L(oop)
 
-	str	n1, [ rem_ptr ]		C store remainder
+	str	n1, [rem_ptr]		C store remainder
 	adc	r0, n0, n0		C quotient: add last carry from divstep
 	mov	pc, lr
 
@@ -87,7 +87,7 @@ L(oop2):
 	addcs	n0, n0, #1		C adjust quotient
 
 L(_even_divisor):
-	str	n1, [ rem_ptr ]		C store remainder
+	str	n1, [rem_ptr]		C store remainder
 	mov	r0, n0			C quotient
 	ldmfd	sp!, { r8, pc }
 EPILOGUE(mpn_udiv_qrnnd)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Fedora-ARM Team Shirts

[Jon Masters]

Hi Folks,

Happy New Year once again, and I hope you had a relaxing break (if you
didn't get time off, I hope you nonetheless enjoyed the holidays).

I have heard from ARM that we can use the Connected Community logo on a
shirt, but there are some restrictions. These include needing to get
their approval on the incorporating design proof, which is not an
unreasonable thing for them to ask of us. There might /just/ be time to
pull off some shirts, if we were to turn this around quickly. Therefore,
we will discuss this on the call today. I am copying Ruth and Robyn on
this mail so that we can get their input on any printing options we
might have at this late stage, if we had a final ready to go before next
week. I am thinking we would not print too many shirts, so we would have
various options available, including a local service.

Comments and opinions are welcome.

Jon.

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

[fedora-arm] Fedora ARM status meeting minutes for 2012-12-19

[Jon Masters]

Hi everyone,

I would like to share the minutes from yesterday's Fedora ARM meeting.
In particular, those on devel@ might be interested in our desire to
discuss PA at FUDCon. At FUDCon, we will have a 24 node Calxeda
EnergyCore (highbank) server that will demonstrate various capabilities
of the (multiple) build server systems that will be available in PHX. At
FUDCon we will discuss both our 32-bit build plans and PA push.
Separately, there will be 64-bit discussions. We would welcome
suggestions (on the arm@ list please) from those who have input on the
best format for the PA discussions during the FUDCon event in January.

Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-12-19/fedora-meeting-1.2012-12-19-21.01.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-12-19/fedora-meeting-1.2012-12-19-21.01.txt
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-12-19/fedora-meeting-1.2012-12-19-21.01.log.html

Additionally, I can update the status of the following:

1a). TC3 images were tested on various boards:

https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-12-20-VFAD-Fedora_18_Beta

1b). I did test on GuruPlug. It's the same as before (works, but
requires modifications to U-Boot configuration and boot setup). This
will not be a beta blocker but it will require that I write up better.

1c). Both the Panda and Panda ES have been tested.

1d). David did run the VFAD as planned.

1f). We hope to all live long enough to have the End of the World beta
release posted later on today.

Jon.

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

Re: [fedora-arm] Fedora-ARM Team Shirts

[Jon Masters]

On 12/21/2012 02:53 AM, Andrew Wafaa wrote:
 On Fri, 2012-12-21 at 07:39 +, j...@redhat.com wrote:
 On 12/21/2012 02:17 AM, Peter Robinson wrote:

 The Fedora project has a couple of approved companies for making of
 t-shirts and other things and they know the logo guidelines process
 etc. I suggest once we have details of the ARM stuff we can probably
 ask OSAS for assistance or direction, I can ask/take the task to see
 if they can assist us.

 On a related note, I'll ping nirik about the download page the websites
 team made as I have permission from ARM to use the ARM Powered logo on
 that page (only). The ARM logos come with an 18 page usage guidelines
 document, and it's pretty restricted what can officially use the logo.
 Sure, many websites and projects infringe, but we're going to dot every
 i and cross every t on this stuff - I have no interest in ever annoying
 ARM. I'll inquire about t-shirts...that will be complex.

 
 Thanks for making sure things are dotted and crossed :-) Unfortunately
 it may be tight to get clearance before the end of this year. I will try
 my best to see what can happen.

I've sent email to Jeff and Philippe. Feel free to assist :)

 It may be that I don't get a response until the around the 11th Jan,
 which is the week before FUDCon - would that be too late? Regardless
 I'll see what I can do so that you don't have to worry about it in the
 future.

My email to the usual ARM suspects asked both about logo and also just
proper use of the ARM name. I suspect we can just put ARM somewhere,
but I would like to know what the community guidelines are. And, if this
needs to go in as a Connected Community thing, RH is a member of that.
Whatever angle works. Appreciate the poking.

Jon.


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

Re: [fedora-arm] Fedora-ARM Team Shirts

[Jon Masters]

On 12/21/2012 03:16 AM, Jon Masters wrote:
 On 12/21/2012 02:53 AM, Andrew Wafaa wrote:
 On Fri, 2012-12-21 at 07:39 +, j...@redhat.com wrote:
 On 12/21/2012 02:17 AM, Peter Robinson wrote:

 The Fedora project has a couple of approved companies for making of
 t-shirts and other things and they know the logo guidelines process
 etc. I suggest once we have details of the ARM stuff we can probably
 ask OSAS for assistance or direction, I can ask/take the task to see
 if they can assist us.

 On a related note, I'll ping nirik about the download page the websites
 team made as I have permission from ARM to use the ARM Powered logo on
 that page (only). The ARM logos come with an 18 page usage guidelines
 document, and it's pretty restricted what can officially use the logo.
 Sure, many websites and projects infringe, but we're going to dot every
 i and cross every t on this stuff - I have no interest in ever annoying
 ARM. I'll inquire about t-shirts...that will be complex.


 Thanks for making sure things are dotted and crossed :-) Unfortunately
 it may be tight to get clearance before the end of this year. I will try
 my best to see what can happen.
 
 I've sent email to Jeff and Philippe. Feel free to assist :)
 
 It may be that I don't get a response until the around the 11th Jan,
 which is the week before FUDCon - would that be too late? Regardless
 I'll see what I can do so that you don't have to worry about it in the
 future.
 
 My email to the usual ARM suspects asked both about logo and also just
 proper use of the ARM name. I suspect we can just put ARM somewhere,
 but I would like to know what the community guidelines are. And, if this
 needs to go in as a Connected Community thing, RH is a member of that.
 Whatever angle works. Appreciate the poking.

So, actually answering your question...I don't know what Chris has in
mind for printing options. I suspect we could find a local print shop in
Lawrence and have something turned around pretty quickly. Actually, let
me ask Rikki[0], copied, if she can let us know what local printer
options there are for t-shirts in town if we needed something done
within a few days? Maybe Chris or one of us will do something and take
with us, but hey, let's get all of the options!

Jon.

[0] A Lawrence local, community manager for USENIX, managing editor of
their magazine, and my Kansas Marathon running partner back in Oct.

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

Re: [fedora-arm] Working on Fedora-arm port for Allwinner A10 based devices

[Jon Masters]

On 12/21/2012 02:57 AM, Jon Masters wrote:

 I have a new hire Fu Wei in Shanghai, China (fuwei on IRC). He is
 getting up to speed on the Fedora ARM project by using AllWinner
 hardware. He got a CubieBoard at my suggestion and has it running. I'd
 like it if you guys could co-ordinate a little. Perhaps you can help
 each other out. I know Fu Wei will be very keen to help :)

I have connected Hans and Fu Wei on IRC, and they'll work together.

Jon.


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

Re: [fedora-arm] F-18: sshd enabled by default + firewalld

[Jon Masters]

On 12/20/2012 09:12 AM, Hans de Goede wrote:
 Hi,
 
 On 12/20/2012 01:55 PM, Peter Robinson wrote:
 On Thu, Dec 20, 2012 at 11:02 AM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 Our F-18 images have sshd enabled by default, but blocked by
 firewalld is this intentional?

 Probably not, I think we likely just need to add the appropriate
 snippet to the kickstart to ensure it's allowed through.
 
 Ok, so where do we track these kind of issues? I've tried using
 the fedora-arm fedorahosted tracker for a Raspberry Pi issue
 (enabling the watchdog kernel module in the kernel), but that feels
 as if it has fallen into a black hole.

David Marlin has a public kickstarts repo:

git://fedorapeople.org/~dmarlin/arm-kickstarts.git

I suggest sending him a pull or a patch for the moment. Perhaps we can
get some kind of component setup for tracking this. David, I'll let you
advise how you'd like to track this - Dennis may have suggestions.

Personally, I've been just disabling and removing firewalld at the same
time that I turn on the ssh service, but I am encouraged to hear that
this is something we can just fix in a kickstart.

Jon.

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