freebsd / crochet

Build FreeBSD images for RaspberryPi, BeagleBone, PandaBoard, and others.
BSD 2-Clause "Simplified" License
612 stars 188 forks source link

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

Closed HarryWeppner closed 10 years ago

HarryWeppner commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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/kientzle/crochet-freebsd/issues/29#issuecomment-33831359 .

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

HarryWeppner commented 10 years ago

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

Cheerio, Harry.

teverett commented 10 years ago

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/kientzle/crochet-freebsd/issues/29#issuecomment-33834557 .

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

pauldokas commented 10 years ago

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: https://github.com/kientzle/crochet-freebsd/issues/29

Paul Dokas dokas at dokas.name

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

teverett commented 10 years ago

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: https://github.com/kientzle/crochet-freebsd/issues/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/kientzle/crochet-freebsd/issues/29#issuecomment-33882406 .

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

kientzle commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

https://github.com/teverett/crochet-freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f

HarryWeppner commented 10 years ago

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

teverett commented 10 years ago

Any feedback? Can we close this?

HarryWeppner commented 10 years ago

sorry, didn't get around to testing yet but will report back soon. It's on my list for today ;-)

HarryWeppner commented 10 years ago

Nice work - booted right to a login prompt!

I only encountered one minor issue along the way as the setup.sh script was looking for arm/wandboard-quad.dts. However, in 11-current the file exists in /usr/src/sys/boot/fdt/dts/wandboard-quad.dts, i.e. there is no arm subdirectory.

Thanks for following up on this issue so quickly!

Cheerio, Harry.

diff --git a/board/Wandboard/setup.sh b/board/Wandboard/setup.sh
index 4a7638a..97f8c3e 100644
--- a/board/Wandboard/setup.sh
+++ b/board/Wandboard/setup.sh
@@ -74,8 +74,8 @@ strategy_add $PHASE_BOOT_INSTALL wandboard_install_uenvtxt
 #
 wandboard_install_dts_fat(){
     echo "Installing DTS to FAT"
-    freebsd_install_fdt arm/wandboard-quad.dts wandboard-quad.dts
-    freebsd_install_fdt arm/wandboard-quad.dts wandboard-quad.dtb
+    freebsd_install_fdt wandboard-quad.dts wandboard-quad.dts
+    freebsd_install_fdt wandboard-quad.dts wandboard-quad.dtb
 }
 #strategy_add $PHASE_BOOT_INSTALL wandboard_install_dts_fat

@@ -84,8 +84,8 @@ wandboard_install_dts_fat(){
 #
 wandboard_install_dts_ufs(){
     echo "Installing DTS to UFS"
-    freebsd_install_fdt arm/wandboard-quad.dts boot/kernel/wandboard-quad.dts
-    freebsd_install_fdt arm/wandboard-quad.dts boot/kernel/wandboard-quad.dtb
+    freebsd_install_fdt wandboard-quad.dts boot/kernel/wandboard-quad.dts
+    freebsd_install_fdt wandboard-quad.dts boot/kernel/wandboard-quad.dtb
 }
 strategy_add $PHASE_FREEBSD_BOARD_POST_INSTALL wandboard_install_dts_ufs
teverett commented 10 years ago

Are you on the very latest source tree? On Mar 2, 2014 11:30 PM, "Harry Weppner" notifications@github.com wrote:

Nice work - booted right to a login prompt!

I only encountered one minor issue along the way as the setup.sh script was looking for arm/wandboard-quad.dts. However, in 11-current the file exists in /usr/src/sys/boot/fdt/dts/wandboard-quad.dts, i.e. there is no arm subdirectory.

Thanks for following up on this issue so quickly!

Cheerio, Harry.

diff --git a/board/Wandboard/setup.sh b/board/Wandboard/setup.sh index 4a7638a..97f8c3e 100644 --- a/board/Wandboard/setup.sh +++ b/board/Wandboard/setup.sh @@ -74,8 +74,8 @@ strategy_add $PHASE_BOOT_INSTALL wandboard_install_uenvtxt # wandboard_install_dts_fat(){ echo "Installing DTS to FAT"

  • freebsd_install_fdt arm/wandboard-quad.dts wandboard-quad.dts
  • freebsd_install_fdt arm/wandboard-quad.dts wandboard-quad.dtb
  • freebsd_install_fdt wandboard-quad.dts wandboard-quad.dts
  • freebsd_install_fdt wandboard-quad.dts wandboard-quad.dtb }

    strategy_add $PHASE_BOOT_INSTALL wandboard_install_dts_fat

@@ -84,8 +84,8 @@ wandboard_install_dts_fat(){ # wandboard_install_dts_ufs(){ echo "Installing DTS to UFS"

  • freebsd_install_fdt arm/wandboard-quad.dts boot/kernel/wandboard-quad.dts
  • freebsd_install_fdt arm/wandboard-quad.dts boot/kernel/wandboard-quad.dtb
  • freebsd_install_fdt wandboard-quad.dts boot/kernel/wandboard-quad.dts
  • freebsd_install_fdt wandboard-quad.dts boot/kernel/wandboard-quad.dtb } strategy_add $PHASE_FREEBSD_BOARD_POST_INSTALL wandboard_install_dts_ufs

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

HarryWeppner commented 10 years ago

Yes, pretty much – 11-current as of git commit 509a9db.

Cheerio, Harry.

teverett commented 10 years ago

I"m confused. On the tip of 11 I see this file system:

http://svnweb.freebsd.org/base/head/sys/boot/fdt/dts/arm/

so, the wandboard dts files are at /sys/boot/fdt/dts/arm/

HarryWeppner commented 10 years ago

The file system structure had just changed with http://svnweb.freebsd.org/base?view=revision&revision=262614, which I hadn't pulled from the git repo yet. My patch is not needed in that case.

Thanks & cheerio, Harry.

teverett commented 10 years ago

can we close this then?

HarryWeppner commented 10 years ago

@teverett, yes we can ;-)

Cheerio, Harry.