[Aakash-hackers] Bootstrapping for Aakash

Sun Feb 2 17:13:47 UTC 2014

Hi Srikant and others,

On 2014-02-02 05:12 AM, Srikant wrote:
> On 2014-02-01 at 8:32 PM, Vasudev Kamath wrote:
>> So I'm just wondering what are the requirements at the momemnt you 
>> people are looking to get Debian on Aakash running.
>>
>> 1. We came to know from Srikant that LIMA drivers need to be ported 
>>    to A13 alwinner SOC but from one of our Debian collegue (Paul 
>>    Wise) LIMA already supports Alwinner A13 SOC. So do you want it to 
>>    be packaged for Debian?

> 1. We were unable to install LIMA previously. Yes, it would be good to 
> have a Debian package.

Here I recommend getting in touch with Olimex developers.  They produce 
Allwinner-based boards and ship them with Debian preinstalled, and I 
know they have practical experience with using the LIMA driver.

https://www.olimex.com/ and on irc.freenode.net at #olimex

I don't mean to say that you can expect Olimex developers to do all the
work needed here, on the contrary I recommend that you show some 
commitment to a collaboration with those guys in "exchange" for hooking 
on to their experience they have gained from being early adopters of the 
LIMA driver.

...or alternatively simply read the blog posts made by Olimex and try 
get from those the info you need, i you for some reason can/will not 
collaborate closely with arguably a competitor.

https://olimex.wordpress.com/tag/video/

> Also, we need to do following (no particular order, based on recall):
>   a) Enable camera
>   b) Suspend to RAM
>   c) sleep (screen off, not display off with backlight on)
>   d) Wifi discovery issue (unable to connect same network)
>   e) Battery monitor(works only in 13.10)
>   f) Touchscreen driver for gsl1680 and one more (@Sachin, do you 
>      remember ?)
>   g) Touchscreen issues, enable long press right click in gt811 and 
>      ft5x
>   h) Boot logo in Uboot, it takes around ~3s to get kernel logo
>   i)  Freeing 128MB reserved memory for MALI 
>   j) One image for all variants of Aakash (same specs, different
>      touchscreens, 5 so far)

I suggest to put above list onto http://wiki.debian.org/DebianAakash - 
and extend wiki page with details as they emerge from further 
discussions here and at other lists.

It seems most of above (all except 1j) are closely tied to hardware, and 
therefore to a large extend need physical access to the actual devices 
to work on.  I understand that a couple devices are being shared with 
Debian developers in India - that sounds good!

What can be done now about hardware-related issues is collect as much as 
possible data about the hardware involved.

Then when developers get hands on actual hardware, they can share their 
findings and their struggle on this list - and others here can try help 
them (directly or pointing them to other places that might be relevant).

For hardware-related issues with data and bug-triaging already collected 
(like touchscreen quirks, it seems) try locate a Debian package directly 
related to that hardware, and file bugreports.

http://www.debian.org/Bugs/Reporting

For hardware issues I suggest to discuss them at the Emdebian 
mailinglist where Debian developers skilled in hacking low-level 
hardware on small devices tend to hang out.  Collect as much detailed 
facts as you can about the devices in question, and if sensible consider 
posting separately on each issue that are likely to be dealt with untied 
from Aakash specifically (e.g. "long press on touchscreen" may not be 
specific to Aakash hardware, I suspect) to encourage collaboration from 
most possible relevant enthusiasts.

Item 1j) seems less bound to specific hardware but instead conceptually 
the _kind_ of device - a tablet computer.  if I am mistaken on that and 
it isn't covered in 2) below, then please clarify.

>> 2. Also we need to go ahead and bootstrap the rootfs for Aakash so if
>>    you have any specific customization in mind do let us know. We 
>>    have Jonas who is specialist in Debian Pure blends and he can give 
>>    us hints on how to go ahead.

> 2. Yes, we will make bootstrap rootfs. We should discuss about what DE 
> we should provide this time. Previously, it was badly customized LXDE. 
> Should we continue with that? or, shall we invest time and resources 
> on a better touch optimized DE, say fork of LXDE or E18. There is 
> plasma-active for tablets, but its KDE, quite heavy for 512MB RAM. 
> Basically, we should have at least good virtual keyboard which should 
> popup automatically, touch optimized window manager, and of course RAM 
> efficient. If you suggest, let's create a separate topic for this ?
> 
> Also, would you recommend to us to go with Debian-Jessie or Wheezy. 
> Manoj found a good comparison [1].
> 
> So far we don't have any special repository to enable. 
> 
> [1] http://www.phoronix.com/scan.php?page=article&item=ubuntu_1404_jessie&num=1

Those questions have different answers depending on a larger underlying 
question: How to maintain what you/we create here?

The approach simplest to grasp is to pick a specific version of Debian 
(e.g. latest stable release or a development snapshot, as compared in 
the link just above), make a copy of that, adapt it as needed, and try 
keep the result in a working state for as long as possible.  And then 
repeat it all when a newer release/snapshot of Debian emerges that looks 
more exciting or is required by newer revisions of your device.

You may learn that the result cannot reliably be upgraded from one major 
version to the next, forcing the upgrade path on already deployed 
devices to simply be "wipe and reinstall from scratch".  If you are used 
to working with Android then that may sound as business as usual - but 
if you are familiar with Debian (or carefully designed derivatives like 
Ubuntu) then that's horrible - we are used to not needing disruption at 
all, just run the command "apt-get dist-upgrade" and continue with local 
data and customizations intact.

You will need a strong development team to handle such long-term 
challenges, or your project will stagnate, deployed devices will lack 
security upgrades, and you loose face towards your users.

Not the approach I recommend, as my might have guessed by now... ;-)

What I recommend is to *not* adapt a release/snapshot, but get involved 
in Debian itself: Help adapt/extend Debian to fit the needs of your 
project, so that Debian infrastructure and community will help sustain 
what is created for as long as there is devices with users - even beyond 
the lifetime of your your own engagement.

Doing things "the Debian way" is often more complex than treating Debian 
as the foundation on which you can apply hacks to achieve your (in 
themselves) simple adaptation needs.  Benefit can be difficult to see, 
but should be evident upon reflection: efficient long-term maintenance.

That was my sales pitch for "Debian Pure Blends".  Continuing from here 
I will simply assume that you are sold on this principle of going "all 
Debian" - you are welcome to choose another path, but my devotion lies 
with Debian so the further you stray away from that the less you'll 
benefit from my passion :-)

Choice of release/snapshot
--------------------------

Treat Debian as yours: Only stable Debian is stable enough for mass 
deployments - development snapshots are relevant only for development 
and testing (possibly including field testing, but don't rely on it for 
mass deployments!)

That may sound harsh - you want to deploy massively yesterday!  Fine, 
then mass-deploy a testing snapshot, but just honest to yourself what is 
the cost of that: potential huge burden on your deployment team in 
dealing with eventual bugs emerging - you can expect Debian community to 
help *develop* the development branch of Debian, but it is your headache 
alone if *deploying* that and it explodes in your face.  Not impossible 
to do (lots of geeks and their close friends run testing or unstable all 
the time), but highly risky - i.e. potentially expensive for you.

(NB! the phoronix.com article seems to be mostly about the benefit of 
changes to power state switching in specific versions of the Linux 
kernel and X11 drivers - so it highly unlikely to be any relevant on 
your ARM device where a bleeding edge kernel is likely required and X11 
drivers are likely to be radically different than the ones tested.)

Choice of Desktop Environment
-----------------------------

That's a tough one!  I like LXDE - personally I prefer so-called "tab 
window managers" and currently use Awesome, but I generally recommend 
LXDE for non-geek friends, and concretely use it in a small deployment I 
am leading at the European Parliament.

https://wiki.debian.org/DebianParl/GreensEFA

The tough part is - as you may know already - that options for touch 
optimized GUIs on Linux is quite sparse.

For stable Debian you may have luck using libgtkstylus, but that library 
seems without a future.

https://bugs.debian.org/729646

I suggest to join the Debian-mobile mailinglist and raise the question 
there - not specifically for your device but generally for gadgets 
running Debian (as such are commonly touch-based), to see what folks 
come up with as prospective paths forward.  Based on input from that 
list we can afterwards reflect on the issue here on this list and note 
down our reasonings at our wiki page.

https://lists.debian.org/debian-mobile/

>> PS: If you have any source code which you want to share we can enable 
>> the source repositories for this project and it can be pushed to Git 
>> repositories provided by Debian. Let me know if you need this and I 
>> will enable it.

Let me draw your attention to above (by Vasudev).  If you have any code 
you are permitted to share publicly then please do so.  Even if you feel 
your code is inferior or outdated, it may help get us all up to speed on 
your work so far and give insides on paths you have tried already.

E.g. to help more detailed in setting up debootstrap scripts, it is 
highly valuable to know what you've tried already, and if any of your 
work has been succesful - especially since I don't own the specific 
hardware.

...speaking of which: I do own a few OLinuxIno A13 boards, so depending 
on Aakash detailed hardware specs I might be able to do some level of 
testing.

On 2014-02-02 08:51:03, Pirate Praveen wrote:
> I think we should enable task tracking and track each issue 
> separately. Some issues could be filed as bugs directly against 
> respective packages.

I recommend *against* using the Alioth bug tracker, if that is implied 
above.  Yes, file bugs against existing Debian packages, but Alioth 
tools are clumsy to use, in my opinion - please avoid them.

(I recommended to use Alioth in the first please, so maybe a bit of 
elaboration is in order here: Alioth as a host for mailinglists and git 
repositories is great - what I recommend against, is the tools embedded 
directly into the Alioth web administration interface - an instance of 
FusionForge.)

I am really excited about this interest in using Aakash with Debian, and 
am prepared to devote extensive amounts of time and energy to help make 
that happen.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/aakash-hackers/attachments/20140202/ea019426/attachment-0001.sig>