Back
[01:59:47] <KGB-linuxcnc> 03Norbert Schechner 05master 9571c6b 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/gmoccapy/release_notes.txt gmoccapy_0_9_9_8_1 - jog_increments handling changed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9571c6b
[02:07:12] <KGB-linuxcnc> 03Norbert Schechner 05master 6eadae4 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen - initialize_manual_tool_change * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6eadae4
[05:25:27] <KGB-linuxcnc> 03John Thornton 05v2.5_branch 9b26e4d 06linuxcnc 10docs/src/config/ini_config.txt Docs: fix min angular velocity description and spelling errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9b26e4d
[07:12:18] <KGB-linuxcnc> 03John Thornton 05v2.5_branch 5751b1d 06linuxcnc 10docs/src/gcode/gcode.txt Docs: make the descriptions of a rapid move use the same terms * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5751b1d
[07:52:59] <skunkworks> cd ..
[07:53:01] <skunkworks> heh
[07:53:59] <pcw_home> cd Hawaii
[07:55:52] <skunkworks> I wish
[07:56:25] <skunkworks> pcw_home, did you see I got the hardware?
[07:56:30] <skunkworks> THanks again
[07:59:01] <archivist> sudo make warm
[07:59:37] <pcw_home> NP, when I get a chance I can send you a 7I76E which does work with whatever bugs exist in th current driver
[07:59:38] <pcw_home> (And I think micges will be able to look into this later this month)
[08:02:27] <skunkworks> I can wait. No rush. I am not using it other than testing.
[08:03:12] <skunkworks> micges is sooo busy... What can be more important than mesa!?
[08:04:00] <pcw_home> unimportant stuff like new baby
[08:04:35] <skunkworks> Pshaaaa - been there.. have the t-shirt.. (still there)
[08:05:54] <skunkworks> The baby does sleep...
[08:06:57] <pcw_home> not necessarily when you want...
[08:27:41] <skunkworks> a little benadryl goes a long way..
[08:28:05] <skunkworks> (that is a direct quote from another parent... (scary))
[09:56:38] <mozmck> heh!
[11:25:22] <memleak> rtai's first non-test 4.0 release is out
[11:35:41] <mozmck> The tarball is dated Dec 6, is there something newer?
[11:43:40] <memleak> no i just didnt notice it until now because paolo never updates the stupid home page
[11:43:51] <memleak> oh he left
[11:58:02] <memleak> no there isnt
[11:58:12] <memleak> @ mozmck
[11:58:27] <mozmck> ok
[11:58:40] <seb_kuzminsky> memleak: what's the relationship between paolo's rtai 4.0 and the rtai branch that shabby and you are working on, that i based our rtai kernel on?
[11:59:21] <mozmck> I did notice that there is a patch for 3.8.x kernel, isn't your kernel 3.5.x seb_kuzminsky?
[11:59:29] <seb_kuzminsky> mozmck: it's 3.4
[11:59:29] <memleak> 3.4
[11:59:34] <memleak> i beat you :P
[12:00:09] <memleak> our branch isnt your branch anymore
[12:00:24] <memleak> old-master is the rtai stuff you based the debs off of, master is based off of vulcano
[12:00:31] <memleak> vulcano is rtai 4.0
[12:00:52] <seb_kuzminsky> i thought vulcano was paolo's unstable development branch? and when it's ready to come out it's called 'magma'?
[12:01:02] <memleak> opposite way
[12:01:18] <seb_kuzminsky> oh, magma is dev, and then volcano releases it out to the world?
[12:01:22] <memleak> yep
[12:01:25] <seb_kuzminsky> aha
[12:01:46] <memleak> old-master is a heavily hacked version of rtai 3.9.1
[12:02:25] <seb_kuzminsky> so your old-master branch (that i used) was a bunch of fixes on top of paolo's magma/dev branch, and your new (current) master branch is those fixes rebased onto volcano (rtai 4.0)?
[12:03:31] <memleak> old-master was actually magma and vulcano combined, but you're right for the current branch
[12:03:36] <seb_kuzminsky> ok
[12:04:12] <seb_kuzminsky> just curious, did you get any of your patches into paolo's repo? or are you still carrying a huge stack of patches against his release?
[12:05:09] <memleak> i always wondered if vulcano is named after the volcano in italy (considering their all italian pretty much) or if they spelled volcano wrong, considering one of them is called magma
[12:05:38] <memleak> and paolo has been merging more and more of my work into the tree
[12:06:06] <seb_kuzminsky> that's great! yay for collaboration :-)
[12:06:11] <mozmck> Is this the repo for your stuff memleak?
https://github.com/ShabbyX/RTAI
[12:06:17] <memleak> yes mozmck
[12:06:23] <mozmck> thanks
[12:06:31] <memleak> master is still in development and not yet rock solid
[12:09:27] <memleak> i might actually update old-master until i figure out the right fixes for master
[12:20:59] <memleak> i mean it's a really stable super clean rtai branch, so i might as well
[12:21:19] <memleak> perhaps even integrate rtai 4.0 into it.
[13:22:53] <skunkworks> pcw_home, and the HD showed up.
[16:25:00] <seb_kuzminsky> linuxcnc-build_: force build --branch=unified-build-candidate-3 checkin
[16:25:01] <linuxcnc-build_> build forced [ETA 1h59m53s]
[16:25:01] <linuxcnc-build_> I'll give a shout when the build finishes
[17:30:43] <linuxcnc-build_> build #13 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/13
[17:31:35] <linuxcnc-build_> build #13 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/13
[17:33:00] <linuxcnc-build_> build #13 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/13
[17:33:05] <linuxcnc-build_> build #13 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/13
[17:40:05] <andypugh> What's the usual approach to a patch that won't "take" ?
[17:41:10] <andypugh> I am guessing that hand-editing the patch until it does take would be the wrong way?
[17:46:15] <linuxcnc-build_> build #5 of deb-wheezy-rtpreempt-binary-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-wheezy-rtpreempt-binary-amd64/builds/5
[17:46:24] <linuxcnc-build_> Hey! build checkin #1665 is complete: Success [3build successful]
[17:46:24] <linuxcnc-build_> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1665
[17:59:27] <linuxcnc-build_> build #1292 of deb-precise-sim-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-i386/builds/1292
[18:00:32] <linuxcnc-build_> build #1291 of deb-precise-sim-binary-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-amd64/builds/1291
[18:00:47] <linuxcnc-build_> build #121 of deb-precise-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rt-binary-i386/builds/121
[18:04:13] <linuxcnc-build_> build #1286 of deb-lucid-sim-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-i386/builds/1286
[18:14:37] <zultron> andypugh, usually you apply the patch. Bits that won't 'take' will create a .rej file next to the original. Then you're expected to edit the file manually.
[18:15:37] <zultron> The .rej file will contain the hunks that couldn't be applied.
[18:15:55] <andypugh> I am trying to use the xenomai "prepare kernel" script, that complans if the patch doesn't take, and doesn't do the rest of the job.
[18:17:15] <zultron> Oh, that's a bit different.
[18:17:39] <zultron> I guess you're having a go at that other ARM architecture.
[18:17:54] <zultron> Is it failing while applying the i-pipe patch?
[18:17:59] <andypugh> Yes
[18:18:19] <zultron> You can apply the i-pipe patch manually before running prepare_kernel.sh.
[18:18:19] <andypugh> There is a "pre" patch, the adeos patch, then a "post" patch.
[18:18:33] <andypugh> ls
[18:18:34] <zultron> Yeah, heh. Keep your chin up.
[18:19:26] <zultron> I think the purpose of the 'pre' patch is to get the tree fixed up to where the i-pipe patch applies cleanly.
[18:19:52] <zultron> You'd best find a way to document your steps, or you may find yourself doing this twice!
[18:20:03] <andypugh> Maybe the trick is to manually make the patches take, then create a new patch?
[18:20:13] <zultron> I believe so.
[18:20:22] <andypugh> What fun
[18:20:29] <zultron> Try to find out what goes into creating the pre- and post- patches.
[18:20:55] <andypugh> I have managed to compile one xeno-kernel on 3.0.43, but it doesn't boot the widget
[18:20:57] <linuxcnc-build_> build #1286 of deb-lucid-sim-binary-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-amd64/builds/1286
[18:20:59] <linuxcnc-build_> build #1287 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1287
[18:21:32] <andypugh> I feel to be annoyingly close.
[18:22:09] <zultron> Well, you've already lost me. 3.0.43 is the kernel version? And which widget?
[18:22:15] <andypugh> I think I might even have made all the patches apply once, but the Xenomai options weren't in menuconfig...
[18:22:41] <andypugh> The widget is a Udoo board
[18:22:45] <zultron> Well, once you apply the i-pipe patch, you should at least see the i-pipe options there (maybe just a few)
[18:23:06] <zultron> Oh, got it.
[18:23:40] <andypugh> The board has a quad core iMX6 and an Arduino, and 72 IO pins addressable by both (at the same time)
[18:23:46] <zultron> Then you need to get prepare-kernel.sh to finish. That applies another set of patches, so you may have more problems there.
[18:24:07] <zultron> Oh yeah, that's the kickstarter I heard about some time back. Neat!
[18:24:51] <andypugh> IO pins are in Arduino Mega format, so in theory LinuxCNC could drive all the Arduino shields (well, the 3.3V ones anyway)
[18:25:48] <zultron> That would be awesome. Arduino shields and HAL is like machine control legos.
[18:31:14] <andypugh> Just gone midnight, time for my dinner. I need days with more hours in them
[18:31:36] <zultron> Me too. See you!
[18:47:26] <CaptHindsight> andypugh: how do you like that board so far?
[18:47:40] <andypugh> I hate it, it never seems to boot :-)
[18:47:48] <CaptHindsight> it's one of the few I haven't tried yet
[18:47:58] <CaptHindsight> oh no
[18:48:21] <andypugh> To be fair, this is because I keep making bad kernels for it
[18:48:53] <CaptHindsight> going to start to work on the cubie with FPGA daughter
[18:49:11] <andypugh> It boots perfectly fine with the standard kernels
[18:49:19] <CaptHindsight> with 7i47S
[18:50:04] <andypugh> I am slightly upset that there isn't a fast data path between the Arm and the Arduino
[18:50:06] <CaptHindsight> is the Uodo (or whatever) pin compatible with arduino or?
[18:50:25] <CaptHindsight> really :(
[18:50:41] <andypugh> Yes, pin-compatible with Arduino Mega (though only 3.3V versions)
[18:50:48] <CaptHindsight> they get so close to a decent design ....
[18:50:55] <andypugh> 72 proper IO pins is pretty nice
[18:51:13] <CaptHindsight> BBB with a decent GPU would have been nice
[18:51:17] <andypugh> And, in theory, you can use those pins as a parallel data bridge
[18:51:55] <andypugh> The main link between the sides is a 115k serial bus
[18:52:12] <andypugh> 2.5M would have been better
[18:52:58] <CaptHindsight> it's ok if you're not moving data, but it would be nice if the latency was real low between processors
[18:54:27] <andypugh> I need to work out if 115k is enough. Given that you won't normally make more than 256 steps per channel per servo period it might be OK for offloading step-gen to the Arduino.
[18:54:49] <andypugh> And the Arduino is pretty good at PWM and analogue input.
[18:55:08] <andypugh> Hardware-interrupt encoder counters might be possible too.
[18:55:37] <andypugh> 128kHz encoder counting seems likely to work.
[18:55:38] <CaptHindsight> after you configure kernels for a few hundred times you get the hang of it :)
[18:57:20] <andypugh> I have done it a few times, this time it is unusually tricksy. I probably ought to configure "early printk" but to be honest I am not sure that the kernels (other than the Udoo stock one) that I have built so far even get there.
[18:58:02] <CaptHindsight> http://shop.udoo.org/usa/?___from_store=other&popup=no do you have the quad?
[18:58:18] <andypugh> I probably ought to look at rolling back the Udoo kernel git to stock and applying the Xenomai patch there
[18:58:26] <andypugh> Yes, I have the Quad.
[18:58:43] <andypugh> It was cheap enough not to have to think especially hard.
[18:59:41] <CaptHindsight> have you ever come across an x-y stage about the size and travel of whats in a DVD drive?
[19:00:00] <andypugh> Only for optical stuff
[19:00:35] <CaptHindsight> yeah, I have some pricey versions for microscopes
[19:00:53] <CaptHindsight> I'm trying to find something low budget low res
[19:01:22] <CaptHindsight> maybe I'll just print the plastic gears myself
[21:21:51] <memleak> hey andypugh i'm quite an experienced kernel hacker, what special features or performance modifications do you want for the kernel? is the cubieboard code included with the latest kernel.org stuff?
[21:22:21] <andypugh> memleak: This is a Udoo board, and the feature I want is Xenomai
[21:22:31] <Tom_itx> heh
[21:22:53] <andypugh> (and I will point out that your RTAI instructions were the only ones I ever found that worked)
[21:22:54] <Tom_itx> andypugh i was wondering which board you got
[21:23:01] <Tom_itx> ^^ i see you got the quad
[21:23:14] <memleak> andypugh: thats why i wrote them
[21:23:29] <memleak> and thanks :)
[21:24:00] <memleak> ah.. is udoo in vanilla?
[21:25:09] <andypugh> So far I have munged the kernel source to persuade adeos-ipipe-3.0.43-mx6q-1.18-12-pre.patch to work, then manually run adeos-ipipe-3.0.43-arm-1.18-13.patch (because it works manually, but not in prepare_kernel.sh). Then run prepare_kernel.sh with no errors, set up Xenomai in menuconfig, and hit: No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop.
[21:25:56] <andypugh> I am now chowning
[21:26:01] <memleak> don't use patch -p1 < commands with prepare_kernel.sh
[21:26:32] <memleak> it breaks the kernel tree
[21:26:32] <andypugh> Can you elaborate on what you mean by that?
[21:26:47] <memleak> only use prepare_kernel.sh
[21:26:57] <andypugh> I would love to.
[21:27:04] <andypugh> But it doesn't work
[21:27:24] <memleak> what happens if you only run the script without any manual patching?
[21:27:51] <andypugh> If I use patch, then there are no errors, and if I then run prepare_kernel.sh that also runs happily
[21:28:18] <andypugh> If I just run the script I get a whole bunch of failed hunks
[21:28:21] <memleak> the kernel itself won't run i can promise you that
[21:28:34] <memleak> xenomai won't work and it will kernel panic
[21:28:53] <andypugh> I am prepared to believe your promise. I am very good at non-running kernels
[21:29:15] <memleak> ok :)
[21:29:17] <andypugh> So, why does patch work for me, and not for the script?
[21:29:53] <memleak> i would assume the xenomai kernel patch in tree (in the ksrc directory) has not been written for whatever kernel version you are trying to patch it to
[21:30:09] <andypugh> Yes. That is indeed the case
[21:30:34] <memleak> easy way to fix it is use a kernel version source tree that does indeed match one of the xenomai patches
[21:30:44] <andypugh> <hollow laugh>
[21:30:59] <andypugh> WOuld you like to see how many kernels I have tried?
[21:31:19] <memleak> have any of the kernels you tried actually match the file names in the xenomai tree?
[21:31:55] <andypugh> One of them did
[21:32:07] <memleak> that failed?
[21:33:18] <andypugh> I have tried vanilla linux-3.0.43 and adeos-ipipe-3.0.43-arm-1.18-13.patch. That patches and compiled, but did not boot the Udoo
[21:33:41] <memleak> where did it fail?
[21:34:27] <memleak> it might just be a few settings in your kernel config, you used prepare_kernel.sh to patch it yes?
[21:35:26] <andypugh> I have tried following the README in the Xeno ksrc tree "1- Checkout the "rel_imx_3.0.15_12.03.00" tag in the Freescale IMX git [1]," but the patches did no actually take on that version.
[21:36:25] <andypugh> I have tried base-versions of both rel_imx_3.0.15 and linux-3.0.43 and they, too, fail to boot the Udoo
[21:36:50] <memleak> with 3.0.43 did you use prepare_kernel.sh without any manual patch -pX commands?
[21:37:04] <andypugh> The only kernel I have managed to build that actually boots the board is built from the Udoo GIT checkout.
[21:37:31] <andypugh> Yes, I think that 3.0.43 took the script.
[21:37:42] <memleak> you think?
[21:37:43] <andypugh> (I should have taken notes, of course I didnt
[21:37:47] <memleak> ah
[21:39:46] <memleak> well if you want to debug it and see if you can get that kernel fixed, try booting 3.0.43 using only the xenomai kernel patch script, and build the kernel, boot it, and if you can take a picture or capture over serial of all the kernel output where it dies, from there i can see whats wrong and what needs to be done to fix it.
[21:40:26] <memleak> also how do you know which options to select in the first place? what base kernel config are you using?
[21:41:36] <andypugh> Ah, no, the kernel that took the "middle" patch and compiled was the Freescale 3.0.15 and that did this
http://pastebin.com/BiSm3Q5L
[21:42:47] <andypugh> Xenomai mxc is a bit messy, there is a patch to step it back to look like 3,0,15, then the real patch, then another patch to step it back!
[21:43:03] <memleak> i'd stick with 3.0.43 and forget about 3.0.15
[21:43:21] <andypugh> I have been using make ARCH=arm UDOO_defconfig as a starting point
[21:43:44] <memleak> udoo_defconfig is in vanilla 3.0?
[21:43:52] <andypugh> Of course not
[21:44:31] <memleak> ah you copied it from the freescale? tree to the vanilla tree?
[21:44:52] <andypugh> I have only ever seen the Udoo boot with 3.0.35 compiled from the Udoo git repo
[21:45:11] <memleak> i know and i'm trying to help you change that
[21:45:26] <memleak> i can get make anything boot :)
[21:45:26] <andypugh> And as far as I know UDOO_defconfig only exists in the UDOO git
[21:45:44] <andypugh> But I have been spreading it about my system
[21:46:25] <memleak> ok, just so i have a clear understanding, you're copying udoo_defconfig to the vanilla kernel tree (3.0.43) patched with xenomai using prepare_kernel.sh and that isn't booting?
[21:47:24] <andypugh> As far as i recall, that is the case
[21:47:41] <andypugh> I would have to reset that folder and try again to be 100% sure
[21:48:20] <memleak> to be safe i would do that to have a solid starting point
[21:48:40] <memleak> if it doesn't work post where the kernel craps out and let's go from there
[21:50:14] <memleak> it would be interesting to try prepare_kernel.sh with the 3.0.43 patches against the official udoo kernel, 3.0.35
[21:50:52] <memleak> if it doesn't patch cleanly i can make modifications to the xenomai tree or adeos itself to make it patch cleanly
[21:50:53] <andypugh> I have spent all evening applying the patches to the kernel repo I know works
[21:51:19] <andypugh> So I would like to follow that through.
[21:51:19] <memleak> the udoo tree?
[21:51:25] <andypugh> Yes
[21:51:33] <andypugh> 3.0.35
[21:51:40] <memleak> ok are any of the patches for 3.0.43 not applying to 3.0.35?
[21:51:54] <andypugh> Not now.
[21:52:10] <memleak> they are not, not applying?
[21:52:55] <andypugh> I fiddled with stuff to make the ..pre.patch work, I then copied two header files from 3.0.43 to 3.0.35 to make the main patch work.
[21:53:46] <memleak> which header files, specifically
[21:53:51] <andypugh> Then the prepare_kernel.sh script at least didn't complain, and the Xenomai options appeared in menuconfig
[21:55:10] <memleak> i want to make sure you aren't removing board-specific code by making those changes
[21:55:29] <memleak> so i can cross reference the header files
[21:55:48] <andypugh> I almost certainly am :-)
[21:55:51] <andypugh> Bear with me
[21:56:46] <andypugh> cacheflush.h and pgtable.h
[21:57:51] <memleak> include/asm-generic ?
[21:57:58] <andypugh> No
[21:59:07] <memleak> arch/arm/include/asm ?
[22:00:31] <andypugh> manually, to fix bits of ...pre.patch yes
[22:04:08] <memleak> that part doesn't seem to be the problem
[22:04:32] <andypugh> The problem is that I am a blundering buffoon :-)
[22:05:01] <memleak> heh i'm just trying to figure out what part it stops booting and why
[22:06:07] <andypugh> It stops after the third and final full-stop of "Starting Kernel ..."
[22:06:34] <memleak> oh dear.. it doesnt give you any dmesg output upon start-up?
[22:06:40] <memleak> that's debugging in the dark 101
[22:06:57] <memleak> you're going to have to see more output if you want to get anywhere with this.
[22:07:59] <andypugh> That is through the serial terminal
[22:08:17] <andypugh> There is _no_ screen display or dmesg
[22:08:30] <memleak> serial should tell you a lot more than that..
[22:08:45] <andypugh> I suspect it doesn't get the chance
[22:09:26] <memleak> I've done this many times with ARM kernel development; you might have to go into make menuconfig and modify the serial output options to send stuff over a specific port upon boot up
[22:09:59] <andypugh> I looked for 'early printk" but failed to find it
[22:10:38] <memleak> not only early printk but there is a text box for the serial device location
[22:12:00] <memleak> in the in-kernel command line you can modify the kernel boot params and in that text box set your console= options
[22:12:14] <memleak> for example console=tty console=ttyS0,128000
[22:13:06] <andypugh> Is there an in-kernel command line with uboot?
[22:15:05] <memleak> http://www.stlinux.com/u-boot/kernel-booting yes :)
[22:18:03] <andypugh> This might be a new record for early failure. It is hanging at "CHK include/linux/version.h" during the compile stage
[22:18:21] <memleak> heh!
[22:19:23] <memleak> are you sure your compiler is set-up right? are you using something like crosstool-ng or the environment provided by the arduino guys?
[22:19:59] <andypugh> I am compiling natively on the board
[22:20:58] <andypugh> (it's a quad-core 1Ghz thing, not exactly lightweight)
[22:21:54] <memleak> holy crap nice!
[22:22:02] <CaptHindsight> you're making this about as hard as you can on yourself
[22:22:21] <andypugh> CaptHindsight: Yes
[22:22:56] <andypugh> I can only get interested in projects that I am not sure I am capable of
[22:23:41] <andypugh> memleak: Given time, it actually moved on from version.h and got as far as arch/arm/mm/dma-mapping.c:368:6: error: implicit declaration of function ‘pgprot_writethrough’ [-Werror=implicit-function-declaration]
[22:24:06] <memleak> ok one moment
[22:25:30] <memleak> i dont see board specific code there, try moving dma-mapping.c from 3.0.43 to .35 like the two headers you did before
[22:25:57] <andypugh> I will point out that, at the moment, I have not run the ...post patch, that might well put that declaration back
[22:26:22] <memleak> no it has to do with the headers you moved
[22:26:53] <memleak> dma-mapping.c includes from <asm/cacheflush.h>
[22:27:26] <memleak> xenomai adeos and prepare_kernel.sh have nothing to do with it
[22:28:16] <memleak> i forgot how much fun kernel hacking is :)
[22:34:49] <memleak> if that doesnn't work or makes the problem worse, undo the move and add this to pgtable.h
[22:35:00] <memleak> #define pgprot_writethrough(prot) \
[22:35:07] <memleak> __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_WRITETHROUGH)
[22:35:53] <memleak> right above #ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
[22:36:08] <andypugh> <ponder> I don't think I left myself an option to und that move.
[22:36:42] <andypugh> But, it is still compiling, so it looks to have helped
[22:36:54] <memleak> the moving of dma-mapping worked?
[22:37:17] <andypugh> Currently compiling: CC kernel/xenomai/nucleus/sched-rt.o
[22:37:24] <andypugh> :-)
[22:37:29] <memleak> sweetness
[22:52:21] <andypugh> Bah!
[22:52:23] <andypugh> arch/arm/plat-mxc/cpu.c: In function ‘setup_debug_uart’:
[22:52:23] <andypugh> arch/arm/plat-mxc/cpu.c:15:2: error: ‘uart_at_24’ undeclared (first use in this function)
[22:52:47] <andypugh> I definitely messed wth that file
[22:54:55] <andypugh> memleak: Help!
[22:56:04] <andypugh> The xenomia..,pre patch deletes very nearly all of that file. It now looks like this:
http://pastebin.com/kxvWwb6i
[22:57:04] <andypugh> I am just not seeing "setup_debug_uart"
[22:58:04] <andypugh> Ah, no, wait...
[22:58:17] <andypugh> Looking in the wrong project....
[22:59:42] <memleak> where are you at now?
[22:59:46] <memleak> sorry i got distracted
[23:00:31] <andypugh> Quite a long way into the compile.
[23:01:24] <memleak> still dead at cpu.c?
[23:01:41] <andypugh> After manually applying the adeos...pre.patch there was not a lot left of cpu.c. It now looks like this:
http://pastebin.com/XZwA8Ttn
[23:02:14] <andypugh> And, yes, really, uart_at_24 is undefined
[23:02:24] <memleak> xD one moment
[23:02:58] <andypugh> memleak: No need
[23:03:13] <andypugh> I see that the adeos...post.patch puts it back
[23:03:34] <memleak> ok.
[23:03:52] <memleak> i was about to give you a cd && wget command
[23:04:20] <andypugh> I was experimenting, and it seems clear that the post patch needs to be used too
[23:05:00] <andypugh> I really do not see why they couldn't combine pre + main + post into a single patch?
[23:06:12] <memleak> not sure.
[23:08:18] <andypugh> I suspect I can just checkout cpu.c from the repo?
[23:08:39] <memleak> yes
[23:09:06] <memleak> i honestly dont know what you mean by post main and pre patch
[23:09:33] <memleak> not much of a xenomai guy, ratehr just an all around kernel hacker
[23:11:59] <andypugh> http://git.xenomai.org/xenomai-2.6.git/tree/ksrc/arch/arm/patches/mxc?id=v2.6.3
[23:12:19] <andypugh> If you navigate up a level then the README explains
[23:29:56] <andypugh> So, as this is a uboot setup, once I have mu uImage, do I need to do anything more than put that in /boot/ ? System.map perhaps?
[23:43:04] <memleak> might as well
[23:44:10] <andypugh> ?
[23:45:20] <memleak> put system.map and uimage in /boot
[23:50:37] <andypugh> OK. Not got there yet