DOCSLIB.ORG

Coreboot Boot Structure LA-UR-06-7928

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Coreboot Boot Structure LA-UR-06-7928 coreboot boot structure LA-UR-06-7928 New coreboot group March 13, 2008 Abstract This is the new coreboot boot architecture. 1 Introduction The new coreboot boot architecture depends on CAR, with payloads appearing as files in a LAR archive. The device tree is defined by a device tree blob (DTB) and all the activities flow from that. For now, the DTC will produce a standard coreboot v2 device tree; this will, we hope, be improved. romcc is gone. Required attributes of a CPU for coreboot v3: • Supports CAR Required platform attributes: 2 Goal 2.1 Design Goals • All components are seperate modules. • The strict seperation of normal/fallback does not exist anymore. Any module can be available several times. • Commonly used code is shared. There is one implementation of printk, and one implementation for each compressor. • Under construction, things have changed recently. 2.2 Features 3 FLASH layout Shown in 1 is the layout of the whole FLASH. Note that we can kill the buildrom tool, since the FLASH code is now a LAR archive. Note that the linker script will now be very simple. The initram is roughly what is in auto.c, although the early hardware setup from auto.c is now in the pre-initram, so that we have serial output and other capabilities. The FLASH recovery is interesting: in hopeless cases, the serial port can be used to load a new flash image, and allow a successful boot from a totally hosed machine. VPD includes data such as the MAC address, instance of the motherboard, etc. The DTB can be modified by the flashrom tool, and hence a platform can be customized from a binary FLASH image. Each LAR file has a checksum attached to the end, so that the system can verify that the data is uncorrupted. We now build at least four targets for a platform: • Basic startup and CAR (in most cases, same for all processors of a given type) • Pre-initram device setup (large FLASH, serial port, etc.) • initram • Traditional coreboot RAM code (LAR, etc.) • Load payload and start it 4 Introduction to the coreboot device tree 4.1 Purpose and function The coreboot device tree is probably the single most important concept in core- boot, and, in V2, was the least understood part of the software. The device tree provides a tremendous amount of capability to the software. The initial tree, which almost always will be an incomplete representation of the hardware (consider pluggable devices), is created by the configuration tool – in V3, the device tree compiler, or DTC. The initial tree is statically allocated at com- pile time. At runtime, hardware must be probed, and the tree must be filled in, extended, and even restructured as the hardware discovery process occurs. The restructuring mainly consists of adding nodes, and reordering nodes in the tree to accomodate these new nodes. The tree represents devices as nodes and busses as edges (called links) between the nodes. Some devices can bridge a bus to another; these are intermediate nodes in the tree. Other devices do not bridge busses; these are leaf nodes. And, of course, a bridge device might exist with nothing on the other side – this device will of course also be a leaf node. Figure 1: FLASH layout LAR archive lzma nrv2b normal/initram normal/coreboot.lzma fallback/initram fallback/coreboot.lzma memtest86/memtest86.lzma vgabios.lzma Basic startup CAR src/cpu/x86/crt0.S Pre−initram device setup Device Tree Blob Device Tree Code CPIO code support FLASH recovery from serial ROM Code Checksum (4 bytes) 0xffffff00 VPD VPD checksum (4 bytes) 0xfffffff0 JMP start At build time, the programmer can specify, via a configuration file, hardware that is likely to be on the mainboard, although it is not required to be present (e.g. a 2-cpu system might have only one CPU installed). Also, hardware that can be probed, and that does not need any special configuration, can be left out of the configuration file and left to be discovered dynamically, even if it is known to be on the board. At run time, the software must determine what hardware exists, and modify the tree to accord to reality. This modification can include deletion of nodes, including bridge nodes; and even deletion of edges in the graph. The software must also be able to add new nodes and edges, as bridges and devices are found. Finally, once the tree is built, the device tree software must allocate resources to each device. Resources, in this context, are for the most part address space ranges, in memory or I/O space. A given device will require a certain range of addresses and, still worse, might require that those addresses be fixed at a certain value (such as a superio which is hardwired to address 0x4e). The software must allocate the resources to devices, and, for a bridge, must allocate the resources to the bridge that are held by all the devices on the other side of the bridge. The process of resource allocation must take into acount the fact that ad- dresses at a bridge may have special alignment requirements (e.g. the 4096 byte alignment for memory address ranges); that memory addresses on a device must be aligned to the size of the region (e.g. a 512KiB region must be aligned to 512KiB); and other restrictions dependent on the device or bridge. Another issue is the use of subtractive address ranges, which define an address range that is picked up by default if no other resource claims it. Subtractive address ranges are typically used for legacy PC address ranges. 4.2 Device tree structures There are three primary objects which are used to manage the coreboot de- vice tree: devices, links, and drivers. Devices and links are generic structures: drivers, on the other hand, are specialized. We describe these parts, and their relationship, below. These structures are linked together in the static device tree. The static de- vice tree, a set of initialized C structures, is created by the device tree compiler, in the file build/statictree.c, using as input the dts file in the mainboard direc- tory. This tree defines the hardware that is known to exist on the mainboard. At run time, the static tree is elided with dynamically determined information, and can even be restructured to some extent (e.g., the static tree has a device at 0:4.0; if a dynamic device is found at 0:3.0, it will be placed in the tree “in front of” the 0:4.0 device). Each device has a void * which can be filled in, via the dts file, with non- generic, i.e., device-specific, information. What’s the difference between generic and non-generic information? As an example, the PCI configuration address or “path” of a device is generic; there is a path of some sort for every device in a system. But, not all devices have iden- Figure 2: The files in the i440bx directory. [rminnich@q ~]$ ls ~/src/bios/coreboot-v3/northbridge/intel/i440bxemulation/ config.h i440bx.c i440bx.h Kconfig Makefile tical capabilities. Some PCI devices have IDE controllers, others do not; some can drive the legacy PC XBUS, others can not; and so on. In coreboot V1, we attempted to create devices that were the union of all possible devices, but cre- ating such a union proved to be impossible, as new devices with new capabilities came out. So, in V2, we split off the device-specific information into a seperate structure. The generic device structure is defined in include/device/device.h; the device-specific structures are defined in the source directory for a given de- vice, always in a file named config.h, e.g. src/northbridge/intel/i440gx/config.h. For an analogous structure, see the Linux kernel Virtual File System (VFS) code. A VFS is a generic file system, with a generic structure, which can be extended via individual file system structures. More on device source directories, configuration structure and con- fig.h file The generic code for the device tree is contained in the device directory. The code for a given device is contained in a single directory, which is not shared with any other device. The naming convention is <device-type>/<vendor>/<device- name>/filename. The config.h file contains configuration information for a given device. Devices, in some cases, have special control registers that need to be set. In a few cases, generic code can handle these operations: see device/pci device.c. Device-specific functions for controlling the device and its settings are found in the device-specific directory. All the configuration variables for controlling a device must be defined in a single structure; to reiterate, that structure is defined in the file config.h. It is one structure, instead of a set of variables, because it must be instantiated and initialized by the device tree compiler (dtc), and a pointer to it is held in the generic device structure. We show an example of a specific device, below. The device is the i440bx emulation. i440bx.h contains manifest constants defining registers, bits in registers, and so on. Config.h defines the structures and declarations that allow the static device tree to compile. We show it below. The file contains an extern declaration, pointing to a set of operations for the chip (needed to get statictree.c to compile); and the chip-specific structure, containing the control variable ramsize. The Kconfig and Makefile are for the Kbuild system. Figure 3: config.h for the i440bx extern struct chip operations northbridge intel i440bxemulation ops; struct northbridge intel i440bx config { /* The various emulators don’t always get 440BX right.
Load more

Recommended publications
  • Application of TRIE Data Structure and Corresponding Associative Algorithms for Process Optimization in GRID Environment
    Application of TRIE data structure and corresponding associative algorithms for process optimization in GRID environment V. V. Kashanskya, I. L. Kaftannikovb South Ural State University (National Research University), 76, Lenin prospekt, Chelyabinsk, 454080, Russia E-mail: a [email protected], b [email protected] Growing interest around different BOINC powered projects made volunteer GRID model widely used last years, arranging lots of computational resources in different environments. There are many revealed problems of Big Data and horizontally scalable multiuser systems. This paper provides an analysis of TRIE data structure and possibilities of its application in contemporary volunteer GRID networks, including routing (L3 OSI) and spe- cialized key-value storage engine (L7 OSI). The main goal is to show how TRIE mechanisms can influence de- livery process of the corresponding GRID environment resources and services at different layers of networking abstraction. The relevance of the optimization topic is ensured by the fact that with increasing data flow intensi- ty, the latency of the various linear algorithm based subsystems as well increases. This leads to the general ef- fects, such as unacceptably high transmission time and processing instability. Logically paper can be divided into three parts with summary. The first part provides definition of TRIE and asymptotic estimates of corresponding algorithms (searching, deletion, insertion). The second part is devoted to the problem of routing time reduction by applying TRIE data structure. In particular, we analyze Cisco IOS switching services based on Bitwise TRIE and 256 way TRIE data structures. The third part contains general BOINC architecture review and recommenda- tions for highly-loaded projects.
    [Show full text]
  • CS 106X, Lecture 21 Tries; Graphs
    CS 106X, Lecture 21 Tries; Graphs reading: Programming Abstractions in C++, Chapter 18 This document is copyright (C) Stanford Computer Science and Nick Troccoli, licensed under Creative Commons Attribution 2.5 License. All rights reserved. Based on slides created by Keith Schwarz, Julie Zelenski, Jerry Cain, Eric Roberts, Mehran Sahami, Stuart Reges, Cynthia Lee, Marty Stepp, Ashley Taylor and others. Plan For Today • Tries • Announcements • Graphs • Implementing a Graph • Representing Data with Graphs 2 Plan For Today • Tries • Announcements • Graphs • Implementing a Graph • Representing Data with Graphs 3 The Lexicon • Lexicons are good for storing words – contains – containsPrefix – add 4 The Lexicon root the art we all arts you artsy 5 The Lexicon root the contains? art we containsPrefix? add? all arts you artsy 6 The Lexicon S T A R T L I N G S T A R T 7 The Lexicon • We want to model a set of words as a tree of some kind • The tree should be sorted in some way for efficient lookup • The tree should take advantage of words containing each other to save space and time 8 Tries trie ("try"): A tree structure optimized for "prefix" searches struct TrieNode { bool isWord; TrieNode* children[26]; // depends on the alphabet }; 9 Tries isWord: false a b c d e … “” isWord: true a b c d e … “a” isWord: false a b c d e … “ac” isWord: true a b c d e … “ace” 10 Reading Words Yellow = word in the trie A E H S / A E H S A E H S A E H S / / / / / / / / A E H S A E H S A E H S A E H S / / / / / / / / / / / / A E H S A E H S A E H S / / / / / / /
    [Show full text]
  • Multiprocessor Initialization of INTEL SOC in Coreboot
    Multiprocessor Initialization OF INTEL SOC in Coreboot Pratik Prajapati ([email protected]) Subrata Banik ([email protected]) 1 Agenda • Intel Multiple Processor (MP) Initialization • Coreboot + Intel FSP Boot Flow • Problem with existing model • Solution space • Design • Future Scope 2 Intel Multiple Processor (MP) Initialization • The IA-32 architecture (beginning with the P6 family processors) defines a multiple-processor (MP) initialization protocol called the Multiprocessor Specification Version 1.4. • The MP initialization protocol has the following important features: • It supports controlled booting of multiple processors without requiring dedicated system hardware. • It allows hardware to initiate the booting of a system without the need for a dedicated signal or a predefined boot processor. • It allows all IA-32 processors to be booted in the same manner, including those supporting Intel Hyper-Threading Technology. • The MP initialization protocol also applies to MP systems using Intel 64 processors. • Entire CPU multiprocessor initialization can be divided into two parts – BSP (Boot Strap Processor) Initialization – AP (Application Processor) Initialization Reference: Intel SDM Multiple Processor Init - section 8.4 3 Coreboot + Intel FSP (Firmware support package) Boot Flow Coreboot/BIOS FSP * Coreboot uses its own temp ram init code. 4 Problem Statement with existing model • Background: Coreboot is capable enough to handle multiprocessor initialization on IA platforms. So ideally, CPU features programming can be part of Coreboot MP Init sequence. • But, there might be some cases where certain feature programming can't be done with current flow of MP init sequence. Because, Intel FSP-S has to program certain registers to meet silicon init flow due to SAI (Security Attributes of Initiator) and has to lock other registers before exiting silicon init API.
    [Show full text]
  • Introduction to Linked List: Review
    Introduction to Linked List: Review Source: http://www.geeksforgeeks.org/data-structures/linked-list/ Linked List • Fundamental data structures in C • Like arrays, linked list is a linear data structure • Unlike arrays, linked list elements are not stored at contiguous location, the elements are linked using pointers Array vs Linked List Why Linked List-1 • Advantages over arrays • Dynamic size • Ease of insertion or deletion • Inserting a new element in an array of elements is expensive, because room has to be created for the new elements and to create room existing elements have to be shifted For example, in a system if we maintain a sorted list of IDs in an array id[]. id[] = [1000, 1010, 1050, 2000, 2040] If we want to insert a new ID 1005, then to maintain the sorted order, we have to move all the elements after 1000 • Deletion is also expensive with arrays until unless some special techniques are used. For example, to delete 1010 in id[], everything after 1010 has to be moved Why Linked List-2 • Drawbacks of Linked List • Random access is not allowed. • Need to access elements sequentially starting from the first node. So we cannot do binary search with linked lists • Extra memory space for a pointer is required with each element of the list Representation in C • A linked list is represented by a pointer to the first node of the linked list • The first node is called head • If the linked list is empty, then the value of head is null • Each node in a list consists of at least two parts 1.
    [Show full text]
  • University of Cape Town Declaration
    The copyright of this thesis vests in the author. No quotation from it or information derived from it is to be published without full acknowledgementTown of the source. The thesis is to be used for private study or non- commercial research purposes only. Cape Published by the University ofof Cape Town (UCT) in terms of the non-exclusive license granted to UCT by the author. University Automated Gateware Discovery Using Open Firmware Shanly Rajan Supervisor: Prof. M.R. Inggs Co-supervisor: Dr M. Welz University of Cape Town Declaration I understand the meaning of plagiarism and declare that all work in the dissertation, save for that which is properly acknowledged, is my own. It is being submitted for the degree of Master of Science in Engineering in the University of Cape Town. It has not been submitted before for any degree or examination in any other university. Signature of Author . Cape Town South Africa May 12, 2013 University of Cape Town i Abstract This dissertation describes the design and implementation of a mechanism that automates gateware1 device detection for reconfigurable hardware. The research facilitates the pro- cess of identifying and operating on gateware images by extending the existing infrastruc- ture of probing devices in traditional software by using the chosen technology. An automated gateware detection mechanism was devised in an effort to build a software system with the goal to improve performance and reduce software development time spent on operating gateware pieces by reusing existing device drivers in the framework of the chosen technology. This dissertation first investigates the system design to see how each of the user specifica- tions set for the KAT (Karoo Array Telescope) project in [28] could be achieved in terms of design decisions, toolchain selection and software modifications.
    [Show full text]
  • Linux Kernel and Driver Development Training Slides
    Linux Kernel and Driver Development Training Linux Kernel and Driver Development Training © Copyright 2004-2021, Bootlin. Creative Commons BY-SA 3.0 license. Latest update: October 9, 2021. Document updates and sources: https://bootlin.com/doc/training/linux-kernel Corrections, suggestions, contributions and translations are welcome! embedded Linux and kernel engineering Send them to [email protected] - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 1/470 Rights to copy © Copyright 2004-2021, Bootlin License: Creative Commons Attribution - Share Alike 3.0 https://creativecommons.org/licenses/by-sa/3.0/legalcode You are free: I to copy, distribute, display, and perform the work I to make derivative works I to make commercial use of the work Under the following conditions: I Attribution. You must give the original author credit. I Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. I For any reuse or distribution, you must make clear to others the license terms of this work. I Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. Document sources: https://github.com/bootlin/training-materials/ - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 2/470 Hyperlinks in the document There are many hyperlinks in the document I Regular hyperlinks: https://kernel.org/ I Kernel documentation links: dev-tools/kasan I Links to kernel source files and directories: drivers/input/ include/linux/fb.h I Links to the declarations, definitions and instances of kernel symbols (functions, types, data, structures): platform_get_irq() GFP_KERNEL struct file_operations - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/470 Company at a glance I Engineering company created in 2004, named ”Free Electrons” until Feb.
    [Show full text]
  • Coreboot - the Free Firmware
    coreboot - the free firmware vimacs <https://vimacs.lcpu.club> Linux Club of Peking University May 19th, 2018 . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 1 / 77 License This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/. You can find the source code of this presentation at: https://git.wehack.space/coreboot-talk/ . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 2 / 77 Index 1 What is coreboot? History Why use coreboot 2 How coreboot works 3 Building and using coreboot Building Flashing 4 Utilities and Debugging 5 Join the community . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 3 / 77 Index 6 Porting coreboot with autoport ASRock B75 Pro3-M Sandy/Ivy Bridge HP Elitebooks Dell Latitude E6230 7 References . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 4 / 77 1 What is coreboot? History Why use coreboot 2 How coreboot works 3 Building and using coreboot Building Flashing 4 Utilities and Debugging 5 Join the community . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 5 / 77 What is coreboot? coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology. The word ’coreboot’ should always be written in lowercase, even at the start of a sentence. vimacs (LCPU) coreboot - the free firmware May 19th, 2018 6 / 77 History: from LinuxBIOS to coreboot coreboot has a very long history, stretching back more than 18 years to when it was known as LinuxBIOS.
    [Show full text]
  • Implementing the Map ADT Outline
    Implementing the Map ADT Outline ´ The Map ADT ´ Implementation with Java Generics ´ A Hash Function ´ translation of a string key into an integer ´ Consider a few strategies for implementing a hash table ´ linear probing ´ quadratic probing ´ separate chaining hashing ´ OrderedMap using a binary search tree The Map ADT ´A Map models a searchable collection of key-value mappings ´A key is said to be “mapped” to a value ´Also known as: dictionary, associative array ´Main operations: insert, find, and delete Applications ´ Store large collections with fast operations ´ For a long time, Java only had Vector (think ArrayList), Stack, and Hashmap (now there are about 67) ´ Support certain algorithms ´ for example, probabilistic text generation in 127B ´ Store certain associations in meaningful ways ´ For example, to store connected rooms in Hunt the Wumpus in 335 The Map ADT ´A value is "mapped" to a unique key ´Need a key and a value to insert new mappings ´Only need the key to find mappings ´Only need the key to remove mappings 5 Key and Value ´With Java generics, you need to specify ´ the type of key ´ the type of value ´Here the key type is String and the value type is BankAccount Map<String, BankAccount> accounts = new HashMap<String, BankAccount>(); 6 put(key, value) get(key) ´Add new mappings (a key mapped to a value): Map<String, BankAccount> accounts = new TreeMap<String, BankAccount>(); accounts.put("M",); accounts.put("G", new BankAcnew BankAccount("Michel", 111.11)count("Georgie", 222.22)); accounts.put("R", new BankAccount("Daniel",
    [Show full text]
  • Algorithms & Data Structures: Questions and Answers: May 2006
    Algorithms & Data Structures: Questions and Answers: May 2006 1. (a) Explain how to merge two sorted arrays a1 and a2 into a third array a3, using diagrams to illustrate your answer. What is the time complexity of the array merge algorithm? (Note that you are not asked to write down the array merge algorithm itself.) [Notes] First compare the leftmost elements in a1 and a2, and copy the lesser element into a3. Repeat, ignoring already-copied elements, until all elements in either a1 or a2 have been copied. Finally, copy all remaining elements from either a1 or a2 into a3. Loop invariant: left1 … i–1 i … right1 a1 already copied still to be copied left2 … j–1 j … right2 a2 left left+1 … k–1 k … right–1 right a3 already copied unoccupied Time complexity is O(n), in terms of copies or comparisons, where n is the total length of a1 and a2. (6) (b) Write down the array merge-sort algorithm. Use diagrams to show how this algorithm works. What is its time complexity? [Notes] To sort a[left…right]: 1. If left < right: 1.1. Let mid be an integer about midway between left and right. 1.2. Sort a[left…mid]. 1.3. Sort a[mid+1…right]. 1.4. Merge a[left…mid] and a[mid+1…right] into an auxiliary array b. 1.5. Copy b into a[left…right]. 2. Terminate. Invariants: left mid right After step 1.1: a unsorted After step 1.2: a sorted unsorted After step 1.3: a sorted sorted After step 1.5: a sorted Time complexity is O(n log n), in terms of comparisons.
    [Show full text]
  • Highly Parallel Fast KD-Tree Construction for Interactive Ray Tracing of Dynamic Scenes
    EUROGRAPHICS 2007 / D. Cohen-Or and P. Slavík Volume 26 (2007), Number 3 (Guest Editors) Highly Parallel Fast KD-tree Construction for Interactive Ray Tracing of Dynamic Scenes Maxim Shevtsov, Alexei Soupikov and Alexander Kapustin† Intel Corporation Figure 1: Dynamic scenes ray traced using parallel fast construction of kd-tree. The scenes were rendered with shadows, 1 TM reflection (except HAND) and textures at 512x512 resolution on a 2-way Intel °R Core 2 Duo machine. a) HAND - a static model of a man with a dynamic hand; 47K static and 8K dynamic triangles; 2 lights; 46.5 FPS. b) GOBLIN - a static model of a hall with a dynamic model of a goblin; 297K static and 153K dynamic triangles; 2 lights; 9.2 FPS. c) BAR - a static model of bar Carta Blanca with a dynamic model of a man; 239K static and 53K dynamic triangles; 2 lights; 12.6 FPS. d) OPERA TEAM - a static model of an opera house with a dynamic model of 21 men without instancing; 78K static and 1105K dynamic triangles; 4 lights; 2.0 FPS. Abstract We present a highly parallel, linearly scalable technique of kd-tree construction for ray tracing of dynamic ge- ometry. We use conventional kd-tree compatible with the high performing algorithms such as MLRTA or frustum tracing. Proposed technique offers exceptional construction speed maintaining reasonable kd-tree quality for ren- dering stage. The algorithm builds a kd-tree from scratch each frame, thus prior knowledge of motion/deformation or motion constraints are not required. We achieve nearly real-time performance of 7-12 FPS for models with 200K of dynamic triangles at 1024x1024 resolution with shadows and textures.
    [Show full text]
  • Singly-Linked Listslists
    Singly-LinkedSingly-Linked ListsLists © 2011 John Wiley & Sons, Data Structures and Algorithms Using Python, by Rance D. Necaise. Modifications by Nathan Sprague LinkedLinked StructureStructure Constructed using a collection of objects called nodes. Each node contains data and at least one reference or link to another node. Linked list – a linked structure in which the nodes are linked together in linear order. © 2011 John Wiley & Sons, Data Structures and Algorithms Using Python, by Rance D. Necaise. Linked Structures – 2 LinkedLinked ListList Terms: head – first node in the list. tail – last node in the list; link field has a null reference. self._ © 2011 John Wiley & Sons, Data Structures and Algorithms Using Python, by Rance D. Necaise. Linked Structures – 3 LinkedLinked ListList Most nodes have no name; they are referenced via the link of the preceding node. head reference – the first node must be named or referenced by an external variable. Provides an entry point into the linked list. An empty list is indicated by a null head reference. self._ © 2011 John Wiley & Sons, Data Structures and Algorithms Using Python, by Rance D. Necaise. Linked Structures – 4 SinglySingly LinkedLinked ListList A linked list in which each node contains a single link field and allows for a complete linear order traversal from front to back. self._ © 2011 John Wiley & Sons, Data Structures and Algorithms Using Python, by Rance D. Necaise. Linked Structures – 5 NodeNode DefinitionDefinition The nodes are constructed from a simple storage class: class ListNode: def __init__(self, data, next_node): self.data = data self.next = next_node © 2011 John Wiley & Sons, Data Structures and Algorithms Using Python, by Rance D.
    [Show full text]
  • Quadcore with Coreboot / Libreboot on the T500 (Hopefully the T400 As Well)
    QuadCore with Coreboot / Libreboot on the T500 (hopefully the T400 as well) (Translator’s note: Unfortunately, I couldn’t get pdflatex to compile with images, so here’s the link, I’ll put lines in at least so that you can see where each image goes) I tested the quadcore-mod from here first on a T500 mainboard, but back then, the BIOS did me a great disservice, see here and read the paragraph “Why this can’t be done for the T500 and W500” at the end of the first post. Meanwhile, we got Libreboot for the T500, which is basically Coreboot without BLOBs, i.e. CPU microcode. The code differs from coreboot in certain other aspects, however I don’t know exactly. With the ROMs offered for the T500, Quads don’t work either. Finally, I got to actually using a Pandaboard to debug Libreboot’s boot process with a Quad-core installed. The boot process hangs when the third CPU is to be initialized. Looking at the code, I found out that the kconfig data is built to the original specs. In the case of the T500 (which takes the data from the folder for the T400), the maximum count for the CPU is set to two. I changed the count to 4, generated the ROM again, flashed it –> You got quadcore. Because the current Libreboot version doesn’t support screens larger than 1280x800 with the T500, I had to extract the original VGA-BIOS for the Intel graphics from the original Lenovo BIOS and integrate it instead of the “native VGA init” into the ROM.
    [Show full text]