08:16 <pivi> NishanthMenon: I really want to send you one of our board, so you get a little bit of diversity there! I should probably stop expecting our PM to take care of it and do it myself ...

08:18 <pivi> NishanthMenon: how meta-ti-upstream is supposed to be different from meta-ti? I mean, you (_ti_) is the upstream for meta-ti.

08:18 <pivi> NishanthMenon: ah, well. you are tracking linux-next now there.

08:20 <pivi> NishanthMenon: if I get this correctly (from some commit messages and the fact that you use linux-next) this layer is mostly for integration testing, not supposed to be used in production.

12:03 <NishanthMenon> Yup

12:04 <NishanthMenon> pivi: hence trying to beat the heck out of next.. I am hope k.ci will get a good testing framework and dashboard to eventually get to this.

12:35 <mripard> NishanthMenon: we've had AM625 boards (SK-AM62 and BeaglePlay) and it looks like they require a specific disk geometry for the BootROM to read the bootloader from a FAT partition

12:36 <mripard> however, someone got a new Beagleplay (with the same stepping) that seems to work fine for any geometry

12:36 <mripard> is there any documentation on what the bootrom expects somewhere?

12:41 <javierm> NishanthMenon: to add more details, the Fedora images are generated using a loopback device and the first partition vfat fs geometry is '63 sectors/track, 16 heads'

12:42 <javierm> NishanthMenon: if we dd that image to a SD card, mripard, eballetbo and me found that our boards don't boot but works for another colleague

12:43 <javierm> formatting using a '32 sectors/track, 64 heads' geometry makes my Beagleplay to boot, but mripard also had to change the partition type from 0x6 (FAT 16) to 0xc (FAT 32 LBA)

12:44 <javierm> NishanthMenon: in my case 0x6 worked with the mentioned geometry. It would great to know what is the actual expection of the bootrom

12:45 <NishanthMenon> Driving to work. Will check message in 30 mins

12:46 <javierm> NishanthMenon: sure, no rush. Thanks!

13:11 <NishanthMenon> Bootrom had some weird fat handling as I recollect.. ended up on fat16

13:11 <NishanthMenon> Let me dig up a conversation on it

13:12 <NishanthMenon> https://github.com/nmenon/k3-upstream-boot-build/pull/11

13:13 <NishanthMenon> Will try to reach people on fat32 observation

13:14 <mripard> thanks

13:14 <mripard> the geometry (32 sectors/track, 64 heads) has also been super important for us

13:14 <mripard> the most important factor actually

13:16 <mripard> it probably doesn't affect your Makefile target because parted will read the default disk geometry, but when preparing an image and then dd'ing the whole image to the SD card, it plays a role

18:03 <bryanb> if i remember correctly the number of blocks was an issue

18:03 <bryanb> https://lists.openembedded.org/g/openembedded-core/message/180298

18:23 <bryanb> we needed the number of blocks to match the count in the partition