38 minutes ago, kisspachyousee said:

I managed ! instead of compiling the default kernel I did version 4, and everything went smooth!

Both must and do work. It must be something else. But if you are satisfied with the outcome ...

4 hours ago, Igor said:

Both must and do work. It must be something else. But if you are satisfied with the outcome ...

in truth I like it because I can finally use the USB key a867 avermedia, but the problem is that now I do not work kodi in log tells me that anything is wrong with EGL / GLX

No GLES support with this kernel yet. Sorry.

Wrote on mobile

2 minutes ago, Igor said:

No GLES support with this kernel yet. Sorry.

Wrote on mobile
 

and there is no way to run kodi?

 

30 minutes ago, kisspachyousee said:

and there is no way to run kodi?

You can use LibreELEC for H3 which can be build from this sources: https://github.com/LibreELEC/LibreELEC.tv/tree/allwinner

 

But there is no support for HW decoding with mainline kernel. Work on this is already planned, but don't expect anything useful before middle of the next year.

is there a way to insert the af9033 driver (avermedia a867) into the old kernel? with the kernel 4.13 there is already the module!
LibreELEC does not matter to me, I prefer ubuntu or debian

7 hours ago, kisspachyousee said:

is there a way to insert the af9033 driver (avermedia a867) into the old kernel?

Possible, but it is on you to port the driver. We don't have resources to support even the onboard hardware.

 

7 hours ago, kisspachyousee said:

LibreELEC does not matter to me, I prefer ubuntu or debian

I would also like to see KODI on Debian but unfortunately, this is hard to achieve. Even on x86 it usually doesn't just work out of the box. Your problem is solvable with two boards - one for backend running modern kernel and one for running Openelec.

before I take another board I want to try to compile the drivers for the old kernel, give me a hand? do I open a new thread?

The supported Armbian build environment is Ubuntu 16.04 LTS I know. Is there any strong reason why one should not build now on Ubuntu 17.10?

Yes, there is a strong reason called "waste of scarce human resources" to gain little on a less important area. There are only a few people working on/supporting/developing a build engine ... which anyway support building withing Docker. This means you can actually build anywhere - at any x64 Linux Docker capable host.

In case this bothers you a lot and you want to dedicate your time to this challenge: https://docs.armbian.com/Process_Contribute/ 

For some time I have been successfully building OrangePIOne and OrangePiSero full dev images on a debian stretch system by adding "stretch" to the supported list on approx. line 685 in lib/general.sh

 

But I have to change general.sh every time there is an update.

 

It should be trivial to change the script such that instead of just dying on an unsupported system the option to go forward anyway - with the appropriate warnings, threats and magic disclaimers. 

38 minutes ago, dhlii said:

It should be trivial to change the script such that instead of just dying on an unsupported system the option to go forward anyway - with the appropriate warnings, threats and magic disclaimers. 

We already tried that and it didn't work well - people demanded fixes for unsupported build hosts even though they had to read the warning each time, so at least understanding what "no support" means wasn't trivial for them.

 

40 minutes ago, dhlii said:

For some time I have been successfully building OrangePIOne and OrangePiSero full dev images on a debian stretch system by adding "stretch" to the supported list on approx. line 685 in lib/general.sh

If you tried to build, for example, the default sun8i branch some time ago it would be a different story.

Thanks @Igor. Just asking!

 

There are just too many people who still don't read instructions (hey, stop lookin' at me!) so the only option is to break if they didn't read the 3 foot tall flaming print saying "BUILD SYSTEM REQUIREMENTS" and "if you don't have this system, use a virtual machine setup, like the vagrant one we provide for you".  If they still want to disregard the instructions, they'll have to edit the build script themselves. 

7 hours ago, zador.blood.stained said:

We already tried that and it didn't work well

I was thinking the other day to RFC main readme. Move all to documentation and leave only reduced text: 

Build system req: Ubuntu 16.04.y X64 (native, containerized, virtualized) + "detailed specifications and advanced build options" with a link to docs + why only Ubuntu?

32 minutes ago, Igor said:

I was thinking the other day to RFC main readme.

README.md may need some work, but i's in a much better shape than, for example, our download pages for H3 boards, so IMO it's not critical.

 

 

is there any old version of armbian with a kernel earlier than 3.4.13 available?
I'm having trouble compiling some drivers and I think the reason is that the kernel is too new for the driver version I want to install.
the error that gives me is:

error "Please do not include <linux / compiler-gcc.h> directly, include <linux / compiler.h> instead.
or:
dvb_frontend.h: 49: 33: error: field 'parameters' has incomplete type

    struct dvb_frontend_parameters parameters;

I want to change kernel config,but not success.

here is my config-default.conf

 

KERNEL_ONLY=""                          # leave empty to select each time, set to "yes" or "no" to skip dialog prompt
KERNEL_CONFIGURE="yes"                  # leave empty to select each time, set to "yes" or "no" to skip dialog prompt
CLEAN_LEVEL="make,debs,oldcache"       

DEST_LANG="en_US.UTF-8"                 # sl_SI.UTF-8, en_US.UTF-8

KERNEL_KEEP_CONFIG="no"                        # do not overwrite kernel config before compilation
EXTERNAL="yes"                          # build and install extra applications and drivers
EXTERNAL_NEW="prebuilt"                 # compile and install or install prebuilt additional packages
CREATE_PATCHES="no"                     # wait that you make changes to uboot and kernel source and creates patches
BUILD_ALL="no"                          # cycle through available boards and make images or kernel/u-boot packages.
                                   

BSPFREEZE=""                            # freeze armbian packages (u-boot, kernel, dtb)
INSTALL_HEADERS=""                      # install kernel headers package

when enter kernel config menu,I save to my.config ,and then I change my.config setting

CONFIG_STRICT_DEVMEM=n

then I load my.config back .

then GUI will ask " Do you wish to save your new configuration ? <ESC><ESC> x to continue"

I chose yes.

then It will create  Armbian_5.41_Orangepione_Ubuntu_xenial_default_3.4.113.img,then I clone to sd card.

 

I boot orange pi one ,then check kernel config setting

cat /proc/config.gz | gunzip > mykernel.conf

always be CONFIG_STRICT_DEVMEM=y

 

how could I change this kernel config setting??

thanks help~                        

 

Edited May 8, 20188 yr by unto

On 5/8/2018 at 2:17 AM, unto said:

I want to change kernel config,but not success.

when enter kernel config menu,I save to my.config ,and then I change my.config setting

CONFIG_STRICT_DEVMEM=n

 

how could I change this kernel config setting??

thanks help~                        

 

I beleive the correct syntax is .config is 

# CONFIG_STRICT_DEVMEM is not set

 

 

I have building Armbian OS Images and custom kernels for a while now (works flawlessly!)

 

When I run ./compile.h the target OS release options are only:

jessie

stretch

xenial (ubuntu 16.04)

 

Do i have to do something different to generate 18.04 target images?

Or hardware specific? is it unsupported?  

 

 

53 minutes ago, Abbotware said:

Do i have to do something different to generate 18.04 target images?

You need to add a switch EXPERT="yes" ... and you are on your own if something doesn't work. Bionic works, but there are tiny bugs ... from the upstream, which we have no capacity nor wish to fix. If you don't want trouble, stick to Debian Stretch.

23 minutes ago, Igor said:

but there are tiny bugs ... from the upstream

oof OK.. well Im going to give it a try regardless (will probably use a different build vm)

I only need to perform a diagnostic test to validate if a bug is related (or unrelated) to the target os distro

1 minute ago, Abbotware said:

will probably use a different build vm

No need for that. This EXPERT switch just opens you a possibility to build more than what's recommended for end users. We do Bionic builds, but we don't want to remove label "testing" until it's working as expected. If you find a bug in Bionic, you are more than welcome to submit a fix. Only together we can hunt em down successfully 

I just built the 4.18.5-mvebu kernel for the clearfog base ... went and installed smoothly and running ... I'm using SFP/fiberoptic network and it works fine, why is SFP supposedly "unsupported"? In any case, thanks for a great project!

 

Jonathan

3 hours ago, jab-r said:

why is SFP supposedly "unsupported"? In any case, thanks for a great project!

 

Jonathan

 

 

That is supposed to be old news. I haven't got chance to test 4.18.y well ... only in a quick pre-release test. I notice most things are working but DVFS (regression) which is one of those nice to/must-have features. I notice SFP was properly detected, but link speed & reliability was not tested. 

 

Thank you for your support!

On 7/5/2018 at 6:53 AM, Igor said:

This EXPERT switch just opens you a possibility to build more than what's recommended for end users

Does that mean it also stops all the updating?

So you just compile your changes locally?

3 minutes ago, xenpac said:

Does that mean it also stops all the updating?

So you just compile your changes locally?

No, that just opens the possibility to build locked targets. Check the manual for other options. If you want to have your own sources and other things: https://docs.armbian.com/Developer-Guide_Build-Preparation/ 

13 hours ago, Igor said:

I notice SFP was properly detected, but link speed & reliability was not tested. 

 

Very professional test matrix which is great. The manufacturers should give you better support for this valuable service.

 

In my experience the detection, link speed and reliability are all excellent (for everyone $dmesg gives lots of info about the SFP module), not that my experience means anything, just commenting here in case anyone googles  

 

Thanks again!

This maybe looks like a stupid question, but i would like to try it out.

 

I have Khadas Vim 1 board, which is not officially supported by Armbian, but there are other Amlogic s905/x boards like Le potato or Odroid C2.

 

When i run compile.sh script, it only shows supported boards to build, there is no s905x board even in expert mode.

 

I would like to build an image for Vim, but i don't know what i have to change or add, to be able to build Ubuntu image for Vim.

 

I know there are Armbian images for S9xxx tv boxes, and they do work very well, but i would like to try to build it by myself.

 

Ignore this post, found it, i'm inexperienced with all of this, so sometimes you literally need to draw me the steps, i am a win user:)

I am trying to build from Balbes Amlogic source, i got 2 errors, error in function compile kernel (compilation.sh:404), failed moving kernel DEBs.

There's a line of code mv: missing destination file operand after 'home/khadas/build/output/debs/'.

I am doing this on Ubuntu xenial.