The U-Boot built from the Mainline sources doesn’t seem to be able to load the kernel.
Here is how i built it:
git clone git://git.denx.de/u-boot.git u-boot-main
cd u-boot-main/
git checkout --track -b omap3 origin/master
make CROSS_COMPILE=arm-linux-gnueabihf- mrproper
make CROSS_COMPILE=arm-linux-gnueabihf- omap3_beagle_config
make CROSS_COMPILE=arm-linux-gnueabihf-
U-Boot builds, I copied the u-boot.img into the Beagleboard xM boot SD (U-Boot FAT partition). The SD has been made from RobertCNelson preconfigured Ubuntu demo image, with currently operational U-Boot. The new U-Boot fails to load the kernel image:
U-Boot SPL 2013.07-00016-gbc15ff8 (Aug 16 2013 - 10:41:31)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.10 (Oct 21 2013 - 15:03:24)
OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 512 MiB
NAND: 0 MiB
MMC: OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment
In: serial
Out: serial
Err: serial
Beagle xM Rev C
No EEPROM on expansion board
Die ID #1c9000029ff800000163810c0d02f018
Net: usb_ether
Hit any key to stop autoboot: 0
mmc0 is current device
gpio: pin 173 (gpio 173) value is 0
gpio: pin 4 (gpio 4) value is 0
SD/MMC found on device 0
reading uEnv.txt
945 bytes read in 3 ms (307.6 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc …
Running uenvcmd …
reading zImage
3812504 bytes read in 239 ms (15.2 MiB/s)
reading initrd.img
3196182 bytes read in 199 ms (15.3 MiB/s)
reading /dtbs/omap3-beagle-xm.dtb
13511 bytes read in 8 ms (1.6 MiB/s)
## Error: “expansion_args” not defined
Kernel image @ 0x80300000 [ 0x000000 - 0x3a2c98 ]
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
** File not found /boot/uImage **
Booting from nand …
no devices available
Wrong Image Format for bootm command
ERROR: can’t get kernel image!
** File not found /boot/zImage **
OMAP3 beagleboard.org #
Is there a working U-Boot source/build environment available? Or patches to build the mainline U-Boot?
Thanks!
Just in case, the contents of my uEnv.txt:
kernel_file=zImage
initrd_file=initrd.img
initrd_high=0xffffffff
fdt_high=0xffffffff
console=ttyO2,115200n8
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext4 rootwait fixrtc
loadkernel=fatload mmc ${mmcdev}:${mmcpart} 0x80300000 ${kernel_file}
loadinitrd=fatload mmc ${mmcdev}:${mmcpart} 0x81600000 ${initrd_file}; setenv initrd_size ${filesize}
loadfdt=fatload mmc ${mmcdev}:${mmcpart} 0x815f0000 /dtbs/${fdtfile}
boot_classic=run loadkernel; run loadinitrd
boot_ftd=run loadkernel; run loadinitrd; run loadfdt
device_args=run expansion_args; run mmcargs
mmcargs=setenv bootargs console=${console} ${optargs} ${kms_force_mode} video=Unknown-1:1024x768@60e root=${mmcroot} rootfstype=${mmcrootfstype} ${expansion}
#Classic Board File Boot:
#uenvcmd=run boot_classic; run device_args; bootz 0x80300000 0x81600000:${initrd_size}
#New Device Tree Boot:
uenvcmd=run boot_ftd; run device_args; bootz 0x80300000 0x81600000:${initrd_size} 0x815f0000
Please don't mix and match source/guide's etc.. It's pain to support..
http://eewiki.net/display/linuxonarm/BeagleBoard
Regards,
Thanks, I understand. Turns out what I needed could have been accomplished without rebuilding U-Boot. I had to set the value of a GPIO line, and there is a U-Boot script command for that.
So, a re-built U-Boot wouldn’t have produced any benefit.
However, I need to figure out how to force this GPIO to stay LOW during kernel startup. Apparently the kernel switches it HIGH (or affects some sort of a reset that forces GPIO_137 high). So, the GPIO line is switched down via “gpio clear 137” U-Boot command, but a couple of seconds later comes back up, and stays up until the user software can be brought up to switch it off. It seems that most interactions with the registers, including setting GPIO levels, can be achieved via the DTS? I see some examples for BBB, but haven’t found anything for the xM.
Thanks!
Not touched via the DTS, but they are touched somehow. When I clear the GPIO 137 (or 138 or 139, to which I have LEDs connected) in U-Boot, the signal is correctly affected. Then I issue the boot command, and let the Linux start up. As soon as the “Starting kernel …” message comes out on the serial port, all signals are back HIGH. So, whether there is a peripheral reset of some kind that “resets” all these GPO signals, or they are set in the C source, but they are definitely affected by kernel startup. I am OK if they came up for a little bit, as long as we had a way to set them LOW before the full system startup completes.
Thanks!
I suspect the problem is not GPIO, something else seems to be muxed into the GPIO pins (maybe MMC2? But it is “disabled” in the DTS!). The GPIOs are accessible from U-Boot (via “gpio” commands), but they are NOT accessible from the Linux userspace.
cd /sys/class/gpio
echo 137 > export
cd gpio137
echo “low” > direction
no effect! The /sys/kernel/debug/omap_mux/sdmmc2_dat7 is not present, so I cannot remux anything into the GPIO pins.
Thanks!
omap_mux is not available in device tree..
Regards,
Well, then how do we make sure the GPIOs are muxed on the pins? The “normal” way to access GPIOs (via /sys/class/gpio) is not working in 3.11. Maybe due to the multiplexing? It worked fine in 3.7 stable, if it’s any help.
/sys/kernel/debug/omap_mux is present, but it’s empty. It is configured in the kernel build. I don’t see how it can be enabled in device tree.
Well, then how do we make sure the GPIOs are muxed on the pins? The
"normal" way to access GPIOs (via /sys/class/gpio) is not working in 3.11.
Maybe due to the multiplexing? It worked fine in 3.7 stable, if it's any
help.
Well, with 3.7 we did not use device tree's...
/sys/kernel/debug/omap_mux is present, but it's empty. It is configured in
the kernel build. I don't see how it can be enabled in device tree.
It's not a "device tree" only zImage, as a few board files are still
enabled that do not work with very well with device trees..
the "TI" only "omap_mux" has been replaced by the generic "pinctrl" driver..
See:
/sys/kernel/debug/pinctrl/44e10800.pinmux/pins
Regards,
There appear to be two pinmux ranges: 48002030.pinmux 48002a00.pinmux
Dumping /sys/kernel/debug/pinctrl/48002030.pinmux/pins crashes the kernel; and GPIO_137 seems to be muxed via 0x48002164, so I cannot see what is muxed on that pin. Dumping /sys/kernel/debug/pinctrl/48002a00.pinmux/pins seems to produce valid output, but I am not sure it is of any use to me.
Hello Porkupan sir,
Have you solved the Issue involved with pin muxing…I stuck at same problem…