| 15:44 | rabeeh | _rmk_: ping |
| 15:46 | _rmk_ | hmm? |
| 15:58 | rabeeh | _rmk_: wanted to consult with regards LDO bypass |
| 15:58 | rabeeh | in the production version we will be doing LDO bypass on part of the micro soms |
| 15:59 | rabeeh | i'm worried on how to get the information passed on to u-boot and the kernel |
| 15:59 | rabeeh | for instance how do i tell that this version of the microsom uses ldo bypass and this one doesn't? |
| 16:00 | rabeeh | i can blow some fuses for this; the question if you have a better idea on top of your mind |
| 16:01 | _rmk | 16:01 * _rmk_ digs up info on the LDO bypass mode... |
| 16:03 | rabeeh | inside the imx6 there are LDOs for the processor, vpu, etc... |
| 16:04 | _rmk_ | yea, so basically the kernel will need to know to control an external regulator to do dvfs? |
| 16:05 | _rmk_ | I assume it's that angle that you're considering? |
| 16:15 | rabeeh | _rmk_: there is no control; either it's ldo bypass or not |
| 16:15 | rabeeh | the voltage externally is fixed |
| 16:16 | rabeeh | i'm just asking whats the best thing to pass this information to the kernel; to do ldo bypass or not |
| 16:16 | rabeeh | for instance on the samples c1 board ldo must not be bypassed since the external voltage is 1.5v and requires ldo to downgrade that |
| 16:17 | rabeeh | but if the kernel mistakenly enables ldo bypass then it will kill the die since 1.5v now drives the processor (instead of 1.25v on 1ghz) |
| 16:21 | _rmk_ | yea... so setting it by mistake would be destructive. does the kernel touch that bit at all - I suspect it doesn't... |
| 16:22 | rabeeh | today no |
| 16:22 | rabeeh | it doesn't touch |
| 16:22 | rabeeh | ldo bypass is generally enabled with the freescale external pmic (pfuze in the kernel) |
| 16:23 | rabeeh | so; one option is to auto detect via a fuse that we can blow in the production line |
| 16:23 | jas-hacks | any thermal benefits with ldo bypass? |
| 16:23 | rabeeh | another option is to get it via command line |
| 16:23 | rabeeh | jas-hacks: yes |
| 16:24 | rabeeh | you don't have an ldo; so you are not wasting energy on the most critical component in the system; the die itself :) |
| 16:24 | jas-hacks | have you tested with it? |
| 16:24 | hste | I guess command line option will not be bulletproof |
| 16:25 | rabeeh | hste: i agree |
| 16:25 | rabeeh | besides that we move the "detection" problem to u-boot |
| 16:26 | _rmk_ | one problem here is whatever we do, it'll be specific to the cubox-i/carrier-1 |
| 16:26 | dv | 16:26 * dv_ wonders why all common hw video en/decoder apis like vaapi and vdpau are slice-based |
| 16:26 | _rmk_ | for passing this from uboot to the kernel, it should be something in the DT.. but the problem there is we haven't got to the point where DT gets provided to the kernel separately, so there's massive potential for errors. |
| 16:27 | _rmk_ | dv: because that's what hardware requires, and its only brain dead closed source which take stupid approaches with requiring the elementary stream because they want to protect their IP... |
| 16:28 | rabeeh | _rmk_: another alternative is just we set the standard fuse bit / map that tells the kernel you can ldo bypass. |
| 16:28 | dv_ | _rmk_: in other words, if the VPU firmware were open source, we could refactor everything to be based on va-api |
| 16:28 | dv_ | rabeeh: didnt you want to talk to freescale about this? |
| 16:29 | rabeeh | not the vpu firmware; the tools only |
| 16:29 | dv_ | yeah, the tools and spec for the BIT processor |
| 16:29 | rabeeh | i doubt that they will open the firmware (i.e. codecs) itself |
| 16:30 | dv_ | otavio: what do you think are the chances of this getting greenlighted? |
| 16:30 | hste | is it possible to set some headers high on production board and let that be the way to detect it? |
| 16:31 | rabeeh | hste: it's possible to blow some fuses |
| 16:31 | rabeeh | i have 64bit of those :) |
| 16:32 | _rmk_ | dv: from what I understand of vmeta, it appears that it takes the elementary stream, and then the libcodecvmetadec library manually asks the hardware to read bits from the stream to read the headers and such like, which it stores into memory. When it wants to decode, it writes the "metadata" into registers in the vmeta hardware and tells vmeta to run a decode on the slice data. |
| 16:33 | _rmk_ | dv: I've toyed with the idea of working out its workspace, and poking the state information directly into there so it doesn't have to read it from the stream |
| 16:33 | _rmk_ | but that's getting too far into the "reverse engineering" of it which isn't permissible |
| 16:35 | dv_ | clean-room reverse engineering isnt permissible? |
| 16:42 | _rmk_ | rabeeh: so there's an official fuse for "you may use LDO bypass" ? |
| 16:45 | rabeeh | _rmk_: there isn't |
| 16:45 | rabeeh | i'm searching back again for other hint |
| 16:49 | rabeeh | nop; there aren't |
| 16:50 | rabeeh | there are general purpose fuses (64bit) that we can do whatever with them |
| 16:51 | _rmk_ | well, this problem won't be specific to just the c1/cubox-i, so I think sending an email to Shawn Guo would be sensible explaining the problem and asking the question: I'd hate to suggest something if there's already some other solution to this problem already |
| 16:52 | _rmk_ | [email protected] if you don't have his address to hand |
| 17:00 | jnettlet | rabeeh, somewhere I have seen a patch for u-boot that does ldo bypass detection. |
| 17:01 | jnettlet | ah found it. It was actually removed from fsl's u-boot tree and moved into the kernel. |
| 17:06 | rabeeh | jnettlet: which one? |
| 17:06 | rabeeh | it's probably pfuze related? |
| 17:07 | hste | ENGR00276023-3: ARM: mx6: enable ldo bypass check on mx6 board |
| 17:10 | jnettlet | rabeeh, looks like it is all straight up device-tree related. I haven't found any detection. |
| 17:12 | jnettlet | rabeeh, here is a doc on Freescale's community site regarding Android. https://community.freescale.com/docs/DOC-94033 |
| 17:13 | jnettlet | it seems like something with this much potential hardware destruction should probably have a standardized fuse to check |
| 17:33 | rabeeh | jnettlet: i'v sent email to Shawn upon rmk's recommendation; lets see what he has to say |
| 17:34 | rabeeh | if there is no conclusion then i think we will just add a pattern or a bit in the general purpose fuse and accordingly decide to ldo enable or bypass |
| 18:47 | jnettlet | rabeeh, sounds right to me. |
| 18:48 | jnettlet | since there are so many ways to override/replace device-tree's, having something permanent on the hardware that can be checked makes me feel a bit more secure. |
| 18:50 | _rmk_ | jnettlet: and how do you expect this to be used by the kernel? via board support code specific to the cubox-i? that's the problem - doing it via fuses is going to be specific to the c1/cubox-i... |
| 18:51 | jnettlet | not if the fuse specified is part of the device-tree |
| 18:53 | jnettle | 18:53 * jnettlet is thinking. default is with ldo bypass disabled. It can be enabled via device-tree but a fuse must be specified that can be checked to verify that is the case. |
| 18:54 | jnettlet | or checked that the hardware does support it. |
| 18:54 | jnettlet | or a flag that specifies no-fuse in which case the hardware manufacturer can deal with the consequences. |
| 18:57 | jnettlet | if someone wants to be malicious then it would be very easy to bypass these checks in the kernel. I just want something that keeps most hobbyist, newbs, etc from shooting themselves in the foot and killing their hardware. |
| 18:59 | _rmk_ | so what happens if someone boots with the wrong device tree, and it finds the fuse indicating that LDO bypass can be used? |
| 19:02 | jnettlet | the fuse from the wrong device-tree matches with another random burned fuse on the board? |
| 19:03 | jnettlet | they will blow up their board. but without a manufacturer spec there isn't much that can be done about that. |
| 19:03 | jnettlet | manufacturer meaning Freescale not Solidrun |
| 19:04 | jnettlet | I guess going nuts, we could require checks in both u-boot and the kernel. Then you would really need to mismatch a lot. |
| 19:05 | jnettlet | I guess most would do this in u-boot as it would sit on an eeprom or nand and not get tinkered with much. |
| 19:54 | purch | crap, second usb-ttl cable with 5V output |
| 20:33 | rabeeh | purch: double out |
| 20:38 | purch | what? |
| 20:38 | rabeeh | s/out/ouch |
| 20:39 | rabeeh | 5v would kill the io pad |
| 20:39 | purch | voltage meter rocks |
| 20:39 | purch | the third should do it: http://www.fasttech.com/product/1208102 |
| 20:44 | rabeeh | _rmk_ / jnettlet: in case i have a special pull up or pull down on the board to indicate with ldo bypass or without; how would that map into device tree? |
| 20:44 | rabeeh | it would be also microsom specific |
| 21:00 | jnettlet | rabeeh, not 100%sure. maybe a property of the soc. |
| 22:02 | svere | anyone also got ** ext2fs_devread() read error ** with uboot trying to load uImage from an ext2 partition? |
| 22:08 | jas-hacks_ | svere: only tried a ext4 partition and it was ok |
| 22:08 | svere | jas-hacks_: i now tried ext2, ext4 and vfat |
| 22:09 | svere | nothing works. uboot can not read the fs |
| 22:09 | svere | C1 U-Boot > fatload mmc 0:1 0x10800000 /uImage |
| 22:09 | svere | reading /uImage |
| 22:09 | svere | Error reading cluster |
| 22:09 | jas-hacks_ | this worked for me ext2load mmc 0:1 0x10800000 /boot/uImage |
| 22:10 | svere | jas-hacks_: i get |
| 22:10 | svere | C1 U-Boot > ext2load mmc 0:1 0x10800000 /uImage |
| 22:10 | svere | ** ext2fs_devread() read error ** |
| 22:10 | svere | ** File not found /uImage ** |
| 22:10 | svere | its with rabeeh's uboot image |
| 22:11 | jas-hacks_ | try the one from here http://stende.no-ip.info/jas/c1/ |
| 22:12 | jas-hacks_ | its jnettlet's uboot |
| 22:13 | svere | jas-hacks_: umm there is not uboot!?!? |
| 22:14 | jas-hacks_ | ah sorry ... instructions here http://imx.solid-run.com/wiki/index.php?title=Building_Carrier-One_U-boot_and_Kernel |
| 22:15 | jas-hacks_ | build "U-Boot Upstream" |
| 22:15 | svere | jas-hacks_: yeah i just thought i can avoid building a crosscompile toolchain |
| 22:16 | hste | svere: where did u start the partition? |
| 22:16 | svere | fdisk -l /dev/sdb: /dev/sdb1 * 2048 3854335 1926144 83 Linux |
| 22:18 | jas-hacks_ | svere: upload a uboot for you 'u-boot.imx' |
| 22:19 | svere | jas-hacks_: thx |
| 22:19 | jas-hacks_ | dd if=u-boot.imx bs=1k seek=1 of=/dev/XXX |
| 22:20 | svere | ok, i used dd if=u-boot.imx of=/dev/sdb bs=512 seek=2 but that should be equivalent |
| 22:20 | jas-hacks_ | yes |
| 22:20 | jas-hacks_ | it should also display to hdmi |
| 22:21 | svere | jas-hacks_: its sitting here on my table with only uart connected |
| 22:21 | svere | s/its/it's/ |
| 22:22 | svere | jas-hacks_: did you upload uboot to the same location |
| 22:22 | svere | ? |
| 22:23 | hste | svere: do u have the uImage on / or /boot ? |
| 22:23 | jas-hacks_ | its there now |
| 22:23 | jas-hacks_ | http://stende.no-ip.info/jas/c1/u-boot.imx |
| 22:23 | svere | hste: i tried both. currently i only put uImage to / |
| 22:25 | svere | testing... |
| 22:31 | svere | ** No partition table - mmc 0 ** |
| 22:31 | svere | Wrong Image Format for bootm command |
| 22:31 | svere | ERROR: can't get kernel image! |
| 22:32 | svere | C1 U-Boot > ext2ls mmc 0:1 / |
| 22:32 | svere | ** No partition table - mmc 0 ** |
| 22:32 | svere | maybe it's the sd-card |
| 22:33 | svere | but it is perfectly readable on the pc |
| 22:33 | svere | partition found, mountable all files there.... |
| 22:33 | jas-hacks_ | what do mmc show |
| 22:34 | rabeeh | svere: which model of sd-card you have? |
| 22:34 | svere | C1 U-Boot > mmc list |
| 22:34 | svere | FSL_SDHC: 0 |
| 22:34 | svere | rabeeh: sandisk 2gb |
| 22:35 | rabeeh | svere: i have similar 2gb class 4 and works perfectly fine |
| 22:35 | jas-hacks_ | what partition is 0:1 ? |
| 22:36 | svere | rabeeh: this one worked fine in the openmoko freerunner... :-( |
| 22:36 | svere | jas-hacks_: i made it ext4 |
| 22:37 | jas-hacks_ | what about 'mmc rescan' |
| 22:38 | svere | jas-hacks_: it changed things... but not for good: |
| 22:38 | svere | C1 U-Boot > mmc rescan |
| 22:38 | svere | C1 U-Boot > mmc list |
| 22:38 | svere | FSL_SDHC: 0 |
| 22:39 | svere | C1 U-Boot > ext2ls mmc 0:1 / |
| 22:39 | svere | ** ext4fs_devread read error - block |
| 22:39 | svere | Failed to mount ext2 filesystem... |
| 22:39 | svere | ** Unrecognized filesystem type ** |
| 22:39 | hste | try put the card into pc and run fsck on it |
| 22:40 | dv_ | sometimes you need to reboot |
| 22:40 | dv_ | a few days ago my microsd card was recognized every 2nd time |
| 22:44 | svere | dv_: hmmm no luck |
| 22:44 | svere | but should: |
| 22:44 | svere | MMC: FSL_SDHC: 0 |
| 22:44 | svere | *** Warning - bad CRC, using default environment |
| 22:45 | svere | tell me something |
| 22:45 | svere | ? |
| 22:45 | dv_ | have a look at it with ext2ls |
| 22:45 | hste | try format with ext4 and put boot.scr and uImage on /boot |
| 22:45 | hste | from the jas location |
| 22:45 | dv_ | sometimes there is a problem with the partition name in the environment |
| 22:46 | jas-hacks_ | "*** Warning - bad CRC, using default environment" thats ok |
| 22:47 | svere | dv: |
| 22:47 | svere | C1 U-Boot > ext2ls mmc 0:1 / |
| 22:47 | svere | ** No partition table - mmc 0 ** |
| 22:48 | jas-hacks_ | It looks like when you 'dd' you over wrote the partition info on the sd card. |
| 22:48 | jas-hacks_ | After you 'dd' can re-insert the sd card into a pc and check the partition is there |
| 22:49 | jas-hacks_ | /s/can/can you |
| 22:50 | svere | jas-hacks_: i don't think partition table is damages because |
| 22:50 | svere | 1) i fdisk'ed the sd after dd'ing uboot |
| 22:51 | svere | 2) if i insert the sd-card into pc i can read the partition table and mount /dev/sdb1 perfectly |
| 22:51 | svere | all files there and everything |
| 22:55 | svere | i guess i will try another sd-card tomorrow |
| 22:55 | svere | thanks for your help guys |
| 23:04 | svere | I tried an 512MB transcend and it works perfectly |
| 23:04 | svere | i can boot the kernel |
| 23:05 | rabeeh | svere: lets follow up on this tomorrow to see what's wrong with it :) |
| 23:05 | rabeeh | hardware wise; the fact that imx6 was able to boot from the micro sd means it's supported from the imx6 bootrom point of view |
| 23:05 | rabeeh | the rest is probably some u-boot error or something else |
| 23:09 | svere | rabeeh: i also have another 4gb sandisk floating around somewhere here on the table |
| 23:10 | svere | maybe i can also check this one |
| 23:13 | svere | have a good night |