**** BEGIN LOGGING AT Fri May 19 03:00:02 2017 May 19 08:56:59 clear May 19 08:57:07 oops ! sorry ! May 19 18:07:28 If I'm using a different toolchain for my kernel than the one that my current uboot image was compiled with, does it need to be recompiled with the same toolchain as the kernel? May 19 18:09:38 generally, no May 19 18:11:41 Hm. Ok, thanks. It's just hanging when it gets around to loading the kernel, but it's good to know that's likely not why. May 19 18:13:42 all the bootloader does is load the 2-3 blobs into memory; setup a small table; load registers and jump to entry point May 19 18:13:48 so unless it is broq... May 19 18:18:08 Is there a verbose setting by chance? May 19 18:19:09 not really May 19 18:19:18 what do you see? (use pastebin if it is more then a few lines) May 19 18:25:08 http://termbin.com/s5zz May 19 18:26:53 It seems to be just looping. And it's kinda slow. Don't know if that's normal or what. May 19 18:29:47 kernel is crashing May 19 18:29:57 and crashing very early on May 19 18:30:19 unless u-boot is giving the kernel a bad DTB, it shouldn't be an issue on the u-boot end May 19 18:32:07 Maybe because I compiled it with musl... May 19 18:32:26 maybe there's an inconsistency between the DTB version you're using the kernel version you're using? May 19 18:32:34 i have no idea May 19 18:39:49 shpew12: Try to get a working setup, and then narrow down what causes the problem. If you have a working toolchain+kernel+dtb combination, you should be able to determine which change causes the problem. May 19 18:41:05 yah, I was going to try again with the kernel from a working image and see how that goes. May 19 18:42:07 shpew12: be sure to pass the right console= to the kernel May 19 18:42:41 or actually: May 19 18:42:42 8607208 bytes read in 474 reading /dtbs/am335x-boneblack.dtb May 19 18:43:06 ehhhh May 19 18:43:42 corrupt serial output? May 19 18:44:16 also, why are you using an u-boot from _2014_ ?! May 19 18:45:06 lol i gave him my old 2gb beaglebone May 19 18:45:21 and he didn't compile u-boot himself just ripped it off the factory image May 19 18:45:23 it's from the 2GB image May 19 18:45:50 but i think you should probably update that May 19 18:45:56 I mean. I could use the newer one. I just honestly didn't think about it... May 19 18:46:08 https://rcn-ee.com/repos/bootloader/am335x_boneblack/ May 19 18:46:16 those are precompiled ones May 19 18:46:56 oh sweet! May 19 18:47:04 or if you want to build from source, clone mainline u-boot and apply appropriate patch set -> https://rcn-ee.com/repos/git/u-boot-patches/ May 19 18:47:18 whats the difference between the MLO and the u-boot prefix? May 19 18:47:26 you need both May 19 18:47:38 ah May 19 18:48:38 dd if=MLO-$version of=$device seek=256 && dd if=u-boot-$version.img of=$device seek=768 May 19 18:51:12 MLO is what bootrom loads into internal SRAM and executes May 19 18:52:07 in case of u-boot that contains its SPL (secondary program loader), which is basically a stripped-down u-boot whose purpose is just to setup the DDR3 memory, load the u-boot.img there and transfer control to it May 19 18:52:40 gosh i knew it.. it's just embedded somewhere on the device May 19 18:52:44 it's not even a proper file May 19 18:52:56 the reason for this two-step process is of course because u-boot is too fatso to fit in internal SRAM May 19 18:53:44 bootrom actually checks 4 fixed locations for a special header, and as fallback looks for a file on a FAT boot partition May 19 18:55:30 the README of my baremetal asm demo contains more details on the options bootrom offers for loading the initial program -> https://github.com/mvduin/bbb-asm-demo May 19 18:57:30 beware that the "MLO" file produced by current u-boot is somewhat mislabeled since it actually includes 512 bytes in front of it which contains the "configuration header" May 19 18:58:15 (which, on am335x, is only relevant for raw mmc/sd boot) May 19 19:04:34 so if you use that dd command, you have to be careful about where you set up your partition, is what i take from this May 19 19:04:53 so your first actual filesystem has to be 768bytes + sizeof(u-boot*.img) into the sd card May 19 19:05:19 i'm assuming $device is the SD card May 19 19:05:56 and that i guess this is a raw mmc/sd boot? but maybe its time to skim over zmatt's github link May 19 19:07:37 768 sectors May 19 19:08:45 the default for fdisk is to just 1MB alignment of partitions anyway May 19 19:09:09 for eMMC it is probably a good idea to use 4MB alignment (the allocation group size) May 19 19:10:22 * ayjay_t gives thumbsup May 19 19:10:47 this is also the default of the current debian images for bbb **** ENDING LOGGING AT Sat May 20 03:00:02 2017