I already have a working config for a compute module 3+. As I need the same setup on a raspberry Pi Model 3 B I tried bringing the config over.
Everything is compiled in a buildroot environment. U-Boot v2020.10 is used.
After some small changes regarding the device tree and dtoverlays I managed to get U-Boot to print on the serial console(as expected), but it ignores all keyboard input.
The following output is produced by U-Boot on serial console.
EDIT
I used the term serial very loosely here. I'm connected to the serial console with a serial-USB adapter and picocom. I applied the miniuart-bt overlay to restore /dev/ttyAMA0 respectively UART0 on gpio pins 14/15.
Lastely I configured U-Boot with PL011.
I left out support for mini-uart as this would break the output too.
This configuration works just fine on the compute module, but doen't register input on the model 3B.
EDIT
I moved the working u-boot.bin from the cm 3 to the model B to see what happens. It seemingly works as both are close enough. But the same problem occurs. The other way around though it does not work. So it is potential not a problem with U-Boot but with the Model B configuration.
1 Isa-Boot>·
2
3 U-Boot 2020.10 (Mar 24 2022 - 12:18:38 +0000)
4
5 DRAM: 924 MiB
6 RPI 3 Model B (0xa02082)
7 MMC: mmc#7e202000: 0, sdhci#7e300000: 1
8 In: serial
9 Out: vidconsole
10 Err: vidconsole
11 Hit any key to stop autoboot: 0·
Neither can I stop autoboot nor can I use the shell to complete the boot script.
I tried what feels like a million configurations and I'm out of ideas what could be the reason for this behavior. I also never experienced this with the cm module.
RPi setup config.txt:
enable_uart=1
start_file=start.elf
fixup_file=fixup.dat
kernel=u-boot.bin
gpu_mem=100
dtoverlay=miniuart-bt
dtparam=spi=on
device_tree=bcm2710-rpi-3-b.dtb
dtoverlay=sc16is750-spi0-ce0
U-Boot defconfig:
CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_ARCH_BCM283X=y
CONFIG_SYS_TEXT_BASE=0x00008000
CONFIG_TARGET_RPI_3_32B=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x4000
CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_SYS_STDIO_DEREGISTER=y
CONFIG_MISC_INIT_R=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_SYS_PROMPT="Isa-Boot> "
CONFIG_CMD_GPIO=y
CONFIG_CMD_MMC=y
CONFIG_CMD_USB=y
CONFIG_CMD_FS_UUID=y
CONFIG_OF_EMBED=y
# CONFIG_ENV_IS_IN_FAT is not set
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
# CONFIG_NET is not set
CONFIG_DM_MMC=y
# CONFIG_MMC_HW_PARTITIONING is not set
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_BCM2835=y
CONFIG_DM_ETH=y
CONFIG_PINCTRL=y
# CONFIG_PINCTRL_GENERIC is not set
# CONFIG_REQUIRE_SERIAL_CONSOLE is not set
# CONFIG_BCM283X_MU_SERIAL is not set
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_DM_VIDEO=y
# CONFIG_VIDEO_BPP8 is not set
# CONFIG_VIDEO_BPP16 is not set
CONFIG_SYS_WHITE_ON_BLACK=y
CONFIG_CONSOLE_SCROLL_LINES=10
CONFIG_PHYS_TO_BUS=y
CONFIG_OF_LIBFDT_OVERLAY=y
From U-boot documentation, "U-boot Environment Variables":
bootdelay: After reset, U-Boot will wait this number of seconds before it executes the contents of the bootcmd variable. During this time a countdown is printed, which can be interrupted by pressing any key.
Set this variable to 0 boot without delay. Be careful: depending on the contents of your bootcmd variable, this can prevent you from entering interactive commands again forever!
Is this value 0 in your case?
Related
I am on linux ubuntu and target is a PIC18F47J53.
I basically want to program the chip and then let it run, using command lines and using pickit4.
using ipecmd (from mplab x ide v5.45), this is my command:
/opt/microchip/mplabx/v5.45/sys/java/zulu8.40.0.25-ca-fx-jre8.0.222-linux_x64/bin/java -jar /opt/microchip/mplabx/v5.45/mplab_platform/mplab_ipe/ipecmd.jar -TPPK4 /P18F47J53 -M -F"/path_to_myfile.hex" -W
This is my output
DFP Version Used : PIC18F-J_DFP,1.4.41,Microchip
*****************************************************
Connecting to MPLAB PICkit 4...
Currently loaded versions:
Application version............00.06.66
Boot version...................01.00.00
Script version.................00.04.17
Script build number............db473af2f4
Tool pack version .............1.6.961
PICkit 4 is supplying power to the target (3.25 volts).
Target device PIC18F47J53 found.
Device Revision Id = 0x1
*****************************************************
Calculating memory ranges for operation...
Erasing...
The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x3ff
program memory: start address = 0x1fc00, end address = 0x1fff7
configuration memory
Programming/Verify complete
Program Report
30-Jan-2021, 12:54:41
Device Type:PIC18F47J53
Program Succeeded.
Operation Succeeded
All good, and takes about 12 seconds, however, after that the pickit4 turns off the power target, and the pickit LED is BLUE (I guess state "ready")
The main question is how can I let the pickit4 powering the boards? any specific parameter? (I cannot find on the readme.html)
If I use MPLAB X IPE GUI to program, the programming is much quicker (3 or 4 seconds), the pickit LED is YELLOW and the target is left powered on. (I selected "release from reset")
I have tried to get the log out with as many details as possible, but I cannot see the commands sent to the pickit4.
Any idea? thanks
I realize that it's been a while since you asked, but i put the answer here for anyone who needs it. Add -OL to your command line options.
I've build an image for my Jetson Nano with yocto using the meta-tegra layer.
This build is using u-boot as bootloader which is set to save the environment on an MMC partition (mmcblk0p14).
gdisk -l /dev/mmcblk0 shows the following:
Number Start (sector) End (sector) Size Code Name
...
14 20996096 20998143 1024.0 KiB 8300 UBOOTENV
...
And the sector size is 512.
I've then configured u-boot-tegra/include/configs/p3450-porg.h with:
...
/* Env is located in it's own partition */
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV 1
#define CONFIG_ENV_OFFSET (20996096 * 512)
...
Where CONFIG_ENV_OFFSET = Start_Sector * Block_Size
This works fine (as far as I can see) as the environment is saved successfully to MMC when i use saveenv.
However, the environment i get when i print it in u-boot shell is NOT the same as when i print the environment with fw_printenv u-boot tool. I have set the /etc/fw_env.config to:
# Device name Device offset Env size
/dev/mmcblk0p14 0 0x2000
So what I've gathered is that, either the fw_env.config is set wrong or the u-boot environment is saved somewhere else on the MMC and no the partition 14.
Does anyone have suggestions to what i could try?
*****************************************************EDIT:*****************************************************
Doing dd if=/dev/mmcblk0p14 of=tmp.txt and reading the tmp.txt file shows the environment that the fw_printenv shows and not the environment I'm seeing in u-boot shell.
So something must be wrong in the u-boot-tegra/include/configs/p3450-porg.h configuration. I just wonder where it actually writes the environment to when i do a saveenv...
Any Idea what I can try to change?
As stated in the comments to the question, the offset is a 32-bit integer so attempting to give it the value of more than 4,294,967,295 (which 20996096 * 512 is) is not gonna work.
To fix it, I've rearranged my partition scheme to have my uboot environment partition as partition 1 instead of 14 and changed the fw_env.config and p3450-porg.h patch accordingly.
I'm having a problem with Skylake i7-6700 HQ laptop display (HD 530 graphics) brightness changes:
If the value changes by 20 it works.
If the value changes by 19 it only works in multiple-hundred jumps.
If the value changes by <19 there is no brightness change at all.
However on my old Ivybridge laptop i7-3630 QM (HD 4000 graphics) brightness successfully changes in steps of 1.
Here is the script for testing:
#!/bin/bash
# Test all brightness levels from 1 to max_brightness
# For Intel i7-6700 HQ HD 530 graphics:
# - When change is 18 steps brighhness doesn't change at all.
# - When change is 19 steps brightnesss changes on multi-hundred point jumps.
# - When change is 20 steps each change applied as expected.
# For Intel i7-3630QM steps of 1 work fine!
if [[ $(id -u) != 0 ]]; then
echo >&2 "$0 must be called with sudo powers"
exit 1
fi
cd /sys/class/backlight/*/
max=$(cat max_brightness)
save=$(cat brightness)
for (( i=1; i < max; i=i+20)); do
echo $i > brightness
echo setting brightness level: $i
sleep .005
done
echo $save > brightness
echo resetting brightness level from $max back to: $save
exit 0
I think my skylake is working fine other than weird temperatures reported for pch_skylake sensor:
$ paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/...$/.0°C/'
INT3400 Thermal 20.0°C
SEN1 56.0°C
SEN2 52.0°C
SEN3 57.0°C
SEN4 61.0°C
pch_skylake -44.0°C
B0D4 50.0°C
x86_pkg_temp 52.0°C
Other than that Linux intel micro-code is definitely activated on old laptop (Ubuntu 16.04) but may not be loaded on new laptop (Ubuntu 16.04.5).
Edit: Rebooted with Ubuntu 18.04.1 LTS, Kernel 4.15.0-36 and the same behaviour is witnessed.
Confirmation: I wonder if others have a Skylake laptop and can confirm hardware brightness works the same way.
Question: For the app I'm developing, do I have to put in a feature for each user to test smallest granular brightness change supported?
Backlight brightness is separate from the GPU proper; the iGPU that's part of the CPU chip just produces pixel data for the LCD, e.g. as a DisplayPort output. (Or in laptops, often an eDP lower-voltage signal).
Note that in a desktop, you can't adjust the backlight brightness with software; there's no connection from the normal GPU hardware / drivers with the backlight.
The software backlight control in laptops is pretty much separate from the iGPU, and has nothing to do with whether it's a Skylake or IvyBridge. The backlight control is a separate hardware device with separate I/O ports (or memory-mapped IO registers or whatever).
Finer granularity backlight adjustment is a property of the laptop design, not the CPU. Specifically of the backlight technology and controller hardware.
(This is my understanding, but I haven't actually looked at GPU or backlight / ACPI driver code in enough detail to be 100% sure this is accurate.)
I have no idea if it's possible for software to query the true / meaningful granularity; this answer is only to point out the misconception that it's dependent on the GPU or GPU drivers.
I am having often BSODs and WinDbg report similar corruption for most of them
4: kd> !chkimg -lo 50 -d !nt
fffff80177723e6d-fffff80177723e6e 2 bytes - nt!MiPurgeZeroList+6d
[ 80 fa:00 e9 ]
2 errors : !nt (fffff80177723e6d-fffff80177723e6e)
and
CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
fffff8021531ae6d-fffff8021531ae6e 2 bytes - nt!MiPurgeZeroList+6d
[ 80 fa:00 aa ]
2 errors : !nt (fffff8021531ae6d-fffff8021531ae6e)
What does it mean? What with what is compared and how it can be that corruption is similar? Does it explicitly indicates RAM problem?
UPDATE
What do these numbers mean? fffff80177723e6d and fffff8021531ae6d? What does it mean, that endings conincide?
What does the following code mean: nt!MiPurgeZeroList+6d?
I already answered this on superuser.com. Windbg downloads the original Exe/DLLs from the Symbol Server and now the chkimg command detects corruption in the images of executable files by comparing them to the copy on a symbol store.
All sections of the file are compared, except for sections that are
discardable, that are writeable, that are not executable, that have
"PAGE" in their name, or that are from INITKDBG. You can change this
behavior can by using the -ss, -as, or -r switches.
!chkimg displays any mismatch between the image and the file as an
image error, with the following exceptions:
Addresses that are occupied by the Import Address Table (IAT) are not checked.
Certain specific addresses in Hal.dll and Ntoskrnl.exe are not checked, because certain changes occur when these sections are loaded.
To check these addresses, include the -nospec option.
If the byte value 0x90 is present in the file, and if the value 0xF0 is present in the corresponding byte of the image (or vice
versa), this situation is considered a match. Typically, the symbol
server holds one version of a binary that exists in both uniprocessor
and multiprocessor versions. On an x86-based processor, the lock
instruction is 0xF0, and this instruction corresponds to a nop (0x90)
instruction in the uniprocessor version. If you want !chkimg to
display this pair as a mismatch, set the -noplock option.
If the RAM is fine, check the HDD / HDD cables for errors (disk diag tool and run chkdsk to detect and fix NTFS issues). You can also connect the HDD to different SATA port on the mainboard.
I am new to solaris OS, and trying to write a script which collects volume data from solaris box.
We did a similar script for Linux, and we used "df -P" command to list the volumes, and select the entries that start with "/dev".
By default, in linux, i could see a volume "/dev/sda1".
when i run df command on solaris box(df -k),i could not see any entry similar to (/dev/*) in my output.
When i mounted a CD, i could see an entry in df output as below.
/dev/dsk/c1t1d0s2 57632 57632 0 100% /media/VBOXADDITIONS_5.0.14_105127
So, in solaris, what is the pattern, i should look for to pick the volumes?
And, why am I not seeing at least one volume in the pattern /dev/
is it "/dev" or something else?
I am using solaris 11 image on oracle virtual box.
When i try "format" command, i could see 3 disks:
AVAILABLE DISK SELECTIONS:
0. c1d0 <VBOX HAR-8ea18e8b-2b2a0a5-0001-31.25GB> testvolu
/pci#0,0/pci-ide#1,1/ide#0/cmdk#0,0
1. c2d0 <VBOX HAR-b4343b55-dbed77c-0001 cyl 1020 alt 2 hd 64 sec 32>
/pci#0,0/pci-ide#1,1/ide#1/cmdk#0,0
2. c3t0d0 <ATA-VBOX HARDDISK-1.0 cyl 1009 alt 2 hd 64 sec 32>
/pci#0,0/pci8086,2829#d/disk#0,0
But, i dont see any partition in "df -k"
Also, i read here(https://docs.oracle.com/cd/E19455-01/805-6331/6j5vgg680/index.html), that disk names should be in "/dev/dsk/*" format.
Solaris 11 uses ZFS which has no one to one relationship between volumes (partitions) and file systems.
You can look at zpool status output to get the underlying devices.
$ zpool status
pool: rpool
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c1t0d0 ONLINE 0 0 0
Here, the whole c1t0d0 disk is used, hence no sx or px suffix.