[wandboard] Mounting from ufs:mmcsd0s2a failed with error 19

[HarryWeppner]

Hi,

first of all, thanks for developing such an elegant toolchain!

I am facing one issue when attempting to boot a Wandboard Quad as FreeBSD does not appear to recognize the SDcard as an mmc block device. The boot ends when attempting to mount the root filesystem:

Mounting from ufs:mmcsd0s2a failed with error 19.

Note that GEOM does not list any device at all.

The full console output shows that the uSDHC controllers are identified ok.

What's the best approach to troubleshoot this issue?

Thanks & cheerio, Harry.

[teverett]

Well congrats on getting that far. I ran into a weird bug booting my Quad, having this console output. I never got as far as setting up the disk mounts b/c I couldn't get my kernel to boot.

[HarryWeppner]

Is there anything connected to USB? On my side there are just an SDHC card, a null modem cable and an Ethernet cable connected to the Wandboard Quad.

The boot strategy appears to differ significantly compared to the Rasperry Pi. The Pi uses ubldr and attaches the kernel from the UFS partition whereas the Wandboard strategy is to loads and runs kernel.bin from the FAT partition without ubldr.

With loader out of the picture will need to figure out how to invoke the debugger pre-init.

Cheerio, Harry.

[teverett]

If you're willing to give me some pointers, I have no issue at all with
modifying it to use ubldr.

On Fri, Jan 31, 2014 at 11:59 AM, Harry Weppner notifications@github.comwrote:

Is there anything connected to USB? On my side there are just an SDHC
card, a null modem cable and an Ethernet cable connected to the Wandboard
Quad.

The boot strategy appears to differ significantly compared to the
https://github.com/kientzle/crochet-freebsd/tree/master/board/RaspberryPi/boothttp://Rasperry%20Pi.
The Pi uses ubldr and attaches the kernel from the UFS partition whereas
the Wandboard strategy is to loads and runs kernel.bin from the FAT
partition without ubldr.

With loader out of the picture will need to figure out how to invoke the
debugger pre-init.

Cheerio, Harry.

Reply to this email directly or view it on GitHubhttps://github.com//issues/29#issuecomment-33831359
.

A better world shall emerge based on faith and understanding - Douglas
MacArthur

[HarryWeppner]

Hi Tom, wouldn't the approach be similar to the Rasperry Pi?

Cheerio, Harry.

[teverett]

Perhaps yes. I had some trouble getting ubldr working on wandboard.
Sorry, I don't remember the specifics.

On Fri, Jan 31, 2014 at 12:34 PM, Harry Weppner notifications@github.comwrote:

Hi Tom, wouldn't the approach be similar to the Rasperry Pihttps://github.com/kientzle/crochet-freebsd/tree/master/board/RaspberryPi/boot
?

Cheerio, Harry.

Reply to this email directly or view it on GitHubhttps://github.com//issues/29#issuecomment-33834557
.

A better world shall emerge based on faith and understanding - Douglas
MacArthur

[pauldokas]

I ran into this same problem a couple of week ago. Searching through
freebsd-arm revealed a workaround. Put the following line into
/boot/loader.conf:

hw.bcm2835.sdhci.hs=0

I don't understand the problem, but I gather from the thread that the
Raspberry PI hardware has some quirks.

Paul

On 01/30/14 12:21, Harry Weppner wrote:

Hi,

first of all, thanks for developing such an elegant toolchain!

I am facing one issue when attempting to boot a Wandboard Quad as FreeBSD does not appear to recognize the SDcard as an mmc block device. The boot ends when attempting to mount the root filesystem:

Mounting from ufs:mmcsd0s2a failed with error 19.

Note that GEOM does not list any device at all.

The full console output shows that the uSDHC controllers are identified ok.

What's the best approach to troubleshoot this issue?

Thanks & cheerio, Harry.

---

Reply to this email directly or view it on GitHub:
#29

Paul Dokas dokas at dokas.name

Don Juan Matus: "an enigma wrapped in mystery wrapped in a tortilla."

[teverett]

I'll give that a try

On Sat, Feb 1, 2014 at 1:23 PM, Paul Dokas notifications@github.com wrote:

I ran into this same problem a couple of week ago. Searching through
freebsd-arm revealed a workaround. Put the following line into
/boot/loader.conf:

hw.bcm2835.sdhci.hs=0

I don't understand the problem, but I gather from the thread that the
Raspberry PI hardware has some quirks.

Paul

On 01/30/14 12:21, Harry Weppner wrote:

Hi,

first of all, thanks for developing such an elegant toolchain!

I am facing one issue when attempting to boot a Wandboard Quad as
FreeBSD does not appear to recognize the SDcard as an mmc block device. The
boot ends when attempting to mount the root filesystem:

Mounting from ufs:mmcsd0s2a failed with error 19.

Note that GEOM does not list any device at all.

The full console output shows that the
uSDHC controllers are identified ok.

What's the best approach to troubleshoot this issue?

Thanks & cheerio, Harry.

---

Reply to this email directly or view it on GitHub:
#29

Paul Dokas dokas at dokas.name

Don Juan Matus: "an enigma wrapped in mystery wrapped in a tortilla."

Reply to this email directly or view it on GitHubhttps://github.com//issues/29#issuecomment-33882406
.

A better world shall emerge based on faith and understanding - Douglas
MacArthur

[kientzle]

On Jan 31, 2014, at 10:59 AM, Harry Weppner notifications@github.com wrote:

Is there anything connected to USB? On my side there are just an SDHC card, a null modem cable and an Ethernet cable connected to the Wandboard Quad.

The boot strategy appears to differ significantly compared to the https://github.com/kientzle/crochet-freebsd/tree/master/board/RaspberryPi/boot. The Pi uses ubldr and attaches the kernel from the UFS partition whereas the Wandboard strategy is to loads and runs kernel.bin from the FAT partition without ubldr.

With loader out of the picture will need to figure out how to invoke the debugger pre-init.

To get ubldr working, you'll first need to be able to build a working U-Boot from source.

Once that works, you'll need to enable a couple of U-Boot features that are normally disabled:

* API support (this is how ubldr does all I/O, by invoking the U-Boot API0
* elf loader support (ubldr is an elf binary)

You'll need to fidget with the default boot script in U-Boot to properly load ubldr. You can look at the patches in Crochet for BeagleBone and RaspberryPi for ideas. For most boards, you may find Crochet's BeagleBone support to be a better example than RPi, as the RPi boot sequence has a few additional steps that most other boards lack.

You'll also, of course, need a build of ubldr that loads at a suitable address. What address works will depend on the boot-time memory map of the particular board. (A wish list item is a fully relocatable ubldr that can be loaded and run from any address. This will require experimenting with run-time ELF relocation.)

Tim

[teverett]

ok, I've got a working u-boot. I've also got API support, I believe and I know I have ELF support.

I've currently got ubldr compiling for address 0x10800000. So, I'm doing this in U-boot:

=> fatload mmc 0:1 10800000 ubldr
reading ubldr
253262 bytes read in 29 ms (8.3 MiB/s)
=> 
=> bootelf 10800000
## Starting application at 0x10800054 ...
## Application terminated, rc = 0xffffffff

Any idea where I'm going wrong?

[kientzle]

On Feb 17, 2014, at 5:13 PM, Tom Everett notifications@github.com wrote:

ok, I've got a working u-boot. I've also got API support, I believe and I know I have ELF support.

I've currently got ubldr compiling for address 0x10800000.

Do you know what addresses U-Boot is using?
You have to make sure ubldr isn't loading on top
of either U-Boot itself or U-Boot's data area.

So, I'm doing this in U-boot:

=> fatload mmc 0:1 10800000 ubldr

reading ubldr

253262 bytes read in 29 ms (8.3 MiB/s)

=>

=> bootelf 10800000

Starting application at 0x10800054 ...

Application terminated, rc = 0xffffffff

"Application terminated" is very strange. Normally,
a mis-compiled ubldr just crashes and the whole
board reboots.

It sounds as if U-Boot hasn't actually started ubldr,
which makes me wonder if that file isn't really
an ELF binary. Is it possible you've loaded the
wrong file?

U-Boot also has some (optional) commands to
edit memory; you might play with those and
see if that range of memory is really readable
and writable.

Beyond that, I can't suggest much. The only way
I was able to make real progress on BeagleBone
was to put together a short bit of assembly that
blinked the LEDs and insert that into U-Boot and
ubldr so I could figure out where things were
crashing. It was rather a tedious process...

Tim

[teverett]

Well at the very bottom of this wiki page http://wiki.wandboard.org/index.php/Boot-process it seems to suggest that uboot loads at 0x10800000, so maybe that is indeed the problem. I also double-checked and I didn't have API enabled, so I've updated all the patches to U-boot and I'll try again.

[teverett]

ok, after some hacking around, I have ubldr working, mostly. There is still some work to do, and some cleanup, but the basics are in place. Boot log is here: http://files.khubla.com/freebsd-wandboard/bootlog.txt.

Please excuse the spelling errors, and the bad typing in the log; I hadn't had coffee yet.

[teverett]

Ok, if anyone would like to take a look at the patch set before I submit a pull request, it's here:

teverett@f61660c

[HarryWeppner]

@teverett - awesome! Will give it a try in the next couple of days and report back here...

[teverett]

Any feedback? Can we close this?