| 08:45 | jnettlet | rabeeh, so Android 4.4 is aimed at devices with 512MB of RAM. Is Freescale's Android build env available through their dev site? |
| 09:02 | DHowett | So - does the cubox pro have the oomph to manage software RAID? |
| 09:02 | DHowett | Considering a hw raid enclosure - esata to the cubox - but I'd like fine-grained control that only putting the cubox in control of RAID would get me |
| 09:03 | DHowett | I can't imagine it's CPU-bound, really. |
| 09:03 | jnettlet | dhowett considering I used to run NAS boxes using software raid on PentiumII 300mhz's...I think it will be fine. |
| 09:04 | DHowett | fair point ;P |
| 09:05 | DHowett | I suppose the core worry then becomes - i imagine a hardware RAID solution would remain unconstrained by eSATA for interface speeds |
| 09:06 | DHowett | like, we'd take a performance hit on doing swraid over a materially slower link - though I can't imaging butting up against the limits of the interface in any manner |
| 09:06 | DHowett | jnettlet: (sorry; if you didn't want to be bombarded, i'm somewhat just speaking to the ether :P) |
| 09:06 | jnettlet | You speed constraint is going to be your Gigabit Ethernet |
| 09:06 | jnettlet | s/You/Your/ |
| 09:06 | DHowett | ah, fair point again ;) |
| 09:09 | DHowett | thanks! |
| 09:13 | jnettlet | good luck. |
| 11:45 | taz_ | hello |
| 11:45 | taz_ | I boot from the usb key my cubox, to install a new system, and instead of see the insatller, I'm in front of "Bootstrap 2.33" |
| 11:46 | taz_ | do you know how must I do ? |
| 11:46 | taz_ | please :) |
| 13:48 | rabeeh | jnettlet: we don't have android 4.4 |
| 13:49 | rabeeh | we have android 4.2.2; moving to android 4.3 |
| 13:49 | jnettlet | rabeeh, yeah but if there are 4.2.2 sources it should be relatively easy to port those to 4.4 |
| 13:49 | rabeeh | the basic stuff yes |
| 13:49 | rabeeh | the difficulties typically comes in the codecs side |
| 13:50 | jnettlet | yep |
| 15:47 | unununium_ | Hello everybody! :) |
| 16:08 | rabeeh | hi ununuium_ |
| 16:56 | _rmk_ | right, that's much of my rework for imx-drm sensibly committed at last |
| 16:56 | _rmk_ | the men in white coats will be pleased |
| 17:06 | _rmk_ | 12 files changed, 620 insertions(+), 850 deletions(-) |
| 17:06 | _rmk_ | net 230 lines removed :) |
| 17:22 | jnettlet | \0/ |
| 17:28 | _rmk_ | oops, it just lost 15 more lines, just like that. :) |
| 17:30 | _rmk_ | still need to sort out the fundamentally broken imx_drm_encoder_get_mux_id() |
| 17:31 | _rmk_ | its less of a problem now that we build things up in a consistent way every time. |
| 17:31 | _rmk_ | but it still needs fixing. |
| 17:32 | _rmk_ | it works on imx6s/dl because we only have one ipu and the two halves of the ipu get proved in a predictable order (predictable given the current driver model behaviour) |
| 17:32 | _rmk_ | with the dual/quad though... |
| 17:37 | _rmk_ | I'm not that worried about it at the moment because its no worse than the driver was before I touched it... |
| 19:13 | rabeeh | taz_: ping |
| 19:14 | taz_ | yes rabeeh |
| 19:14 | taz_ | hello rabeeh |
| 19:14 | rabeeh | hi |
| 19:14 | rabeeh | i'v seen your previous posts about issues on CuBox |
| 19:14 | taz_ | ok |
| 19:14 | rabeeh | did you try another USB stick? |
| 19:14 | taz_ | yes |
| 19:14 | taz_ | same issue :x |
| 19:15 | rabeeh | SanDisk typically works ok |
| 19:15 | rabeeh | u-boot is very picky on the type of USB stick |
| 19:15 | taz_ | ha |
| 19:15 | taz_ | SanDisk is a compagny of usb cable ? |
| 19:16 | rabeeh | usb thumb drive |
| 19:16 | taz_ | rabeeh: here is my story : http://www.solid-run.com/phpbb/viewtopic.php?f=7&t=1566 |
| 19:17 | rabeeh | what happens after transfer is complete? |
| 19:17 | taz_ | rabeeh: i don't think my problem is related to usb drive, but : the xmodem upload of u-boot fail |
| 19:17 | rabeeh | do you see the u-boot prompt? |
| 19:17 | rabeeh | typically this happens because of bad quiality of micro usb cable |
| 19:17 | taz_ | i never see u-boot prompt and the transfert is not complete, the transfert fail in fact |
| 19:18 | rabeeh | i'v seen this alot; and when changing to a 'thicker' usb cable things behave |
| 19:18 | rabeeh | thicker cable sometimes means more reliable; more shielded |
| 19:19 | rabeeh | i don't know the root cause; but it helps |
| 19:20 | taz_ | ok i'll try all my micro usb cable |
| 19:20 | rabeeh | if you have a thicker one that would be helpful |
| 19:20 | rabeeh | i think it might be that the shield is simply not there on the thinner cables |
| 19:21 | rabeeh | if xmodem is transferred ok; the first validation would be seeing the red light on the front of CuBox !!! |
| 19:22 | taz_ | i would like, but the red light never light on :/ |
| 19:23 | rabeeh | ok; so this really means that xmodem has failed |
| 19:27 | taz_ | ok |
| 19:27 | taz_ | I'll try other usb cable |
| 19:34 | taz_ | rabeeh: thanks for the forum |
| 19:35 | taz_ | rabeeh: about the usb cable, when you say "thicker" you speak about the lenght of the tip ? |
| 19:35 | rabeeh | no; the cable itself |
| 19:36 | taz_ | ah ok |
| 19:37 | taz_ | rabeeh: but when I plug radom cable, I see in "dmesg" that /dev/ttyUSB0 was created, so is the thicker important ? |
| 19:37 | taz_ | random* |
| 19:42 | rabeeh | taz_: i don't know; but it helps |
| 19:42 | rabeeh | i know it's a bit weird since USB URB (packets) have CRC and reptition etc... |
| 19:42 | rabeeh | but i don't know how the USB to RS232 is implemented in failures point of view |
| 19:44 | taz__ | rabeeh: back |
| 19:44 | taz__ | rabeeh: I try with anoter cable : same issue as this morning : check it please http://pastebin.com/MSymPcwf |
| 19:47 | taz__ | rabeeh: and at the same time I have this in minicom : http://imageshack.us/content_round.php?page=done&l=img577/7985/w38s.png&sa=0 |
| 20:10 | taz__ | rabeeh: i'm here ;) |
| 20:10 | rabeeh | taz__: oh |
| 20:10 | rabeeh | please pastebin the script you are using |
| 20:10 | rabeeh | btw - are you pressing the tiny button beneath the rj45 connector on the back? |
| 20:11 | taz__ | yes for the button :) |
| 20:11 | taz__ | ok |
| 20:11 | rabeeh | before inserting the DC-jack; right ? |
| 20:11 | taz__ | http://pastebin.com/MsSx5J4Y |
| 20:11 | taz__ | yes before |
| 20:12 | rabeeh | and are you using native Linux or VM? |
| 20:13 | taz__ | native linux debian stable |
| 20:14 | rabeeh | taz__: do you feel a bit of coding? |
| 20:14 | rabeeh | i have scripts on the side that were never published that can reset, software wise click the button and release the boot sequence |
| 20:14 | rabeeh | we use it as fully automated for manufacturing (i.e. we don't really press the button on every newly system for burning u-boot) |
| 20:16 | taz__ | ho rabeeh you work in the solid run society? |
| 20:17 | taz__ | just would like to say that cubox product rox :) |
| 20:19 | rabeeh | taz__: yes. i work for the company :) |
| 20:19 | rabeeh | thanks for the complements |
| 20:20 | taz__ | h�h� :) |
| 20:22 | taz__ | rabeeh: your not published script works with usb cable ? |
| 20:33 | rabeeh | no |
| 20:33 | rabeeh | it's a script that you run on your linux pc that controls cubox reset, boot select (button) |
| 20:34 | taz__ | ok but it control cubox with wich device ? |
| 20:35 | rabeeh | it controls cubox over the micro usb cable |
| 20:35 | rabeeh | the same usb to serial cable |
| 20:35 | taz__ | ok ok |
| 20:35 | taz__ | :) |
| 20:35 | rabeeh | it uses some gpio pins of the ftdi usb to serial controller |
| 20:36 | taz__ | can i try this script please ? |
| 20:36 | rabeeh | interested? |
| 20:36 | taz__ | ho yes sure!! (: |
| 20:36 | rabeeh | please send me your email to [email protected] |
| 20:36 | rabeeh | i'll prepare a small package |
| 20:37 | taz__ | with plesure :) |
| 20:38 | taz__ | rabeeh: mail sent |
| 20:43 | rabeeh | got your email. i'm rewriting the script a bit so it won't be confusing |
| 20:44 | taz__ | ok thanks a lot :) |
| 20:51 | rabeeh | got your email. i'm rewriting the script a bit so it won't be confusing |
| 20:51 | rabeeh | ok. just sent you an email; please compile first the ftdi-bitbang-read/write |
| 20:51 | rabeeh | you need to have the community libftdi installed |
| 20:52 | taz__ | ok recieved, I try to copile |
| 20:53 | taz__ | rabeeh: to compile I need "ftdi.h" gcc says |
| 20:53 | taz__ | do you have this file or is a standard lib ? |
| 20:53 | rabeeh | dpkg-query -S /usr/lib/x86_64-linux-gnu/libftdi.so |
| 20:53 | rabeeh | libftdi-dev: /usr/lib/x86_64-linux-gnu/libftdi.so |
| 20:53 | taz__ | maybe |
| 20:53 | taz__ | ok :) |
| 20:54 | rabeeh | you need to install libftdi-dev |
| 20:54 | rabeeh | taz__: if this works; can you please create a github project with those? |
| 20:54 | taz__ | rabeeh: with plesure :) |
| 20:54 | taz__ | rabeeh: compile fail :x |
| 20:55 | rabeeh | pastebin please |
| 20:55 | taz__ | http://pastebin.com/LpFpkc1Z |
| 20:56 | rabeeh | please add '-lftdi' at the end of the compile command |
| 20:56 | rabeeh | look at README.txt |
| 20:56 | taz__ | ok sorry |
| 20:56 | taz__ | I look.. |
| 20:56 | taz__ | compil ok! |
| 20:57 | taz__ | ./ftdi-bitbang-read |
| 20:57 | taz__ | EB |
| 20:58 | taz__ | without power plugin in cubox |
| 20:58 | rabeeh | ok. |
| 20:58 | taz__ | is e good news? |
| 20:58 | taz__ | is a * |
| 20:58 | rabeeh | now just try 'sudo ./power_status.sh' |
| 20:58 | taz__ | ok |
| 20:58 | rabeeh | it should poll until power is enabled |
| 20:59 | taz__ | ot@laptop:/home/gui/control-cubox# ./power_status.sh |
| 20:59 | taz__ | Putting CuBox in reset state |
| 20:59 | taz__ | Boot select from RS-232 (i.e. micro USB cable) |
| 20:59 | taz__ | Releasing reset |
| 20:59 | taz__ | Start your xmodem transfer |
| 20:59 | taz__ | root@laptop:/home/gui/control-cubox# |
| 20:59 | taz__ | is it ok ? |
| 20:59 | rabeeh | hmm... |
| 21:00 | rabeeh | not good |
| 21:00 | taz__ | :x |
| 21:00 | taz__ | there is no power |
| 21:00 | taz__ | is ok with no power? |
| 21:00 | rabeeh | no |
| 21:00 | taz__ | must I plug the power? |
| 21:00 | rabeeh | it means it didn't detect the ftdi chip correctly |
| 21:00 | rabeeh | no; hold on |
| 21:00 | taz__ | ok |
| 21:01 | rabeeh | what does the following show - |
| 21:01 | rabeeh | lsmod | grep ftdi |
| 21:01 | taz__ | lsmod | grep ftdi |
| 21:01 | taz__ | ftdi_sio 38270 1 |
| 21:01 | taz__ | usbserial 32061 3 ftdi_sio |
| 21:01 | taz__ | usbcore 128741 7 ehci_hcd,xhci_hcd,uvcvideo,ftdi_sio,usb_storage,usbserial |
| 21:01 | rabeeh | oh; |
| 21:01 | rabeeh | is your putty / minicom or whatever open? |
| 21:01 | taz__ | yes |
| 21:02 | rabeeh | please close first :) |
| 21:02 | taz__ | ho sorry i close it now, I didn't know :( |
| 21:02 | rabeeh | the rmmod probably has failed because the module is being used by putty |
| 21:02 | taz__ | root@laptop:/home/gui/control-cubox# ./power_status.sh |
| 21:02 | taz__ | Putting CuBox in reset state |
| 21:02 | taz__ | Boot select from RS-232 (i.e. micro USB cable) |
| 21:02 | taz__ | Releasing reset |
| 21:02 | taz__ | Start your xmodem transfer |
| 21:02 | taz__ | root@laptop:/home/gui/control-cubox# |
| 21:03 | taz__ | I plug out usb then plugin and : |
| 21:03 | taz__ | root@laptop:/home/gui/control-cubox# ./ftdi-bitbang-read |
| 21:03 | taz__ | FF |
| 21:03 | taz__ | root@laptop:/home/gui/control-cubox# ./power_status.sh |
| 21:03 | taz__ | Power is UP |
| 21:03 | taz__ | Putting CuBox in reset state |
| 21:03 | taz__ | Boot select from RS-232 (i.e. micro USB cable) |
| 21:04 | taz__ | Releasing reset |
| 21:04 | taz__ | Start your xmodem transfer |
| 21:04 | taz__ | root@laptop:/home/gui/control-cubox# |
| 21:04 | rabeeh | yippe |
| 21:04 | rabeeh | now please try manually your sx command |
| 21:04 | rabeeh | i.e. - |
| 21:04 | rabeeh | sx u-boot-cubox_hynix_cubox_1GB_uart.bin < /dev/ttyUSB0 > /dev/ttyUSB0 |
| 21:05 | taz__ | ok sx runs... |
| 21:05 | taz__ | now I plug ? |
| 21:05 | taz__ | the power* |
| 21:05 | taz__ | ho sx fail (maybe timeout ?) |
| 21:06 | rabeeh | wasn't it already powered? |
| 21:06 | rabeeh | ok. let me send you an update |
| 21:06 | taz__ | rabeeh: I never plug the power yet |
| 21:06 | rabeeh | ok. |
| 21:06 | rabeeh | must be a bug somewhere |
| 21:07 | rabeeh | i'v sent you a newer tarball; please run sudo ./power_status.sh |
| 21:07 | taz__ | must I try to launch sx and quickly plug the power? |
| 21:07 | rabeeh | no no |
| 21:08 | taz__ | ok |
| 21:08 | rabeeh | the ./power_status.sh script will wait until you plug in the DC-jack |
| 21:08 | taz__ | ok i launch power_status.sh |
| 21:08 | taz__ | hum the script relase the shell |
| 21:09 | taz__ | ho |
| 21:09 | taz__ | new mail |
| 21:09 | taz__ | :) |
| 21:10 | taz__ | ok new mail, tgz downloaded, uncompress, gcc done, |
| 21:10 | taz__ | now i launch the reader? |
| 21:11 | rabeeh | just the script |
| 21:11 | rabeeh | sudo ./power_status.sh |
| 21:11 | taz__ | ok |
| 21:11 | taz__ | hum :( |
| 21:11 | taz__ | root@laptop:/home/gui/v2/control-cubox# ./power_status.sh |
| 21:11 | taz__ | Got unclear state from the FTDI GPIO chip EE |
| 21:11 | taz__ | Putting CuBox in reset state |
| 21:11 | taz__ | Boot select from RS-232 (i.e. micro USB cable) |
| 21:11 | taz__ | Releasing reset |
| 21:12 | taz__ | Start your xmodem transfer |
| 21:12 | taz__ | root@laptop:/home/gui/v2/control-cubox# |
| 21:12 | taz__ | ho fuck |
| 21:12 | taz__ | sorry |
| 21:12 | taz__ | the power was on!!! |
| 21:12 | taz__ | SORRY :( |
| 21:12 | rabeeh | doesn't matter. it's not good anyway |
| 21:12 | taz__ | power is down 'code F6) |
| 21:12 | rabeeh | ok; better :) |
| 21:12 | taz__ | :) |
| 21:13 | rabeeh | code F6 / F4 means power is down |
| 21:13 | taz__ | ok |
| 21:13 | rabeeh | code FE / FC means power is up |
| 21:13 | taz__ | ok |
| 21:13 | taz__ | I had "FF" last time |
| 21:13 | rabeeh | now you have some sort of special code EE which i don't understand where it's coming from |
| 21:13 | taz__ | with reader programm |
| 21:13 | rabeeh | yes |
| 21:14 | taz__ | so the power_status.sh runs.... |
| 21:14 | rabeeh | the power_status.sh is very simple; it first removes the ftdi_sio module so it can gain access to the ftdi gpios |
| 21:14 | taz__ | how must I do please? |
| 21:14 | taz__ | ok |
| 21:15 | rabeeh | ok; please run the following as root - |
| 21:15 | rabeeh | rmmod ftdi_sio |
| 21:15 | rabeeh | echo 00 | ./ftdi-bitbang-write |
| 21:15 | taz__ | i'm in root all the time for cubox manipulation |
| 21:15 | rabeeh | ./ftdi-bitbang-read |
| 21:16 | taz__ | ok but must I cancel the script before? |
| 21:16 | rabeeh | yes. |
| 21:16 | taz__ | ok |
| 21:16 | rabeeh | just cancel the script, remove the power and close putty |
| 21:16 | taz__ | ok |
| 21:16 | taz__ | oot@laptop:/home/gui/v2/control-cubox# echo 00 | ./ftdi-bitbang-write |
| 21:16 | taz__ | starting now |
| 21:16 | taz__ | Enter Hex Value to write: |
| 21:16 | taz__ | 00 |
| 21:16 | taz__ | F6 |
| 21:16 | taz__ | root@laptop:/home/gui/v2/control-cubox# |
| 21:17 | rabeeh | ok. great |
| 21:17 | rabeeh | now please plug in DC jack and run - |
| 21:17 | rabeeh | ./ftdi-bitbang-read |
| 21:17 | taz__ | ./ftdi-bitbang-read |
| 21:17 | taz__ | FE |
| 21:17 | taz__ | (no red light) |
| 21:17 | rabeeh | great |
| 21:17 | taz__ | ok |
| 21:17 | rabeeh | that's ok. |
| 21:18 | taz__ | :) |
| 21:18 | rabeeh | now this means that power detection is working. F6 is no power and FE is powered |
| 21:18 | taz__ | ok |
| 21:18 | rabeeh | :w |
| 21:18 | taz__ | vim user \o/ |
| 21:18 | rabeeh | yes. sorry |
| 21:18 | rabeeh | wrong window; i'm editing the script to make more self checks |
| 21:19 | taz__ | ok |
| 21:19 | rabeeh | now; lets try from the beginning |
| 21:19 | taz__ | i wait for your instruction sir :) |
| 21:19 | rabeeh | power is off; putty is closed and script is cancelled |
| 21:19 | rabeeh | ./power_status.sh |
| 21:19 | rabeeh | it should be telling you again and again 'Power is DOWN (code F6)' |
| 21:20 | taz__ | ./power_status.sh |
| 21:20 | taz__ | Error: Module ftdi_sio is not currently loaded |
| 21:20 | taz__ | Can't remove module. Please close terminal emulation (minicom / putty etc...) and rerun |
| 21:20 | rabeeh | is this what you are getting? |
| 21:20 | taz__ | but ALL is closed... |
| 21:20 | taz__ | can I plug out and in the usb ? |
| 21:20 | rabeeh | oh; ok. my fault this time |
| 21:20 | rabeeh | please run modprobe ftsi_sio |
| 21:21 | rabeeh | i will fix the script |
| 21:21 | taz__ | modprobe ftsi_sio |
| 21:21 | taz__ | FATAL: Module ftsi_sio not found. |
| 21:21 | rabeeh | please run modprobe ftdi_sio |
| 21:21 | rabeeh | sorry. my mistake |
| 21:22 | taz__ | i'm on linux debian with kernel 3.2.0-4-amd64 -> i can install all module you want |
| 21:22 | rabeeh | ok. i mistakenly wrote 'ftsi_sio' instead of 'ftdi_sio' |
| 21:22 | taz__ | modprobe : ok |
| 21:23 | taz__ | opwer status script : power is down (code F6) |
| 21:24 | rabeeh | ok. |
| 21:24 | rabeeh | now plug in DC-jack |
| 21:24 | taz__ | (the scrpipt is still running...) |
| 21:24 | rabeeh | great |
| 21:24 | taz__ | ok |
| 21:24 | taz__ | Power is DOWN (code F6) |
| 21:24 | taz__ | Power is DOWN (code F6) |
| 21:24 | taz__ | Got unclear state from the FTDI GPIO chip F7 |
| 21:24 | taz__ | Putting CuBox in reset state |
| 21:24 | taz__ | Boot select from RS-232 (i.e. micro USB cable) |
| 21:24 | taz__ | Releasing reset |
| 21:24 | taz__ | Start your xmodem transfer |
| 21:25 | taz__ | root@laptop:/home/gui/v2/control-cubox# |
| 21:25 | rabeeh | ok. i don't know now why you are getting F7 |
| 21:25 | taz__ | :( |
| 21:25 | rabeeh | but regardless; can you please try now 'sx ...'? |
| 21:26 | taz__ | ok |
| 21:26 | taz__ | root@laptop:/home/gui/v2/control-cubox# sx /home/gui/cubox/u-boot-cubox_hynix_cubox_1GB_uart.bin < /dev/ttyUSB0 > /dev/ttyUSB0 |
| 21:26 | taz__ | Sending /home/gui/cubox/u-boot-cubox_hynix_cubox_1GB_uart.bin, 0 blocks: Give your local XMODEM receive command now. |
| 21:26 | taz__ | Retry 0: No ACK on EOT |
| 21:26 | taz__ | Transfer incomplete |
| 21:26 | taz__ | root@laptop:/home/gui/v2/control-cubox# |
| 21:27 | taz__ | (i have NO micro sd card in the cubox : is a problem ?) |
| 21:27 | taz__ | i have just power and usb, just it. |
| 21:31 | taz__ | rabeeh: I have 2 cubox in this state :( |
| 21:31 | rabeeh | are those cubox or cubox pro? |
| 21:33 | rabeeh | taz__? |
| 21:33 | taz__ | cubox standard v2 |
| 21:34 | taz__ | how can I really check it ? |
| 21:34 | taz__ | verify it* |
| 21:35 | rabeeh | does it CB-300-D or CBP-300-D on the bottom? |
| 21:35 | rabeeh | CBP is the pro |
| 21:35 | taz__ | there is no stikers |
| 21:35 | taz__ | do you have a picture showing it ? |
| 21:37 | rabeeh | ? |
| 21:37 | rabeeh | how old is your device? |
| 21:37 | rabeeh | when did you buy it? |
| 21:38 | taz__ | hum 2 years approx |
| 21:38 | rabeeh | oh; |
| 21:38 | rabeeh | is your micro USB connector beneath the esata connector? |
| 21:38 | rabeeh | or on the side beneath the SPDIF? |
| 21:39 | taz__ | like this http://i.pcworld.fr/1278455-solidrun-cubox-pro-1.jpg |
| 21:40 | rabeeh | ok. |
| 21:40 | rabeeh | it's an ES v2 then |
| 21:41 | rabeeh | taz__: have a small call |
| 21:41 | rabeeh | will be back in 15m |
| 21:41 | taz__ | ok |
| 22:06 | taz__ | rabeeh: I look about my purshase : for information it was in juily 2012 |
| 23:20 | rabeeh | taz__: sorry for disappering |
| 23:20 | rabeeh | are you still online? |
| 23:21 | taz__ | yes |
| 23:21 | taz__ | :) |
| 23:21 | rabeeh | ok. |
| 23:21 | taz__ | no prob |
| 23:21 | rabeeh | so i'v tried reproducing this F7 case; but i can't |
| 23:21 | rabeeh | it's working for me all the time; |
| 23:21 | taz__ | ah :x |
| 23:22 | taz__ | ok |
| 23:22 | rabeeh | i was wondering if you have different Linux machine around? |
| 23:22 | taz__ | i have openbsd machine |
| 23:22 | taz__ | in the other room |
| 23:22 | rabeeh | maybe you can try the 'sx' or equivalent command there? |
| 23:22 | rabeeh | i simply can't get it not to work |
| 23:23 | taz__ | ok I take my laptop debian with me |
| 23:23 | taz__ | so we can talk too |
| 23:23 | rabeeh | but first you need to figure out what is the 'sx' equivalent in bsd |
| 23:23 | rabeeh | it might be the same command though |
| 23:24 | taz__ | my machine is booting |
| 23:24 | taz__ | i'll see |
| 23:24 | rabeeh | i think you can for now forget about the scripts; they are not helping a lot |
| 23:24 | rabeeh | you can simply do what you have previously done - |
| 23:24 | rabeeh | 1. power off |
| 23:24 | rabeeh | 2. click on boot select button |
| 23:24 | rabeeh | 3. power on |
| 23:24 | rabeeh | 4. sx command to send file |
| 23:25 | taz__ | ok |
| 23:25 | rabeeh | btw - is it a desktop bsd? |
| 23:26 | taz__ | yes openbsd with xfce |
| 23:27 | taz__ | which package give "sx" in debian please? |
| 23:29 | taz__ | ah lrzsz ! |
| 23:30 | taz__ | yes this is packaged on openbsd :) |
| 23:31 | rabeeh | same as linux |
| 23:36 | taz__ | hum it don't give the sx command :/ i don't understand how it's works on openbsd |
| 23:36 | taz__ | i google... |
| 23:42 | taz__ | i don't find. So I boot an usb live usb key xubuntu on my openbsd pc |
| 23:47 | taz__ | hum, back! sorry wifi prob |
| 23:48 | unununium_ | Your weren't gone... |
| 23:49 | taz__ | ok |
| 23:53 | taz__ | rabeeh: ok try on another pc with xubuntu : sx -vv ..etc.... -> print nothing : not say timeout, but no say fail, no say complete...nothing.. |
| 23:54 | rabeeh | is /dev/ttyUSB0 there? |
| 23:54 | taz__ | yes |
| 23:54 | taz__ | in dmesg I see it |
| 23:56 | taz__ | ho its me |
| 23:56 | taz__ | in fact he says : retry 0 : no ACK on EOT |
| 23:56 | taz__ | transfert incomplete |
| 23:56 | taz__ | voil� |
| 23:56 | rabeeh | so the same |
| 23:57 | taz__ | yes |
| 23:57 | rabeeh | let's do it a bit different now |
| 23:57 | taz__ | ok |
| 23:57 | rabeeh | i just want to check that hardware flow control is disabled on /dev/ttyUSB0 |
| 23:58 | taz__ | ok how ? |