How to pass data from u-boot bootloader to QNX application via ram? - u-boot

Using QNX 6.5.x with u-boot as a bootloader, on an ATSAMA5d3x module.
We'd like to pass some amount of data, ~1.5kb, from the bootloader into QNX via RAM, rather than trying to pass it via flash storage.
Is there a mechanism to tell QNX to reserve an area of RAM and not touch it? This would let us mmap it from the QNX application to read the data out of it, without QNX using it for heap or otherwise zeroing it out.
Is there another approach you've used to pass data like this into QNX?

QNX startup-* programs permit the use of the -r argument to reserve a block of phyiscal address space. You can supply arguments to startup in the .build file for the bootstrap image (the source to mkifs).
Example:
[image=0x22000000]
[virtual=armle-v7,raw +compress] .bootstrap = {
# reserve 4k at paddr 0x20000000 and don't clear it
startup-atsama5d3x-ek -vvv -r 0x20000000,4096,1
# reset of boot code goes here
}
[+script] .script = {
# and so on
}
# and so forth
Ref: http://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.utilities/topic/s/startup_options.html

I try using qnx 6.5.0 on ATSAMA5d3x
I use default nand driver from bsp, but periodically(when try open some bin file) i get this error:
fs-etfs-sama5d3x: readcluster DATAERR on cluster xxxxxx
after reset all ok, i can run binary, but after a while this error will appear again
Why is this happening? You use default driver?
Maybe you know something
*Forgive me for asking in your question, too little information on qnx 6.5.0 on ATSAMA5d3x
enter image description here

Related

Compiling application to run not from the start of the flash stm32L4R9I

I have an steval-stwinkt1 board, that i am trying to enable support for DFU mode.
I flashed costume boot loader firmware on to the the start of the flash (0x8000000) that lets you load into another firmware that was uploaded by the DFU mode or to stay in the current program to flash new firmware throw the USB.
i used this st tutorial- https://www.youtube.com/watch?v=n_LDXOQHerU
I tried the .dfu package that comes with the STM32Cube and i saw that the program ran successfully so i assume that the bootloader works.
but when i try to make my own DFU package from my software the software never loads and i get hard fault. i moved the software according to the ST totorial & some research i done to 0x800C000 by changin the following lines:
in the FLASH.ld file:
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 2048K
to:
FLASH (rx) : ORIGIN = 0x800C000, LENGTH = 2048K
and in the stm32l4r9xx.h changed FLASH_BASE to:
#define FLASH_BASE (0x0800C000UL)
on another try i tried instead of changing FLASH_BASE to change VECT_TAB_OFFSET but it still didnt work.
to make the dfu package i use dfu-tool (i use linux) and use this command:
dfu-tool convert dfuse software.bin software.dfu
also tried to convert the hex int dfu package using the official tool that is used in the tutorial i used and still didnt work
what do i need to change to make my software works when i load the dfu package?
thanks
itay
It appears to me that you have overlooked the fact that your application-dedicated flash size is not going to be 2048K anymore, since your custom bootloader is now placed at the start of the flash. Therefore, you need to subtract the app's flash origin from the total flash size:
FLASH (rx) : ORIGIN = 0x800C000, LENGTH = 2048K - (ORIGIN(FLASH) - 0x8000000)
In such cases, a suggestion would be to try to debug the hard fault using the HardFault_Handler() and a bit of coding. You will then be able to extract and analyze the link register, program counter, program status register, etc. at the moment when hard fault occurred.

U-Boot: "go" vs "bootz" with zImage

I have a zImage for an ARM board. I consider zImage to be:
self extracting (that is to say "executable")
position independent
So, I guess, all I have to do is put zImage to DDR at some 0xADDRRESS and
then just jump to the 0xADDRRESS. But using U-Boot's go 0xADDRRESS doesn't get my kernel going, while bootz 0xADDRRESS does.
What am I missing? Why a simple jump (go) is not enough? What's special about bootz?

Copy files from emmc via uboot to tftp-server

i got the problem that a device isnt booting up into linux.
It just holds on "Starting kernel ...".
To get a better grip on what goes wrong i thought it would be nice to get access to the logs from linux.
I can access the userland from uboot via "ls":
Zynq> ls mmc 0:2
ostree/deploy/poky/deploy/9d325972b955e6584d3fad0a7ff1bf1a8.0/etc
<DIR> 2048 .
<DIR> 1024 ..
<DIR> 1024 modprobe.d
0 motd
<DIR> 1024 xdg
<DIR> 1024 logrotate.d
58 rpcbind.conf
1633 inputrc
828 mke2fs.conf
15 timestamp
10929 login.defs
324 issue
<DIR> 1024 sudoers.d
etc ...
Now im looking for a way to copy files from the userland to another device(remote-pc).
I learned about "tftpput" which is available in uboot.
My problem is that "tftpput" expects a save address and size. But i dont know how to get those information.
tftpput - TFTP put command, for uploading files to a server
Usage:
tftpput Address Size [[hostIPaddr:]filename]
I was not able to find a good documentation on "tftpput". Maybe someone has a link for me or provide me a small "how to" about this?
Thanks in advance
To answer the specific question, you need a tftp server on another machine. Then when you use 'load' to bring a file into memory you will now have that address, $filesize will now be set for you (for the size parameter) and the machine you setup a tftp server on is the final part of the command.
That said, if you only see "Starting kernel" and nothing else, it is quite likely that the linux kernel isn't getting to the point where the rootfs is mounted, userland runs and you're going to see log files. Without more information it's hard to say what you need to do here, but your bootargs are the first place to make sure are correct.
To analyze why the kernel is not booting you could enable the early console.
For ARM 64bit systems the early console is enabled via the kernel command line parameters. U-Boot takes these from the environment variable bootargs.
The arguments for earlycon depend on your board, e.g. for the Odroid C2:
setenv bootargs earlycon=meson,0xc81004c0
For an early console on 32bit ARM system you will have to compile the kernel with appropriate configuration options, e.g. for the Banana Pi:
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_SUNXI_UART0=y
CONFIG_EARLY_PRINTK=y
lets assume that file.txt has 16bytes of size (it is 10 in hex)
First it is necessary load the file into the memory
fatload mmc 1:1 0x40400000 file.txt
Then you can send it to tftp server:
tftpput 0x40400000 10 192.168.7.1:filetxt

Can I easily compile u-boot with more commands for arm versatile bp

I have compiled u-boot from u-boot-2013.01.y branch for versatilebp board (arm), and I need fatload command that is not present in this configuation.
I'm running u-boot under qemu
DRAM: 128 MiB
WARNING: Caches not enabled
Using default environment
In: serial
Out: serial
Err: serial
Net: SMC91111-0
Warning: SMC91111-0 using MAC address from net device
VersatilePB # fat
Unknown command 'fat' - try 'help'
VersatilePB # help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
dhcp - boot image via network using DHCP/TFTP protocol
env - environment handling commands
erase - erase FLASH memory
flinfo - print FLASH memory information
go - start application at address 'addr'
help - print command description/usage
iminfo - print header information for application image
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing address)
mtest - simple RAM read/write test
mw - memory write (fill)
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
reset - Perform RESET of the CPU
setenv - set environment variables
tftpboot- boot image via network using TFTP protocol
version - print monitor, compiler and linker version
VersatilePB #
I need fatload to load file containing image of fat filesystem containing kernel of freebsd. Can I somehow change compile config for that board to compile u-boot with fatload command? Or it's just not possible/not supported for that board?
Having done more or less exactly this for a Versatile AB, it's most certainly possible. The simplest way is to find where that board's command set is defined, and hack in the commands you want by defining the relevant CONFIG_CMD_* symbols. In this case, that place is include/configs/versatile.h.
Looking at my checkout of 2015.07, I seem to have added, among others (I think I was trying to convince the MMC to work at the time), these lines:
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION 1

How to recover from infinite reboot loops in NodeMCU?

My NodeMCU program has gone in to infinite reboot loop.
My code is functionally working but any action I try to do, e.g. file.remove("init.lua") or even just =node.heap(), it panics and reboots saying: PANIC: unprotected error in call to Lua API (not enough memory).
Because of this, I'm not able to change any code or delete init.lua to stop automatic code execution.
How do I recover?
I tried re-flashing another version of NodeMCU, but it started emitting garbage in serial port.
Then, I recalled that NodeMCU had two extra files: blank.bin and esp_init_data_default.bin.
I flashed them at 0x7E000 and 0x7C000 respectively.
They are also available as INTERNAL://BLANK and INTERNAL://DEFAULT in the NodeMCU flasher.
This booted the new NodeMCU firmware, all my files were gone and I'm out of infinite reboot loop.
Flash the following files:
0x00000.bin to 0x00000
0x10000.bin to 0x10000
And, the address for esp_init_data_default.bin depends on the size of your module's flash.
0x7c000 for 512 kB, modules like ESP-01, -03, -07 etc.
0xfc000 for 1 MB, modules like ESP8285, PSF-A85
0x1fc000 for 2 MB
0x3fc000 for 4 MB, modules like ESP-12E, NodeMCU devkit 1.0, WeMos D1 mini
Then, after flashing those binaries format its file system (run "file.format()" using ESPlorer) before flashing any other binaries.
Downloads Link
I've just finished working through a similar problem. In my case it was end-user error that caused a need to forcibly wipe init.lua, but I think both problems could be solved similarly. (For completeness, my problem was putting a far-too-short dsleep() call in init.lua, leaving the board resetting itself immediately upon starting init.lua.)
I tried flashing new NodeMCU firmware, writing blank.bin and esp_init_data_default.bin to 0x7E000 and 0x7C000, and also writing 0x00000.bin to 0x00000 and 0x10000.bin to 0x10000. None of these things helped in my case.
My hardware is an Adafruit Huzzah ESP8266 breakout (ESP-12), with 4MB of flash.
What worked for me was:
Download the NONOS SDK from Espressif (I used version 1.5.2 from http://bbs.espressif.com/viewtopic.php?f=46&t=1702).
Unzip it to get at boot_v1.2.bin, user1.1024.new.2.bin, blank.bin, and esp_init_data_default.bin (under bin/ and bin/at/).
Flash the following files to the specified memory locations:
boot_v1.2.bin to 0x00000
user1.1024.new.2.bin to 0x010000
esp_init_data_default.bin to 0xfc000
blank.bin to 0x7e000
Note about flashing:
I used esptool.py 1.2.1.
Because of the nature of my problem, I was only able to write changes to the flash when in programming mode (i.e. after booting with GPIO0 held down to GND).
I found that I needed to reset the board between each step (else invocations of esptool.py after the first would fail).
Erased the flash. esptool.py --port <your/port> erase_flash
Then I was able to write a new firmware. I used a stock nodeMCU 0.9.5 just to isolate variables, but I strongly suspect any firmware would work at this point.
The only think that worked for me was python flash tool esptool in ubuntu, windows flashtool never deleted init.lua and reboot loop.
Commands (ubuntu):
git clone https://github.com/themadinventor/esptool.git
cd esptool
python esptool.py -h
ls -l /dev/tty*
nodemcu_latest.bin can be downloaded from github or anywhere.
sudo python esptool.py -p /dev/ttyUSB0 --baud 460800 write_flash --flash_size=8m 0 nodemcu_latest.bin

Resources