Jump to content

Tinkerboard build 4.4-119 fail & questions


Rfreire

Recommended Posts

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 by Rfreire
Added question #2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 :-)

 

Link to comment
Share on other sites

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

 

 

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