Back
[00:11:36] <linuxcnc-build> build #2298 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2298
[00:27:36] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[00:27:37] <linuxcnc-build> build #2299 forced
[00:27:37] <linuxcnc-build> I'll give a shout when the build finishes
[01:07:08] <linuxcnc-build> build #185 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/185
[01:07:24] <linuxcnc-build> build #21 of 4014.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-amd64/builds/21
[01:24:05] <linuxcnc-build> Hey! build 0000.checkin #2299 is complete: Success [3build successful]
[01:24:05] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2299
[01:58:08] <seb_kuzminsky> Get:1
http://buildbot.linuxcnc.org/ wheezy/master-rtpreempt linuxcnc-uspace amd64 1:2.7.0~pre0.717.g8b88a71 [5,258 kB]
[02:35:32] <seb_kuzminsky> aaaand:
[02:35:33] <seb_kuzminsky> Get:4
http://buildbot.linuxcnc.org/ wheezy/master-sim linuxcnc-uspace armhf 1:2.7.0~pre0.717.g8b88a71 [4941 kB]
[02:35:50] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 0000.checkin
[02:35:51] <linuxcnc-build> build forced [ETA 56m27s]
[02:35:51] <linuxcnc-build> I'll give a shout when the build finishes
[03:18:38] <linuxcnc-build> build #1815 of 4008.deb-precise-amd64 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/1815
[03:33:17] <linuxcnc-build> Hey! build 0000.checkin #2300 is complete: Success [3build successful]
[03:33:17] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2300
[03:46:45] <linuxcnc-build> build #187 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/187
[06:23:16] <jepler> seb_kuzminsky: getting closer
[06:29:18] <jepler> groan .. my odroid also has the problem that the fan turns on when the monitor is disconnected. crazy symptom of something wrong.
http://forum.odroid.com/viewtopic.php?f=77&t=3539#p28781
[06:29:58] <jepler> just as stated there, temperature reads as 50(000) on turning the monitor off, 39(000) e.g., if idle and monitor is on
[06:45:25] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/145206
[07:00:57] <jepler> if somebody complained linuxcnc was slow on a p4 I'd roll my eyes
[07:02:09] <skunkworks> heh
[07:48:54] <archivist> what language is the new mach4 bloatware written in?
[07:51:21] <archivist> must be javascipt that yahoo uses the web page has pinned my firefox at 100%
[08:34:14] <cradek> I think I'm going to need something with more ram for the sherline's machine. 256MB isn't quite enough anymore.
[08:34:32] <cradek> (it only has one ram slot, and doesn't recognize anything bigger)
[08:34:43] <cradek> too bad, because it's a neat little machine
[09:26:34] <CaptHindsight> Exynos4412 Prime CPU Module will be discontinued in Q2 2014
http://forum.odroid.com/viewtopic.php?f=80&t=5816
[09:29:41] <CaptHindsight> does that mean the ODROID-U3 is already obsolete?
[10:00:07] <seb_kuzminsky> i need to teach the buildbot to not try to build 2.6 debs on armhf
[10:09:48] <jepler> CaptHindsight: everything is already obsolete
[10:18:09] <pcw_home> If its available its obsolete
[10:21:29] <skunkworks> depressing ;)
[10:26:17] <CaptHindsight> lots of Exynos4412 Prime modules available in China, those won't disappear until after Samsung EOL's the device
[10:26:54] <CaptHindsight> hardkernel just seems to only sell their boards for about a year or so
[10:28:12] <CaptHindsight> their ODROID-XU and ODROID-XU+E with Exynos5 Octa Cortex™-A15 1.6Ghz quad core are also being discontinued this quarter
[10:40:42] <pcw_home> Thats the problem with most Arm dev boards, they are not
[10:40:44] <pcw_home> a platform in any sense (not all that surprising for cell phone chips)
[10:40:45] <pcw_home> Things made with industrial application targeted chips like the BeagleBone
[10:40:47] <pcw_home> will probably be more stable (if slower)
[11:07:20] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 0000.checkin
[11:07:21] <linuxcnc-build> build #2301 forced
[11:07:21] <linuxcnc-build> I'll give a shout when the build finishes
[11:15:20] <jepler> the difficulty of making a "(Linux)CNC product" based on ARM seems to be threefold .. (A) high enough performance in the CPU department (B) RT kernel availability and (C) I/O availability
[11:15:27] <CaptHindsight> pcw_home: harkernel has especially short lifetimes for their boards and Samsung got really picky about who gets docs and parts as soon as they were fast enough to be useful to replace x86
[11:15:37] <jepler> BBB / rpi fail at the first if you are just going to treat the embedded system like a full linux stack
[11:16:02] <cradek> (D) each particular product you have to customize everything for is gone from the market in a flash
[11:16:04] <jepler> everything shorter-lived fails (B) and/or (C), because who has the time to spin a new RT kernel or adapt to a new I/O connector
[11:17:26] <jepler> maybe (B) is going to get fixed in the next few years, with the ARM standardization stuff that is going on .. unfortunately, they standardized on UEFI and ACPI as far as I understand it
[11:17:50] <jepler> and (C) would be fixed if only they did put USB on the wrong side of a USB bridge
[11:18:14] <CaptHindsight> yes, since PC's need a BIOS so ARM must as well
[11:18:29] <jepler> just wait: the next "thumb" mode will actually be x86 code
[11:18:35] <jepler> "bigtoe"
[11:18:37] <jepler> you heard it here first
[11:21:15] <CaptHindsight> the ARM vendors also join Linaro and then release less source than before they joined
[11:22:25] <seb_kuzminsky> jepler: spi seems like a promising way to make C less painful (everyone's got a spare SPI port, right? right?)
[11:22:43] <jepler> seb_kuzminsky: yeah, but no standard SPI connector
[11:23:13] <seb_kuzminsky> that's why jesus invented jumper cables
[11:23:50] <jepler> and a variety of I/O standards
[11:25:31] <CaptHindsight> the Rpi and *duino have become psuedo-standard form factors and pinouts
[11:25:37] <jepler> I see 7i90 placed spi on the HD26 connector
[11:26:03] <CaptHindsight> just not very nice ones
[11:26:56] <jepler> so you just need some very simple (maybe only passives and connectors) card which goes onto your ARM's connector and has a HD26 connector
[11:29:09] <CaptHindsight> how about hm2_eth on ARM?
[11:29:19] <jepler> CaptHindsight: see above about ethernet being on the wrong side of a USB bridge
[11:29:53] <ssi> CaptHindsight: might be an issue because one ethernet
[11:29:53] <CaptHindsight> jepler: on your odroid :(
[11:29:57] <ssi> or that too
[11:29:58] <ssi> heh
[11:30:03] <jepler> also on cubietruck
[11:30:07] <ssi> I know of an arm board with two real gigabit phys
[11:30:14] <jepler> I have by no means looked at all the boards available though
[11:30:18] <seb_kuzminsky> jepler: you said hd26, did you mean dsub25?
[11:30:29] <archivist> jepler, you actually said usb <jepler> and (C) would be fixed if only they did put USB on the wrong side of a USB bridge
[11:30:49] <jepler> archivist: ah no wonder it made no sense
[11:30:56] <archivist> hehe
[11:30:58] <CaptHindsight> did/didn't
[11:31:01] <jepler> seb_kuzminsky: the 2x13 pins connector
[11:31:47] <seb_kuzminsky> ok
[11:32:00] <jepler> seb_kuzminsky: it's not a DB form factor, it's the .100" pitch shrouded header
[11:32:58] <CaptHindsight> SPI and ethernet are on the cubie2 headers,banana pi has SPI, have to check on its ethernet
[11:35:04] <seb_kuzminsky> jepler: P4, i see it now
[11:35:20] <jepler> seb_kuzminsky: yes.
[11:35:45] <CaptHindsight> did he really put ethernet on the cubietruck on USB?
[11:36:36] <jepler> CaptHindsight: let me make sure of that information.
[11:36:50] <CaptHindsight> checking the schematic now
[11:38:53] <CaptHindsight> ethernet uses the MAC in the A20
[11:39:03] <jepler> CaptHindsight: oh good, I'm happy to be wrong
[11:39:51] <CaptHindsight> jepler: but I wouldn't be surprised if they did something goofy
[11:40:18] <CaptHindsight> wifi bluetooth is on SDIO on the A20
[11:40:30] <pcw_home> The tegra T 1 looks really nice too bad its made by Nvidia
[11:41:08] <CaptHindsight> so ethernet uses the MAC in the A20 for cubie2, cubietruck and banana pi
[11:42:17] <CaptHindsight> also true for the
http://www.pcduino.com/
[11:43:21] <CaptHindsight> if the Exynos4412 Prime soc's are still in production it's easy enough to get those in BGA or on a COM board
[11:44:18] <CaptHindsight> Exynos4412 Prime would need SPI --> HM2
[11:44:46] <jepler> yeah, that's the only solution I see at the moment
[11:45:27] <CaptHindsight> imx6 boards have SPI and Ethernet
[11:46:27] <CaptHindsight> and PCIe
[11:46:48] <jepler> I'll be playing around with SPI on the odroid this weekend, but for me this is all just a "for fun" project
[11:47:45] <jepler> .. anyway, if the level translator board shows up I will
[12:03:57] <linuxcnc-build> Hey! build 0000.checkin #2301 is complete: Success [3build successful]
[12:03:57] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2301
[12:59:27] <pcw_home> CaptHindsight: have you tested a4 5000s?
[13:01:24] <pcw_home> dont normally like Biostar but this looks pretty decent:
[13:01:26] <pcw_home> http://www.newegg.com/Product/Product.aspx?Item=N82E16813138412
[13:07:13] <memleak> I have a biostar board. Only Fedora 17 works on it (18 19 20, ubuntu 11.04, 12.04, and 10.04 fail on it) but every 5 or 6 reboots it won't find grub.
[13:08:04] <memleak> once its up and running though its perfectly fine.
[13:09:15] <CaptHindsight> yeah, Biostar tends to have the worst BIOS
[13:10:51] <CaptHindsight> pcw_home: we have tested A4 4000 up to A10 6800, the problem is KMS and the new hardware drivers causing delay
[13:12:02] <CaptHindsight> with KMS disabled and using the llvmpipe driver we get under 10uS
[13:12:06] <pcw_home> Yeah video drivers are probably the cause of most latency issues
[13:12:49] <CaptHindsight> KMS on = 200uS+, KMS off = 8uS
[13:12:58] <pcw_home> Yow
[13:13:00] <memleak> radeon.modeset=0 && rm -rf /mesa/dri/directory/*radeonsi*
[13:14:39] <CaptHindsight> kernel mode setting is the worst with the Northern Islands and newer GPU's
http://wiki.gentoo.org/wiki/Radeon
[13:16:30] <memleak> some northern islands chips such as 6410D work fine however, such as E-350
[13:17:03] <memleak> havent noticed problems with these:
http://en.wikipedia.org/wiki/Radeon_HD_6000_Series#IGP_.28HD_6xxx.29
[13:40:47] <CaptHindsight> from what I understand preempt_rt relies on only the kernel scheduler and video drivers, X and/or KMS run tasks outside of scheduler
[13:42:38] <CaptHindsight> IIRC, xenomai and RTAI patch the kernel with ipipe that bypasses the kernel scheduler
[13:43:15] <pcw_home> most of which doesnt matter :-(
[13:43:45] <CaptHindsight> yet 3.4.9 RTAI with KMS left on has 200uS with the new GPU's and with KMS off <20uS
[13:44:05] <pcw_home> its not real unless you do I/O
[13:44:59] <CaptHindsight> well the point being that KMS is even clobbering the latency test
[13:45:40] <pcw_home> yeah thats pretty bad
[13:46:29] <pcw_home> like the proprietary nvidia driver
[13:46:34] <CaptHindsight> the radeon devs weren't aware of the issue and cyclictest is currently broken and only logs what goes through the scheduler
[13:47:17] <pcw_home> so may eventually get fixed
[13:47:34] <CaptHindsight> so when KMS is on we see USB or other tasks causing delays, nothing video driver related
[13:48:12] <CaptHindsight> it's so fragmented now, KMS has gpu driver stuff as does X
[13:52:17] <CaptHindsight> what would be handy is a kernel task logger that actually logs everything including ipipe
[13:53:38] <CaptHindsight> but the llvmpipe is so fast that we can run linuxcnc and play HD video just fine
[13:54:29] <pcw_home> hmm looks like KMS does monitor info polling, thats got to be bad
[13:55:14] <CaptHindsight> xenomai said they were going to follow preempt_rt for their next version
[13:55:50] <CaptHindsight> I'm not sure yet what scheduler they will use
[13:58:51] <CaptHindsight> with preempt_rt we noticed that page faults from firefox were causing major delays
[14:13:22] <CaptHindsight> "Xenomai 3 discontinues kernel space APIs"
[14:14:44] <CaptHindsight> http://www.xenomai.org/index.php/Xenomai:Roadmap#Xenomai_3_FAQ
[14:15:47] <CaptHindsight> so they don't seem to be concerned about losing 3-20uS by abandoning kernel space
[14:27:18] <seb_kuzminsky> hm, my mail to Francis Tisserant <tissf@free.fr> is bouncing :-/
[14:27:54] <cradek> maybe he should try @cheap.fr
[14:34:09] <seb_kuzminsky> i guess i'll take cradek's advise and "merge" the french docs by using tissf's version from 2.5 over the random weblate version that's currently in 2.6
[17:56:22] <jepler> pcw_home: I started my assembler from scratch a second time. now it's table-driven.
http://pastebin.com/UWpHsK7p
[18:38:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 ee09a87 06linuxcnc 10docs/src/config/ini_config.txt 10docs/src/gcode/overview.txt 10src/emc/usr_intf/pncconf/pncconf.py Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ee09a87
[18:41:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master b3d38ac 06linuxcnc 10(5 files in 4 dirs) Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b3d38ac
[18:42:10] <seb_kuzminsky> i'm gonna make 2.6.2 soon (for the xhc-hb04 fix), anyone have any fixes they want to get in?
[19:15:28] <jepler> seb_kuzminsky: not from here
[21:35:43] <cradek> seb_kuzminsky: I don't know of anything either
[21:48:42] <pcw_home> jepler: that looks great!
[21:48:43] <pcw_home> I should make a simple twiddler config to try twiddling I/O bits
[21:48:45] <pcw_home> (so download assembled binary to ROM, not recompile FPGA)
[22:09:01] <jepler> pcw_home: so in tasm it seems like 'ffh' can parse as a number. does that mean it can't be used as a label?
[22:09:08] <jepler> or do you have to write '0ffh' ?
[22:09:12] <jepler> or otherwise lead with a digit
[22:09:17] <jepler> oh hey it says that right abve
[22:14:04] <jepler> pcw_home: what is UNIQUE? It seems to have something to do with some fancy flow control macros you use...
[22:14:06] <jepler> DUMB8.MAC: UNIQUE ; This label goes to the false-clause, or the endif.
[22:14:53] <pcw_home> unique label i think
[22:15:20] <pcw_home> just a unique jump target label
[22:18:49] <pcw_home> I tend not to use the macro features much, the stuff GIlbert has
[22:18:50] <pcw_home> written uses all that "if else" stuff
[22:18:52] <pcw_home> some of the code is is portable to PICS/DSPICs with the right macros
[22:18:53] <jepler> the docs don't mention UNIQUE or DUP
[22:19:21] <pcw_home> maybe it was added to the assembler
[22:19:30] <pcw_home> (or macro processor)
[22:19:39] <jepler> oh, maybe your own addition?
[22:20:30] <jepler> there's yet a long way to go if I want to build sslbp.asm with my own assembler :-/
[22:20:49] <jepler> it uses these flow control macros pretty extensively
[22:21:07] <jepler> org 0
[22:21:07] <jepler> nop
[22:21:07] <jepler> nop ;whyyyy
[22:21:12] <jepler> hah
[22:21:39] <pcw_home> SSLBP Is probably the worst, you might try the ssremote code (I just wrote) it uses no macros
[22:22:29] <jepler> just my luck
[22:23:13] <jepler> I have a copy of TWID.ASM here, it looks pretty close to something I could assemble
[22:23:25] <pcw_home> yeah theres fancy macros and include file munging in SSLBP
[22:23:40] <jepler> It's just about bedtime here
[22:24:03] <jepler> anyway, I think I remember discussing that you're no Python hacker, but I went ahead and tossed what I have up here:
https://github.com/jepler/pta
[22:24:29] <pcw_home> Ill take a look
[22:24:54] <jepler> it includes a full(?) table for d8 converted from the TASMD8SS.TAB you sent me recently
[22:25:11] <jepler> right now I'm bogged down in parsing numbers :-P
[22:25:40] <jepler> but that, ignoring unknown .DIRECTIVES, and using EQU instead of = should get me pretty close to building TWID.ASM from 2011
[22:26:03] <pcw_home> Thats great since thata the latest and greatest 8 bit proc so very unlikely to change
[22:27:56] <pcw_home> you might compare your output it to twidrom.vhd
[22:29:24] <pcw_home> Actually its not a great example since its for an earlier processor
[22:29:24] <pcw_home> I'll update twidrom.vhd to the newer processor when I get a chance
[22:34:03] <skunkworks_> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/145216
[22:37:37] <jepler> pcw_home: hmm my assembler doesn't like it
[22:38:05] <jepler> commandregh equ 0401h ; (ptr) host interface command register
[22:38:05] <jepler> ldab commandregh
[22:38:12] <jepler> and I error: ValueError: 1025 (0x401) doesn't fit in 10 bits
[22:40:13] <jepler> but probably it is actually intending to get ldab @X,1 (?)
[22:40:17] <jepler> well, anyway, it's a night.
[22:40:25] <pcw_home> probably wrong comments in the .tab file
[22:45:23] <pcw_home> Ahh thats code for a one step earlier processor
[22:45:57] <pcw_home> ssremote code is better
[23:08:28] <skunkworks_> https://www.youtube.com/watch?v=qAqcAZq-vPM