Using GPIO-Poweroff on a Raspberry Pi Compute Module with DAS U-Boot to turn off the PSU - linux

I've been trying to get GPIO-Poweroff to switch off the board PSU using GPIO but no matter what I try, it never seems to work. If I manually toggle the GPIO pin, the device immediately shuts down. If I take stock Raspbian-Lite and add the following line to config.txt it works. But U-Boot seems to be ignoring it. I am using Raspbian Lite 2017-07-5 with the latest mainline U-Boot: git://git.denx.de/u-boot.git compiled with rpi_defconfig.
dtoverlay=gpio-poweroff,gpiopin=6,active_low=1
With U-Boot the Raspberry Pi boots and works normally, it even shuts down but it never toggles GPIO6. This leaves the PSU running and the only way to fix it is by holding down the power button for at least 5 seconds. I know that dt-blob.bin is loaded and applied as the board has a camera which only works with the correct dt-blob.bin.
At thus point I am out of ideas. I have tried:
Updating the Linux kernel using rpi-update
Decompiling both gpio-poweroff.dtbo and dt-blob.bin. Changing 0x1a to 0x06 and 0x0 to 0x1 inside gpio -poweroff.dtbo, concatenating them together and it doesn't work.
Manually doing the above and intertwining the decompiled code.
Using fdt addr, and fdt apply inside boot.scr to apply it manually, this didn't work because fdt_overlay_apply FDT_ERR_NOSPACE and I couldn't seem to get past this.
Cloning linux and trying to make dtsb, target doesn't exist.
Cloning linux/arch/arm/boot/dts, writing a MakeFile and compiling them with my changes results in a U-Boot loading, Raspbian loading but gpio-poweroff not working.
Other attempts which are barely worth mentioning.
Nothing I try seems to work, and I'm not sure where to go forward.
For reference, here are some of the files in use:
boot.cmd:
#Setting default bootargs
setenv original_bootargs console=ttyS0 console=tty1 rootfstype=ext4 fsck.repair=yes hdmi.audio=0 disp.screen0_output_mode=1920x1080p60:1280x720p60:800x600p60:EDID rootwait panic=10 # console MUST be ttyS0 or it WILL NOT BOOT!
# Identify if we are using partition 2 or 3
if fatload mmc 0:1 ${loadaddr} swap; then echo "Using Partition 3"; setenv partition 3; else echo "Using Partition 2"; setenv partition 2; fi
# Check for recovery
if fatload mmc 0:1 ${loadaddr} recovery; then echo "Using Recovery Partition"; setenv partition 4; fi
#if gpio input 32 || fatload mmc 0:1 ${loadaddr} recovery; then echo "Using Recovery Partition"; setenv partition 4; fi
# Create an empty file to detect boot failures
fatwrite mmc 0:1 ${kernel_addr_r} recovery 0
# Set bootargs
setenv bootargs "${original_bootargs} root=/dev/mmcblk0p${partition}"
# Load the existing Linux kernel into RAM
echo Loading partition ${partition}
ext4load mmc 0:${partition} ${kernel_addr_r} kernel.img
# Boot the kernel we have just loaded
bootz ${kernel_addr_r} - ${fdt_addr}
Not sure why, but it boots with red and blue swapped, and at a low resolution. Compiled with mkimage -A arm -O linux -T script -C none -a 0x00000000 -e 0x00000000 -n "Boot Script" -d boot.cmd boot.scr
config.txt:
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
#dtparam=audio=on
gpu_mem=128
start_x=1
dtoverlay=gpio-poweroff,gpiopin=6,active_low=1
dtdebug=1

So, I've somewhat fixed it by compiling my own bcm27***.dtb files with the following concatenated after their original content:
/ {
compatible = "brcm,bcm2709";
power_ctrl: power_ctrl {
compatible = "gpio-poweroff";
gpios = <&gpio 6 1>;
};
};
However, this has completely broken GPIO and i2c. So this isn't a complete solution. My next step is to restore the original files, and try adding this to the end of dt-blob.bin

I did it, here is the answer:
# Manually apply overlay
setenv fdt_length 50000
setexpr kernel_addr_r ${fdt_addr} + ${fdt_length}
fdt addr ${fdt_addr} # Load the existing tree
fdt boardsetup # Device specific setup
fdt move ${fdt_addr} ${fdt_addr} ${fdt_length} # Resize the loaded fdt to ${fdt_length}
fatload mmc 0:1 ${kernel_addr_r} overlays/gpio-poweroff.dtbo
fdt apply ${kernel_addr_r} # Apply the overlay
Editing default device trees and dt-blob.bin ended being a fruitless endeavour. What you need to do is apply the overlay yourself, manually, inside uboot.src.
The first step is to find the source code of the desired overlay, and change the default value to you desired value, you cannot use overlay arguments inside U-Boot.
Before applying overlays you need to increase the size of the loaded device tree using fdt move, then you can load and apply from fat. If you wanted to apply more overlays you simply need to add additional lines such as:
fatload mmc 0:1 ${kernel_addr_r} overlays/rpi-tv.dtbo
fdt apply ${kernel_addr_r} # Apply the overlay
Be careful your device tree doesn't run out of space!

Related

How to re-enable CPU Cores after isolcpus

I'm running some processes on a Jetson NX and I was trying to isolate 3 of the cores so I could use taskset and dedicate them to my python script which incorporated multi processing. To do this, I followed a few tutorials and modified my /boot/extlinux/extlinux.conf file to be:
TIMEOUT 30
DEFAULT primary
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=3-5
This worked fine for my needs and when I ran cat /sys/devices/system/cpu/isolated
it outputted 3-5. Now I'm trying to bring back cores 3 and 4, so I modified the extlinux.conf file to say:
TIMEOUT 30
DEFAULT primary
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=5
and I rebooted my Jetson. However It still says cores 3-5 are isolated. Is there some other steps I need to take to re-enable these cores?

Booting kernel from SD in qemu (ARM) with u-boot

I'm quite new to embedded systems and I'm playing around with ARM on qemu. So I've run into problem booting linux kernel image from an emulated SD on versatile express with cpu cortex-a9.
I prepared everything in the following order: first, I've built the kernel with vexpress_defconfig using appropriate ARM toolchain. Then I've built u-boot with vexpress_ca9x4_defconfig. Everything went just fine. The linux kernel source I took is at version 4.13 (latest stable from git). U-boot version is 2017.09-00100. Then I prepared an SD image:
dd if=/dev/zero of=sd.img bs=4096 count=4096
mkfs.vfat sd.img
mount sd.img /mnt/tmp -o loop,rw
cp kernel/arch/arm/boot/zImage /mnt/tmp
umount /mnt/tmp
Next I try to run qemu as follows:
qemu-system-arm -machine vexpress-a9 -cpu cortex-a9 -m 128M -dtb kernel/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -kernel uboot/u-boot -sd sd.img -nographic
U-boot loads successfully and gives me command prompt. And SD is really there and attached:
=> mmcinfo
Device: MMC
Manufacturer ID: aa
OEM: 5859
Name: QEMU!
Tran Speed: 25000000
Rd Block Len: 512
SD version 1.0
High Capacity: No
Capacity: 16 MiB
Bus Width: 1-bit
Erase Group Size: 512 Bytes
I attempt to load compressed image from SD into memory and boot it:
fatload mmc 0:0 0x4000000 zImage
and everything looks ok
=> fatload mmc 0:0 0x4000000 zImage
reading zImage
3378968 bytes read in 1004 ms (3.2 MiB/s)
but then I want to boot the kernel and get an error:
=> bootz 0x4000000
Bad Linux ARM zImage magic!
I also tried U-boot images, crafted with u-boot's mkimage, like in this example:
uboot/tools/mkimage -A arm -C none -O linux -T kernel -d kernel/arch/arm/boot/Image -a 0x00010000 -e 0x00010000 uImage
also trying out -C gzip on zImage and different load/entry addresses, to no avail. The images were copied to sd.img. When I fatload the image and check it with iminfo, whichever options I try, I constantly get error:
=> iminfo 0x4000000
## Checking Image at 04000000 ...
Unknown image format!
I'm totally confused and this problem drives me nuts, while information on this subject in Internet is rather scarce. Please, hint me what I'm doing wrong and redirect into right direction.
qemu in use is QEMU emulator version 2.9.0.

Understanding Verified Uboot on Embedded Board

I've scoured the presentations and documentation for verified u-boot and have several questions. I'll try to walk any users through where I am as I suspect I am not the only one who is having some slight difficulty understanding the process for verified u-boot.
I have a compiled zImage that has a working external DTB for use without verification. It boots and works (let's call this normal-board.dts)
Secondly, I have u-boot compiled with the following config entries:
CONFIG_ARM=y
CONFIG_ARCH_AT91=y
CONFIG_TARGET_AT91SAM9260EK=y
CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9G20,SYS_USE_DATAFLASH_CS1"
CONFIG_SYS_PROMPT="#> "
# CONFIG_CMD_BDI is not set
CONFIG_CMD_IMI=y
# CONFIG_CMD_IMLS is not set
# CONFIG_CMD_LOADS is not set
# CONFIG_CMD_FPGA is not set
# CONFIG_CMD_SOURCE is not set
CONFIG_CMD_SETEXPR=y
CONFIG_DEFAULT_DEVICE_TREE="myboard"
CONFIG_CMD_MMC=y
CONFIG_CMD_FAT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_RSA=y
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_OF_CONTROL=y
My board has a partition scheme similar to:
... boot strap, uboot and env
0xD00084000 (zImage)
0xD0020AA00 (normal-board.dtb)
The rootfs is on NAND (external to this chip)
The device can be booted in a standard configuration using a command such as:
cp.b 0xD0084000 0x22000000 0x186A00;cp.b 0xD020AA00 0x28000000 0x61A8;bootm 0x22000000 - 0x28000000
At this point, I've recompiled u-boot, but the nomenclature is a bit confusing as there are several elements.
FIT Control DTS (I assume that this is one used by u-boot and needs to be in its own partition)
FIT DTB (the same DTB more or less as the non-FIT one (normal-board.dtb), but with FIT magic somewhere in it)
FIT kernel image (I assume that some magic gets added to the zImage here too?)
Having seen that there is a uboot control FIT FDT, will this need its own partition? and will the FIT DTB be the same as the working kernel DTB (just flash this instead of the non-FIT one)???
Next, given this script I started hashing out from various documentation and slides, we can see that u-boot.{dts,dtb} is the control FDT, and the ITS file is the one with the fit (I assume that its the same as normal-board.dts, BUT has a FIT node added).
Eg. u-boot.dts
/dts-v1/;
/ {
model = "Keys";
compatible = "myboard";
signature {
dev_key {
required = "conf";
algo = "sha1,rsa2048";
key-name-hint = "dev_key";
};
};
};
Now the example DTS for myboard WITH THE FIT section:
/dts-v1/;
/ {
description = "Linux kernel2";
#address-cells = <1>;
images {
kernel#1 {
description = "Linux kernel";
data = /incbin/("../linux/arch/arm/boot/zImage");
arch = "arm";
os = "linux";
type = "kernel_noload";
compression = "none";
load = <0x80080000>;
entry = <0x80080000>;
kernel-version = <1>;
hash#1 {
algo = "sha1";
};
};
};
configurations {
default = "conf#1";
conf#1 {
description = "Boot Linux kernel";
kernel = "kernel#1";
signature#1 {
algo = "sha1, rsa2048 ";
key-name-hint = "dev_key";
sign-images = "kernel";
};
};
};
};
However, what the heck is fitImage (see below script - this is from the examples)? is it zImage? I couldn't find any documentation describing its first mention - what it is where it comes from etc... or is it an output generated by the reference from within the ITS for an incbin?
#!/bin/bash
key_dir=/tmp/keys
key_name=dev_key
FIT_IMG="fitImage"
rm -rf ${key_dir}
mkdir ${key_dir}
MKIMG="/home/dev/lede/staging_dir/host/bin/mkimage"
DTC="/usr/bin/dtc"
#Generate a private signing key (RSA2048):
openssl genrsa -F4 -out \
"${key_dir}"/"${key_name}".key 2048
# Generate a public key:
openssl req -batch -new -x509 \
-key "${key_dir}"/"${key_name}".key \
-out "${key_dir}"/"${key_name}".crt
# Control FDT (u-boot.dts) - hits uboot to have keys etc...
CTRL_FDT="u-boot.dts"
# FIT image ITS - describes the node
FIT_ITS="fit-image.its"
#Assemble control FDT for U-Boot with space for public key:
$DTC -p 0x1000 $CTRL_FDT -O dtb -o u-boot.dtb
# Generate fitImage with space for signature:
$MKIMG -D "-I dts -O dtb -p 2000" \
-f f$FIT_ITS $FIT_IMG
# Sign fitImage and add public key into u-boot.dtb:
$MKIMG -D "-I dts -O dtb -p 2000" -F \
-k "${key dir}" -K u-boot.dtb -r $FIT_IMG
# Signing subsequent fitImage:
$MKIMG -D "-I dts -O dtb -p 2000" \
-k "${key dir}" -f $FIT_ITS -r $FIT_IMG
Iminfo gets me this far:
#> iminfo
## Checking Image at 20000000 ...
FIT image found
FIT description: Configuration to load a Basic Kernel
Image 0 (linux_kernel#1)
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x200000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x20000000
Entry Point: 0x20008000
Hash node: 'hash#1'
Hash algo: sha256
Hash value: bf1d62a9ac777310746c443f2500cf197967f1e7c9cb56ff5c33206670e12d8f
Hash len: 32
Image 1 (fdt#1)
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x20165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash#1'
Hash algo: sha256
Hash value: c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Default Configuration: 'config#1'
Configuration 0 (config#1)
Description: Plain Linux
Kernel: linux_kernel#1
FDT: fdt#1
## Checking hash(es) for FIT Image at 20000000 ...
Hash(es) for Image 0 (linux_kernel#1): sha256+
Hash(es) for Image 1 (fdt#1): sha256+
The zImage is prepared (and this is likely the wrong way)
mkimage -A arm -O linux -C none -T kernel -a 0x22000000 -e 0x22008000 -n linux-4.4.36 \
-d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB
Even along the lines of the following (I seem to get this, what do I do for addresses - is the reallocation part of the issue? such as the fdt_high variables?)
#> bootm 0x23000000
## Current stack ends at 0x23f119b8 * kernel: cmdline image address = 0x23000000
## Loading kernel from FIT Image at 23000000 ...
No configuration specified, trying default...
Found default configuration: 'config#1'
Using 'config#1' configuration
Trying 'linux_kernel#1' kernel subimage
Description: Linux zImage
Type: Kernel Image
Compression: uncompressed
Data Start: 0x230000dc
Data Size: 1465544 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x23000000
Entry Point: 0x23000000
Hash node: 'hash#1'
Hash algo: sha256
Hash value: bb397db1ec90ec8526c6d215c9ded2a1357a258c2145f97fda9898e810e847d7
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
kernel data at 0x230000dc, len = 0x00165cc8 (1465544)
* ramdisk: using config 'config#1' from image at 0x23000000
* ramdisk: no 'ramdisk' in config
* fdt: using config 'config#1' from image at 0x23000000
## Checking for 'FDT'/'FDT Image' at 23000000
## Loading fdt from FIT Image at 23000000 ...
Using 'config#1' configuration
Trying 'fdt#1' fdt subimage
Description: FDT blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x23165ea4
Data Size: 21681 Bytes = 21.2 KiB
Architecture: ARM
Hash node: 'hash#1'
Hash algo: sha256
Hash value: c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
Hash len: 32
Verifying Hash Integrity ... sha256+ OK
Can't get 'load' property from FIT 0x23000000, node: offset 1465916, name fdt#1 (FDT_ERR_NOTFOUND)
Booting using the fdt blob at 0x23165ea4
of_flat_tree at 0x23165ea4 size 0x000054b1
Initial value for argc=3
Final value for argc=3
Loading Kernel Image ... OK
CACHE: Misaligned operation at range [23000000, 23165cc8]
kernel loaded at 0x23000000, end = 0x23165cc8
images.os.start = 0x23000000, images.os.end = 0x2316c911
images.os.load = 0x23000000, load_end = 0x23165cc8
ERROR: new format image overwritten - must RESET the board to recover
So, there's a lot in the above question, and I'll try and answer a few things which should help clear things up:
The U-Boot binary needs to contain the pubkey. So in this case, the "myboard" device tree you've listed is where that needs to end up. It is within the binary and not a separate partition in flash.
The next thing is that the FIT image is a container with lets say different ways to open it. The fitImage contains zImage and normal-board.dtb and logic so that you can say that each of these pieces needs to be signed by a particular public key. So in this case, instead of a flash partition for the zImage and another for normal-board.dtb you have a single partition for fitImage to reside in. It is the output from providing the "its" file to mkimage. This is similar to how "uImage" is the output from providing "zImage" to mkimage.
After alot of man-hours studying, reading, and trying - I created a full blog article about how verified uboot works, and how DTBs (both forms) come together when building the final images.
This article can be found here
However, the key things to note are indeed what Tom said and here are a few more (after quoting my article):
There are two kinds of DTBs (the kernel & uboot DTBS)
There is a file called an ITS - this describes the FIT image to be built
You will need an asynchronous key pair
You will need a version of mkimage that supports verified uboot/DTBs
Your bootloader will need support Verified uboot enabled
Uboot and the Linux kernel need to know about DTBs
Even though you sign your images, a copy of the public key and other cryptographic info will be needed in the final bootloader
It was a fun process :)

Angstrom kernel - Stuck at "Starting kernel ..."

I have been trying to compile kernel for BeagleBone Black using Angstrom build system. Have tried lot of different things which came to my mind but will describe one of them which i think should most likely be working.
I have used prepared Angstrom image (Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.06.20.img) and then compiled kernel (http://github.com/Angstrom-distribution/setup-scripts.git - v2014.12 release) as is described at their website:
MACHINE=beagleboard ./oebb.sh config beagleboard
MACHINE=beagleboard ./oebb.sh update
MACHINE=beagleboard ./oebb.sh bitbake virtual/kernel
My idea is that i will take uImage and copy it instead of original one in /boot/ but it gets stuck at "Starting kernel...". I have tried using different dtb files the ones compiled with this kernel and the original ones.
(It is not because of bad console output it's really stuck)
Here is a header of original/working kernel:
Booting from mmc ...
## Booting kernel from Legacy Image at 80007fc0 ...
Image Name: Angstrom/3.8.13/beaglebone
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4270776 Bytes = 4.1 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
XIP Kernel Image ... OK
OK
Using Device Tree in place at 80f80000, end 80f88e40
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Here is mine which gets stuck at Starting kernel ...
Booting from mmc ...
## Booting kernel from Legacy Image at 80007fc0 ...
Image Name: Linux-3.14.20
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4279000 Bytes = 4.1 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
XIP Kernel Image ... OK
OK
Using Device Tree in place at 80f80000, end 80f88e40
Starting kernel ...
And here is printenv output from u-boot
arch=arm
baudrate=115200
board=am335x
board_name=A335BNLT
board_rev=00C0
bootcmd=gpio set 53; i2c mw 0x24 1 0x3e; run findfdt; mmc dev 0; if mmc rescan ; then echo micro SD card found;setenv mmcdev 0;else echo No micro SD card found, setting mmcdev to 1;setenv mmcdev 1;fi;setenv bootpart ${mmcdev}:2;mmc dev ${mmcdev}; if mmc rescan; then gpio set 54; echo SD/MMC found on device ${mmcdev};if run loadbootenv; then echo Loaded environment from ${bootenv};run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;gpio set 55; if run loaduimage; then gpio set 56; run loadfdt;run mmcboot;fi;fi;
bootdelay=1
bootdir=/boot
bootenv=uEnv.txt
bootfile=uImage
bootpart=0:2
console=ttyO0,115200n8
cpu=armv7
dfu_alt_info_emmc=rawemmc mmc 0 3751936
dfu_alt_info_mmc=boot part 0 1;rootfs part 0 2;MLO fat 0 1;MLO.raw mmc 100 100;u-boot.img.raw mmc 300 3C0;u-boot.img fat 0 1;uEnv.txt fat 0 1
dfu_alt_info_nand=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel part 0 7;rootfs part 0 8
ethact=cpsw
ethaddr=68:c9:0b:da:22:56
fdt_high=0xffffffff
fdtaddr=0x80F80000
fdtfile=am335x-boneblack.dtb
findfdt=if test $board_name = A33515BB; then setenv fdtfile am335x-evm.dtb; fi; if test $board_name = A335X_SK; then setenv fdtfile am335x-evmsk.dtb; fi;if test $board_name = A335BONE; then setenv fdtfile am335x-bone.dtb; fi; if test $board_name = A335BNLT; then setenv fdtfile am335x-boneblack.dtb; fi
importbootenv=echo Importing environment from mmc ...; env import -t $loadaddr $filesize
kloadaddr=0x80007fc0
loadaddr=0x80200000
loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz
loaduimage=load mmc ${bootpart} ${kloadaddr} ${bootdir}/${bootfile}
mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${kloadaddr} - ${fdtaddr}
mmcdev=0
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext4 rootwait
mtdids=nand0=omap2-nand.0
mtdparts=mtdparts=omap2-nand.0:128k(SPL),128k(SPL.backup1),128k(SPL.backup2),128k(SPL.backup3),1920k(u-boot),128k(u-boot-env),5m(kernel),-(rootfs)
nandargs=setenv bootargs console=${console} ${optargs} root=${nandroot} rootfstype=${nandrootfstype}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} ${nandsrcaddr} ${nandimgsize}; bootm ${loadaddr}
nandimgsize=0x500000
nandroot=ubi0:rootfs rw ubi.mtd=7,2048
nandrootfstype=ubifs rootwait=1
nandsrcaddr=0x280000
netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs nfsroot=${serverip}:${rootpath},${nfsopts} rw ip=dhcp
netboot=echo Booting from network ...; setenv autoload no; dhcp; tftp ${loadaddr} ${bootfile}; tftp ${fdtaddr} ${fdtfile}; run netargs; bootm ${loadaddr} - ${fdtaddr}
nfsopts=nolock
ramargs=setenv bootargs console=${console} ${optargs} root=${ramroot} rootfstype=${ramrootfstype}
ramboot=echo Booting from ramdisk ...; run ramargs; bootm ${loadaddr} ${rdaddr} ${fdtaddr}
ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M
ramrootfstype=ext2
rdaddr=0x81000000
rootpath=/export/rootfs
soc=am33xx
spiargs=setenv bootargs console=${console} ${optargs} root=${spiroot} rootfstype=${spirootfstype}
spiboot=echo Booting from spi ...; run spiargs; sf probe ${spibusno}:0; sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; bootm ${loadaddr}
spibusno=0
spiimgsize=0x362000
spiroot=/dev/mtdblock4 rw
spirootfstype=jffs2
spisrcaddr=0xe0000
static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off
stderr=serial
stdin=serial
stdout=serial
usbnet_devaddr=68:c9:0b:da:22:56
vendor=ti
ver=U-Boot 2013.04-dirty (Jun 19 2013 - 09:57:14)
1 : Kernel extract the physical address and link address
2 : machine id
#define MACH_TYPE_PERSONAL_SERVER 17
#define MACH_TYPE_L7200 19
#define MACH_TYPE_PLEB 20
#define MACH_TYPE_INTEGRATOR 21
#define MACH_TYPE_H3600 22
#define MACH_TYPE_P720T 24
#define MACH_TYPE_ASSABET 25
#define MACH_TYPE_LART 27
#define MACH_TYPE_GRAPHICSCLIENT 29
#define MACH_TYPE_XP860 30
#define MACH_TYPE_CERF 31
#define MACH_TYPE_NANOENGINE 32
#define MACH_TYPE_JORNADA720 48
#define MACH_TYPE_EDB7211 50
#define MACH_TYPE_PFS168 52
3:configuration of uart
1 :
config NEED_MACH_MEMORY_H
bool
help
Select this when mach/memory.h is required to provide special
definitions for this platform. The need for mach/memory.h should
be avoided when possible.
config PHYS_OFFSET
hex "Physical address of main memory" if MMU
depends on !ARM_PATCH_PHYS_VIRT && !NEED_MACH_MEMORY_H
default DRAM_BASE if !MMU
help
Please provide the physical address corresponding to the
location of main memory in your system.

outb() does not work in LDD3 example short module

I am trying short.c in examples of Linux Device Driver 3
My PC has Parallel Port and after the Ubuntu boots up, I can see these:
cat /proc/ioports
0378-037a : parport0
037b-037f : parport0
outp 0x378 1
(outp is another example in LDD3 which write data to ports)
the LED on the port is ON.
Then I run these commands to remove modules
rmmod lp
rmmod parport_pc
cat /proc/ioports
(There is no module on 0378-037f any more.)
I run this again but the LED is not ON this time.
outp 0x378 1
Then I install short.ko and request_region() succeeds.
cat /proc/ioports
0378-037f : short
cat /proc/devices
249 short
outp 0x378 1
the LED is not ON this time either.
I tried these too, but same result (LED is not ON)
mknod /dev/short0 c 249 0
echo -n "a" > /dev/short0
"a" is 0x61 so that the last bit is 1.
Why can I not write data out though I have got the I/O region?
Thanks for your answer.
Finally, I found the solution.
Make sure the “parport” module is not loaded or compiled into your kernel. It is not enough to simply unload the parport module, as it leaves the ports in an inconsistent state. You must reboot the machine and keep the parport and all related modules/code from loading in the first place.
One way to do this is to edit the /etc/modprobe.d/blacklist.conf file and add the following lines:
blacklist ppdev
blacklist lp
blacklist parport_pc
blacklist parport
It seems that partport has modify the mode of parallel port.
And if cups is installed, you should modify /etc/modules-load.d/cups-filters.conf:
#lp
#ppdev
#parport_pc

Resources