DOS partition trouble

What is the magic to make a DOS partition on a uSD card acceptable to the X booter (ROM code)? Does it have to be the first partition? Bootable? FAT type? Certain size? I can’t seem to make a partition with fdisk on linux that the ROM code will accept. I thought maybe it didn’t like FAT32 but FreeBSD boots happily from a FAT 32 partition. FAT 12 doesn’t even work although Debian boots fine from FAT 12. I can’t see what is different between what linux fdisk makes and the bootable Debian or FreeBSD partitions.

Specifically, which TI device are you talking about? FAT isn't even a
requirement anymore.. (depending on the TI device)

Regards,

FAT, and FAT32 both work fine. Something else is your problem.

Sorry. I am using Beaglebone Black. I saw that (no FAT) on the BBB page at eewiki.net and was puzzled.

Well, zeroing the first sector and creating the partition table seems to have fixed the problem but it is frustrating not knowing what the problem was. Thanks for the help.

Well, zeroing the first sector and creating the partition table seems to have fixed the problem but it is frustrating not knowing what the problem was. Thanks for the help.

So look at it like this. What happens when in code one attempts to read a string in C out of memory, where the string is of unknown size, and the string has no null termination ?

Segfault. What has that got to do with the ROM not recognizing a partition table?

Everything... The boot ROM is pretty basic..if you have noise/etc anywhere
where the bootrom expects "something"... (it's normally looking for a
short header)

Well, the bootrom can get lost pretty easily..

As long as you:

1: /dev/zero the first 1MB of the drive
2: create your partition table ignoring the first 1MB
3: dd the MLO/u-boot.img into the first 1MB

You can have pretty much 'any' rootfs format that u-boot supports...

Regards,

Segfault. What has that got to do with the ROM not recognizing a partition table?

What Robert said above, but also not necessarily segfault. It’s undefined behavior, as in no one can say what will happen, until it happens. There is a very good chance it’ll segfault, but there is a chance said code could seem to work fine, or even fail silently. I’ve seen all three cases personally.

So we have no idea how the OP’s media was cleared, when attempting to put the first, and second stage bootloaders on that media. But it seems to be clear that the MBR contained trash from a previous partition table. Or simply just trash.

Oh, and if you’re really creative, you can actually take that “trash” in the MBR, and make it jump to a specific location in memory . . . before the OS even loads. Hopefully, we all understand what that means :wink:

Agreed, but this was a working uSD that I ran fdisk on. It mounted fine on a linux box but the ROM didn’t recognize it. I can’t imagine the ROM code is doing anything with LSN 0 other than reading the partition table. Zeroing it and then entering the same numbers with fdisk worked. I still find that puzzling. And a bit scary.

Carl

You seriously think the ROM is trying to execute x86 code out of LSN 0???

Carl

It doesn't know it's x86... :wink: It tries to excute whatever it see's..

There was a very cool talk at 32nd Chaos Communication Congress this year:

https://media.ccc.de/c/32c3

Where in the middle, they took a jpg and ran it thru the 8051 de-compiler
and got good 8051 assembly...

https://media.ccc.de/v/32c3-7189-key-logger_video_mouse

Regards,

I was actually thinking of one of the black hat videos I saw last year, where they discussed bypassing CPU privileged mode prior to the OS loading. But the concept is the same. But who says the instructions would have to be x86 ? They don’t have to be.

Personally, I find it a bit scary that when partitioning / formatting media that has been used for something else prior. Not zeroing out the MBR before hand. You do realize that without dd, and /dev/zero, the only other tool that completely wipes out MBR exploits was DOS’s fdisk ? Which stopped shipping after Win95. That includes Linux fdisk, and other tools.

But the original point I was getting to. An old MBR can, or will interfere with MLO / u-boot.img when using a FAT partition, and when loading MLO / u-boot.img from the MBR, unless there is magically a NULL character right after 512K, there is no telling what will be attempted to be loaded into memory. THAT buddy, is scary.

I think the real person to talk to about all this would be DR. Phil Polstra - As this is his forte. And I know he’s done at least one set of video’s concerning exploiting Windows, Linux, and ARM Linux. I think on pluralsite, but I’d have to look again.

The BBB ROM code does not try to execute anything in LSN 0, so whether any non-partition table bytes are x86 or random garbage is moot. Good luck trying to modify the ROM code so that it did.