**** BEGIN LOGGING AT Wed Oct 12 02:59:57 2022 Oct 12 13:56:03 whelp, I think the am3358 doesn't actually mean that it doesn't care what's in your MBR as long as your partitons are listed. Resorted to dd'ing from a know good mbr to get my MLO and u-boot working off FAT Oct 12 13:57:15 kongn: it definitely doesn't care what's in your mbr, unless your mbr somehow looks like a valid configuration header for direct (non-FAT) mmc boot Oct 12 13:58:22 I have tried every which way all the while purging my post-512 bytes data so no TOC or raw MLO could be detected. Oct 12 13:59:04 example of a known-good way to make a bootable sd card for the am335x (this is just using a tiny demo program as MLO but it obviously works the same when the MLO is u-boot SPL): https://github.com/mvduin/bbb-asm-demo#example-fat-partitioned Oct 12 13:59:25 the only thing that matters is that the partition is marked as bootable Oct 12 14:01:33 I don't think that would work when your bytes 0-460 are 0 Oct 12 14:01:42 it does Oct 12 14:02:10 bootrom does not care about those bytes except to see if it's a configuration header for raw mmc boot Oct 12 14:02:10 then maybe it's an interaction with the sd card being MLC.. lemme test right now. Oct 12 14:02:34 the type of NAND cell an sd card uses is irrelevant and invisible Oct 12 14:03:59 would the following commands be suitable? echo 248,131072,0x0C,* \n 133120,+,0x83,- to sfdisk? Oct 12 14:04:09 *2048 Oct 12 14:05:16 I'm not particularly familiar with the syntax of sfdisk, but if that means a bootable fat partition followed by a non-bootable linux partition then sure Oct 12 14:12:17 Yup, no luck, hexdump shows all 0's before 0x1b0 and after 0x200 till 0x100000. Oct 12 14:16:06 lemme compare the good one vs this one. Oct 12 14:20:11 Yup, when I write in the first 80 bytes of the good mbr sector to the bad one, the bad one loads from FAT. Oct 12 14:20:52 what's in those bytes? Oct 12 14:21:37 no clue, but probably headers on how to read the raw sectors as that good card has a RAW MLO at 0x20000 Oct 12 14:22:31 https://pastebin.com/SATKcfgR Oct 12 14:23:08 this looks like garbage bytes to me, or maybe a bootloader for x86 systems Oct 12 14:24:15 raw mmc boot does not require anything in any sectors other than the configuration header that immediately precedes the MLO, and is located at sector 0, 256, 512, or 768 Oct 12 14:25:41 I was trying to avoind raw mmc as this is for simplicity/ will be moving u-boot to spi flash for production. Maybe the empty spi flash was interfering with mmc boot from fat Oct 12 14:27:48 raw mmc boot is simpler and more reliable than using a fat partition, and it will also more closely resemble your final configuration where you won't have any reason to have a fat partition at all Oct 12 14:30:06 Well, this is why I should have been on here earlier instead of banging my head against a wall after making packaging scripts and running into this mbr issue. Oct 12 14:31:06 Thank you for the pointer. Oct 12 14:36:45 kongn: hmm, I just tested it and I can't get the FAT partitioned example to work anymore, while the raw mmc boot one works fine Oct 12 14:38:11 Yea, I do see how the raw would be easier, but I do think with the u-boot modifications still needing to be done, I'll use the "magicalMBR.img" Oct 12 14:40:13 that part still makes absolutely zero sense to me whatsoever, I really have no idea what could be going on there Oct 12 14:41:10 I'm also quite sure the procedure I documented was tested to work when I wrote it... so I don't know why it no longer does Oct 12 14:42:06 I did see there was a change in sfdisk functionality across some version Oct 12 14:42:33 the yocto scripts change flags across version 2.26.2 Oct 12 14:46:46 I just also tried using plain fdisk Oct 12 14:47:27 maybe there's something particular about the partition table itself? I really don't think the early bytes are relevant Oct 12 14:50:20 yea, just tested again, and my magical mbr is not working again... Oct 12 14:50:27 lol Oct 12 14:58:53 ok now I have it booting from FAT, so wtf is different Oct 12 14:59:35 this time I had a colleague FAT-format the card instead of doing it myself Oct 12 15:03:27 kongn: interestingly after they formatted it the mbr also had those bytes, but wiping those bytes has no effect, it still boots just fine Oct 12 15:03:32 I'm 99% sure that's an x86 bootloader Oct 12 15:04:36 That makes sense, I'll look into mkfs.vfat flags. Oct 12 15:11:20 yeah it's somehow the formatting.. if I partition the card but let my colleague FAT-format using the GUI disks utility (instead of me doing it with mkfs.fat) then it works Oct 12 15:12:23 so it's not the partitioning Oct 12 15:16:13 Yup, windows format of the disk also allows it to work Oct 12 15:16:43 kongn: lol wtf, I compared the fat metadata between the two and the working one has "sectors/track 16, heads 4" while mkfs.fat produces "sectors/track 16, heads 4" Oct 12 15:17:10 mkfs.fat -g 4/16 fixed the issue for me Oct 12 15:17:31 sorry, mkfs.fat produced "sectors/track 61, heads 4" Oct 12 15:17:57 Great find! thank you! will test. Oct 12 15:20:46 Yup, bash script working. Thank you Oct 12 15:21:51 you're welcome! and see, obscure nonsense like this is exactly why it's a good idea to avoid using a FAT boot partition ;) Oct 12 15:22:15 I wonder if the 61/16 is just a mistype in mkfs source. 61 doesn't sound like a valid size Oct 12 15:22:20 haha Oct 12 15:22:41 I don't think so, based on the manpage it uses quite a magic algorithm to determine those parameters Oct 12 15:24:19 heh, I've been doing this testing with my old tiny demo program written in assembly and y'know... it's kinda nice to see a program get loaded and running so fast that I can't visually see any delay between releasing the reset button and the program running ;) Oct 12 15:24:32 I mean sure, it does basically nothing, but still Oct 12 15:28:30 Yea, Uboot does boot quick, it's really nice compared to the bootup time we still need to trim from the linux system Oct 12 15:40:36 my tests didn't involve u-boot, u-boot is pretty slow Oct 12 15:40:52 like, it's not slow in absolute terms, but it is slow for what it does Oct 12 15:43:47 what were you testing? assembly code for the arm? Oct 12 15:44:11 ahh, I see now, what sort of demo test was it? Oct 12 15:45:36 a trivial one, it just toggles the leds when you press the S2 button Oct 12 15:46:03 there's absolutely no reason to do this in asm but someone was looking for an example of doing that Oct 12 15:47:15 it does demonstrate irq handling (since it uses an irq for the button-press) Oct 12 16:31:02 that sounds like a great demo. I can see how the setup time is minimal. Oct 12 16:38:55 yeah the initialization of that program is completely dwarfed by the (itself imperceptible) time it takes bootrom to load the program Oct 12 21:40:38 Set up beaglebone with jtag using ccs Oct 12 21:40:49 Is anybodya can help Oct 12 21:43:21 Hello **** ENDING LOGGING AT Thu Oct 13 02:59:57 2022