14:01 <Guest78> hi

14:02 <Guest78> is anyone here?

14:25 <Amgine[m]> 60-120 seconds.

21:02 <onio> I am trying to build u-boot v2017.01 to run on BeagleBoneBlack but when I run make I get error "arm-cortex_a8-linux-gnueabihf-gcc: error: unrecognized -march target: armv5"

21:03 <onio> Earlier today I was able to build u-boot version v2022.04 and copied both MLO and u-boot.img to the SD-Card but when I power on the board all I got was continuous output of CCCCCCCCC

21:03 <vagrantc> i know it usually has some patches relative to upstream, but it's been a while since i've looked

21:03 <zmatt> onio: ehh, armv5 is definitely wrong

21:03 <vagrantc> oh yeah, at least armv7

21:04 <zmatt> onio: if you're getting CCCC then bootrom doesn't understand the contents of your SD card and hasn't even loaded your MLO

21:06 <onio> I am not even sure where it is getting the -march target: armv5 from.

21:08 <zmatt> dunno either, but v2017.01 builds fine for me... or, well, the version with rcn's patches (i.e. the same as was used for official beagleboard.org images), dunno if mainline was any use back then

21:09 <vagrantc> definitely had mainline working as early as 2016.11 ... but i think even earlier

21:09 <onio> zmatt: did you just build v2017.01 now?

21:10 <zmatt> I think the armv5 error might be incompatibility between that very old u-boot and a very new gcc.... I don't see armv5 documented as possible value for -march= in the current gcc manpage

21:10 <vagrantc> u-boot 2013.10 i think...

21:10 <zmatt> https://patchwork.ozlabs.org/project/gcc/patch/5AFD58EB.70204@foss.arm.com/

21:12 <zmatt> and no I haven't compiled u-boot in a long time

21:14 <onio> is there a way to validate the MLO image that was built when I used u-boot v2022.04?

21:14 <zmatt> anyway, as for your other problem... bootrom looks for MLO in two different ways: it first tries to find a "configuration header" in sector 0, 256, 512, and 768 ... if found, it expects the MLO to start at the next sector. if it finds it in none of these locations it will try to look for a file named "MLO" on a FAT partition, but iirc it is a bit fussy about some details, I don't quite remember since ...

21:14 <zmatt> ...nobody really uses this method anymore for a long time

21:16 <zmatt> iirc the MLO u-boot creates actually has this configuration header prepended, which I think might actually make it an invalid MLO file for the second method though I'm not sure... this is what it looks like if it has a configuration header: https://pastebin.com/2Nz3a9FF

21:17 <zmatt> typically configuration header + MLO is written to sector offset 256, u-boot.img to sector offset 768, and the first partition starts at sector 8192

21:18 <zmatt> I think for the method using a FAT partition, the partition needs to be marked as "bootable" in the partition table, and the MLO (and u-boot.img) need to be in the root of that filesystem. and if the MLO starts with a configuration header you should probably strip it off (i.e. remove the first 512 bytes)

21:20 <onio> this is what I get when I do hexdump on the MLO https://pastebin.com/ZCrR0dMH

21:22 <zmatt> yep so that has a configuration header

21:23 <zmatt> the stuff at offset 0x200 is the start of the *actual* MLO

21:24 <zmatt> hmm, that length seems rather large

21:26 <zmatt> the first two words of the real MLO (ignoring the configuration header) are the length and load address... the load address is always 0x402f0400, the length in your case is apparently 0x1a094 (107668 bytes)

21:26 <zmatt> which I think is _very_ close to the max

21:27 <zmatt> just over 105K, while the max allowed is 109K ... so I guess it technically still fits :P

21:27 <zmatt> I guess u-boot continues to get more and more bloated

21:27 <onio> https://imgur.com/a/ZSTW05X

21:31 <zmatt> yeah like I said, if you want to use the FAT partition method then you probably need to strip off the configuration header

21:31 <zmatt> there's probably some way to keep u-boot from prepending it in the first place, but I've never looked into how or why that happens

21:33 <zmatt> you can e.g. use head -c +513 MLO >MLO-without-ch and then put that file on the boot partition as "MLO"

21:35 <zmatt> any particular reason you're trying to build u-boot yourself instead of using a prebuilt one?

21:35 <onio> zmatt learning exercise

21:35 <zmatt> fair enough

21:36 <onio> going through the Mastering Embedded Linux Programming by Chris Simmond

21:36 <onio> book

21:36 <zmatt> books are tricky, they tend to get outdated fast

21:37 <onio> yes, that is what I been finding

21:39 <onio> head -c +513 MLO >MLO-without-ch I am not sure I understand this command. Is the "-without-ch" part of the command?

21:40 <zmatt> MLO-without-ch is the output filename here, just as example... overwriting the original MLO file with this command would not work

21:41 <zmatt> oh, also I meant tail, not head

21:42 <zmatt> alternatively dd if=MLO of=MLO-without-ch skip=1 will do basically the same

21:42 <zmatt> to create a version of the MLO with the configuration header stripped off

21:44 <onio> alright thanks, where can I learn about the MLO file structure?

21:45 <zmatt> MLO is just a raw binary with two 32-bit (little-endian) integers prepended: the length of the raw binary and the address to which it should be loaded (always 0x402f0400)

21:46 <zmatt> bootrom just loads the rest of the MLO (with given length) to that address and then execution simply jumps to it

21:48 <zmatt> unless you meant the structure of the configuration header (which isn't technically part of the MLO, even though u-boot's build process includes it in the file it calls "MLO"), which is presumably documented in the AM335x TRM... I'm pretty sure everyone just copy-pastes that fixed sequence of bytes without caring what it means ;)

21:49 <zmatt> ah, there ya go, the structure/meaning of the configuration header: https://github.com/mvduin/bbb-asm-demo/blob/master/extra/raw-mmc-header.txt

21:49 <onio> zmatt: cool thanks

21:49 <zmatt> that github repo is something I made a long time ago, an example of a tiny executable that gets directly loaded/executed by bootrom

21:52 <onio> Nice

21:55 <onio> zmatt: thanks for your time. I will have to continue tomorrow. I am worn out and brain dead as I a have been on this for over 12 hours

21:55 <zmatt> giving the brain a rest every now and then can be helpful too :)

21:56 <onio> yep, very very true

21:57 <onio> thanks once again

23:15 <set_> I am messing w/ that book too!

23:15 <set_> onio!

23:15 <set_> Me, me, me.

23:15 <set_> Dang. He/she left. Boo!

23:16 <set_> oh and what is the deal w/ uboot changing?

23:16 <set_> It is hard to find the right picks and tricks.

23:16 <set_> I know...w/ all kbuild envs, one can always use /.

23:17 <set_> But still. it used to be right there in my face for viewing. Now, i cannot find any of it, e.g. omap2_plus, where to place the .dtb and so on.

23:27 <set_> I read!

23:28 <set_> Something I learned today from watching IoTCon Europe 2020 was the kernel needs to be newer than the toolchain. Book it!

23:28 <set_> and to think I did not care or even know it was a fact.

23:31 <set_> check the dates!