Anyone have an audio cape working in 4.1.x?

My overlay is constantly changing, so having it in initramfs was causing problems.

BUT: I don't seem to be able to unload my overlay once it's applied, so I have to reboot anyway.

Your script worked great!

Now, if I make a change to the source and want to rebuild and re-generate the .debs, what do I do?

TIA,

./tools/rebuild_deb.sh

Regards,

Hmm, that seems to do a LOT of work. It re-presented menuconfig, which I just exited, and then it cleaned a bunch of directories, tarred up linux-upstream again, and is rebuilding everything.

I just want to recompile the one file I changed (or any that depended on it, but this was a .c file), and have it re-build the .debs, etc.

but... it's not redoing the "KERNEL" directory.. :wink:

upsteam "make deb-pkg" does all that extra stuff, save your self by
install "ccache" and enabling 2GB for ~/.ccache

Regards,

Your script worked great!

Now, if I make a change to the source and want to rebuild and re-generate the .debs, what do I do?

./tools/rebuild_deb.sh

Hmm, that seems to do a LOT of work. It re-presented menuconfig, which I just exited, and then it cleaned a bunch of directories, tarred up linux-upstream again, and is rebuilding everything.

I just want to recompile the one file I changed (or any that depended on it, but this was a .c file), and have it re-build the .debs, etc.

but... it's not redoing the "KERNEL" directory.. :wink:

upsteam "make deb-pkg" does all that extra stuff, save your self by

So, would I just

$ cd KERNEL
$ make
$ make deb-pkg

install "ccache" and enabling 2GB for ~/.ccache

Okay, I'll look into this. Seems like a bandaid over a broken build, if one can't just analyze the dependencies and skip build steps that don't need to happen.

Your script worked great!

Now, if I make a change to the source and want to rebuild and re-generate the .debs, what do I do?

./tools/rebuild_deb.sh

Hmm, that seems to do a LOT of work. It re-presented menuconfig, which I just exited, and then it cleaned a bunch of directories, tarred up linux-upstream again, and is rebuilding everything.

I just want to recompile the one file I changed (or any that depended on it, but this was a .c file), and have it re-build the .debs, etc.

but... it's not redoing the "KERNEL" directory.. :wink:

upsteam "make deb-pkg" does all that extra stuff, save your self by

So, would I just

$ cd KERNEL
$ make
$ make deb-pkg

That's what: "./tools/rebuild_deb.sh" does..

install "ccache" and enabling 2GB for ~/.ccache

Okay, I'll look into this. Seems like a bandaid over a broken build, if one can't just analyze the dependencies and skip build steps that don't need to happen.

it's just for "deb-pkg" packaging script... the "./tools/rebuild.sh"
that just calls make is more sane and would have just updated the one
file..

Regards,

Your script worked great!

Now, if I make a change to the source and want to rebuild and re-generate the .debs, what do I do?

./tools/rebuild_deb.sh

Hmm, that seems to do a LOT of work. It re-presented menuconfig, which I just exited, and then it cleaned a bunch of directories, tarred up linux-upstream again, and is rebuilding everything.

I just want to recompile the one file I changed (or any that depended on it, but this was a .c file), and have it re-build the .debs, etc.

but... it's not redoing the "KERNEL" directory.. :wink:

upsteam "make deb-pkg" does all that extra stuff, save your self by

So, would I just

$ cd KERNEL
$ make
$ make deb-pkg

That's what: "./tools/rebuild_deb.sh" does..

Yeah, I just tried its make invocation...rebuilding everything again. Even with ccache, this would be too much.

install "ccache" and enabling 2GB for ~/.ccache

Okay, I'll look into this. Seems like a bandaid over a broken build, if one can't just analyze the dependencies and skip build steps that don't need to happen.

it's just for "deb-pkg" packaging script... the "./tools/rebuild.sh"
that just calls make is more sane and would have just updated the one

Ah, okay, I'll try that next.

Oof, even ./tools/rebuild.sh takes too long. I then tried:

  $ make bone_capemgr

But that wants to re-run an interactive configuration step. Then I realized I was missing a bunch of stuff, so I tried

  $ make -j8 ARCH=arm KBUILD_DEBARCH=armhf LOCALVERSION=-bone0 KDEB_CHANGELOG_DIST=trusty KDEB_PKGVERSION=1cross KDEB_SOURCENAME=linux-upstream CROSS_COMPILE=/home/rmann/bbb/bb-kernel/dl/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- bone_capemgr

Turns out, bone_capemgr isn't a module I can just rebuild. Or if it is, I'm in the wrong place. Anyway, yeah this will quickly discourage me from hacking on the kernel if I can't find a much faster way to try changes.

My method is:

./build_kernel.sh

(stop after menuconfig pop's up..)

(make changes)

./tools/rebuild.sh

insert mmc card:

./tools/install_kernel.sh

insert card into bbb and boot..

(repeat make changes)

Regards,

Yeah. If you find a compile error in your change, you've just wasted 5 minutes. It's like when I was 9 programming on an Apple II that required me to swap the floppy with the Pascal compiler with the floppy with my code on it 20 times per compile.

What's the difference between linux-image* and linux-firmware-image*?

TIA,

don't bother with the firmware package.

Regards,

Heh. Okay.

So, there are some differences between 4.1.4-ti-r9 and 4.2.1-bone2 regarding the da830-evm-audio (davinci_evm.c). I haven't looked into them yet, but things are worse in 4.2.1. Here are the dmesg logs:

https://github.com/JetForMe/podtique/wiki/da830-evm-audio-Differences-between-Kernels

git clone https://github.com/RobertCNelson/bb-kernel/
cd bb-kernel/
git checkout origin/am33x-v4.3 -b tmp
./build_deb.sh

(menuconfig loads → enable uio_pruss)

copy linux-image*.deb to board, run: sudo dpkg -i linux-image*.deb
then reboot…

@Robert

So essentially, this does everything your build guide on eewiki does, but automatically ? Well, as far s compiling the kernel, and well . . . now that I think about it. It’s the same set of scripts?

Just got round to doing this myself, as now I have a need to start experimenting with the PRU’s but wow . . .

Usually I’m very good at thinking “outside of the box” but totally did not even think to use this script in this way . . . Totally awesome, and well done Robert( again ). Totally blew my mind here hah !

In the past the "make deb-pkg" which ./build_deb.sh used was very
un-reliable in cross arch environments.. the linux-headers package
still is completely broken when built for "armhf" on "x86.."

but... it's better then it was before, as (builddeb script) is being
fixed on mainline and i've been backporting the script..

Regards,

errr . . .

william@pc:~$ uname -a
Linux eee-pc 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u2 i686 GNU/Linux

:confused: