Back
[08:24:00] <skunkworks> zlog,
[09:29:27] <seb_kuzminsky> https://lists.ubuntu.com/archives/ubuntu-announce/2015-March/000193.html
[09:46:45] <skunkworks> wow - 5 years
[09:49:04] <archivist> dont wanna upgrade!
[09:52:40] <pcw_home> probably dont have to unless its connected to the net and theres a hard to work-around exploit
[10:02:44] <jepler> yeah, I would not be afraid to continue using any working linuxcnc installation provided (A) I never, ever browsed the web from it and (B) I had no services exposed directly to the internet (and (C) I didn't care about any features in newer linuxcnc either)
[10:06:52] <skunkworks> when will linuxcnc stop supporting 10.04?
[10:07:15] <skunkworks> it was reletivley recently that 8.04 was dropped
[10:08:25] <seb_kuzminsky> the only reason i can think of to stop supporting a distro is when we start build-depending or depending on software that's not available for that distro
[10:08:39] <seb_kuzminsky> that's why we dropped hardy, it doesnt have libusb or something that we needed
[11:09:26] <pcw_home> I think pathpilot is running on 10.04
[11:15:31] <cradek> that's kind of a surprising choice
[11:17:40] <pcw_home> Since I dont have a copy its just a rumor, but maybe they started with it and have not upgraded
[11:21:00] <skunkworks> that is the consensus
[11:22:02] <skunkworks> they are getting around the lockieness of the control. (opening up gedit - go to help - opens firefox..)
[13:10:44] <mozmck> has anyone played with CPU shielding with the preempt-rt kernel?
https://rt.wiki.kernel.org/index.php/CPU_shielding_using_/proc_and_/dev/cpuset
[15:52:58] <andypugh> I haven’t even managed to make a preempt-rt kernel which boots yet
[15:53:14] <memfrob> O_O
[15:53:30] <memfrob> seriously?? are you making your own kernel configs?
[15:54:28] <andypugh> No, I am copying the existing config, applying the patch and still managing to compile kernels that won’t boot even without actually enablung RT
[15:55:13] <andypugh> Which I think takes special skill
[15:55:58] <memfrob> cp -prv arch/x86/boot/bzImage /boot/vmlinuz-vernum-rt && make modules_install && grub2-mkconfig -o /boot/{grub,grub2}/grub.cfg ?
[15:56:34] <memfrob> the old fashioned way should always work..
[15:56:39] <andypugh> I should perhaps mention I am not working wth x86
[15:56:53] <memfrob> very similar method
[15:57:14] <andypugh> I decided to see what the RPi2 was like with PREMPT-RT
[15:58:09] <andypugh> (And that is the very example they suggest in their tutorial, so my failure makes me a very special case)
http://www.raspberrypi.org/documentation/linux/kernel/patching.md
[15:58:41] <memfrob> change x86 to <arch you're using> then for modules INSTALL_MOD_PATH="mod_output" make modules_install && cp -prv mod_output/* /path/to/cross-compiled-distro/lib/modules/<kernel version you're using>
[15:59:15] <andypugh> The Pi git config has loadable modules disabled
[15:59:26] <memfrob> are you getting kernel panics or a kernel load error when u-boot tries to boot?
[15:59:40] <andypugh> And some “magic” seems to want to always boot from kernel7.img
[16:00:12] <andypugh> I get a rainbow square. Which apparently is a graphics system test, and no further output.
[16:00:13] <memfrob> so its not the kernel itself but the bootloader..
[16:01:12] <memfrob> have you tried using the upstream u-boot bootloader for the pi?
[16:01:27] <memfrob> i dont think theres any "magic" if you compile u-boot and flash yourself
[16:01:29] <andypugh> No
[16:01:51] <memfrob> raspberry pi is in official denx repo
[16:02:37] <andypugh> Everything I have read seems to say that it ought to be as easy as cp /arch/arm/boot/zImage /boot/kernel7.img
[16:03:00] <memfrob> .img to me sounds like an initrd, not *zImage
[16:03:11] <andypugh> I am in the middle of compiling the stock kernel with the stock config to see if I can make even that unbootable.
[16:03:25] <memfrob> enable earlyprintk and see whats going on w/ UART debug
[16:03:38] <memfrob> thats how i've been able to build kernels for any arm board i've worked with
[16:03:59] <andypugh> I am a bit short of uarts
[16:04:17] <memfrob> FTDI adapters you mean?
[16:04:33] <andypugh> Ones not glued to an Arduino anyway
[16:04:50] <memfrob> what does ardunio have to do with compiling a kernel for a pi?
[16:05:06] <andypugh> It seems that there ought to be a standalone USB-powered pure LCD serial terminal out there, but I have never found one.
[16:05:20] <memfrob> you look at the serial output of the pi, not arduino
[16:05:56] <andypugh> Yes, I am just saying that I have dozens of ftdi adaptors, but they are all on Arduino boards and none are loose.
[16:06:16] <memfrob> oh i see
[16:06:24] <memfrob> sorry i misunderstood
[16:06:35] <memfrob> earlyprintk=vga?
[16:07:00] <andypugh> I don’t think I am even getting that far
[16:07:51] <memfrob> try vanilla upstream uboot and see what happens?
[16:08:34] <andypugh> I don’t think that a vanilla kernel will run on the Pi SoC
[16:08:48] <memfrob> vanilla uboot, not kernel
[16:09:01] <andypugh> In that case you are using a language I don’t speak
[16:09:07] <memfrob> uboot is the bootloader
[16:09:37] <memfrob> the firmware that does the hw init and boot params and such
[16:09:53] <memfrob> power on -> uboot -> kernel -> distro
[16:10:00] <andypugh> I might try that later. Changing the bootloader seems to be gettting _futher_ away from the problem rather than closer though.
[16:11:08] <memfrob> i always change the bootloader first and work my way in closer to kernel and distro building
[16:11:47] <memfrob> i dont trust the factory boot loaders to work with custom kernels and suc
[16:12:01] <memfrob> usually stuff is hardcoded and whatnot
[16:12:46] <memfrob> (i.e. only loads kernels from kernel7.img in a given path)
[16:14:18] <memfrob> bbl
[16:16:53] <andypugh> well, I just managed to fail with a complete stock kernel, but I have proved that kernel= in /boot/config.txt works :-)
[17:59:58] <memfrob> sounds like a uboot problem
[18:00:43] <cradek> I think the pi2 does not use uboot
[18:04:18] <memfrob> pi2 is in uboot
[18:04:30] <memfrob> whether it comes with it is another story
[18:04:35] <CaptHindsight> andypugh: just FYI
http://openlunchbox.com/smf/index.php?topic=48.0 feedback, opinions, criticisms, funny looks appreciated
[18:05:42] <memfrob> uboot is my fav and i highly recommend it in all cases where it supports the hw :D
[18:06:46] <cradek> apparently the *GPU* loads the kernel directly somehow
[18:13:40] <andypugh> cradek: That would fit with me getting a graphics test and nothing after that.
[18:14:52] <andypugh> So, perhaps my problem is actually related to the graphiocs firmware…
[18:15:41] <cradek> seems like the web is full of people not being able to boot it, and wishing it would use uboot
[18:19:18] <andypugh> Booting it is no problem. Booting it with _my_ kernel image eludes me.
[18:20:05] <memfrob> uboot-tree/board/raspberrypi/rpi_2 it can use uboot it just doesnt come with it
[18:20:27] <memfrob> crosstool-ng, some dd commands and voila
[18:20:37] <andypugh> I seem to recall spending weeks messign abut with uboot on the Udoo too…
[18:21:20] <memfrob> once you get used to it reflashing boards with it becomes a breeze
[18:21:59] <andypugh> I don’t want to get used to it. I wanted to tweak the kernel once last sunday and then move on to interesting projects.
[18:22:11] <memfrob> the tricky part is just knowing the right memory addresses and offets for it
[18:22:43] <andypugh> I can’t manage the easy parts.
[18:23:34] <memfrob> have you looked at elinux.org/RPi_U-Boot ?
[18:23:53] <andypugh> No
[18:24:08] <andypugh> I am still in the middle of the kernel compile I started earlier this evening.
[18:26:11] <andypugh> I do at least know how to recover a bootable Pi when my kernels fail at the moment. There is no suggestion that the Pi isn’t trying to boot from my kernels. I don’t, thereofore, see why the answer is likely to be a change in boot loader.
[18:27:07] <memfrob> follow instructions here? elinux.org/Raspberry_Pi_Kernel_Compilation
[18:28:11] <memfrob> it even says you should update the firmware to make sure your new kernel works.
[18:28:32] <memfrob> i dont think its possible to just swap kernels without some hacking at the firmware
[18:28:49] <andypugh> I am puzzled as to why those instructions are 10x as comple as the ones on the RPi site.
[18:29:33] <andypugh> http://www.raspberrypi.org/documentation/linux/kernel/building.md
[18:29:36] <memfrob> apparently the "next" branch for the firmware.git repo is required to use kernels newer than 3.6
[18:30:03] <andypugh> But the eLinux instructions appear to be for the arm6 boards. as it is kernel7.img for the new Pi
[18:30:16] <memfrob> "next - This is a development branch which provides a newer GPU firmware to work with the updated drivers in the 3.6 kernel"
[18:30:42] <andypugh> My Pi is already booting happily from the stock 3.18.7 kernel
[18:30:50] <cradek> the rpi2 is a GPU with a computer accidentally stuck on the side
[18:31:05] <mozmck> yes, pi2 != pi
[18:32:10] <memfrob> I'm just highly convinced your problems will not magically go away making new kernels and recompiling different kernels over and over again, expecting a different result.
[18:32:15] <andypugh> cradek: This is why it makes a so much better PC than the Beagle, which is so hopeless that Machinkit seem to have given up on using it for the GUI and almost mandate a separate PC for the GUI stuff. Which rather leaves me wondering why you need to have the Beagle at all.
[18:32:32] <memfrob> I suggest hacking at the bootloader a bit, that is the best advice I can give.
[18:32:57] <cradek> andypugh: some people also prefer to buy a windows license or an ipad and incorporate those somehow
[18:33:04] <memfrob> it's the only way i think you're ever going to get at least a different result than you are now.
[18:33:14] <cradek> andypugh: I don't try to understand it all anymore
[18:33:18] <andypugh> And I am saying that I see no evidence that there is anything wrong with the bootloader, as it boots and loads the standard kernel every time.
[18:33:56] <memfrob> right, because there's magic in the kernel or elsewhere like i said, something somewhere else hardcoded that prevents your custom one from loading.
[18:34:26] <andypugh> If I install a new bootloader I almost guarantee that my imcompetence will see me unable to even boot the original kernel any more.
[18:34:36] <memfrob> if you cant regenerate the stock one, then some "magic" such as you said is happening, and i believe that is in the bootloader
[18:35:08] <memfrob> theres not much else magic can happen
[18:35:26] <andypugh> I am currently compiling the actual stock kernel from the original repo. If that doesn’t work then I know that there is witchcraft at play.
[18:35:42] <memfrob> only other possibility is theres something wrong with your compiler
[18:35:58] <memfrob> and its flipping bits around on your custom kernel making it unbootable
[18:36:30] <memfrob> in which case ive seen boards, namely by ARCHOS, which i could not reproduce stock kernels with without their specific GCC toolset
[18:37:06] <andypugh> I am not saying that you are wrong about the bootloader. I am saying that if that is the case then I have totally lost interest and the board is going back on the shelf.
[18:37:08] <memfrob> crosstool-ng, codesourcery, etc. all would fail. so its either bootloader or compiler
[18:37:52] <memfrob> i always figured i'd run into issues with a pi hence why i never even bought one in the first place
[18:38:56] <andypugh> They make a great wireless pring server if you install Avahi and CUPS
[19:00:18] <mozmck> seb_kuzminsky: what is the plan on the new configure stuff?
[19:33:30] <andypugh> Hooray! Pleased by failure! I made a bootable kernel. With no USB or networking, bit at least it booted.
[19:42:52] <skunksleep> Yay!? :)
[19:44:15] <PCW> easier to frame working vs not working when you have an example of both
[19:44:19] <andypugh> Well, I know that the make modules failed, looks like something in the actual code
[19:45:06] <PCW> save your working .config !
[20:36:53] <cradek> yay andy
[20:41:46] <mozmck> hmm, the build dependencies do not appear to be complete.
[20:42:33] <mozmck> I built a package that depends on the build dependencies using (mk-build-deps -B control)
[20:43:10] <cradek> that would be surprising since we use pbuilder on buildbot. what do you find is missing?
[20:43:16] <mozmck> Installed that on a new computer, but ./configure --with-realtime=uspace failed because it was missing bwidget, tclx, and libtk-img
[20:43:41] <mozmck> after installing those I could successfully run ./configure
[20:44:00] <seb_kuzminsky> mozmck: you touched the config stuff last, its your problem now :-P
[20:44:03] <cradek> hmm is buildbot uspaceing? surely it is
[20:44:14] <mozmck> haha!
[20:44:27] <cradek> well wherever the buck is I'm sure it's not here
[20:44:49] <mozmck> The stuff I touched is sitting in the deb-new-configure branch :) what is the plan for that?
[20:45:01] <seb_kuzminsky> mozmck: src/configure checks for runtime dependencies, in addition to the build-time dependencies that debian/configure checks for
[20:45:26] <mozmck> aha, so that would explain it.
[20:45:36] <seb_kuzminsky> see src/configure's --disable-check-runtime-deps
[20:45:54] <mozmck> I thought debian/configure would call src/configure ... oh I see.
[20:46:01] <seb_kuzminsky> mozmck: i guess at this point we should probably put it in master rather than 2.7
[20:46:11] <seb_kuzminsky> deb/conf and src/conf are totally separate
[20:46:13] <mozmck> well ignore me then!
[20:46:33] <mozmck> ok, sounds good
[20:47:39] <seb_kuzminsky> cradek: yes, the buildbot builds & runtests & packages uspace debs for 2.7 and newer
[20:48:38] <cradek> I was going to go check, but I got distracted by a terrible metafilter thread instead
[20:48:39] <seb_kuzminsky> on both vanilla and rt-preempt kernels
[20:48:47] <cradek> thanks for doing all that
[20:50:13] <seb_kuzminsky> found a picture of cradek:
http://imgur.com/JStNf
[20:50:27] <cradek> yep that's me
[20:51:13] <cradek> actually today I took the day off work, finished and mailed my taxes AND got the oil changed in the car
[20:51:21] <cradek> I feel like such an adult
[20:51:57] <seb_kuzminsky> http://i.imgur.com/tK0E6.jpg
[20:52:02] <seb_kuzminsky> this meme never stops
[20:52:21] <seb_kuzminsky> oil *and* taxes?! that's like two things! nice work :-)
[20:53:04] <cradek> yes I'm as amazed as you are
[20:53:48] <seb_kuzminsky> i barely managed to go to work and stare blankly at build failures all day
[20:56:36] <seb_kuzminsky> yay, i burned an install image to a usb drive
[20:56:39] <seb_kuzminsky> i deserve an internet break
[20:56:56] <cradek> is that hard?
[21:04:10] <seb_kuzminsky> no, it's easy, you just open a new tab and type reddit
[21:06:49] <cradek> oh you
[22:46:08] <cradek> gosh I wish I had arbitrary arcs (want to cut some spherical stuff)
[22:50:29] <cradek> wait I think I can use planar arcs if only I could do a little math
[22:51:19] <Roguish> hello all. are both base_period and servo_period used in a servo hostmod2 system???
[22:51:47] <cradek> usually a base thread is not needed, but you can do whatever you want
[22:52:24] <Roguish> ok, so the primary thread is the 'servo_thread', yes?
[22:54:01] <Roguish> i've been getting a lot of 'unexpected real time delays.....' and am trying to sort is all out.
[23:00:18] <pcw_home> Yeah, normally a base thread is just a liability if not absolutely needed
[23:01:21] <Roguish> pcw_home: thanks. won't even put it in. Is ACPI off by default in all these realtime kernel?
[23:01:35] <pcw_home> if you are getting "unexpected real time delays" on a 1 KHz servo thread something is funky
[23:02:33] <pcw_home> I dont think its off as I think its required to power down the computer
[23:05:10] <pcw_home> usually at the minimum you need to turn off all power management in the BIOS
[23:05:16] <Roguish> well, I just figured out how to get the VESA display driver working. not really straightforward.
[23:06:22] <Roguish> I have turned off as much of the power management in the BIOS as possible. Added 'ACPI=OFF' to the kernel line in grub.cfg
[23:20:14] <mozmck> pcw_home: in your kernel config, did you turn off cpu freq scaling?
[23:27:00] <pcw_home> Yes
[23:27:19] <pcw_home> Well I think I did
[23:28:30] <mozmck> cpu idle support as well?
[23:28:33] <pcw_home> a couple people noticed Atheros wireless was turned off
[23:29:17] <mozmck> what about the ACPI stuff? I remember from doing this with RTAI that BUTTON was fine and allowed you to turn power off.
[23:30:28] <pcw_home> not sure about idle (i messed with it on the kernel command line and it didn't seem to make much if any difference)
[23:30:53] <mozmck> The ACPI Thermal Zone stuff is HIGHLY recommended it says
[23:31:00] <pcw_home> I dont think the basic acpi stuff is harmfull
[23:31:39] <pcw_home> I know if i run the sensors stuff from the laptop its bad for latency
[23:31:49] <pcw_home> (the utility)
[23:32:06] <mozmck> Ok, I'll leave the defaults and see how it performs. Could be some of it is only bad if you use it (like the sensors stuff)
[23:33:02] <pcw_home> something very bad happens on the laptop if you pull the charger cord...
[23:33:34] <mozmck> Hmm, that could be because of the ACPI AC adapter and/or Battery settings.
[23:34:30] <mozmck> Well, I'm not too worried about laptops right now. Fine for testing but I doubt they are the best for running machines.
[23:34:44] <pcw_home> I didn't try messing further with it, and not sure I want it running full blast on batteries
[23:35:02] <pcw_home> no but handy for demos etc
[23:35:12] <mozmck> true.
[23:35:35] <pcw_home> perhaps testing also
[23:35:56] <mozmck> user space wakeup sources - if I don't let it go to sleep I probably don't need those either
[23:36:36] <pcw_home> No, screen savers are also a likely latency problem
[23:37:38] <mozmck> Yes, I guess it's best to disable them for a control.
[23:37:54] <mozmck> Maybe allow the screen to go blank after a long time or something
[23:38:45] <pcw_home> Yeah you can get burn-in I notice (though it seems to go away after a while)
[23:39:28] <pcw_home> (linuxcnc test computer has screen saver disabled)
[23:39:55] <mozmck> I often set it to blank after an hour, so it's not doing it while I'm working.
[23:42:45] <Roguish> night all. thanks cradek and pcw_home
[23:43:40] <pcw_home> ack the 7i92 project file is missing from the hostmot2 source
[23:44:26] <mozmck> hmm, I built a bitfile - I guess I used a different one.
[23:44:52] <pcw_home> Hmm looks like I can power the 7I92 from the laptops USB port
[23:48:41] <mozmck> Were you talking about the hostmot2 firmware project? I used the etherhm2.xise project. I think I had to change the chip and ucf file.
[23:48:50] <pcw_home> Yeah there's a generic Ethernet project file but I have one for the 7I92 with the right FPGA chip and .ucf file bound
[23:52:47] <pcw_home> wasn't sure the laptop USB would work for power without anything to enumerate but it seems fine
[23:52:49] <pcw_home> I guess they need to run those little lights and humping dogs
[23:56:56] <mozmck> You can charge non-usb stuff with them I know.
[23:57:52] <mozmck> I think you have to pull the D+ line low before the computer even knows something is there.
[23:57:59] <mozmck> Or something like that.
[23:59:14] <pcw_home> not sure, maybe the two wire cable I have does that in the connector
[23:59:29] <mozmck> I think the power is there all the time
