| 06:09 | dbsx | Pleading. Can someone confirm that the current Debian Jessie will not boot on a Cubox? |
| 07:51 | jnettlet | Here is something to shoot for. http://www.youtube.com/watch?v=KPU4_QVPFZ0 |
| 09:56 | rabeeh | _rmk_: for getting the ar8035 working on your board you must have the exact reset strap as in the kernel i'v sent |
| 09:59 | jnettlet | rabeeh, he got it sorted out last night. |
| 10:00 | rabeeh | great |
| 10:00 | rabeeh | the ar8035 and ar8030 is extremely tricky |
| 10:05 | jnettlet | rabeeh, is the RAM config on the Carrier-1 2x256 or 1x512? |
| 10:05 | jnettlet | and it is 800Mhz correct? |
| 10:09 | rabeeh | 2x256MByte |
| 10:10 | rabeeh | 32bit width; and that's the config of the SOM board with the solo |
| 10:10 | rabeeh | 800mhz |
| 10:10 | rabeeh | 800mbps per bit; clock rate is 400mhz |
| 10:10 | jnettlet | right. perfect just what I thought. wanted to make sure. |
| 10:11 | rabeeh | the dual lite is 64bit; and the dual and quad are 64bit but with 1066Mbps per bit (i.e. 533MHz clock rate) |
| 10:16 | _rmk_ | rabeeh: do we need to configure all those pinmux settings, even the ones for the MII pins? |
| 10:16 | rabeeh | _rmk_: yes |
| 10:16 | rabeeh | we share ar8035 and ar8030 on the same footprint |
| 10:17 | rabeeh | ar8035 connects to rgmii pins; and ar8030 to rmii pins |
| 10:17 | _rmk_ | other boards don't bother with the MII pins with RGMII mode |
| 10:17 | rabeeh | i know; because they typically use ar8031 which is only rgmii and rmii pins are completely disconnected |
| 10:18 | _rmk_ | also... there's a very big question being raised over setting GPR1 bit 21, but setting SION for the reference clock. Apparantly that is wrong and can lead to the transmit clock being generated by the IMX6 but the receive clock being generated by the phy. |
| 10:20 | rabeeh | true |
| 10:20 | _rmk_ | I'm told if you want to provide the IMX6 with a reference clock, GPR1 bit 21 must be clear |
| 10:20 | rabeeh | this is only preparation for the next step |
| 10:21 | rabeeh | which is imx6 provides 25MHz and gets back either 50mhz or 125mhz (RMII and RGMII) |
| 10:21 | rabeeh | now on the board the clock for the phy is received via the crystal on the board near the phy |
| 10:22 | rabeeh | it's a 25mhz crystal that internal phy pll generates 125MHz that feeds the RGMII TX clock |
| 10:22 | rabeeh | in the future when using the AR8035 there will be a 25MHz coming from the i.mx6; instead of the crystal |
| 10:22 | rabeeh | ok? |
| 10:23 | rabeeh | now as you might guess; if you look at the crystal there are two unassembled 0402 resistors place; those will bridge the i.mx6 clock to the ar8035 phy |
| 10:24 | rabeeh | this is what i'm working on right now; i want to completely get the crystal out of the board to cleanup some place |
| 10:24 | _rmk_ | ok. so, if we have the crystal, then the 8035 generates the clock and we shouldn't set GPR1 bit 21 |
| 10:25 | rabeeh | for now yes. |
| 10:25 | _rmk_ | if we don't have the crystal, then GPR1 bit 21 needs to be set and SION clear. |
| 10:25 | rabeeh | you are asking all those question to know? or you are worried about DT? |
| 10:26 | rabeeh | SION set too |
| 10:26 | rabeeh | sorry - SION off |
| 10:26 | rabeeh | only GPR1 bit 21 set; and the pll8 set to create a 25mhz clock |
| 10:26 | _rmk_ | I'm asking because it got raised while I was banging my head against a brick wall yesterday |
| 10:26 | rabeeh | oh; sorry |
| 10:26 | rabeeh | i disappeared yesterday |
| 10:27 | rabeeh | the phy link to the imx6 is pretty tricky |
| 10:27 | _rmk_ | what didn't help was I mis-spelled a keyword in DT. rather than pinctrl-names, I had pintctrl-names. |
| 10:28 | _rmk_ | hence why when I found that eventually, it was obviously a fraudian slip, so I declared it to be beer o'clock last night :) |
| 10:28 | rabeeh | for now i'm wondering weather to be super smart and auto detect the phy type and accordingly set if it's rmii / rgmii; or just use fuse |
| 10:29 | _rmk_ | the problem will be that DT's going to be rather inflexible with this - because DT specifies the pin mux settings in a hard-coded form. |
| 10:30 | _rmk_ | if different pinmux settings will be required, it'll mean two different DT files |
| 10:31 | _rmk_ | btw, how different is carrier-1 from the ultimate cubox-i hardware? |
| 10:33 | jnettlet | _rmk_, you could just move everything else to carrier-common.dtsi and include that for each model's .dts which would incorporate the various pinmux settings. |
| 10:34 | jnettlet | that is what I have started doing for the mmp2/mmp3/xo1.75/4 variations |
| 10:34 | _rmk_ | yes, still means you need the several dtb files and get the right one for the hardware |
| 10:34 | jnettlet | unfortunately yes. |
| 10:36 | jnettlet | I would really like to see device-tree stuff moved out of the kernel/u-boot/ofw and let them all inherit from a common repository. |
| 10:37 | rabeeh | _rmk_: ethernet will be the same since it's all on the som |
| 10:37 | rabeeh | i'd rather call the common dt file microsom.dt |
| 10:38 | rabeeh | or imx6-microsom.dt |
| 10:38 | rabeeh | the differences between cubox-i and c1 will be mainly gpio, i2c addresses and connectivity |
| 10:38 | rabeeh | ethernet, hdmi, usb phy (not the control), sata, pci-e serdes (not the control) will be exactly the same |
| 10:39 | jnettlet | rabeeh, okay I will make those changes to my uboot as well. I am merging your work into uboot mainline. |
| 10:39 | rabeeh | i mean for obvious reasons serdes lines will be exactly the same; so control will be a bit modified |
| 10:40 | _rmk_ | ok. now, I'm not going to be around for a few days so I'll sort that out as and when. |
| 10:41 | jnettlet | _rmk_, have fun. |
| 10:44 | _rmk_ | another thing I found - we don't want to run enet.0 clocks at 50MHz - that's too slow for gigabit... and that clock doesn't exist in the 4.1.0 BSP |
| 10:45 | _rmk_ | that was rather confusing when reading patch 2 |
| 10:46 | jnettlet | I am interested to iperf running on it to see what kind of throughput we can generate |
| 10:47 | _rmk_ | when I set that to 50MHz, it worked on a 100mbit switch but gigabit just got interestingly corrupted packets |
| 10:47 | _rmk_ | (repeated bytes) |
| 10:49 | rabeeh | for RGMII; you must only get the TX clock from the phy |
| 10:49 | rabeeh | you must not generate it; i think the tolerance between the clock differences will make buffer under/over flows |
| 10:49 | rabeeh | maybe it's a bit confusing; let me write this again. |
| 10:50 | rabeeh | 1. in RGMII ; crystal generates 25MHz and goes to phy; phy internally generates 125MHz and feeds i.MX6 TX reference clock |
| 10:50 | jnettlet | One of the guys who works on the XSCE used to work for Freescale. One of his tasks was system performance analysis and he said that their bus arbiter architecture was the bottleneck. |
| 10:51 | rabeeh | jnettlet: i think it's internal inside the enet IP itself |
| 10:51 | rabeeh | (i.e. Synopsys) |
| 10:51 | rabeeh | it's unrelated to freescale |
| 10:51 | rabeeh | i mean freescale busses and arbitrations; for a fact i can drive >100MB/sec on SATA without issues |
| 10:52 | rabeeh | performance wise i'm capable of reaching ~430Mbps on iperf |
| 10:52 | jnettlet | I guess they actually listened to his report and fixed it :-) He left in 2010 |
| 10:54 | jnettlet | which is more than acceptable. |
| 10:56 | jnettle | 10:56 * jnettlet is going to get some fresh air. |
| 11:06 | rabeeh | have fun |
| 11:58 | dv_ | rabeeh: I am trying to write some OE scripts for the c1 |
| 11:59 | dv_ | there are existing configs for the sabre solo automotive and the sabre solo sd |
| 11:59 | dv_ | which one do you consider to be closer to the c1? the sd? |
| 12:13 | jnettlet | dv_, the sd |
| 12:13 | jnettlet | all his uboot modifications are based on that. |
| 12:15 | rabeeh | dv_: sabresd |
| 12:16 | rabeeh | please look at the patches on the wiki; the forth one adds C1 |
| 12:16 | rabeeh | http://download.solid-run.com/pub/solidrun/c1/kernel/initial/0004-Added-Carrier-One-C1-to-imx6_defconfig.patch |
| 12:16 | rabeeh | i.e. it should be make imx6_defconfig |
| 12:16 | rabeeh | on top of that add the stuff you need; for instance devtmpfs is by default disabled ! |
| 12:16 | dv_ | yes |
| 12:18 | jnettlet | dv_, can the imx6 decode and encode h264 at the same time? |
| 12:18 | dv_ | yes |
| 12:18 | jnettlet | nice |
| 12:18 | dv_ | it can encode h264 baseline only though |
| 12:18 | jnettlet | what other formats can it encode to? |
| 12:20 | dv_ | mpeg4, h263 |
| 12:21 | dv_ | oh, and mjpeg |
| 12:22 | dv | 12:22 * dv_ is trying to figure out how OE / meta-fsl-arm figures out where to put the u-boot.bin in the sdcard image |
| 12:22 | dv_ | otavio, any hints? |
| 12:22 | dv_ | does it get this info from the uboot config? |
| 12:30 | rabeeh | dv_: you are probably familiar with this - |
| 12:30 | rabeeh | http://imx.solid-run.com/wiki/index.php?title=Building_Carrier-One_U-boot_and_Kernel |
| 12:30 | rabeeh | sudo dd if=u-boot.bin of=/dev/sdX bs=512 seek=2 skip=2 conv=fsync |
| 12:31 | rabeeh | first 1KB of u-boot should be ripped off; and then it should be written to 1KB offset |
| 12:40 | dv_ | okay, |
| 12:40 | dv_ | I guess I need to adjust this in classes/image_types_fsl.bbclass |
| 12:40 | dv_ | also, is a phone recharger a good option for a c1 power source?= |
| 12:41 | jnettlet | dv_, how many amps? |
| 12:41 | dv_ | 5V 1A |
| 12:42 | jnettlet | should be fine if you aren't using usb |
| 12:42 | dv_ | hmm an USB hub would also help |
| 12:42 | jnettlet | I would suggest getting a 2A if possible. |
| 13:36 | dv_ | 2A ? |
| 13:36 | dv_ | over USB? |
| 13:36 | dv_ | isnt this a bit .. much? |
| 14:16 | jnettlet | dv_, not for a power circuit. The board isn't meant to run off a computers usb port. |
| 14:17 | dv_ | yeah |
| 14:17 | dv_ | but I thought the USB spec doesnt go that high |
| 14:17 | jnettlet | That spec is just for a port running in Host mode. |
| 14:18 | jnettlet | A usb charge/power circuit can take as much power as you can design into it. |
| 14:20 | jnettlet | A lot of new phones with larger batteries will detect the 2amps and switch to a fast charge circuit. Others require usb pins to be shorted on the cable to figure that out. |
| 14:24 | dv_ | time to shop for gadgets. |
| 14:24 | dv_ | later |
| 14:27 | shesselba | rabeeh: about audio1 extclk on 88ap510 cubox, is it connected to si5351 clkout 1 or 2? |
| 15:35 | dbsx | Anyone want to hear about the Debian show stopper? |
| 15:42 | dbsx | Due to popular demand: udev post version 175 is a mess. On a Cubox when booting from mmcblk0 it no longer creates a symlink for /dev/root. So if you have a /dev/root entry in fstab (doesn't everyone) the boot stops. Oddly if you do not have anything in fstab it will boot. |
| 16:31 | jnettlet | dbsx, actually that bug probably came around because a lot of distros wanted to start deprecating /dev devices in fstab, instead using UUID or LABEL |
| 16:33 | jnettlet | mostly because specific communities developers are pushing systems that don't support traditional SysV stylings |
| 16:39 | dbsx | That would nice if I could get UUID or LABEL to work on mmcblk. Anyway I am not a fan of systems that stop booting after an upgrade |
| 16:41 | jnettlet | is it only on mmcblk devices that it stops creating a symlink to /dev/root? |
| 16:42 | jnettlet | really any system can stop booting after an upgrade. It is near impossible to account for 100% of what a person could do to their configuration. |
| 16:44 | jnettlet | Linux and BSD are literally the only operating systems that can run on just about any computer in the world. That is pretty mind numbing |
| 16:44 | dbsx | From the bug reports it is other devices as well. I had a quick look at the scripts and could find nothing that created /dev/root |
| 16:45 | dbsx | Three things I hate about Linux a) systemd b) python c) bluez |
| 16:46 | jnettlet | it is called something like create_root_dev_rule |
| 16:46 | jnettlet | python? that isn't linux specific |
| 16:46 | jnettlet | and bluez is much better than Windows bluetooth stack. |
| 16:46 | jnettle | 16:46 * jnettlet has no comment on systemd |
| 16:48 | jnettlet | the model behind systemd is sound, but anything Lennart tackles tends to be problematic because he is unwilling to bend to accommodate input outside his mental model. |
| 16:49 | jnettlet | It is usually once he gets interested in something else and loosens control on a project that it becomes useful |
| 16:51 | dbsx | jnettlet: I grepped for anything like create_root_dev_rule in /etc & /lib no hits |
| 16:52 | jnettlet | dbsx, hmmm me neither. Must have gotten yanked at some point. |
| 16:52 | dbsx | Do you have LABEL= working? |
| 16:52 | jnettlet | haven't tried it because most my systems are rotating dev messes held together with spit and duct tape. |
| 16:53 | dbsx | Hmmm. Mine are cable ties |
| 16:59 | jnettlet | I thought this went away a long time ago and it did. Debian didn't even have a udev rule, but had a snippet in udev.conf that would create it. |
| 17:01 | jnettlet | dbsx, do you have /dev/.udev/root-link-rule ? |
| 17:03 | dbsx | No. and nothing in /run like that |
| 17:04 | jnettlet | never mind you don't. This is Debian's fault trying to support something long past deprecation without communicating to their users. |
| 17:05 | jnettlet | This "feature" has been gone since 2010 :-) |
| 17:06 | jnettlet | Most other distros dumped it when the hal daemon was deprecated |
| 17:07 | jnettlet | sorry to be the bearer of bad news. If UUID doesn't work then you should file a bug |
| 17:10 | dbsx | I starting to think that debian is a bug |
| 17:13 | jnettlet | nobody's perfect |
| 17:14 | dbsx | except me and thee |
| 17:16 | dbsx | I just tried fstab with LABEL= and UUID= on the cubox. Both freeze on boot. Nothing or /dev/mmcblk0p2 work. |
| 17:21 | jnettle | 17:21 * jnettlet wonders if this has something to do with uboot |
| 17:21 | jnettlet | I will put it on my list. |
| 17:23 | dv_ | damnit |
| 17:23 | dv_ | its surprisingly hard to find a USB<->TTL cable |
| 17:24 | dv_ | and shops are closing in half an hour :/ |
| 17:27 | dbsx | jnettlet: I have not changed uboot or kernel to create the problem. |
| 19:26 | rabeeh | dv_ / otavio: where do i get the EGL and GPU user space drivers? |
| 19:26 | rabeeh | i mean i don't want to go through the ltib hell; where is a good URL to be extracted from yocto? |
| 19:28 | dv_ | rabeeh: http://download.ossystems.com.br/bsp/freescale/source/ |
| 19:28 | dv_ | look at gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp.bin and gpu-viv-bin-mx6q-3.5.7-1.0.0-sfp.bin |
| 19:37 | gimli | is xorg needed or do we have EGL on the framebuffer too ? |
| 19:40 | otavio | dv_: sdcard class |
| 19:41 | otavio | rabeeh: what are you looking for? |
| 19:41 | rabeeh | otavio: gimli on #cubox is trying to get buildroot up and running; and he wants the gpu drivers (and probably then the video engine drivers) |
| 19:41 | rabeeh | otavio: and no; he doesn't want yocto :) |
| 19:42 | otavio | hheh |
| 19:42 | otavio | gimli: egl works in fb too |
| 19:42 | rabeeh | is there a sane place where it has a tarball to extract? |
| 19:42 | otavio | yes |
| 19:42 | otavio | http://download.ossystems.com.br/bsp/freescale/source/ |
| 19:45 | dv_ | I didnt find a USB<->TTL adapter in time |
| 19:45 | dv_ | trying to bring up the board without a serial console is not exactly easy :) |
| 19:46 | rabeeh | dv_: you can |
| 19:46 | rabeeh | just download the images i'v posted on the wiki and you can bring it up without serial console |
| 19:46 | rabeeh | u-boot goes to 1kb offset (as the dd command on the wiki) |
| 19:46 | rabeeh | and use the kernel as-is |
| 19:47 | rabeeh | oh; you need to configure u-boot command line for that |
| 19:49 | dv_ | and, how? |
| 19:49 | dv_ | :) |
| 19:49 | gimli | rabeeh: btw, got the serial port working :D |
| 19:50 | dv_ | otavio: I've been trying to add modifications to u-boot and kernel recipes |
| 19:50 | dv_ | and machine config for the c1 |
| 19:50 | rabeeh | gimli: soldered? :) |
| 19:50 | rabeeh | dv_: i was unable to upload to github the 3.0.35 / 4.1.0 (rpc connection timeouts) |
| 19:50 | dv_ | initially I tried to simply apply rabeeh's u-boot patches to u-boot-imx 2009.08 , but there are several differences, so I created a separate u-boot-c1 one |
| 19:51 | otavio | rabeeh: this offset is fro u-boot-imx |
| 19:51 | rabeeh | i'v forked the boundary devices one |
| 19:51 | rabeeh | https://github.com/SolidRun/linux-imx6 |
| 19:51 | rabeeh | i'll patch it later on |
| 19:51 | otavio | dv_: for yocto you can set the offset too |
| 19:51 | dv_ | yes |
| 19:51 | otavio | dv_: tell me what you want and I tell how to do it in yocto |
| 19:51 | dv_ | one significant difference though is that the uImage is _not_ copied with dd |
| 19:52 | dv_ | unlike with the sabre |
| 19:52 | otavio | dv_: no, we use it in a partition |
| 19:52 | dv_ | just a sec, phone |
| 20:00 | rabeeh | dv_: just sent you a u-boot.bin that should have the command line ready to boot uImage from fat filesystem on first partition on the sd card |
| 20:01 | rabeeh | just make sure that the partition starts >= 1MB |
| 20:01 | rabeeh | just make sure that the partition starts >= 1MB from the beginning of the sd card |
| 20:01 | rabeeh | dV_: just hook hdmi display capable of 1080p@60 |
| 20:03 | dv_ | ah, okay |
| 20:03 | dv_ | and what rootfs is set? |
| 20:03 | dv_ | the kernel command line I mean |
| 20:03 | dv_ | otavio: if you want I can give you the changes I've made |
| 20:04 | dv_ | its nothing spectacular though. I had to dd the u-boot.bin manually, since I didnt touch the sdcard setup yet |
| 20:04 | otavio | dv_: just tell me what you want |
| 20:04 | otavio | dv_: and which version of u-boot it is based |
| 20:04 | dv_ | rabeeh: damnit, the hdmi display here only gives me 720p :/ |
| 20:05 | dv_ | otavio: 2009.08 |
| 20:05 | dv_ | do you have a c1? |
| 20:05 | otavio | dv_: ok |
| 20:05 | otavio | hold |
| 20:05 | dv_ | otavio: check out https://github.com/rabeeh/u-boot.imx6 and http://download.solid-run.com/pub/solidrun/c1/kernel/initial/ |
| 20:06 | otavio | dv_: not yet; did not arrive |
| 20:06 | otavio | # Please, add the following variables to conf/local.conf |
| 20:06 | otavio | # in order to use this u-boot version |
| 20:06 | otavio | # UBOOT_SUFFIX = "bin" |
| 20:06 | otavio | # UBOOT_PADDING = "2" |
| 20:06 | otavio | # PREFERRED_PROVIDER_u-boot = "u-boot-imx" |
| 20:06 | dv_ | ah |
| 20:06 | otavio | dv_: rabeeh sent some |
| 20:06 | otavio | dv_: and I will send one for Fabio |
| 20:06 | otavio | dv_: and a cuple of people will work on support for yocto for i |
| 20:06 | otavio | it |
| 20:07 | rabeeh | dv_: resent with 720p |
| 20:07 | dv_ | rabeeh: thanks |
| 20:07 | dv_ | rabeeh: what is root= set to ? |
| 20:07 | dv_ | uh wait. I can find this out with "strings" |
| 20:08 | dv_ | is this for booting from NFS? |
| 20:08 | rabeeh | nop |
| 20:08 | rabeeh | initramfs |
| 20:09 | rabeeh | just load the 30MB kernel uImage from the wiki and you are all set |
| 20:09 | rabeeh | remember to put the kernel on a partition that starts >= 1MB from the start of the sd card |
| 20:09 | dv_ | alright |
| 20:10 | dv_ | otavio: my crude changes: https://www.dropbox.com/s/7sua9qfu27sd5ja/first-carrier-one-changes.patch |
| 20:11 | dv_ | (the additional kernel patches are those from rabeeh at http://download.solid-run.com/pub/solidrun/c1/kernel/initial/ ) |
| 20:11 | otavio | dv_: you missed the padding |
| 20:11 | otavio | dv_: add in line 26 |
| 20:11 | dv_ | hmm I was unsure if 2 was the default |
| 20:12 | otavio | dv_: no; or default is mainline |
| 20:12 | otavio | dv_: fslc |
| 20:12 | otavio | dv_: death for u-boot-imx heheh |
| 20:12 | dv_ | oh, well. if you can apply rabeeh's patches to the 2013 uboot, be my guest |
| 20:13 | otavio | dv_: once I have the board and schematic; I will add it there |
| 20:13 | otavio | dv_: me or fabio will do it |
| 20:13 | dv_ | great |
| 20:14 | otavio | dv_: I am finishing a customer board bringup at this moment |
| 20:14 | otavio | dv_: in 2013.10 u-boot hehe \m/ |
| 20:15 | dv_ | neato |
| 20:15 | dv_ | so freescale is upstreaming it all to mainline uboot? |
| 20:25 | dv_ | rabeeh: how long does it usually take to see something on screen? |
| 20:25 | rabeeh | 30s |
| 20:27 | dv_ | well I see the ACT LED is on |
| 20:28 | dv_ | does it make a difference if I use mkfs.vfat or mkfs.msdos? |
| 20:31 | rabeeh | mkfs.vfat |
| 20:31 | rabeeh | that's what i use |
| 20:31 | dv_ | does the initramfs use a dchp client? |
| 20:31 | dv_ | *dhcp |
| 20:33 | otavio | dv_: not much; they are better but not there yet |
| 20:34 | dv_ | rabeeh: well the board is doing something. but i dont see any hdmi output |
| 20:52 | rabeeh | dv_: i'll prepare an image for you |
| 20:52 | dv_ | ah, many thanks |
| 21:07 | rabeeh | dv_: please try |
| 21:07 | rabeeh | i'v sent you a new image; 720p |
| 21:07 | rabeeh | but this time i tested it |
| 21:07 | rabeeh | previous images had wrong bootargs |
| 21:08 | rabeeh | you can keep the uImage if you want |
| 21:08 | rabeeh | to blindly debug; look at the 'OK' LED; when uImage is booting it should go on; then off |
| 21:09 | jnettlet | dv_, send me your info so I can get OLPC to get a machine sent out to you Monday morning. That will come with a usb serial adapter you can use. |
| 21:11 | jnettlet | well hopefully Monday morning, I don't know if the person shipping them out is in the office or traveling. |
| 21:11 | dv_ | address ? |
| 21:11 | dv_ | i mean, you need the address, thats it? |
| 21:12 | jnettlet | address and phone number |
| 21:12 | jnettlet | you can't ship international without it at this point. |
| 21:12 | dv_ | rabeeh: nice, works |
| 21:12 | rabeeh | congrats |
| 21:12 | dv_ | jnettlet: ok |
| 21:13 | dv_ | rabeeh: no dhcp though, right? |
| 21:13 | jnettlet | wumpus, ^ that goes for you too |
| 21:13 | rabeeh | it's fixed 192.168.15.106 |
| 21:13 | rabeeh | you can udhcpc |
| 21:14 | dv_ | right. need to find a keyboard |
| 21:14 | dv_ | one problem though: the power source delivers only up to 1A |
| 21:15 | rabeeh | dv_: it should be ok |
| 21:15 | jnettlet | usb keyboard shouldn't draw that much |
| 21:15 | rabeeh | in idle it takes ~200mA |
| 21:15 | rabeeh | when working without gpu max ~400mA |
| 21:15 | rabeeh | your keyboard will take ~100mA max |
| 21:15 | dv_ | I see you used buildroot |
| 21:16 | rabeeh | yes. |
| 21:16 | rabeeh | i'v added things i need for testing |
| 21:16 | rabeeh | previously it had gstreamer with the vpu drivers |
| 21:16 | rabeeh | but then it became too big that it wouldn't boot |
| 21:16 | jnettlet | all these old 1GB micro-sdhc cards are perfect for uboot dev work. |
| 21:17 | rabeeh | jnettlet: yea |
| 21:17 | rabeeh | they won't die for you; ha? |
| 21:17 | rabeeh | :) |
| 21:17 | jnettlet | nope I have a whole tray of them |
| 21:18 | jnettlet | I think I have lost one. The come from a time when companies tried hard to make reliable flash media |
| 21:19 | cbxbiker61 | xbmc is going to pull in a game emulator that should work on both x86 and arm, that'll be interesting in the long run |
| 21:22 | jnettle | 21:22 * jnettlet doesn't know why he reads Linux news sites. |
| 21:23 | jnettlet | nothing but irritation |
| 21:23 | bencoh | hmm |
| 21:24 | cbxbiker61 | jnettlet, you should check out The Linux Action Show and Tech Snap on jupiter broadcasting, there's a plugin for Xbmc |
| 21:24 | jnettlet | cbxbiker61, sorry I listened to them a long time ago. All they did was talk about blah blah blah it should be more like a Mac blah blah blah |
| 21:25 | jnettlet | The only Linux entertainment I can get behind is Linux Outlaws |
| 21:25 | gimli | rabeeh: yes, soldered right ;) |
| 21:25 | jnettlet | There is the occasional rant but generally they are pretty positive. |
| 21:25 | cbxbiker61 | Tech Snap then, good security info |
| 21:26 | jnettlet | The Phoronix articles just anger me to no end. |
| 21:27 | jnettlet | I really want a search engine that will allow me to filter out parts of the internet. Just black hole entire chunks. |
| 21:27 | gimli | the dude from Phoronix need a clue stick. stopped reading them |
| 21:28 | jnettlet | Michael Larabel and yes he is a moron. |
| 21:28 | jnettlet | yet people continue to link to his articles and discuss them. |
| 21:29 | cbxbiker61 | at least he keeps me up to date on Linux video developments |
| 21:30 | jnettlet | he does nothing positive, just complains about annoying things and incites people to get upset about things they know nothing about. |
| 21:31 | gimli | lets say it simple. he is just an ass |
| 21:33 | jnettlet | I worked for 2 years trying to get VIA to work more with the opensource community. Just when we were getting ready to release a KMS driver and VIA was working on an opensource 3D driver to release. He writes a nasty article inciting a bunch of people and VIA pretty much walked away from the OSS community. I got a bunch of angry emails and death threats for taking too long, and we all walked away from it. |
| 21:33 | jnettlet | Yet he continues to complain about the state of OSS graphics drivers when he is one of the biggest problems. |
| 21:34 | jnettle | 21:34 * jnettlet needs a drink |
| 21:36 | jnettlet | that is better. |
| 21:38 | jnettlet | dv_, some progress on vivante kernel stuff today. Should have some time tomorrow to get you something to test. |
| 21:38 | jnettlet | ttyl |
| 21:38 | file | jnettlet, there is always people in OSS like that... and sometimes they don't realize they are a problem |
| 21:52 | otavio | jnettlet: what OLPC is using now? |
| 21:55 | rabeeh | otavio: Marvell mmp3 |
| 21:55 | otavio | ohh |