[ Sorry, that fell off screen ]
Roger Shimizu wrote...
> [CC Vagrant, u-boot pkg maintainer]
>
> On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl
> wrote:
> > Paul Wise wrote...
> >>
> >> Is it possible to put a bootloader like u-boot in the flash partitions
> >> and have it load the Linux ker
Lennart Sorensen wrote...
> I actually highly doubt there are that many armv7 boxes running armel.
> armhf was a nice performance improvement and worth the hassle to reinstall
> if you had such a box in the first place. I think most armel systems
> are probably armv5, often the marvell chips. No
On Sat, Dec 17, 2016 at 08:15:15PM +0800, Paul Wise wrote:
> On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote:
>
> > Yes, but that still says:
>
> Ack.
>
> > I think a proper procedure should involve a script that:
> >
> > - is packaged in Debian;
>
> Ack.
>
> > - checks whether the h
On Sun, Dec 18, 2016 at 11:22 PM, Roger Shimizu wrote:
> Is there any way to simplify?
Remove the obsolete armel binaries where they occur and then mark the
packages as NFU on armel:
https://wiki.debian.org/ftpmaster_Removals
https://wiki.debian.org/PackagesArchSpecific
--
bye,
pabs
https://w
On Sat, Dec 10, 2016 at 12:22 PM, Wookey wrote:
>
> We can do poor-mans partial arch by just being fairly agressive about
> disabling armel for packages that are broken or not suitable. Not very
> clever or efficient, but it is easy to do and requires no infra or
> tooling changes at all. So long
On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote:
> Yes, but that still says:
Ack.
> I think a proper procedure should involve a script that:
>
> - is packaged in Debian;
Ack.
> - checks whether the hardware it's running on has all the hardware
> requirements for the new architectur
On Thu, Dec 15, 2016 at 11:19:34AM +0800, Paul Wise wrote:
> On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote:
>
> > One way in which the need to keep armel around would be reduced is if we
> > could somehow upgrade from armel machines to armhf ones, without
> > requiring a reinstall.
>
> T
On 2016-12-16, Roger Shimizu wrote:
> On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl
> wrote:
>>> Is it possible to put a bootloader like u-boot in the flash partitions
>>> and have it load the Linux kernel and initrd from elsewhere?
There's no technical reason this wouldn't be possible, just
[CC Vagrant, u-boot pkg maintainer]
On Sat, Dec 10, 2016 at 11:31 PM, Christoph Biedl
wrote:
> Paul Wise wrote...
>>
>> Is it possible to put a bootloader like u-boot in the flash partitions
>> and have it load the Linux kernel and initrd from elsewhere?
>
> That how I've been running my Dockstar
On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote:
> One way in which the need to keep armel around would be reduced is if we
> could somehow upgrade from armel machines to armhf ones, without
> requiring a reinstall.
There is a script for that here:
https://wiki.debian.org/CrossGrading
--
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
[...asking for armel to be retained...]
One way in which the need to keep armel around would be reduced is if we
could somehow upgrade from armel machines to armhf ones, without
requiring a reinstall.
After all, armel has been around
On Wed, Dec 14, 2016 at 06:40:22PM +0100, Wouter Verhelst wrote:
> On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
> [...asking for armel to be retained...]
>
> One way in which the need to keep armel around would be reduced is if we
> could somehow upgrade from armel machines to ar
On Wed, Dec 07, 2016 at 03:53:31PM +, Steve McIntyre wrote:
> AFAIK there are potentially still similar problems with ARMv5 - lack
> of architcture-defined barrier primitives for C++11 atomics to
> work. (I'd love to be corrected on this if people know better!) This
> is one of the key points h
2016-12-09 0:12 GMT+02:00 Christoph Biedl :
> Same here. My Dockstars (orion5x/kirkwood) still work like a charm and
> it gives a bad feeling having to trash them some day just because
> there's no support any more.
>
> On the other hand, they face another problem I guess is typical for
> that gene
On 2016-12-07 15:53 +, Steve McIntyre wrote:
> On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
> >I'm ARM porter on armel/marvell (orion5x/kirkwood).
> >Stretch will be frozen and released soon, which makes me bit depressed,
> >because it means armel will be dropped out of unst
On Fri, 2016-12-09 at 22:14 +0900, Roger Shimizu wrote:
> On Fri, 09 Dec 2016 00:53:17 +
> > Ben Hutchings wrote:
>
> > Also, dedicated tiny flash partitions for the kernel and initrd. I
> > wouldn't be surprised to be find that by the time we want to release
> > buster we can't build a usef
On Fri, 09 Dec 2016 00:53:17 +
Ben Hutchings wrote:
> Also, dedicated tiny flash partitions for the kernel and initrd. I
> wouldn't be surprised to be find that by the time we want to release
> buster we can't build a useful kernel that fits into the 2 MB partition
> that most of these devic
Roger Shimizu wrote...
> I'm ARM porter on armel/marvell (orion5x/kirkwood).
> Stretch will be frozen and released soon, which makes me bit depressed,
> because it means armel will be dropped out of unstable/testing as the
> conclusion of Cape Town BoF.
Same here. My Dockstars (orion5x/kirkwood
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
>[ intentionally keep d-d CCed ]
>
>On Fri, 22 Jul 2016 02:36:05 +0100
>Steve McIntyre wrote:
>
>> [ Please note the cross-post and Reply-To ]
>>
>> Hi folks,
>>
>> As promised, here's a quick summary of what was discussed at the ARM
[ intentionally keep d-d CCed ]
On Fri, 22 Jul 2016 02:36:05 +0100
Steve McIntyre wrote:
> [ Please note the cross-post and Reply-To ]
>
> Hi folks,
>
> As promised, here's a quick summary of what was discussed at the ARM
> ports BoF session in Cape Town.
Thanks for the summary!
I'm ARM port
On Thu, Aug 11, 2016 at 11:47:12AM +, Riku Voipio wrote:
>On Fri, Jul 22, 2016 at 02:36:05AM +0100, Steve McIntyre wrote:
>> armhf
>> =
>> Current port, first released with Wheezy. Due to cross-distro effort,
>> this setup (ARMv7 EABI using VFPv3D-16) is the default supported
>> 32-bit ARM
On Fri, Jul 22, 2016 at 02:36:05AM +0100, Steve McIntyre wrote:
> armhf
> =
> Current port, first released with Wheezy. Due to cross-distro effort,
> this setup (ARMv7 EABI using VFPv3D-16) is the default supported
> 32-bit ARM architecture in all distros now. We've got a couple of
> kernel var
On 2016-07-27 00:53 -0400, Jeffrey Walton wrote:
> >> The Mustang board is a nice test platform because its an early ARMv8
> >> board. While its ARMv8, it lacks CRC and Crypto extensions.
> >
> > That's interesting. Having almost given up on any AMD ARM
> > hardware ever appearing, I've been consi
>> The Mustang board is a nice test platform because its an early ARMv8
>> board. While its ARMv8, it lacks CRC and Crypto extensions.
>
> That's interesting. Having almost given up on any AMD ARM
> hardware ever appearing, I've been considering getting a
> Gigabyte MP30-AR0 (which I thought for a
On 2016-07-22, Steve McIntyre wrote:
> is the lack of direct support for C++11 atomics - it's possible to use
> a kernel helper to cover for this lack, but performance will be
> terrible.
This is going to be a real problem for Qt in the very near future. A
requirement for qt 5.7 is a c++11 compli
On 2016-07-23 18:46 +, Phil Endecott wrote:
> > > Affordable, usable machines are available now, e.g. the Cello
>
> Is the Cello actually available? 96boards is still saying "pre-order".
I have seen one, but that was '1st batch'. I don't know current
status, but yes I guess it's still under
> > Affordable, usable machines are available now, e.g. the Cello
Is the Cello actually available? 96boards is still saying "pre-order".
> There are three other ARM64 gadgets worth mentioning...
And the ODROID-C2. (Can someone add that to the list at
https://wiki.debian.org/Arm64Port#Hardwar
On Fri, Jul 22, 2016 at 9:36 AM, Steve McIntyre wrote:
> armel
> =
>
> armel is the longest-running of our current ARM ports in Debian,
> starting in 2007. It's starting to become difficult to support. Debian
> is the only common distro still supporting ARMv4t.
I note armel is still more popu
On 22/07/16 02:36, Steve McIntyre wrote:
Affordable, usable machines are available now, e.g. the Cello
Does anyone know what is going on with this. Have boards actually
started shipping?
W dniu 22.07.2016 o 04:02, Jeffrey Walton pisze:
There are three other ARM64 gadgets worth mentioning...
* Raspberry Pi 3 Model B (http://www.amazon.com/dp/B01CD5VC92), $38 USD
This device has armv8 core but no support for running Linux in 64-bit mode.
The Mustang board is a nice test pla
> arm64
> =
>
> Most recent ARM port. All looking good now - we've been mostly able to
> move on from Juno development platforms to real server hardware
> now. We're using some APM Mustang machines and an AMD Seattle box
> hosted by ARM and Linaro at the moment, and even real arm64 server
> mac
[ Please note the cross-post and Reply-To ]
Hi folks,
As promised, here's a quick summary of what was discussed at the ARM
ports BoF session in Cape Town.
This year, unfortunately the session did not have video so I can't
link to it. I've taken a copy of the Gobby notes from the session,
alongsi
32 matches
Mail list logo
