The document summarizes the bootstrap procedure of the u-boot bootloader. It begins by initializing the CPU and hardware, setting up the stack pointer for early board initialization. It then performs early board initialization, calculates addresses for relocating the binary, performs the relocation, and sets up the stack pointer for common board initialization. Finally, it performs common board initialization and jumps into the main loop to complete the remaining initialization processes.
This document provides an overview of the steps to port the U-boot bootloader to a new SoC using the NDS32 architecture as an example. It describes the directory structure of U-boot and key files related to the architecture, board, configuration, and device drivers. The document outlines where to define SoC hardware addresses, initialize board-specific peripherals, configure options, and implement device drivers to support the new SoC and board.
The conversion of the ARM Linux kernel over to the Device Tree as the mechanism to describe the hardware has been a significant change for ARM kernel developers. Nowadays, all developers porting the Linux kernel on new ARM platforms, either new SOCs or new boards, have to work with the Device Tree. Based on practical examples, this talk intends to provide a ""getting started guide"" for newcomers in the Device Tree world: what is the Device Tree? How is it written and compiled? How do the bootloader and kernel interact? How are Device Tree bindings written and documented? What are the best practices for writing Device Trees and their bindings?
Video available at https://www.youtube.com/watch?v=m_NyYEBxfn8.
This document provides an overview of WiredTiger, an open-source embedded database engine that provides high performance through its in-memory architecture, record-level concurrency control using multi-version concurrency control (MVCC), and compression techniques. It is used as the storage engine for MongoDB and supports key-value data with a schema layer and indexing. The document discusses WiredTiger's architecture, in-memory structures, concurrency control, compression, durability through write-ahead logging, and potential future features including encryption and advanced transactions.
Yocto Project Open Source Build System and Collaboration InitiativeMarcelo Sanz
The Yocto Project creates a custom embedded Linux distribution for a device by building recipes that define how to obtain, patch, compile and package software, rather than using an existing Linux distribution. It provides a common build environment and tools to configure, build and test embedded systems across different processor architectures.
The document summarizes Linux synchronization mechanisms including semaphores and mutexes. It discusses:
1. Semaphores can be used to solve producer-consumer problems and are implemented using a count and wait list.
2. Mutexes enforce serialization on shared memory and have fast, mid, and slow paths for lock and unlock. The mid path uses optimistic spinning and OSQs.
3. Only the lock owner can unlock a mutex, and mutexes transition to the slow path if the owner is preempted, a spinner is preempted, or the owner sleeps.
The document proposes several extensions to the RISC-V ISA to improve code size efficiency. It analyzes benchmark programs to identify optimization opportunities where common instruction sequences can be fused into single instructions. New instructions proposed include TBLJAL for table-based function calls and jumps, PUSHPOP for saving/restoring multiple registers, and MULIADD for fusing load, multiply and add instructions. Evaluation shows the proposed instructions reduce code size by up to 10% on average across benchmarks when implemented in the compiler.
This document provides performance comparisons of AMD Ryzen processors versus Intel processors. It shows that Ryzen processors have advantages over their Intel counterparts in various workloads like gaming, content creation, and multi-threaded tasks. The document also outlines the "Zen" microarchitecture of Ryzen processors and how it enables strong multi-threaded performance. Product stacks for both AMD and Intel are shown to compare their mainstream, high-performance, and enthusiast-level processors.
The embedded Linux boot process involves multiple stages beginning with ROM code that initializes hardware and loads the first stage bootloader, X-Loader. The X-Loader further initializes hardware and loads the second stage bootloader, U-Boot, which performs additional initialization and loads the Linux kernel. The kernel then initializes drivers and mounts the root filesystem to launch userspace processes. Booting can occur from flash memory, an eMMC/SD card, over a network using TFTP/NFS, or locally via UART/USB depending on the boot configuration and available devices.
This document provides an overview of the steps to port the U-boot bootloader to a new SoC using the NDS32 architecture as an example. It describes the directory structure of U-boot and key files related to the architecture, board, configuration, and device drivers. The document outlines where to define SoC hardware addresses, initialize board-specific peripherals, configure options, and implement device drivers to support the new SoC and board.
The conversion of the ARM Linux kernel over to the Device Tree as the mechanism to describe the hardware has been a significant change for ARM kernel developers. Nowadays, all developers porting the Linux kernel on new ARM platforms, either new SOCs or new boards, have to work with the Device Tree. Based on practical examples, this talk intends to provide a ""getting started guide"" for newcomers in the Device Tree world: what is the Device Tree? How is it written and compiled? How do the bootloader and kernel interact? How are Device Tree bindings written and documented? What are the best practices for writing Device Trees and their bindings?
Video available at https://www.youtube.com/watch?v=m_NyYEBxfn8.
This document provides an overview of WiredTiger, an open-source embedded database engine that provides high performance through its in-memory architecture, record-level concurrency control using multi-version concurrency control (MVCC), and compression techniques. It is used as the storage engine for MongoDB and supports key-value data with a schema layer and indexing. The document discusses WiredTiger's architecture, in-memory structures, concurrency control, compression, durability through write-ahead logging, and potential future features including encryption and advanced transactions.
Yocto Project Open Source Build System and Collaboration InitiativeMarcelo Sanz
The Yocto Project creates a custom embedded Linux distribution for a device by building recipes that define how to obtain, patch, compile and package software, rather than using an existing Linux distribution. It provides a common build environment and tools to configure, build and test embedded systems across different processor architectures.
The document summarizes Linux synchronization mechanisms including semaphores and mutexes. It discusses:
1. Semaphores can be used to solve producer-consumer problems and are implemented using a count and wait list.
2. Mutexes enforce serialization on shared memory and have fast, mid, and slow paths for lock and unlock. The mid path uses optimistic spinning and OSQs.
3. Only the lock owner can unlock a mutex, and mutexes transition to the slow path if the owner is preempted, a spinner is preempted, or the owner sleeps.
The document proposes several extensions to the RISC-V ISA to improve code size efficiency. It analyzes benchmark programs to identify optimization opportunities where common instruction sequences can be fused into single instructions. New instructions proposed include TBLJAL for table-based function calls and jumps, PUSHPOP for saving/restoring multiple registers, and MULIADD for fusing load, multiply and add instructions. Evaluation shows the proposed instructions reduce code size by up to 10% on average across benchmarks when implemented in the compiler.
This document provides performance comparisons of AMD Ryzen processors versus Intel processors. It shows that Ryzen processors have advantages over their Intel counterparts in various workloads like gaming, content creation, and multi-threaded tasks. The document also outlines the "Zen" microarchitecture of Ryzen processors and how it enables strong multi-threaded performance. Product stacks for both AMD and Intel are shown to compare their mainstream, high-performance, and enthusiast-level processors.
The embedded Linux boot process involves multiple stages beginning with ROM code that initializes hardware and loads the first stage bootloader, X-Loader. The X-Loader further initializes hardware and loads the second stage bootloader, U-Boot, which performs additional initialization and loads the Linux kernel. The kernel then initializes drivers and mounts the root filesystem to launch userspace processes. Booting can occur from flash memory, an eMMC/SD card, over a network using TFTP/NFS, or locally via UART/USB depending on the boot configuration and available devices.
Linux uses /proc/iomem as a "Rosetta Stone" to establish relationships between software and hardware. /proc/iomem maps physical memory addresses to devices, similar to how the Rosetta Stone helped map Egyptian hieroglyphs to Greek and decode ancient Egyptian texts. This virtual file allows the kernel to interface with devices by providing address translations between physical and virtual memory spaces.
Have a quick overview of most of the embedded linux components and their details. How ti build Embedded Linux Hardware & Software, and developing Embedded Products
This document discusses Andes Technology Corporation's RISC-V processor IP solutions. It summarizes that Andes is a leading RISC-V CPU IP vendor that provides a portfolio of RISC-V processor cores ranging from embedded control to application processing. It also develops tools like the AndeSight IDE and provides customization services through its AndeSentry security framework and scalable acceleration architecture.
Viller Hsiao presents information on Linux vsyscall and vDSO. vDSO (virtual dynamic shared object) is mapped into userspace and contains implementations of common system calls to make them faster. It gets benefits from ASLR and allows additional system calls compared to the older vsyscall method. The kernel generates the vDSO shared object which is then loaded and accessed by the glibc dynamic linker to provide optimized system call implementations to applications.
Continguous Memory Allocator in the Linux KernelKernel TLV
Agenda:
Continguous Memory Allocator - how to allocate large continguous memory for large scale DMA in the kernel.
Speaker:
Mark Veltzer - CTO of Hinbit and a senior instructor at John Bryce. Mark is also a member of the Free Source Foundation and contributes to many free projects.
Основные темы, затронутые на семинаре:
Задачи и компоненты подсистемы управления памятью;
Аппаратные возможности платформы x86_64;
Как описывается в ядре физическая и виртуальная память;
API подсистемы управления памятью;
Высвобождение ранее занятой памяти;
Инструменты мониторинга;
Memory Cgroups;
Compaction — дефрагментация физической памяти.
GPU compute has leveraged discrete GPUs for a fairly limited set of academic and supercomputing system workloads until recently. With the increase in performance of integrated GPU inside an Accelerated Processing Unit (APU), introduction of Heterogeneous System Architecture (HSA) devices, and proliferation of programming tools, we are seeing GPU compute make its way into mainstream applications. In this presentation we cover GPU compute and HSA, focusing on the application of GPU compute in the Medical and Print Imaging segments. Examples of performance data are reviewed and the case is made for how GPU compute can deliver tangible benefits.
Este documento presenta el "Código de Gilwell", una serie de 12 principios que deben guiar a los adiestradores scout. Los principios incluyen ofrecer amistad y comprensión, dar el ejemplo, ser eficientes y estar actualizados, tratar a los participantes como adultos, mantener una actitud positiva, lealtad, sentido del humor y esfuerzo. El objetivo es que los adiestradores creen un ambiente de aprendizaje efectivo basado en la confianza y el respeto mutuo.
U-Boot is an open source bootloader used widely in embedded systems. It initializes hardware and loads the operating system kernel. The document provides an overview of U-Boot from the user and developer perspectives, including its features, build process, file structure, and boot sequence. It also discusses modernizing efforts like adopting the driver model, device tree, and Kbuild configuration system to improve compatibility and support new platforms.
This document discusses Linux kernel debugging. It provides an overview of debugging techniques including collecting system information, handling failures, and using printk(), KGDB, and debuggers. Key points covered are the components of a debugger, how KGDB can be used with gdb to debug interactively, analyzing crash data, and some debugging tricks and print functions.
Arm device tree and linux device driversHoucheng Lin
This document discusses how the Linux kernel supports different ARM boards using a common source code base. It describes how device tree is used to describe hardware in a board-agnostic way. The kernel initializes machine-specific code via the device tree and initializes drivers by matching compatible strings. This allows a single kernel binary to support multiple boards by abstracting low-level hardware details into the device tree rather than the kernel source. The document also contrasts the ARM approach to the x86 approach, where BIOS abstraction and standardized buses allow one kernel to support most x86 hardware.
U-Boot project has evolved in the time span of over 17 years and so as its complexity and its uses. This has made it a daunting task in getting started with its development and uses. This talk will address all these issues start with overview, features, efforts created by community and future plans.
The U-Boot project has evolved in the time span of over 17 years and so as its complexity and its uses. This has made it a daunting task in getting started with its development and uses. This talk will address all these issues and share development efforts created by the U-Boot community.
In this talk Jagan Teki(Maintainer for Allwinner SoC, SPI, SPI FLASH Subsystems) will introduce U-Boot from scratch with a brief overview of U-Boot history, U-Boot Proper, SPL, TPL, Build process and Startup sequence. He will talk about other preliminaries such as Image booting, Falcon Mode, Secure Boot and U-Boot features like device tree, device overlays, driver model and DFU, etc.
Once giving enough introduction, he will also talk about steps to port U-Boot to new hardware with a demo, along with U-Boot testing process. Finally, he will address and review ongoing development work, issues and future development regarding U-Boot.
The document discusses QEMU and adding a new device to it. It begins with an introduction to QEMU and its uses. It then discusses setting up a development environment, compiling QEMU, and examples of existing devices. The main part explains how to add a new "Devix" device by creating source files, registering the device type, initializing PCI configuration, and registering memory regions. It demonstrates basic functionality like interrupts and I/O access callbacks. The goal is to introduce developing new emulated devices for QEMU.
ISSCC 2018: "Zeppelin": an SoC for Multi-chip ArchitecturesAMD
This document describes the "Zeppelin" system-on-a-chip designed for multi-chip architectures. Key aspects include an 8-core "Zen" CPU complex, AMD Infinity Fabric interconnect, memory and I/O capabilities. The chip is designed for use in both single-die desktop and multi-die server configurations to provide scalability across markets using the same underlying SoC design.
The document summarizes the use of LLVM for code generation when recompiling Nintendo games as native games. LLVM provides a full compiler infrastructure that can be used to generate code for various platforms from a common intermediate representation (LLVM bitcode). The document discusses using LLVM for code generation from 6502 assembly to generate native code for emulation. Optimizations available through LLVM are also discussed.
Bootstrap process of u boot (NDS32 RISC CPU)Macpaul Lin
The bootstrap procedure of the u-boot bootloader involves:
1. Relocating the binary from flash/ROM to DRAM without adjustments through memory remapping.
2. Performing a general relocation of the binary in DRAM which involves adjusting addresses.
3. Initializing hardware and memory before jumping to the main initialization code.
This document discusses Device Tree, which is a data structure used to describe hardware platforms in Linux. It consists of a series of named nodes and properties. Device Tree is compiled from a Device Tree Source file (.dts) into a binary blob (.dtb) by a Device Tree Compiler. It allows hardware information to be passed to the operating system at boot time without needing to be encoded in code. The format and common uses of Device Tree are explained along with how drivers can probe for devices based on Device Tree properties and nodes.
The document discusses Linux device trees and how they are used to describe hardware configurations. Some key points:
- A device tree is a data structure that describes hardware connections and configurations. It allows the same kernel to support different hardware.
- Device trees contain nodes that represent devices, with properties like compatible strings to identify drivers. They describe things like memory maps, interrupts, and bus attachments.
- The kernel uses the device tree passed by the bootloader to identify and initialize hardware. Drivers match based on compatible properties.
- Device tree files with .dts extension can be compiled to binary blobs (.dtb) and overlays (.dtbo) used at boot time to describe hardware.
The procedure of imaging an Android device using dc3dd; introduction to the typical data storage and partition layout of the Android Os, concept of rooting on Android and the difference between a logical and a physical data extraction, physical imaging of the internal and external storage using dc3dd.
U-Boot is an open source boot loader that initializes hardware and loads operating systems. It supports many CPUs and boards. The boot process involves a pre-relocation phase where U-Boot initializes hardware and copies itself to RAM, and a post-relocation phase where it finishes hardware initialization and loads the kernel or operating system. Debugging can be done before and after relocation by setting breakpoints and examining memory.
ARM Linux Booting Process
One must be wondering How this Embedded Devices come to life? What goes into this devices that will tune to users Commands. We are going to explain about Embedded Arm based devices in general as The ARM architecture is a widely used 32-bit RISC processor architecture. In fact, the ARM family accounts for about 75% of all 32-bit CPUs, and about 90% of all embedded 32-bit CPUs.
Linux uses /proc/iomem as a "Rosetta Stone" to establish relationships between software and hardware. /proc/iomem maps physical memory addresses to devices, similar to how the Rosetta Stone helped map Egyptian hieroglyphs to Greek and decode ancient Egyptian texts. This virtual file allows the kernel to interface with devices by providing address translations between physical and virtual memory spaces.
Have a quick overview of most of the embedded linux components and their details. How ti build Embedded Linux Hardware & Software, and developing Embedded Products
This document discusses Andes Technology Corporation's RISC-V processor IP solutions. It summarizes that Andes is a leading RISC-V CPU IP vendor that provides a portfolio of RISC-V processor cores ranging from embedded control to application processing. It also develops tools like the AndeSight IDE and provides customization services through its AndeSentry security framework and scalable acceleration architecture.
Viller Hsiao presents information on Linux vsyscall and vDSO. vDSO (virtual dynamic shared object) is mapped into userspace and contains implementations of common system calls to make them faster. It gets benefits from ASLR and allows additional system calls compared to the older vsyscall method. The kernel generates the vDSO shared object which is then loaded and accessed by the glibc dynamic linker to provide optimized system call implementations to applications.
Continguous Memory Allocator in the Linux KernelKernel TLV
Agenda:
Continguous Memory Allocator - how to allocate large continguous memory for large scale DMA in the kernel.
Speaker:
Mark Veltzer - CTO of Hinbit and a senior instructor at John Bryce. Mark is also a member of the Free Source Foundation and contributes to many free projects.
Основные темы, затронутые на семинаре:
Задачи и компоненты подсистемы управления памятью;
Аппаратные возможности платформы x86_64;
Как описывается в ядре физическая и виртуальная память;
API подсистемы управления памятью;
Высвобождение ранее занятой памяти;
Инструменты мониторинга;
Memory Cgroups;
Compaction — дефрагментация физической памяти.
GPU compute has leveraged discrete GPUs for a fairly limited set of academic and supercomputing system workloads until recently. With the increase in performance of integrated GPU inside an Accelerated Processing Unit (APU), introduction of Heterogeneous System Architecture (HSA) devices, and proliferation of programming tools, we are seeing GPU compute make its way into mainstream applications. In this presentation we cover GPU compute and HSA, focusing on the application of GPU compute in the Medical and Print Imaging segments. Examples of performance data are reviewed and the case is made for how GPU compute can deliver tangible benefits.
Este documento presenta el "Código de Gilwell", una serie de 12 principios que deben guiar a los adiestradores scout. Los principios incluyen ofrecer amistad y comprensión, dar el ejemplo, ser eficientes y estar actualizados, tratar a los participantes como adultos, mantener una actitud positiva, lealtad, sentido del humor y esfuerzo. El objetivo es que los adiestradores creen un ambiente de aprendizaje efectivo basado en la confianza y el respeto mutuo.
U-Boot is an open source bootloader used widely in embedded systems. It initializes hardware and loads the operating system kernel. The document provides an overview of U-Boot from the user and developer perspectives, including its features, build process, file structure, and boot sequence. It also discusses modernizing efforts like adopting the driver model, device tree, and Kbuild configuration system to improve compatibility and support new platforms.
This document discusses Linux kernel debugging. It provides an overview of debugging techniques including collecting system information, handling failures, and using printk(), KGDB, and debuggers. Key points covered are the components of a debugger, how KGDB can be used with gdb to debug interactively, analyzing crash data, and some debugging tricks and print functions.
Arm device tree and linux device driversHoucheng Lin
This document discusses how the Linux kernel supports different ARM boards using a common source code base. It describes how device tree is used to describe hardware in a board-agnostic way. The kernel initializes machine-specific code via the device tree and initializes drivers by matching compatible strings. This allows a single kernel binary to support multiple boards by abstracting low-level hardware details into the device tree rather than the kernel source. The document also contrasts the ARM approach to the x86 approach, where BIOS abstraction and standardized buses allow one kernel to support most x86 hardware.
U-Boot project has evolved in the time span of over 17 years and so as its complexity and its uses. This has made it a daunting task in getting started with its development and uses. This talk will address all these issues start with overview, features, efforts created by community and future plans.
The U-Boot project has evolved in the time span of over 17 years and so as its complexity and its uses. This has made it a daunting task in getting started with its development and uses. This talk will address all these issues and share development efforts created by the U-Boot community.
In this talk Jagan Teki(Maintainer for Allwinner SoC, SPI, SPI FLASH Subsystems) will introduce U-Boot from scratch with a brief overview of U-Boot history, U-Boot Proper, SPL, TPL, Build process and Startup sequence. He will talk about other preliminaries such as Image booting, Falcon Mode, Secure Boot and U-Boot features like device tree, device overlays, driver model and DFU, etc.
Once giving enough introduction, he will also talk about steps to port U-Boot to new hardware with a demo, along with U-Boot testing process. Finally, he will address and review ongoing development work, issues and future development regarding U-Boot.
The document discusses QEMU and adding a new device to it. It begins with an introduction to QEMU and its uses. It then discusses setting up a development environment, compiling QEMU, and examples of existing devices. The main part explains how to add a new "Devix" device by creating source files, registering the device type, initializing PCI configuration, and registering memory regions. It demonstrates basic functionality like interrupts and I/O access callbacks. The goal is to introduce developing new emulated devices for QEMU.
ISSCC 2018: "Zeppelin": an SoC for Multi-chip ArchitecturesAMD
This document describes the "Zeppelin" system-on-a-chip designed for multi-chip architectures. Key aspects include an 8-core "Zen" CPU complex, AMD Infinity Fabric interconnect, memory and I/O capabilities. The chip is designed for use in both single-die desktop and multi-die server configurations to provide scalability across markets using the same underlying SoC design.
The document summarizes the use of LLVM for code generation when recompiling Nintendo games as native games. LLVM provides a full compiler infrastructure that can be used to generate code for various platforms from a common intermediate representation (LLVM bitcode). The document discusses using LLVM for code generation from 6502 assembly to generate native code for emulation. Optimizations available through LLVM are also discussed.
Bootstrap process of u boot (NDS32 RISC CPU)Macpaul Lin
The bootstrap procedure of the u-boot bootloader involves:
1. Relocating the binary from flash/ROM to DRAM without adjustments through memory remapping.
2. Performing a general relocation of the binary in DRAM which involves adjusting addresses.
3. Initializing hardware and memory before jumping to the main initialization code.
This document discusses Device Tree, which is a data structure used to describe hardware platforms in Linux. It consists of a series of named nodes and properties. Device Tree is compiled from a Device Tree Source file (.dts) into a binary blob (.dtb) by a Device Tree Compiler. It allows hardware information to be passed to the operating system at boot time without needing to be encoded in code. The format and common uses of Device Tree are explained along with how drivers can probe for devices based on Device Tree properties and nodes.
The document discusses Linux device trees and how they are used to describe hardware configurations. Some key points:
- A device tree is a data structure that describes hardware connections and configurations. It allows the same kernel to support different hardware.
- Device trees contain nodes that represent devices, with properties like compatible strings to identify drivers. They describe things like memory maps, interrupts, and bus attachments.
- The kernel uses the device tree passed by the bootloader to identify and initialize hardware. Drivers match based on compatible properties.
- Device tree files with .dts extension can be compiled to binary blobs (.dtb) and overlays (.dtbo) used at boot time to describe hardware.
The procedure of imaging an Android device using dc3dd; introduction to the typical data storage and partition layout of the Android Os, concept of rooting on Android and the difference between a logical and a physical data extraction, physical imaging of the internal and external storage using dc3dd.
U-Boot is an open source boot loader that initializes hardware and loads operating systems. It supports many CPUs and boards. The boot process involves a pre-relocation phase where U-Boot initializes hardware and copies itself to RAM, and a post-relocation phase where it finishes hardware initialization and loads the kernel or operating system. Debugging can be done before and after relocation by setting breakpoints and examining memory.
ARM Linux Booting Process
One must be wondering How this Embedded Devices come to life? What goes into this devices that will tune to users Commands. We are going to explain about Embedded Arm based devices in general as The ARM architecture is a widely used 32-bit RISC processor architecture. In fact, the ARM family accounts for about 75% of all 32-bit CPUs, and about 90% of all embedded 32-bit CPUs.
The board support package (BSP) provides hardware abstraction and initialization routines for the Linux kernel. It hides low-level hardware details and allows drivers and the kernel to work across different boards. Key BSP components include microprocessor support, board-specific routines for boot loading, memory mapping, interrupts, timers and power management. The BSP establishes the interface between the hardware and operating system.
The document provides an overview of Das U-Boot, a universal boot loader used to load operating systems and applications into memory on embedded systems. It discusses U-Boot's features such as its command line interface, ability to load images from different sources, and support for various architectures and boards. It also covers compiling and configuring U-Boot, as well as its basic command set and image support capabilities.
The U-Boot is an "Universal Bootloader" ("Das U-Boot") is a monitor program that is under GPL. This production quality boot-loader is used as default boot loader by several board vendors. It is easily portable and easy to port and to debug by supporting PPC, ARM, MIPS, x86,m68k, NIOS, Microblaze architectures. Here is a presentation that introduces U-Boot.
1. Embedded C requires compilers to create executable files that can be downloaded and run on microcontrollers, while C compilers typically generate code for operating systems on desktop computers.
2. Embedded systems often have real-time constraints and limited memory and other resources that require more optimization, unlike most desktop applications.
3. Programming for embedded systems focuses on optimally using limited resources and satisfying timing requirements using basic C constructs and function libraries.
1. Embedded C requires compilers to create files that can be downloaded and run on microcontrollers, while C compilers typically generate OS-dependent executables for desktop computers.
2. Embedded systems often have real-time constraints and limited memory/power that are usually not concerns for desktop applications.
3. Programming for embedded systems requires optimally using limited resources and satisfying real-time constraints, which is done using the basic C syntax and function libraries but with an embedded/hardware-oriented mindset.
A loader is a system program that loads programs into memory for execution. It performs functions like allocation of memory space, loading code and data into memory, relocation of code to adjust for different memory locations, and linking of subprograms. Loaders can be of different types like absolute, relocating, and direct linking loaders. A bootstrap loader is needed to initially load the operating system after self-tests.
This document describes a bootable operating system created by Shahzeb Pirzada and M. Faiz. It includes source code for a boot loader written in assembly language that displays the text "C:\Windows" on the screen. The boot loader is designed to run at physical address 0x7C00 and uses BIOS interrupts to display the message. It fills the remaining space with zeros and ends with the signature bytes 0xAA55 to mark it as a valid boot sector. NASM is used to assemble the source code into a bootable floppy disk image file.
This document discusses bootloaders for embedded systems. It defines a bootloader as the first code executed after a system powers on or resets that is responsible for loading the operating system kernel. The document then describes the tasks of a bootloader like initializing hardware, loading binaries from storage, and providing a shell. It outlines the booting process differences between desktops and embedded systems. Finally, it focuses on the universal bootloader U-Boot, describing its directory structure, configuration, building process, and commands.
This document provides an overview of boot loaders and memory management units (MMUs) on the iMX31 microcontroller. It discusses the iMX31 bootstrap ROM codes that help developers download and execute binary images in RAM or flash memory. It describes the iMX31 NAND flash boot mode where the first 2048 bytes of NAND are used to boot the system. It also discusses how Windows CE uses an Ethernet boot loader (eboot) to launch the kernel from NAND flash. Finally, it introduces concepts of MMUs like memory relocation, copy-on-write protection, and virtual memory translation.
The document provides information about the boot process on Linux systems from BIOS to kernel loading. It discusses:
- The boot sequence from BIOS performing self-test to loading the master boot record from the boot drive, then the boot loader (LILO or GRUB), and finally the kernel.
- How LILO and GRUB allow selecting operating systems and passing options to the kernel like the root filesystem.
- Common boot loader characteristics and how GRUB uses device names differently than Linux.
- How to recover from a failed boot by booting from removable media and reinstalling LILO or GRUB in the master boot record.
- Common kernel parameters and where to
The document discusses the key components of a computer system and how they work together to execute programs. It explains that the CPU performs a fetch-execute cycle to carry out instructions: it fetches instructions from memory one by one, decodes and executes them, and stores results. The CPU is connected to memory and I/O devices via buses that transmit addresses, data, and control signals. The memory hierarchy, from registers to cache to main memory to disk, aims to provide fast access to frequently used data. Efficient use of this hierarchy is crucial for good performance.
The BOOT LOADER is also known as Bootstrap Loader. The BOOT LOADER pattern describes the mechanisms that are necessary to start a computer, from being switched on, up to full operability. In order to run-up into a defined state of operation, with the operating system initialized and started, a sequence of single bootstrap steps is performed, each gaining a higher level of operability. This technique also supports flexibility in different dimensions, e.g. selecting a software version, a boot device, or even updating the whole software. General Purpose Computers (such as PCs, workstations, mainframes), Embedded Systems.
Loaders are system software programs that perform the loading function of placing programs into memory for execution. The fundamental processes of loaders include allocation of memory space, linking of object programs, relocation to allow loading at different addresses, and loading the object program into memory. There are different types of loaders such as compile-and-go loaders, absolute loaders, and linking loaders. Compile-and-go loaders directly place assembled code into memory locations for execution, while absolute loaders place machine code onto cards to later load into memory. Linking loaders allow for multiple program segments and external references between segments through the use of symbol tables and relocation information.
The document discusses routers and Cisco IOS. It describes how Cisco IOS is the operating system that controls routing and switching functions. It then explains the basic components and functions of routers, including memory components like ROM, RAM, NVRAM and Flash memory. It also discusses router interfaces, bootup sequence, and configuration modes.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
GraphSummit Singapore | The Future of Agility: Supercharging Digital Transfor...Neo4j
Leonard Jayamohan, Partner & Generative AI Lead, Deloitte
This keynote will reveal how Deloitte leverages Neo4j’s graph power for groundbreaking digital twin solutions, achieving a staggering 100x performance boost. Discover the essential role knowledge graphs play in successful generative AI implementations. Plus, get an exclusive look at an innovative Neo4j + Generative AI solution Deloitte is developing in-house.
Cosa hanno in comune un mattoncino Lego e la backdoor XZ?Speck&Tech
ABSTRACT: A prima vista, un mattoncino Lego e la backdoor XZ potrebbero avere in comune il fatto di essere entrambi blocchi di costruzione, o dipendenze di progetti creativi e software. La realtà è che un mattoncino Lego e il caso della backdoor XZ hanno molto di più di tutto ciò in comune.
Partecipate alla presentazione per immergervi in una storia di interoperabilità, standard e formati aperti, per poi discutere del ruolo importante che i contributori hanno in una comunità open source sostenibile.
BIO: Sostenitrice del software libero e dei formati standard e aperti. È stata un membro attivo dei progetti Fedora e openSUSE e ha co-fondato l'Associazione LibreItalia dove è stata coinvolta in diversi eventi, migrazioni e formazione relativi a LibreOffice. In precedenza ha lavorato a migrazioni e corsi di formazione su LibreOffice per diverse amministrazioni pubbliche e privati. Da gennaio 2020 lavora in SUSE come Software Release Engineer per Uyuni e SUSE Manager e quando non segue la sua passione per i computer e per Geeko coltiva la sua curiosità per l'astronomia (da cui deriva il suo nickname deneb_alpha).
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...Zilliz
Join us to introduce Milvus Lite, a vector database that can run on notebooks and laptops, share the same API with Milvus, and integrate with every popular GenAI framework. This webinar is perfect for developers seeking easy-to-use, well-integrated vector databases for their GenAI apps.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
20 Comprehensive Checklist of Designing and Developing a WebsitePixlogix Infotech
Dive into the world of Website Designing and Developing with Pixlogix! Looking to create a stunning online presence? Look no further! Our comprehensive checklist covers everything you need to know to craft a website that stands out. From user-friendly design to seamless functionality, we've got you covered. Don't miss out on this invaluable resource! Check out our checklist now at Pixlogix and start your journey towards a captivating online presence today.
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AIVladimir Iglovikov, Ph.D.
Presented by Vladimir Iglovikov:
- https://www.linkedin.com/in/iglovikov/
- https://x.com/viglovikov
- https://www.instagram.com/ternaus/
This presentation delves into the journey of Albumentations.ai, a highly successful open-source library for data augmentation.
Created out of a necessity for superior performance in Kaggle competitions, Albumentations has grown to become a widely used tool among data scientists and machine learning practitioners.
This case study covers various aspects, including:
People: The contributors and community that have supported Albumentations.
Metrics: The success indicators such as downloads, daily active users, GitHub stars, and financial contributions.
Challenges: The hurdles in monetizing open-source projects and measuring user engagement.
Development Practices: Best practices for creating, maintaining, and scaling open-source libraries, including code hygiene, CI/CD, and fast iteration.
Community Building: Strategies for making adoption easy, iterating quickly, and fostering a vibrant, engaged community.
Marketing: Both online and offline marketing tactics, focusing on real, impactful interactions and collaborations.
Mental Health: Maintaining balance and not feeling pressured by user demands.
Key insights include the importance of automation, making the adoption process seamless, and leveraging offline interactions for marketing. The presentation also emphasizes the need for continuous small improvements and building a friendly, inclusive community that contributes to the project's growth.
Vladimir Iglovikov brings his extensive experience as a Kaggle Grandmaster, ex-Staff ML Engineer at Lyft, sharing valuable lessons and practical advice for anyone looking to enhance the adoption of their open-source projects.
Explore more about Albumentations and join the community at:
GitHub: https://github.com/albumentations-team/albumentations
Website: https://albumentations.ai/
LinkedIn: https://www.linkedin.com/company/100504475
Twitter: https://x.com/albumentations
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
For the full video of this presentation, please visit: https://www.edge-ai-vision.com/2024/06/building-and-scaling-ai-applications-with-the-nx-ai-manager-a-presentation-from-network-optix/
Robin van Emden, Senior Director of Data Science at Network Optix, presents the “Building and Scaling AI Applications with the Nx AI Manager,” tutorial at the May 2024 Embedded Vision Summit.
In this presentation, van Emden covers the basics of scaling edge AI solutions using the Nx tool kit. He emphasizes the process of developing AI models and deploying them globally. He also showcases the conversion of AI models and the creation of effective edge AI pipelines, with a focus on pre-processing, model conversion, selecting the appropriate inference engine for the target hardware and post-processing.
van Emden shows how Nx can simplify the developer’s life and facilitate a rapid transition from concept to production-ready applications.He provides valuable insights into developing scalable and efficient edge AI solutions, with a strong focus on practical implementation.
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
2. Outline
• Introduction.
• How to pack a boot loader?
• Overview – The bootstrap procedure
• Binary relocation and memory remap.
• Vector setup.
• Low level initialization.
• Stack setup and jump into C functions.
• Early board and peripherals initialization.
• General Relocation.
• Common board and other peripherals initialization.
• Summary
• Appendix
3. Introduction
• This slide only discuss the bootstrap procedure of u-boot.
– We will also discuss device drivers which will be touched only in early
initialization stages.
– The license of this slide
• CC-SA: http://creativecommons.org/licenses/by-sa/3.0/tw/
• We will take N1213 CPU core which is NDS32 RISC architecture as the
reference.
• U-boot is a boot loader for embedded system.
– Supports PPC, ARM, AVR32, MIPS, x86, m68k, nios, microblaze, blackfin, and
NDS32.
– Wikipedia: http://en.wikipedia.org/wiki/Das_U-Boot
– Project: http://www.denx.de/wiki/U-Boot/WebHome
– Git: git://git.denx.de/u-boot.git
– This slides has been wrote based on the version
• ftp://ftp.denx.de/pub/u-boot/u-boot-2011.12.tar.bz2
– The bootstrap procedure will be improved continuously, so please follow up the
most recent develop discussion on mailing list.
• Mailing list: http://lists.denx.de/mailman/listinfo/u-boot
4. Introduction
• What is boot loader?
– http://en.wikipedia.org/wiki/Boot_loader#Boot_loader
– Functionality
• The main task of boot loader is to prepares CPU and RAM to
access the nonvolatile devices to load OS into ram.
• It provides firmware upgrade and fail-safe functions.
• It could run basic diagnostic and testing.
• You can develop simple application on u-boot.
– You can even use u-boot with non-OS frame buffer display
(VFD) on some devices..
– But the challenge of a boot loader is how to boot itself
into the memory appropriately.
• This might be the most important task of a boot loader.
5. Introduction
• Bootstrap procedure.
– Purpose
• The boot loader is usually stored
in FLASH or EEPROM.
• The boot loader must do the very
beginning setup and then copy
itself from FLASH or EEPROM
into DRAM then continue setting
hardware.
– How
• After power on, CPU will load the
first line of machine code (the
beginning of a boot loader) from
FLASH or EEPROM.
– The $PC (program counter
register) is usually the initial
value (0x0) which points to the
base address of FLASH or ROM.
• Then boot loader will setup DRAM
controller and copy itself into
DRAM.
– The program of bootstrap
procedure is usually called the
“boot code” or “startup code”.
CPU (SoC)
DRAM
FLASH
ROM
6. How to pack a boot loader?
• How to pack a boot loader into FLASH or
ROM?
– The linker script will pack the binary of all the
above procedures of a boot loader and other
functions in to a single binary file.
– This binary file is the boot loader which will be
burned into FLASH or EEPROM.
– The base address of .TEXT could be
changed depends on the initial value of the
$PC which will vary for different SoC.
arch/nds32/cpu/n1213/u-boot.lds:
OUTPUT_FORMAT("elf32-nds32", "elf32-nds32", "elf32-nds32")
OUTPUT_ARCH(nds32)
ENTRY(_start)
SECTIONS
{
. = ALIGN(4);
.text :
{
arch/nds32/cpu/n1213/start.o (.text)
*(.text)
}
. = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
. = ALIGN(4);
.data : { *(.data*) }
. = ALIGN(4);
.got : {
__got_start = .;
*(.got.plt) *(.got)
__got_end = .;
}
. = .;
__u_boot_cmd_start = .;
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .;
. = ALIGN(4);
_end = .;
.bss : {
__bss_start = .;
*(.bss)
. = ALIGN(4);
__bss_end__ = .;
}
}
.TEXT
.rodata
.got
.data
.u_boot_cmd
.bss
0x00000000, _start
7. How to pack a boot loader?
• If the initial value of a $PC is not equal to
zero (the base address of FLASH or ROM is
not at 0x0), the starting address and other
linking address in u-boot can be shifted by
an offset value
“CONFIG_SYS_TEXT_BASE” to be
execute correctly when it runs in FLASH or
in ROM.
– CONFIG_SYS_TEXT_BASE is defined in
configuration file “include/configs/adp-
ag101.h”
– start.S will use this value to do relocation
calculation.
arch/nds32/cpu/n1213/start.S:
/* Note: TEXT_BASE is defined by the (board-
dependent) linker script */
.globl _TEXT_BASE
_TEXT_BASE:
.word CONFIG_SYS_TEXT_BASE
.TEXT
.rodata
.got
.data
.u_boot_cmd
.bss
CONFIG_SYS_TEXT_BASE, _start
FLASH/ROM
DRAM
AHB
Controller
Reserved
SMC
Controller
DMA
Controller
Reserved
...
0x00000000
8. How to pack a boot loader?
• When u-boot copies itself into RAM, it will
use some symbols to calculate the offset
address for relocation and memory layout
setup.
– These symbols will be inserted into the ELF
and linker will convert them into values to
calculate relative address.
– Some magic numbers and offsets will also be
inserted into binary for calculating offsets in
runtime.
– NDS32 current won’t separate IRQ and FIQ
stack.
arch/nds32/cpu/n1213/start.S:
/*
* These are defined in the board-specific linker
script.
* Subtracting _start from them lets the linker
put their
* relative position in the executable instead of
leaving
* them null.
*/
#ifdef CONFIG_USE_IRQ
/* IRQ stack memory (calculated at run-time) */
.globl IRQ_STACK_START
IRQ_STACK_START:
.word 0x0badc0de
/* IRQ stack memory (calculated at run-time) */
.globl FIQ_STACK_START
FIQ_STACK_START:
.word 0x0badc0de
#endif
/* IRQ stack memory (calculated at run-time) + 8
bytes */
.globl IRQ_STACK_START_IN
IRQ_STACK_START_IN:
.word 0x0badc0de
...
0x0000 0000
...
0xdec0 ad0b
...
...
.TEXT
_TEXT_BASE
IRQ_STACK_START_IN
9. Overview –
The bootstrap procedure
Reset CPU and Hardware
Setup SP for
Early Board Setup
Environment (ASM->C)
Early Board Setup
board_init_f()
Relocation
Setup SP for
Common Board Setup
Setup GD and JUMP to
Final Board Setup
Common Board Setup
board_init_r()
Jump into Main loop
Low Level Initialization
Setup Memory
Memory REMAP
Setup Memory Controller
or on-chip SRAM
10. Overview –
The bootstrap procedure
• Example
– The description of boot code (startup code) in Start.S.
/*
* Andesboot Startup Code (reset vector)
*
* 1. bootstrap
* 1.1 reset - start of u-boot
* 1.2 to superuser mode - as is when reset
* 1.3 Do lowlevel_init
* - (this will jump out to lowlevel_init.S in SoC)
* - (lowlevel_init)
* 1.4 Do Memory Remap if it is necessary.
* 1.5 Turn off watchdog timer
* - (this will jump out to watchdog.S in SoC)
* - (turnoff_watchdog)
* 2. Do critical init when reboot (not from mem)
* 3. Relocate andesboot to ram
* 4. Setup stack
* 5. Jump to second stage (board_init_r)
*/
11. Overview –
The bootstrap procedure
Reset CPU and Hardware
Setup Vector
Setup SP for
Early Board Setup
Environment (ASM->C)
Early Board Setup
board_init_f()
Early Devices Setup
Calculate Addresses (SP,
Dest, GD) for Relocation
General Relocation
Copy Binary to RAM
Fix Relocation
Fix GOT
Clear BSS
Setup SP for
Common Board Setup
Setup GD and JUMP to
Final Board Setup
Common Board Setup
board_init_r()
Setup Mem for dlmalloc()
Setup Board Data
Setup Board FLASH
Load Default
Environments
Setup Environment
env_relocate();
Jump into Main loop
Setup SoC and Board
Specific Devices
board_init()Low Level Initialization
Turnoff Watchdog
Setup Memory
Memory REMAP
Setup Memory Controller
or on-chip SRAM
12. Overview –
The bootstrap procedure
cpu/n1213/start.S
Setup Vector
cpu/n1213/start.S
Setup SP for
Early Board Setup
Environment (ASM->C)
lib/board.c
board_init_f()
Early Devices Setup
Calculate Addresses (SP,
Dest, GD) for Relocation
cpu/n1213/start.S
Copy Binary to RAM
Fix Relocation
Fix GOT
Clear BSS
cpu/n1213/start.S
Setup SP for
Common Board Setup
cpu/n1213/start.S
Setup GD & Final Setup
lib/board.c
board_init_r()
Setup Mem for dlmalloc()
Setup Board Data
Setup Board FLASH
Load Default
Environments
Setup Environment
env_relocate();
Jump into Main loop
Setup SoC and Board
Specific Devices
board_init()cpu/n1213/ag101/low_levelinit.S
cpu/n1213/ag101/watchdog.S
Turnoff Watchdog
Setup Memory
Memory REMAP
Setup Memory Controller
or on-chip SRAM
13. Binary relocation and
memory remap.
• Binary relocation.
– "Relocation is the process of assigning load addresses to various parts
of [a] program and adjusting the code and data in the program to reflect
the assigned addresses.“
• John R. Levine (October 1999). "Chapter 1: Linking and Loading". Linkers
and Loaders. Morgan-Kauffman. p. 5. ISBN 1-55860-496-0.
– In other words, it means copy the binary from a source address to a new
destination address but the binary must be able to execute correctly.
• Doing memory relocation usually need to adjust the linking address offsets
and global offset table through all binary.
• If you don’t want to do address adjustment, you must copy the binary to the
destination address which exactly “the same as” its origin address.
– This requires the mechanism called memory “remap”.
– Two relocation will happened in u-boot.
• One is relocation with remap, which doesn’t need to do address adjustment.
• The other is the general relocation (or, generic relocation), which need to do
address adjustment based on dynamic calculated offsets relative to the top
of the DRAM.
14. Binary relocation and
memory remap.
• Binary relocation.
FLASH/ROM
U-boot
DRAM
...
0x00000000
0x10000000
FLASH/ROM
DRAM
...
U-boot
U-boot
copy
Relocation for
REMAP
REMAP
…
DRAM
FLASH/ROM
...
U-boot
U-boot
General
Relocation
U-boot runs in
DRAM with
adjusted linking
address.
DRAM
FLASH/ROM
...
U-boot
U-boot
U-boot
relo
U-boot runs in
DRAM with the
origin linking
address.
15. Binary relocation and
memory remap.
• Memory remap.
– Boot loader must copy itself into RAM even it ran in ROM at the
very beginning.
• Variable cannot be modified when it is stored in ROM.
– Boot loader must copy itself to RAM to update the variables correctly.
– Function calls relies on stack operation which is also should be stored
in RAM.
• For example, in some CPU architecture or system, ROM is
assigned at with base address 0x00000000, where is the initialize
value of $PC.
– Boot loader is usually linked at the address same as the initialize value
of $PC.
– Base address exchange between ROM and RAM is usually happened
when doing remapping.
– You will need to do memory remap after boot loader has copied itself
into RAM to make sure the execution correctness.
16. Memory relocation and remap.
• Memory remap.
FLASH/ROM
U-boot
DRAM
...
0x00000000
0x10000000
FLASH/ROM
DRAM
...
U-boot
U-boot$PC
FLASH/ROM
DRAM
...
U-boot
U-boot
copy
DRAM
FLASH/ROM
...
U-boot
U-boot
$PC+4
The Instruction
affects
REMAP
REMAP,
Change
the Base
Address
U-boot runs in
DRAM with the
origin linking
address.
Relocation for
REMAP
remap
17. Binary relocation and
memory remap.
• Memory remap.
– Not all architecture or SoC need to do memory
remap, it is optional.
• Some architecture provides a simple start-up code with
remap runs before boot loader, like ARM.
• The base address of ROM on some SoC is not begin at
0x00000000.
– Which also means the initial value of $PC of this SoC could be
configured with other value.
• Some architecture or SoC doesn’t allocate vector table at
0x00000000.
– The base address of DRAM may not required to be
0x00000000.
– It’s configurable if the CPU has a system register to configure
the base address of vector table.
18. Binary relocation and
memory remap.
• Memory remap is optional, it depends on the
configuration of your system.
– Most architecture doesn’t require to run Linux with storing vector
table at 0x00000000.
– Memory remap is usually done with-in low level initialization.
• You can also do low level initialization without memory remap which
is configurable.
• General binary relocation is a must for current
implementation of u-boot.
– U-boot will calculate the reserved space from the top of the RAM
for stack and other purpose.
– Finally u-boot will relocate itself to the address below this
reserved area, which is near the top of the RAM.
19. Binary relocation and
memory remap.
• Low level initialization.
– Low level initialization (lowlevel_init) will perform memory setup
configuration and remap.
• Memory remap is optional.
– If another boot loader (pre-loader) runs before u-boot, the boot
loader must done lowlevel_init for u-boot.
• Hence u-boot should be configured with
“CONFIG_SKIP_LOWLEVEL_INIT”.
– U-boot won’t perform lowlevel_init and remap will be skipped.
• This pre-loader will copy u-boot without address adjustment from
FLASH or ROM into DRAM.
– U-boot will perform general relocation itself.
– The base link address CONFIG_SYS_TEXT_BASE should be the
same as the destination which pre-loader will put u-boot.
20. Binary relocation and
memory remap.
• You could choose one of the 3 types of lowlevel_init and
remap combination when u-boot is doing bootstrap.
FLASH/ROM
U-boot
DRAM
...
0x00000000
0x10000000
FLASH/ROM
DRAM
...
U-boot
U-boot
relo
Pre-loader will
copy u-boot to
DRAM.
lowlevel_init
without remap
DRAM
FLASH/ROM
...
U-boot
U-boot
relo
U-boot
copy
lowlevel_init
with remap
copy
DRAM
FLASH/ROM
...
U-boot
U-boot
relo
U-boot
pre-loader
Without
lowlevel_init
U-boot will
copy itself to
DRAM.
21. Vector setup.
• Vector table is allocated at the
beginning of the u-boot binary.
– After general relocation u-boot
will usually copy the vector
table to the correct address
and adjust the address where
the real vectors exist.
• When CPU loads u-boot from
FLASH or ROM, it will jump to
the first vector to do “reset”.
– In reset vector, CPU will do
CPU core initialization and
check if lowlevel_init is
required.
arch/nds32/cpu/n1213/start.S
.globl _start
_start: j reset
j tlb_fill
j tlb_not_present
j tlb_misc
j tlb_vlpt_miss
j machine_error
j debug
j general_exception
j syscall
j internal_interrupt ! H0I
j internal_interrupt ! H1I
j internal_interrupt ! H2I
j internal_interrupt ! H3I
j internal_interrupt ! H4I
j internal_interrupt ! H5I
j software_interrupt ! S0I
.balign 16
22. Vector setup.
• reset:
– Configure $MISC_CTL and
$IVB to make sure the
vectors are 4 bytes aligned
at the address
0x00000000.
• load_lli:
– This will jump to the
procedure lowlevel_init and
then return.
• turnoff_wtdog:
– This will jump to the
procedure
load_turnoff_watchdog and
then return.
arch/nds32/cpu/n1213/start.S
/*
* The bootstrap code of nds32 core
*/
reset:
set_ivb:
li $r0, 0x0
/* turn on BTB */
mtsr $r0, $misc_ctl
/* set IVIC, vector size: 4 bytes, base:
0x0 */
mtsr $r0, $ivb
load_lli:
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
jal load_lowlevel_init
jral $p0
#endif
/*
* Set the N1213 (Whitiger) core to superuser mode
* According to spec, it is already when reset
*/
turnoff_wtdog:
#ifndef CONFIG_SKIP_TRUNOFF_WATCHDOG
jal load_turnoff_watchdog
jral $p0
#endif
23. Low level initialization
• The purpose if lowlevel_init is to
configure the power and memory
setting by when RAM are not
initialized.
• The main task of lowlevel_init is to
setup memory controller and
relatives to make sure the DRAM
could be operate correctly.
– Setup timing and clock of DRAM.
– Setup power related issue of
DRAM.
– Setup base address of DRAM.
– Perform memory remap of u-boot.
• To turn off watchdog timer is to
avoid hardware reset triggered by
random value inside an enabled
watchdog timer during bootstrap.
Low Level Initialization
Turnoff Watchdog
Setup Memory
Memory REMAP
Setup Memory Controller
or on-chip SRAM
24. Low level initialization
• ASM macro load_lowlevel_init
– will jump to the real lowlevel_init
macro and return.
• ASM macro
load_turnoff_watchdog
– will jump to the real
load_turnoff_watchdog macro and
return.
arch/nds32/cpu/n1213/start.S
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
load_lowlevel_init:
la $r6, lowlevel_init
la $r7, load_lli + 4
sub $p0, $r6, $r7
add $p0, $p0, $lp
ret
#endif
#ifndef CONFIG_SKIP_TRUNOFF_WATCHDOG
load_turnoff_watchdog:
la $r6, turnoff_watchdog
la $r7, turnoff_wtdog + 4
sub $p0, $r6, $r7
add $p0, $p0, $lp
ret
#endif
25. Low level initialization
• There are 2 main task
inside lowlevel_init
– Jump to mem_init
• Configuration DRAM
controller and setup base
address
– Jump to remap
• Memory remap.
arch/nds32/cpu/n1213/ag101/lowlevel_init.S
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
.globl lowlevel_init
lowlevel_init:
move $r10, $lp
led 0x0
jal mem_init
led 0x10
jal remap
led 0x20
ret $r10
26. Low level initialization
• mem_init
– Setup static memory controller
(SMC).
– Setting control and timing
registers.
– To make sure the timing of
reading from FLASH or
ROM is correct.
– Setup AHB controller
– Setting base address of
DRAM.
– Setup power management
controller (PMU).
– Setting the required power
parameters for DRAM.
arch/nds32/cpu/n1213/ag101/lowlevel_init.S
mem_init:
move $r11, $lp
/*
* mem_init:
* There are 2 bank connected to FTSMC020
on AG101
* BANK0: FLASH/ROM (SW5, J16), BANK1:
OnBoard SDRAM.
* we need to set onboard SDRAM before
remap and relocation.
*/
led 0x01
write32 SMC_BANK0_CR_A, SMC_BANK0_CR_D
! 0x10000052
write32 SMC_BANK0_TPR_A, SMC_BANK0_TPR_D
! 0x00151151
/*
* config AHB Controller
*/
led 0x02
write32 AHBC_BSR6_A, AHBC_BSR6_D
/*
* config PMU controller
*/
/* ftpmu010_dlldis_disable, must do it in
lowleve_init */
led 0x03
setbf32 PMU_PDLLCR0_A, FTPMU010_PDLLCR0_DLLDIS
! 0x00010000
27. Low level initialization
• mem_init (cont.)
– Setup SDRAM controller
(SDMC).
– Setting control and timing
registers.
– Setting other required
parameters.
arch/nds32/cpu/n1213/ag101/lowlevel_init.S
/*
* config SDRAM controller
*/
led 0x04
write32 SDMC_TP1_A, SDMC_TP1_D
! 0x00011312
led 0x05
write32 SDMC_TP2_A, SDMC_TP2_D
! 0x00480180
led 0x06
write32 SDMC_CR1_A, SDMC_CR1_D
! 0x00002326
led 0x07
write32 SDMC_CR2_A, FTSDMC021_CR2_IPREC
! 0x00000010
wait_sdram
led 0x08
write32 SDMC_CR2_A, FTSDMC021_CR2_ISMR
! 0x00000004
wait_sdram
led 0x09
write32 SDMC_CR2_A, FTSDMC021_CR2_IREF
! 0x00000008
wait_sdram
led 0x0a
move $lp, $r11
ret
28. Low level initialization
• remap:
– For CPU support only
NDS32 V0 ISA
• There is no “mfusr”
instruction for you to
access $PC directly.
• The work around is to use
branch and then access
$LP which will be the
same as $PC.
– Remapping
• First configure the base
address of DRAM in
SDRAM controller.
arch/nds32/cpu/n1213/ag101/lowlevel_init.S
remap:
move $r11, $lp
#ifdef __NDS32_N1213_43U1H__ /* NDS32 V0 ISA - AG101
Only */
bal 2f
relo_base:
move $r0, $lp
#else
relo_base:
mfusr $r0, $pc
#endif /* __NDS32_N1213_43U1H__ */
/*
* Remapping
*/
led 0x1a
write32 SDMC_B0_BSR_A,
SDMC_B0_BSR_D ! 0x00001100
/* clear empty BSR registers */
led 0x1b
li $r4, CONFIG_FTSDMC021_BASE
li $r5, 0x0
swi $r5, [$r4 + FTSDMC021_BANK1_BSR]
swi $r5, [$r4 + FTSDMC021_BANK2_BSR]
swi $r5, [$r4 + FTSDMC021_BANK3_BSR]
29. Low level initialization
• remap:
– CONFIG_MEM_REMAP
• Setup the origin base
address for SDRAM in
$r4.
• Setup the destination
address for binary copy
from ROM to RAM.
– Set remap bit
• Set REMAP bit into AHB
Controller
– After setting the
REMAP bit, the base
address of SDRAM
and ROM will be
exchanged.
arch/nds32/cpu/n1213/ag101/lowlevel_init.S
#ifdef CONFIG_MEM_REMAP
led 0x11
li $r4, PHYS_SDRAM_0_AT_INIT /*
0x10000000 */
li $r5, 0x0
la $r1, relo_base /* get
$pc or $lp */
sub $r2, $r0, $r1
sethi $r6, hi20(_end)
ori $r6, $r6, lo12(_end)
add $r6, $r6, $r2
1:
lwi.p $r7, [$r5], #4
swi.p $r7, [$r4], #4
blt $r5, $r6, 1b
/* set remap bit */
/*
* MEM remap bit is operational
* - use it to map writeable memory at 0x00000000, in
place of flash
* - before remap: flash/rom 0x00000000, sdram: 0x10000000-
0x4fffffff
* - after remap: flash/rom 0x80000000, sdram:
0x00000000
*/
led 0x1c
setbf15 AHBC_CR_A, FTAHBC020S_CR_REMAP ! 0x1
#endif /* #ifdef CONFIG_MEM_REMAP */
move $lp, $r11
2:
ret
30. Low level initialization
• Note:
– The mechanism inside AHBC when setting remap bit.
• The following is quoted from the DATASHEET of FTAHBC020S.
• Remap function, switch base address of slave 4 and slave
6.
– Activate remap function
After applying the remap function, the new base address of
slave 6 = the original base address of slave 4;
the new base address of slave 4 = the original base address
of slave 4 + space size of slave 6.
– Note that the base address should be the boundary of the
space size.
31. Low level initialization
• Turn off watchdog to
avoid hardware reset
accidently during
bootstrap.
– You can implement this in
C language if the period of
lowlevel_init is very short.
arch/nds32/cpu/n1213/ag101/watchdog.S
.text
#ifndef CONFIG_SKIP_TRUNOFF_WATCHDOG
ENTRY(turnoff_watchdog)
#define WD_CR 0xC
#define WD_ENABLE 0x1
! Turn off the watchdog, according to Faraday
FTWDT010 spec
li $p0,
(CONFIG_FTWDT010_BASE+WD_CR) ! Get the addr
of WD CR
lwi $p1, [$p0] ! Get the config of WD
andi $p1, $p1, 0x1f ! Wipe out useless bits
li $r0, ~WD_ENABLE
and $p1, $p1, $r0 ! Set WD disable
sw $p1, [$p0] ! Write back to WD CR
! Disable Interrupts by clear GIE in $PSW reg
setgie.d
ret
ENDPROC(turnoff_watchdog)
#endif
32. Stack setup and jump into
C functions.
• Stack setup is important before
programs executes from ASM to C
environment.
– Compiler (gcc + bintuils) will have its
own register usage and operation on
stack to maintain the function calls.
– It is also related to linking mechanism
which implemented in compiler.
• Different linking mode (PIC/non-PIC)
will lead different usage among
registers.
• $sp, $lp, $gp, and $r15 must be set
correctly for address offset calculation
and function returns.
– The linking method is quite different in
PIC mode and in non-PIC mode.
• The register layout and usage of $gp,
$r15 will be different.
• You must use PIC mode in nowadays
u-boot.
nds32le-linux-objdump -D u-boot: (V1 ISA toolchain)
00000f18 <board_init_r>:
f18: 3a 6f a1 bc smw.adm $r6,[$sp],
$r8,#0x6
f1c: 45 d2 07 58 movi $gp,#132952
f20: 42 ff 80 20 mfusr $r15,$pc
f24: 41 d7 f4 00 add $gp,$r15,$gp
f28: 51 ff ff fc addi $sp,$sp,#-4
f2c: 81 40 mov55 $r10,$r0
...
1042: dd 26 jral5 $r6
1044: 44 fd f9 ca movi $r15,#-132662
1048: 40 f7 f4 00 add $r15,$r15,$gp
104c: dd 0f jr5 $r15
104e: 92 00 srli45 $r0,#0x0
Setup SP for
Early Board Setup
Environment (ASM->C)
33. Stack setup and jump into
C functions.
• In early stack setup, we just
specify a compile-time parameter
“CONFIG_SYS_INIT_SP_ADDR”
to indicate where the early stack
begins.
– This depends on your memory
layout design of your SoC.
– It is configured in file
“include/configs/adp-ag101.h”.
• __NDS32_N1213_43U1H__
implies the code is using NDS32
V0 ISA and cooresponding
register layout.
• Then we jump to early board setup
C function board_init_f().
arch/nds32/cpu/n1213/start.S
/*
* Set stackpointer in internal RAM to call board_init_f
* $sp must be 8-byte alignment for ABI compliance.
*/
call_board_init_f:
li $sp, CONFIG_SYS_INIT_SP_ADDR
li $r0, 0x00000000
#ifdef __PIC__
#ifdef __NDS32_N1213_43U1H__
/* __NDS32_N1213_43U1H__ implies NDS32 V0 ISA */
la $r15, board_init_f ! store function
address into $r15
#endif
#endif
j board_init_f ! jump to
board_init_f() in lib/board.c
34. Early board and
peripherals initialization.
• After the memory is configured,
early board setup (board_init_f) is
the first C function which provides
C level hardware setup capability
by using the least amount of RAM.
– You will do lot of stack and
reserved memory calculation for
general relocation.
– You will also need to setup UART
and console to help the debugging
task.
– Then you will need to pass the
parameters to relocation_code
ASM procedure to help on
relocation and common board
setup.
Early Board Setup
board_init_f()
Early Devices Setup
Calculate Addresses (SP,
Dest, GD) for Relocation
Setup SP for
Common Board Setup
35. Early board and
peripherals initialization.
• Setup the point of global
data structure.
• Calculate the u-boot
length between _start to
__bss_end__.
• Initialize hardware
peripherals with
init_sequence[] which
must be setup during
early board setup.
arch/nds32/lib/board.c
void board_init_f(ulong bootflag)
{
bd_t *bd;
init_fnc_t **init_fnc_ptr;
gd_t *id;
ulong addr, addr_sp;
/* Pointer is writable since we allocated a
register for it */
gd = (gd_t *) ((CONFIG_SYS_INIT_SP_ADDR) &
~0x07);
memset((void *)gd, 0, GENERATED_GBL_DATA_SIZE);
gd->mon_len = (unsigned int)(&__bss_end__) -
(unsigned int)(&_start);
for (init_fnc_ptr = init_sequence;
*init_fnc_ptr; ++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0)
hang();
}
36. Early board and
peripherals initialization.
• The content of
init_sequence[].
– Setup UART and console
for debugging in early
board setup and later.
arch/nds32/lib/board.c
init_fnc_t *init_sequence[] = {
#if defined(CONFIG_ARCH_CPU_INIT)
arch_cpu_init, /* basic arch cpu dependent
setup */
#endif
#if defined(CONFIG_PMU) || defined(CONFIG_PCU)
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
pmu_init,
#endif
#endif
board_init, /* basic board dependent setup */
#if defined(CONFIG_USE_IRQ)
interrupt_init, /* set up exceptions */
#endif
timer_init, /* initialize timer */
env_init, /* initialize environment */
init_baudrate, /* initialze baudrate settings */
serial_init, /* serial communications setup */
console_init_f, /* stage 1 init of console */
#if defined(CONFIG_DISPLAY_BOARDINFO)
checkboard, /* display board info */
#endif
#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C)
init_func_i2c,
#endif
dram_init, /* configure available RAM banks */
display_dram_config,
NULL,
};
37. Early board and
peripherals initialization.
• Calculate the reserved
memory areas and the
stack address for general
relocation.
arch/nds32/lib/board.c
debug("monitor len: %08lXn", gd->mon_len);
/*
* Ram is setup, size stored in gd !!
*/
debug("ramsize: %08lXn", gd->ram_size);
addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size;
#if !(defined(CONFIG_SYS_ICACHE_OFF) &&
defined(CONFIG_SYS_DCACHE_OFF))
/* reserve TLB table */
addr -= (4096 * 4);
/* round down to next 64 kB limit */
addr &= ~(0x10000 - 1);
gd->tlb_addr = addr;
debug("TLB table at: %08lxn", addr);
#endif
/* round down to next 4 kB limit */
addr &= ~(4096 - 1);
debug("Top of RAM usable for U-Boot at:
%08lxn", addr);
38. Early board and
peripherals initialization.
• Calculate the reserved
memory areas and the
stack address for general
relocation. (cont.)
– Reserve frame buffer
here if you has LCD
display or video
devices.
arch/nds32/lib/board.c
#ifdef CONFIG_LCD
#ifdef CONFIG_FB_ADDR
gd->fb_base = CONFIG_FB_ADDR;
#else
/* reserve memory for LCD display (always full
pages) */
addr = lcd_setmem(addr);
gd->fb_base = addr;
#endif /* CONFIG_FB_ADDR */
#endif /* CONFIG_LCD */
/*
* reserve memory for U-Boot code, data & bss
* round down to next 4 kB limit
*/
addr -= gd->mon_len;
addr &= ~(4096 - 1);
39. Early board and
peripherals initialization.
• Calculate the reserved
memory areas and the
stack address for general
relocation. (cont.)
– Reserve the memory area
for dlmalloc memory
management of malloc.
• TOTAL_MALLOC_LEN
– Setup board information
structure.
– Setup global data structure.
arch/nds32/lib/board.c
/*
* reserve memory for malloc() arena
*/
addr_sp = addr - TOTAL_MALLOC_LEN;
debug("Reserving %dk for malloc() at: %08lxn",
TOTAL_MALLOC_LEN >> 10, addr_sp);
/*
* (permanently) allocate a Board Info struct
* and a permanent copy of the "global" data
*/
addr_sp -= GENERATED_BD_INFO_SIZE;
bd = (bd_t *) addr_sp;
gd->bd = bd;
memset((void *)bd, 0, GENERATED_BD_INFO_SIZE);
debug("Reserving %zu Bytes for Board Info at:
%08lxn",
GENERATED_BD_INFO_SIZE, addr_sp);
addr_sp -= GENERATED_GBL_DATA_SIZE;
id = (gd_t *) addr_sp;
debug("Reserving %zu Bytes for Global Data at:
%08lxn",
GENERATED_GBL_DATA_SIZE, addr_sp);
40. Early board and
peripherals initialization.
• Calculate the reserved
memory areas and the
stack address for general
relocation. (cont.)
– If you need to specify IRQ
stack, then reserve here.
• Currently NDS32 doesn’t
distinguish FIQ and IRQ.
• Adjustment stack and ABI
compliance.
arch/nds32/lib/board.c
/* setup stackpointer for exeptions */
gd->irq_sp = addr_sp;
#ifdef CONFIG_USE_IRQ
addr_sp -= (CONFIG_STACKSIZE_IRQ +
CONFIG_STACKSIZE_FIQ);
debug("Reserving %zu Bytes for IRQ stack at:
%08lxn",
CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ,
addr_sp);
#endif
/* leave 3 words for abort-stack */
addr_sp -= 12;
/* 8-byte alignment for ABI compliance */
addr_sp &= ~0x07;
debug("New Stack Pointer is: %08lxn", addr_sp);
41. Early board and
peripherals initialization.
• Calculate the reserved
memory areas and the
stack address for general
relocation. (cont.)
– Finally we setup bank size
for DRAM.
– Write relocation addr, stack
starting address, and the
relocation offset into global
data structure.
– Finally call general
relocation function
“relocate_code()”.
arch/nds32/lib/board.c
gd->bd->bi_baudrate = gd->baudrate;
/* Ram isn't board specific, so move it to board
code ... */
dram_init_banksize();
display_dram_config(); /* and display it */
gd->relocaddr = addr;
gd->start_addr_sp = addr_sp;
gd->reloc_off = addr - _TEXT_BASE;
debug("relocation Offset is: %08lxn", gd-
>reloc_off);
memcpy(id, (void *)gd, GENERATED_GBL_DATA_SIZE);
relocate_code(addr_sp, id, addr);
/* NOTREACHED - relocate_code() does not return
*/
}
42. General Relocation.
• General relocation is the last
binary copy of u-boot during
bootstrap process.
– Whether the u-boot is copied
from ROM, FLASH, RAM or
somewhere else, it general
relocation will copy the u-boot
into DRAM and to linking
address adjustment.
– Then the u-boot is ready to
run in the RAM and
responsible for loading OS
image into RAM.
Relocation
Copy Binary to RAM
Fix Relocation
Fix GOT
Clear BSS
43. General Relocation.
• relocate_code:
– First we save the
parameters passed in for
later calculation.
– relocate_code(addr_sp, id,
addr);
– addr_sp: stack address
– addr: relocation
destination address.
arch/nds32/cpu/n1213/start.S:
/*
* void relocate_code (addr_sp, gd, addr_moni)
*
* This "function" does not return, instead it
continues in RAM
* after relocating the monitor code.
*
*/
.globl relocate_code
relocate_code:
/* save addr_sp */
move $r4, $r0
/* save addr of gd */
move $r5, $r1
/* save addr of destination */
move $r6, $r2
44. General Relocation.
• relocate_code:
– Setup Stack.
– Do binary copy from _start
to __bss_start.
– Calculate the offset
between _start and
__bss_start.
arch/nds32/cpu/n1213/start.S:
/* Set up the stack */
stack_setup:
move $sp, $r4
la $r0, _start
beq $r0, $r6, clear_bss /* skip
relocation */
move $r1, $r6 /* r1 <- scratch
for copy_loop */
la $r3, __bss_start
sub $r3, $r3, $r0 /* r3 <-
__bss_start_ofs */
add $r2, $r0, $r3 /* r2 <- source
end address */
45. General Relocation.
• relocate_code:
– Do binary copy from _start
to __bss_start. (cont.)
– Copy loop.
– fix_relocations
– Do address adjustment
and linking address fix up.
– Specify the starting
address for fix.
– Calculate the offset of
relocation address
where to fix.
– $r9 will used in the
following relocation fix.
arch/nds32/cpu/n1213/start.S:
copy_loop:
lwi.p $r7, [$r0], #4
swi.p $r7, [$r1], #4
blt $r0, $r2, copy_loop
/*
* fix relocations related issues
*/
fix_relocations:
/* r0 <- Text base */
l.w $r0, _TEXT_BASE
/* r9 <- relocation offset */
sub $r9, $r6, $r0
46. General Relocation.
• relocate_code:
– fix_got:
• GOT is global offset table,
which is used for address
lookup with $GP when
indexing data and functions.
– When the binary of u-
boot is packed, the value
of GOT was referenced
by FLASH or ROM
because u-boot ran in
FLASH at the beginning.
– Skip the first 2 entries
since they must be zero.
– Specify the starting address of got
in FLASH and in RAM.
– Specify the ending address of got
in FLASH and in RAM.
– Fix all value in GOT by relocation
offset value in $r9.
arch/nds32/cpu/n1213/start.S:
fix_got:
/*
* Now we want to update GOT.
*
* GOT[0] is reserved. GOT[1] is also reserved for the
dynamic object
* generated by GNU ld. Skip these reserved entries from
relocation.
*/
/* r2 <- rel __got_start in FLASH */
la $r2, __got_start
/* r2 <- rel __got_start in RAM */
add $r2, $r2, $r9
/* r3 <- rel __got_end in FLASH */
la $r3, __got_end
/* r3 <- rel __got_end in RAM */
add $r3, $r3, $r9
/* skipping first two entries */
addi $r2, $r2, #8
fix_got_loop:
lwi $r0, [$r2] /* r0 <-
location in FLASH to fix up */
add $r0, $r0, $r9 /* r0 <-
location fix up to RAM */
swi.p $r0, [$r2], #4 /* r0 <- store
fix into .got in RAM */
blt $r2, $r3, fix_got_loop
48. General Relocation.
• relocate_code:
– clear_bss:
• Clear BSS section to
zero since it might have
random value in RAM.
arch/nds32/cpu/n1213/start.S:
clear_bss:
/* r0 <- rel __bss_start in FLASH */
la $r0, __bss_start
/* r0 <- rel __bss_start in FLASH */
add $r0, $r0, $r9
/* r1 <- rel __bss_end in RAM */
la $r1, __bss_end__
/* r0 <- rel __bss_end in RAM */
add $r1, $r1, $r9
li $r2, 0x00000000 /* clear */
clbss_l:
/* clear loop... */
sw $r2, [$r0]
addi $r0, $r0, #4
bne $r0, $r1, clbss_l
49. Relocation.
• relocate_code:
– call_board_init_r:
• Prepare to call common
board setup function
board_init_r().
– Load the function
address which the
value was referenced
in ROM.
– Calculate the real
address of
board_init_r() in RAM.
– Prepare parameters
to call board_init_r().
• Setup $r15 and $lp to
jump into C
environment.
arch/nds32/cpu/n1213/start.S:
/*
* We are done. Do not return, instead branch to second
part of board
* initialization, now running from RAM.
*/
call_board_init_r:
la $r0, board_init_r
/* offset of board_init_r() */
move $lp, $r0
/* real address of board_init_r() */
add $lp, $lp, $r9
/* setup parameters for board_init_r */
move $r0, $r5 /* gd_t */
move $r1, $r6 /* dest_addr */
#ifdef __PIC__
#ifdef __NDS32_N1213_43U1H__ /* NDS32 V0 ISA
*/
move $r15, $lp /* store
function address into $r15 */
#endif
#endif
/* jump to it ... */
jr $lp /* jump to
board_init_r() */
50. Common board and
other peripherals initialization.
• Common board setup includes
– SoC and customized board
specific setup by calling
board_init().
– Memory setup for malloc()
management.
– Setup enviroment parameters.
– Other peripherals devices.
Common Board Setup
board_init_r()
Setup mem for dlmalloc()
Setup Board Data
Setup Board FLASH
Load Default
Environments
Setup Environment
env_relocate();
Jump into Main loop
Setup SoC and Board
Specific Devices
board_init()
51. Common board and
other peripherals initialization.
• board_init_r()
– Set GD_FLG_RELOC to
indicate the relocation has
been done.
– Calculate the u-boot binary
size in FLASH or ROM.
– Call board_init() which will
setup devices and for a
specific SoC and board.
arch/nds32/lib/board.c:
/*
* This is the next part if the initialization
sequence: we are now
* running from RAM and have a "normal" C
environment, i. e. global
* data can be written, BSS has been cleared, the
stack size in not
* that critical any more, etc.
*/
void board_init_r(gd_t *id, ulong dest_addr)
{
char *s;
bd_t *bd;
ulong malloc_start;
extern void malloc_bin_reloc(void);
gd = id;
bd = gd->bd;
/* tell others: relocation done */
gd->flags |= GD_FLG_RELOC;
monitor_flash_len = &_end - &_start;
debug("monitor flash len: %08lXn",
monitor_flash_len);
board_init(); /* Setup chipselects */
52. Common board and
other peripherals initialization.
• board_init_r()
– fixup_cmdtable
• Fix the u-boot command table
relocation.
– Calculate and setup the
preserved memory space
for dlmalloc (malloc
management).
• malloc_bin_reloc() will fix the
relocation issue of the
dlmalloc management table
(bin) which is a bi-direction
linking list maintain free
spaces and addresses.
• This part is important
because cmd_env will use
hash and malloc to
management environment
parameters.
arch/nds32/lib/board.c:
#if defined(CONFIG_NEEDS_MANUAL_RELOC)
/*
* We have to relocate the command table
manually
*/
fixup_cmdtable(&__u_boot_cmd_start,
(ulong)(&__u_boot_cmd_end -
&__u_boot_cmd_start));
#endif /* defined(CONFIG_NEEDS_MANUAL_RELOC) */
#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
#endif
debug("Now running in RAM - U-Boot at: %08lxn",
dest_addr);
/* The Malloc area is immediately below the
monitor copy in DRAM */
malloc_start = dest_addr - TOTAL_MALLOC_LEN;
mem_malloc_init(malloc_start, TOTAL_MALLOC_LEN);
malloc_bin_reloc();
53. Common board and
other peripherals initialization.
• board_init_r()
– Setup FLASH.
• Do flash_init()
• Calculate the flash offset
and size.
arch/nds32/lib/board.c:
#ifndef CONFIG_SYS_NO_FLASH
/* configure available FLASH banks */
gd->bd->bi_flashstart =
CONFIG_SYS_FLASH_BASE;
gd->bd->bi_flashsize = flash_init();
gd->bd->bi_flashoffset =
CONFIG_SYS_FLASH_BASE + gd->bd->bi_flashsize;
if (gd->bd->bi_flashsize)
display_flash_config(gd-
>bd->bi_flashsize);
#endif /* CONFIG_SYS_NO_FLASH */
54. Common board and
other peripherals initialization.
• board_init_r()
– Setup the rest of
devices.
• Setup NAND flash.
• Setup IDE devices.
• Setup MMC/SD
devices.
• Setup PCI bridge and
related devices.
#if defined(CONFIG_CMD_NAND)
puts("NAND: ");
nand_init(); /*
go init the NAND */
#endif
#if defined(CONFIG_CMD_IDE)
puts("IDE: ");
ide_init();
#endif
#ifdef CONFIG_GENERIC_MMC
puts("MMC: ");
mmc_initialize(gd->bd);
#endif
#if defined(CONFIG_CMD_PCI) ||
defined(CONFIG_PCI)
puts("PCI: ");
nds32_pci_init();
#endif
55. Common board and
other peripherals initialization.
• board_init_r()
– Setup the rest
environments and
functions.
• Setup environments and
import values from the
environment structure
stored in FLASH or ROM.
• Get IP address from
environments.
• Setup API environment for
standalone applications.
• Setup remain function
related to architecture
extended functions or
SoC.
arch/nds32/lib/board.c:
/* initialize environment */
env_relocate();
/* IP Address */
gd->bd->bi_ip_addr = getenv_IPaddr("ipaddr");
/* get the devices list going. */
stdio_init();
jumptable_init();
#if defined(CONFIG_API)
/* Initialize API */
api_init();
#endif
/* fully init console as a device */
console_init_r();
#if defined(CONFIG_ARCH_MISC_INIT)
/* miscellaneous arch dependent initialisations */
arch_misc_init();
#endif
#if defined(CONFIG_MISC_INIT_R)
/* miscellaneous platform dependent initialisations */
misc_init_r();
#endif
#if defined(CONFIG_USE_IRQ)
/* set up exceptions */
interrupt_init();
/* enable exceptions */
enable_interrupts();
#endif
56. Common board and
other peripherals initialization.
• board_init_r()
– Setup the rest
environments and
functions.
• Get load_address of
OS image from
environments.
• Setup ethernet.
• Finally we jump to
main_loop() and waiting
for commands from
console.
arch/nds32/lib/board.c:
/* Initialize from environment */
load_addr = getenv_ulong("loadaddr", 16, load_addr);
#if defined(CONFIG_CMD_NET)
s = getenv("bootfile");
if (s != NULL)
copy_filename(BootFile, s, sizeof(BootFile));
#endif
#ifdef BOARD_LATE_INIT
board_late_init();
#endif
#if defined(CONFIG_CMD_NET)
puts("Net: ");
eth_initialize(gd->bd);
#if defined(CONFIG_RESET_PHY_R)
debug("Reset Ethernet PHYn");
reset_phy();
#endif
#endif
/* main_loop() can return to retry autoboot, if so just
run it again. */
for (;;)
main_loop();
/* NOTREACHED - no way out of command loop except
booting */
}
57. Summary
• Most of the configurable parameters related to
architecture of a SoC are also listed in configuration file.
– This provide you the flexibility to customize your system
according to the application.
• Use lowlevel_init and remap correctly according to your
design of the system.
• The bootstrap procedure is only the back ground
knowledge for you before you start the porting task of a
SoC.
– For more information, please read the other slides.
• U-boot porting guide for SoC.
• The bootstrap procedure will be improved continuously,
so please follow up the most recent develop discussion
on mailing list.
58. Appendix:
An Example of Vector Implements
.align 5
tlb_fill:
SAVE_ALL
! To get the kernel stack
move $r0, $sp
! Determine interruption type
li $r1, 1
bal do_interruption
.align 5
tlb_not_present:
SAVE_ALL
! To get the kernel stack
move $r0, $sp
! Determine interruption type
li $r1, 2
bal do_interruption
.align 5
tlb_misc:
SAVE_ALL
! To get the kernel stack
move $r0, $sp
! Determine interruption type
li $r1, 3
bal do_interruption
.align 5
tlb_vlpt_miss:
SAVE_ALL
! To get the kernel stack
move $r0, $sp
! Determine interruption type
li $r1, 4
bal do_interruption
.align 5
machine_error:
SAVE_ALL
! To get the kernel stack
move $r0, $sp
! Determine interruption type
li $r1, 5
bal do_interruption
.align 5
debug:
SAVE_ALL
! To get the kernel stack
move $r0, $sp
! Determine interruption type
li $r1, 6
bal do_interruption
59. Appendix:
reset_cpu
• Do not use it.
• reset_cpu:
– This macro was connect to
do_reset but currently is
obsoleted now.
• The macro will reset CPU and
jump to somewhere to
execute a new binary.
• Keep this only for reference,
should be removed later.
– The function do_reset will
be called when you
execute “reset” command
in console.
• Any kind of “reset” in a boot
loader should be hardware
reset to avoid hardware
unstable includes dirty
contents in the memory.
arch/nds32/cpu/n1213/start.S:
/*
* void reset_cpu(ulong addr);
* $r0: input address to jump to
*/
.globl reset_cpu
reset_cpu:
/* No need to disable MMU because we never enable it */
bal invalidate_icac
bal invalidate_dcac
mfsr $p0, $MMU_CFG
andi $p0, $p0, 0x3 ! MMPS
li $p1, 0x2 ! TLB MMU
bne $p0, $p1, 1f
tlbop flushall ! Flush TLB
1:
! Get the $CACHE_CTL reg
mfsr $p0, MR_CAC_CTL
li $p1, DIS_DCAC
! Clear the DC_EN bit
and $p0, $p0, $p1
! Write back the $CACHE_CTL reg
mtsr $p0, MR_CAC_CTL
! Jump to the input address
br $r0