DOS partition trouble

[geekg...@gmail.com]

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.

[Robert Nelson]

On Mon, Apr 11, 2016 at 6:24 PM, <geekg...@gmail.com> wrote:

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,

--

Robert Nelson
https://rcn-ee.com/

[William Hermans]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[geekg...@gmail.com]

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

[geekg...@gmail.com]

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.

On Monday, April 11, 2016 at 8:53:54 PM UTC-4, RobertCNelson wrote:

[William Hermans]

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 ?

--

[Carl Krieder]

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

On Tue, Apr 12, 2016 at 11:53 AM, William Hermans <yyr...@gmail.com> wrote:

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 ?

On Tue, Apr 12, 2016 at 7:16 AM, <geekg...@gmail.com> wrote:

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.

On Monday, April 11, 2016 at 8:53:54 PM UTC-4, RobertCNelson wrote:

On Mon, Apr 11, 2016 at 6:24 PM, <geekg...@gmail.com> wrote:

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,

--

Robert Nelson
https://rcn-ee.com/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/VkEDlXayFB8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

On Tue, Apr 12, 2016 at 11:41 AM, Carl Krieder <geekg...@gmail.com> wrote:

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,

[William Hermans]

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.

--

[William Hermans]

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 ;)

[Carl Krieder]

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 received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/VkEDlXayFB8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Carl Krieder]

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

Carl

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/VkEDlXayFB8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

On Tue, Apr 12, 2016 at 2:30 PM, Carl Krieder <geekg...@gmail.com> wrote:

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

It doesn't know it's x86... ;)  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,

[William Hermans]

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.

--

[William Hermans]

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.

[William Hermans]

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.

[Carl Krieder]

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.

--

For more options, visit http://beagleboard.org/discuss
---