Do you have a lot of free time and an urge to contribute mobile phone packaging to Debian?

[Timo Jyrinki]

Hi,

The title says it mostly. There is a lot of work to be done on
hardware adaptation / kernel support, middleware (FSO2 / oFono) and UI
(SHR, Mer/Nemo/MTF, Aurora) regarding mobile phones. For a few devices
it's mostly taking code from upstream and packaging.

Why I'm asking it more precisely is that I have a spare Nokia N900,
for which there is now basic, probably untested support in fso-deviced
[1] and related packages. What would be needed on that middleware
level is similar to fso-common's [2] fso-gta01/fso-gta02 meta packages
for Neo 1973 / Neo FreeRunner phones, polished together with its
dependencies so far that the apt-get install fso-n900 would bring the
phone functionalities online (then apt-get install some UI and off you
go). This of course assumes that first you have a kernel from
somewhere and otherwise normal Debian armel/armhf rootfs - which
brings one next into packaging the hardware adaptation for OMAP3/N900
into Debian. UIs are common ground with other Debian mobile phoners,
like the pkg-fso team [3] which you should probably anyway join to
contribute to FSO packages. Finally, remember to check out the recent
Mobile UXes BoF report [4], which should be updated with the fact that
MeeGo is now called Mer on the community side and MeeGo CE - the
OMAP3/N900/N950/N9 hw adaptation and handheld UX project - is now
called Nemo.

[1] http://packages.qa.debian.org/f/fso-deviced.html
[2] http://packages.qa.debian.org/f/fso-common.html
[3] http://wiki.debian.org/Teams/DebianFSO
[4] http://lists.debian.org/debian-devel/2011/09/msg00126.html

I have too many devices and I'd like to give the N900 to someone who
wants to make a difference in this area in Debian and also work in the
upstream projects Mer/Nemo (home of the hw adaptation [5], and MTF
based handheld ux), upcoming Tizen (the actual continuation of MeeGo)
et cetera. What I lack is free time. The N900 would come with stock
PR1.3 maemo software, but with u-boot readily installed so you can
boot up Debian from microSD card. It is also possible to consider how
to use the 256MB NAND and the 2GB eMMC. There is some previous work
done or investigated already regarding Debian on N900, see [6] for
details (the modem support should now be in both FSO2 and oFono).

[5] 
http://monster.tspre.org:2082/Mer%3a/Trunk%3a/Adaptations%3a/N900/Mer_Trunk_Base_armv7hl_standard/src/
[6] http://elektranox.org/n900/todo.html

-Timo


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cajtffxmbhqnmnmbamgcn3pz9ezgy6ekb66iofvcxx1-we06...@mail.gmail.com

Re: Do you have a lot of free time and an urge to contribute mobile phone packaging to Debian?

[Timo Jyrinki]

2011/10/20 Timo Jyrinki timo.jyri...@gmail.com:
 I have too many devices and I'd like to give the N900 to someone who
 wants to make a difference in this area in Debian and also work in the

Found a receiving DD.

-Timo


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAJtFfx=2dnedn9dbhbnkyjyt13oayodbhdea3r4vwkvamyc...@mail.gmail.com

Re: Do you have a lot of free time and an urge to contribute mobile phone packaging to Debian?

[Timo Jyrinki]

2011/10/22 green greenfreedo...@gmail.com:
 Thanks for contributing the hardware; the N900 would/will be a great device
 if/when it is fully supported by open source software.  I would like to
 purchase one sometime if it looks like I can run (real) Debian on it,
 especially if I can do so with mainline Linux.

To be fair, I did get the device for free as well, mostly in order to
work on MeeGo stuff which I did. Anyway, it's good not to have such a
potential developer device mostly unused. I would have originally
donated it to a local MeeGo device program for developers, but they
already had a couple of free N900:s in their inventory so I thought
I'd turn towards the Debian community. Work done in Debian tends to
help everyone as well...

-Timo


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cajtffxmjq8pnruug6-aknrg4+r8fj2dnagt4td_h252djca...@mail.gmail.com

Re: armel v4t vs v5

[Timo Jyrinki]

2012/4/18 Wookey woo...@wookware.org:
 I just asked and the answer seems to be 'some, but not much'. There
 are a few more useful instructions which should amount to a few
 percent speed improvement, but the gains are not exciting, which does
 suggest leaving it at v4t until really no-one cares anymore.

+1 for this. Armel at this point is clearly for a bit more legacy
devices, and Debian is one of the rare distros that support ARMv4.
Thus many embedded devices are likely to run Debian, and might run for
years and years. Any single digit percentage increase in performance
would make a switch to ARMv5 just a technological exercise for
builders, but a net loss for users.

The move to ARMv7 is going on strong, and armhf is here to provide the
performance. Raspberry Pi lives on the unfortunate middle ground that
would like to have ARMv6 with hard-float, but that's another story...

-Timo (disclaimer: owner of a couple of FreeRunners, but also an ARMv5 device)


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAJtFfxmTyrgWPfXu=+mglw_+uo58n5a5nmkujtvat3fznj6...@mail.gmail.com

Re: modern cheap NAS fully supported by Debian?

[Timo Jyrinki]

2012/7/20 Nicola Bernardini n...@sme-ccppd.org:
 I gave up on my NSLU 2 which seems irremediably broken (my guess is that
 the RAM is botched) and I would like to buy another NAS  in  that  price
 range or whereabouts. And of course, I would like to be able  to  run  a
 full Debian system on it. Debian  Squeeze  would  be  fine,  but  I  can
 install Woody if need be. What do you think is a good  buy?

Being a happy owner of an (now) officially Debian supported NAS device
for many years, I wouldn't go for anything else if I'd be upgrading
now: http://www.cyrius.com/debian/kirkwood/. In other words, I'd not
stare at small megahertz differences etc., just getting the one that
has support beginning from installer.

I love my orion based QNAP TS-109, and currently would upgrade to QNAP
TS-119 if I would have the need, but QNAP isn't cheap. So maybe the
Plug variants mentioned on the page instead.

-Timo


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cajtffxn82ww7hp+xvrm+8g5fb1a7teuvtqbxzazie1syjjd...@mail.gmail.com

Re: Help needed after updating Debian on QNAP TS-109 Pro II

[Timo Jyrinki]

2012/9/22 Juha Larjomaa juha.larjo...@iki.fi:
 I have been happily running Squeeze from a USB stick on my QNAP TS-109 Pro
 II for a long time. Today, I decided to update my system with 'apt-get
 upgrade'. Some packages were updated but I saw that some files were kept
 back by apt-get - so I decided to run 'apt-get dist-upgrade' without
 knowing any better.

I noticed this only today, but happy to hear it all worked out for you.

I've been running the same device with Debian for years now, and I've
unattended-upgrades running so I've always gotten all the updates. I
have rebooted occasionally after kernel security fixes. My only
problem was when I decided to migrate the hard drive I'm running
Debian also from to ext4...
http://losca.blogspot.fi/2012/07/where-computing-takes-you.html but
even that turned out well :)

I look forward to seeing how squeeze - wheezy will go. I have a RS232
to 3.3V TTL adapter bought from some online shop that I successfully
used for installing Debian via a TS-109 Pro II's serial port back in
the days of etch.

-Timo


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAJtFfxmKOS7bf=d0ooy+bcyufpdoyzx2ygcuiow6ba01kf7...@mail.gmail.com

Re: building qt4 for arm

[Timo Jyrinki]

2013/2/12 Neil Williams codeh...@debian.org:
 That doesn't help with the problem that the default Debian build only
 supports Xorg and most boards are actually going to require QtEmbedded
 and framebuffer support. If you've only got 256MB of RAM, Xorg is
 seriously painful.

The Qt5 on Debian will btw build the framebuffer and EGL QPA plugins
in addition to the XCB plugin.

-Timo


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAJtFfx=y9c9colxy6pb0fbphomfc5afyk6qhgvj_dl95onq...@mail.gmail.com

Re: Help needed with qtcreator FTBFS on arm*

[Timo Jyrinki]

2014-06-21 17:15 GMT+03:00 Lisandro Damián Nicanor Pérez Meyer
perezme...@gmail.com:
 Hi ARM porters! I'm writing you because we currently have qtcreator FTBFS only
 on ARM* [0] and we can't figure out what's the problem.

Ubuntu has qtcreator 3.1.1 built for armhf. I think the main
difference is that Ubuntu has been using g++-4.7 on armhf for
qtcreator, because of past problems with qtcreator built against Qt 5
on armhf. That's a quite big hammer though, so a better solution or a
smaller testcase to file a bug with would be of course good.

-Timo


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cajtffxnriynoczpz9trsmvg-rbjjvgakbq0w_ws94qzwmnu...@mail.gmail.com

Re: Information needed from owners/users of Debian on ARM/kirkwood base QNAP devices (should take 1min to gather)

[Timo Jyrinki]

2014-06-17 10:49 GMT+03:00 Ian Campbell i...@hellion.org.uk:
 TL;DR: Please run the attached kirkwood-qnap script on your ARM based
 QNAP systems as ./kirkwood-qnap --info and report the results in this
 thread along with the model/kind of your QNAP device (as precisely as
 you can).

QNAP TS-221 (2.0GHz, 1GB RAM -
http://www.qnap.com/en/index.php?lang=ensn=822c=351sc=514t=523n=18375g=1):

$ ./kirkwood-qnap --info
Kernel:Linux verkko 3.2.0-4-kirkwood #1 Debian 3.2.54-2
armv5tel GNU/Linux
cpuinfo:Hardware: QNAP TS-119/TS-219
dt model:n/a

PCI devices:
00:00.0 0600: 11ab:6282 (rev 01)
00:01.0 0106: 197b:2363 (rev 03)
00:01.1 0101: 197b:2363 (rev 03)
01:00.0 0600: 11ab:6282 (rev 01)
01:01.0 0c03: 1b6f:7023 (rev 01)

PHY devices (/sys/bus/mdio_bus/devices/):
0:00

Soc Bus:n/a

QNAP TS-119/TS-219
kirkwood-qnap: machine: QNAP TS-119/TS-219
kirkwood-qnap: success: PCI = kirkwood-ts219-6282.dtb
kirkwood-qnap: success: PHY = kirkwood-ts219-6282.dtb

-Timo


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAJtFfxkjKWB_CBw4wfVYEy-ZfgU7JNS7Uwp+7bYd=rhgrvu...@mail.gmail.com

Re: ext3/ext2 kernel bug with umlauts?

[Timo Jyrinki]

On Fri, 29 Aug 2008, Theodore Tso wrote:


Can someone create a small filesystem:

dd if=/dev/null of=/tmp/sample.img bs=1k count=32768
/sbin/mkfs.ext3 -F /tmp/sample.img
mkdir /sample
mount -o loop /tmp/sample.img /sample

... and then create some of these files for me, and then unmount the
filesystem, bzip2 it, and send it to me?


The problem seems not to be reproducable simply by creating similarly 
named files or even copying the whole directories. The problem shows with 
the full 25GB data set of mine (for me), but not if I just check which 
directories were problematic on ARM and copy just those to eg. USB stick.


As explained in the long quotations in Martin's e-mail, when the problem 
is visible (I've ca. the same 25GB of data on two different disks, and 
the problem is shown on both disks in that directory), ls -U shows the 
problematic directory entires in a sequential order, but they are 
different on a different disk - meaning it's not the names or data as 
such, but where/how they are positioned on the disk + ext3 data somehow.


Of course feel free to try to reproduce something that fits on a USB stick 
or so, I'll try to do that again too.


-Timo


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ext3/ext2 kernel bug with umlauts?

[Timo Jyrinki]

Hi, sorry for some delay, haven't dwelled into the problem recently.

On Fri, 29 Aug 2008, Martin Michlmayr wrote:

Timo, can you try to mount the filesystem as ext2 (rather than ext3)
and tell me whether you still see this problem.


Right, that solves the problem. Mounting as ext2 works, mounting as ext3
gives the problems described in my bug report and on the mailing list by
Kai.


  01-jürgen_paape-so_weit_wie_noch_nie.mp3
  03-erlend_øye-sheltered_life_(rmx)+fine_night_(acapella).mp3
  [...]

 I have to confirm this strange problem.

I just tried the same and it works fine here.  I created a dir with
the name above with those files in it on a USB stick connected to my
laptop running 2.6.27-rc4.  Then I moved it to an orion5x based box
running 2.6.26 but everything is fine.


I've not been able to reproduce the problem by any simple empty file / 
directory creation. Even with the same directory structure, I cannot 
see the problem if the data is not there. And I cannot see the problem if 
I just copy the problematic (on that disk) entries/dirs. I also tried 
using a script to create directories with entries beginning with ä in 
fi-wiktionary, but they also look fine when connected to QNAP.


It does not look like any corruption on the HDD I'm using either, 
since the same data backuped to another disc shows the same problem in 
the same directory/directories, although for different entries. Both disks 
can be accessed fine when mounted as ext3 to other machines.



What is the output of 'locale'?


fi_FI.UTF-8 on all lines (except the last LC_ALL which is empty). I tried
export LANG=C (which changes all output lines of locale to C) before
mounting but at least that didn't change anything.

-Timo


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ext3/ext2 kernel bug with umlauts?

[Timo Jyrinki]

On Fri, 29 Aug 2008, Theodore Tso wrote:


time tst_hash -q -a tea -n 300
time tst_hash -q -a half_md4 -n 300


[EMAIL PROTECTED]:~$ uname -a
Linux debian 2.6.26-1-orion5x #1 Thu Aug 21 11:45:38 UTC 2008 armv5tel GNU/Linux
[EMAIL PROTECTED]:~$ time ./tst_hash -q -a tea -n 300
41 collisions

real0m44.432s
user0m43.980s
sys 0m0.450s
[EMAIL PROTECTED]:~$ time ./tst_hash -q -a half_md4 -n 300
0 collisions

real0m43.136s
user0m42.680s
sys 0m0.460s

(second run:
41 collisions

real0m44.893s
user0m44.360s
sys 0m0.360s

0 collisions
real0m44.880s
user0m44.390s
sys 0m0.490s)


-Timo


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ext3/ext2 kernel bug with umlauts?

[Timo Jyrinki]

On Wed, 22 Oct 2008, Martin Michlmayr wrote:


* Theodore Tso [EMAIL PROTECTED] [2008-10-20 23:19]:

Can someone confirm that these patches fix the problem folks have been
seeing?


http://merkel.debian.org/~tbm/tmp/ext3/


I can also confirm that the patched kernels fix the problem for me - I 
can now move disks from a x86 machine to the armel machine and access 
all directories without problems.


Likewise, thanks a lot to Theodore, and to Martin for providing pre-built 
kernels!


-Timo


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Debian on TS-221: cannot power off

[Timo Jyrinki]

2014-11-03 12:54 GMT+02:00 Thomas Pircher tehpeh-deb...@tty1.net:
 On 2014-11-02 8:28 pm, Simon Elsbrock wrote:
 Unfortunately I've been unable to power off the device. As soon as I
 run `poweroff` I can hear the disks spin down after some time only to
 spin up immediately afterwards.

 I had this problem a couple of weeks ago on my QNAP TS-220 with an
 up-to-date Debian testing.

Right, I think I had this problem with my TS-221 too, with Debian 7.0.
I shut it down, and wondered why it immediately powered on again.

But I've only ever tried to shut it down once, since, well, I've it
running all the time.

-Timo


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAJtFfxk8kmQMbXek_6TvfcAcEOqxGGb-LbiGB-SuC_Az=jz...@mail.gmail.com

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

[Timo Jyrinki]

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 generation, just by the age: Memory.

There are new kirkwood devices still being produced and my <2y old one
(and still on sale in some places) is 2.0GHz one with 1GB RAM.

Just pointing out that ARMv5 is less a certain generation of CPUs as
such but a selection of instruction set by a chip manufacturer. It
will of course become rarer over time.

Thanks to all who have maintained armel so far, I'll be a happy user
for the duration of stretch support.

-Timo

Re: QNAP TS-419P Stretch ATA errors

[Timo Jyrinki]

2017-04-20 9:14 GMT+03:00 Rob J. Epping
:
> On April 19, 2017 7:47:49 PM GMT+02:00, John Horan  wrote:
>>I upgraded my storage to stretch the other day, and the device started
>>freezing.  So I hooked up a serial console and saw the lots of ata
>>errors
...
> A bit later the disk in the TS-219 died.
> Will try and swap the new stretch disks to the TS-221 this weekend.

Did you try out stretch on TS-221, or any others with more recent
Debian stretch experiences now that it was released? I don't see
anything marvell/kirkwood/qnap related in changelog lately that could
improve the situation if there's a generic problem.

I'm tempted but hesitating to upgrade. I have TS-221 specifically.

-Timo

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

[Timo Jyrinki]

2018-04-25 14:16 GMT+03:00 Martin Michlmayr <t...@cyrius.com>:
> Timo Jyrinki is happy to run some tests.  He's affected and has a
> serial console.  The bug is still there in the 4.9 kernel we're
> shipping with Debian kernel.
>
> Andrew, what information or access do you need so this can be tracked
> down?

Yesterday I tried booting with mem=512M added to the u-boot's setenv
bootargs, and wasn't able to reproduce the problem. Booting again
without the parameter it was there again. I repeated a couple of times
with same results, although sometimes it took some time for the
problem to occur in the normal 1GB RAM use case so I'm not 100% sure
of how bullet proof the workaround is. I tried to use at least some
memory by starting Debian installer fetching, logging into it via ssh
etc.

Could someone else try it out? Double-check the parameter worked with
'free'. I'm tempted to make a backup of my current / + flash
partitions and dist-upgrade to stretch. On that note, what would be
the easiest way to set the mem=512M as the default for normal boots?

Andrew wasn't able to reproduce the problem on his 6282 machine. Would
it be that he has QNAP TS-219P+ or similar that has only 512MB RAM?
(https://www.cyrius.com/debian/kirkwood/qnap/ts-219/specs/)

-Timo

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

[Timo Jyrinki]

2018-06-05 20:25 GMT+03:00 Timo Jyrinki :
> more proper kernel zImage build with CONFIG_VMSPLIT_3G_OPT=y would be useful
...
> wget https://people.debian.org/~timo/qnap/zImage

It seems my native kernel build on the QNAP device finished last
night, so here's the zImage for it:

https://people.debian.org/~timo/qnap/zImage_new

I have no time to test it myself now. Just in case it would be somehow better.

-Timo

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

[Timo Jyrinki]

2018-06-02 18:55 GMT+03:00 Ian Campbell :
> You need to append a dtb and then encode in u-boot's uImage format.
> e.g.
>
>cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-ts419-6281.dtb > x
>sudo mkimage -A arm -T kernel -O linux -C none -a 0x8000 -e 0x8000 -d x 
> uImage

Thank you! Now it's all coming back to me, I'm not sure if I've played
with these since Neo FreeRunner times.

So the good news is that with this kernel
kernel-kirkwood-ts219-6282-split3gopt from
https://people.debian.org/~timo/qnap/ (initrd from
http://ftp.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-21x/)
I'm getting full 1GB RAM without the errors!

I do seem to have a problem with networking, not sure because of my
custom build somehow otherwise or if VMSPLIT_3G_OPT=y could affect it.

In the same directory I've also included the zImage, in case you want
to combine it with a different dtb than the kirkwood-ts219-6282 one
and create your own uImage.

-Timo

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

[Timo Jyrinki]

2018-06-02 22:31 GMT+03:00 Andrew Lunn :
>> kernel-kirkwood-ts219-6282-split3gopt from
...
>> I'm getting full 1GB RAM without the errors!
>
> Now, the question is, is this an O.K. workaround? Or do we need to
> figure out why highmem breaks on Kirkwood?

Fine by me, but I'm not really in position to say that much. On a personal
level even the mem=768M is ok workaround, I can live with 768MB RAM and I'm
really happy to be able to use Debian 9.0.

It would be nice to see more testing on the kernel at some point. Maybe a
more proper kernel zImage build with CONFIG_VMSPLIT_3G_OPT=y would be
useful too, I don't know what's the cause for my wired network brokenness.
I did build the current kernel in a qemu emulated chroot environment
instead of real hw.

Regardless, for testing, if it helps I put the dtb files extracted from
official marvell 4.9 .deb to https://people.debian.org/~timo/qnap/dtb/

In more detail:
wget
http://ftp.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-21x/initrd
# or ts-11x, ts-41x
wget https://people.debian.org/~timo/qnap/zImage
wget https://people.debian.org/~timo/qnap/dtb/kirkwood-ts419-6281.dtb # for
example, depending on your model
cat zImage kirkwood-ts419-6281.dtb > x
mkimage -A arm -T kernel -O linux -C none -a 0x8000 -e 0x8000 -d x uImage

Then follow https://www.cyrius.com/debian/kirkwood/qnap/ts-219/uboot/ to
boot the initrd + uImage from serial console.

On TS-221, with my USB to TTL cable it worked for me with minicom with the
following pins connected:
https://people.debian.org/~timo/qnap/TS-221_console_1.jpg

For the TFTP server (anything in the same network works), I found tftpd-hpa
simple. Just modify TFTP_DIRECTORY in /etc/default/tftpd-hpa and it just
works.

-Timo

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

[Timo Jyrinki]

2018-07-04 21:48 GMT+03:00 Andrew Lunn :
>> 1) The config option change works, but some networking issues were
>> mentioned.  Someone needs to figure out whether that's related.
>
> I would be interested in knowing what the network issues were? They
> might be a pointer to what is going wrong with high pages.

"Network doesn't work". I'm not sure what's going on, but the
installer isn't able to enable the network, even though the network
device exists and can be configured. Cable is connected similarly to
normal operation and lights are blinking (and obviously the system was
just booted with TFTP from u-boot too).

I tried now again, this time with the "zImage_new" which was the one
recompiled natively. It didn't make a difference as the symptoms
seemed similar, so I put some logs (slightly manually redacted for
possible unique identifiers) at:
https://people.debian.org/~timo/qnap/split3gopt-logs/

Syslog shows both installer and me trying to get life into the
network. I tried setting IP and default route manually and pinging the
router but nothing.

Adding to my earlier instructions, if one wants to test those kernels
built by me you now need to fetch the older initrd to go along with
them from: 
http://snapshot.debian.org/archive/debian/20180605T102632Z/dists/stretch/main/installer-armel/20170615%2Bdeb9u3/images/kirkwood/network-console/qnap/ts-21x/initrd

-Timo

Re: Upgrade report for stretch on QNAP TS-212P

[Timo Jyrinki]

Thanks for the report!

Have I missed anything related to the faults with the 1GB RAM / 2.0GHz
models (TS-221), ie are they mabe now able to upgrade to stretch? Last
thread I can find is from July last year about the "Unhandled fault:
external abort on linefetch (0x014)" [1].

[1] https://lists.debian.org/debian-arm/2017/07/msg00053.html

This post just picked my interest since you mentioned TS-212P is using
Marvell 6182 like the TS-221 and unlike TS-219 which was working
already before. So I wonder if the problem was 6182 specific and now
fixed, or rather more TS-221 or RAM size specific and still remains.

-Timo, still running jessie


2018-03-13 18:29 GMT+02:00 Vincent Legoll :
> A few more details...
>
> I used kernel-6182 & initrd from:
>
> http://ftp.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-21x/
>
> verified with help from:
> http://ftp.debian.org/debian/dists/stretch/main/installer-armel/current/images/SHA256SUMS
>
> I had to restart a few times because my previous RAID
> setup was detected by D-I and I was afraid it would interfere
> with the new install (I wanted to change partition layout)
>
> The (multiple-minutes-long) flashing at the end of D-I
> was getting on my nerves (I saw it stuck at 66% for a
> long time) but eventually finished properly.
>
> --
> Vincent Legoll
>

Re: Upgrade report for stretch on QNAP TS-212P

[Timo Jyrinki]

2018-03-16 12:30 GMT+02:00 Martin Michlmayr :
> Are you in a position to test kernels and attach a serial console if
> necessary?

Possibly yes, now my QNAP doesn't have services that absolutely need
to be up 24/7. OTOH my free time is extremely limited, but with
instructions and kernels available I can see if I can find time.

I should have 3.3V TTL to RS-232 wires somewhere that I used with
TS-109, and although
https://www.cyrius.com/debian/kirkwood/qnap/ts-219/serial/ doesn't
explicitly list TS-221, maybe I can trial and error until I find the
correct pins.

-Timo

Re: Bug#881333: tracking OpenGL support for specific boards

[Timo Jyrinki]

pe 30. marrask. 2018 klo 1.26 Lisandro Damián Nicanor Pérez Meyer
(perezme...@gmail.com) kirjoitti:
> > > Keep in mind, only the proprietary drivers seem to not support opengl
> > > while the hardware is perfectly capable of doing so.
> >
> > Not necessarily.
> > If the manufacturer specifies OpenGL ES support, then - on the hardware
> > level - it is a GLES renderer and may or may not support the entire
> > OpenGL specification natively. It usually requires considerable work to
> > make GLES hardware support OpenGL.
>
> So the real place which should be fixed is, somehow, in Qt itself, and
> preferably by not hacking libs.

Surely the best solution would indeed be getting
https://bugreports.qt.io/browse/QTBUG-36829 fixed, but there is
unfortunately no reported recent progress.

-Timo

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

[Timo Jyrinki]

ti 23. huhtik. 2019 klo 1.37 Matti Viljanen (matti.vilja...@kapsi.fi) kirjoitti:
> I have a Fujitsu Q703 aka. QNap TS-221, with 1GB of RAM and 6282 variant
> chip inside, and I have hit this behavior.
...
> it get an IP address but the LEDs blink normally - I think this is the
> same situation Timo had. I have used the recovery image QNap provided
> and re-flashed the kernel by flash-debian script (and manually cat-ing,
> too), but soon I should have my TTL serial adaptor ready.

Thanks a lot for testing, and confirming something goes wrong with
CONFIG_VMSPLIT_3G.

> I would like to help testing, if you have any ideas. What should I try next?

Alas I'm out of my depth on the topic regarding what to try next if
wanting to use the whole 1GB of RAM.

The workaround limiting RAM to 768MB works fine, and since no variant
seems to have over 1GB RAM, maybe it's acceptable tradeoff for most so
this hasn't seen more progress. The workaround in u-boot with the
adapter is described at
https://lists.debian.org/debian-arm/2018/06/msg0.html , and after
setting that I've used my TS-221 for the past year. It can also be set
via fw_printenv and fw_setenv (not tested myself) as instructed at
http://karuppuswamy.com/wordpress/2012/04/16/u-boot-tools-for-debian-arm-linux-in-qnap-server/.
fw_printenv gives me the following on the last line:
bootargs=console=ttyS0,115200 root=/dev/ram initrd=0xa0,0x90
ramdisk=34816 mem=768M

-Timo

Re: Buster on nap TS-219p II

[Timo Jyrinki]

ke 24. heinäk. 2019 klo 0.12 basti (mailingl...@unix-solution.de) kirjoitti:
> I use mdadm RAID, yes. I think this should be best practice for a NAS. I
> have fixed by setting COMPRESS=xz |in
> /etc/initramfs-tools/initramfs.conf for now. I'am looking forward what
> will happen on newer kernels. Best Regards |

So to re-cap, other than that problem, you updated your TS-219P II
successfully from stretch to buster?

I'm looking forward to upgrading my TS-221 (with u-boot mem limited to
768MB) some day, no hurry though.

-Timo

Re: Buster on nap TS-219p II

[Timo Jyrinki]

ti 27. elok. 2019 klo 14.00 basti (mailingl...@unix-solution.de) kirjoitti:
> It's the Flash (MTD). This is only a few MB.
>
> But yes I have done with xz compressed initramfs.

Just reporting that likewise, with COMPRESS=xz Debian 10 has worked
flawlessly on my TS-221 for the last 1.5 months since I upgraded. It's
very nice that armel was able to be kept as a release architecture for
Debian 10 too.

Continuing to run with mem=768M.

-Timo

Re: Buster on nap TS-219p II

[Timo Jyrinki]

pe 25. lokak. 2019 klo 11.57 Emanuele Olivetti
(emanuele.olive...@gmail.com) kirjoitti:
> Is COMPRESS=xz the default option for initramfs.conf now in buster? If not, 
> will it be soon?
> I am waiting to upgrade to buster to avoid  issues like this one.

I don't think so, and it may not happen. Regardless, it's good to have
the option set already before starting the upgrading.

So the only thing I did before editing sources.list + apt update + apt
dist-upgrade (inside screen) was this:

--- /etc/initramfs-tools/initramfs.conf.dpkg-dist2019-02-06
01:55:47.0 +0200
+++ /etc/initramfs-tools/initramfs.conf2019-09-04 12:19:34.170996659 +0300
@@ -41,7 +41,9 @@
 # COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | xz ]
 #

-COMPRESS=gzip
+#changed for buster, old gzip, new xz
+#COMPRESS=gzip
+COMPRESS=xz

 #
 # NFS Section of the config.

Re: Qnap TS-219P+ Kernel 5.9.0-1-marvell

[Timo Jyrinki]

ti 3. marrask. 2020 klo 22.44 Uwe Kleine-König (u...@kleine-koenig.org)
kirjoitti:
> For now it is not even certain that bullseye will include support for
> armhf at all. See

Just noting that I love how many times these discussions occur along
the lines of "armhf starts to be quite old and with problems, not sure
how long it is going to be supported" and then the opportunity to
delightfully answer "well... it's armel" :)

Some bits of history, these QNAP devices are not ancient as such, they
were announced in 2013. But they happened to use a Marvell Kirkwood
chipset which is only ARMv5, using an ARM core that was announced in
2001 (with some Wikipedia checking). ARMv7 ie armhf cores would have
been available since 2007.

A bit similarly my Openmoko GTA02 in 2008 had ARMv4 (the Debian armel
baseline) compatible CPU, which had an ARM core announced in 1998.
Sometimes new things are a bit slow to trickle.

With Debian 10 LTS support until 2024 the lifetime of these QNAP
devices would be max 11 years if bought on the release year, which is
a bit short for a solid piece of hardware. I'll need to investigate
options latest by 2024, like maintaining the couple of externally
visible network services myself in case of security updates.

Anyway, I'm extremely happy with Martin Michlmayr's original work on
the official Debian support for these old QNAP Orion/Kirkwood based
devices, and the problem solving we've all done together. They have
brought me many good Debian NAS years.

-Timo

Re: Bullseye on the QNAP TS-220

[Timo Jyrinki]

Christian Henz kirjoitti 4.9.2021 klo 18.29:

I have recently upgraded to bullseye on my TS-220, and ran into the

...

I have now managed to install the bullseye kernel into the otherwise
unused (?) "RootFS2" partition (3MB), so I thought I'd report on the
steps I went through, in case it might be helpful to someone else.


Thank you, I was wondering if anyone's upgraded these Kirkwoods to 
bullseye and I guess the answer is "no, not successfully" unless going 
your route.


The instructions look good and if one day I have time to dig up my 
serial cable from somewhere and have plenty of extra time, I'll try it. 
It seems my QNAP TS-221 just keeps on going so there's a "risk" I'll 
want to use it past buster's support period.



For testing purposes, I then manually created a uImage of the buster
kernel


You don't happen to have the mkimage line handy? Maybe there's nothing 
special about it but it wouldn't hurt to have a reference in this 
thread. OTOH, testing booting from it via serial cable is of course safe.



     $ uname -r
     5.10.0-8-marvell


\o/

-Timo

Re: Bullseye on the QNAP TS-220

[Timo Jyrinki]

Martin Michlmayr kirjoitti 29.9.2021 klo 6.29:

BTW, Karsten Sperling took another approach and changed the u-boot
config to change the MTD partition layout.


Arnaud Mouiche has taken a similar approach and has written a script
that will automatically configure QNAP devices.

I think that's the best approach for those who want to run bullseye on
their QNAP.

The script can be found here:
https://github.com/amouiche/qnap_mtd_resize_for_bullseye

If someone uses this script, please post your feedback here.


I thought I answered this thread earlier but don't find myself doing so.

Indeed that script worked without a hitch and I've been running Debian 
11 on QNAP TS-221 for something like 1.5 years now with zero problems.


-Timo

Re: Add QNAP model Q703

[Timo Jyrinki]

Arnd Bergmann kirjoitti 11.8.2023 klo 11.01:

PS: is there any way I can help with debugging the 1GB RAM issue? I
applied the mem limit to 768MB in uboot as a workaround but if I can
help in any way with debugging this issue I'm happy to.



I forgot what the problem was, but it sounds like the difference
between CONFIG_VMSPLIT_3G and CONFIG_VMSPLIT_3G_OPT in the kernel.

Ideally you'd want to use CONFIG_VMSPLIT_3G_OPT in a kernel for
a system with 1GB of contiguous RAM, but I don't know if the
problem here was caused by picking this or not picking this.


I tried that around 
https://lists.debian.org/debian-arm/2018/06/msg7.html (still there 
at https://people.debian.org/~timo/qnap/) and had 1GB in use but some 
other problems with my build.


I have continued to run with 768MB which is enough for my use cases, and 
with the Debian 11 (after the flash partition restructuring script and 
dist-ugprade) the system has been rock solid.


Now of course I would be curious whether anyone has tried upgrading any 
Kirkwood devices to Debian 12, but bullseye has luckily plenty of 
support remaining.


-Timo

Re: Add QNAP model Q703

[Timo Jyrinki]

Timo Jyrinki kirjoitti 24.8.2023 klo 17.09:
I have continued to run with 768MB which is enough for my use cases, and 
with the Debian 11 (after the flash partition restructuring script and 
dist-ugprade) the system has been rock solid.


Now of course I would be curious whether anyone has tried upgrading any 
Kirkwood devices to Debian 12, but bullseye has luckily plenty of 
support remaining.


The answer was yes and now I'm in that group of Debian 12 users as well.

https://github.com/amouiche/qnap_mtd_resize_for_bullseye/issues/41

Long live kirkwood!

-Timo

Re: Immediate fallouts from the big linux changes, and actions

[Timo Jyrinki]

Bastian Blank kirjoitti 24.12.2023 klo 13.46:

- Finally, the armel build fails because it can't find its kernel. The
   marvell flavour seems to have been dropped entirely (at least that's
   how I read the linux changelog for 6.6.3-1~exp1:
 
https://tracker.debian.org/news/1482751/accepted-linux-663-1exp1-source-into-experimental/


Yes, the kermel was broken and the checks for this disabled since quite
some time.


Not that I'd object to removal as such, but to keep documentation 
straight is there some new brokenness that wasn't there at Debian 12 
release time? Kernel 6.1.0 works fine on marvell based devices like QNAP.


The changelog only refers to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950324 which just 
describes a problem with the default flash layout, fixing of which has 
been automated with a script 
(https://github.com/amouiche/qnap_mtd_resize_for_bullseye).


Debian 11 and Debian 12 have been working fine on these devices.

-Timo