Back
[08:31:12] <jepler> https://lwn.net/Articles/643918/ Jailhouse 0.5 released ... Linux-based partitioning hypervisor Jailhouse ... Consequently, running cyclictest over a -rt kernel in a cell gives native latencies
[09:12:00] <seb_kuzminsky> jepler: neat!
[10:49:28] <cradek> aha!
[10:49:29] <cradek> [ 103.793630] Failed to communicate with pluto-servo board after programming firmware.
[10:49:55] <cradek> the error message is the same, but after adding 220 pullup to +5 on strobe, it programs (the LED goes out)
[10:51:34] <cradek> I wonder if I need pullups on some other pins too
[10:53:54] <cradek> maybe 14, 17
[10:56:24] <pcw_home> also, is it really getting set into EPP mode?
[10:58:41] <pcw_home> I think that the open drain outputs (at least on some parallel port hardware) change to push-pull when in EPP mode
[11:04:02] <kwallace> I would think the Pluto would need EPP to do any (two-way) communication with the parallel port?
[11:17:33] <cradek> pin 16 needs pullup, 14 seems sharp, I only see one low pulse, maybe after programming? it's 70ns wide
[11:18:54] <cradek> ahh 17 is slow rise too
[11:19:55] <cradek> I'm going to add pullups to 14,16,17
[11:26:30] <pcw_home> My experience with the Sun1888 with a 7I43 (years ago) was that it would not work with a long cable, maybe its the same issue
[11:26:44] <cradek> interesting
[11:39:05] <cradek> those three pullups made the signals look nice, but it still fails to communicate after (successful) programming
[11:41:46] <pcw_home> maybe its not in EPP mode
[11:42:34] <cradek> you mean the sun card?
[11:43:13] <jepler> outb(0x80, ioaddr_hi + 0x2); // select EPP mode in ECR
[11:43:21] <jepler> this is what pluto driver does to switch from SPP to EPP mode
[11:43:53] <jepler> if(board[i].port.base_hi) {
[11:43:53] <jepler> outb(0x94, board[i].port.base_hi + HM2_7I43_ECP_CONTROL_HIGH_OFFSET); // select EPP mode in ECR
[11:43:57] <jepler> vs what 7i43 does
[11:44:14] <jepler> hm2_7i43_epp_write_control(0x04, &board[i]); // set control lines and input mode
[11:44:27] <jepler> 7i43 also does this
[11:46:05] <jepler> bit 4 is "ecp interrupt bit", bit 3 is "dma enable bit". It's surprising to me to set those bits true for EPP mode.
[11:46:22] <jepler> (bits 4 and 3 of ECP ECR, the difference between 0x80 and 0x94)
[11:48:08] <jepler> cradek: have you run a mesa epp board on this parport?
[11:49:43] <cradek> nope, interesting idea
[11:54:35] <pcw_home> I can't remember what I did to test the SUN1888
[11:54:36] <pcw_home> probably just set EPP mode by hand and ran my loopback test
[12:31:52] <skunkworks> that should be part of the printer port driver... That would fix issues some have with the gecko 540
[12:34:58] <skunkworks> seems setting the port to EPP in the bios doesn't alway make linux see it as EPP
[12:38:26] <PCW> yeah there's some pretty weird PP hardware out there (and really none of it should require a driver)
[13:10:53] <skunkworks> right.
[14:26:13] <cradek> http://pastie.org/10187289
[14:26:40] <cradek> the 7i43 DONE light turns off, but it doesn't work
[14:27:29] <cradek> unfortunately I am 70% sure this 7i43 works (it's very old, from seb, with some rework on it)
[14:29:34] <PCW> Done light turning off is a good sign (programmed OK via EPP)
[14:30:04] <PCW> so valid bit file CRC etc
[14:30:24] <cradek> epp is used for programming it?
[14:30:32] <PCW> yes
[14:31:05] <cradek> I have so many unknowns...
[14:31:45] <PCW> unless the driver emulates EPP by byte banging but I dont think so
[14:33:30] <PCW> CPLD handles EPP handshake until FPGA is programmed then hands control to FPGA (when DONE is asserted)
[14:34:43] <cradek> so you think this could be a bad 7i43?
[14:35:55] <PCW> possibly but if you got done to go out I think its not too likely
[14:36:25] <PCW> only power LED on when programmed?
[14:36:26] <archivist> using the same par port as earlier experiments you were talking about?
[14:39:28] <PCW> at power up there should be three lights on
[14:39:29] <PCW> Yellow power
[14:39:31] <PCW> Red /INIT
[14:39:32] <PCW> Red /DONE
[14:39:34] <PCW> only yellow power LED should remain on after programming
[14:39:51] <cradek> init stays on after programming
[14:40:30] <cradek> yeah only DONE turns off
[14:43:40] <PCW> hmm that could be a CRC error
[14:44:33] <cradek> I picked at random config=firmware=hm2/7i43/SVST4_4B.BIT
[14:44:33] <PCW> I was not even aware that was possible (done asserted but bad FPGA load)
[14:45:05] <PCW> any should be fine
[14:45:39] <PCW> as long as it for a 7I43 with the correct size FPGA
[14:45:55] <PCW> 400K version?
[14:46:08] <cradek> [ 1569.366287] hm2/hm2_7i43.0: board has FPGA '3s400tq144', but the firmware in hm2/7i43-2/SVST4_4.BIT is for FPGA '3s200tq144'
[14:46:14] <cradek> oh another tells me this
[14:46:16] <cradek> lemme try a -4
[14:47:19] <cradek> 7i43-4/SVST4_4.BIT does the same thing - DONE led turns off
[14:47:41] <PCW> short cable?
[14:47:44] <cradek> with 7i43-2/SVST4_4.BIT both lights stay on, I get that "wrong size" error
[14:47:56] <cradek> yes 3' or less
[14:48:00] <cradek> let me try another
[14:48:09] <PCW> arghh
[14:49:37] <PCW> maybe cycle power since DONE asserted but bad FPGA load it not recoverable any other way
[14:49:58] <cradek> argh it's the wrong gender
[14:50:09] <cradek> I have cycled power (unplugged usb) each time
[14:51:22] <cradek> haha
[14:51:29] <cradek> third cable, both LEDs turn off, computer hangs
[14:52:22] <cradek> first DONE turned off, then INIT also turned off
[14:52:28] <cradek> rebooting...
[14:54:42] <cradek> yep same again, DONE turns off, INIT turns off, pc hangs
[14:54:48] <cradek> wt absolute f
[14:55:59] <PCW> thats odd, /init should go out immediately when programming starts then /done should goe off when programming completes
[14:56:30] <micges> cradek: did you tried to use mesaflash to communicate with board?
[14:56:43] <cradek> nope
[14:57:25] <cradek> this is all insane
[14:57:52] <cradek> rebooting again!
[14:58:02] <cradek> sure wonder what the crash is
[14:59:05] <PCW> EPP can hold the CPU (well ISA state machine) in a wait state but max time should be 10 usec
[14:59:36] <cradek> DONE definitely turns off first
[15:00:11] <cradek> last message on the console: hm2_7i43: loading HostMot2 Mesa 7i43 driver version 0.3
[15:01:50] <cradek> ooh cable #4 has the right genders
[15:02:14] <cradek> some of these might be super duper old scsi cables
[15:03:59] <cradek> cable #4, both lights go out, machine does not hang, this error:
[15:03:59] <cradek> [ 110.547714] hm2/hm2_7i43.0: invalid cookie, got 0xFFFFFFFF, expected 0x55AACAFE
[15:04:03] <cradek> [ 110.547774] hm2/hm2_7i43.0: FPGA failed to initialize, or unexpected firmware?
[15:04:06] <cradek> [ 110.547828] hm2_7i43.0: board at (ioaddr=0xEC00, ioaddr_hi=0xE880, epp_wide ON) not found!
[15:04:28] <skunksleep> I can't believe you don't have zip drive cables :)
[15:04:50] <cradek> was that db25 scsi? some of these might be.
[15:04:56] <PCW> epp issues maybe, flat cables work well if short
[15:05:15] <cradek> there's a flat on the 7i43 but it's female so I can't plug it in directly
[15:06:40] <cradek> halcmd: loadrt hm2_7i43 config=firmware=hm2/7i43-4/SVST4_4.BIT ioaddr=0 epp_wide=0
[15:06:45] <cradek> this LOADED
[15:06:51] <cradek> epp_wide=0 is key
[15:07:46] <cradek> I can turn LEDS on
[15:07:49] <PCW> didnt someone suggest that for the Pluto as well?
[15:07:53] <cradek> yes
[15:08:07] <cradek> so now... known-good cable, known-good non-wide EPP comms
[15:08:29] <cradek> known-good 7i43
[15:08:32] <cradek> whee
[15:08:32] <PCW> well fewer variables...
[15:08:36] <cradek> a lot fewer
[15:08:53] <cradek> this cable is the one with my name carefully written on both ends
[15:09:06] <cradek> some time in the past I've felt very possessive about it
[15:09:23] <PCW> jeeez, even Ethernet is easier
[15:09:43] <cradek> 5 s32 RO 227367 hm2_7i43.0.read.time
[15:09:43] <cradek> 5 s32 RW 269676 hm2_7i43.0.read.tmax
[15:09:52] <cradek> aren't those huuuuge times?
[15:09:58] <PCW> ping rarely crashes the computer
[15:10:22] <PCW> yes pretty big
[15:10:34] <cradek> 5 s32 RO 146772 hm2_7i43.0.write.time
[15:10:35] <cradek> 5 s32 RW 206082 hm2_7i43.0.write.tmax
[15:10:44] <PCW> unless you have a 10 GHz cpu
[15:10:47] <cradek> 5 s32 RO 18828 hm2_7i43.0.pet_watchdog.time
[15:10:48] <cradek> 5 s32 RW 31023 hm2_7i43.0.pet_watchdog.tmax
[15:10:51] <cradek> 1.8 GHz
[15:11:10] <cradek> ok, going to try pluto again
[15:12:07] <cradek> minor gender problems, no big deal
[15:13:33] <cradek> Failed to communicate with pluto-servo board after programming firmware.
[15:13:43] <cradek> nope nope
[15:13:45] <cradek> sigh
[15:39:26] <jepler> cradek: did you put back the forever-missing double-read in pluto_clear_error_register?
[15:40:51] <cradek> yes
[15:43:01] <cradek> I can't find any other important differences between the pluto and hm2 epp code
[15:44:17] <cradek> - outb(0x80, ioaddr_hi + 0x2); // select EPP mode in ECR
[15:44:18] <cradek> + outb(0x94, ioaddr_hi + 0x2); // select EPP mode in ECR
[15:44:23] <cradek> I tried this too
[15:45:34] <jepler> well that leaves us with there being a real problem in the pluto fpga firmware
[15:45:54] <cradek> or possibly still another hardware problem
[15:46:33] <cradek> on the pluto itself, I mean
[15:46:35] <jepler> tinkerer sent you an alternate firmware file, are your latest tests with it?
[15:46:58] <cradek> I think he just sent me led-blink which was to test the programming
[15:47:14] <cradek> but I think the programming works fine, because of the led reliably going out now
[16:01:49] <jepler> tinkerer's firmware added extra registers in the FPGA for the address and data strobes. his tarball from 2013 in private mail includes updated bitfiles (rbf). I put a copy here
http://emergent.unpythonic.net/files/sandbox/pluto_new.tgz
[16:02:31] <jepler> though unfortunately he seems only to have modified pluto_step_firmware
[16:03:03] <cradek> src/hal/drivers/pluto_servo_firmware/pluto_servo.rbf
[16:03:04] <cradek> src/hal/drivers/pluto_servo_firmware/pluto_servo_opendrain.rbf
[16:03:04] <cradek> src/hal/drivers/pluto_servo_firmware/pluto_servo_orig_broken.rbf
[16:03:04] <cradek> src/hal/drivers/pluto_servo_firmware/pluto_servo_rbf.working
[16:04:30] <jepler> confusing. the -rwx------ 1 jepler jepler 19895 Oct 27 2013 pluto_stepper.rbf
[16:04:40] <jepler> I think this is the one you would want to try, to see if epp communication works
[16:04:59] <cradek> ok
[16:05:49] <jepler> this is also interesting
[16:05:49] <jepler> src/hal/drivers/pluto_servo_firmware/pluto_servo.rbf | Bin 19897 -> 19895 bytes
[16:05:58] <jepler> #define FIRMWARE_SIZE 19895
[16:06:16] <jepler> I wonder how important those last two bytes are
[16:08:56] <jepler> aka I wonder whether the fpga knows if it got a good bitstream
[16:11:06] <cradek> [ 4160.627254] Failed to communicate with pluto-servo board after programming firmware.
[16:11:23] <cradek> using pluto_servo.rbf from _new does not help this
[16:11:40] <jepler> try with pluto_stepper.rbf
[16:11:51] <jepler> bsaed on the diffs he only modified the stepper firmware
[16:12:06] <jepler> and even then, put it under a different name
[16:12:10] <jepler> pluto_stepper.rbf, not pluto_step.rbf.
[16:13:24] <jepler> though he must have rebuilt pluto_servo, the evidence seems to indicate it probably does not have modifications to the EPP protocol handling
[16:13:31] <cradek> ok
[16:13:46] <cradek> I renamed his _stepper.rbf to _step.rbf and rebuilt
[16:13:48] <cradek> let's see
[16:14:58] <cradek> [ 4382.477245] Failed to communicate with pluto-servo board after programming firmware.
[16:15:01] <cradek> nope
[16:15:11] <cradek> (it must always say -servo in this error)
[16:15:18] <jepler> yes, apparently
[16:15:39] <jepler> so what you did was untar that thing, then copy just the one rbf file into your source tree in the right spot with the right name?
[16:15:44] <cradek> yes
[16:16:00] <jepler> and you reset the pluto etc
[16:16:01] <cradek> and I saw the build ran rbf2h
[16:16:09] <cradek> I'm going to power off for good measure
[16:19:19] <cradek> Failed to communicate with pluto-servo board after programming firmware.
[16:21:42] <jepler> sigh
[16:21:49] <cradek> fixing the SIZE define doesn't help
[16:25:02] <jepler> I don't seem to have an e-mail that really explains what the change is about. I wonder if there was discussion on irc or something
[16:25:09] <jepler> oblique references to an "open collector problem"
[16:25:12] <jepler> in my mail
[16:25:32] <jepler> which .. seems relevant to what has been going on with you
[17:50:28] <andypugh> I just noticed that the INI-config documentation does not mention the [PYTHON] section referred to here:
http://www.linuxcnc.org/docs/html/remap/structure.html#_upgrading_an_existing_configuration_for_remapping
[22:11:16] <mozmck> seb_kuzminsky: you around? The Integrator Manual for 2.7 has HALTCL Files as chapter 7 under Configuration, but all the other HAL reference is in chapter 10
[22:13:32] <mozmck> HALTCL does not seem to be mentioned in the HAL Manual either
[22:13:57] <mozmck> This is the PDF docs
[22:44:41] <cradek> http://timeguy.com/cradek-files/emc/edgelit-nine.jpg
[22:45:48] <cradek> attempting to make some of the old style of displays that shine a light into the edge of stacked pieces of glass
[22:46:06] <cradek> it's an 11 year old project
[22:46:15] <cradek> in 2004 I tried to use plastic - it doesn't work very well
[22:46:34] <cradek> lately I've discovered you can machine glass without too much trouble
[23:01:11] <skunksleep> zlog
[23:35:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 ebc9eb6 06linuxcnc 10docs/src/gcode/gcode.txt docs: fix a minor formatting mistake in the gcode docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ebc9eb6
[23:36:32] <seb_kuzminsky> that looks great, cradek
[23:37:41] <seb_kuzminsky> although something's wrong, that's clearly a 6
[23:38:19] <cradek> I see what you mean
[23:39:40] <seb_kuzminsky> mozmck: yes, i see that you're right
[23:39:44] <seb_kuzminsky> 2.6 has the same problem
[23:39:51] <cradek> which?
[23:40:07] <cradek> oh I see
[23:40:15] <seb_kuzminsky> haltcl docs are not well integrated into either the Integrator manual or the HAL manual
[23:40:18] <seb_kuzminsky> yeah
[23:47:22] <seb_kuzminsky> i bet it's not the only inconsistency in our docs layout
[23:47:38] <seb_kuzminsky> i set out to clean it up a bit for 2.7, but ran out of steam after the Getting Started guide
[23:47:54] <seb_kuzminsky> maybe we can do one section per release...
[23:48:36] <seb_kuzminsky> Oh, also i should evaluate the po4a experiment that francis and i did last year and see if we should propose switching our docs-translations to that
[23:51:47] <seb_kuzminsky> here's mozmck's thing:
https://sourceforge.net/p/emc/feature-requests/132/
[23:53:36] <seb_kuzminsky> and here's andypugh's thing:
https://sourceforge.net/p/emc/feature-requests/133/
[23:53:50] <seb_kuzminsky> i'm off to make deviled eggs for tomorrow's potluck, good night folks
