lanefu

Extra security  ... fixed. One minute cron, so you don't need to wait long.
 
It looks better now. PDF check, some Youtube solution ... working on content. 

It turns out that that version of FFmpeg does not work because the video engine version in the H3 is different to the A20. According to nove on #cedrus IRC: 'the way that the hardware is initialized changed, and also the way that h264 encoding subengine is enabled changed'
 
Obviously I am still eager for more information regarding this.

great..  BTW there's a task topic already created for you.   It'll inspire others if you can show status there
 
 http://forum.armbian.com/index.php/topic/1532-392-documentation-rework/

Thanks, I'll forked a little while ago, so I'll re-base my fork and start submitting.
 
Thanks!!
 
Kriston

Ok, for the THS, adding back the 1008000 entry is a kind of ugly workaround : during boot FREQ switch is crashing, but at least it continue to boot completely.
I presume that real fix would not be adding it, but change the value at the origin of that 1008000, which is probably in u-boot, but this is outside of my knowledge.
@Tkaiser, the patches you mentioned, and even Megi's change doesn't seem to be part of the Armbian build process. Maybe patches are not applied for some reason.
 
@jernej, I started doing what you've said, I got some part done, but now I'm a bit lost about platform files searching for the legacy sys_config.h

Cool, I also did few things on the way:
 
- docs.armbian.com is updated auto when new commit is done to lib.docs, checking via cron at the moment
- wiki @lib is closed
- I moved main documentation link to docs.armbian.com since it's better than what we have right now in any case.
BTW: Do we really need brackets [ ] in URL? They are URL unfriendly ... any other option?

I continued my permanent link experiment, it is working locally. It's a simple bash script. I'm not 100% convinced it's a good idea. It is simply:
 
1. A human adds markers in the source document where you want to specify an anchor name, overriding what is automatically generated.
2. When html is built, script replaces the autogenerated anchors with the specified one, in mkdoc's output files (The anchor id, and links to it in the html files and search index).
 
 
The marker that goes in source can be something that will not be displayed even if not properly processed out, eg:
abuse a markdown reference: "[permalink]: my-anchor-name"
or fake html that browsers will ignore: "<permalink="my-anchor-name">
(the latter can be processed more cleanly).
 
It can be used sparsely in the source, only where desired (but then a site maintainer must add the tags when the scripts warn of potential broken links), or it can be used all over (but then either the doc writers must deal with them or a site maintainer).
 
 
Whether this is worth it is someone else's call, so i'll leave it until someone wants to move forward. Any decision on it should be easily changed later.

I've had some great success with Docker, both to build Armbian for and to deploy our application on a Lime2.
 
The catch is, I'm doing this on a Mac, using the latest beta of Docker. The key benefits of this are:
- a single command to build an entire deployable image,
- can test the actual compiled ARM application directly before deploying to the embedded board.
 
Much thanks to lanefu for his comments on the loopback device nodes, which was the final piece of the puzzle.
 
My current Dockerfile, which adds some extra required packages.
# Docker build environment for Armbian # # Build the image: # docker build -t armbian-build:clean lib/ # # To run a container and perform a build: # docker run -it --privileged armbian-build:clean # ./compile.sh # # Once completed, you will need to commit the build as a new container to save cached build and downloads # OR uncomment the final line of script instead. # docker commit `docker ps -lq` armbian-build:post-build # # Next time run # docker run -it armbian-build:post-build FROM ubuntu:16.04 RUN apt-get update RUN apt-get install -qy git build-essential binutils binfmt-support qemu-user-static nano pkg-config ccache ntpdate udev # Recreate loopback and partition devices RUN rm -rf /dev/loop[0-1]* RUN mknod /dev/loop0 b 7 0 RUN mknod /dev/loop0p1 b 259 0 RUN mknod /dev/loop0p2 b 259 1 RUN mknod /dev/loop0p3 b 259 2 RUN mknod /dev/loop0p4 b 259 3 RUN mknod /dev/loop1 b 7 1 RUN mknod /dev/loop1p1 b 259 0 RUN mknod /dev/loop1p2 b 259 1 RUN mknod /dev/loop1p3 b 259 2 RUN mknod /dev/loop1p4 b 259 3 WORKDIR /root RUN git clone --depth 1 https://github.com/igorpecovnik/lib/ RUN cp lib/compile.sh . # RUN ./compile.sh BOARD=lime2 BRANCH=next RELEASE=xenial KERNEL_ONLY=no PROGRESS_DISPLAY=plain # uncomment this line to run the first build, to populate the docker image with current sources and packages

I fought the good fight over the weekend trying to get Armbian builder to build full images while running in a docker container.    I've had some success, and managed to build a armban 5.11 image for my Orange Pi One.. I'm running on it with wifi etc.
 
I'm using a CentOS7 Docker 1.9.1 host and using Ubuntu 14.04 Trusty Docker Container for the Armbian builder container. (I just used the Dockerfile from the armbian git repo)
 
Bottom line loopback management inside containers is a bad time.. especially when losetup implementations vary between host and container.   The partprobe step in the container doesn't seem to trigger appropriate feedback to udev to create partitiion devices on the /dev loop back devices.   I got around it by creating them ahead of time.
 
Here's a few tricks to limp through.  I'll try to add more clarity later.
 
1.  Don't. just go build a ubuntu 14.04 VM or use a turn key one on amazon and get your life back.
 
 
From Docker Host
#you need modules modprobe binfmt_misc modprobe loop #scrub loopbacks for good luck rm -rf /dev/loop[0-9]*     Launch armbian builder container with --privileged=true #sudo docker run --privileged=true --name=armbian -it armbianbuilder #or if you're re-using container #sudo docker start -i armbian From container   #start apt-cacher-ng service apt-cacher-ng start ​ #scrub loopbacks again in container for good luck rm -rf /dev/loop[0-9]* #create all your loop back devices mknod /dev/loop0 b 7 0 mknod /dev/loop0p1 b 259 0 mknod /dev/loop0p2 b 259 1 mknod /dev/loop0p3 b 259 2 mknod /dev/loop0p4 b 259 3 mknod /dev/loop1 b 7 1 mknod /dev/loop1p1 b 259 0 mknod /dev/loop1p2 b 259 1 mknod /dev/loop1p3 b 259 2 mknod /dev/loop1p4 b 259 3 mknod /dev/loop2 b 7 2 mknod /dev/loop2p1 b 259 0 mknod /dev/loop2p2 b 259 1 mknod /dev/loop2p3 b 259 2 mknod /dev/loop2p4 b 259 3 #build your dreams cd ~ ./compile.sh Every time you build an image you should destroy the loopbacks and recreate.  It's your best chances of getting the partitions in the loopback image to behave for mounting.
 
 
     

Just look at the screenshot, look how the URL is constructed. That's what mkdocs does for you after 2 minutes of 'tweaking'. Taking the structure that is present in the ckecked out .md documents and creating nice formatted HTML from it. URLs are called like documents, anchor names depend on internal structure. Everytime a clueless guy starts to edit wiki contents believing only wiki output would count everything breaks. It's that easy.
 
Defining 'internal' structure inside _Sidebar.md worsens everything even more since now you have to parse this file to modify MD documents prior to feeding it to mkdocs. IMO bad.
 
So by giving up on the 'presentation engine' in our github wiki and simply using a home page that states 'Do just edit the pages accessible on the right, don't change page titles, don't change section names, only add stuff and edit structure very carefully' you might get the wiki approach to work IF we want to postprocess the stuff therein (no idea if WE want that still)
 
By adjusting structure levels inside the individual .md docs and minimizing their count the postprocessing efforts are MINIMAL. Just choose the right mkdocs theme, disable search therein and feed the output to htmldoc. And you get a full PDF manual with links, index and so on. And using a different theme you can use HTML output from mkdocs on armbian.com (given that nobody uses the github wiki like a wiki and starts there editing like crazy -- that's the whole point. As soon as people start to use the wiki in the usual wiki way all our persistent links get fucked up automatically)
 
But since only @lanefu looked that much into (and might be able to understand me) I finally stop here since the whole discussion gets boring.

@lanefu
 
Yes, something like this. Just push it to wiki and add to menu, let's say "Report a problem" in section "General".

So you're talking about the order of horribly outdated information instead of the information itself (I thought we're talking about improving documentation? That means that every of these sentences has to be either deleted or reworked since this is outdated stuff back from the day Igor supported 5 boards and now we're dealing with +40)
 
Then what do you suggest? Anyone should change something that comes to your mind right now? Don't we have a wiki now? Shouldn't we talk about the processes how to alter the wiki's contents (who is allowed to do what? How can we integrate people not allowed to edit directly to contribute?) instead of polluting this thread with random nonsense like "someone should add '&& sync' somewhere"?
 
I stop here.

Okay, cool!  I did some tinkering.  It looks like using the GitHub wiki for the Single Point of Truth for the docs would work really well.
 
here's my findings:
 
you can SSH clone with your keys by inserting wiki in the main repo clone url (wiki gui only gives you https clone option) The raw wiki markdown files are named the same as the title, with no extra prefixes or suffixes The default wiki sidebar displays pages in a sorted fashion.  This allows us to rely on a naming convention to keep things grouped and allow for inserts direct access to the repo lets you add non-wiki files... ex: mkdocs.yml can reside within the wiki repo, along with style sheets etc

tkaiser has built a new Kernel with i2s Modules. With this Kernel and some cheap DAC  e.g. (http://www.ebay.de/itm/Audiophonics-I2S-DAC-ES9023-Sabre-to-Analog-24bit-192KHZ-fur-Raspberry-PI-/291573327639?hash=item43e31fe717:g:TTwAAOSw~OdVZXtm)  it is possible to get good quality sound  out of the Orange Pis. After installing the Kernel
Two Things have to be changed in the fex File:
 
Change Directory to boot:
cd /boot Turn the script.bin to a fex-File and open it in an Editor
sudo bin2fex script.bin script.fex sudo nano script.fex Now change the following Entries:
[twi1] twi_used = 1 to
[twi1] twi_used = 0 and
[pcm0] daudio_used = 0 to
[pcm0] daudio_used = 1 Save your changes and do :
sudo fex2bin script.fex script.bin After a reboot your done.
 
 
I do not know for what the Section [twi1] is good for, i hope nothing serious..
This connections have to be made:
 
5V > Pin 2
Gnd > Pin6
BCK > Pin 27
LRCK > Pin 28
Data > Pin37
 
(according to the Picture "giachi" has posted on the diyaudio Forum http://www.diyaudio.com/forums/pc-based/285427-i2s-connection-orange-dac.html#post4587580
see below)
 
The second Picture is only for orientation on an Orangepi PC, the red Wire is 5V ! Be aware that the Header is rotated by 180°on the One!
 
That´s all .
 
Regards

OK, let's use Github wiki as a base. I already done some rework. First part is more or less done, now going to script part and fine tuning on the top of it.
 
https://github.com/igorpecovnik/lib/wiki

Okay, cool!  I did some tinkering.  It looks like using the GitHub wiki for the Single Point of Truth for the docs would work really well.
 
here's my findings:
 
you can SSH clone with your keys by inserting wiki in the main repo clone url (wiki gui only gives you https clone option) The raw wiki markdown files are named the same as the title, with no extra prefixes or suffixes The default wiki sidebar displays pages in a sorted fashion.  This allows us to rely on a naming convention to keep things grouped and allow for inserts direct access to the repo lets you add non-wiki files... ex: mkdocs.yml can reside within the wiki repo, along with style sheets etc

The one problem I had with a github wiki was how to access the raw contents? But as usual it's quite easy. Editing wiki pages creates revisions and raw .md can be obtained in an automated fashion:
 
The latest revision of https://github.com/ThomasKaiser/lib/wiki/01-User-documentation for example is always accessible as: https://raw.github.com/wiki/ThomasKaiser/lib/01-User-documentation.md
 
The whole wiki is just a git repo in itself so cloning it locally is also possible: https://github.com/ThomasKaiser/lib.wiki.git

okay.. I'll volunteer now...based on my understanding of this thread
 
A quick recap and some strategic questions about the direction we're heading.
 
Documentation will be provided in the following formats:
HTML / HTML Site w/ clean url ex: http://armbian.com/documentation/userdocs PDF (style of user manual) MD (github convenience  -- automatically renders individual files) Following tools will be used:
mkdocs htmldoc Behavioral Requirements
Functional TOC in PDF Search (for html site?) Questions:
Should we move documentation to a separate repo and update lib/documentation to be a git submodule? Where should the documentation output be stored (html/pdf)? Should documentation resources automatically be updated after every documentation commit?

Few my ideas.
 
 
I think no need for this. I expect lot's of changes now, since we need to add few things and apply better structure to what's already done.
 
Let's see what do we have now:
 
"user faq" - This suppose to be "Getting Started: Everything you need to get Armbian up and running". It's close to that, except some things might be too advanced for novice user.
"enabling HW features" - is little more than this, but not many things present at the moment. Here we could add (move from) most important things: connecting spi / i2c displays, sensors, ... The main question remain "how far" should we go with all this?
"h3_mini_faq" - logbook and user faq only for H3. How to deal with per board stuff? Generally.
"geek faq" - how to deal with tools. We need 2-3 script user review to be done and merged into this documentation (can be claimed for board). Our / coder POW is not the best to write such manual. Basically one must start from scratch, test all functions and write down experiences, written in manual/howto style.
"fel-boot" - features within tools. The same. Someone from outside should review / rewrite the docs.
 
 
Current situation: docs sources are .md and they are rendered to .html within blog and there we can set permanent links per documents. This part is not that bad after all. "Getting started" and "Basic" is the same page just in case someone does not understand it properly. Next doc is "Building" aka "geek manual" and a log book.
 
One idea is, to merge all those sections into one .pdf file "Armbian handbook". First part basic stuff, than few howtos and building howtos, walk trough and perhaps logbook at the end.
 
Not necessarily but we can do that quickly in the future if needed. 
 
One more exposed link on the download page would help, agree. Elsewhere is not critical since the page offers pretty strait links: download, docs, sources and forum. I think main problem is that we don't have proper docs internal organization, few things are doubled, build script needs much more explanation, examples, ... where to put log of changes? We even have separate, more detailed for H3. 

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.

I did a bit of experimentation and have the following suggestions:
 
1. On http://www.armbian.com/change "Getting Started" to "Documentation". Currently all documentation is under "getting started" which isn't an intuitive place to look for advanced stuff.
However since you want a clear "where to start" sign that stands out to new visitors, we could have a prominent "Getting Started: Everything you need to get Armbian up and running" icon/link/banner stickied near the top of the Home page (and maybe Downloads page if people are directly linked there from external sites). It should take you to a documentation page that starts with an outline (with links) of the main steps a complete novice would take.
 
2. If the html docs are going to be mainly mkdocs output with some post-processing, I would try to put the output underneath the Armbian nav bar, using a theme that has the Documentation navigation on a left sidebar to avoid crowding the top. Theme readthedocs does this. It should be possible to use html <embed> to shove the mkdocs webpage into the Armbian web page. Unless someone really wants to tweak the theme and process the output to look perfect, maybe as little as changing the theme's colors will be enough to make it look good.
 
Edit: That is, either you could let mkdocs use the whole browser window, which is not ideal because it looks like the documentation is a different site. Or leave mkdocs output as a full webpage and embed it, which I think would be easiest to try. Or process the output a lot so that you combine the Armbian page and the mkdocs output into one generated page, which should be more work but give you more control.

Hi,
 
I'm trying to make my opi one act as a keyboard. I've found that I need to activate g_hid module, but when I trying to execute:
modprobe g_hid it says:
modprobe: FATAL: Module g_hid not found. Also, g_ether, g_mass_storage, g_multi, g_ptinter and g_serial modules are available.
So, what should I do and maybe anyone can provide me an example how to send a keystroke to my pc?
 
Thanks.

Still grokking big picture -- interest piqued.   

Well, I just looked into MkDocs a little more (10 minutes). It seems all that's needed is an additional index.md that defines the final structure, eg.
Site_name: Armbian ${temprevision} pages: - User FAQ: main-01-user-faq.md - Enabling Hardware Features: main-02-Enabling_hardware_features.md - H3 Mini FAQ: main-03-H3_mini_faq.md - Geek FAQ: main-04-geek-faq.md - FEL Boot guide: main-05-fel-boot.md - Version history: main-06-logbook.md (so no need for numerical prefixes since order can be defined here). I used also the wrong mode before (webserver on 127.0.0.1) but mkdocs can also produce a set of temporary static HTML files (which can then be adjusted easily, eg. making the youtube links work). If the search stuff will be deactivated and headers/footers in MkDocs then the raw material to be fed into htmldoc is already perfect.
 
With htmldoc you then get clickable TOC generation, headers/footers, page numbers and the like for free (this tool is from Mike Sweet, main author of CUPS, so generated PDF is also not that dodgy as that produced by most other tools). I think it's pretty easy for someone familiar with MkDocs to provide perfect HTML (integrated into github workflow so that documentation commits trigger a new PDF manual version), piping that into htmldoc is easy too. The only 'real task' would be adjusting header levels in our various docs so that a nice 'PDF book' gets created in the end.
 
That being said I won't look into this any more also. Any volunteers?
 
Edit: IMO the final goal if MkDocs will be used together with htmldoc would be two sets of documentation. MkDocs should produce a set of static HTML files (generation triggered through github commits) and these should also be rendered to a nice looking PDF 'manual'. IMO we still suck when it's about documentation, especially the 'why do users do NOT look into available docs' part.

I found and apply "markdown-pdf" tool. Lightweight and looks good enough out of the box I would say.
Preview result in attachment - without any corrections or order.
Armbian_5.14_documentations.pdf