Bad Linux ARM zImage magic

[mac...@msn.com]

Hi All,

I'm trying to build Debian, put it on an SD card and boot. I'm using the instructions from here http://eewiki.net/display/linuxonarm/BeagleBone .

I've come across a few differences between what is reported by u-boot during the boot process and variables set in uEnv.txt.

#optargs=

#mmcroot=/dev/mmcblk0p2 ro

#mmcrootfstype=ext4 rootwait fixrtc

 

uenvcmd=run loadimage; run loadfdt; run mmcargs; bootz ${loadaddr} - ${fdtaddr}

In u-boot, if I printenv. There is a variable called loaduimage.

loaduimage=load mmc ${bbotpart} ${klaodaddr} ${bootdir}/${bootfile}

bootfile=uImage

However, the script line in the link performs this- sudo cp -v ./linux-dev/deploy/${kernel_version}.zImage /media/boot/zImage

Am I missing something in the kernel build menu configuration process or can I just rename bootfile to zImage? Do I need to change the addresses to load?

I also got an second error in u-boot when running the next uenvcmd associated with run loadfdt. The /boot directory structure has changed. the file not found ids located in the dtbs directory.

Finally, I tried running the install_kernel.sh script in /linux-dev/tools. It runs without error but doesn't move the files to the sd card.

Regards,

-M

[mac...@msn.com]

I went back and started from scratch with u-boot. It looks like it had build errors.

git clone git://git.denx.de/u-boot.git
Cloning into 'u-boot'...
remote: Counting objects: 253022, done.
remote: Compressing objects: 100% (49006/49006), done.
remote: Total 253022 (delta 202954), reused 249594 (delta 199777)
Receiving objects: 100% (253022/253022), 60.92 MiB | 5.80 MiB/s, done.
Resolving deltas: 100% (202954/202954), done.
victoryred@WorkStation:~$ cd u-boot
victoryred@WorkStation:~/u-boot$ git checkout v2014.04-rc3 -b tmp
Switched to a new branch 'tmp'
victoryred@WorkStation:~/u-boot$ wget -c https://raw.github.com/eewiki/u-boot-patches/master/v2014.04-rc3/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
--2014-04-11 16:41:52--  https://raw.github.com/eewiki/u-boot-patches/master/v2014.04-rc3/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
Resolving raw.github.com (raw.github.com)... 199.27.79.133
Connecting to raw.github.com (raw.github.com)|199.27.79.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4886 (4.8K) [text/plain]
Saving to: `0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch'

100%[====================================================================>] 4,886       --.-K/s   in 0.001s 

2014-04-11 16:41:52 (7.62 MB/s) - `0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch' saved [4886/4886]


patch -p1 < 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
patching file include/configs/am335x_evm.h
patching file include/configs/ti_armv7_common.h
victoryred@WorkStation:~/u-boot$ make ARCH=arm CROSS_COMPILE=${CC} distclean
victoryred@WorkStation:~/u-boot$ make ARCH=arm CROSS_COMPILE=${CC} am335x_evm_config
Configuring for am335x_evm - Board: am335x_evm, Options: SERIAL1,CONS_INDEX=1,NAND
victoryred@WorkStation:~/u-boot$ make ARCH=arm CROSS_COMPILE=${CC}
  GEN     include/autoconf.mk.dep
cc1: error: bad value (armv5) for -march= switch
  GEN     include/autoconf.mk
cc1: error: bad value (armv5) for -march= switch
  CHK     include/config/uboot.release
  UPD     include/config/uboot.release
  CHK     include/generated/version_autogenerated.h
  UPD     include/generated/version_autogenerated.h
  CHK     include/generated/timestamp_autogenerated.h
  UPD     include/generated/timestamp_autogenerated.h
  HOSTCC  scripts/basic/fixdep
  CC      lib/asm-offsets.s
lib/asm-offsets.c:1:0: error: bad value (armv5) for -march= switch
make[1]: *** [lib/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

-M

[mac...@msn.com]

Hi All,

Here's my latest update regarding building a 3.13.9-bone9 bootable image.

Again, I want to thank Robert Nelson, Jason Kridner and everyone that has contributed to the BBB/Debian effort. This was a big improvement for me.

I did get Debian 3.13.9 running last night. I am trying to integrate devices with the BBB and it was recommended that in order to complete the integration I should perform the build and upgrade. But first I needed to put together the cross compiler development platform. I didn't didn't have one other than Windows 7, Eclipse, GNU toolchain and Putty. I went the dual boot route by adding Ubuntu to may second SSD.

As mentioned above I tried to perform the steps outlined in this link  http://eewiki.net/display/linuxonarm/BeagleBone . The difficulties I had are documented earlier in this thread. Those issues were part of my learning curve and having the correct packages loaded in the correct directory structure. I own those issues.

However, in those instructions there are patches applied to u-boot. After the patch, many environmental variables are set in AM335x_evm.h. Some of those variables are load addresses for zImage. Other variables are defined/set in uEnv.txt. This was important all day yesterday because u-boot wouldn't load the zImage or fdtload. It can become confusing trying to understand the uImage/zImage concept when you go back and forth between the code and running uboot. BTW, none of this troubleshooting would have been possible without at least a serial -> USB converter and Putty running a serial connection. Need to learn u-boot as part of the process as well. Using printenv and comparing the environmental variables to the values defined/set in the u-boot patch (AM335x_evm.h) was insightful.

So, to finish the build discussion, I ended up using ./build_kernel.sh and ./install_kernel.sh. I think ./install_kernel.sh is still a work in progress as can be determined by looking at the conditional code surrounding zImage. But it works and the pesky edits and cp -v of fstab, inittab et. al. found in the '//eewiki.net/' are now included in the shell (build/install). Life is simpler for that. But........let's go back to the patches referenced in the '//eewiki.net/' link that are applied to u-boot and also to uEnv.txt.

In a nutshell, variables such as loadaddr are set in AM335x_emv.h if you apply the patch. Yet they appear to be changed in uboot when you compare the contents of the dump when you perform printenv. It was interesting because according to uboot quit with the unable to load zImage running from the uEnv.txt command file. Interesting because some of those variables aren't defined or set in uEnv.txt and are different than what was defined in the u-boot patch. What was more curious was the skeletal uEnv.txt command file from the wiki link. At the end of the day, here's how I got things to work. I booted my Win7 machine and copied the latest Debian build (v3.8) to one of my SD cards. I ran my BBB to check that it worked. Shutdown my BBB and removed the card. I rebooted my development platform out of Win7 and into Ubuntu. Placed the sdcard into a reader and compared the uEnv.txt file in the ~/linux-dev/deploy path against what was on the sdcard. Well, I almost fell out of my chair.

I had a "I wonder if" moment and copied the uEnv.txt file from the sdcard (w/Debian v3.8) to my desktop and then swapped sdcards (w/Debian v3.13.9) and copied the much different  uEnv.txt file from my desktop to the sdcard. After placing the sdcard into the BBB I started the BBB. Now everything booted correctly (Debian v3.13.9). 

I hope that someone benefits from my mistakes and my discoveries.

[Robert Nelson]

On Mon, Apr 14, 2014 at 11:22 AM, <mac...@msn.com> wrote:
> Hi All,
>
> Here's my latest update regarding building a 3.13.9-bone9 bootable image.
> Again, I want to thank Robert Nelson, Jason Kridner and everyone that has
> contributed to the BBB/Debian effort. This was a big improvement for me.
>
> I did get Debian 3.13.9 running last night. I am trying to integrate devices
> with the BBB and it was recommended that in order to complete the
> integration I should perform the build and upgrade. But first I needed to
> put together the cross compiler development platform. I didn't didn't have
> one other than Windows 7, Eclipse, GNU toolchain and Putty. I went the dual
> boot route by adding Ubuntu to may second SSD.
>
> As mentioned above I tried to perform the steps outlined in this link
> http://eewiki.net/display/linuxonarm/BeagleBone . The difficulties I had are
> documented earlier in this thread. Those issues were part of my learning
> curve and having the correct packages loaded in the correct directory
> structure. I own those issues.

Well hat's the wrong page for the BBB and hence why the uEnv.txt did not work..

For the BeagleBone black use:
http://eewiki.net/display/linuxonarm/BeagleBone+Black

Not sure how much clearer i can make it..:
http://eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-uEnv.txtbasedbootscript

Quote: "This will not work on the BeagleBone Black with the default
firmware in eMMC: for that device use: BeagleBone Black"

> However, in those instructions there are patches applied to u-boot. After
> the patch, many environmental variables are set in AM335x_evm.h. Some of
> those variables are load addresses for zImage. Other variables are
> defined/set in uEnv.txt. This was important all day yesterday because u-boot
> wouldn't load the zImage or fdtload. It can become confusing trying to
> understand the uImage/zImage concept when you go back and forth between the
> code and running uboot. BTW, none of this troubleshooting would have been
> possible without at least a serial -> USB converter and Putty running a
> serial connection. Need to learn u-boot as part of the process as well.
> Using printenv and comparing the environmental variables to the values
> defined/set in the u-boot patch (AM335x_evm.h) was insightful.
>
> So, to finish the build discussion, I ended up using ./build_kernel.sh and
> ./install_kernel.sh. I think ./install_kernel.sh is still a work in progress
> as can be determined by looking at the conditional code surrounding zImage.

That's called making the script generic and supporting legacy
platforms. PS the directions on the wiki never state to use the
"./tools/install_kernel.sh" script, that's cheating.. ;)

> But it works and the pesky edits and cp -v of fstab, inittab et. al. found
> in the '//eewiki.net/' are now included in the shell (build/install). Life
> is simpler for that. But........let's go back to the patches referenced in
> the '//eewiki.net/' link that are applied to u-boot and also to uEnv.txt.
>
> In a nutshell, variables such as loadaddr are set in AM335x_emv.h if you
> apply the patch. Yet they appear to be changed in uboot when you compare the
> contents of the dump when you perform printenv. It was interesting because
> according to uboot quit with the unable to load zImage running from the
> uEnv.txt command file. Interesting because some of those variables aren't
> defined or set in uEnv.txt and are different than what was defined in the
> u-boot patch. What was more curious was the skeletal uEnv.txt command file
> from the wiki link. At the end of the day, here's how I got things to work.
> I booted my Win7 machine and copied the latest Debian build (v3.8) to one of
> my SD cards. I ran my BBB to check that it worked. Shutdown my BBB and
> removed the card. I rebooted my development platform out of Win7 and into
> Ubuntu. Placed the sdcard into a reader and compared the uEnv.txt file in
> the ~/linux-dev/deploy path against what was on the sdcard. Well, I almost
> fell out of my chair.
>
> I had a "I wonder if" moment and copied the uEnv.txt file from the sdcard
> (w/Debian v3.8) to my desktop and then swapped sdcards (w/Debian v3.13.9)
> and copied the much different uEnv.txt file from my desktop to the sdcard.
> After placing the sdcard into the BBB I started the BBB. Now everything
> booted correctly (Debian v3.13.9).
>
> I hope that someone benefits from my mistakes and my discoveries.

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Robert Nelson]

Thus you never set "CC" to the cross compiler referenced..

[William Hermans]

One thing I am finding unclear in your latest instructions Robert.

Under the root file system heading .  .

"optargs=quiet init=/lib/systemd/systemd"



Now I suspect I know what this is for and how to use it, but someone else may not. By the way your comments section of that site is completely terrible now days. Neither firefox, nor chrome on my system here could load your text editor. Just sat there loading indefinitely.


--
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.

[Robert Nelson]

On Mon, Apr 14, 2014 at 12:24 PM, William Hermans <yyr...@gmail.com> wrote:
> One thing I am finding unclear in your latest instructions Robert.
>
> Under the root file system heading . .
>
> "optargs=quiet init=/lib/systemd/systemd"

Yeah, i haven't documented the systemd stuff very well on those pages.

>
> Now I suspect I know what this is for and how to use it, but someone else
> may not. By the way your comments section of that site is completely
> terrible now days. Neither firefox, nor chrome on my system here could load
> your text editor. Just sat there loading indefinitely.

Yeap, and every new comment, just makes those pages worse. That's why
I moved the comments into their own pages about a year ago. The mysql
server really struggles with them. I'm tempted to start purging
old-outdated comments.

[William Hermans]

Robert, They are still useful I think to someone, maybe make an archive ? Just suggestion.

[mac...@msn.com]

Yes Robert,

You are correct on all counts. I was unaware of the http://eewiki.net/display/linuxonarm/BeagleBone+Black . I performed a google search and found the first site I mentioned.

Being "new" can be a painful process. Not working on a staff with others to learn from is even more painful.

The biggest obstacle is that "you don't know what you don't know".

Again, I thank you for your efforts. I will be persistent.

Respectfully,

[William Hermans]

macarr, just so you know I have been using Debian for a good while and it took me 2-3 tries to get his steps right myself. At the time the instructions were a bit less clear, but the fault was my own ( I was a bit rusty with some of the steps / commands ).

I am currently rebuilding my own kernel to the latest from scratch, and so far they seem to work perfectly ( I am about half way through, e.g. I've downloaded all the tools and have compiled the kernel).

@Robert, I should be able to do the same steps I took back in December to get a working TFTP/NSF boot/root with the latest kernel ?

What about 3.13 ? I remember you saying something about it being a "different animal" some months ago.

I would ask on your comments pages for your site, but . . . Yeah editor wont stop loading.

[William Hermans]

Sorry ---->NFS <----

[mac...@msn.com]

Hi William,

Yes, I realize that the pain is self-inflicted and I want to be clear about that. I have a favourite golfer that once said,"I'm an idiot!". I've uttered those very words once or twice lately. Judging by the forums I think others have said similar things.

You would never believe it by my comments but in the late 1980's I was doing this full time on a RT VME chassis running UniFlex (Unix variant). I wrote drivers in C and 68030 assembly language and did some very neat stuff. The learning curve was steep back then too. Ah, but I was young! Time didn't matter...So I had to see what the kids are getting into these days.

I am actually more concerned with another issue regarding attaching a USB hub to the USB host on the BBB. After I've done that the system won't enumerate any of the devices I've put into the hub. But according to dmesg the hub itself was successfully installed.

Ideas?

[William Hermans]

I have no hands on with this sort of thing, but I have noticed on many occations that "we" always need to research the hardware we use on a particular Linux Distro.

.Which kernel are you using again ? 3.8.x does not do Hotplug very well, or even at all. SO if you're hot plugging USB devices into the hub after the system is up and running, It could be that the hub may buffer you from a kernel oops, but still does not recognize the devices.

It could also be that you need to compile a module or two into the kernel statically for the HUB to work properly. But that is just a guess on my behalf that could be wrong. I have not personally noticed anything specific to this when browsing menuconfig, but I was not looking for this sort of thing when compiling my own kernel.

*OR* Maybe you just need a different hub . . . Perhaps someone with more experience with this sort of thing will reply and give us their 2 cents.

[Cody Lacey]

Was your hub plugged in at boot or after?  I may have a workaround you can try.

If you know the hub enumerates post the contents of /sys/bus/usb/devices

[mac...@msn.com]

Hi William and Cody,

I have some partially good news. Using Robert's link I did successfully build and install v3.14.1-bone2 and I have my BBB up and running. Thanks for your support. BTW, watching the board boot over the serial port is jaw dropping-ly cool. The software checksum
 calculation speeds seems to be amazing. The arm4regs are reporting 685.2 MB/sec. Now I'm having fun.

So now to the questions you are asking so that you can help me.

Note: The USB hub is an externally powered Belkin HS USB 2.0 hub model F5U233.

It is not recognized at boot time. I'll try a hot plug and look at dmesg.

No messages appended to dmesg after the hot plug.

the /sys/bus/usb/devices file is empty.

[William Hermans]

Serial boot ? I have not done that yet, Id like to read a write up of that if you wrote one. e.g. I have no hands on with serial booting, and perhaps would like to know how.

[mac...@msn.com]

Hi William,

I boot the BBB from the SD card but I purchased the Adafruit debugging cable http://www.adafruit.com/products/954. At first I was using Win7(64) and downloaded a copy of Putty for uSoft. The default settings for the BBB serial port is 115.2 Kb, 8 data bits,no parity, 1 stop bit and no handshaking. In putty create/load/save a profile for the serial port you are connected to. You can see which one by looking in control panel device manager serial ports. The com port you need will be connected to a Prolific USB to Serial bridge.

The physical connections from the cable to the BBB are

BBB       Wire        Function
Pin 1      Black      Signal Ground
Pin 4      Green      Receive
Pin 5      White      Transmit

I did the same thing in Ubuntu but the serial port is /dev/ttyUSB0 with the port configuration settings the same. In Ubuntu, from a terminal enter sudo putty prior to starting the BBB.

It's a must have setup to debug u-boot and capture the kernel boot. U-boot is a piece of work all to itself. But if you know how to use it you can back drive the information you get from it to the area in uEnv.txt and the boot loader. Once the kernel is started the kernel messages reflect what you can get from dmesg after you log into the BBB. Yes it is very interesting and exciting/fun.

I keep the serial cable connected all the time and my other work is done through the network connections. I use tightvncserver on the BBB and tightvncviwer on the pc for a remote desktop session or Cloud-9 from google chrome as advertised on BB website.

Hope I helped.

Mike

[mac...@msn.com]

Hi Cody,

I posted this to both you and William but in a different post.

 Note: The USB hub is an externally powered Belkin HS USB 2.0 hub model F5U233.

It is not recognized at boot time. I'll try a hot plug and look at dmesg.

No messages appended to dmesg after the hot plug.

the /sys/bus/usb/devices file is empty.

I appreciate your help.

Mike

On Thursday, April 17, 2014 7:48:42 AM UTC-7, cody wrote:

[William Hermans]

macarr, ah I see, I thought you meant actually booting from the serial device. Which is something altogether different.

I actually use an MSP430 launchpad v1.5. with the MCU removed to get to the terminal.

 It is limited to 9600 baud but I only use it for troubleshooting boot up issues.

 I did a write up of it last year here

http://forum.beaglefu.com/topic/92-msp430-launchpad-v15-serial-debug/

All in all it isnt the most practical approach but is still neat. And it works !

[mac...@msn.com]

Hi Cody,

Yesterday after my last post I re-tried a non externally powered usb hub. It's a generic from Staples office supply P/N 36302. The BBB running 3.14.1-bone2 found it and I subsequently attached a Rocketfish bluetooth adapter and a Sony PS3 Dual Shock controller all fine so far. So I can now start testing my next configuration. I don't know if anyone is keeping a list of working USB hubs (I think they are) if so they will probably be able to add this to the list.

This same usb hub did not work under Debian v3.8.

Finally, going back to the Belkin externally powered hub I was first experimenting with, when I unplugged the power adapter from the hub and reconnected it to the BBB I got this dmesg report-

[29444.521754] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_wait_bcon (89, <AValid), retry #1, port1 00000104

On Thursday, April 17, 2014 7:48:42 AM UTC-7, cody wrote:

[mac...@msn.com]

Well the next issue I ran into was with the USB bluetooth adapter. I have two, both are based on Broadcom chipsets the BCM2046 and BCM2070A0.


------@arm:~# uname -a
Linux arm 3.14.1-bone2 #1 SMP Wed Apr 16 22:21:08 PDT 2014 armv7l GNU/Linux

Digging deeper into things these are the messages I'm getting-

from dmesg

[    4.677402] usb 2-1: new full-speed USB device number 2 using musb-hdrc
[    4.819554] usb 2-1: device v0a5c p21e8 is not supported                                     <<<<------------
[    4.825144] usb 2-1: New USB device found, idVendor=0a5c, idProduct=21e8
[    4.832201] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    4.839717] usb 2-1: Product: BCM20702A0                                                         <<<<------------
[    4.843830] usb 2-1: Manufacturer: Broadcom Corp
[    4.848685] usb 2-1: SerialNumber: 00190E1562FA

------@arm:~# hciconfig -a
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:19:0E:15:62:FA  ACL MTU: 1021:8  SCO MTU: 64:1
        DOWN
        RX bytes:565 acl:0 sco:0 events:29 errors:0
        TX bytes:358 acl:0 sco:0 commands:29 errors:0
        Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT

----@arm:~# hciconfig hci0 up
[   62.177413] Bluetooth: hci0 command 0x0c12 tx timeout
[   64.177396] Bluetooth: hci0 command 0x080f tx timeout
Can't init device hci0: Connection timed out (110)

It's the same issue for the Rocketfish adapter with the BCM2046 chip.

Do I need to upload firmware to the BCM2046 or BCM2070 during intialization in order to be able to use them? Is it available to us?

The Rocketfish adapter was connecting to my iPhone in v3.8.