00:21 | DHowett | Having a tracking number for my CuBox only makes the anticipation work. Bedamned, postal services! |
00:21 | DHowett | worse. not work. |
00:47 | Coburn | Problem... |
00:48 | Coburn | When compile any other kernel than rabeehs, my USB card reader doesn't work. |
00:48 | Coburn | By that, it only detects one port instead of all of them |
00:48 | Coburn | Is there a magic setting that is required for usb card readers to work? Multifunction devices or something? |
01:02 | DHowett | Coburn: this might be a stretch, but maybe multi-LUN support for SCSI generics? |
01:02 | Coburn | I'm going to check |
01:03 | DHowett | (as usbstorage exposes its nodes via sg, and that *might* be a generic multi-card->usb-mass-storage bridge chip) |
01:03 | Coburn | likely |
01:04 | Coburn | Got it |
01:04 | Coburn | Scan all LUNs |
01:18 | Coburn | bloody realtek... |
01:18 | Coburn | Bus 001 Device 002: ID 0bda:0151 Realtek Semiconductor Corp. Mass Storage Device (Multicard Reader) |
01:29 | Coburn | WOOOT |
01:29 | Coburn | Needed the all LUNs probed |
01:30 | Cobur | 01:30 * Coburn commits that to internal brain memory |
01:41 | DHowett | awesome :D |
03:07 | Coburn | welp, a sandisk 16gb uSD just hit the bin |
03:07 | Coburn | it gave me sense errors on sector 4096 |
03:17 | DHowett | Could it be the aforementioned reader? |
03:18 | DHowett | That seems like such a perfect sector number. |
07:05 | Coburn | [12:17:59] Could it be the aforementioned reader? |
07:05 | Coburn | Nah |
07:05 | Coburn | Trying it in another PC makes it derp |
07:05 | DHowett | meh, sucks |
07:06 | Coburn | actually |
07:06 | Coburn | lemme try it in windows |
07:07 | Coburn | yep |
07:07 | Coburn | it's stuck on diskpart clean |
07:10 | Coburn | DISKPART> clean |
07:10 | Coburn | DiskPart has encountered an error: Data error (cyclic redundancy check). |
07:10 | Coburn | See the System Event Log for more information. |
07:10 | Coburn | Good on ya windows |
09:31 | dxtr | My kernel is friggin' awesome now \o |
10:01 | rabeeh | dxtr: which version? |
10:04 | dxtr | 3.8 |
10:04 | dxtr | Linux cubox.dxtr.cc 3.8.0 #7 Mon Feb 25 13:31:54 CET 2013 armv7l GNU/Linux |
10:35 | Thirsty | dxtr: headless or with HDMI output? |
12:29 | dxtr | Thirsty: Headless |
16:44 | edorizzi | re all |
16:45 | edorizzi | may I ask help about my "bricked" cubox v2 ? |
17:16 | rabeeh | hi edorizzi |
17:17 | edorizzi | hi rabeeh |
17:17 | rabeeh | hey. |
17:17 | rabeeh | what's with your CuBox? |
17:18 | edorizzi | I received it fewdays ago .. I was happy with it untill as a stupid I tried to upghrade the version of ubuntu .... |
17:18 | edorizzi | after that it seems dead ... |
17:18 | edorizzi | seems but not true |
17:19 | rabeeh | oh |
17:19 | rabeeh | is the red light on the front on? |
17:19 | rabeeh | i mean once you power it on? |
17:19 | edorizzi | no |
17:19 | edorizzi | I followed the wiki page to try to "unbrick it" |
17:19 | rabeeh | did you use the CuBox installer for that? |
17:19 | edorizzi | no, no light at all |
17:20 | edorizzi | yes .. let me explai |
17:20 | edorizzi | explain what I did |
17:20 | edorizzi | I'm using a macbookpro with 10.8.2 |
17:21 | edorizzi | I installed zterm, the only I found able to use xmodem |
17:22 | edorizzi | I'm able to upload the installer (v1 at the beginning, today I tried with the new v3) |
17:23 | edorizzi | but it does not reboot |
17:23 | rabeeh | if there is no red light once you power on the box then probably u-boot was wiped out (v1 installer also tries to install u-boot too) |
17:24 | edorizzi | I guess so |
17:24 | rabeeh | what about the green LED on the power supply? |
17:24 | rabeeh | is it constant on? or blinking? |
17:24 | edorizzi | no light at all |
17:25 | rabeeh | oh |
17:25 | edorizzi | I followed step by step this http://www.solid-run.com/mw/index.php/Unbricking_CuBox_-_Reflashing_SPI_Memory |
17:25 | rabeeh | then please disconnect CuBox from the power supply and check if the green LED comes up? |
17:25 | rabeeh | if not then most probably your power supply is fried |
17:26 | edorizzi | sorry sorry … the green light is on on the POWER SUPPLY ... |
17:26 | rabeeh | ok :) |
17:27 | edorizzi | I thought on the cubox .. sorry again |
17:27 | rabeeh | do you have access to Linux machine? |
17:27 | rabeeh | we never tried unbricking using Mac |
17:27 | rabeeh | but the process is very simple - |
17:27 | rabeeh | 1. Press on the small button on the back of CuBox (beneath the RJ45 connector) |
17:27 | rabeeh | 2. Power on (then CuBox Dove goes into x-modem state) |
17:28 | edorizzi | if I turn on the box I can access to it … hitting return I get Bootstrap 2.33> |
17:28 | rabeeh | 3. Send the u-boot in it's _uart.bin version |
17:28 | rabeeh | btw - is it CuBox or CuBox Pro? |
17:28 | rabeeh | oh; great |
17:28 | edorizzi | it is the pro .. the button in above the HDMI |
17:28 | rabeeh | means the main processor is alive - seems nothing really damaged |
17:28 | rabeeh | oh. it's the pro. |
17:28 | rabeeh | hold on then. |
17:30 | rabeeh | please use this image instead - |
17:30 | rabeeh | http://dl.dropbox.com/u/72661517/tbr/u-boot-cubox_hynix_cubox_2GB_uart.bin |
17:30 | rabeeh | i will update the download.solid-run.com with the newer image |
17:30 | rabeeh | basically the spi flash image is unified for both CuBox and CuBox pro |
17:30 | rabeeh | but the _uart.bin version is different (since it relies on different configuration of the DDR) |
17:31 | edorizzi | u-boot-cubox_hynix_cubox_uart.bin ? |
17:31 | edorizzi | 03-Oct-2012 19:12 339436 |
17:32 | edorizzi | and this image on the usb pen cubox-installer-0_3.zip ? |
17:33 | rabeeh | nop |
17:33 | edorizzi | aaah |
17:33 | rabeeh | download that file through the zterm |
17:34 | punkt | rabeeh: it should be possible to unify the uart image aswell, due to the marvel chip spec |
17:34 | rabeeh | well. nop |
17:34 | rabeeh | i tried doing that; but the bootrom header is one when loading through uart |
17:35 | rabeeh | when loading through the spi flash you can select via board type (we have that already implemented). |
17:36 | punkt | rabeeh: isn't it possible to get this with different extended bootromheaders? |
17:36 | rabeeh | nop. loading through xmodem is really very basic |
17:36 | punkt | rabeeh: ok |
17:36 | rabeeh | you can't run custom binary headers (typically used for ddr3 read calibration) and you can't have different headers depending on a reset strap on the board. |
17:37 | rabeeh | on CuBox we have three different resistors that we use to map the different board versions and the amount of DDR. we can use those resistors as reset strap but only when booting from the SPI flash. |
17:37 | punkt | rabeeh: not with only one reset strap on the board... but isn't something else different on the board, that you could match against? |
17:38 | edorizzi | I'm uploading u-boot-cubox_hynix_cubox_2GB_uart.bin right now |
17:38 | rabeeh | reset strap is the only way. |
17:38 | rabeeh | the main reason is that you can't really run any kind of software without the DDR being alive |
17:38 | rabeeh | and you need the header to get the DDR alive :) |
17:39 | punkt | rabeeh: exactly, what is the difference between uart and spi, does the uart make no use of the extended bootrom header? |
17:40 | punkt | rabeeh: because, the extended bootrom header is hosting the ram configuration, as far as i know |
17:40 | punkt | rabeeh: not the binary header extension |
17:40 | rabeeh | the uart makes use of the extended bootrom header; but it will accept only one configuration (hardcoded in the ROM code inside the chip) |
17:41 | rabeeh | where booting from spi can accept different bootrom headers |
17:41 | rabeeh | well... maybe there is a common configuration between the 1GB and 2GB configuration that it's possible to make at least for the uart version. |
17:42 | punkt | rabeeh: you mean a common timing configuration |
17:42 | rabeeh | yes. timing wise |
17:44 | rabeeh | the diff isn't that big - |
17:44 | rabeeh | http://pastebin.com/vC1NQ1bx |
17:44 | rabeeh | the 0xD0800100 and 0xD0800110 defines the sizes of the mapped window (which we can leave for 1GB) |
17:44 | punkt | rabeeh: unified diff plz |
17:45 | punkt | rabeeh: :) |
17:45 | rabeeh | http://pastebin.com/B38qmu2Y |
17:45 | edorizzi_ | sorry rabeeh, now it's working .. which package do you suggest ? ubuntu-core 12.10 o the 12.10-hardfp ? |
17:45 | rabeeh | both ubuntu 12.10 are hardfp |
17:45 | rabeeh | there is headless version and xubuntu which is headful |
17:46 | edorizzi | yes .. it's tru .. I) go wit ubunto for now |
17:48 | edorizzi | are you still here ? |
17:48 | rabeeh | yes. |
17:48 | rabeeh | actually the bootrom developer from Marvell just visiting me |
17:48 | rabeeh | (software developer). |
17:48 | rabeeh | :) |
17:49 | edorizzi | I'm getting this ... |
17:49 | edorizzi | mmc0: Timeout waiting for hardware interrupt. |
17:49 | edorizzi | mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0xe00 |
17:50 | punkt | rabeeh: ok, due to the datasheet 0x1e in the main header is indicating the count of extended headers |
17:50 | edorizzi | pls. tell him to say hallo to spiderman ;-) |
17:50 | punkt | rabeeh: it also tells that its only needed in spi or PCIX mode |
17:50 | punkt | rabeeh: why isn't it also possible at least for NAND? |