Jump to content

H3/NanoPI Neo stock build failed


Sfinx

Recommended Posts

Hello,

 

While trying to build full Devian Jessy image for NanoPi Neo at stock x86_64 Ubuntu 16.04 using latest https://github.com/igorpecovnik/libgit , got this:

 

...

[ o.k. ] Compiling default kernel [ 3.4.113 ]
[ o.k. ] Compiler version [ arm-linux-gnueabihf-gcc 5.4.0 ]
[ o.k. ] Using kernel config file [ lib/config/kernel/linux-sun8i-default.config ]
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.hash.c
  SHIPPED scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
drivers/net/wireless/bcmdhd/Kconfig:56:warning: defaults for choice values not supported
 
 Armbian building script, http://www.armbian.com| Author: Igor Pecovnik
 â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€
  ┌────────────────────────────────────────────────────────────────────────────────────────────────â”
  │ Compiling kernel...                                                                            â”‚  
  │────────────────────────────────────────────────────────────────────────────────────────────────│  
  │   CC [M]  net/netfilter/ipvs/ip_vs_wrr.o                                                       │  
  │   CC [M]  net/netfilter/ipvs/ip_vs_lc.o                                                        â”‚  
  │   CC [M]  net/netfilter/ipvs/ip_vs_wlc.o                                                       │  
  │   CC [M]  net/netfilter/ipvs/ip_vs_lblc.o                                                      â”‚  
  │   CC [M]  net/netfilter/ipvs/ip_vs_lblcr.o                                                     │  
  │   CC [M]  net/netfilter/ipvs/ip_vs_dh.o                                                        â”‚  
  │   CC [M]  net/netfilter/ipvs/ip_vs_sh.o                                                        â”‚  
  │   CC [M]  net/netfilter/ipvs/ip_vs_sed.o                                                       │  
  │   CC [M]  net/netfilter/ipset/ip_set_list_set.o                                                â”‚  
  │   CC [M]  net/netfilter/ipvs/ip_vs_nq.o                                                        â”‚  
  │   LD [M]  net/netfilter/ipset/ip_set.o                                                         │  
  │   CC [M]  net/netfilter/ipvs/ip_vs_ftp.o                                                       │  
  │   CC [M]  net/netfilter/ipvs/ip_vs_pe_sip.o                                                    â”‚  
  │   LD [M]  net/netfilter/ipvs/ip_vs.o                                                           │  
  │   LD [M]  net/netfilter/nf_conntrack.o                                                         │  
  │   LD      net/netfilter/netfilter.o                                                            â”‚  
  │   LD      net/netfilter/built-in.o                                                             │  
  │   LD      net/built-in.o                                                                       │  
  
    
 
 
[ error ] ERROR in function compile_kernel [ common.sh:249 ]
[ error ] Kernel was not built [ @host ]
[ o.k. ] Process terminated 
....
 
 
The full kernel compile error is covered by dialog output so no way (!?) to see it. The question is : how to compile the image without this stupid ncurses dialog - just using plain tty with normal error output ?
 
TIA, Rus
 
Link to comment
Share on other sites

ok, the actual error is:

 

...

/bin/sh: 1: Syntax error: Unterminated quoted string
/home/rus/Projects/rtpdev/v2/sources/linux-sun8i/sun8i/drivers/gpu/mali/mali/Kbuild:273: recipe for target 'drivers/gpu/mali/mali/__malidrv_build_info.c' failed
make[4]: *** [drivers/gpu/mali/mali/__malidrv_build_info.c] Error 2
scripts/Makefile.build:443: recipe for target 'drivers/gpu/mali/mali' failed
make[3]: *** [drivers/gpu/mali/mali] Error 2
scripts/Makefile.build:443: recipe for target 'drivers/gpu/mali' failed
make[2]: *** [drivers/gpu/mali] Error 2
scripts/Makefile.build:443: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:948: recipe for target 'drivers' failed
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
....
 
And caused by armbian/patch/kernel/sun8i-default/add-mali-r3p0-fixed.patch. The only thing I can't understand beside untested patch - is why to enable the Mali at NanoPi Neo board which do not has any video output ????
Link to comment
Share on other sites

The only thing I can't understand beside untested patch

Untested  :lol:

https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sun8i-default/add-mali-r3p0-fixed.patch

Last change more than 4 months ago (not counting previous versions), so it worked fine for several releases and tons of nightlies and user builds.

 

is why to enable the Mali at NanoPi Neo board which do not has any video output ????

Because the kernel configuration is the same for all H3 based boards, and FEX configuration (in case of the legacy kernel) and /etc/modules contents define what is actually used on different hardware.

 

/bin/sh: 1: Syntax error: Unterminated quoted string

/home/rus/Projects/rtpdev/v2/sources/linux-sun8i/sun8i/drivers/gpu/mali/mali/Kbuild:273: recipe for target 'drivers/gpu/mali/mali/__malidrv_build_info.c' failed

If you check the Kbuild file that produces this error, you'll see that it collects some info about build machine and build configuration (including date, CPU type, configuration name, ...), so something inserts unterminated or unescaped quote, which breaks the build process for you. This didn't happen for anybody before (at least there were no reports of build breakages for this particular reason).

Link to comment
Share on other sites

Untested  :lol:

https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sun8i-default/add-mali-r3p0-fixed.patch

Last change more than 4 months ago (not counting previous versions), so it worked fine for several releases and tons of nightlies and user builds.

 

Because the kernel configuration is the same for all H3 based boards, and FEX configuration (in case of the legacy kernel) and /etc/modules contents define what is actually used on different hardware.

 

If you check the Kbuild file that produces this error, you'll see that it collects some info about build machine and build configuration (including date, CPU type, configuration name, ...), so something inserts unterminated or unescaped quote, which breaks the build process for you. This didn't happen for anybody before (at least there were no reports of build breakages for this particular reason).

 

If you check echo section in 'man bash' you will find useful the following patch which fixes problem with this buggy patch :

 

..

--- sources/linux-sun8i/sun8i/drivers/gpu/mali/mali/Kbuild.orig 2017-02-24 18:48:09.929512034 +0200
+++ sources/linux-sun8i/sun8i/drivers/gpu/mali/mali/Kbuild 2017-02-24 19:28:26.386511134 +0200
@@ -270,4 +270,4 @@
 
 # Create file with Mali driver configuration
 $(DRIVER_DIR)/__malidrv_build_info.c:
- @echo 'const char *__malidrv_build_info(void) { return "malidrv: $(VERSION_STRINGS)";}' > $(DRIVER_DIR)/__malidrv_build_info.c
+ @echo "const char *__malidrv_build_info(void) { return \"malidrv: $(VERSION_STRINGS)\";}" > $(DRIVER_DIR)/__malidrv_build_info.c

..

 

Because the kernel configuration is the same for all H3 based boards, and FEX configuration (in case of the legacy kernel) and /etc/modules contents define what is actually used on different hardware.

 

 

It is 'we do not care' like answer. So I think your logic is not consistent. If you state that have the NanoPI Neo board supported and have the actual board config - then follow this logic. Otherwise just remove all the H3 boards and use the generic 'H3' kernel config ;)

It is definitely armbian configuration bug that have to be fixed - this board do not have the HDMI or TV out.

Link to comment
Share on other sites

It is definitely armbian configuration bug that have to be fixed - this board do not have the HDMI or TV out.

 

OMFG! Check Armbian documentation how to prevent this patch that causes troubles on your machine from being applied (empty file with same name in appropriate userpatches dir).

 

Be assured that we will still use one single kernel config and one set of patches per $LINUXFAMILY in the future. And please try to understand Zador's answer regarding 'FEX configuration (in case of the legacy kernel) and /etc/modules contents'. Thanks!

Link to comment
Share on other sites

It is 'we do not care' like answer. So I think your logic is not consistent. If you state that have the NanoPI Neo board supported and have the actual board config - then follow this logic. Otherwise just remove all the H3 boards and use the generic 'H3' kernel config ;)

It is definitely armbian configuration bug that have to be fixed - this board do not have the HDMI or TV out.

So what next? Will you ask Debian or Ubuntu maintainers to disable Nvidia GPUs support in the future because your build host uses AMD GPU or something similar?

Armbian kernel package in question is called linux-image-sun8i and kernel configuration is called linux-sun8i-default, so it applies to all devices that use SoC of sun8i family (in Armbian legacy kernel case this includes only H3 SoC). Having per-board compile time kernel config is something that I can't imagine even for a bad dream scenario, since per-board differences can be solved at runtime and the only "disadvantage" is a small amount of wasted disk space.

 

Also nobody prevents you from building a minimal kernel for yourself - that's what Armbian build system is for, and any problems with the build can be solved without questioning release scheme.

 

If you check echo section in 'man bash' you will find useful the following patch which fixes problem with this buggy patch

This "buggy patch" is Mali Utgard kernel driver imported without significant changes to the build process.

Link to comment
Share on other sites

Armbian kernel package in question is called linux-image-sun8i and kernel configuration is called linux-sun8i-default, so it applies to alldevices that use SoC of sun8i family (in Armbian legacy kernel case this includes only H3 SoC)

 

 

 

I see

 

 

This "buggy patch" is Mali Utgard kernel driver imported without significant changes to the build process.

 

 

 
So what ?  It uses the wrong quotes type which will work only for en_US locale. Seems like not the patch but globe need to be corrected ;))
Link to comment
Share on other sites

So what ?  It uses the wrong quotes type which will work only for en_US locale. Seems like not the patch but globe need to be corrected ;))

Well, now that we know that this may cause build issues, we can just remove this "build info" or make it static. And regarding 'man bash' - /bin/sh in Ubuntu by default is linked to dash, not bash, and dash may have different quotes processing logic.

Link to comment
Share on other sites

It is the worst build system I've ever saw:

 

- bunch of shell scripts with spread out and not documented vars inside

- it is hiding build errors by default with useless dialogs

- broken overbloat logic where you have to select the board but not its kernel config as appeared that config is silently shared among several boards

- no way to apply custom patch _after_ the builtin patch stage

- useless for developing as cleans and restarts all the build tree over again

- support in term - "it works for us (admins) and we do not care if it do not works for users"

 

Sorry, I do not see how I can use this.

Link to comment
Share on other sites

It is the worst build system I've ever saw:

 

And the only one? I am sure there is room for improvement, but just don't expect that you will jump on experienced developer level in one day. This script become complex if you go out of default zone. This build system is used by us on daily basis and there more and more 3rd party users who are using it for their purpose. If something goes wrong, we fix it or they fix it - with specific fixes, since saying "this script sux" is useless information.

 

Sorry, I do not see how I can use this.

 

Feel free to use and compare to alternative solution if you make them work  :D  

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=2451&extra=

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=394

Link to comment
Share on other sites

It is the worst build system I've ever saw

I have a feeling you didn't find the build system documentation (it is linked on the bottom the project page) if you are asking following questions

 

- bunch of shell scripts with spread out and not documented vars inside

I'm assuming you have a better alternative in mind for such a project?  :)

 

- it is hiding build errors by default with useless dialogs

PROGRESS_DISPLAY=plain

 

- broken overbloat logic where you have to select the board but not its kernel config as appeared that config is silently shared among several boards

No comments, was discussed above

 

- no way to apply custom patch _after_ the builtin patch stage

Patches are applied in order based on their file name (LC_ALL=C sort order). Do I need to explain further how to make your patch apply after the builtin ones?

 

- useless for developing as cleans and restarts all the build tree over again

If only there were variables like CLEAN_LEVEL, FORCE_CHECKOUT and KERNEL_KEEP_CONFIG that control this behavior...

 

- support in term - "it works for us (admins) and we do not care if it do not works for users"

I don't know what kind of support are you expecting. Using telepathy or similar skills to find out what produces extra quote in your environment?

Link to comment
Share on other sites

I have a feeling you didn't find the build system documentation (it is linked on the bottom the project page) if you are asking following questions

 

 

The project sucks if people need documentation to see the build errors.

 

I'm assuming you have a better alternative in mind for such a project? 

 

 

Sure, the old plain make always rules. Just try to study the Linux kernel build system.

 

 

PROGRESS_DISPLAY=plain

 

 

 
It must be set by default. But seems like by default you are more comfortable to hide the build errors.
 
No comments, was discussed above

 

 

No discussion was made as you are not familiar with simple logic that you have been created by your own for this project. Try to dig in it again: people forced to select the board but not board config (!?) Seems like overbloat is normal for you but not to the rest of the embedded world where every byte has its own weight.

 

Patches are applied in order based on their file name (LC_ALL=C sort order). Do I need to explain further how to make your patch apply after the builtin ones?

 

 

So people need the special sorting rule for trying to fix the broken patches ? This is pure sh#t logic. Think a little bit more about moving the userpatches stage after the built-in ones.

 

If only there were variables like CLEAN_LEVEL, FORCE_CHECKOUT and KERNEL_KEEP_CONFIG that control this behavior...

 

 

Try to build custom u-boot with FORCE_CHECKOUT=no in latest git. You even never tested your poor scripts. So my original critic was that these variables are spreaded among several scripts. If you are not able to create the good build system - try at least create the single clear and working config for current one.

 

I don't know what kind of support are you expecting. Using telepathy or similar skills to find out what produces extra quote in your environment?

 

 

Do no lie at least here. Re-read the first post of this thread and your first answer. Your first answer about build error was not figuring out its actual cause but bold statement that all is working locally to you.

 There exist the funny didactic story about fire fighter that is exact same as you: some person called the fire station and crying that his house at fire. But the fire fighter have been answered the following: "I'm having the same house in front of me - and it is all ok wit it."

 

Try to turn by the face not ass to your users and may be you will have some positive feedback.

 

Good bye

Link to comment
Share on other sites

OMFG! Check Armbian documentation how to prevent this patch that causes troubles on your machine from being applied (empty file with same name in appropriate userpatches dir).

 

Be assured that we will still use one single kernel config and one set of patches per $LINUXFAMILY in the future. And please try to understand Zador's answer regarding 'FEX configuration (in case of the legacy kernel) and /etc/modules contents'. Thanks!

 

It will not work as the single kernel config over the same $LINUXFAMILY assumed that videoadapter must be present. You shoot yourself  in the foot...

Link to comment
Share on other sites

 

And the only one? I am sure there is room for improvement, but just don't expect that you will jump on experienced developer level in one day. This script become complex if you go out of default zone. This build system is used by us on daily basis and there more and more 3rd party users who are using it for their purpose. If something goes wrong, we fix it or they fix it - with specific fixes, since saying "this script sux" is useless information.

 

 

Feel free to use and compare to alternative solution if you make them work  :D  

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=2451&extra=

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=394

 

Yes the room for the improvement can exist only when developers have the clear mind without "f#ck off, it works for me" garbage

Link to comment
Share on other sites

Good bye

 

Bye bye!

 

It's soooo sad to loose such a genius like you trying so hard to improve things with constructive criticism but unfortunately we can't do better! It's our fault since we're way too stupid for our shitty scripts and this world in general (same applies to all other satisfied users of Armbian's build system for sure) but we're not able to realize this since we're suffering from Dunning-Kruger syndrome (we're too stupid to realize how stupid we are -- fantastic, isn't it?! You might visit youtube and let explain that to you by John Cleese)

Link to comment
Share on other sites

Bye bye!

 

It's soooo sad to loose such a genius like you trying so hard to improve things with constructive criticism but unfortunately we can't do better! It's our fault since we're way too stupid for our shitty scripts and this world in general (same applies to all other satisfied users of Armbian's build system for sure) but we're not able to realize this since we're suffering from Dunning-Kruger syndrome (we're too stupid to realize how stupid we are -- fantastic, isn't it?! You might visit youtube and let explain that to you by John Cleese)

 

No sad here - you just unable to accept the critics. Its dead end. Bye

Link to comment
Share on other sites

@Igor, @zador, I second the suggestion to make 'PROGRESS_DISPLAY=plain' the default (I use this all the time myself, we might check our usual invocation of compile.sh to overthink some other defaults too)

 

No, this not armbian way - why not  add another dialog layer ? It is definitely better for the developers - they are happy to iterate over the same things forever - errors, endless compiles, etc.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines