Re: marvell_cesa continues to fail on kirkwood with kernel 4.4

[Martin Michlmayr]

* JM  [2016-02-05 04:20]:
> To quickly bring you up to speed, the driver for Marvell's hardware
> crypto accelerator embedded in their Armada/Kirkwood SoCs has been
> rewritten as marvell_cesa and merged in kernel 4.2. The new driver
> received a number of patches since and has been enabled in Debian as a
> module in 4.4~rc4-1~exp1 (debian bug #807634), coexisting with the old
> driver (mv_cesa).

(As Jan found out later, the drivers don't really coexist that well
and disabling the old driver makes the new one work.)

Upstream is moving to the new CESA driver, so I'll disable the old one
in Debian's 4.6.

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: Debian Jessie on QNAP TS-112P - Reboot instead of shutdown

[Martin Michlmayr]

* jfc  [2016-04-20 20:21]:
> I get the same issue since I upgraded my Qnap TS-119P II | Turbo to
> Jessie. I'm not able to shutdown my Qnap anymore, it always reboot
> whatever command I use (halt, shutdown, systemctl).

I just found the bug report again (not that it contains more info):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794266

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: Supporting armel/armhf in wheezy-lts

[Tollef Fog Heen]

]] Raphael Hertzog 

I am not speaking on behalf of DSA here.

> The LTS period is about to start soon and we will send out an announce
> soon... it would be nice to be able to say a word about armel/armhf, so
> an official confirmation from ftpmasters/DSA would be nice.

So, I'm a bit divided on all this.  While the DMUP is heavy artillery
and we should be careful about invoking it, I think it crosses the line
in «Don't use Debian Facilities for private financial gain or for
commercial purposes, including consultancy or any other work outside the
scope of official duties or functions for the time being, without
specific authorization to do so.», so you need explicit authorization
before you start.

We have to balance multiple issues here: on one hand, LTS is clearly
useful.  On the other hand, Debian is a volunteer organisation and we
don't pay people to work on Debian.  By asking for donations for «Debian
LTS» and then paying folks to work on it, we're at least very, very
close to that line, if we don't cross it, somewhat depending on who «we»
are and how it's marketed and presented, and I think that is not
particularly clearly communicated today.

JFTR, for me at least, this isn't about wanting a piece of the action; I
don't want to be paid for my DSA work.  One option I've been toying
about with (but which I'm not sure is a good one) is that some portion
of the Debian LTS income go to Debian, rather than individuals.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Supporting armel/armhf in wheezy-lts

[Raphael Hertzog]

On Mon, 18 Apr 2016, Raphael Hertzog wrote:
> In the mean time, the sponsor clarified that they will join as "gold
> sponsor" so they are effectively sponsoring 8 hours of work per month,
> which seems to be enough to cover for the increased work that those
> ports might represent.

The sponsorship is now confirmed since they have paid for a full year
already. Plat'Home is the fourth gold LTS sponsor.

>From IRC discussions it looks like that the buildd maintainers
(at least Neil Williams and Riku Voipio) have no objections to supporting
armel/armhf (Riku is rather pleased by it). On the ftpmaster side,
I had no official feedback but at least Ansgar seemed to be
fine with it when I asked him on IRC. On the Debian Admin side, I have
not had any feedback yet.

The LTS period is about to start soon and we will send out an announce
soon... it would be nice to be able to say a word about armel/armhf, so
an official confirmation from ftpmasters/DSA would be nice.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

On Apr 21, 2016, at 9:04 AM, Vagrant Cascadian  wrote:

> On 2016-04-21, Rick Thomas wrote:
>> Are you saying that the amount of RAM seen by Debian Linux is
>> determined by something in u-boot?
> 
> Yes.

How is this information communicated from u-boot to the Linux kernel?  I 
thought I understood (at least in principle) how the hand-off between then 
worked, but clearly I’m missing something.

> 
>> But if I were using your patched mainline u-boot, I would get a
>> different (larger) number (almost, but not quite, the full 4.0GiB)?
> 
> That’s how it's worked for me, yes.

Would you be willing to share this modified u-boot with me?  I’d like to try it 
out on my device to see if it’s really an i4pro or a 4x4.

> 
> There's something about the imx6 that limits it to 3.8GB.
> 
> 
>> I seem to remember that I got roughly the same number (lightly less
>> than 2.0 GiB) when I booted the manufacturer supplied u-boot and
>> Ubuntu kernel from the uSD-card that came with it.
> 
> Maybe it came with a u-boot that didn't support the cubox-i4x4, as it
> wasn't added until relatively recently:
> 
>  https://github.com/SolidRun/u-boot-imx6
> 
> Or, maybe you really did get a cubox-i4pro.

Possible… I’ll have to boot it from the original µSD-card and see what version 
of u-boot it has.  I may have time to do that this weekend.

> live well,
>  vagrant