| 01:43 | Wizzup | What is the carrier one and how is it different from cubox-i? |
| 06:29 | jnettlet | Wizzup, The Carrier-1 was the early reference design provided to the development community to start support for the Cubox-i. It is now a product called the HummingBoard |
| 07:02 | dbsx | jnettlet: any luck with a debug uboot? |
| 07:02 | jnettlet | dbsx, still waiting to get the i4pro config rabeeh is using for the cubox-i's |
| 07:04 | jnettlet | dbsx, I can try to build you one with my standard C1 config. In theory it should work fine, I just haven't tested it. |
| 07:05 | dbsx | whichever option you think best. I can wait a day for rabeeh. It would seem the uboot actually starts OK, but then craps itself after a random period |
| 07:06 | jnettlet | that is why I am interested in getting some debug output. |
| 07:07 | dbsx | me too |
| 07:07 | jnettlet | are you testing over a serial console, or via hdmi console? |
| 07:07 | dbsx | both. I tried just console, and I tried just HDMI and I tried both |
| 07:08 | dbsx | The HDMI display does not last for long (2 secs?) |
| 07:09 | jnettlet | oh so it is getting that far? interesting. |
| 07:09 | jnettlet | usb and or ethernet plugged in? |
| 07:10 | jnettle | 07:10 * jnettlet will be right back. dogs just woke up and need to go out |
| 07:11 | dbsx | HDMI I occasionaly get to see the SR logo and some ubootish output (@60 HZ), then the monitor switches to 70HZ and goes crazy or blank. Most times the HDMI output is just blank |
| 07:15 | dbsx | see http://pastebin.com/xwWqJGtX for all of my console output (with lots of power ons when it stops) |
| 07:25 | jnettlet | dbsx, oh the monitor switches to 70hz, that means there is some clock instability. |
| 07:25 | jnettlet | the HDMI clocks are a bit off in u-boot I still need to fix that. |
| 07:27 | dbsx | ok, the big hassle is that it will just freeze up when console only and intterupted. It means I do not get very far |
| 07:34 | jnettlet | let's try a debug build using my using config. That should be close enough to figure out what is up. |
| 07:34 | dbsx | ok. let me know where to get it |
| 07:41 | jnettlet | dbsx, https://dl.dropboxusercontent.com/u/736509/c1_debug/u-boot.imx |
| 07:43 | dbsx | ok, where do I 'dd' it on the SD. ? |
| 07:44 | jnettlet | oh sorry. Are you on windows or linux? |
| 07:44 | dbsx | linux |
| 07:46 | dbsx | I can remember rabeeh posting a dd command for replacing uboot, I cant remember where I saw it though |
| 07:49 | jnettlet | ok yep, put the sdhc card in your box and get the root device, not the partition. So /dev/sdc or /dev/mmcblk0 you can see that in dmesg |
| 07:50 | jnettlet | the use sudo dd if=/path/to/u-boot.imx of=/dev/devicefound bs=512 seek=2 conv=fsync |
| 07:50 | jnettlet | Then move the sdhc card back to the cubox-i, power it on and hopefully we will get some debug output to the serial console |
| 07:51 | dbsx | ok . fsync rather sync? |
| 07:53 | jnettlet | dbsx, yeah fsync is the linux variant |
| 07:58 | dbsx | dd if=u-boot.imx of=/dev/mmcblk0 bs=512 seek=2 conv=fsync |
| 07:59 | dbsx | can get to uboot. no front led, nothing happens other than red light at optical plug |
| 08:00 | dbsx | using a SR transcend SD |
| 08:05 | dbsx | I just needed to wait a few minutes for console output to appear |
| 08:05 | dbsx | http://pastebin.com/VayQzGar |
| 08:16 | jnettlet | looking |
| 08:24 | dbsx | jnettlet: tried a few more times. Sometimes it stops very early, like at "Reserving ..." |
| 08:25 | jnettlet | dbsx, but it never boots all the way up with this u-boot? |
| 08:27 | dbsx | no, with the original uboot I got as far as loading kernel once. It stops at random place (if I can trust the console output) |
| 08:28 | jnettlet | dbsx, okay lets try something crazy. let me give you the original ddr timings we had for that board. Just to see if there is any difference. |
| 08:28 | dbsx | See http://pastebin.com/4KTAzKtZ for another boot |
| 08:28 | dbsx | ok |
| 08:29 | jnettlet | you can download the new image from the same URL |
| 08:29 | dbsx | ok, doing it. Give 10 mins |
| 08:35 | dbsx | Stops @ "new stack pointer is:", no HDMI output |
| 08:37 | jnettlet | okay one more thing I want to try. |
| 08:37 | dbsx | hmm |
| 08:39 | jnettlet | okay another image there to try |
| 08:39 | jnettle | 08:39 * jnettlet looks to check errata and upstream patches |
| 08:45 | dbsx | 4 power ons and nothing happens. 5th power on I get as far as "fec_mii_setspeed: mii_speed 0000000a", then stops |
| 08:46 | dbsx | 6th boot outputs the first 5 lines only |
| 08:49 | dbsx | The good news is that I am getting very skilled at extracting and inserting micro SDs |
| 08:50 | jnettlet | dbsx, this is nothing compared to when I was doing the u-boot 2013 bringup for the board :-) |
| 08:51 | jnettle | 08:51 * jnettlet is looking. |
| 08:53 | dbsx | making coffee, back shortly |
| 08:55 | jnettle | 08:55 * jnettlet thinks more coffee is a fine idea |
| 09:11 | dbsx | verified that my input voltage is 5.17V rock steady (meanwell) 3A |
| 10:08 | jnettlet | dbsx, still around. I want you to try another build if you have time. |
| 10:17 | dbsx | ok |
| 10:17 | dbsx | let me know when ready |
| 10:20 | jnettlet | dbsx, all ready for download |
| 10:20 | dbsx | ok |
| 10:26 | dbsx | better, first shot got to the uboot prompt. Then froze. Have not been able to repeat it (yet) |
| 10:27 | jnettlet | not been able to repeat getting to the uboot prompt and freezing, or not even getting to the uboot prompt? |
| 10:27 | jnettlet | s/been/being/ |
| 10:29 | dbsx | not getting to the uboot prompt. freezes up at random points. I can paste the log that got to the prompt if you want it |
| 10:29 | jnettlet | sure |
| 10:30 | jnettlet | rabeeh, ping |
| 10:32 | dbsx | jn http://pastebin.com/ckxd3tak |
| 10:40 | dbsx | jn, I think getting to the prompt was just good luck. Can't do it again |
| 10:47 | dbsx | jn: BTW most times nothing at all shows on the console at POR |
| 10:47 | jnettlet | dbsx, can you try unplugging you device and letting it set for 5 minutes and then attempt to boot it up. Perhaps the difference between that first successful boot and the others was a "cooldown" period |
| 10:49 | dbsx | will do |
| 10:55 | dbsx | disconnected evrything and tried it. Nothing showed on the console |
| 10:57 | jnettle | 10:57 * jnettlet raises eyebrow in confusion |
| 10:57 | hste | dbsx: could it be a bad power adapter? |
| 11:00 | dbsx | The power adapter is very stable (meanwell) 5V/3A . I have tried 2 others which are also known to be good. Output is a stable 5.17 volt. 2.1/5.5/(11) |
| 11:03 | dbsx | jnettlet: The only thing I have established is that the device (sometimes) loads uboot (db frowns) |
| 11:03 | jnettlet | dbsx, and you have tested other sdhc cards right? |
| 11:04 | dbsx | Yes. I can try another if you like. I am currently using a 4GB transcend from SR which accompanied the i4pro |
| 11:05 | jnettlet | dbsx, try another just to verify the behavior doesn't change |
| 11:06 | dbsx | ok |
| 11:06 | jnettlet | I am looking into how early I can get serial output out of uboot |
| 11:12 | rabeeh | damn it; my internet connection is loose today |
| 11:12 | jnettlet | rabeeh, figured something like that. |
| 11:13 | jnettlet | rabeeh, dbsx is having some u-boot issues on his i4pro. It is hanging at various places. |
| 11:13 | rabeeh | i'v noticed that |
| 11:13 | rabeeh | in his dump is running c1 u-boot ? |
| 11:14 | rabeeh | i can see that from the prompt |
| 11:15 | jnettlet | rabeeh, he is just using my c1 config, but it is compiled for the i4pro |
| 11:15 | jnettlet | I just noticed your patches didn't include the new config file for the cubox-i |
| 11:19 | Wizzup | jnettlet: so if a news item says there is some support for the carrier-one in mainline,this does not apply to cubox? |
| 11:19 | Wizzup | cubox-i |
| 11:20 | jnettlet | Wizzup, they will apply to the cubox-i |
| 11:21 | jnettlet | depending on the model you will need a new device-tree file. U-boot is different because it needs to setup the different types of DDR |
| 11:22 | Wizzup | cool, and @ dt, makes sense |
| 11:22 | jnettlet | Wizzup, if I remember correctly you only care about the non-media portions of the board. |
| 11:23 | Wizzup | yep |
| 11:23 | Wizzup | sata,eth,usb,microsd mostly |
| 11:23 | jnettlet | then you should be fine. |
| 11:23 | Wizzup | (well, O know i1 has no sata) |
| 11:23 | Wizzup | ty |
| 11:33 | dbsx | So uboot gets loaded from the second 1M on the SD ? true/false |
| 11:34 | jnettlet | dbsx, 1K |
| 11:35 | jnettlet | the blocksize is 512 bytes and we seek in 2 |
| 11:35 | dbsx | aha |
| 11:36 | jnettlet | you can also do bs=1K seek=1 |
| 11:37 | dbsx | prepping a new 8GB card |
| 11:39 | jnettlet | as long as you start your first partition on sector 2048 you should be fine. |
| 11:39 | jnettlet | basically GPT style is safest. |
| 11:56 | dbsx | so now we have tried 3 different SDs transcend, sandisk and ultima with the same result |
| 12:01 | dbsx | giving up for a while |
| 12:03 | jnettlet | dbsx, okay that rules that out then. |
| 12:06 | hste | jnettlet: how is it going with vpu and xbmc? |
| 12:06 | jnettlet | hste, I haven't had any time to look at it yet. |
| 12:07 | dbsx | jnettlet: Do you know of anyone(including rabeeh) that can boot an i4pro? |
| 12:08 | jnettlet | dbsx, rabeeh has done a lot of testing with u-boot on the i4pro |
| 12:09 | jnettlet | it is possible you got a bad DDR3 chip. |
| 12:11 | dbsx | yes, somethings certainly different. I'm off to watch a video on a Cubox (XBMC) |
| 12:20 | _rmk_ | jnettlet: just been looking at the composite stuff in my xorg driver again, with reference to the imx-drm docs. |
| 12:21 | _rmk_ | err, imx docs |
| 12:21 | _rmk_ | interesting that the imx docs suggest that it can do ROP and alpha-blend together |
| 12:22 | _rmk_ | whereas the library headers talk about "Enable alpha blending engine in the hardware and disengage the ROP engine." |
| 12:23 | _rmk_ | I think I trust the headers on this one :) |
| 12:23 | jnettlet | _rmk_, in all the docs I have read that is the case |
| 12:25 | _rmk_ | I've also been trying to trace some of the X servers CPU usage... hardly surprising where it ends up despite trying not to bounce bos between the CPU and GPU... |
| 12:26 | _rmk_ | one case which really hurts at the moment is this: |
| 12:26 | _rmk_ | 4.251665537: vivante_set_pixmap_bo: 0xb72000a0, 1920x1080 fmt 211 type |
| 12:26 | _rmk_ | 2 |
| 12:26 | _rmk_ | (new pixmap 1920x1080 allocated) |
| 12:26 | _rmk_ | 4.251741515: vivante_PolyFillRect: D0xb7200190 G0xb6f990e0 n1 |
| 12:26 | _rmk_ | 4.251783863: vivante_map_gpu: 0xb72000a0 -> GPU |
| 12:27 | _rmk_ | (gets mapped to GPU for the fill) |
| 12:27 | _rmk_ | 4.376975417: vivante_fill: disable alpha blend |
| 12:27 | _rmk_ | ^^^ see how long that took... |
| 12:27 | jnettlet | wow |
| 12:28 | jnettlet | why is that taking so long? |
| 12:28 | _rmk_ | that's what I'm trying to track down |
| 12:30 | jnettlet | that is just translated into gckOS_MapUserMemory in the kernel |
| 12:30 | _rmk_ | a good test for this is merely to start up gnome... one of the things it does very shortly after X "looks" initialised is it fades out the existing background while fading in the new background (which is the same!) and it hits this pretty badly |
| 12:30 | _rmk | 12:30 * _rmk_ blames the gnomes for that |
| 12:31 | _rmk_ | yea, and gckOS_MapUserMemory() translates into flush_dcache_page() for each and every page |
| 12:31 | _rmk_ | (inside get_user_pages()) |
| 12:32 | _rmk_ | I need to check that we're not doing something stupid like double-flushing (with flush_dcache_page + flush_anon_page being together) |
| 12:33 | _rmk_ | either way, 120ms is far tooooooo long |
| 12:34 | _rmk_ | I can probably get around this by passing them via dma_buf instead but I need to make sure that nothing horrid can happen with the cpu cache |
| 12:36 | _rmk_ | btw, the timing measurements are made via clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) so they're unaffected by other processes |
| 12:40 | rabeeh | dbsx: i'm a bit lost. did you try the image on the getting started link |
| 12:40 | rabeeh | the email i'v got from you shows 'data abort' ! |
| 12:40 | rabeeh | as if something really bad happened. |
| 12:41 | jnettlet | rabeeh, he was first using that image when we started debugging yes. |
| 12:42 | jnettlet | _rmk_, might be worth checking if you are getting caught up trying to get a Mutex or Semaphore lock in gckOS_MapUserMemory. |
| 12:43 | jnettlet | A lot of my performance increases have been reducing lock contention |
| 12:44 | jnettlet | If you enable gcdDETECT_TIMEOUT it should give you some useful info |
| 12:44 | _rmk_ | yea, my view of vivante's approach to locking is they seem to like covering code with lots of locks "just in case" without really thinking about it |
| 12:44 | jnettle | 12:44 * jnettlet has to go out the dogs are starting an uprising as their walk is quite late. |
| 12:44 | _rmk_ | jnettlet: you need self-walking dogs |
| 12:45 | hste | jnettlet: what sort of dogs do u got? |
| 12:45 | jnettlet | _rmk_, I grew up with those, but society seems to afraid to deal with it at this point |
| 12:45 | _rmk_ | jnettlet: or maybe you can get that confused.com robot to walk them for you :) |
| 12:45 | jnettlet | hste, mutts. Italian Greyhound/Dauschund mix, and a Lab, Husky, Basset Hound mix |
| 12:46 | hste | :) I have a terrier/chiuaua mix |
| 12:46 | jnettlet | ultimately the dog walking is good for me. Gets me out of the house and away from the computer for a while. |
| 12:46 | _rmk_ | true |
| 12:47 | jnettlet | hste: https://lh3.googleusercontent.com/-M85y_TSrBxg/Uk2vpID4EnI/AAAAAAAAFSY/RZqnFKHPArk/w1081-h811-no/IMG_20131003_193307.jpg |
| 12:49 | jnettlet | _rmk_, let me know what you find out. After I finish getting the VPU working I was going to finish porting your newest drm patchset to my 3.10 tree and test that. |
| 13:22 | dbsx | I used the image on the getting started link |
| 14:03 | _rmk | CPU -> GPU pixmap bouncing (which the i915 driver could also do with) |
| 15:06 | taz | hi |
| 15:06 | taz | hi rabeeh ! :) |
| 15:06 | taz | rabeeh: did you recievied my postal card ? |
| 15:13 | jnettlet | _rmk_, any luck with the long mapping time? |
| 15:13 | _rmk_ | jnettlet: not yet, I've already dealt with the locking there |
| 15:14 | _rmk_ | I've changed ChangeWindowAttributes so it doesn't cause unnecessary GPU->CPU fallbacks which gets rid of one source bouncing |
| 15:16 | _rmk_ | the other places which bounce stuff back and forth is the compositing stuff, particularly with glyphs - I can get rid of some of that by caching glyphs in a much larger pixmap (thereby avoiding the silly cost of lots of small pixmaps) which should help glyph stuff but its still going to bounce stuff because the final composite needs component alpha and the vivante gpu can't do that |
| 16:21 | rabeeh | taz: hey - we have got the post :) |
| 16:21 | rabeeh | Riki got the card 2 weeks ago and then she told me someone sent love letter to SolidRun and then I explained to her all about you. |
| 16:21 | rabeeh | Thank you a lot for it. |
| 16:26 | taz | hey cool! :) |
| 16:27 | taz | see you |
| 16:31 | jnettlet | "A love letter to SolidRun"...bwahahaha...how cute. |
| 16:35 | jnettlet | _rmk_, what has always angered me about that part of the RENDER extension, is that RENDER is supposed to be based on the Porter-Duff rendering method which most 2d compositing engines are written to support. Then they add crap like component alpha rending, which virtually no hardware supports and even with opengl you end up doing multiple passes. |
| 16:36 | jnettlet | And all that to just render text. |
| 16:37 | jnettlet | I guess the other option would be to do what Android does, which is almost nothing and just wait for a 1080p resolution on a 5" screen, so you don't need subpixel rendering :-) |
| 17:33 | ssvb | jnettlet: it's more like the other way around - the hardware vendors had enough time to design the hardware, which can fully support RENDER extension |
| 17:34 | jnettlet | ssvb, why on earth would the hardware vendors create hardware around an Xorg only feature? |
| 17:34 | ssvb | jnettlet: component alpha is used for subpixel antialiased fonts |
| 17:35 | ssvb | jnettlet: because Xorg is used by a certain percent of their users? |
| 17:35 | jnettlet | hahahaha |
| 17:36 | Coolgeek | jnettlet: you forgot that : "hahaha" |
| 17:36 | jnettlet | I love Linux and have been developing for Xorg for years, and we are not even close to 1% of any graphics makers users |
| 17:37 | jnettlet | Linux userbase is Servers, and embedded. Embedded does not use Xorg |
| 17:37 | ssvb | jnettlet: well, it's up to the hardware vendors to release the joke of "accelerated" X drivers, make clowns out of themselves and be squashed by mere software rendering ;) |
| 17:39 | jnettlet | How do they make clowns of themselves? All drivers need to start somewhere. |
| 17:40 | jnettlet | Really Xorg is the problem, and the solution has been to dump 2d rendering altogether like in Wayland and Android and only use the 3d engine because GLESv2 is a standard that you can expect hardware vendors to adhere to. |
| 17:41 | jnettlet | If you say RENDER is based on the PorterDuffy standard and the hardware vendors don't support it you can complain. If you start doing your own thing, then it is your problem. |
| 17:42 | jnettlet | That has always been the hardest part of developing in the Xorg community. The developers always whining about how hardware vendors are idiots and their way is best. Their attitudes have been part of why most hardware vendors have not wanted anything to do with helping out. |
| 17:43 | ssvb | jnettlet: Xorg supports GLESv2 just fine, wayland would have been a better solution if it could utilize the fixed function 2D hardware acceleration engines |
| 17:43 | ssvb | jnettlet: I mean utilize them better than Xorg |
| 17:44 | jnettlet | ssvb, Xorg supports GLESv2 through glamour, which someone made work. |
| 17:44 | jnettlet | Xorg itself didn't even bend to accommodate some of the problems the developers came across |
| 17:45 | ssvb | jnettlet: you got it backwards, glamor actually implements RENDER on top of GL, that's a compatibility layer |
| 17:45 | ssvb | jnettlet: the GL/GLES drivers themselves have nothing to do with glamor |
| 17:46 | jnettlet | ssvb, first GL has nothing to do with any of this. Xorg has nothing to do with GLES support. All of this is supported through the drivers. |
| 17:47 | ssvb | jnettlet: yes, and your question is? |
| 17:47 | jnettlet | glamor allows the DDX driver to accelerate the RENDER extension via GLESv2 hardware |
| 17:48 | ssvb | jnettlet: please define "accelerate". Is it making things faster? Or just forcing the pixels to pass through GPU no matter the cost? |
| 17:49 | jnettlet | give me a break. I don't have time for your trolling. |
| 17:51 | ssvb | jnettlet: lol, a good try evading the most important question :) |
| 17:52 | ssvb | jnettlet: and btw, afaik PorterDuff is not a standard, that's just an old paper |
| 17:53 | ssvb | jnettlet: the real standard is something like SVG specification |
| 19:29 | Matoking | Updated my i2Ultra order to i4Pro :P |
| 19:58 | Bluerise | rabeeh? |
| 20:41 | jnettlet | dv, do you know if the gst-plugins 3.5.7 for fsl need any patches to work properly. The linking seems to be a complete mess. |
| 20:53 | jnettlet | _rmk_, does your /proc/cpuinfo have anything for Revision: after booting from device-tree? |
| 20:56 | _rmk_ | Revision : 0000 |
| 20:58 | jnettlet | yep, I think I need to add something to u-boot to get that to report back. Stupid userspace libs parse that for library loading and such. |
| 20:59 | jnettle | 20:59 * jnettlet wonders if it can just be added to device-tree |
| 21:01 | hste | jnettlet: we had sth on that on gk802 https://github.com/imx6-dongle/uboot-imx6dongle/commit/30b74222a02c673814798271bd7f1b829919b485 |
| 21:02 | jnettlet | hste, yeah that is what I was looking at doing. But then I would need to return different values for the different boards. Will make things a little more annoying for SPL |
| 21:02 | jnettle | 21:02 * jnettlet would be happier to just something to device-tree |
| 21:04 | jnettlet | nope looks like it just reads the value for the atags |
| 21:05 | jnettlet | :-( |
| 21:17 | jnettlet | hste, I have CONFIG_REVISION_TAG set which in the new u-boot should be autogenerating that tag. |
| 21:20 | hste | jnettlet: more on this here https://community.freescale.com/thread/305396 |
| 21:20 | hste | CPU id is 0x62 in mainline u-boot, but in vpu lib, it still detects 0x63 or 0x61 |
| 21:21 | jnettlet | hste, ah that is the patch I needed. thanks |
| 21:24 | jnettlet | hste, oh man that thread is awful. They are trying to fix this in three different places. Obviously that hasn't happened. |
| 21:25 | jnettle | 21:25 * jnettlet is going to add a device-tree parser for this then. If freescale can't get it together in u-boot/kernel/userspace libraries |
| 21:26 | jnettlet | _rmk_, Any input ^^^ |
| 21:33 | rabeeh | Bluerise: here |
| 21:34 | Bluerise | rabeeh: I see that for example C1 Solo and Quad differ in the RAM settings. Can that be auto configured or does it have to be u-boot-blob-specific? |
| 21:34 | Bluerise | We were wondering how to integrate 8 different u-boots, and it might just be easier to let the user do that... |
| 21:47 | _rmk_ | jnettlet: what are they trying to do with this? |
| 21:47 | _rmk_ | detect the SoC type? |
| 21:48 | _rmk_ | it it something that /sys/devices/soc0/soc_id doesn't provide? |
| 21:49 | rabeeh | i have a funny story to tell; Bluerise: yes it's possible; this is SPL support that will be added in some time |
| 21:50 | Bluerise | Funny story? |
| 21:50 | rabeeh | oh; |
| 21:50 | rabeeh | two different windows |
| 21:50 | Bluerise | I'm always interested in stories. Even more in funny ones. ;) |
| 21:50 | rabeeh | sorry; i'm having a nervous breakdown |
| 21:51 | rabeeh | oh; the funny story is that when the operations guy comes to the office then the firewall (brand name) reboots |
| 21:51 | Bluerise | Oh, that breakdown doesn't sound good. |
| 21:51 | rabeeh | turns out that he connects via wireless and when clicking 'Get mail' on thunderbird the router reboots |
| 21:51 | Bluerise | wow |
| 21:51 | rabeeh | hehe... i just lost it for few minutes; broke something and i'm fine now :) |
| 21:51 | rabeeh | Bluerise; and the firewall is a brand brand name :) |
| 21:52 | Bluerise | If it's from the company I work for (as student currently), let me know. ;) |
| 21:52 | rabeeh | i wonder how this could happen... at the beginning i though i was dreaming then i'v asked him to wait; i watched that LEDs on the power / status of the firewall and asked him to get mail |
| 21:52 | rabeeh | and boom... :) |
| 21:52 | Bluerise | But ours doesn't do that... |
| 21:52 | Bluerise | nice |
| 21:52 | Bluerise | There are some possibilities... |
| 21:52 | rabeeh | it's probably the wifi firmware fault |
| 21:53 | Bluerise | hmm |
| 21:53 | rabeeh | they tend to be crappy. |
| 21:53 | rabeeh | what do you think? |
| 21:53 | Bluerise | it sounds possible |
| 21:53 | Bluerise | probably not a software bug (the OS that is running, deep packet inspection or so) |
| 21:53 | Bluerise | Could be the WiFi, yeah. |
| 21:54 | Bluerise | On a rather unrelated note: I remember having seen a talk about "packets in packets" |
| 21:55 | Bluerise | someone was transmitting data over some radio protocol |
| 21:55 | Bluerise | the data he sent was basically also that radio protocol |
| 21:55 | Bluerise | sometimes the radio had hiccups and didn't see the header of the actual packet, so it in the end treated the data as packet |
| 21:56 | Bluerise | rabeeh: You could try to send the same packet via ethernet |
| 21:56 | Bluerise | the only problem is that the mac addresses won't match |
| 21:57 | Bluerise | so it's not 100% the same.. |
| 21:58 | rabeeh | wired works fine |
| 21:59 | Bluerise | rabeeh: Does i.MX6 sd-card DMA need something special? I think I saw some co-processor which needed its own firmware? |
| 21:59 | Bluerise | gotta check the RM |
| 22:47 | jnettlet | _rmk_, well they are using a hex id to indentify the board revision. I guess we could rewrite the userpace to use soc_id instead. |
| 22:48 | jnettlet | my guess is some of their binary blobs may do the same checks. |