| 06:31 | tthtlc | hi |
| 06:32 | tthtlc | i am playing with hummingboard running android |
| 06:33 | tthtlc | problem is when it connect my serial uart....on my HDMI screen showing the bootup, it seemed uart was never detected and no messages ever go to the uart....is this true? |
| 09:11 | topi` | jnettlet: I'm trying to compile uboot from your tree (in github, and the imx6 branch) but does it contain hummingboard support? I only saw support files for cubox-i there... |
| 09:11 | topi` | maybe I'm looking at the wrong directory |
| 09:14 | topi` | it seems my native compiler is incapable of compiling UBOOT: |
| 09:14 | topi` | ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not |
| 09:15 | topi` | (my host is a Tegra K1 board (armhf) with hard float ABI) |
| 09:16 | topi` | it's a pretty decent compile box - the kernel takes 7 minutes to compile :) |
| 09:20 | jnettlet | topi`, we have a unified u-boot architecture. One install of SPL/u-boot.img will boot all our microsom based hardware |
| 09:25 | jnettlet | topi`, you can try setting CFLAGS for -mfpu=vfpv3 to see if that helps |
| 09:26 | jnettlet | also don't pass make -j args as it doesn't build if you are using multiple threads. |
| 09:27 | cbxbiker61 | pretty sure you have to use libs/compiler doing soft float for u-boot |
| 09:38 | jnettlet | cbxbiker61, nope it is all self contained. I compile against a hard-float cross-compiler. |
| 09:38 | jnettlet | it is all about how you tell the compiler to build u-boot |
| 09:39 | jnettlet | but like the core kernel there is no floating point code in the project so hard vs soft float really doesn't matter |
| 10:54 | topi` | jnettlet: is the "build-all.sh" your script? |
| 10:54 | topi` | it's doing some setup and doing make -j8 |
| 10:54 | jnettlet | topi`, nope rabeeh's |
| 10:55 | topi` | ok :) so rabeeh is responsible for the uboot? |
| 10:55 | topi` | I got it from github.com/linux4kix/uboot, is that right? |
| 10:56 | jnettlet | that is my personal repo and should not be used for production. |
| 10:56 | topi` | ok, what then? :) |
| 10:56 | jnettlet | The official github repo. https://github.com/SolidRun/ |
| 10:56 | topi` | ok |
| 10:56 | topi` | oh, there's even a 3.14 kernel nowadays under SolidRun |
| 10:57 | jnettlet | yes. the workflow is generally into my repo for testers/devs then once proven tested over to SolidRun |
| 10:57 | topi` | what's the difference between cubox-i and Hummingboard Pro? |
| 10:57 | jnettlet | form factor, some connectors. |
| 10:58 | topi` | so the .dtb files might be different? |
| 10:58 | jnettlet | the HB is a development board, while the CBi is more a consumer product |
| 10:58 | jnettlet | the .dtb files are different, but our u-boot auto-detects the platform and will load the proper .dtb |
| 10:59 | topi` | ok |
| 10:59 | jnettlet | if you write your own custom script it is up to you to do. |
| 10:59 | topi` | so I can just compile the uboot with "mx6_cubox-i4pro"? |
| 11:00 | jnettlet | actually those are all old you don't want to do that at all. |
| 11:00 | jnettlet | just use mx6_cubox-i that is the universal build |
| 11:00 | topi` | OK |
| 11:01 | jnettlet | the others are legacy before we sorted out universal boot |
| 12:53 | topi` | jnettlet: now I can boot the GPT partitioned system manually! |
| 12:54 | topi` | if I somehow could change "mmcpart" variable from 1 to 2 then it'd be automatic |
| 12:54 | topi` | is this something inherited from UBOOT? I guess it's a convention to use partition 1 to find zImage and stuff |
| 12:55 | topi` | but I have "protective MBR partition" (type 0xee) as my 1st partition so that Linux GPT code recognises it as a protective/hybrid |
| 12:59 | jnettlet | I was wondering if that was the case |
| 12:59 | jnettlet | we can patch the default initscript to walk the first two partitions if that will help. |
| 13:00 | jnettlet | I would have to check to see how much work it is to test against the partition type in uboot scripting |
| 17:21 | topi` | jnettlet: the partition type, as in filesystem? |
| 17:21 | topi` | when I format /boot to ext2, it works just fine with UBOOT load commands |
| 17:21 | topi` | or do you mean the partition type byte in MBR? |
| 17:22 | topi` | it's 0x0c for a LBA FAT32 partition (which I'm using) and 0xee for a "Protected MBR" that GPT partitioning puts there |
| 17:23 | topi` | actually, for my purposes, I can just use partition 1, and forget about Protected MBR (if I find a way to make gdisk not to complain about it) |
| 17:24 | jnettlet | ah you are using 0x0c so we can't rely on that to know if we should check the second partition. |
| 17:24 | jnettlet | ultimately checking the next partition will only add another 0.3seconds to the SPL boot stage |
| 17:26 | topi` | yes |
| 17:26 | topi` | the SPL is already taking too much time to load UBOOT |
| 17:26 | topi` | i'll try a 1-partition MBR layout, to see if it poses any problems for the partitioning tools |
| 17:28 | jnettlet | topi`, if you are worried about speed then you should look into using directboot |
| 17:28 | jnettlet | but you have to use msdos for your first partition |
| 17:29 | jnettlet | ext2 drivers are too big. |
| 17:30 | jnettlet | basically SPL loads the zImage and .dtb from the first partition if it is msdos and then boots right into the kernel |
| 17:33 | topi` | yeah ext2 is bloated, at least compared to the simplicity that is FAT16 :) |
| 17:34 | topi` | it might also be possible to use msdos for the first partition; I found out that writes to /dev/loop1 are not reflected in the underlying file for a *long* time (possibly 60 seconds) |
| 17:34 | topi` | I don't know why but this explains why my msdos partition was corrupted after the script finished |
| 17:36 | topi` | one good property of msdos filesystem is that you don't need to fill the *whole* partition, so the file (being dd'ed) can be sparse |
| 17:37 | topi` | and I've planned that in production, we don't manipulate partitions, but instead overwrite entire partitions with binary data (that has been tested before release) |
| 17:37 | jnettlet | topi`, even if you call sync after the write? |
| 17:37 | topi` | jnettlet: I do an unmount after the write, which should equal to a sync |
| 17:38 | topi` | but maybe it doesn't hold true with msdos, since it seems to work with ext2 |
| 17:38 | topi` | anyhow, loop devices behave a little bit oddly |
| 18:31 | topi` | jnettlet: wasn't a good idea, now that there's no partition type 0xEE in MBR, linux kernel thinks there's no GPT! |
| 18:31 | topi` | grrrr.. |
| 18:31 | topi` | unless... I could force the kernel with the "gpt" kernel param |
| 18:35 | topi` | YES! success. |
| 18:35 | jnettlet | topi`, can you put the protective partition after /boot |
| 18:36 | jnettlet | keep it physically first on the drive, but make it the second partition |
| 18:37 | topi` | hmm, good idea, I shall try that out |
| 18:37 | jnettlet | I have no idea if that will work. It is just a thought |
| 18:37 | topi` | I'll tell you shortly :) |