00:22 | shesselba_ | _rmk_: ping |
00:22 | _rmk_ | umm? |
00:23 | shesselba_ | With 3.7.0 I have a division by zero warning related to sdhci |
00:24 | shesselba_ | http://pastebin.com/hh2eqpZu |
00:24 | shesselba_ | any idea where to look at? |
00:30 | cbxbiker61 | shesselba_, the problem should be in add_partition |
00:31 | shesselba_ | cbxbiker61: I know.. but there is no (obvious) division |
00:31 | cbxbiker61 | ok |
00:32 | cbxbiker61 | did you build the kernel yourself? |
00:32 | shesselba_ | sure |
00:33 | cbxbiker61 | if so, you could use objdump disasseble of the object file that contains add_partition |
00:33 | cbxbiker61 | then you can find the line correlating to offset 0xd4 |
00:34 | shesselba_ | yeah, but I checked block/partition-generic.c.. it hasn't been changed since Aug. And the warning wasn't there with short before 3.7 |
00:34 | shesselba_ | and I know there has been a lot bug fixing within dove-sdhci _and_ mmc lately |
00:35 | cbxbiker61 | is it using any macros defined in headers? those may have changed |
00:37 | cbxbiker61 | i'm working on my first project where I can take advantage of c++11, c++11 new features are great. |
00:37 | shesselba_ | there is a reference to __do_div64 at add_partition 0x2b8 |
00:38 | cbxbiker61 | that's probably it, now to figure out where the parameters came from |
00:45 | shesselba_ | my guess is either queue_limit_alignment_offset or queue_limit_discard_alignment |
00:49 | shesselba_ | hmm, commit 8dd2cb7e880d2f77fba53b523c99133ad5054cfd |
00:49 | shesselba_ | block: discard granularity might not be power of 2 |
00:50 | shesselba_ | introduces sector_div to queue_limit_discard_alignment |
00:50 | _rmk_ | that commit doesn't seem to be in mainline |
00:51 | shesselba_ | pre 3.7-rc1 ? |
00:51 | _rmk_ | as of yesterdays tree, that commit ID doesn't seem to exist in mainline |
00:51 | _rmk_ | fatal: bad object 8dd2cb7e880d2f77fba53b523c99133ad5054cfd |
00:53 | shesselba_ | I found a discussion about it, looks like it was pulled about 8hrs ago |
00:53 | _rmk_ | ah, in that case it won't be in my tree yet |
00:54 | shesselba_ | is there a way to revert just that single commit? |
00:54 | _rmk_ | git revert will create a new commit in your tree reverting the specified id |
00:57 | shesselba_ | yep, reverting the commit fixes the div_by_zero warning |
00:58 | _rmk_ | ok |
00:59 | shesselba_ | now, is the related patch buggy or is the lim->discard_granularity wrong? |
01:00 | _rmk_ | I'll tell you soon, I'm just overloading one of my old arm boxes with git activity :) |
01:00 | shesselba_ | hehe |
01:01 | _rmk_ | I'd say it shouldn't be zero |
01:02 | shesselba_ | I have no idea what is about anyway ;) |
01:03 | _rmk_ | well, Jens might be around... |
01:04 | _rmk_ | so I'm just dumping a few lines into the channel he's on (even if he isn't around at the moment, he may eventually see it and reply over night) |
01:04 | shesselba_ | armlinux? |
01:05 | _rmk_ | nope |
01:06 | _rmk_ | don't ask too many questions about it either :) |
01:06 | shesselba_ | I won't ;) thanks for taking over |
02:15 | Coburn | [09:41:03] < rabeeh> [04:57:58] they claim - Hi10P won't work on ARM or even Intel ATOM processors (maybe one day, but none of the current ones in 2012 would do it) |
02:15 | Coburn | I've got some japanese shows that are Hi10P. |
02:16 | Coburn | Well, they are MKVs with AAC audio + H264 video |
03:23 | dung | 03:23 * dung_ noticed that U_Boots bubt is a Marvell extension |
03:43 | dung | Some questions about the audio upgrade: a) the change in kernel is renaming S/PDIF to SPDIF, which suits the ALSA config? b) AC-3 / DTS passthrough (and a decoding reciever) is the way to play HD video/audio on CuBox? c) pass-through HDMI always worked? |
03:50 | dung | On my side, a DAC for stereo audio would suit the CuBox :) |
03:54 | dung | Of course for video it's a big win to analog-digital-analog converting, but.. how much does it cost to do DAC audio? In the end it has to be done somewhere, and I think I found out that this is not an open standard. Please correct me! Until then this is an important part of high quality audio, which I believe is never met with compressed "passthrough". |
03:55 | dung | *to not have to a-d-a |
04:04 | dung | more than 2 audio channels are addon to video ;) |
04:05 | dung | and surrounded people are impressed by the effects :) |
04:13 | dung | Does an open source DAC audio codec exists? |
04:17 | dung | *fk* audio DAC codec exist? |
04:17 | dung | *fk* *s~ |
04:18 | dung | *f*k* :) |
04:19 | Coburn | dung: a) SPDIF is what ALSA says, so I guess so |
04:20 | Coburn | dung: b) Not sure, not a guru with AC-3 stuff |
04:20 | Coburn | dung: c) What do you meant about HDMI pass-thru? |
04:21 | dung | that's the video magic on cubox: hdmi passthru |
04:22 | Coburn | HDMI Video or Audio Passthrough? |
04:22 | dung | i don't know if it was always possible, but didn't know that stuff |
04:22 | dung | s/but/or |
04:23 | Coburn | XBMC allows you to do HDMI AC3/DTS passthrough, which means it would mean the HDMI receiver would need to be able to decode it |
04:25 | dung | ..the pass through makes it possible to play 8 channels on CuBox, which is only of interest in combination with video. the upgrade eddects SPDIF, not HDMI ? |
04:26 | dung | *effects |
04:27 | dung | in short: then the upgrade is the ALSA config |
04:27 | dung | ? |
04:29 | dung | now the kernel driver supports ALSA naming conventions? |
04:30 | dung | well.. just from my fantasy - haven't looked into details |
04:32 | dung | but i'm guessing for weeks since I nearly understand what has been done :) |
04:35 | dun | 04:35 * dung murmled to himself after he saw the bad grammer |
04:41 | dung | *wrong |
04:41 | dung | it's all right :) |
04:42 | dun | 04:42 * dung keeps cool |
04:42 | dung | it's running faster |
04:43 | dung | after leaving out.. security? |
04:45 | dung | i did, but should we have to take care about security in case of a graphics driver/library? |
04:47 | dung | from my point of view it's a bit of fantastic - the frame buffer! |
04:47 | dung | it always was an now it's part of ARM graphics |
04:47 | dung | strange |
04:49 | dung | don't forget KMS |
04:49 | dung | oh; Direct Rendering |
04:57 | dung | for me, CuBox's software design follows a usual way, known from PC, with closed graphcics driver/library. That is in tradition of PCs, consumed by the gaming industry. Marvell GFX ? |
05:02 | dung | I haven't had the nerves to look into how the RPi community does "bootloader > GL > kernel"? Happy birthday CuBox! |
05:13 | dung | earlier I ment.. it always was my interest: a working FB device |
05:25 | dung | Now they are called "SetTop Boxes"? |
05:26 | dung | Let's do it in a way, everybody can follow. |
05:32 | Coburn | Too exotic terms there for my circuitry to handle |
05:32 | Coburn | but something that the R-Pi has is BerryBoot |
05:33 | Coburn | It's a bootloader that allows multiOS on a SD |
05:33 | Coburn | Now, do that on the CuBox and you'd be set |
05:33 | dung | One thing I love with what I've learned with Linux is 'call things by their name' and 'dont't hide a thing' |
05:35 | dung | *anything of course |
05:37 | dung | BerryBoot can start X client over ssh? |
05:37 | dung | no problem, brb.. :) |
05:46 | dung | that was joke :smaller: |
05:48 | dbsx | Multiboot on Cubox is a piece of cake. You can set uboot variables from linux so (for example) you can set with device partition and directory to boot from |
05:49 | dbsx | with=which |
05:50 | dung | - ; an initrd has to be ready for any filesystem, network, and X session |
05:51 | dung | which width? |
05:51 | dung | switch width :) |
05:53 | dung | enough widths |
05:54 | dung | notice the spell of the 'ths' |
06:01 | dun | 06:01 * dung handles dbsx a cookie |
06:01 | dung | ok? |
06:02 | dung | [teatime] |
06:12 | dung | I believe security within bmm/etc is nonsense - please correct |
06:16 | dung | i will not say "please corr.." anymore |
06:27 | dung | but i still i believe it's secureley to trust a |
06:27 | dung | gou driver |
06:30 | dung | re: you can trust GPU driver cause of its limited function? |
06:31 | dung | pooh.. |
06:31 | dung | i'm a new bee :) |
06:37 | dung | what's that exynos thing? |
06:38 | dung | FB bmm should be fast a low level |
06:38 | dung | security? |
06:41 | dung | /dev/mem ? |
06:44 | dung | Ooh.. ;) |
06:45 | dung | not yet :) |
06:56 | dung | after cubox is on rtc is no matter |
06:57 | dung | i'll try to not forget comparison |
06:58 | dung | but that is another clock, what are you talking about? CLK especially? |
06:59 | dung | ..ticks.. |
07:02 | dung | i'm about to understand this, don't answer but.. |
07:03 | dung | Some questions about the audio upgrade: a) the change in kernel is renaming S/PDIF to SPDIF, which suits the ALSA config? b) AC-3 / DTS passthrough (and a decoding reciever) is the way to play HD video/audio on CuBox? c) pass-through HDMI always worked? |
07:18 | dung | no, just tell me about clk |
07:19 | dung | *all about clks |
07:20 | dun | 07:20 * dung hides away |
07:21 | dung | aha; time for i2c |
07:21 | dung | see you at the airport |
07:25 | dung | Oops: 0 pins from human height: usual |
07:40 | dung | no pin found so far :) |
07:41 | dung | oh; jump :) |
07:50 | dung | hi dotarray :) |
08:04 | dung | after killing all instancec i was not allowd to run, i got a blank screen |
08:04 | Coburn | [14:48:49] Multiboot on Cubox is a piece of cake. <- true, not going to argue with that, but check this. Methinks it's pretty slick (I'm currently testing it now) http://www.berryterminal.com/doku.php/berryboot |
08:04 | Coburn | dung: killing what |
08:05 | dung | *instances :) |
08:06 | Coburn | dung: to me, it sounds like you're randomly babbling about stuff |
08:06 | dung | ..of undiscovered things |
08:07 | Coburn | what do you mean by FB bmm ? |
08:07 | dung | Coburn, ? |
08:07 | dung | frame buffer graphics |
08:08 | Coburn | I'm not a linux guru, but I'm guessing if you had *exclusive* access to the hardware |
08:08 | Coburn | then you would have full potiental hardware power |
08:08 | dung | the one CuBox does render 3d graphics |
08:13 | Coburn | Indeed. |
08:13 | Coburn | I wonder if the graphics would be on par with the current day consoles? |
08:14 | Coburn | I mean, can it do Xbox 360 graphics? |
08:14 | Coburn | Offtopic, but openELEC on R-Pi gets ~25FPS at 1080p |
08:16 | Coburn | gj Coburn, I crashed it |
08:16 | Coburn | woot |
08:16 | dung | i've to do some upgrades, e.g. moinjfs console patch, etc |
08:18 | dung | i don't have rmks insites |
08:19 | dung | but i tend to use _rmk_s for my dirver image |
08:19 | Coburn | Wow... |
08:19 | Coburn | GPU glitchorama on the R-Pi |
08:19 | Coburn | O.o |
08:19 | dung | hell, how does it work |
08:20 | Coburn | what does what work? |
08:20 | dung | *who does its .. |
08:22 | dung | strike |
08:22 | dung | realtime |
08:22 | dung | chat with Coburn |
08:23 | Coburn | ... |
08:23 | Coburn | I'm not really following you |
08:23 | Coburn | In fact, I don't have a clue what's going one |
08:23 | Coburn | on* |
08:23 | dung | aha :) |
08:24 | Coburn | oh |
08:24 | Coburn | you mean, what GPU is inside the R-Pi, dung? |
08:24 | Coburn | Or the manufacturer of the GPU? |
08:26 | Coburn | The GPU is a MediaCore IV |
08:26 | Coburn | and the manufacturer is Broadcom |
08:27 | dung | i know the way it's orgonized with CuBox |
08:37 | dung | how! who"s that? |
08:39 | dung | sorry, half asleep.. |
08:45 | dung | - rose wood - hard-to-brick TM |
08:51 | dung | I haven't had enough nerves to look into RPi firmare |
08:53 | dung | it goes from closed library to closed firmware - good luck |
09:01 | dung | I hadn't have enough..? |
09:03 | dung | I don't believe is located in Japan. Hehe, I thought it english :) |
09:04 | dung | I don't believe 'Ilcontegis' is located in Japan |
09:07 | dung | maybe china or taiwan? |
09:09 | dung | gin..? |
11:22 | mongrol | ello? |
11:22 | mongrol | is this the solid-run cubox channel? |
11:24 | rabeeh | mongrol: yes |
11:25 | mongrol | ta |
11:25 | mongrol | I've been reading the forums with a view to replacing my celeron based MythTV backend server with a cubox |
11:26 | mongrol | but there seems to be some posts mentioning unstableness of the cubox |
11:26 | mongrol | my plan is to run Archlinuxarm as it has a mythtv package |
11:26 | mongrol | do you know of anyone running mythtv or perhaps tvheadend |
11:26 | mongrol | ? |
11:27 | mongrol | and what is the state of "stable" of the various distros? |
11:36 | rabeeh | so you need mythtv backend only? (headless) |
11:37 | rabeeh | if that's for recording without transcoding then CuBox can do the job |
11:37 | rabeeh | doing any kind of transcoding (i.e. moving mpeg2 interlaced to h.254 de-interlaced for instance) then you will need a very serious computer (i think even celeron won't be enough) |
11:37 | mongrol | yeah, single sata disk would do it |
11:38 | mongrol | It needs to do some commercial ripping |
11:38 | mongrol | which the celeron breezes through, so there is some transcoding |
11:38 | mongrol | are there any benchmarks available for the chip? |
11:38 | mongrol | I can check my transcode logs and do some extrapolation |
11:55 | rabeeh | is it offline transcoding? or online? |
11:55 | rabeeh | in my mind, realtime transcoding for HD required core i7 processors |
11:56 | rabeeh | there are some benchmarks on the forums; you can take a look |
11:56 | rabeeh | ripping is not transcoding |
11:56 | rabeeh | transcoding you change the codec; which typically means you decode then encode; ripping is extracting data then changing file containers. |
12:04 | mongrol | commercial "tagging" is processing the stream and tagging when commercials start and finish |
12:04 | mongrol | so its not changing codecs |
12:05 | mongrol | can be done during recording or scheduled afterwards |
12:19 | rabeeh | oh; then my guess the CuBox will be able to do that. |
12:20 | mongrol | I think it has the juice, my only fear is stability |
12:20 | rabeeh | stability of what? the hardware / system? |
12:20 | rabeeh | or software? |
12:21 | mongrol | both I suppose |
12:21 | rabeeh | the hardware is very stable; there are few boxes on the net that has been online for months |
12:21 | mongrol | righty, good enough for me |
12:22 | rabeeh | the software is pretty stable too; but is getting patched more and more |
12:22 | mongrol | whats the status of GPU acceleration on linux? |
12:22 | rabeeh | for instance the kernel is being patched towards completely mainline |
12:22 | mongrol | 2d only X11 drivers + opengles framebuffer? |
12:22 | rabeeh | GPU is opengl-es 2.0; there are applications that already use it like xbmc and others |
12:22 | mongrol | yep, good |
12:22 | rabeeh | full working DRI 2 is not there. |
12:23 | mongrol | is it openmax? |
12:23 | rabeeh | for video decoding there is a separate engine called vmeta |
12:23 | mongrol | and xbmc supports it directly? |
12:23 | rabeeh | vmeta has by default a gstreamer driver, and for xbmc there is a native decoder interface |
12:24 | mongrol | hmm, quite a possible frontend as well then |
12:24 | rabeeh | yes. xbmc supports vmeta directly; which in my mind is way better than omxplayer |
12:24 | mongrol | I've every intention of replacing mythfrontend with xbmc when frodo is out |
12:24 | mongrol | its quite usable on my Pi already |
12:24 | rabeeh | CuBox supports geexbox with Frodo today (hardfp) |
12:25 | mongrol | great info, thanks for your help |
12:26 | rabeeh | please provide more info once you have something |
12:26 | rabeeh | best if you can provide a ready to use rootfs that i can add to the CuBox installer |
12:27 | rabeeh | http://www.solid-run.com/mw/index.php/CuBox_Installer |
12:27 | mongrol | yeah sure, I'll document my build if its successfuly |
12:27 | mongrol | its going to be hilarious if I replace a full ATX box with a 2x2 inch one :) |
12:27 | mongrol | (+ disk) |
12:29 | dung | [D< |
14:29 | dung | |
15:14 | dung | oh - i slep on the board |
15:14 | dung | good morning |
15:17 | dung | rabeeh! it's easy to add ubuntu core to the installer. the only probelem is no link to current/latest from ubuntu |
15:18 | dung | and i dont't want me to out as ubuntu guy ;) |
15:18 | dung | they are throwing ads into desktop nowadays |
15:20 | dung | i meen to download the rootfs from the ubuntu community while in the installer |
15:22 | dung | that's a very nice thing in programming: thinking about it, writing, and it's there forever |
15:35 | bencoh | hey guys, is http://www.solid-run.com/mw/index.php/Angstrom_on_CuBox supposed to be accurate/up-to-date ? |
15:36 | bencoh | (or is there some other "official" OE repository for the cubox ?) |
15:40 | Kiranos | there seem to be alot on what to do |
15:41 | bencoh | and the git repository hasn't been updated since june |
15:56 | dung | today we eat apps from buildd and can't wait for the next snapshot |
15:59 | bencoh | hm ? |
16:00 | dung | sad, but my teacher is trial and error :( |
16:00 | bencoh | oh, that's not sad, that's perfectly fine with me :) |
16:00 | dung | is experience |
16:01 | bencoh | asking wether a source of information is still uptodate isn't incompatible with the fact that I'm already playing with OE ;) |
16:01 | bencoh | whether* |
16:03 | dung | you can use any distro, all met the at the same: kernel and driver |
16:04 | Kiranos | you speak in riddles my friend :) |
16:04 | dung | very cool is just a chroot to distros :) |
16:04 | bencoh | sure, but I'm specifically willing to build something around OE and the cubox |
16:05 | dung | what's OE ? |
16:06 | bencoh | openembedded |
16:06 | dung | oh |
16:07 | dung | the words 'open' and 'embedded' are incompatible in some kind |
16:08 | bencoh | that's the very sad part about embedded :) |
16:08 | dung | g* |
16:09 | bencoh | (well ... it's not entirely true anyway, but ...) |
16:20 | dung | distributiond need to earn respect |
16:21 | dung | nobody wants to download binaries from strangers |
16:21 | dung | ah! the security of graphics driver? |
16:22 | dung | if i cant' read the source. a git tree is nothing more than an exe |
16:24 | dung | i'm not that experienced that i know what can be done with /dev/mem |
16:25 | dung | but.. local security is not a matter at home |
18:00 | _rmk_ | damn it, shesselba just dropped off |
18:03 | rabeeh | ? |
18:03 | rabeeh | shesselba__ is off; but the original shesselba is still here |
18:03 | rabeeh | the original and only :) |
18:04 | _rmk_ | oh. In which case... |
18:04 | _rmk_ | 12:41 < axboe> rmk: yeah, that is the culprit... ingo reported the same, sent out a test fix. will upstream once confirmed |
18:04 | _rmk_ | got a reply to his query last night ^^^ |
18:17 | rabee | 18:17 * rabeeh lost you |
18:18 | rabeeh | English please |
23:06 | RandomPixels | hello guys |
23:06 | RandomPixels | my ubuntu 10.04 powered cubox won't boot without hdmi |
23:07 | Morta | What OS do you have on your PC |
23:07 | Morta | ? |
23:08 | RandomPixels | ubuntu 10.04 |
23:08 | RandomPixels | the one that shipped with the cubox |
23:08 | Morta | No i mean on your main pc |
23:08 | Morta | http://www.solid-run.com/mw/index.php/Flashing_U-Boot |
23:08 | Morta | Try to flash uboot |
23:09 | RandomPixels | mac osx |
23:09 | RandomPixels | and windows |
23:09 | Morta | Do not the windows one |
23:09 | RandomPixels | :) |
23:09 | Morta | this isnt flash propper |
23:10 | Morta | I had only expirence with tftpt and windwos |
23:10 | Morta | so tfpt is a proper solution |
23:10 | Morta | so try with this |
23:10 | Morta | should be possible on macosx also i think |
23:11 | Morta | http://download.solid-run.com/pub/solidrun/cubox/u-boot/2009.08_5.4.4_SR1/oct-3/ |
23:11 | Morta | that the newst uboot |
23:12 | RandomPixels | worst part is i don't have any hdmi capable display in the house |
23:12 | Morta | buy a hdmi to vga cable ? |
23:12 | RandomPixels | N/A at this hour |
23:14 | Morta | i dont need a hdmi cable to show the uboot procces |
23:14 | Morta | you can get with a usb to mini usb cable |
23:14 | Morta | and then with putty oder minicom |
23:15 | bencoh | or screen on osx |
23:15 | Morta | yes screen is also possible with linux, unxi and osx |
23:20 | RandomPixels | i try to run screen |
23:20 | RandomPixels | Cannot exec '/dev/tty.usbserial': No such file or directory |
23:25 | Morta | you must look with mount |
23:25 | Morta | and your usb cable must be pluged in |
23:26 | Morta | or with df -h i dont know if it possible on osx i only know linux good and windows as well |
23:27 | RandomPixels | devfs 182Ki 182Ki 0Bi 100% 630 0 100% /dev |
23:27 | RandomPixels | map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net |
23:27 | RandomPixels | map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home |
23:27 | RandomPixels | devfs 182Ki 182Ki 0Bi 100% 630 0 100% /dev |
23:27 | RandomPixels | map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net |
23:27 | RandomPixels | map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home |
23:27 | RandomPixels | sorry |
23:28 | RandomPixels | ./dev/disk0s2 111Gi 104Gi 7.2Gi 94% 27197340 1897962 93% / |
23:28 | RandomPixels | devfs 182Ki 182Ki 0Bi 100% 630 0 100% /dev |
23:28 | RandomPixels | map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net |
23:28 | RandomPixels | map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home |
23:28 | Morta | looks only vor hd |
23:28 | Morta | hdd |
23:28 | Morta | try df -h |
23:29 | RandomPixels | that's what i did |
23:29 | RandomPixels | should i connect only the USB cable ? |
23:29 | RandomPixels | without power ? |
23:29 | Morta | yes |
23:30 | Morta | and what gives only the command mount for a output ? |
23:30 | RandomPixels | devfs on /dev (devfs, local, nobrowse) |
23:30 | RandomPixels | map -hosts on /net (autofs, nosuid, automounted, nobrowse) |
23:30 | RandomPixels | map auto_home on /home (autofs, automounted, nobrowse) |
23:30 | RandomPixels | ./dev/disk0s2 on / (hfs, local, journaled) |
23:30 | RandomPixels | devfs on /dev (devfs, local, nobrowse) |
23:30 | RandomPixels | map -hosts on /net (autofs, nosuid, automounted, nobrowse) |
23:30 | RandomPixels | map auto_home on /home (autofs, automounted, nobrowse) |
23:30 | RandomPixels | last 4 rows |
23:31 | Morta | you see /dev/tty .... ? |
23:34 | RandomPixels | only tty.Bluetooth-Modem and tty.Bluetooth-PDA-Sync |
23:35 | Morta | try mount /dev/tty.usbserial |
23:35 | RandomPixels | mount: /dev/tty.usbserial: unknown special file or file system. |
23:35 | RandomPixels | just to be sure |
23:36 | RandomPixels | we're talking about the USB cable |
23:36 | RandomPixels | to the serial port of the cubox |
23:36 | RandomPixels | the small one, below eSATA |
23:36 | Morta | yyes |
23:37 | Morta | the cubox has a mini usb to rs232 converter |
23:37 | RandomPixels | does it ? :) |
23:38 | RandomPixels | so my cable might be f***-ed up ? |
23:38 | Morta | i dont think so |
23:39 | Morta | its hard to help you because i'm not really pro on osx |
23:39 | RandomPixels | the unix bases behind are pretty much the same |
23:39 | Morta | yes but unix and linux has his diffrence |
23:39 | RandomPixels | so 70% of stuff can be done on osx |
23:39 | RandomPixels | oh, big differences |
23:40 | Morta | they are small ones and big diffrences |
23:41 | Morta | ok try with windows |
23:41 | Morta | but dont do the flash with windows i didnt make good experiences |
23:43 | Morta | i had a bricked cubox so i try to flash u boot i get the resualt who is written on page but after a reboot it was again bricked |
23:46 | RandomPixels | back. rebooted |
23:47 | Morta | so you can try with putty or tera term |
23:47 | Morta | the setup is serial |
23:47 | Morta | baud rate 115220 |
23:48 | Morta | 115200 |
23:48 | Morta | first step |
23:48 | Morta | disconnect all cables from cubox |
23:48 | Morta | the connect the usb cable between pc and cubox |
23:48 | RandomPixels | eh, leave it, i'll do it when i'm back in UK |
23:49 | Morta | ok |
23:49 | Morta | good chance |
23:49 | RandomPixels | thanks a lot! |
23:49 | Morta | np |