I would like to boot an U-boot image from RAM using another U-boot. I loaded the U-boot image in the RAM using tftp tftp 0x90000000 u-boot.img and tried to run it with go 0x90000000 but nothing happens. I guess there are some conflicts concerning the initializations. When I went to the U-boot code, I found in the file /arch/arm/cpu/armv7/start.S the following comment do important init only if we don't start from memory!. So I have some questions.
First of all, is it possible to do that?
Any Idea of what are those important init?
And is there anything else I need to remove from the u-boot code?
I spent a couple of days trying to do the same thing in order to avoid the hassle of burning each new image version to flash, after all, if I have a working bootloader why not load a new version from it. I think this section of U-Boot documentation page explains perfectly why this not impossible.
If you want to start U-Boot from another boot loader, you must disable a lot of code, i. e. all initialization parts that already have been performed by this other boot loader...
The code you have to disable contains the most critical parts in U-Boot, i. e. these are the areas where 99% or more of all errors are located when you port U-Boot to a new hardware. In the result, your RAM image may work, but in the end you will need a full image to program the flash memory with it, and then you will have to enable all this highly critical and completely untested code.
Related
This question might be too broad and may not be easily understandable until you see actual code or what is happening, but I thought I should give at least a try. I am porting U-boot for RISCV cpu on MAX10 FPGA in its DDR3 Memory. I have made all the necessary configurations for my specific board and processor as mentioned in the README of U-boot and it is successfully built as well.
But, currently I am unable to get into U-boot application for some reason. Whenever I prompt it to enter into address that I have specified in CONFIG_SYS_LOAD_ADDR which is 0x80000000, it resets and starts from address 0x00000000. I don't have any idea that why is this happening. Can someone expert with this stuff help me?
Whenever I prompt it to enter into address that I have specified in CONFIG_SYS_LOAD_ADDR which is 0x80000000, it resets and starts from address 0x00000000.
CONFIG_SYS_LOAD_ADDR is merely a default load address for various U-Boot commands (e.g. tftpboot).
The symbol that does need to be defined is CONFIG_STANDALONE_LOAD_ADDR, which is used as the linker address for standalone applications.
The U-Boot standalone applications are built as non-relocatable code.
Since your application was built with an unknown default link address, it is unlikely to properly execute at 0x80000000.
If you haven't already, you should also perform a memory test using U-Boot's memtest.
Heading seems kinda weird, I am also not getting what exact should I write there, but hope I am able to make you understand what I want to do exactly!
- I will have Primary bootloader and secondary bootloader both will resides in different areas of memory (may be boot flash or program flash).
- One of bootloader will be active at a time and other will be inactive.
- Let consider, Primary bootloader is active, and now I will download my application firmware. I am also reading the active bootloader version from application firmware so that I can check whether I need to update bootloader.
- And If I need to update bootloader then inactive bootloader will be activated and it will replace previously active bootloader with updated one. And secondary bootloader will switch back to inactive mode. Thus secondary bootloader only become active when it have to update primary bootloader.
- In whole this process, I want to reserve some memory area for Primary bootloader version, secondary bootloader version, and some custom configuration data with fixed memory location and can be accessible from Primary, secondary as well as application firmware.
You'll need to understand the Linker files. I have yet to do this for the MX/MZ line but I have don this sort of thing on MANY dsPIC33's. Pretty much the following way: Bootloader gets a set amount of flash dedicated in the .gld usually a single page so it's easier to erase (0x400) then the Superboot loader (the secondary bootloader) is ONLY loaded into the PIC when you are actually loading a new bootloader. So what the superboot loader is is really a smaller application designed to simply update the bootloader and then jump to the reset address of the bootloader. I personally wouldn't keep the secondary/super bootload code in there all the time simply to avoid confusion later on. You can really do this using update techniques from outside the PIC. Again I can;t offer direct help with the PIC32 line but if you'd like to see example linker files for the dsPIC33 lines I can provide those.
I'm new to these devices and even if they are very cheap, I don't unnecessarily want to brick them.
I've used esptool to flash the NodeMCU firmware onto my modules. When doing so, I need to specify the address where the file(s) get written, which usually is 0x00000. Does that mean that the firmware actually contains the bootloader? Or is it located in a separate region on the flash?
If the bootloader itself is contained in the firmware file, an interrupted flashing process would render the module useless, I suppose?
Thanks for clarification!
You can't damage the module this way. I probably did a hundred flashes, some of which failed (e.g. due to a too high baud rate). The firmware itself does contain the bootloader at 0x000000, but that's a second-stage bootloader which can be exchanged arbitrarily. You shouldn't be able to overwrite the first-stage bootloader. Quoting from the man who created rBoot, an open-source alternative for the properitary Espressif booatloader at http://richard.burtons.org/:
The boot loader is written to the first sector of the SPI flash and is executed like any other program, the built in first stage boot loader does not know it is loading a second stage loader rather than any other program.
So what happens next? Well the second stage boot loader isn’t open source, it’s provided to us as a binary blob to use blindly.
In short: You cannot damage your module by writing nonsense to 0x00000. It will maybe execute some arbitrary code before it finds an invalid opcode, but that's not enough to make the CPU explode or the module to be damaged. Reflashing the firmware is enough to recover from a damaged second-stage bootloader.
So where is that first-stage bootloader exactly? From the comments at richard.burtons.org/2015/05/17/esp8266-boot-process, the creator answered this himself as:
Commentator: I have been figuring out if the first stage boot loader is in the processors ROM or in the Flash. I guess it is in the ROM. If this is in ROM then there is no risk of messing flash and leave the device useless.
Could you please confirm it.
Richard: That’s correct. Stage one is in rom and you can’t do anything to break it.
I have a project in mind and for that I require the kernel to boot up and bring me to a console window so that I can start working. [later I'll automate the process].
How do I accomplish it?
Well, I have downloaded the latest stable kernel source from kernel.org and I have tried editing the init/main.c file. But I have no idea what in the world was going on in that file [noob ^n].
Hence, I post this question for an answer.
I require the kernel to boot up and bring me to a console window so that I can start working.
The kernel doesn't do much by itself. In fact, it's unlikely you want to alter "main" in the kernel.
If you want to "run" the kernel, you'll also need a root filesystem and some user-space programs. If you want a minimal userland, you can use "busybox". Even better, buildroot will help you create a minimal userland + kernel.
You can even combine your root filesystem plus the kernel into a single binary. At runtime, it will uncompress userland into a ramdisk and run entirely from RAM. See initramfs. This is super-helpful for embedded systems. A minimal kernel+root filesystem can be around 1MB.
Go through below link
http://balau82.wordpress.com/2010/03/27/busybox-for-arm-on-qemu/
Just black screen after running Qemu
hi :
i was building kernel for my gentoo linux . when i start the kernel , i
got this message , and can't going on.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
non-volatile memory driver v1.3
i don't know how to solve this problem . and i need help . thanks .
Why don't you try to disable pci hotplug support in kernel (if I recall correctly is in main config menu / PCI support)? You probably don't need this.
I'm going to have to disagree with those voting to close, because I think there really is a question here, and the question is "How to debug this?"
I'm going to propose two approaches:
1) Studious approach: Learn about mechanisms intended for handling boot problems. See if you can increase the kernel debug message level. Disable un-needed drivers as Quizzo suggested.
2) Cowboy approach: grep the kernel sources for strings seen in the final messages, and start shotgunning all possibly relevant bits of code with your own "still alive at" printk messages. Once you know where it's hanging, figure out why and either remove that mechanism or fix it.
At an extreme there's also a tool for debugging the kernel - kgdb - which you could set up if you have a second machine available.
If you already have linux running on this box, see if there's a config.gz in /proc or in a boot folder which you can extract and compare to the configuration you are trying to compile. It might not be a bad idea to first recompile and test exactly the same version and configuration as you have running, and then make desired changes one by one.
Also you might see if there's odd hardware in your system you could temporarily remove. For example, an older PC I have has a bios that hangs during drive enumeration if I have a large USB external drive plugged in during boot.
i have solved the problem by enable all pci hotplug flag in kernel config file.
thinks all.