| 02:32 | jmontleo | _rmk_, should the wifi/bluetooth work with the diff you posted, or are they still a work in progress? (http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.13-rc7-20140116.diff) |
| 07:30 | Juggie | xbmc any better on i2ultra/i4 vs lower end models? |
| 07:40 | jnettlet | Juggie, well more cores, faster GPU, and more memory bandwidth are always going to hep |
| 07:40 | jnettlet | help |
| 07:41 | Juggie | it should be more limited by the GPU for skin |
| 07:42 | jnettlet | one of the limiting factors of the GPU is the memory bandwidth |
| 07:44 | Juggie | hmm |
| 07:44 | jnettlet | but even the single core can do 1080p XBMC at 30fps |
| 07:46 | Juggie | yah the video accel should be the same across the board. |
| 07:46 | Juggie | its really the gui/skin performance i was curious about |
| 07:47 | Juggie | too much choice in the market atm, pivos is coming out with a new box too |
| 07:49 | jnettlet | yes but how is their thermal control? The cubox-i excels at that. |
| 07:50 | Juggie | no idea |
| 07:52 | Juggie | pivos is using the new Amlogic M802 cpu |
| 07:57 | jnettlet | I just have no need for 4k :-) |
| 08:01 | jnettlet | _rmk_, wumpus, so we should take this errata into account moving down the road with GPU drivers. The GPU3D L1 cache assumes that all memory requests are 16 bytes. If a request is 16 bytes, there |
| 08:01 | jnettlet | are no issues since the data boundary lines up evenly. If a request is not aligned to 16 bytes, the |
| 08:01 | jnettlet | memory controller will split those unaligned requests into two requests, doubling the number of |
| 08:01 | jnettlet | requests processed internally in L1 cache. |
| 08:04 | Juggie | jnettlet, i was not really thinking about 4k but that is a good point |
| 08:05 | Juggie | in the realm of intel minature boxes, that baytrail nuc is finally showing up in retail |
| 08:05 | Juggie | $130+ram is pretty decent |
| 08:06 | Juggie | more if you want a disk |
| 08:30 | wumpus | jnettlet: thanks for the info |
| 08:33 | jnettlet | wumpus, hey |
| 08:33 | jnettlet | has bunnie contacted you about his Novena board and working GC2000 support for etnaviv |
| 08:34 | wumpus | I don't think so |
| 08:35 | wumpus | nope, I have no mails from him at least |
| 08:36 | wumpus | there were some questions about android gc2000 at some point a month or so ago |
| 08:36 | jnettlet | wumpus, what kind of questions? |
| 08:38 | wumpus | people working on cyanogen mod for some samsung tablet, how to get it running, but they usually go scared when I tell gc2000 needs some changes to the driver still :) |
| 11:19 | jnettlet | grrr, the point and shoot that is definitely showing its age, but was great for super-macro shots just died :-( |
| 11:20 | jnettlet | cell phones suck for shooting circuit boards |
| 11:21 | dv_ | jnettlet: hey, hows the kernel doing? |
| 11:24 | _rmk_ | jnettlet: some p-a-s suck too, especially when they have a nice bright flash which they don't like you turning off |
| 11:25 | jnettlet | dv_, generally good. Stilling need to look at wifi and esata |
| 11:25 | _rmk_ | those photos of the icybox board I did a few days ago, I ended up having to put a piece of paper in front of the flash to get rid of a lot of its energy, otherwise the photo was just a white reflection from the board |
| 11:25 | jnettlet | _rmk_, yeah this Olympus was generally decent. But 5 years old and the sensor just crapped out. |
| 11:26 | Thijxx | Hi there magicians |
| 11:26 | MikeSeth | during the boot time initialization we switch from internal oscillator to an external crystal correct? |
| 11:27 | _rmk_ | jnettlet: I hacked esata yesterday, and I see that ojn has posted patches for wifi |
| 11:27 | jnettlet | _rmk_, excellent! is that on lkml? |
| 11:28 | jnettlet | my football team lost, so they are out of the playoffs. No more distractions there. |
| 11:28 | _rmk_ | ... but, my bigger concern at the moment is that the hummingboard DT patches aren't currently making it into mainline because the branch which the pengutronix folk merged it into has been rejected |
| 11:28 | jnettlet | what? |
| 11:29 | _rmk_ | basically their re-organisation of the pinctrl stuff wasn't acceptable |
| 11:29 | _rmk_ | and they took my patches into that and reworked them for those changes |
| 11:30 | jnettlet | oh and your dt relied on their changes? |
| 11:30 | jnettlet | ah |
| 11:30 | _rmk_ | my DT doesn't, but what they merged did |
| 11:30 | jnettlet | that seems kind of backwards, since your DT works with upstream |
| 11:30 | _rmk_ | they updated what I sent them for their changes, and merged that |
| 11:30 | _rmk_ | anyway, I'm pressing for agreement that I can send them as-is |
| 11:31 | _rmk_ | and maybe the cubox-i DT support along with it at the same time. |
| 11:31 | _rmk_ | but primerily, I want the hb dt support in during this window |
| 11:36 | _rmk_ | btw, the esata changes I did are a real hack - I just changed the hard-coded values in the driver, prevented the stupidities from occuring, and made the thing print a message when it enters the can-only-be-recovered-by-soc-wide-reset low power mode |
| 11:38 | jnettlet | _rmk_, is your work based on the current in kernel driver or the patches posted a couple of days ago cleaning up the init code? |
| 12:32 | _rmk_ | jnettlet: http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.13-20140120 |
| 12:32 | _rmk_ | jnettlet: http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.13-20140120.diff |
| 12:33 | _rmk_ | I think the PWM leds stuff is being fixed differently |
| 12:33 | jnettlet | oh excellent. I will rebase that onto 3.10 and see what breaks. |
| 12:57 | Thijxx | anyone running Arch and having dhcp boot problems? (i4-pro) |
| 13:05 | _rmk_ | jnettlet: you'll like this... |
| 13:05 | _rmk_ | jnettlet: have you seen my current signature which is on every email I send for linux stuff? |
| 13:06 | _rmk_ | jnettlet: basically, its about our fttc line only doing around 5.8mbps |
| 13:06 | _rmk_ | jnettlet: this morning, we discovered that our other (main voice number) is dead - no DC on the circuit... but this carries the ADSL which this irc connection is using (because it was the faster) |
| 13:07 | _rmk_ | jnettlet: coincidentally, the FTTC line is now doing... about 8.3mbps. |
| 13:30 | dv_ | is the ti 3410 used in the cubox-i or the hummingboard? |
| 13:34 | _rmk_ | dv: ti3410? |
| 13:34 | dv_ | a kernel module that causes compiler errors with the kernel. but I think the error is caused elsewhere. |
| 13:35 | dv_ | I just thought it is a necessary module for the cubox-i . I do not know what the cubox-i uses for USB |
| 13:35 | _rmk_ | most of the stuff is on SoC for cubox-i |
| 13:35 | dv_ | (the 3410 seems to be something for usb peripherals) |
| 13:35 | dv_ | yeah, thats what puzzled me. |
| 13:35 | _rmk_ | the only off-chip devices we talk to are the rtc and ether phy. |
| 13:38 | dv_ | alright |
| 13:38 | dv_ | on a sidenote, I can build the SPL u-boot with yocto now, and it works both for the hummingboard and for the cubox-i |
| 14:02 | jnettlet | _rmk_, that is nuts |
| 14:03 | jnettlet | so the voice line was interfering with the DSL circuit? |
| 14:11 | dv_ | yay, now both uboot and kernel boot with the cubox-i and the HB |
| 14:11 | dv_ | I can put in the exact same SD card in the devices and it works. thats cool |
| 14:17 | jnettlet | dv_, we will need to add a uboot.scr when we switch to device-tree. It will need to choose a different .dtb depending on the board. |
| 14:17 | dv_ | or uenv.txt ? |
| 14:17 | dv_ | hmm does uboot use both? first uboot.scr, then uEnv.txt ? |
| 14:19 | jnettlet | uboot first looks for uboot.scr and will use that if it is there. If it doesn't exist it will see if there is a uEnv.txt file and use that. Then it applies that to finish loading the dtb and zImage / uImage and boot accordingly |
| 14:20 | MikeSeth | _rmk_: I've taken a look at imx documentation, now I see what you meant by non-trivial clock tree |
| 14:20 | dv_ | I generally prefer uEnv.txt because it does not have to be processed, unlike boot.scr |
| 14:21 | jnettlet | but I don't think uEnv can actually do conditionals |
| 14:21 | dv_ | I think it does. its just uboot script |
| 14:22 | dv_ | jnettlet: do you think it would be possible to identify the board in uboot and choose the dtb accordingly? that would make it possible to use the exact same sd card on all devices, just like now |
| 14:23 | jnettlet | we are already doing board detection in uboot. I guess the .dtb detection depends if things are standardized enough |
| 14:24 | jnettlet | that would also really make neither a uEnv.txt or boot.scr necessary |
| 14:25 | jnettlet | hmmm. I wonder if I can make SPL smart enough that if there is no uEnv.txt or boot.scr to just load zImage and cut the second stage of u-boot out completely |
| 14:27 | jnettlet | I guess I would need some way to break that our and let SPL load the second stage for debugging |
| 14:29 | dv_ | hmm I guess the devicetree would only be actually useful once the kernel is mainlined. if I understand it correctly, the dtb would eventually encompass all cubox-i and HB devices |
| 14:29 | _rmk_ | jnettlet: things may seem slower - I've just swapped the FTTC/ADSL connections... FTTC measures 8.17Mbps down 0.42Mbps up vs ADSL at around 7Mbps down 0.7Mbps up. |
| 14:30 | jnettlet | dv_, nope there will be a couple of .dtb files. |
| 14:31 | jnettlet | but it will be useful for people wanting to use my 3.10 kernel as well |
| 14:31 | dv_ | ah. so, the sdcard image would contain a bunch of dtb files on the fat32 partition alongside the kernel, and uboot would choose the appropiate dtb |
| 14:32 | dv_ | the SPL would, that is |
| 14:33 | jnettlet | yep right .dtb and then same kernel |
| 14:36 | dv_ | alright. it does not match the pattern used by meta-fsl-arm, but I guess it can be argued that this is a special feature of cubox-i machines |
| 14:37 | dv_ | (meta-fsl-arm expects exactly one dtb) |
| 14:40 | jnettlet | well ultimately all of meta-fsl-arm should use a single kernel and just have a bunch of .dtb files |
| 14:40 | jnettlet | that is really the whole point of device-tree. However I know that is a sore subject with _rmk_ these days |
| 14:42 | dv_ | oh wait. nevermind. I misread something. |
| 14:42 | dv_ | it is actually a whitespace-separated list of DTBs |
| 14:43 | jnettlet | ah okay that makes complete sense |
| 14:45 | dv_ | hmm I need to give the machine config for yocto a name. it would be one config for cubox-i and HBs (since there is no point in having different configs - they would be identical) |
| 14:46 | dv_ | I think "cuboxi" would be appropiate. it would include hummingboard, but the cuboxi is more prominent. and "solidrun" is inaccurate, since the marvell-based cubox is also from solidrun |
| 14:50 | jnettlet | solidxrun-fsl |
| 14:50 | jnettlet | solidrun-fsl |
| 14:50 | jnettlet | or solidrun-imx6 |
| 14:50 | jnettlet | is probably more accurate |
| 15:36 | dv_ | alright. solidrunmx6 then. (for some reason, dashes seem to be verboten in machine names) |
| 15:37 | jnettlet | what about underscores? |
| 15:37 | dv_ | that too |
| 15:37 | dv_ | for example, the sabre SD machine config name is imx6dlsabresd |
| 15:38 | jnettlet | does that mean the proper name should be imx6solidrun? |
| 15:38 | dv_ | hmm that would probably be better |
| 15:38 | jnettlet | at least consistent |
| 15:38 | dv_ | ah, btw, there are now thoughts in meta-fsl to move to SPL. they are also recommending to move to mainline u-boot. |
| 15:39 | jnettlet | well MXC SPL hasn't been accepted into mainline yet. |
| 15:40 | jnettlet | it is another work in progress |
| 15:41 | dv_ | yeah I am skeptical that it will be part of 2014.01 |
| 15:42 | dv_ | and I do not want to wait much longer before submitting the meta-fsl-arm-extra patches |
| 15:42 | dv_ | ideally I could use the forked u-boot for a while and then switch to mainline in a future patch |
| 15:42 | dv_ | otavio: what do you think? |
| 15:49 | MarcusVinter | jnettlet, may we take a look at this bluetooth issue today if you get some time? |
| 15:58 | suihkulokki | has anyone tried building galcore.ko for recent kernels? |
| 15:58 | jmontleo | suihkulokki, haven't, don't even know where to get the code; if someone points me to it I'll be happy to try |
| 16:03 | otavio | dv_: the SPL implementation did by Wandboard, and copied in SolidRun fork, is bad ... I'd use mainline code |
| 16:03 | jnettlet | MarcusVinter, probably don't have time today. Maybe tomorrow. I also don't have a box to test with right now. |
| 16:03 | otavio | dv_: and port the SPL code to the current mainline version and properly integrate it |
| 16:03 | dv_ | otavio: but according to jnettlet it hasnt been fully integrated yet |
| 16:04 | otavio | dv_: in mainline? SPL didn't been fully merged yet |
| 16:04 | dv | 16:04 * dv_ is confused |
| 16:04 | jnettlet | there is no MX6 SPL support in mainline. The only proposal for SPL is the patches that Wandboard and SolidRun are using |
| 16:04 | otavio | dv_: but ought to make it more or less final layout |
| 16:04 | otavio | jnettlet: right |
| 16:04 | otavio | jnettlet: the multi pads has been merged |
| 16:04 | dv_ | so I cannot use mainline. at least not without patches. |
| 16:04 | MarcusVinter | Okay thanks jnettlet. Its just we have to demo it to another company tomorrow and I wanted to be able to show them bluetooth working to give them more of an idea of how it will work. hopefully they will like it anyway though lol. If they do, SolidRun and i-Virtuals will make some nice cash. |
| 16:05 | otavio | SPL final integration is missing yet |
| 16:05 | dv_ | yeah I included that in "patches" |
| 16:05 | otavio | dv_: you do |
| 16:05 | otavio | dv_: hummingboard_solo is there |
| 16:05 | dv_ | oh you mean using mainline without SPL |
| 16:05 | otavio | dv_: yes |
| 16:05 | otavio | dv_: and work in upstreaming the missing parts |
| 16:06 | dv_ | hmm. what about using mainline and using the solidrun patches on top of it for now? |
| 16:06 | jnettlet | that means a different image for each variant of the board |
| 16:06 | otavio | dv_: I think SPL will be done in similar way was done in MX28 |
| 16:06 | dv_ | I want to upstream cubox-i support in meta-fsl-arm-extra asap |
| 16:06 | otavio | jnettlet: initially yes |
| 16:06 | otavio | jnettlet: but this is not a huge drawback |
| 16:07 | jnettlet | for users it is |
| 16:07 | dv_ | being able to use the exact same SD card with different machines is pretty nice, otavio :> |
| 16:07 | otavio | dv_: I fully agree; but not using dirty hacks is also nice hehehe |
| 16:07 | otavio | dv_: the problem is |
| 16:08 | dv_ | I think using mainline + applying patches in the recipe is a nice compromise, and over time, the patches can be removed |
| 16:08 | otavio | dv_: we need to see how it will be done in mainline |
| 16:08 | dv_ | hm. |
| 16:08 | otavio | dv_: the patches are not the problem |
| 16:08 | otavio | dv_: the problem is if it will be two or a single blob binary in the end |
| 16:08 | dv_ | you want to plan how to integrate SPL into image_types_fsl |
| 16:08 | otavio | dv_: mx5 has spl support |
| 16:09 | otavio | dv_: check how |
| 16:09 | dv_ | and to do that you need to know what the build output of u-boot 2014.01 will be |
| 16:09 | otavio | dv_: yes |
| 16:09 | dv_ | right now, with the fork, I get two blobs |
| 16:09 | otavio | dv_: exactly |
| 16:09 | jnettlet | as is done for tegra and ti |
| 16:09 | otavio | dv_: but we need to find the final way it will be |
| 16:09 | dv_ | and upstream isnt telling? |
| 16:09 | otavio | jnettlet: yes but not in mx5, mxs |
| 16:10 | dv_ | oh, and mx5 doesnt use SPL? https://github.com/Freescale/meta-fsl-arm/blob/master/classes/image_types_fsl.bbclass |
| 16:10 | otavio | dv_: not sure; needs checking |
| 16:10 | jnettlet | otavio, well that is ridiculous. For most installations there is no reason to have the second half of u-boot. We just need to load a .dtb and zImage and boot right to linux. |
| 16:11 | dv_ | jnettlet: second half = u-boot.img ? |
| 16:11 | otavio | jnettlet: this is what is called 'Falcon' |
| 16:11 | otavio | dv_: yes |
| 16:11 | otavio | jnettlet: and this is also supported in mainline when we have SPL proper merged |
| 16:11 | dv_ | okay now I am unsure what to do. I have fully working integration for cubox-i and hummingboard, with SPL, on my PC |
| 16:11 | otavio | jnettlet: and this is not ridculous; if you can work in a proper patch we can speed things |
| 16:12 | dv_ | so I should ditch SPL and go to mainline |
| 16:12 | otavio | dv_: did you duplicated the class no? |
| 16:12 | dv_ | part of it |
| 16:12 | otavio | dv_: send the patch and we see how it looks |
| 16:12 | dv_ | just what I needed |
| 16:12 | jnettlet | or I can switch to coreboot and not worry about u-boot's ridiculous maintainers |
| 16:12 | dv_ | okay. |
| 16:12 | otavio | jnettlet: your call |
| 16:12 | jnettlet | done then |
| 16:13 | otavio | jnettlet: calling people ridiculous does not help |
| 16:13 | otavio | jnettlet: but we're in a free world |
| 16:13 | otavio | jnettlet: so make your call and be happy |
| 16:13 | dv_ | otavio: I have heard not-so-nice things about the u-boot maintainers though |
| 16:13 | otavio | dv_: well it depends |
| 16:14 | otavio | dv_: they sometimes are hard. Linux maintainers are hard as well ... |
| 16:14 | dv_ | jnettlet: and what about barebox? |
| 16:14 | jnettlet | dv_, will look at it |
| 16:14 | otavio | dv_: but the end output is good; they try to get clean code merged |
| 16:14 | dv_ | I see |
| 16:14 | otavio | dv_: just they don't accept workarounds and like |
| 16:15 | otavio | dv_: this sometimes slow things down and people get upset |
| 16:15 | otavio | dv_: I do the same in meta-fsl-arm |
| 16:15 | dv_ | okay, I will submit the existing patches I have when I get back home. I will call the machine config "imx6solidrun". |
| 16:15 | otavio | dv_: no |
| 16:15 | otavio | imx6hummingboard |
| 16:15 | dv_ | erm, this is not just for the hummingboard |
| 16:15 | dv_ | it convers hummingboard and cubox-i |
| 16:15 | otavio | solidrun does not imply the base board |
| 16:15 | dv_ | with the same machine config |
| 16:16 | dv_ | (and same kernel, same uboot) |
| 16:16 | otavio | dv_: do you have the compromise from rabeeh this will support ALL boards done by solidrun? |
| 16:16 | otavio | I doubt |
| 16:16 | dv_ | well calling it hummingboard is also inaccurate :/ |
| 16:17 | dv_ | what we need is one name for this entire device family |
| 16:17 | dv_ | maybe imx6microsom? |
| 16:17 | jnettlet | dv_, barebox looks interesting I will try and get support up and running |
| 16:17 | otavio | dv_: cubox-i seems beter |
| 16:17 | otavio | jnettlet: barebox is nice |
| 16:17 | otavio | jnettlet: you can reuse the device tree |
| 16:18 | dv_ | otavio: kinda collides with hummingboard though . but cubox-i was also my choice initially |
| 16:18 | otavio | dv_: cubox-i is what people will look for |
| 16:18 | dv_ | ok, you could say the HB is a stripped-down cubox-i solo.. |
| 16:18 | otavio | dv_: you can put a comment in the machine .conf stating it also work for humming |
| 16:18 | dv_ | fine. cubox-i then. is it ok to use dashes in machine names? |
| 16:18 | otavio | dv_: yes |
| 16:19 | dv_ | i mean, I see names without them often. like "imx6dlsabresd" |
| 16:24 | _rmk | 16:24 * _rmk_ applies further work to his patch set |
| 16:24 | otavio | dv_: it works |
| 16:25 | otavio | jnettlet: I just think, if you help us to finish SPL work in mainline everyone profit ... this would be my option ... |
| 17:01 | _rmk_ | right, the basic cubox-i and hummingboard dt stuff is now in my tree for for-next inclusion |
| 17:04 | Thijs_ | hi there, to boot from USB stick, should it be formatted as Win32? It keeps telling me unregonnised filesystem type |
| 17:04 | dv_ | Thijs_: cubox or cubox-i? |
| 17:04 | Thijs_ | cubox-i |
| 17:04 | dv_ | iirc, you must have an sdcard inside with uboot onit |
| 17:05 | Thijs_ | I follow this: http://www.solid-run.com/mw/index.php/CuBox_Installer |
| 17:05 | dv_ | I mean, you cannot just use an usb stick |
| 17:05 | Thijs_ | oh, ok |
| 17:05 | _rmk_ | Thijs: if "Win32" means NTFS, then no. Needs to be VFAT. |
| 17:06 | _rmk_ | (or ext2/3/4) |
| 17:06 | dv_ | yeah. the partitions can be on your usb stick, no problem. its just uboot itself that has to be on the sdcard |
| 17:06 | Thijs_ | and uboot is the /boot/ with 3 files in it? |
| 17:06 | dv_ | no, uboot is placed outside of the partitions |
| 17:07 | Thijs_ | ok |
| 17:07 | jnettle | 17:07 * jnettlet doesn't think the Cubox_Installer works with cubox-i |
| 17:07 | dv_ | see http://www.solid-run.com/mw/index.php/Flashing_U-Boot |
| 17:07 | Thijs_ | thank you |
| 17:07 | dv_ | for imx6-based devices like the cubox-i it is common that they load u-boot from the first few sectors of the sd card |
| 17:08 | dv_ | and yeah, the cubox installer probably doesnt work with cubox-i (yet) |
| 17:08 | Thijs_ | but to get debian, I still need to make some combination of uboot and a debian installer I guess |
| 17:08 | jnettlet | hmmm barebox is hosted and maintained by pengutronix. I wonder if I should run away now |
| 17:08 | dv_ | jnettlet: :D |
| 17:09 | dv_ | hmm I think I saw somebody here trying to add cubox-i support to debian |
| 17:09 | dv_ | was it MikeSeth ? |
| 17:09 | Thijs_ | yes I read of him in the forum |
| 17:09 | Thijs_ | he has a HF version running |
| 17:09 | dv_ | then you know who to talk to :) |
| 17:10 | Thijs_ | :) thanks guys |
| 17:10 | dv_ | jnettlet: it is probably really better to just try to mainline u-boot SPL support instead.. |
| 17:10 | _rmk | 17:10 * _rmk_ builds 3.13 |
| 17:11 | jnettlet | dv_, this is the third "runin" with u-boot maintainers refusing to admit they have done anything wrong or refused to talk about the MX6 code. I am DONE with it |
| 17:12 | _rmk_ | jnettlet: which bit is this over? |
| 17:12 | jnettlet | u-boot |
| 17:12 | dv_ | oh :/ didnt know that |
| 17:12 | _rmk_ | yea, which bit of u-boot? |
| 17:12 | jnettlet | me working on it, I will get something else to run on the Cubox-i / Hummingboard. |
| 17:13 | dv_ | jnettlet: got any mailing list links etc.? |
| 17:13 | jnettlet | dv_, this was offline |
| 17:13 | dv_ | ah |
| 17:18 | jnettlet | it just got me thinking, "why do we even need u-boot" at this point. Google is right just come C and assembly to init bare hardware to load a kernel into memory and run it. |
| 17:19 | jnettlet | all we do is punch ourselves in the face duplicating work to initialize the same hardware, twice! |
| 17:20 | _rmk_ | except... you need to get the kernel from somewhere |
| 17:21 | _rmk_ | but I do agree... u-boot has become "the bootloader" which everyone uses just because it's there |
| 17:21 | _rmk_ | consequently many of the other projects in this area just died through lack of use |
| 17:22 | jnettlet | barebox seems to be more in tune with the linux kernel so it should be small work to get that working properly on our hardware. |
| 17:24 | jnettlet | oh someone has added kirkwood and armada XP support for Marvell. |
| 17:25 | dv_ | to barebox? |
| 17:25 | jnettlet | yep |
| 17:26 | hste | isn't coreboot an alternativ? |
| 17:26 | jnettlet | yeah that is another that I need to look more at. I played around with it for the XO platform but never took it too serious. |
| 17:27 | jnettlet | that is what most x86 Chromebooks use. |
| 17:28 | jnettlet | oh interesting it was a guy that just started following me on Google+ a couple of weeks ago that submitted the Armada support. |
| 17:29 | _rmk_ | right, that's 3.13 booted |
| 17:30 | jnettlet | http://free-electrons.com/ |
| 17:31 | _rmk_ | and now that I have the front led controllable, I can make to dim down when it's finished booting, so I know when I can log into it when the tv's off |
| 17:31 | jnettlet | oh, good idea |
| 17:31 | jnettlet | you could also flash error messages in morse code :-P |
| 17:31 | _rmk_ | I do that on the cubox indirectly by setting the front led there to be triggered from mmc activity |
| 17:32 | _rmk_ | on cubox: |
| 17:32 | _rmk_ | echo mmc0 > /sys/class/leds/cubox\:red\:health/trigger || : |
| 17:32 | _rmk_ | on cubox-i: |
| 17:32 | _rmk_ | echo 16 > /sys/class/leds/imx6\:red\:front/brightness || : |
| 17:32 | _rmk_ | I probably ought to call it cubox-i:red:front or something like that |
| 17:33 | jnettlet | _rmk_, if it is just a gpio, I have a patch in the OLPC tree that does a real "disk activity" led for mmc devices. |
| 17:33 | _rmk_ | on the cubox-i, it's a PWM, but on the cubox, it's just a gpio |
| 17:38 | jnettlet | well either should work. it is basically just the ide-block-trigger ported to the mmc infrastructure |
| 17:47 | patrickg | I'm planning on doing the coreboot port at some point. and yes, the idea is to do hardware init and leave user interface (and so on) for someone else (might be uboot or linux or tianocore ...) |
| 17:50 | jnettlet | patrickg, why coreboot rather than barebox? |
| 17:50 | patrickg | jnettlet: because I do coreboot for 7 years now - familiarity more than anything else |
| 17:51 | jnettlet | patrickg, fair enough. |
| 17:51 | patrickg | also, barebox's website stating "nfs" is scary :) |
| 17:51 | jnettlet | oh for development you have to have it. |
| 17:52 | jnettlet | but that is where I agree. You need a division of functionality. For devs nfs:tftp:http booting is a necessity for kernel development. For shipping products, load the kernel and get out of the way please. |
| 17:52 | patrickg | I think uboot (and uefi more so) have an unfortunate disregard for separation of concerns. everything is stuffed in one big project. barebox doesn't seem to be an improvement |
| 17:52 | jnettlet | dump this old "BIOS" mentality |
| 17:54 | jnettle | 17:54 * jnettlet git clones coreboot |
| 17:57 | patrickg | its arm support is still developing. supporting more chipsets should give a better idea on what to do. the allwinner a10 is the first chip to require some block device support within coreboot, for example. |
| 17:58 | jnettlet | okay that is probably too raw for immediate use :-) |
| 17:58 | jnettlet | we will see |
| 18:12 | jnettlet | oh barebox already has MX6 support. I should have this running in no time. |
| 18:12 | jnettlet | woah, barebox already has cubox_i/carrier_1 support |
| 18:15 | jnettlet | added by Lucas Stach |
| 18:15 | jnettlet | Lucas Stach, Lucas Stach...is there a Lucas Stach on the channel? |
| 18:20 | dv_ | uh, really? |
| 18:20 | dv_ | so barebox should work with it already? |
| 18:20 | dv_ | interesting |
| 18:21 | dv_ | hmm perhaps archlinuxarm uses barebox, and this is why support has been added. lets see |
| 18:23 | jnettlet | well the driver model is right out of the kernel mostly so adding new hardware should be relatively simple. |
| 18:23 | jnettlet | this definitely seems more what I want. |
| 18:23 | MarcusVinter | You still need C1 info jnettlet? |
| 18:24 | dv_ | I have never used barebox before. can it do something similar to SPL? |
| 18:24 | dv_ | because if so, I could just switch to barebox for my meta-fsl patches |
| 18:35 | hste | dv_: how is it going with gstreamer? |
| 18:35 | dv_ | hste: just starting development again, got a lot of catching up to do. right now, the meta-fsl patches have priority. gstreamer-imx follows. |
| 18:36 | dv_ | hste: in gstreamer-imx, the next thing to do is to add wayland support. |
| 18:37 | dv_ | have you tried using wayland on the imx6 already? I am curious how well it runs |
| 18:37 | hste | no. havn't tried it |
| 18:37 | jnettlet | dv_, it can do SPL and Falcon. |
| 18:37 | jnettlet | let's see if they will accept the SPL work |
| 18:38 | dv_ | alright. I will submit the patches with the forked u-boot, just to have something working now, and also mention barebox as a possible future alternative. |
| 18:39 | jnettlet | dv_, I think that sounds like a plan. Point to rabeeh's uboot repository as mine is gone from github |
| 18:40 | dv_ | I already use his |
| 18:41 | jnettlet | perfect |
| 18:47 | davorin | any1 seen rabeeh today? |
| 18:48 | MarcusVinter | I saw him leave around 12pm GMT |
| 18:48 | MarcusVinter | lol |
| 18:48 | davorin | that explains (o; |
| 18:48 | davorin | still ows me some docs (o; |
| 18:49 | davorin | or any1 seen some usom docs? |
| 18:49 | MarcusVinter | Not me. |
| 18:49 | MarcusVinter | I 'aint seen nothin'. |
| 18:49 | davorin | (o; |
| 18:49 | davorin | want to fire up my pcb software...but missing some pinouts and pcb patterns |
| 18:50 | MarcusVinter | Oh nice! |
| 18:51 | davorin | as hb doesn't support parallel tft i want to do my own carrierboard... |
| 18:52 | davorin | to be able to stack small tft displays onit with/without touchy thingy |
| 18:52 | davorin | not sure if i get problems if the form factor is the same as beaglebone (o; |
| 18:55 | davorin | bugger...1 i4pro left out of then...and not even arrived... |
| 20:21 | MikeSeth | oh wow, uboot ipu init code is hairy |
| 22:16 | jas-hacks | jnettlet: hi, with your 3.10.17 kernel are you seeing a mutex deadlock occurring in Glacore? |