Tinkerboard build 4.4-119 fail & questions

[Rfreire]

Hello there @Igor and board;

 

Two things :-)

 

1. Potential problem. I'm trying to build a crafted Kernel image and I found tat some patches does not apply cleanly, being:

 

[ warn ] * [l][c] 04-patch-4.4.114-115.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.115-116.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.116-117.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.117-118.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.118-119.patch [ failed ]
[ warn ] * [l][c] 220_uart4_fix.patch [ failed ]

 

And finally, I have a build failure:

 

  CC      lib/zlib_inflate/inflate_syms.o
sound/usb/pcm.c: In function ‘set_sync_ep_implicit_fb_quirk’:
sound/usb/pcm.c:361:2: error: duplicate case value
  case USB_ID(0x1397, 0x0002):
  ^~~~
sound/usb/pcm.c:352:2: note: previously used here
  case USB_ID(0x1397, 0x0002):
  ^~~~
scripts/Makefile.build:277: recipe for target 'sound/usb/pcm.o' failed
make[2]: *** [sound/usb/pcm.o] Error 1
make[2]: *** Waiting for unfinished jobs....
  CC      kernel/pid_namespace.o
  CC      fs/btrfs/hash.o
scripts/Makefile.build:484: recipe for target 'sound/usb' failed
make[1]: *** [sound/usb] Error 2
Makefile:1016: recipe for target 'sound' failed
make: *** [sound] Error 2
make: *** Waiting for unfinished jobs....

Have you guys seen that?

 

Question #2.

 

Well, I was able to overcome that by disabling the sound/multimedia driver tree (won't be my use case anyways :-).

 

And now I'm experimenting with different kernel configurations.

 

When using compile.sh, is it possible to "read" a previously created .config so I don't have to setup _everything_ again prior to making a build?

 

Thanks for your attention! : -)

Edited April 7, 2018 by Rfreire
Added question #2

[TonyMac32]

The issue is an update to the vendor kernel.  If you build against the development branch it will succeed.

 

in config-default.conf (if that's the config you're using) add LIB_TAG="development"

 

We're having a discussion now about how to better handle development changes/the repo, the development branch was an experiment to avoid breaking nightly builds before more thorough testing than one person can usually do. 

 

Once we get it all straightened out I would of course recommend sticking with the master branch unless you're actively developing

[Rfreire]

Ah thanks a lot, Tony!

 

Patches has just applied perfect and cleanly.

 

Now what about a build frenzy when you are changing stuffs. How do you do over there?

 

As in my original post, trying to remember everything from last .config and navigating the whole curses tree is... complicated :-)

 

[Rfreire]

3 hours ago, Rfreire said:

Now what about a build frenzy when you are changing stuffs. How do you do over there?

 

As in my original post, trying to remember everything from last .config and navigating the whole curses tree is... complicated :-)

 

 

 

Ah. Read the fancy manual :-)

./compile.sh KERNEL_KEEP_CONFIG=yes