I have a nucleo-144 board with stm32f746zg MCU. I'm trying to program the board with openocd, using gnu make and the makefile generated from stm32cubemx. I've added following line to my makefile to automate the flashing process:
flash: all
openocd -f interface/stlink.cfg -f target/stm32f7x.cfg -c "program $(BUILD_DIR)/$(TARGET).elf verify reset exit"
The code compiles without any problem and when I type make flash in the terminal the result is:
❯ make flash
openocd -f interface/stlink.cfg -f target/stm32f7x.cfg -c "program build/my-board.elf verify reset exit"
Open On-Chip Debugger 0.11.0 (2021-11-18) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK V2J33M25 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.236769
Info : stm32f7x.cpu: Cortex-M7 r0p1 processor detected
Warn : Silicon bug: single stepping may enter pending exception handler!
Info : stm32f7x.cpu: target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f7x.cpu on 3333
Error: couldn't bind gdb to socket on port 3333: No error
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002a18 msp: 0x20050000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
** Programming Started **
Info : device id = 0x10016449
Info : flash size = 1024 kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked
But the program doesn't run on the board and there's no blinking. I tried this in windows and wsl ubuntu. In both cases the results are the same. Also tried loading the binary file instead of .elf but again no luck.
Can somebody tell me what am I doing wrong here?
Ok. I'm not sure if I should post this as an answer, but the problem wasn't either openocd or the broken hardware.
When I started the project in cubemx, I initialized the default nucleo-f746zg peripherals and for some reason (probably one of the peripherals need higher clock frequency to work properly) in clock configuration the default clock source is selected as HSE and this option cannot be changed. On the other hand the nucleo board doesn't come with an external oscillator and it should be soldered by the user. So after generating the code and flashing it to the board it causes an error and the program doesn't run. Although, I think there was a block of code in clock configuration of HAL libraries that would "try" to use HSE and PLL as clock source and in case of not responding or any problem in settings, the HSI would be used as default source.
Anyway when I start the project from MCU selector in cubemx and don't use nucleo initializations, I can set the clock to HSI and everything works fine.
I've got a JTAG (J-Link more precisely) related problem.
I'm trying to connect by J-Link to raspberry pi 3b+ (bare-metal).
The probe finds the CPU and reads coresight ROM table, but there are missing information about Cross Trigger Interface (CTI). The units are available in the CPU according to ARM documentation.
There is a possibility to write a special script for J-Link, to set up CPU but documentation is poor and I do not know how to do it.
It there anyone who had or met with similar problem? Any advice how to run it?
Below is output from run of JLinkExe with attempt to connect:
./JLinkExe
SEGGER J-Link GDB Server V6.52c Command Line Version
JLinkARM.dll V6.52c (DLL compiled Oct 11 2019 15:44:50)
Command line: -if jtag -device Cortex-A53 -endian little -speed auto -port 2331 -swoport 2332 -telnetport 2333 -vd -ir -localhostonly 1 -singlerun -strict -timeout 0 -nogui -jlinkscriptfile /home/piotr/rpi.JLinkScript
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: on
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: /home/piotr/rpi.JLinkScript
J-Link settings file: none
------Target related settings------
Target device: Cortex-A53
Target interface: JTAG
Target interface speed: auto
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V10 compiled Oct 8 2019 14:57:57
Hardware: V10.10
S/N: 260111336
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.09 V
Listening on TCP/IP port 2331
Connecting to target...ERROR: CTI connected to core not found. Debugging not possible
ERROR: CTI connected to core not found. Debugging not possible
ERROR: Could not connect to target.
Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...
Shutting down...
Could not connect to target.
Please check power, connection and settings. piotr / opt JLink ./JLinkExe
SEGGER J-Link Commander V6.52c (Compiled Oct 11 2019 15:44:58)
DLL version V6.52c, compiled Oct 11 2019 15:44:50
Connecting to J-Link via USB...O.K.
Firmware: J-Link V10 compiled Oct 8 2019 14:57:57
Hardware version: V10.10
S/N: 260111336
License(s): FlashBP, GDB
OEM: SEGGER-EDU
VTref=3.085V
Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: CORTEX-A53
Type '?' for selection dialog
Device>
Please specify target interface:
J) JTAG (Default)
S) SWD
T) cJTAG
TIF>J
Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect
JTAGConf>
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "CORTEX-A53" selected.
Connecting to target via JTAG
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x4BA00477, IRLen: 04, CoreSight JTAG-DP
Scanning AP map
AP scan stopped (required AP found)
AP[0]: APB-AP
Scanning ROMTbl # 0x80000000
[0]Comp[0] # 0x80010000: Cortex-A53
[0]Comp[1] # 0x80011000: PMU-A53
[0]Comp[2] # 0x80012000: Cortex-A53
[0]Comp[3] # 0x80013000: PMU-A53
[0]Comp[4] # 0x80014000: Cortex-A53
[0]Comp[5] # 0x80015000: PMU-A53
[0]Comp[6] # 0x80016000: Cortex-A53
[0]Comp[7] # 0x80017000: PMU-A53
End of ROM table
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x4BA00477, IRLen: 04, CoreSight JTAG-DP
Scanning AP map
AP scan stopped (required AP found)
AP[0]: APB-AP
Scanning ROMTbl # 0x80000000
[0]Comp[0] # 0x80010000: Cortex-A53
[0]Comp[1] # 0x80011000: PMU-A53
[0]Comp[2] # 0x80012000: Cortex-A53
[0]Comp[3] # 0x80013000: PMU-A53
[0]Comp[4] # 0x80014000: Cortex-A53
[0]Comp[5] # 0x80015000: PMU-A53
[0]Comp[6] # 0x80016000: Cortex-A53
[0]Comp[7] # 0x80017000: PMU-A53
End of ROM table
****** Error: CTI connected to core not found. Debugging not possible
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x4BA00477, IRLen: 04, CoreSight JTAG-DP
Scanning AP map
AP scan stopped (required AP found)
AP[0]: APB-AP
Scanning ROMTbl # 0x80000000
[0]Comp[0] # 0x80010000: Cortex-A53
[0]Comp[1] # 0x80011000: PMU-A53
[0]Comp[2] # 0x80012000: Cortex-A53
[0]Comp[3] # 0x80013000: PMU-A53
[0]Comp[4] # 0x80014000: Cortex-A53
[0]Comp[5] # 0x80015000: PMU-A53
[0]Comp[6] # 0x80016000: Cortex-A53
[0]Comp[7] # 0x80017000: PMU-A53
End of ROM table
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x4BA00477, IRLen: 04, CoreSight JTAG-DP
Scanning AP map
AP scan stopped (required AP found)
AP[0]: APB-AP
Scanning ROMTbl # 0x80000000
[0]Comp[0] # 0x80010000: Cortex-A53
[0]Comp[1] # 0x80011000: PMU-A53
[0]Comp[2] # 0x80012000: Cortex-A53
[0]Comp[3] # 0x80013000: PMU-A53
[0]Comp[4] # 0x80014000: Cortex-A53
[0]Comp[5] # 0x80015000: PMU-A53
[0]Comp[6] # 0x80016000: Cortex-A53
[0]Comp[7] # 0x80017000: PMU-A53
End of ROM table
****** Error: CTI connected to core not found. Debugging not possible
Cannot connect to target.
You may find some of the information you need in this (detailed) article.
The (DBG/)CTI addresses you are looking for would then be:
set DBGBASE {0x80010000 0x80012000 0x80014000 0x80016000}
set CTIBASE {0x80018000 0x80019000 0x8001a000 0x8001b000}
Please note that you can test using OpenOCD, since it does support your J-Link EDU, by using the tcl/interface/jlink.cfg definition file, prior to resume your testing with J-Link commander.
You should use the trunk version of OpenOCD, since 0.10 does not support Armv8 form what I understand. The git repository is located here: git://repo.or.cz/openocd.git
Regarding the J-Link-specific script, you may search on the Segger support forum archives now that you know the CTI addresses, the information you are looking for may be available there. If not, just ask for help on the forum.
Update: you already asked for support on the forum I guess.
From the manual, page 218, you may just need to set CORESIGHT_Core-BaseAddr in your script - there is an example here.
I'm developing a tool that modifies LUKS partitions and disks.
Everything is working very well. Until now...
To handle disks properly as a non-root user, I added some polkit rules to change password, open partition, change crypttab and many others.
But, I'm seeing problems when I change crypttab and I need to run dracut to apply some dracut modules (dracut --force). Specially, the last one.
My user is part of admin group and I added a rule into sudoers file to not ask sudo password when my application is executed.
So, I decided to use this code:
gchar *dracut[] = {"/usr/bin/sudo", "/usr/bin/dracut", "--force", NULL};
if ((child = fork()) > 0) {
waitpid(child, NULL, 0);
} else if (!child) {
execvp("/usr/bin/sudo", dracut);
}
It is not working because SELinux is preventing to run this command:
SELinux is preventing /usr/bin/sudo from getattr access on the chr_file /dev/hpet.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that sudo should be allowed getattr access on the hpet chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sudo' --raw | audit2allow -M my-sudo
# semodule -X 300 -i my-sudo.pp
Additional Information:
Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context system_u:object_r:clock_device_t:s0
Target Objects /dev/hpet [ chr_file ]
Source sudo
Source Path /usr/bin/sudo
Port <Unknown>
Host <Unknown>
Source RPM Packages sudo-1.8.25p1-4.el8.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.14.1-61.el8.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name jcfaracco#hostname
Platform Linux jcfaracco#hostname 4.18.0-80.el8.x86_64 #1
SMP Wed Mar 13 12:02:46 UTC 2019 x86_64 x86_64
Alert Count 9
First Seen 2019-06-14 19:32:42 -03
Last Seen 2019-06-14 19:42:46 -03
Local ID 772b2c41-2302-4ee0-8886-52789eb63e22
Raw Audit Messages
type=AVC msg=audit(1560552166.658:199): avc: denied { getattr } for pid=2291 comm="sudo" path="/dev/hpet" dev="devtmpfs" ino=10776 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:clock_device_t:s0 tclass=chr_file permissive=0
type=SYSCALL msg=audit(1560552166.658:199): arch=x86_64 syscall=stat success=no exit=EACCES a0=7ffd4a6dffb0 a1=7ffd4a6def20 a2=7ffd4a6def20 a3=7fe845a73181 items=0 ppid=1756 pid=2291 auid=4294967295 uid=982 gid=980 euid=0 suid=0 fsuid=0 egid=980 sgid=980 fsgid=980 tty=tty1 ses=4294967295 comm=sudo exe=/usr/bin/sudo subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=stat AUID=unset UID=gnome-initial-setup GID=gnome-initial-setup EUID=root SUID=root FSUID=root EGID=gnome-initial-setup SGID=gnome-initial-setup FSGID=gnome-initial-setup
Hash: sudo,xdm_t,clock_device_t,chr_file,getattr
Do you know how to fix this issue? Any other idea to call dracut inside a C code is welcome too. In case of any other smart way to perform this issue.
Hope it's OK to jot this down, even if I cannot accept answer immediately (and hope it's OK for SO - as there is a C patch below):
It seems I screwed up the hard disk on my desktop PC ({DRDY err}). So I wanted to run a bootable media to run fsck, but the CD on this desktop is broken, so I can only use USB flash. I have a couple of USB thumbdrives with Ubuntu and Suse - these start booting on the desktop; but during boot, udev tries to detect hard drives, and since the hard disk is screwed, it just loops there, and the respective OS never finishes booting.
So I tried to download SystemRescueCd; I have this USB thumbdrive, on which I tried to install SystemRescueCD:
# lsusb with sudo, to retrieve all info
$ sudo lsusb -v -d 058f:6387 | grep -i 'id\|iManufacturer\|iProduct\|iSerial\|bInterface'
Bus 001 Device 043: ID 058f:6387 Alcor Micro Corp. Transcend JetFlash Flash Drive
idVendor 0x058f Alcor Micro Corp.
idProduct 0x6387 Transcend JetFlash Flash Drive
iManufacturer 1 takeMS
iProduct 2 Mem-drive Mini
iSerial 3 C5E7F0CC
bInterfaceNumber 0
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
# search by serial:
$ find /dev/disk/by-id/ -name '*C5E7F0CC*'
/dev/disk/by-id/usb-takeMS_Mem-drive_Mini_C5E7F0CC-0:0-part1
/dev/disk/by-id/usb-takeMS_Mem-drive_Mini_C5E7F0CC-0:0
# list and get device node
$ ls -la /dev/disk/by-id/usb-takeMS_Mem-drive_Mini_C5E7F0CC-0:0
lrwxrwxrwx 1 root root 9 2013-03-25 20:37 /dev/disk/by-id/usb-takeMS_Mem-drive_Mini_C5E7F0CC-0:0 -> ../../sdc
$ ls -la /dev/disk/by-id/usb-takeMS_Mem-drive_Mini_C5E7F0CC-0\:0-part1
lrwxrwxrwx 1 root root 10 2013-03-25 20:37 /dev/disk/by-id/usb-takeMS_Mem-drive_Mini_C5E7F0CC-0:0-part1 -> ../../sdc1
# it is /dev/sdc - list disk info
$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 2108 MB, 2108686336 bytes
94 heads, 29 sectors/track, 1510 cylinders
Units = cylinders of 2726 * 512 = 1395712 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0003e405
Device Boot Start End Blocks Id System
/dev/sdc1 * 1 1511 2059263+ c W95 FAT32 (LBA)
I tried to use my Ubuntu 11.04 Natty netbook to image the thumbdrive - and I used both
the recommended usb_inst.sh installer; and
I tried to use unetbootin (via sudo apt-get install unetbootin);
in both of these cases, when I try to boot the USB thumbdrive on the desktop, the boot procedure fails with:
SYSLINUX 4.02 debian-20101016 CHS Copyright (C) 1993-2010 H. Peter Anvin et al
ERROR: No configuration file found
No DEFAULT or UI configuration directive found!
boot:
.... with prompt at boot. (In fact, unetbootin fails at "Verifying DMI Pool Data", before entering syslinux - probably because it is much older than the .iso I'm trying to image).
First I checked the md5 as mentioned in No Default or UI Configuration Found!
$ md5sum ./systemrescuecd-x86-3.5.0.iso
48552b9e905872bd5061eb112b73ea20 ./systemrescuecd-x86-3.5.0.iso
... but it seems OK, as per Sysresccd-versions.
Then I tried to reformat the drive to FAT16 (via sudo gparted /dev/sdc); and repeated both usb_inst.sh and unetbootin methods - again no dice. Funny enough, in all of these cases, if I try to run the flash USB thumbdrive in the QEMU emulator:
# sudo apt-get install qemu
sudo qemu -hda /dev/sdc
... it boots fine - showing the syslinux menu and so on; however, boot always fails on the desktop.
Here I should mention, that I could write down the following from the boot screen of the problematic desktop PC:
Award Modular BIOS v6.00PG
AMDRS740 BIOS
It has a boot menu accessed via F12, and in the boot menu, among other options, these are for USB:
...
USB-FDD
USB-ZIP
USB-CDROM
USB-HDD
...
Typically, I choose USB-HDD - but I've tried the others; either the procedure freezes before even entering syslinux - or the boot fails as described above.
There is advice to rename directories/files manually from isolinux to syslinux (Trying to boot from usb - Ask Ubuntu) - when I used usb_inst.sh, only syslinux/isolinux.bin would have to be renamed. There is also advice to copy syslinux.cfg to the root of the USB flash thumbdrive (Cannot boot Live USB, Linux - Super User). But still no improvements - syslinux is still complaining that it is missing the configuration file - which apparently is the syslinux.cfg.
Then I tried to look if it is possible to somehow "debug" syslinux; found log tracing/debugging/trouble shooting in syslinux - The Syslinux Project - reboot.pro:
> Do we have specific commands to trace or log syslinux?
Being open source, one is able to compile Syslinux and enable extra debugging output.
also [SOLVED] Stuck on boot: Syslinux Problem [Archive] - Ubuntu Forums: "_
Debugging syslinux is described at http://www.syslinux.org/wiki/index.php/Development/Debugging , but effective debugging (if I recall correctly) requires recompiling it to add the debug hooks._". However, Development/Debugging - Syslinux Wiki talks about something called bochs; and I suspect that is to debug syslinux itself - not necessarily to "debug" (or query) the environment it is in.
Anyways, at last, I could see no way out but to get syslinux from source; basically, this was needed so it builds:
sudo apt-get install nasm
sudo apt-get install uuid-dev
git clone git://git.kernel.org/pub/scm/boot/syslinux/syslinux.git syslinux-git
cd syslinux-git/
make OPTFLAGS+=-DDEBUG=1
Turns out, it isn't really clear how to enable such debugging, that will show what syslinux "sees" when plugged in a given computer; given that I do load into syslinux at boot, the problem is what does it see as a filesystem. I tried to enable the DEBUG environment variable as shown above (after adding override OPTFLAGS := to the Makefile) - but that, in itself, generated no new messages during boot failure. I have used the following command to "burn" the USB thumbdrive (after unmounting it from the Gnome applet):
sudo ./linux/syslinux --stupid --directory /syslinux --install /dev/sdc1
... and I've tried both with stupid and without (and both for the source-built version, and the one from the Ubuntu package repositories for Natty).
Grepping through the source, I realized there is something called rosh (Read-Only SHell) - however, that compiles as a rosh.c32 - and one is supposed to have it as a boot kernel option in syslinux.cfg - which, as noted, I cannot load. So rosh.c32 is unfortunately not much help for my problem.
However, given that rosh implements the ls command, I tried to copy relevant portions into the code of syslinux - and trigger a ls / listing of the root when syslinux scans for the configuration file. With those changes, recorded in syslinux-e40ba60-rosh-ls.patch; now I get the following when I boot:
SYSLINUX 4.06 CHS 5-ge40ba60* Copyright (C) 1993-2010 H. Peter Anvin et al
Listing: "/"
rosh_ls_arg_dir 0 files found
Listing: "/syslinux"
Listing: ""
CurrentDirName: "/syslinux/"
confignamebuf: /syslinux/extlinux.conf; realpath -1
confignamebuf: /syslinux/syslinux.cfg; realpath -1
confignamebuf: /boot/syslinux/extlinux.conf; realpath -1
confignamebuf: /boot/syslinux/syslinux.cfg; realpath -1
confignamebuf: /syslinux/extlinux.conf; realpath -1
confignamebuf: /syslinux/syslinux.cfg; realpath -1
confignamebuf: /extlinux.conf; realpath -1
confignamebuf: /syslinux.cfg; realpath -1
ERROR: No configuration file found
No DEFAULT or UI configuration directive found!
Interestingly; for the root /, the _ls function at least returns "0 files"; the others ("/syslinux", and the empty string "") already fail at the opendir call - and so the _ls function doesn't even get called!
I would have thought that my slapstick copying of the ls function would not work as intended; but running the thumbdrive in qemu on netbook, does in fact provide a full listing of files - and given that at least for /, the function gets called and returns on the desktop - I'd suspect that it does indeed work.
However, that still doesn't solve my problem - why does syslinux, after boot, see 0 files under the root /? What else could I do to debug this problem? I wouldn't mind patching some C code into syslinux - but I just don't know what I should be looking for, that would point me to correct preparation of the USB thumbdrive for booting on the desktop machine...
OK, I got it to boot...
First, I noted there are alternative mbr's in the built git source as per Mbr - Syslinux Wiki and HowTos - Syslinux Wiki, so I tried both mbr.bin and altmbr.bin - altmbr.bin like this:
$ printf '\1' | cat mbr/altmbr.bin - | sudo dd bs=440 count=1 conv=notrunc iflag=fullblock of=/dev/sdc
... but that didn't help much.
Finally, I noted that lsusb says "bInterfaceProtocol 80 Bulk (Zip)"; and I remembered reading something about ZIP drives somewhere, so tried to look it up - and finally found this:
syslinux/doc/usbkey.txt
The proper mode to boot a USB key drive in is "USB-HDD". That is the
ONLY mode in which the C/H/S geometry encoded on the disk itself
doesn't have to match what the BIOS thinks it is. Since geometry on
USB drives is completely arbitrary, and can vary from BIOS to BIOS,
this is the only mode which will work in general.
Some BIOSes have been reported (in particular, certain versions of the
Award BIOS) that cannot boot USB keys in "USB-HDD" mode. This is a
very serious BIOS bug, but it is unfortunately rather typical of the
kind of quality we're seeing out of major BIOS vendors these days. On
these BIOSes, you're generally stuck booting them in USB-ZIP mode.
THIS MEANS THE FILESYSTEM IMAGE ON THE DISK HAS TO HAVE A CORRECT
ZIPDRIVE-COMPATIBLE GEOMETRY.
....
The script "mkdiskimage" which is supplied with the syslinux
distribution can be used to initialize USB keys in a Zip-like fashion.
To do that, calculate the correct number of cylinders (31 in the
example above), and, if your USB key is /dev/sda (CHECK THE KERNEL
MESSAGES CAREFULLY - IF YOU ENTER THE WRONG DISK DRIVE IT CANNOT BE
RECOVERED), run:
mkdiskimage -4 /dev/sda 0 64 32
(The 0 means automatically determine the size of the device, and -4
means mimic a zipdisk by using partition 4.)
So, as recommended there, first I find the number of cylinders for my thumbdrive:
$ grep 512-byte /var/log/syslog | tail -n 1
Mar 25 22:33:34 mypc kernel: [50884.608687] sd 45:0:0:0: [sdc] 4118528 512-byte logical blocks: (2.10 GB/1.96 GiB)
# get number of cylinders:
$ wcalc '4118528/(64*32)'
= 2011
... then I continue with mkdiskimage. After that was done, I tried usb_inst.sh again - and realized that it will overwrite the partition 4 that mkdiskimage made, and make a partition 1 for itself instead. That means, one should copy those files fron usb_inst.sh in a backup elsewhere, then run mkdiskimage - then finally copy the backed up files back to thumbdrive again; here is a command line log:
# mkdiskimage is present in syslinux-git:
$ ./utils/mkdiskimage
Usage: ./utils/mkdiskimage [-doFMz4][-i id] file c h s (max: 1024 256 63)
....
# ... but also in Debian/Ubuntu packaging of syslinux
$ mkdiskimage -4 /dev/sdc 0 64 32
/usr/bin/mkdiskimage: /dev/sdc: don't know how to determine the size of this device
# use sudo - note this command takes a while to complete:
$ sudo mkdiskimage -4 /dev/sdc 0 64 32
Warning: more than 1024 cylinders (2011).
Not all BIOSes will be able to boot this device.
$ ls /dev/sdc*
/dev/sdc /dev/sdc4
$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 2108 MB, 2108686336 bytes
64 heads, 32 sectors/track, 2011 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x866262cc
Device Boot Start End Blocks Id System
/dev/sdc4 * 1 2011 2059248 e W95 FAT16 (LBA)
# (make sure umounted / ejected)
# cd to usb_inst.sh directory; and
# run usb_inst.sh for /dev/sdc; note it will:
# write MBR and "Creating filesystem on /dev/sdc1..."
# and "installing boot loader on /dev/sdc1";
# regardless of the previous setup on partition 4:
sudo bash ./usb_inst.sh
# now no more partition 4:
$ ls /dev/sdc*
/dev/sdc /dev/sdc1
# ( mount /dev/sdc1 via disk applet )
$ rsync -a /media/SYSRESC /media/backup/
# ... duhh... - again now
# ( umount/eject via disk applet )
$ sudo mkdiskimage -4 /dev/sdc 0 64 32
Warning: more than 1024 cylinders (2011).
Not all BIOSes will be able to boot this device.
$ sudo ./linux/syslinux --install /dev/sdc4
# ( mount via disk applet )
$ rsync -a /media/backup/SYSRESC/ /media/31A8-40E9/
$ sudo qemu -hda /dev/sdc # works
# ( umount/eject via disk applet )
# boot on desktop - works! loads rescue64 and initram.igz...
The interesting thing is - even if there is the warning "Not all BIOSes will be able to boot this device."; somehow this problematic BIOS loads this thumbdrive without a problem (and the _ls function above lists fine). Also interesting - here I choose the USB-HDD boot option (not the USB-ZIP) and it still works ?!
So, as a partial answer - I guess the way to debug this, would be for syslinux to somehow write on the thumbdrive the CHS geometry it sees during the syslinux installation; and on boot, to query the BIOS (I guess) about which CHS geometry the BIOS sees - and then dump these two geometries to screen; if there is a mismatch, then it is likely one should run mkdiskimage (unfortunately, I wouldn't know how to code that into syslinux)
Going back to my original HDD problem - turns out also SystemRescueCD uses udev to probe for devices - and again the boot process cannot complete (even if I choose the boot option "all files to memory (docache)")... So I get messages like:
udevadm settle - timeout of 180 seconds reached, the event queue contains:
Activating dmraid (fake hardware raid) ...
Starting mdadm (linux software raid) ....
udevd[88] worker [91] unexpectedly returned with status 0x0100 ...
udevd[88] worker [91] failed while handling '/devices/pci0000:00/.../sdb/sdb1'
So, I either find a Live USB distro which does not probe for disks using udev - or I better take this HDD out, toss it into a HDD USB enclosure, and try fsck it on another computer (hopefully I'll be able to blacklist this drive from udev on a running system)
Edit Aug 24 2013: Back to this problem, I thought I'd jot down few extra notes:
Since I cannot yet afford the time to fix this PC and its faulty drive, I've used this USB thumbdrive to boot multiple operating systems: PartedMagic and SliTaz did also encounter errors on the hard disk - but apparently use different drivers to access it (so the DRDY ERR loop didn't start), and they could finish booting relatively fast. Then I tried building a custom Ubuntu 12.04 image (using ubuntu-builder) - and this one ended up in a DRDY ERR loop, which may take more than 5 minutes to complete, before the OS finishes booting. I have posted more about this in Bug #1216397 “
It should be possible to ignore (skip probing) a known bad disk partition at boot” : Bugs : “linux” package : Ubuntu.
There are a few interesting things in respect to syslinux, now that this USB thumbdrive is used to boot multiple operating systems. First of all, the thumbdrive is, still, first made bootable with syslinux --install while empty (which places a file ldlinux.sys in the partition's root) - which corresponds to the mkdiskimage step above; and only afterwards are files (like kernel images, and including /boot/syslinux/syslinux.cfg) copied to it.
Now, I'd first build the CD image ISO in ubuntu-builder, and test it using VirtualBox (as qemu on my machine is way too slow for that). Once the ISO image was shown to work as expected, then only the files under its casper directory are relevant for the USB thumbdrive thus prepared; and they can be referenced through a boot menu entry in syslinux.cfg. So, I'd edit the syslinux.cfg on the thumbdrive, and copy the casper image files (e.g. filesystem.squashfs) to the thumbdrive - and test it with qemu as above. Once this qemu step passed, I'd move the USB thumbdrive on the target PC with the broken drive - and interestingly, here I might get syslinux boot failures of multiple sorts (during different boot stages):
"No DEFAULT or UI configuration directive found!" (or sometimes a "Bad <something> ..." message), before the syslinux boot menu is shown - even if the debug, as above, would show that syslinux reads the filesystem on the thumbdrive correctly, and finds the /boot/syslinux/syslinux.cfg (which does have proper directives)!
"Invalid or corrupt kernel image", once the syslinux menu is shown, and the new kernel image (Ubuntu) chosen - even if the other images (found previously on the thumb) boot fine on the broken drive PC; and the new image boots fine from thumb in qemu on a different machine!
"/init: line 7: can't open /dev/sr0: no medium found", once the new (Ubuntu) image is chosen from syslinux menu, and it starts booting; this seems an Ubuntu specific message, appearing a few seconds after it starts booting. I still encounter it even if booting completes succesfully - when it's a problem, this message just loops repeatedly, not allowing the rest of the boot process to complete
It turns out, any of these can appear whenever I try to change and save the syslinux.cfg file on the thumbdrive; or when I make changes in the casper image files, and I rsync or copy them to the thumbdrive. Maybe the copying process (since it may change the sectors where the files are located on the thumb), "confuses" parts of the boot process - although, this shouldn't happen, since also the working procedure above starts from a blanked, syslinux'd thumbdrive, to which files are copied after; so I think this may point to failing sectors on the thumbdrive.
However, even in this state, the working procedure above seemed to be useful - because using it, I could recover the thumb back to a working state! In more detail, it goes like this:
Keep a copy of the thumbdrive files somewhere on a different disk (e.g. ~/thumbcopy) - but without the ldlinux.sys file.
Whenever you want to make a change (to syslinux.cfg or to bootable image files) - make sure this change is saved in ~/thumbcopy first
Now, say I've changed some files on the bootable thumbdrive directly, and I encounter one of the errors above. Then:
First, delete all files but the ldlinux.sys on the thumbdrive, e.g.: rm -rf $(ls -I"ldlinux.sys" /media/31A8-40E9/)
Then, rsync or copy (cp -arv ...) the files in ~/thumbcopy to the thumbdrive, e.g.: rsync -aP ~/thumbcopy/ /media/31A8-40E9/
Now, try boot the thumbdrive in the PC again - it usually boots fine!
I've encountered all three types of errors, because I'd often try to change/copy individual files directly in the thumbdrive: sometimes the change doesn't introduce a problem, so booting is fine - however, in many cases, it does introduce a problem. For some reason, using the above procedure I managed to recover the thumbdrive from either type of abovementioned problems - maybe it has to do with USB Flash delayed writes, maybe with USB Flash failing sectors, I cannot really tell... But in any case: deleting all files, and re-copying them in one go, does seem to be a worthwhile procedure to try in case of errors like that.
It's an ancient post, but in case others stumble upon this, I'll add an answer anyway.
If you're struggling to get syslinux to boot, ROSH (Read-only Shell) can be useful, as you mentioned. To start ROSH, you can simply type rosh at the boot: prompt (if you do have a working graphical menu, press escape to drop back to the boot: prompt.
Inside the shell, you have some basic commands to look around in your environment. For more documentation, see https://wiki.syslinux.org/wiki/index.php?title=Read-Only_SHell(rosh.c32)
I've been trying to build and boot OpenEmbedded-Core on the evaluation kit for Freescale's ARM i.MX28, using the Freescale ARM layer for OpenEmbedded-Core. Unfortunately, I can't find a basic "Getting Started" guide (though there is a Yocto getting-started guide). Unfortunately, I haven't been able to "get started", to the point of successfully booting to a basic command prompt on the board's debug serial port.
Here is what I've been able to piece together, and as far as I've managed to get so far.
Fetch sources
mkdir -p oe-core/freescale-arm
cd oe-core/freescale-arm
git clone git://git.openembedded.org/openembedded-core oe-core
git clone git://github.com/Freescale/meta-fsl-arm.git
cd oe-core
git clone git://git.openembedded.org/meta-openembedded
git clone git://git.openembedded.org/bitbake bitbake
Set up environment
. ./oe-init-build-env
That puts us in a new sub-directory build and sets certain environment variables.
Edit configuration
Edit the conf/bblayers.conf and local.conf files:
conf/bblayers.conf should have the meta-fls-arm and meta-oe layers added for BBLAYERS. E.g.:
BBLAYERS ?= " \
/home/craigm/oe-core/freescale-arm/oe-core/meta \
/home/craigm/oe-core/freescale-arm/oe-core/meta-openembedded/meta-oe \
${TOPDIR}/../../meta-fsl-arm \
"
In conf/local.conf, I set:
BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"
MACHINE = "imx28evk"
Build
bitbake core-image-minimal
I ran this build overnight, and it has completed successfully for me. Output files were in ~/oe-core/freescale-arm/oe-core/build/tmp-eglibc/deploy/images.
There are two boot options that I'd like to try, as described below. Boot from SD card is simpler, but takes quite a long time (~30 min) to write the image to the SD card. Booting from TFTP + NFS is faster, but requires more set-up.
Boot from SD Card
Write image to SD card:
sudo dd if=tmp-eglibc/deploy/images/core-image-minimal-imx28evk.sdcard of=/dev/sdc
It took something like 30 minutes (3.5 GB file). Then I put it in the board's SD card slot 0, and powered-up. It got as far as loading the kernel, then stopped:
U-Boot 2012.04.01-00059-g4e6e824 (Aug 23 2012 - 18:08:54)
Freescale i.MX28 family at 454 MHz
BOOT: SSP SD/MMC #0, 3V3
DRAM: 128 MiB
MMC: MXS MMC: 0
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: FEC0, FEC1
Hit any key to stop autoboot: 0
reading boot.scr
** Unable to read "boot.scr" from mmc 0:2 **
reading uImage
2598200 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-2.6.35.3-11.09.01+yocto-20
Created: 2012-08-23 7:53:40 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2598136 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Boot from TFTP + NFS
First, I tried to write U-Boot onto an SD card:
sudo dd if=tmp-eglibc/deploy/images/u-boot-imx28evk.mxsboot-sdcard of=/dev/sdc
Then I put it in the board's SD card slot 0, and powered-up. But all I got in the debug serial port was:
0x8020a01d
So, I decided to use Freescale's distribution of U-Boot for i.MX28 (from their LTIB distribution) onto an SD card. I set suitable U-Boot parameters for NFS booting with parameters from DHCP.
setenv bootargs console=ttyAMA0,115200n8
setenv bootargs_nfs setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=,v3,tcp fec_mac=${ethaddr}
saveenv
I connected to a DD-WRT router with the following DNSmasq settings:
dhcp-boot=,,192.168.250.106
dhcp-option=17,"192.168.250.106:/home/craigm/rootfs"
On my host PC, I set up a TFTP server to serve the uImage file from ~/oe-core/freescale-arm/oe-core/build/tmp-eglibc/deploy/images/.
I also set up a root NFS server to serve the root file system. I edited /etc/exports to serve /home/craigm/rootfs. I extracted the root file system:
bitbake meta-ide-support
rm -Rf ~/rootfs
runqemu-extract-sdk tmp-eglibc/deploy/images/core-image-minimal-imx28evk.tar.bz2 ~/rootfs
Then I put the U-Boot SD card in the board's SD card slot 0, and powered-up. It got as far as this, then stopped:
...
TCP cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
mxs-rtc mxs-rtc.0: setting system clock to 1970-01-01 00:03:33 UTC (213)
eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
eth1: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1)
Sending DHCP requests .
PHY: 0:00 - Link is Up - 100/Full
., OK
IP-Config: Got DHCP answer from 192.168.250.106, my address is 192.168.250.142
IP-Config: Complete:
device=eth0, addr=192.168.250.142, mask=255.255.255.0, gw=192.168.250.1,
host=192.168.250.142, domain=, nis-domain=(none),
bootserver=192.168.250.106, rootserver=192.168.250.106, rootpath=/home/craigm/rootfs
Looking up port of RPC 100003/3 on 192.168.250.106
Looking up port of RPC 100005/3 on 192.168.250.106
VFS: Mounted root (nfs filesystem) on device 0:15.
Freeing init memory: 160K
I'm not sure if it's running without a serial console, or some other problem. I can ping it on 192.168.250.142, but I can't Telnet or SSH to it.
Questions
Is there any sort of "getting started" guide for OpenEmbedded-Core on Freescale's i.MX28?
Is the Freescale ARM layer really intended for use with OpenEmbedded-Core, Yocto, or what? I don't really understand how those projects relate.
Has anyone else had success booting a minimal image of OpenEmbedded-Core on Freescale's i.MX28? If so, how did your procedure differ from mine?
I'm not sure at this stage whether the problem is just a non-functional serial console, or some other sort of issue. It's hard to diagnose these problems that prevent even getting a basic system running. Any pointers on how to diagnose at this point?
Why would the U-Boot be broken so it can't even boot?
From the boot message it looks like U-boot is working fine. U-boot is not broken.
The following boot message
2598200 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-2.6.35.3-11.09.01+yocto-20
Created: 2012-08-23 7:53:40 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2598136 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
By the above log u-boot has done its job.
"Booting the kernel" is the point where bootloader given the control to the kernel.
I guess the problem might be in kernel image or in memory.
To eliminate the problem of memory, try to check the manual and try to read and write in the RAM using the board's reference manual.
From the boot log RAM looks like has no problem. It has been initialized.
DRAM: 128 MiB
Check if the following message is not causing any problem.
* Warning - bad CRC, using default environment
Check if all the devices have been initialized and nothing is skipped after the bad crc warning.