Wikibooks
enwikibooks
https://en.wikibooks.org/wiki/Main_Page
MediaWiki 1.47.0-wmf.13
first-letter
Media
Special
Talk
User
User talk
Wikibooks
Wikibooks talk
File
File talk
MediaWiki
MediaWiki talk
Template
Template talk
Help
Help talk
Category
Category talk
Cookbook
Cookbook talk
Transwiki
Transwiki talk
Wikijunior
Wikijunior talk
Subject
Subject talk
TimedText
TimedText talk
Module
Module talk
Event
Event talk
Soviet History
0
21431
4655971
4213225
2026-08-01T06:35:15Z
一隻北極熊
3609960
4655971
wikitext
text/x-wiki
[[File:Coat of arms of the Soviet Union (1956–1991).svg|center|200px|Coat of arms of the Soviet Union.]]
{{Book title|{{BOOKNAME}}|}}
In 1917, the Russian Empire was losing a war against both Germany and Austria-Hungary. The population was starting to resent the Czar/Tsar, and wanted a different leader so the war would end. Vladimir Lenin, returning from exile in Switzerland, led the Communist Party of Russia to power in the October Revolution.
==Chapters==
{{Book search}}
*[[/Before The Creation of the Soviet Union/]]
*[[/Russian Civil War/]]
*[[/Leadership of Vladimir Lenin/]]
*[[/Leadership of Stalin, 1925-1938/]]
*[[/Pre-War Soviet-German Relations/]]
*[[/Great Patriotic War 1941-1945/]]
*[[/Rebuilding After The War 1945-1953/]]
*[[/Soviet Union becomes a Superpower/]]
*[[/Nikita Khrushchev 1953-1965/]]
*[[/Leonid Brezhnev 1965-1983/]]
*[[/Yuri Andropov 1983-1984/]]
*[[/Konstantin Chernenko-1984-1985/]]
*[[/Mikhail Gorbachev 1985-1990/]]
*[[/The Collapse of the Soviet Union/]]
[[zh:蘇聯歷史]]
{{Alphabetical|S}}
{{Shelves|Asian history|European history}}
{{status|0%}}
e1z2blidukoi2jwu75d9k1oy8u2sa9s
Muggles' Guide to Harry Potter/Books/Philosopher's Stone/Chapter 2
0
35825
4655967
4308321
2026-07-31T23:58:22Z
Nasdn2
3595259
/* Synopsis */ delink: the text says dursleys but it links to privet drive
4655967
wikitext
text/x-wiki
{{Muggles' Guide to Harry Potter/Book/Page|prev=Chapter 1|next=Chapter 3|tab=2|title=The Vanishing Glass}}
== Synopsis ==
Almost ten years have passed since the Dursleys family took Harry Potter, now nearly 11 years old. Harry has grown into a skinny boy with unruly black hair and green eyes hidden behind round glasses. He also has a lightning-bolt-shaped scar on his forehead which his aunt and uncle attribute to the supposed car crash that killed his parents. The Dursleys' living room is filled with [[Muggles' Guide to Harry Potter/Characters/Dudley Dursley|Dudley's]] photographs, while there are none of Harry, who sleeps in a spidery cupboard under the staircase.
One morning, [[Muggles' Guide to Harry Potter/Characters/Petunia Dursley|Aunt Petunia]] awakens Harry, ordering him to cook breakfast. Today is Dudley's birthday, and everything must be perfect. The kitchen table is loaded with presents. The overweight Dudley is a bully who enjoys punching Harry, though he is rarely able to catch him. Dudley enters the kitchen and is about to throw a tantrum after counting the same amount of presents he received last year. Petunia only narrowly averts the temper by quickly promising to buy Dudley two more gifts that day, bringing the total to 39.
The Dursleys are taking Dudley to the zoo for his birthday, but they learn that [[Muggles' Guide to Harry Potter/Characters/Arabella Figg|Mrs Figg]], their cat-obsessed neighbour who usually looks after Harry at her house during such outings, has broken her leg and is unavailable. They discuss what to do with their nephew while Dudley wails that he does not want Harry to come along. However, Dudley's friend, Piers Polkiss, arrives, and the Dursleys are forced to let Harry join the expedition. [[Muggles' Guide to Harry Potter/Characters/Vernon Dursley|Uncle Vernon]] sternly warns Harry that if any "funny business" occurs, he will be in the cupboard until Christmas — strange things seem to happen around Harry, and the Dursleys refuse to believe he did not cause them.
Uncle Vernon becomes angry when Harry mentions dreaming about a flying motorcycle during their drive to the zoo. The trip goes well at first, and Harry even gets some ice cream. Harry has a conversation with a large boa constrictor in the reptile house. When Dudley pushes Harry aside so he can see the snake's strange behaviour, the glass enclosing the snake exhibit vanishes. The snake slithers out, thanking Harry and saying it will go to its natural environment in Brazil.
In the car, Dudley and Piers greatly exaggerate their snake encounter, claiming it attacked them. Back home, a furious Uncle Vernon sends Harry to his cupboard, saying he will not be allowed any meals for a week. As Harry lies inside, thinking, he remembers faint images of a flashing green light and pain in his forehead. He also recalls how, occasionally, when he is out with the Dursleys, odd-looking people seem to recognise him.
== Analysis ==
It is immediately apparent that Harry is unlike other boys, a fact that is not only known by Vernon and Petunia but one they are uncomfortable with. The abusive Dursleys have treated him as little more than a slave, showing him no affection or even the slightest respect. Despite this ill-treatment, however, Harry is neither timid nor bitter and is generally cheerful and kind, unlike his cousin Dudley, who is being shaped into a cruel, egotistical bully by his parents' overindulgence, and whose name reflects his personality (a dud). Harry's early traits show the admirable attributes vital to his destiny.
Harry's magical talents are seen burgeoning here, as he makes the glass partition at the zoo disappear and converses with the snake (the latter is explained more fully in this book's sequel, [[Muggles' Guide to Harry Potter/Books/Chamber of Secrets|''Harry Potter and the Chamber of Secrets'']]). The author has said that this uncontrolled magical ability is normal for wizard children who are still unable to control their powers. Like other Muggle-raised wizard children, Harry knows nothing about these talents, likely making their effect even more disturbing and potentially harmful to those around them. Strangely, Harry hardly seems frightened by these bizarre incidents and only casually questions them. This suggests that he innately accepts magic and perhaps has an unconscious awareness about his true wizard nature. His enforced isolation from the wizarding world and much of the muggle world also gives him little reference for what is considered "normal".
Harry has also started experiencing residual memories about his parents' deaths, though he was told they were killed in a car crash. The flying motorcycle in his dream is the one [[Muggles' Guide to Harry Potter/Characters/Rubeus Hagrid|Hagrid]] used to transport him to the Dursleys, and the green flash he recalls, though as yet unexplained, is the curse Voldemort cast to kill him.
== Questions ==
{{Muggles' Guide to Harry Potter/Questions}}
=== Review ===
# Why did Dudley pretend to cry before they left to go to the zoo?
# Why did Dudley stop his fake crying when his friend arrived?
# Why do the Dursleys take Harry with them to the zoo rather than just leave him at home?
# What "strange" things tend to happen around Harry?
=== Further Study ===
# Why do you think the Dursleys treat Harry the way they do?
# Why do the Dursleys punish Harry for all the strange things that happen?
# What do the strange things happening around Harry reveal about his character? What does he think about it?
# Why can a snake talk to Harry?
# Why would strangers on the street seem to recognize Harry?
# Why does Harry dream about a flying motorbike? Why would this make Uncle Vernon angry?
== Greater Picture ==
{{Muggles' Guide to Harry Potter/Intermediate Spoiler}}
The scene with the snake could foreshadow events in the following two chapters. Harry and the snake are both prisoners, cut off from the world they truly belong to: Harry, stuck with the Dursleys, is isolated from the Wizarding world, just as the snake, captive in the zoo, is prevented from living in the Amazon jungle. Also, both have been raised away from their proper homes and lack knowledge about their native worlds. Each, in turn, is released from their prison and heads toward an unknown future, somehow believing that it must be better than what they are leaving behind.
We learn about Harry's ability to speak to snakes, which becomes important in future books. A wizard who can talk to snakes is called a [[Muggles' Guide to Harry Potter/Magic/Parselmouth|Parselmouth]], and the language itself is called [[Muggles' Guide to Harry Potter/Magic/Parseltongue|Parseltongue]]. Being Muggle-raised, Harry does not know just how rare this ability is and will be dismayed to learn that it is linked with the descendants of [[Muggles' Guide to Harry Potter/Characters/Salazar Slytherin|Salazar Slytherin]], a wizard who is seen as an originator of the highly prejudiced [[Muggles' Guide to Harry Potter/Magic/Pureblood|system of beliefs about Blood purity]]. It will be a plot point in two later books that Harry is unaware whether he speaks and hears English or Parseltongue.
The speaking with snakes, and the disappearing glass, are only the latest manifestations of Harry's magical background. In this chapter, we have also read about flying to a rooftop to avoid a beating from Dudley's gang, hair that grew back overnight, and a jumper that shrunk impossibly when Aunt Petunia was trying to fit it onto Harry. While it may seem that these early magical signs could trigger [[Muggles' Guide to Harry Potter/Characters/Albus Dumbledore|Albus Dumbledore]]'s great plan into action, we must recall that Harry is about to turn 11. When magical children turn that age, they are invited to attend [[Muggles' Guide to Harry Potter/Places/Hogwarts School of Witchcraft and Wizardry|Hogwarts]], which they begin the September that follows their eleventh birthday. The author has stated that Hogwarts is the only Wizarding school in the United Kingdom. Thus, every magical child can attend when they reach 11. Not all children do; some, like [[Muggles' Guide to Harry Potter/Characters/Marvolo Gaunt|Marvolo Gaunt]], who we will meet later in the series, likely would never have entrusted the established school system with their children. Others may attend a school in another country. [[Muggles' Guide to Harry Potter/Characters/Draco Malfoy|Draco Malfoy]], Harry's future nemesis, mentions that he almost went to [[Muggles' Guide to Harry Potter/Places/Durmstrang Institute|Durmstrang]], a school hidden somewhere in Eastern Europe.
It should be noted that Harry, in this chapter, produces the same effect as a Vanishing Spell, a spell that isn't taught until the fifth year and does so without a wand. Harry also demonstrates wandless magic in [[Muggles' Guide to Harry Potter/Books/Prisoner of Azkaban/Chapter 2|''Harry Potter and the Prisoner of Azkaban'']] when [[Muggles' Guide to Harry Potter/Characters/Marge Dursley|Aunt Marge]] insults [[Muggles' Guide to Harry Potter/Characters/James Potter|Harry's father]]. The common factor in these events, along with the earlier manifestations of magic, was that Harry was emotionally charged. From this, it is easy to infer that wandless magic is associated with strong emotional feelings.
As the story progresses, Harry's personal qualities and flaws are continually seen as he matures into a young man. Whereas Harry develops into a well-rounded person, the Dursleys are always depicted as two-dimensional, uncaring, and unpleasant characters whose faults are deliberately exaggerated to contrast Harry's good nature with the worst human attributes.
Although Harry has no idea yet that he possesses magical powers, he is beginning to realize he has some unusual abilities that other children lack. From later conversations Harry has with Muggle-born wizard children, it appears their families were generally unaware the Wizarding world existed until their child was old enough to attend Hogwarts. The parents, who probably realized their child was somehow different, generally are quite shocked upon learning they have a magical offspring. It is unknown why Muggle parents are apparently never told about the magical world before their child's eleventh birthday. At least some Muggle-born magical children may show no overt magical ability until they are older and therefore remain undetected by the Wizarding community. Harry, however, discovers that the Dursleys have always known that he is a wizard and not only deliberately withheld this information but attempted to suppress his magical ability. Harry also learns his parents were wizards and were murdered rather than killed in a car crash as the Dursleys told him. Harry will discover even later that Aunt Petunia knows far more about the Wizarding world than she has ever let on, even to her husband.
Under the pretext of explaining why the Dursleys fear leaving Harry home alone, we learn how he previously used magic before knowing he was a wizard, basically in self-defence. This story contrasts with the tale in [[Muggles' Guide to Harry Potter/Books/Half-Blood Prince/Chapter 13|''Harry Potter and the Half-Blood Prince'']] of how the young boy, [[Muggles' Guide to Harry Potter/Characters/Tom Marvolo Riddle|Tom Riddle]] (later known as [[Muggles' Guide to Harry Potter/Characters/Lord Voldemort|Lord Voldemort]]), used his powers to terrorize other children before learning he was a wizard. This comparison between the two characters adds another layer to the good vs. evil theme.
Mrs Figg, who, like many characters in this series, is introduced by name before being seen in person, is the Dursleys' odd neighbour who occasionally watches Harry. Although she appears to be an unlikeable person, she is tied to the wizard world (though she has no magical powers) and works for Professor Dumbledore, helping guard Harry. She is also a member of [[Muggles' Guide to Harry Potter/Major Events/Order of the Phoenix|the Order of the Phoenix]], Dumbledore's secret organization that fights Voldemort. Another character, [[Muggles' Guide to Harry Potter/Characters/Marge Dursley|Aunt Marge]], Vernon's sister, is also mentioned by name in this chapter. Unlike Mrs Figg, she is very unpleasant, as seen in ''Harry Potter and the Prisoner of Azkaban,'' where she has a small but pivotal role in one chapter.
=== Connections ===
*Sirius Black's flying motorcycle, initially seen in the [[Muggles' Guide to Harry Potter/Books/Philosopher's Stone/Chapter 1|previous chapter]], is very likely the motorcycle that Harry dreams about.
*The green flashes in Harry's dream likely also are the wand flashes of [[Muggles' Guide to Harry Potter/Characters/Lord Voldemort|Voldemort]] killing Harry's mother and attempting to kill Harry.
*Harry's ability to talk to snakes will form a major plot point in the next book, ''Harry Potter and the Chamber of Secrets''. It will also be fundamental to Harry's understanding of an episode at [[Muggles' Guide to Harry Potter/Places/House of Gaunt|the Gaunt shack]] in [[Muggles' Guide to Harry Potter/Books/Half-Blood Prince/Chapter 10|''Harry Potter and the Half-Blood Prince'']] and the technique used to open a locket in [[Muggles' Guide to Harry Potter/Books/Deathly Hallows/Chapter 19|''Harry Potter and the Deathly Hallows'']]. Harry's being unaware of whether he is speaking English or Parseltongue will also be critical to an episode in [[Muggles' Guide to Harry Potter/Books/Deathly Hallows/Chapter 17|''Harry Potter and the Deathly Hallows'']]. In [[Muggles' Guide to Harry Potter/Books/Deathly Hallows/Chapter 31|''Harry Potter and the Deathly Hallows'']], Ron is able to use Harry's Parseltongue ability to open the [[Muggles' Guide to Harry Potter/Places/Chamber of Secrets|Chamber of Secrets]], repeating from memory what he once heard Harry speaking.
*Mrs Figg [[Muggles' Guide to Harry Potter/Books/Order of the Phoenix/Chapter 2|will turn out]] to be tied to the Wizarding world, not only knowing about Harry's situation but also monitoring Harry's progress and reporting problems to [[Muggles' Guide to Harry Potter/Characters/Albus Dumbledore|Professor Dumbledore]].
1ea9kot4inky3khf178fqjby95v843j
Wikibooks:List of class projects
4
97303
4655968
4602674
2026-08-01T01:16:05Z
Alexander.Sidorkin
3618390
/* Critical Thinking */ new section
4655968
wikitext
text/x-wiki
{{Classproject}}
{{shortcut|WB:LCP}}
Please read [[Wikibooks:Guidelines for class projects]]. This page is a listing of all class and group projects that are using wikibooks to collaboratively write textbooks and instructional materials. <br>
''Note that old projects have been moved to Archives. No data has been deleted and you should be able to find your project in its original location.''
{{Archive box|
/Archive 1}}
{{-}}
{|
|-
| style="vertical-align: top;" | __TOC__
| style="vertical-align: top;" | We ask that all new class projects '''include the following information''':
#'''Subject''' The basic subject of your book, such as "Physiology", or "Algebra"
#'''Wikibook''' The title of your book, such as [[Human Physiology]], or [[Algebra]].
#'''Educational Setting''' The type of class or group editing the book. Such as a highschool class, or a seniors group
#'''Dates''' The timeframe for the project. Classes typically are only in session for a finite amount of time.
#'''Moderator''' The username of the group leader here on wikibooks. Every group should have a leader (classes, for instance, have a teacher).
#'''Comments''' Additional comments about the book, requests for specific types of help, etc.
<div style="width: 100%; text-align: center; font-size: larger;" class="PrettyTextBox">
[{{fullurl:Wikibooks:List_of_class_projects|action=edit§ion=new}} Add a New Project]</div>
|}
== Paramedic Education: ==
* Book Title: "Strategies for Success in Paramedic School"
* Instructional Level: Collegiate
* Date of initial Development: 10/2014-1/30/2016
* Moderator: pjohnson181
The goal of this book is to provide a constantly updating resource for students enrolled in Paramedic education and most specifically for those enrolled in New River Community and Technical College's Paramedic Program: Instructor - Paula Johnson
== Perspectives in Digital Culture ==
'''1. Subject''' Digital Cultures
'''2. Wikibook''' Perspectives in Digital Culture
'''3. Educational Setting''' Undergraduate Module FMSU9A4, [[Wikipedia:University of Stirling|University of Stirling]]
'''4. Dates''' February and March 2015
'''5. Moderator''' [[User:GregXenon01|GregXenon01]] ([[User talk:GregXenon01|discuss]] • [[Special:Contributions/GregXenon01|contribs]])
'''6. Comments''' Users are new to Wikipedia and related projects. Part of an Educational Assignment. Students will be working in groups of 6 towards individual and group assessment. The aim of this assessment is to get students working at different levels - as individual researchers, as research teams, and as research communities. That is to say: producing knowledge; collaboration and sharing; and peer-reviewing the work of others for the good of the community. Each group will work on a chosen theme, integrating their independent research with (fully cited) lecture materials and independent study. [[User:Hopkinson28|Hopkinson28]] ([[User talk:Hopkinson28|discuss]] • [[Special:Contributions/Hopkinson28|contribs]]) 14:25, 10 February 2015 (UTC)
== Educational psychology ==
* Title: Cognition and Instruction
* Educational setting: Undergraduate university class
* Dates: September 2015 to December 2015
* Moderator: [https://en.wikipedia.org/wiki/User:Nesbit Nesbit]
== An Internet of Everything? ==
'''1. Subject''' Digital Cultures
'''2. Wikibook''' Perspectives in Digital Culture
'''3. Educational Setting''' Undergraduate Module FMSU9A4, Spring 2016 [[Wikipedia:University of Stirling|University of Stirling]]
'''4. Dates''' February and March 2016
'''5. Moderator''' [[User:GregXenon01|GregXenon01]] ([[User talk:GregXenon01|discuss]] • [[Special:Contributions/GregXenon01|contribs]])
'''6. Comments''' Users are new to Wikipedia and related projects. Part of an Educational Assignment. Students will be working in groups of 5 towards individual and group assessment. The aim of this assessment is to get students working at different levels - as individual researchers, as research teams, and as research communities. That is to say: producing knowledge; collaboration and sharing; and peer-reviewing the work of others for the good of the community. Each group will work on a chosen theme, integrating their independent research with (fully cited) lecture materials and independent study.
== Rhetoric ==
'''1.''' '''Subject''' Rhetoric
'''2.''' '''Wikibooks''' The Study of Rhetoric
'''3.''' '''Educational Setting''' Undergraduate ENGL208, Fall 2016 Saint Xavier University
'''4.''' '''Dates''' September - November 2016
'''5.''' '''Moderator''' KaiserLee (discuss • contribs)
'''6.''' '''Comments''' Each student will work on a chosen rhetorical term, and will compile their independent research with fully cited entries. The class will collaborate on the introductory essay, "What is Rhetoric?" (tentative title).
Textbook on the study of rhetoric, with an emphasis on the Western tradition of rhetoric.
== Psychology ==
== Human Memory ==
* '''Wikibook:''' Human Memory: A User's Manual
* '''Instructional Level:''' Collegiate
* '''Date of initial Development:''' November 2016 - May 2017
* '''Moderator:''' [[User:apsUH|apsUH]]
* '''Comments:''' The goal of this project is to offer reading material and useful links to students enrolled in the University of Hawaii's Psychology 429 Course, "Human Memory: A User's Manual": Instructor - Art Shimamura
== Open and Distance Education: ==
* Book Title: Open and Distance Education
* Instructional Level: Graduate Level
* Date of initial Development: 12/01/2017-2/21/2018
* Moderator: [[User:Rjbfigueroa|Roberto Figueroa Jr]]
The goal of this book is to provide a constantly updating resource for students enrolled in Distance and eLearning most specifically in the International Christian University: Instructor - Insung Jung
== Fall 2018 PBSC College Algebra ==
* Subject: College Algebra
* Wikibook: College Algebra by Fall 2018 PBSC CA Students
* Educational Setting: This book is to be written as a group by students in my College Algebra class this upcoming Fall semester.
* Dates The timeframe for the project: Aug to Dec 2018
* Moderator: [[User:Anuragkatyal|Anuragkatyal]]
* Comments This is a group project for the Fall 2018 College Algebra course at Palm Beach State College taught by me, Anurag Katyal.
== Perspectives of Aquatic Toxicology==
*'''Subject''': Aquatic Toxicology
*'''Wikibook''': Perspectives of Aquatic Toxicology
*'''Educational Setting''': Aquatic Toxicology A ECL 444/ 544X TOX 444/ 544X Course , Iowa State University
*'''Dates''': February 2019 - June 2020
*'''Moderator''': Boris Jovanovic, Evrim Baran, Dana AlZoubi
*'''Comments''': This is a group project performed in Aquatic Toxicology course, taught by Dr Boris Jovanovic, at Iowa State University.
== Social media and communication behavior ==
'''1. Subject''': Computer-mediated Communication
'''2. Wikibook''': Social media and communication behavior
'''3. Educational Setting''': Undergraduate Module CNM4881a, Spring 2020 [[Wikipedia:National University of Singapore|National University of Singapore]]
'''4. Dates''': January - May 2020
'''5. Moderator''': Kokil Jaidka
'''6. Comments''': Users are students and are likely new to contributing to Wikipedia. They will work in groups towards assessments. The aim of the exercise is to produce knowledge and to teach the benefits of collaboration, sharing, and peer-review. Each group will contribute towards three themes in course of the semester, integrating their own readings with lecture materials. All information will be comprehensively cited and an up-to-date list of references will be maintained.
== Sustainability and Sense of Place in the Sonoran Desert ==
# '''Subject:''' Interdisciplinary
# '''Title:''' [[Sustainability and Sense of Place in the Sonoran Desert]].
# '''Setting:''' College level honors colloquium - [https://en.wikipedia.org/wiki/Arizona_Western_College Arizona Western College]
# '''Dates:''' Spring 2020
# '''Moderator:''' [[User:Atlas.Spheres|Jacob Gibson]]
# '''Comments:''' This book compiles an ecological and cultural background of the Sonoran Desert to discover a sense of this iconic place. Editorial help and subject help both appreciated!
== Information Technology and Ethics ==
# '''Subject:''' Information Technology and Ethics
# '''Wikibook:''' [[Information Technology and Ethics]].
# '''Educational Setting:''' [http://illinoistech.edu Illinois Institute of Technology] university undergraduate and graduate students in Information Technology, Applied Cybersecurity, and Cybersecurity Engineering.
# '''Dates:''' The project repeats each Spring semester, January though May, and began in Spring of 2016. For Spring 2020, the project is due April 28th.
# '''Moderator:''' [http://trygstad.rice.iit.edu Ray Trygstad], Industry Professor of Information Technology and Management.
# '''Comments:''' Since 2016, the ''Legal and Ethical Issues in Information Technology'' course, [http://bulletin.iit.edu/search/?P=ITMM%20485 ITMM 485]/[http://bulletin.iit.edu/search/?P=ITMM%20585 ITMM 585], at [http://illinoistech.edu Illinois Institute of Technology] has been working on improving this Wikibook by creating new chapters or improving existing chapters in this pre-existing book as a class project. If successful, this project will continue in coming semesters until the book is in an acceptable and useful state. Each chapter the class has worked on should be documented in the discussion page for that chapter. Please address any questions or suggestions to me at [mailto:trygstad@iit.edu trygstad@iit.edu]. [[User:Ray Trygstad|Ray Trygstad]] ([[User talk:Ray Trygstad|discuss]] • [[Special:Contributions/Ray Trygstad|contribs]]) 18:07, 31 January 2020 (UTC)
=== Call for Participation ===
As this is a subject taught at many institutions, everyone is welcome to join this project and we are willing to coordinate everyone's efforts. Please address inquiries to me at [mailto:trygstad@iit.edu trygstad@iit.edu].
== Electronic Properties of Materials ==
This is part of a 15 week graduate course taught by Scott.beckman. Currently Prof. Beckman has 200+ pages of hand written notes and the students will be digitizing these as part of the course, spring 2020.
There are currently 3 sub-sections, each sub-section containing about 10-15 chapters.
The subsections are
# Quantum Mechanics for Engineers
# Band Theory of Solids
# Electronic Properties
At some point in the future, it would be desirable to add a fourth sub-section that focuses on Devices. This will not be possible during spring 2020.
== Perspectives in Digital Literacy ==
'''1. Subject''': Digital Literacy
'''2. Wikibook''': Perspectives in Digital Literacy
'''3. Educational Setting''': Composition undergraduates at LaGuardia Community College
'''4. Dates''': Beginning December 2020 and continuing for the foreseeable future depending on the output of the classes. The course repeats every semester.
'''5. Moderator''': [[User:Doctorxgc| Ximena Gallardo, a.k.a. Dr. X]]
'''6. Comments''': Members of the project are probably new to Wikimedia projects and wikiwork, so there may be a learning curve, especially during this time of remote learning. Every semester a class will research a new sub-theme/section, e.g. misinformation.
== Themes in Literature==
'''1. Subject''': Thematic literary analysis
'''2. Wikibook''': Themes in Literature
'''3. Educational Setting''': Composition undergraduates at LaGuardia Community College
'''4. Dates''': Beginning December 2020 and continuing for the foreseeable future depending on the output of the classes. The course repeats every semester.
'''5. Moderator''': [[User:Doctorxgc| Ximena Gallardo, a.k.a. Dr. X]]
'''6. Comments''': Members of the project are probably new to Wikimedia projects and wikiwork, so there may be a learning curve, especially during this time of remote learning. Every semester a class will research a new sub-theme/section, e.g. "Isolation and Community" (this year's theme).
== Women's Writing Before Woolf: A Social Reference ==
'''Subject:''' literature
'''Wikibook:''' ''Women's Writing Before Woolf: A Social Reference''
'''Educational Setting:''' a third-year course at the University of Newcastle, Australia
'''Dates:''' initial work on the book will run from February to July 2021, but this course is taught annually and each cohort will contribute to the production and maintenance of the book.
'''Moderator:''' [https://www.newcastle.edu.au/profile/erin-mccarthy Dr. Erin A. McCarthy]
'''Comments:''' Students will begin posting their first entries in the next few weeks. They may need assistance with the technical elements of the project, especially later in the term, when they are required to edit one another's work. I will be marking the content elsewhere.
{{Wikibooks editor navigation}}
== Principles of Pharmacology ==
* '''Subject''': Pharmacology & Toxicology
* '''Wikibook''': Principles of Pharmacology and Toxicology
* '''Educational Setting''': Bio 321 Principles of Pharmacology & Toxicology, Concordia University, Nebraska
* '''Dates''': January 2023 - May 2023
* '''Moderator''': Kyle Johnson
* '''Comments''': This is a group project performed in Principles of Pharmacology course, taught by Dr. Kyle Johnson, at Concordia University, Nebraska. The topics discussed in this book do not necessarily represent the viewpoints of Concordia University or the LCMS.
[[User:Kylebjohnson70|Kylebjohnson70]] ([[User talk:Kylebjohnson70|discuss]] • [[Special:Contributions/Kylebjohnson70|contribs]]) 04:47, 24 December 2022 (UTC)
== The Future of Leadership ==
'''Subject:''' Organizational Leadership
'''Wikibook:''' [[The Future of Leadership]]
'''Educational Setting:''' MGT 5599, The Future of Leadership, Idaho State University, Pocatello, Idaho
'''Dates:''' January 2023-March 2023
'''Moderator:''' Alex Bolinger
'''Comments:''' This book is a group project for Dr. Bolinger's The Future of Leadership elective course in the College of Business at Idaho State University. The views discussed in this book represent those of the class and the research that they cite. [[User:Boliale2|Boliale2]] ([[User talk:Boliale2|discuss]] • [[Special:Contributions/Boliale2|contribs]]) 23:48, 23 February 2023 (UTC)
== Computer Science IB ==
'''Subject:''' Computer science for the IB diploma
'''Wikibook:''' [[IB/Group 4/Computer Science|https://en.wikibooks.org/wiki/IB/Group_4/Computer_Science]]
'''Educational Setting:''' Computer Science Standard Level, Diploma years, Ecole Jeanine Manuel, Paris, France
'''Dates: '''April 2023 - April 2024
'''Moderator:''' Camille Duquesne [[User:Kappamille]]
'''Comments:''' Given the lack of a very solid text book for the current IB program of computer science, students have prepared specific book pages that were reviewed in class. If the student's work is fitting they will integrate it to the book. Members of the project are probably new to Wikimedia projects and may need guidance. Contents of the page will be graded in class. [[User:Kappamille|Kappamille]] ([[User talk:Kappamille|discuss]] • [[Special:Contributions/Kappamille|contribs]]) 15:07, 3 April 2023 (UTC)
== Native American Management Practices ==
'''Subject:''' Native American Management Practices: Where and How they Differ!
'''Wikibook:''' https://en.wikibooks.org/wiki/Native_American_Management_Practices
'''Educational Setting:''' Business Majors at a Tribal College
'''Dates''': April 2023 - April 2030
'''Moderator:''' dpfowler
''''''Comments'''''
'
This new Wikibook is a class project with Saginaw Chippewa Tribal College (SCTC) management students. The book's development will be an ongoing project with subsequent management classes making additional contributions and its development communicated to other tribal colleges and their students. Previous Wikibooks initiated by the instructor include "Learning Theories" in 2006, which is recognized by Wikibooks as a Featured Book, and well as "Learning Theorists" 2007). [[User:Dpfowler|Dpfowler]] ([[User talk:Dpfowler|discuss]] • [[Special:Contributions/Dpfowler|contribs]]) 20:04, 10 April 2023 (UTC)
== Digital Public Infrastructure ==
1. <b>Subject:</b> Digital Public Infrastructure
2. <b>Wikibook:</b> [[Public Digital Backbone]]
3. <b>Educational Setting:</b> Practicianers and students working in and for the Digital Age
4. <b>Dates:</b> 2 August 23 to 31 December 23
5. <b>Moderator:</b> Anil Shaligram
6. <b>Comments:</b> This wiki textbook is useful for the unfolding field of Digital Public Infrastructure that is catching up. All those who are drawn to the field can contribute without any institutional bounderies. But for practical reasons and to trigger the process a few dedicated contributes will take initiative. Also the core subject is not restricted to this textbook but more allied Wikibooks are planned. So it will form a useful Shelf for students. [[User:Anil Shaligram|Anil Shaligram]] ([[User talk:Anil Shaligram|discuss]] • [[Special:Contributions/Anil Shaligram|contribs]]) 12:00, 10 October 2023 (UTC)
[[Category:Wikibooks]]
== A Companion to Our Literary Journey ==
# '''Subject''' A book for advanced students of English as a Second Language in Italian High Schools
# '''Wikibook''' [[A Companion to Our Literary Journey]]
# '''Educational Setting''' High school class (3rd year) - "Cambridge" curriculum (English as a Second Language)
# '''Dates''' School year 2024/2025.
# '''Moderator''' [[User:Ferdi2005]]
# '''Comments''' Hi there! I'm an it.wikipedia and it.wikibooks user, I'm happy to collaborate with the en.wikibooks community with this school project!
[[User:Ferdi2005|Ferdi2005]] ([[User talk:Ferdi2005|discuss]] • [[Special:Contributions/Ferdi2005|contribs]]) 13:56, 27 February 2025 (UTC)
== Natural sciences ==
Excretory system [[Special:Contributions/41.113.119.170|41.113.119.170]] ([[User talk:41.113.119.170|discuss]]) 12:40, 1 April 2025 (UTC)
== Civil ==
democracy
[[Special:Contributions/~2025-35233-99|~2025-35233-99]] ([[User talk:~2025-35233-99|talk]]) 19:56, 20 November 2025 (UTC)
== Critical Thinking ==
This introductory course examines thinking processes, dispositions, and the components of reasoning. It satisfies General Education Area 1B, Critical Thinking and Composition, and carries no prerequisite. Students learn argument reconstruction, formal and informal fallacies, cognitive bias, evidence evaluation, and decision making under uncertainty.
The section is designed as an AI-native course. Students are expected to use artificial intelligence throughout, without restriction, and the course asks what remains of human judgment when the tools are always available. The premise is that operating these systems is not the scarce skill. Judging them is. [[User:Alexander.Sidorkin|Alexander.Sidorkin]] ([[User talk:Alexander.Sidorkin|discuss]] • [[Special:Contributions/Alexander.Sidorkin|contribs]]) 01:16, 1 August 2026 (UTC)
31fju6v71fnq748p7jntvqto693jus0
Chess Opening Theory/1. c4/1...c5/2. Nf3
0
137914
4655963
3088537
2026-07-31T20:02:58Z
~2026-42570-29
3618339
Just added more examples
4655963
wikitext
text/x-wiki
{{Chess Opening Theory/Position|=
|English Opening - Symmetrical Variation|
|rd|nd|bd|qd|kd|bd|nd|rd|=
|pd|pd| |pd|pd|pd|pd|pd|=
| | | | | | | | |=
| | |pd| | | | | |=
| | |pl| | | | | |=
| | | | | |nl| | |=
|pl|pl| |pl|pl|pl|pl|pl|=
|rl|nl|bl|ql|kl|bl| |rl|=
||
}}
= English Opening - Symmetrical Variation=
===2. Nf3===
Main line symmetrical. The idea in this variation is to achieve the pawn break on d4 for white. Black on the other hand might calmly accept the pawn exchange and develop comfortably, with the ideal of pinning and destroying the white knight on c3. This can also lead to Catalan type of positions where white plays g3 and Bg2.
==Theory table==
{{Chess Opening Theory/Table}}.
<table border="0" cellspacing="0" cellpadding="4">
<tr>
<th align "center">1.c4 c5 2.Nf3</th>
</tr>
<tr>
<th></th>
<th align="left">2</th>
<th align="left">3</th>
<th align="left">4</th>
<th align="left">5</th>
</tr>
<tr>
<th align="right"></th>
<td>Nf3<br>[[/2...Nf6|Nf6]]</td>
<td>d4<br>cxd4</td>
<td>Nxd4<br>e6</td>
<td>Nc3<br>Nc6</td>
<td>=</td>
</tr>
<tr>
<th align="right"></th>
<td>...<br>[[/2...g6|g6]]</td>
<td>Nc3<br>Bg7</td>
<td>e3<br>Nf6</td>
<td>d4<br>cxd4</td>
<td>=</td>
</tr>
<tr>
<th align="right"></th>
<td>...<br>[[/2...Nc6|Nc6]]</td>
<td>Nc3<br>Nf6</td>
<td>+=</td>
</tr>
</table>
{{ChessMid}}
{{Wikipedia|English Opening}}
==References==
{{reflist}}
{{BCO2}}
{{ChessFooter}}
shme45uv3a2ubnuu7w11rvaumb300tp
Wikibooks:Reading room/Administrative Assistance
4
140081
4655948
4655877
2026-07-31T12:25:12Z
MathXplore
3097823
Reporting Aranyaresidency
4655948
wikitext
text/x-wiki
__NEWSECTIONLINK__ {{Discussion Rooms}} {{shortcut|WB:AN|WB:AA}} {{TOC left}}
{{User:MiszaBot/config
|archive = Wikibooks:Reading room/Administrative Assistance/Archives/%(year)d/%(monthname)s
|algo = old(14d)
|counter = 1
|minthreadstoarchive = 1
|minthreadsleft = 1
}}
{{ombox|type=content|text='''To request a rename or usurpation''', go to the global request page at Meta [[meta:SRUC|here]].<br />''Please do not post those requests here!''}}
{{Clear}}
Welcome to the '''Administrative Assistance reading room'''. You can request assistance from [[WB:ADMIN|administrators]] for handling a variety of problems here and alert them about problems which may require special actions not normally used during regular content editing. Please be patient as administrators are often quite busy with either their own projects or trying to perform general maintenance and cleanup.
You can deal with most vandalism yourself: [[Wikibooks:Dealing with vandalism|fix it]], then [[Wikibooks:Templates/User_notices|warn the user]]. If there is repeated vandalism by one user, lots of vandalism on a single page, or vandalism from many users, tell an admin here, or in [irc://irc.freenode.net/wikibooks #wikibooks] (say <code>!admin</code> to get attention).
For more general questions and assistance that doesn't require an administrator, please use the [[WB:HELP|Assistance Reading Room]].
{{clear}}
[[Category:Reading room]]
== Drpriyajaganathan reported by MathXplore ==
* {{userlinks|Drpriyajaganathan}}
Spam <!-- USERREPORTED:/Drpriyajaganathan/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 10:46, 18 July 2026 (UTC)
:What do you find as spam ? [[Special:Contributions/~2026-40412-29|~2026-40412-29]] ([[User talk:~2026-40412-29|talk]]) 12:20, 18 July 2026 (UTC)
== WinniJoy reported by MathXplore ==
* {{userlinks|WinniJoy}}
Spam <!-- USERREPORTED:/WinniJoy/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 10:48, 18 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|Codename Noreste]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 19:00, 19 July 2026 (UTC)
== ~2026-40144-05 reported by MathXplore ==
* {{userlinks|~2026-40144-05}}
Spam <!-- USERREPORTED:/~2026-40144-05/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 11:17, 19 July 2026 (UTC)
: I blocked them for creating out of scope pages. [[User:Codename Noreste|Codename Noreste]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 18:59, 19 July 2026 (UTC)
== Tkdesigner34 reported by MathXplore ==
* {{userlinks|Tkdesigner34}}
Spam <!-- USERREPORTED:/Tkdesigner34/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:08, 20 July 2026 (UTC)
:{{done}} ―[[User:Koavf|Justin (<span style="color:grey">ko'''a'''<span style="color:black">v</span>f</span>)]]<span style="color:red">❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯</span> 19:37, 20 July 2026 (UTC)
== Samanthajagan reported by MathXplore ==
* {{userlinks|Samanthajagan}}
Spam, [[Special:AbuseLog/314786]] <!-- USERREPORTED:/Samanthajagan/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:30, 21 July 2026 (UTC)
:{{done}} —[[User:Atcovi|Atcovi]] [[User talk:Atcovi|(Talk]] - [[Special:Contributions/Atcovi|Contribs)]] 12:47, 21 July 2026 (UTC)
== Upgradchennai0 reported by MathXplore ==
* {{userlinks|Upgradchennai0}}
Link spam, [[Special:AbuseLog/314865]], [[Special:CentralAuth/Upgradchennai0]] <!-- USERREPORTED:/Upgradchennai0/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 07:54, 26 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 13:02, 26 July 2026 (UTC)
== Elearningandearning reported by MathXplore ==
* {{userlinks|Elearningandearning}}
Spam <!-- USERREPORTED:/Elearningandearning/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:06, 29 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 14:49, 29 July 2026 (UTC)
== Starlium reported by MathXplore ==
* {{userlinks|Starlium}}
Long-term abuse. Cross-wiki abuse. [[Special:CentralAuth/Wahyu_Saputraa]], [[:w:id:Wikipedia:Investigasi pengguna siluman/Wahyu Saputraa]] <!-- USERREPORTED:/Starlium/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:17, 29 July 2026 (UTC)
: Globally locked by a steward. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 14:48, 29 July 2026 (UTC)
== Aranyaresidency reported by MathXplore ==
* {{userlinks|Aranyaresidency}}
Link spam, [[Special:AbuseLog/314920]] <!-- USERREPORTED:/Aranyaresidency/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:25, 31 July 2026 (UTC)
0bxhy3kh2mm1oqv7wvuxivjgcquvnr7
4655951
4655948
2026-07-31T16:33:09Z
Codename Noreste
3441010
/* Aranyaresidency reported by MathXplore */ reply: {{done}}. (-) ([[mw:c:Special:MyLanguage/User:JWBTH/CD|CD]])
4655951
wikitext
text/x-wiki
__NEWSECTIONLINK__ {{Discussion Rooms}} {{shortcut|WB:AN|WB:AA}} {{TOC left}}
{{User:MiszaBot/config
|archive = Wikibooks:Reading room/Administrative Assistance/Archives/%(year)d/%(monthname)s
|algo = old(14d)
|counter = 1
|minthreadstoarchive = 1
|minthreadsleft = 1
}}
{{ombox|type=content|text='''To request a rename or usurpation''', go to the global request page at Meta [[meta:SRUC|here]].<br />''Please do not post those requests here!''}}
{{Clear}}
Welcome to the '''Administrative Assistance reading room'''. You can request assistance from [[WB:ADMIN|administrators]] for handling a variety of problems here and alert them about problems which may require special actions not normally used during regular content editing. Please be patient as administrators are often quite busy with either their own projects or trying to perform general maintenance and cleanup.
You can deal with most vandalism yourself: [[Wikibooks:Dealing with vandalism|fix it]], then [[Wikibooks:Templates/User_notices|warn the user]]. If there is repeated vandalism by one user, lots of vandalism on a single page, or vandalism from many users, tell an admin here, or in [irc://irc.freenode.net/wikibooks #wikibooks] (say <code>!admin</code> to get attention).
For more general questions and assistance that doesn't require an administrator, please use the [[WB:HELP|Assistance Reading Room]].
{{clear}}
[[Category:Reading room]]
== Drpriyajaganathan reported by MathXplore ==
* {{userlinks|Drpriyajaganathan}}
Spam <!-- USERREPORTED:/Drpriyajaganathan/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 10:46, 18 July 2026 (UTC)
:What do you find as spam ? [[Special:Contributions/~2026-40412-29|~2026-40412-29]] ([[User talk:~2026-40412-29|talk]]) 12:20, 18 July 2026 (UTC)
== WinniJoy reported by MathXplore ==
* {{userlinks|WinniJoy}}
Spam <!-- USERREPORTED:/WinniJoy/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 10:48, 18 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|Codename Noreste]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 19:00, 19 July 2026 (UTC)
== ~2026-40144-05 reported by MathXplore ==
* {{userlinks|~2026-40144-05}}
Spam <!-- USERREPORTED:/~2026-40144-05/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 11:17, 19 July 2026 (UTC)
: I blocked them for creating out of scope pages. [[User:Codename Noreste|Codename Noreste]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 18:59, 19 July 2026 (UTC)
== Tkdesigner34 reported by MathXplore ==
* {{userlinks|Tkdesigner34}}
Spam <!-- USERREPORTED:/Tkdesigner34/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:08, 20 July 2026 (UTC)
:{{done}} ―[[User:Koavf|Justin (<span style="color:grey">ko'''a'''<span style="color:black">v</span>f</span>)]]<span style="color:red">❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯</span> 19:37, 20 July 2026 (UTC)
== Samanthajagan reported by MathXplore ==
* {{userlinks|Samanthajagan}}
Spam, [[Special:AbuseLog/314786]] <!-- USERREPORTED:/Samanthajagan/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:30, 21 July 2026 (UTC)
:{{done}} —[[User:Atcovi|Atcovi]] [[User talk:Atcovi|(Talk]] - [[Special:Contributions/Atcovi|Contribs)]] 12:47, 21 July 2026 (UTC)
== Upgradchennai0 reported by MathXplore ==
* {{userlinks|Upgradchennai0}}
Link spam, [[Special:AbuseLog/314865]], [[Special:CentralAuth/Upgradchennai0]] <!-- USERREPORTED:/Upgradchennai0/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 07:54, 26 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 13:02, 26 July 2026 (UTC)
== Elearningandearning reported by MathXplore ==
* {{userlinks|Elearningandearning}}
Spam <!-- USERREPORTED:/Elearningandearning/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:06, 29 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 14:49, 29 July 2026 (UTC)
== Starlium reported by MathXplore ==
* {{userlinks|Starlium}}
Long-term abuse. Cross-wiki abuse. [[Special:CentralAuth/Wahyu_Saputraa]], [[:w:id:Wikipedia:Investigasi pengguna siluman/Wahyu Saputraa]] <!-- USERREPORTED:/Starlium/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:17, 29 July 2026 (UTC)
: Globally locked by a steward. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 14:48, 29 July 2026 (UTC)
== Aranyaresidency reported by MathXplore ==
* {{userlinks|Aranyaresidency}}
Link spam, [[Special:AbuseLog/314920]] <!-- USERREPORTED:/Aranyaresidency/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:25, 31 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 16:33, 31 July 2026 (UTC)
hoeb9g5826emufbwev3hm6p1kb764fh
4655980
4655951
2026-08-01T07:33:44Z
MathXplore
3097823
Reporting Permata55
4655980
wikitext
text/x-wiki
__NEWSECTIONLINK__ {{Discussion Rooms}} {{shortcut|WB:AN|WB:AA}} {{TOC left}}
{{User:MiszaBot/config
|archive = Wikibooks:Reading room/Administrative Assistance/Archives/%(year)d/%(monthname)s
|algo = old(14d)
|counter = 1
|minthreadstoarchive = 1
|minthreadsleft = 1
}}
{{ombox|type=content|text='''To request a rename or usurpation''', go to the global request page at Meta [[meta:SRUC|here]].<br />''Please do not post those requests here!''}}
{{Clear}}
Welcome to the '''Administrative Assistance reading room'''. You can request assistance from [[WB:ADMIN|administrators]] for handling a variety of problems here and alert them about problems which may require special actions not normally used during regular content editing. Please be patient as administrators are often quite busy with either their own projects or trying to perform general maintenance and cleanup.
You can deal with most vandalism yourself: [[Wikibooks:Dealing with vandalism|fix it]], then [[Wikibooks:Templates/User_notices|warn the user]]. If there is repeated vandalism by one user, lots of vandalism on a single page, or vandalism from many users, tell an admin here, or in [irc://irc.freenode.net/wikibooks #wikibooks] (say <code>!admin</code> to get attention).
For more general questions and assistance that doesn't require an administrator, please use the [[WB:HELP|Assistance Reading Room]].
{{clear}}
[[Category:Reading room]]
== Drpriyajaganathan reported by MathXplore ==
* {{userlinks|Drpriyajaganathan}}
Spam <!-- USERREPORTED:/Drpriyajaganathan/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 10:46, 18 July 2026 (UTC)
:What do you find as spam ? [[Special:Contributions/~2026-40412-29|~2026-40412-29]] ([[User talk:~2026-40412-29|talk]]) 12:20, 18 July 2026 (UTC)
== WinniJoy reported by MathXplore ==
* {{userlinks|WinniJoy}}
Spam <!-- USERREPORTED:/WinniJoy/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 10:48, 18 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|Codename Noreste]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 19:00, 19 July 2026 (UTC)
== ~2026-40144-05 reported by MathXplore ==
* {{userlinks|~2026-40144-05}}
Spam <!-- USERREPORTED:/~2026-40144-05/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 11:17, 19 July 2026 (UTC)
: I blocked them for creating out of scope pages. [[User:Codename Noreste|Codename Noreste]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 18:59, 19 July 2026 (UTC)
== Tkdesigner34 reported by MathXplore ==
* {{userlinks|Tkdesigner34}}
Spam <!-- USERREPORTED:/Tkdesigner34/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:08, 20 July 2026 (UTC)
:{{done}} ―[[User:Koavf|Justin (<span style="color:grey">ko'''a'''<span style="color:black">v</span>f</span>)]]<span style="color:red">❤[[User talk:Koavf|T]]☮[[Special:Contributions/Koavf|C]]☺[[Special:Emailuser/Koavf|M]]☯</span> 19:37, 20 July 2026 (UTC)
== Samanthajagan reported by MathXplore ==
* {{userlinks|Samanthajagan}}
Spam, [[Special:AbuseLog/314786]] <!-- USERREPORTED:/Samanthajagan/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:30, 21 July 2026 (UTC)
:{{done}} —[[User:Atcovi|Atcovi]] [[User talk:Atcovi|(Talk]] - [[Special:Contributions/Atcovi|Contribs)]] 12:47, 21 July 2026 (UTC)
== Upgradchennai0 reported by MathXplore ==
* {{userlinks|Upgradchennai0}}
Link spam, [[Special:AbuseLog/314865]], [[Special:CentralAuth/Upgradchennai0]] <!-- USERREPORTED:/Upgradchennai0/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 07:54, 26 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 13:02, 26 July 2026 (UTC)
== Elearningandearning reported by MathXplore ==
* {{userlinks|Elearningandearning}}
Spam <!-- USERREPORTED:/Elearningandearning/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:06, 29 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 14:49, 29 July 2026 (UTC)
== Starlium reported by MathXplore ==
* {{userlinks|Starlium}}
Long-term abuse. Cross-wiki abuse. [[Special:CentralAuth/Wahyu_Saputraa]], [[:w:id:Wikipedia:Investigasi pengguna siluman/Wahyu Saputraa]] <!-- USERREPORTED:/Starlium/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:17, 29 July 2026 (UTC)
: Globally locked by a steward. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 14:48, 29 July 2026 (UTC)
== Aranyaresidency reported by MathXplore ==
* {{userlinks|Aranyaresidency}}
Link spam, [[Special:AbuseLog/314920]] <!-- USERREPORTED:/Aranyaresidency/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:25, 31 July 2026 (UTC)
: {{done}}. [[User:Codename Noreste|<span style="color: blue">Codename Noreste</span>]] ([[User talk:Codename Noreste|discuss]] • [[Special:Contributions/Codename Noreste|contribs]]) 16:33, 31 July 2026 (UTC)
== Permata55 reported by MathXplore ==
* {{userlinks|Permata55}}
Spam <!-- USERREPORTED:/Permata55/ --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 07:33, 1 August 2026 (UTC)
r64fb3ncm9114ddk0bb6hhg35ul9ytl
Vehicle Identification Numbers (VIN codes)/GM/VIN Codes
0
142013
4655958
4655943
2026-07-31T19:04:36Z
JustTheFacts33
3434282
/* Engine codes for light trucks */
4655958
wikitext
text/x-wiki
{{Vehicle Identification Numbers (VIN codes)/Warning}}{{clear}}
It is the tenth digit that gives you the model year for GM. I've been working at a Chevy dealer for years running codes/vins. For example (my examples only apply to 2001-2015 gm vehicles)
Remember 10th digit from the beginning, (left to right).
2001... 1,
2002...2,
2003...3,
etc.,
2009...9.
After 2009, the tenth digit was given a letter
2010... A,
2011...B,
2012...C,
2013...D,
2014...E,
2015...F,
Etc...
We have another 20 years worth of letters.
Thanks for reading.
You can always check your model year by looking in your drivers side door jamb and it will give you model year. If it was assembled in July or later, the model year is probably a year later than the calendar year of the manufacturing date listed.
==American GM==
===American VIN format 1981-1984 Passenger Car===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>A</td><td></td><td></td><td>[[#American restraint types 1981-1984|Restraint type]]</td>
</tr><tr>
<td>5</td>
<td>M</td><td></td><td></td><td>[[#Car Line & Series Code 1981-1984|Car Line & Series Code]]</td>
</tr><tr>
<td>6</td>
<td>4</td><td></td><td></td><td rowspan=2>[[#Body style codes 1981-1986|Body style]]</td>
</tr><tr>
<td>7</td>
<td>7</td><td></td><td></td><td> </td>
</tr><tr>
<td>8</td>
<td>8</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>E</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>9</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====American restraint types 1981-1984====
The restraint type is specified as character 4 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|A||Manual Seatbelts only - No Passive Restraint
|}
====Car Line & Series Code 1981-1984====
The Car Line & Series Code is specified as character 5 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!List of GM platforms
!Car Line & <br> Series Code
!:Category:General Motors vehicles|Model
|-
|rowspan=19|GM A platform - rear-wheel drive
|T||Chevrolet Malibu 1981
|-
|W||Chevrolet Malibu Classic 1981
|-
|Z||Chevrolet Monte Carlo 1981
|-
|D||Pontiac LeMans 1981
|-
|F||Pontiac Grand LeMans 1981
|-
|J||Pontiac Grand Prix 1981
|-
|K||Pontiac Grand Prix LJ 1981
|-
|P||Pontiac Grand Prix Brougham 1981
|-
|G||Oldsmobile Cutlass sedan, Cutlass Cruiser wagon 1981
|-
|H||Oldsmobile Cutlass Cruiser ''Brougham'' wagon 1981
|-
|K||Oldsmobile Cutlass Calais coupe 1981
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1981
|-
|R||Oldsmobile Cutlass Supreme coupe, Cutlass LS sedan 1981
|-
|E||Buick Century wagon 1981
|-
|H||Buick Century sedan, Estate wagon 1981
|-
|J||Buick Regal 1981
|-
|K||Buick Regal ''Sport'' 1981
|-
|L||Buick Century ''Limited'' 1981
|-
|M||Buick Regal ''Limited'' 1981
|-
|rowspan=10|GM A platform - front-wheel drive
|W||Chevrolet Celebrity 1982-1984
|-
|F||Pontiac 6000 1982-1984
|-
|G||Pontiac 6000 ''LE'' 1982-1984
|-
|H||Pontiac 6000 ''STE'' 1983-1984
|-
|G||Oldsmobile Cutlass Ciera 1982
|-
|J||Oldsmobile Cutlass Ciera ''LS'' 1982-1984, Cutlass Cruiser ''LS'' 1984
|-
|M||Oldsmobile Cutlass Ciera ''Brougham'' 1982-1984
|-
|G||Buick Century ''T-Type'' 1983-1984
|-
|H||Buick Century ''Custom'' 1982-1984
|-
|L||Buick Century ''Limited'' 1982-1984
|-
|rowspan=19|GM B platform
|D||Chevrolet Bel Air 1981 (Canada only)
|-
|L||Chevrolet Impala 1981-1984
|-
|N||Chevrolet Caprice Classic 1981-1984
|-
|F||Pontiac Laurentian 1981 (Canada only)
|-
|L||Pontiac Catalina 1981, Parisienne 1984
|-
|L||Pontiac Parisienne 1982-1983 (Canada only)
|-
|N||Pontiac Bonneville 1981
|-
|N||Pontiac Parisienne 1981, Parisienne Brougham 1982-1983 (Canada only)
|-
|R||Pontiac Bonneville Brougham 1981
|-
|T||Pontiac Parisienne Brougham 1984
|-
|L||Oldsmobile Delta 88 1981-1983
|-
|N||Oldsmobile Delta 88 Royale 1981-1984
|-
|P||Oldsmobile Custom Cruiser 1981-1984
|-
|V||Oldsmobile Delta 88 Royale Brougham LS 1984
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1981-1984
|-
|N||Buick Le Sabre 1981, Le Sabre ''Custom'' 1982-1984
|-
|P||Buick Le Sabre ''Limited'' 1981-1984
|-
|R||Buick Le Sabre Estate Wagon 1981-1983
|-
|V||Buick Electra Estate Wagon 1981-1984
|-
|rowspan=13|GM C platform - rear-wheel drive
|G||Oldsmobile 98 Regency 1984
|-
|H||Oldsmobile 98 Regency Brougham 1984
|-
|V||Oldsmobile 98 Luxury 1981
|-
|W||Oldsmobile 98 Regency Brougham 1982-1983
|-
|X||Oldsmobile 98 Regency 1981-1983
|-
|R||Buick Electra Limited 1984
|-
|U||Buick Electra Park Avenue 1984
|-
|W||Buick Electra Park Avenue 1981-1983
|-
|X||Buick Electra Limited 1981-1983
|-
|B||Cadillac Fleetwood Brougham 1981-1983
|-
|D||Cadillac DeVille 1981-1983
|-
|M||Cadillac DeVille 1984
|-
|W||Cadillac Fleetwood Brougham 1984
|-
|rowspan=1|GM D platform - rear-wheel drive
|F||Cadillac Fleetwood Limousine 1981-1984
|-
|rowspan=4|GM E platform
|Z||Oldsmobile Toronado Brougham 1981-1984
|-
|Y||Buick Riviera T-Type 1981-1984
|-
|Z||Buick Riviera 1981-1984
|-
|L||Cadillac Eldorado 1981-1984
|-
|rowspan=7|GM F platform
|P||Chevrolet Camaro Sport Coupe 1981-1984
|-
|S||Chevrolet Camaro Berlinetta 1981-1984
|-
|S||Pontiac Firebird 1981-1984
|-
|T||Pontiac Firebird ''Esprit'' 1981
|-
|V||Pontiac Firebird ''Formula'' 1981
|-
|W||Pontiac Firebird ''Trans Am'' 1981-1984
|-
|X||Pontiac Firebird ''Trans Am'' Turbo Special Edition 1981, Firebird ''S/E'' 1982-1984
|-
|rowspan=15|GM G platform - rear-wheel drive
|W||Chevrolet Malibu Classic 1982, Malibu 1983
|-
|Z||Chevrolet Monte Carlo 1982-1984
|-
|J||Pontiac Grand Prix 1982-1984
|-
|K||Pontiac Grand Prix LJ 1982-1983, Grand Prix LE 1984
|-
|N||Pontiac Bonneville G 1982-1984
|-
|P||Pontiac Grand Prix Brougham 1982-1984
|-
|R||Pontiac Bonneville G Brougham 1982-1984
|-
|S||Pontiac Bonneville G ''LE'' 1984
|-
|H||Oldsmobile Cutlass Cruiser wagon 1982-1983
|-
|K||Oldsmobile Cutlass Calais coupe 1982-1984
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1982-1984
|-
|R||Oldsmobile Cutlass Supreme coupe & sedan 1982-1984
|-
|J||Buick Regal 1982-1984
|-
|K||Buick Regal ''Sport'' 1982, Regal ''T-Type'' 1983-1984
|-
|M||Buick Regal ''Limited'' 1982-1984
|-
|rowspan=13|GM J platform
|C||Chevrolet Cavalier 1983-1984
|-
|D||Chevrolet Cavalier 2-d/4-d/wagon 1982, Cavalier CS 1983-1984
|-
|E||Chevrolet Cavalier 3-door hatchback 1982, Cavalier CS 3-door hatchback 1983, Cavalier Type 10 2-d/3-d/Convertible 1984
|-
|B||Pontiac J2000 1982, 2000 1983, 2000 Sunbird 1984
|-
|C||Pontiac J2000 LE 1982, 2000 LE 1983, 2000 Sunbird LE Convertible 1983, 2000 Sunbird LE 1984
|-
|D||Pontiac J2000 SE 1982, 2000 SE 1983, 2000 Sunbird SE 1984
|-
|E||Pontiac J2000 S 1982
|-
|C||Oldsmobile Firenza Base model 1982-1984, Firenza S 1982-1984
|-
|D||Oldsmobile Firenza LX 1982-1984, Firenza SX 1982-1984
|-
|E||Buick Skyhawk T-Type 1983-1984
|-
|S||Buick Skyhawk Custom 1982-1984
|-
|T||Buick Skyhawk Limited 1982-1984
|-
|G||Cadillac Cimarron 1982-1984
|-
|rowspan=1|GM K platform
|S||Cadillac Seville 1981-1984
|-
|rowspan=3|GM P platform
||E||Pontiac Fiero ''Coupe'' 1984
|-
||F||Pontiac Fiero ''SE'' 1984
|-
||M||Pontiac Fiero ''Sport coupe'' 1984
|-
|rowspan=6|GM T platform - rear-wheel drive
|B||Chevrolet Chevette 1981-1983, Chevette CS 1984
|-
|J||Chevrolet Chevette Scooter 1981-1983, Chevette 1984
|-
|B||Pontiac Acadian 1981-1984 (Canada only)
|-
|J||Pontiac Acadian S 1981-1982, Pontiac Acadian Scooter 1983-1984 (Canada only)
|-
|L||Pontiac T1000 1982, 1000 1983-1984
|-
|M||Pontiac T1000 1981
|-
|rowspan=10|GM X platform
|H||Chevrolet Citation 2-door coupe 1982-1983, Citation II 2-door coupe 1984
|-
|X||Chevrolet Citation hatchback 1981-1983, Citation II hatchback 1984
|-
|T||Pontiac Phoenix SJ 1982-1983, Phoenix SE 1984
|-
|Y||Pontiac Phoenix 1981-1984
|-
|Z||Pontiac Phoenix LJ 1981-1983, Phoenix LE 1984
|-
|B||Oldsmobile Omega 1981-1984
|-
|E||Oldsmobile Omega Brougham 1981-1984
|-
|B||Buick Skylark 1981-1982, Skylark Custom 1983-1984
|-
|C||Buick Skylark Limited 1981-1984
|-
|D||Buick Skylark Sport 1981-1982, Skylark T-Type 1983-1984
|-
|rowspan=1|GM Y platform
|Y||Chevrolet Corvette 1981-1982, 1984
|}
===American VIN format 1985-1986 Passenger Car===
GM has traditionally encoded the platform as the 4th character of the VIN. Other content includes an engine code and manufacturing plant. GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>D</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Platform]]</td>
</tr><tr>
<td>5</td>
<td>W</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Series Code]]</td>
</tr><tr>
<td>6</td>
<td>6</td><td></td><td></td><td rowspan=2>[[#Body style codes 1981-1986|Body style]]</td>
</tr><tr>
<td>7</td>
<td>9</td><td></td><td></td><td> </td>
</tr><tr>
<td>8</td>
<td>Y</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>G</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>9</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====Body style codes 1981-1986====
The Body type is specified as characters 6 and 7 of the American GM VIN for passenger cars from 1981-1986.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|11,27,37,47,57,97||Two-Door Coupe/Sedan
|-
|07,08,77,87||Two-Door Hatchback
|-
|67||Two-Door Convertible
|-
|19,69||Four-Door Sedan
|-
|68||Four-Door Hatchback
|-
|23||Four-Door Limousine, 8-passenger ("Limousine")
|-
|33||Four-Door Limousine w/Center Partition, 7-passenger ("Formal Limousine")
|-
|35||Four-Door Station Wagon
|}
===American VIN format 1987- Passenger Car===
GM has traditionally encoded the platform as the 4th character of the VIN. Other content includes an engine code and manufacturing plant. GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>D</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Platform]]</td>
</tr><tr>
<td>5</td>
<td>M</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Series Code]]</td>
</tr><tr>
<td>6</td>
<td>5</td><td></td><td></td><td>[[#Body style codes 1987- Passenger Car|Body style]]</td>
</tr><tr>
<td>7</td>
<td>7</td><td></td><td></td><td>[[#American restraint types 1987-|Restraint type]]</td>
</tr><tr>
<td>8</td>
<td>N</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>3</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>0</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
===American VIN format 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>K</td><td></td><td></td></tr><tr>
<td>4</td>
<td>E</td><td></td><td></td><td>[[#GVWR/Brake System 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|GVWR/Brake System]]</td>
</tr><tr>
<td>5</td>
<td>K</td><td></td><td></td><td>[[#Line & Chassis Type 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 1981-1999]]</td>
</tr><tr>
<td>5</td>
<td>K</td><td></td><td></td><td>[[#Line & Chassis Type 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 2000-2009]]</td>
</tr><tr>
<td>6</td>
<td>1</td><td></td><td></td><td>[[#Series 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle|Series]]</td>
</tr><tr>
<td>7</td>
<td>8</td><td></td><td></td><td>[[#Body style codes 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|Body type]]</td>
</tr><tr>
<td>8</td>
<td>K</td><td></td><td></td><td>[[#Engine codes for light trucks|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>N</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>J</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====GVWR/Brake System 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The GVWR/Brake System is specified as character 4 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!GVWR Range in lbs. & Weight Class
!Brake System
|-
|A||Class A: 0-3,000||Hydraulic
|-
|B||Class B: 3,001-4,000||Hydraulic
|-
|C||Class C: 4,001-5,000||Hydraulic
|-
|D||Class D: 5,001-6,000||Hydraulic
|-
|E||Class E: 6,001-7,000||Hydraulic
|-
|F||Class F: 7,001-8,000||Hydraulic
|-
|G||Class G: 8,001-9,000||Hydraulic
|-
|H||Class H: 9,001-10,000||Hydraulic
|-
|J||Class 3: 10,001-14,000||Hydraulic
|-
|K||Class 4: 14,001-16,000||Hydraulic
|-
|L||Class 5: 16,001-19,500||Hydraulic
|}
====Line & Chassis Type 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|B||Special Body Buick, Chevrolet
|-
|C||Chevy full-size pickups & chassis cabs 2wd (C-series) '81-'86, '88-'99,<br /> GMC full-size pickups & chassis cabs 2wd (C-series) '81-'86, Sierra 2wd (C-series) '88-'99
|-
|C||Chevy C10 Blazer 2wd ('81-'82), Tahoe 4-door 2wd ('95-'99), Suburban 2wd ('81-'86, '92-'99),<br /> GMC C1500 Jimmy 2wd ('81-'82), Yukon 4-door 2wd ('95-'99), Suburban 2wd ('81-'86, '92-'99)
|-
|D||Military Truck 4wd
|-
|E||'91-'97 Geo Tracker 2wd, '98-'99 Chevrolet Tracker 2wd
|-
|E||'97-'98 Chevy S-10 EV
|-
|G||Chevy/GMC full-size vans (Chevy Van, Sportvan, Express, GMC Vandura, Rally Van, Savana)
|-
|H||'93-'96 Chevy G30HD/GMC G3500HD cutaway van
|-
|H||Cadillac chassis cutaway/special body (Based on Rwd Fleetwood '93-'96, Fwd DeVille '97-'99)
|-
|J||'89-'97 Geo Tracker 4wd, '98-'99 Chevrolet Tracker 4wd
|-
|K||Chevy full-size pickups & chassis cabs 4wd (K-series) '81-'86, '88-'99,<br /> GMC full-size pickups & chassis cabs 4wd (K-series) '81-'86, Sierra 4wd (K-series) '88-'99
|-
|K||Chevy K10/K5 Blazer 4wd ('81-'86, '92-'94), Tahoe 4wd ('95-'99), Suburban 4wd ('81-'86, '92-'99),<br /> GMC K1500 Jimmy 4wd ('81-'86), Yukon 4wd ('92-'99), Suburban 4wd ('81-'86, '92-'99), '99 Cadillac Escalade 4wd
|-
|L||Chevy Luv 2wd '81-'82
|-
|L||Chevy Astro/GMC Safari 4wd '90-'99
|-
|M||Chevy Astro/GMC Safari 2wd '85-'99
|-
|P||Forward Control (includes Chevrolet Step-Van/GMC Value-Van, Chevy/GMC P-Series)
|-
|R||Chevy Luv 4wd '81-'82
|-
|R||Chevy full-size pickups & chassis cabs 2wd (R-series), Suburban 2wd '87-'91,<br /> GMC full-size pickups & chassis cabs 2wd (R-series), Suburban 2wd '87-'91
|-
|S||Chevy S-10 2wd ('82-'99), S-10 Blazer 2wd ('83-'94), Blazer 2wd ('95-'99), GMC S-15 2wd ('82-'90), Sonoma 2wd ('91-'99),<br> S-15 Jimmy 2wd ('83-'91), Jimmy 2wd ('92-'99), Isuzu Hombre 2wd ('96-'99)
|-
|T||Chevy S-10 4wd ('83-'99), S-10 Blazer 4wd ('83-'94), Blazer 4wd ('95-'99), GMC S-15 4wd ('83-'90), Sonoma 4wd ('91-'99), Syclone 4wd ('91),<br> S-15 Jimmy 4wd ('83-'91), Jimmy 4wd ('92-'99), Typhoon 4wd ('92-93), Envoy 4wd ('98-'99), Oldsmobile Bravada 4wd ('91-'94, '96-'99),<br> Isuzu Hombre 4wd ('98-'99)
|-
|U||Regular length All-Purpose Vehicle ('90-'99 U-body fwd minivans)
|-
|V||Chevy full-size pickups & chassis cabs 4wd (V-series), V10/V1500 Blazer 4wd, Suburban 4wd '87-'91,<br /> GMC full-size pickups & chassis cabs 4wd (V-series), V1500 Jimmy 4wd, Suburban 4wd '87-'91
|-
|W||'81-'87 Chevy El Camino, GMC Caballero
|-
|X||Extended length All-Purpose Vehicle ('97-'99 U-body fwd extended length minivans)
|-
|Z||Cadillac chassis cutaway/special body (Based on Rwd Fleetwood '81-'84, Fwd Fleetwood '85-'92)
|}
====Line & Chassis Type 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Pontiac Aztek 2wd '01-'05, Buick Rendezvous 2wd '02-'07
|-
|A||Chevrolet HHR '06-'09, HHR Panel '07-'09
|-
|B||Pontiac Aztek Awd '01-'05, Buick Rendezvous Awd '02-'06
|-
|C||Chevy full-size pickups & chassis cabs 2wd (C-series) '00, full-size chassis cabs 2wd (C3500HD) '01-'02, Silverado 2wd '00-'09, Silverado Classic 2wd '07,<br /> GMC Sierra 2wd (C-series) '00-'09, Sierra Classic 2wd '00, '07
|-
|C||Chevy Tahoe 2wd ('00-'09), Suburban 2wd ('00-'09), Avalanche 2wd ('02-'09),<br /> GMC Yukon 2wd ('00-'09), Yukon XL 2wd ('00-'09), Cadillac Escalade 2wd ('02-'09), Escalade ESV 2wd ('08-'09)
|-
|E||Chevrolet Tracker 2wd '00-'04
|-
|E||Cadillac SRX 2wd & Awd '04-'09
|-
|G||Chevy/GMC full-size vans 2wd (Chevy Express, GMC Savana) '00-09
|-
|H||Chevy/GMC full-size vans 4wd (Chevy Express, GMC Savana) '03-09
|-
|H||Cadillac Commercial Chassis for Hearse (Based on Fwd DeVille '02-'05, DTS '06-'09)
|-
|H||Cadillac Professional Chassis for Limousine (Based on Fwd DeVille '00-'05, DTS '06-'07)
|-
|J||Chevrolet Tracker 4wd '00-'04
|-
|K||Chevy full-size pickups & chassis cabs 4wd (K-series) '00, Silverado 4wd '00-'09, Silverado Classic 4wd '07,<br /> GMC Sierra 4wd (K-series) '00-'09, Sierra Classic 4wd '00, '07
|-
|K||Chevy Tahoe 4wd ('00-'09), Suburban 4wd ('00-'09), Avalanche 4wd ('02-'09), GMC Yukon 4wd ('00-'09), Yukon XL 4wd ('00-'09),<br> Cadillac Escalade 4wd ('00, '02-'09), Escalade ESV 4wd ('03-'09), Escalade EXT 4wd ('02-'09)
|-
|K||Cadillac Professional Chassis for Limousine (Based on Fwd DTS '08-'09)
|-
|L||Chevy Astro/GMC Safari 4wd '00-'05
|-
|L||Chevy Equinox 2wd & Awd '05-'09, Pontiac Torrent 2wd & Awd '06-'09, Saturn Vue 2wd & Awd '08-'09
|-
|M||Chevy Astro/GMC Safari 2wd '00-'05
|-
|N||Hummer H2 '03-'09, H2 SUT '05-'09
|-
|N||Hummer H3 '06-'09, H3T '09
|-
|R||GMC Acadia 2wd, Saturn Outlook 2wd '07-'09, Buick Enclave 2wd '08-'09, Chevy Traverse 2wd '09
|-
|S||Chevy S-10 2wd ('00-'03), Blazer 2wd ('00-'05), GMC Sonoma 2wd ('00-'03), Jimmy 2wd ('00-'01), Isuzu Hombre 2wd ('00)
|-
|S||Chevy Trailblazer 2wd ('02-'09), SSR ('03-'06), GMC Envoy 2wd ('02-'09), Envoy XUV 2wd ('04-'05), Oldsmobile Bravada 2wd ('02-'04),<br> Buick Rainier 2wd ('04-'07), Isuzu Ascender 2wd ('03-'08)
|-
|S||Chevy Colorado 2wd ('04-'09), GMC Canyon 2wd ('04-'09), Isuzu i-series 2wd ('06-'08)
|-
|T||Chevy S-10 4wd ('00-'04), Blazer 4wd ('00-'05), GMC Sonoma 4wd ('00-'04), Jimmy 4wd ('00-'01, Canada only: '02-'05), Envoy 4wd ('00),<br> Oldsmobile Bravada 4wd ('00-'01), Isuzu Hombre 4wd ('00)
|-
|T||Chevy Trailblazer 4wd ('02-'09), GMC Envoy 4wd ('02-'09), Envoy XUV 2wd ('04-'05), Oldsmobile Bravada 4wd ('02-'04), Buick Rainier 4wd ('04-'07),<br> Isuzu Ascender 4wd ('03-'08), Saab 9-7X 4wd ('05-'09)
|-
|T||Chevy Colorado 4wd ('04-'09), GMC Canyon 4wd ('04-'09), Isuzu i-series 4wd ('06-'08)
|-
|U||Regular length All-Purpose Vehicle [Minivan] ('00-'04 Chevy Venture, Pontiac Montana)
|-
|U||Regular length All-Purpose Vehicle [Minivan] (Chevy Uplander [US: '06-'08, Canada only: '05-'09], Pontiac Montana SV6 [Canada only: '05-'09])
|-
|V||Extended length AWD All-Purpose Vehicle [Minivan] ('02-'04 Chevy Venture, Pontiac Montana, Oldsmobile Silhouette Extended length AWD)
|-
|V||Extended length FWD All-Purpose Vehicle [Minivan] ('05 Chevy Venture, Pontiac Montana Extended length FWD)
|-
|V||Extended length FWD All-Purpose Vehicle [Minivan] (Chevy Uplander ['05-'08, Canada only: '09], Pontiac Montana SV6 ['05-'06, Canada only: '07-'09],<br> Buick Terraza ['05-'07], Saturn Relay ['05-'07])
|-
|V||GMC Acadia Awd, Saturn Outlook Awd '07-'09, Buick Enclave Awd '08-'09, Chevy Traverse Awd '09
|-
|X||Extended length FWD All-Purpose Vehicle [Minivan] ('00-'04 Chevy Venture, Pontiac Montana, Oldsmobile Silhouette Extended length FWD)
|-
|X||Extended length AWD All-Purpose Vehicle [Minivan] ('05-'06 Chevy Uplander AWD, Pontiac Montana SV6 AWD, Buick Terraza AWD, Saturn Relay AWD)
|-
|Z||Saturn Vue 2wd & Awd '02-'07
|}
====Series 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1||1/2 Ton (includes '96-'99 Isuzu Hombre)
|-
|2||3/4 Ton
|-
|3||1 Ton
|-
|8||1/2 Ton ('81-'87 El Camino, Caballero)
|-
|9||Cadillac, Buick, Chevrolet Commercial Body/Chassis
|-
|0||All-Purpose Vehicle ('90-'99 U-body fwd minivans)
|}
====Series 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1 <br> (following A)||Chevrolet HHR LS ('06-'07)
|-
|2 <br> (following A)||Chevrolet HHR LT ('06-'07)
|-
|3 <br> (following A)||Chevrolet HHR LT ('07)
|-
|1 <br> (following A)||Chevrolet HHR LS w/auto. trans. ('08-'09)
|-
|2 <br> (following A)||Chevrolet HHR 1LT w/auto. trans. ('08-'09)
|-
|3 <br> (following A)||Chevrolet HHR LS w/man. trans. ('08-'09)
|-
|4 <br> (following A)||Chevrolet HHR 1LT w/man. trans. ('08-'09)
|-
|5 <br> (following A)||Chevrolet HHR 2LT (all transmissions) ('08-'09)
|-
|6 <br> (following A)||Chevrolet HHR SS w/auto. trans. ('08-'09) (Pos. 1-3 of VIN is 3GN)
|-
|7 <br> (following A)||Chevrolet HHR SS w/man. trans. ('08-'09) (Pos. 1-3 of VIN is 3GN)
|-
|6 <br> (following A)||Chevrolet HHR Panel SS w/auto. trans. ('09) (Pos. 1-3 of VIN is 3GC)
|-
|7 <br> (following A)||Chevrolet HHR Panel SS w/man. trans. ('09) (Pos. 1-3 of VIN is 3GC)
|-
|8 <br> (following A)||Chevrolet HHR Panel LS w/auto. trans. ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|9 <br> (following A)||Chevrolet HHR Panel LS w/man. trans. ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|0 <br> (following A)||Chevrolet HHR Panel LT (all transmissions) ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|1 <br> (following A)||Chevrolet HHR Panel LS ('08) (Pos. 1-3 of VIN is 3GC)
|-
|2 <br> (following A)||Chevrolet HHR Panel LT ('08) (Pos. 1-3 of VIN is 3GC)
|-
|3 <br> (following A)||Chevrolet HHR Panel LT ('08) (Pos. 1-3 of VIN is 3GC)
|-
|0 <br> (following V)||Chevrolet Venture Plus ('05) (Pos. 8 of VIN is E)
|-
|1 <br> (following V)||Chevrolet Venture Cargo ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following V)||Chevrolet Venture LS ('05) (Pos. 8 of VIN is E)
|-
|3 <br> (following V)||Chevrolet Venture LT ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following U)||Chevrolet Uplander LS SWB 2wd ('06-'08)
|-
|0 <br> (following V)||Chevrolet Uplander Base model 2wd ('05)
|-
|1 <br> (following V)||Chevrolet Uplander Cargo Van 2wd, Mobility (incomplete vehicle) 2wd ('05-'08)
|-
|2 <br> (following V)||Chevrolet Uplander LS 2wd ('05-'08)
|-
|3 <br> (following V)||Chevrolet Uplander LT 2wd ('05-'08)
|-
|3 <br> (following X)||Chevrolet Uplander LT Awd ('05-'06)
|-
|1 <br> (following M)||Chevrolet Astro 2wd ('00-'05)
|-
|1 <br> (following L)||Chevrolet Astro Awd ('00-'05)
|-
|1 <br> (following G)||Chevrolet Express 1500 series 2wd ('00-'09)
|-
|2 <br> (following G)||Chevrolet Express 2500 series 2wd ('00-'09)
|-
|3 <br> (following G)||Chevrolet Express 3500 series 2wd ('00-'09)
|-
|3 <br> (following G)||When VIN starts with 1GBK: Chevrolet Express 4500 series Cutaway 2wd ('09)
|-
|6 <br> (following G)||Chevrolet Express 1500 series LT 2wd ('01-'02)
|-
|1 <br> (following H)||Chevrolet Express 1500 series Awd ('03-'09)
|-
|2 <br> (following H)||Chevrolet Express 2500 series Awd ('03-'05)
|-
|1 <br> (following E)||Chevrolet Tracker Base model 2wd ('00-'04)
|-
|6 <br> (following E)||Chevrolet Tracker LT 2wd ('01-'04)
|-
|1 <br> (following J)||Chevrolet Tracker Base model 4wd ('00-'01, '04)
|-
|1 <br> (following J)||Chevrolet Tracker Base model w/1SB (Preferred) Equip. Group 4wd ('02-'03)
|-
|2 <br> (following J)||Chevrolet Tracker Base model w/1SA (Base) Equip. Group 4wd ('02-'03)
|-
|6 <br> (following J)||Chevrolet Tracker LT 4wd ('01-'04)
|-
|7 <br> (following J)||Chevrolet Tracker ZR2 4wd ('01-'04)
|-
|1 <br> (following L)||Chevrolet Equinox LS 2wd ('05-'09)
|-
|2 <br> (following L)||Chevrolet Equinox LS Awd ('05-'09)
|-
|6 <br> (following L)||Chevrolet Equinox LT 2wd ('05-'07)
|-
|7 <br> (following L)||Chevrolet Equinox LT Awd ('05-'07)
|-
|3 <br> (following L)||Chevrolet Equinox 1LT 2wd ('08-'09)
|-
|4 <br> (following L)||Chevrolet Equinox 1LT Awd ('08-'09)
|-
|5 <br> (following L)||Chevrolet Equinox 2LT 2wd ('08-'09)
|-
|6 <br> (following L)||Chevrolet Equinox 2LT Awd ('08-'09)
|-
|7 <br> (following L)||Chevrolet Equinox LTZ 2wd ('08-'09)
|-
|8 <br> (following L)||Chevrolet Equinox LTZ Awd ('08-'09)
|-
|9 <br> (following L)||Chevrolet Equinox Sport 2wd ('08-'09)
|-
|0 <br> (following L)||Chevrolet Equinox Sport Awd ('08-'09)
|-
|1 <br> (following R)||Chevrolet Traverse LS 2wd ('09)
|-
|2 <br> (following R)||Chevrolet Traverse LT 2wd ('09)
|-
|3 <br> (following R)||Chevrolet Traverse LTZ 2wd ('09)
|-
|1 <br> (following V)||Chevrolet Traverse LS Awd ('09)
|-
|2 <br> (following V)||Chevrolet Traverse LT Awd ('09)
|-
|3 <br> (following V)||Chevrolet Traverse LTZ Awd ('09)
|-
|1 <br> (following S)||Chevrolet Blazer 2wd ('00-'05)
|-
|1 <br> (following T)||Chevrolet Blazer 4wd ('00-'05)
|-
|1 <br> (following S)||Chevrolet Trailblazer 2wd ('02-'08), Trailblazer EXT 2wd ('02-'06)
|-
|1 <br> (following T)||Chevrolet Trailblazer 4wd ('02-'08), Trailblazer EXT 4wd ('02-'06)
|-
|3 <br> (following S)||Chevrolet Trailblazer LT 2wd ('09)
|-
|3 <br> (following T)||Chevrolet Trailblazer LT 4wd ('09)
|-
|5 <br> (following S)||Chevrolet Trailblazer SS 2wd ('09)
|-
|5 <br> (following T)||Chevrolet Trailblazer SS 4wd ('09)
|-
|1 <br> (following C)||Chevrolet Tahoe Limited 2wd ('00) [GMT400; 8th pos. of VIN is R]
|-
|1 <br> (following K)||Chevrolet Tahoe Z71 4wd ('00) [GMT400; 8th pos. of VIN is R]
|-
|1 <br> (following C)||Chevrolet Tahoe 2wd ('00-'06) [GMT800]
|-
|1 <br> (following K)||Chevrolet Tahoe 4wd ('00-'06) [GMT800]
|-
|1 <br> (following C)||Chevrolet Tahoe 2wd ('07-'08) [GMT900]
|-
|0 <br> (following C)||Chevrolet Tahoe Police/Special Service 2wd ('07-'09) [GMT900]
|-
|1 <br> (following C)||Chevrolet Tahoe LS 2wd ('09) [GMT900]
|-
|2 <br> (following C)||Chevrolet Tahoe LT 2wd ('09) [GMT900]
|-
|3 <br> (following C)||Chevrolet Tahoe LTZ 2wd ('09) [GMT900]
|-
|1 <br> (following K)||Chevrolet Tahoe 4wd ('07-'08) [GMT900]
|-
|0 <br> (following K)||Chevrolet Tahoe Police/Special Service 4wd ('07-'09) [GMT900]
|-
|1 <br> (following K)||Chevrolet Tahoe LS 4wd ('09) [GMT900]
|-
|2 <br> (following K)||Chevrolet Tahoe LT 4wd ('09) [GMT900]
|-
|3 <br> (following K)||Chevrolet Tahoe LTZ 4wd ('09) [GMT900]
|-
|1 <br> (following C)||Chevrolet Suburban 1500 series 2wd ('00-'08)
|-
|2 <br> (following C)||Chevrolet Suburban 2500 series 2wd ('00-'08)
|-
|1 <br> (following K)||Chevrolet Suburban 1500 series 4wd ('00-'08)
|-
|2 <br> (following K)||Chevrolet Suburban 2500 series 4wd ('00-'08)
|-
|1 <br> (following C)||Chevrolet Suburban 1500 series LS 2wd ('09)
|-
|2 <br> (following C)||Chevrolet Suburban 1500 series LT 2wd ('09)
|-
|3 <br> (following C)||Chevrolet Suburban 1500 series LTZ 2wd ('09)
|-
|4 <br> (following C)||Chevrolet Suburban 2500 series LS 2wd ('09)
|-
|5 <br> (following C)||Chevrolet Suburban 2500 series LT 2wd ('09)
|-
|1 <br> (following K)||Chevrolet Suburban 1500 series LS 4wd ('09)
|-
|2 <br> (following K)||Chevrolet Suburban 1500 series LT 4wd ('09)
|-
|3 <br> (following K)||Chevrolet Suburban 1500 series LTZ 4wd ('09)
|-
|4 <br> (following K)||Chevrolet Suburban 2500 series LS 4wd ('09)
|-
|5 <br> (following K)||Chevrolet Suburban 2500 series LT 4wd ('09)
|-
|1 <br> (following C)||Chevrolet Avalanche 1500 series 2wd ('02-'08)
|-
|2 <br> (following C)||Chevrolet Avalanche 2500 series 2wd ('02-'03)
|-
|1 <br> (following K)||Chevrolet Avalanche 1500 series 4wd ('02-'08)
|-
|2 <br> (following K)||Chevrolet Avalanche 2500 series 4wd ('02-'06)
|-
|1 <br> (following C)||Chevrolet Avalanche 1500 series LS 2wd ('09)
|-
|2 <br> (following C)||Chevrolet Avalanche 1500 series LT 2wd ('09)
|-
|3 <br> (following C)||Chevrolet Avalanche 1500 series LTZ 2wd ('09)
|-
|1 <br> (following K)||Chevrolet Avalanche 1500 series LS 4wd ('09)
|-
|2 <br> (following K)||Chevrolet Avalanche 1500 series LT 4wd ('09)
|-
|3 <br> (following K)||Chevrolet Avalanche 1500 series LTZ 4wd ('09)
|-
|1 <br> (following S)||Chevrolet SSR 2wd ('03-'06)
|-
|6 <br> (following S)||Chevrolet SSR Signature Series 2wd ('03) <br> [All SSR Signature Series also have a 0 in the 12th pos. of VIN whereas all other SSRs have a 1 in the 12th pos. of VIN]
|-
|1 <br> (following S)||Chevrolet S-10 2wd ('00-'03)
|-
|1 <br> (following T)||Chevrolet S-10 4wd ('00-'04)
|-
|1 <br> (following S)||Chevrolet Colorado 2wd ('04-'07)
|-
|1 <br> (following T)||Chevrolet Colorado 4wd ('04-'07)
|-
|1 <br> (following V)||Pontiac Montana Mobility (incomplete vehicle) 2wd ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following V)||Pontiac Montana ('05) (Pos. 8 of VIN is E)
|-
|0 <br> (following V)||Pontiac Montana SV6 1SA 2wd ('05)
|-
|3 <br> (following V)||Pontiac Montana SV6 1SB 2wd ('05)
|-
|2 <br> (following X)||Pontiac Montana SV6 1SA Awd ('05)
|-
|3 <br> (following X)||Pontiac Montana SV6 1SB Awd ('05)
|-
|1 <br> (following V)||Pontiac Montana SV6 Mobility (incomplete vehicle) 2wd ('06)
|-
|3 <br> (following V)||Pontiac Montana SV6 2wd ('06)
|-
|3 <br> (following X)||Pontiac Montana SV6 Awd ('06)
|-
|0 <br> (following A)||Pontiac Aztek 2wd ('01-'05)
|-
|0 <br> (following B)||Pontiac Aztek Awd ('01-'05)
|-
|6 <br> (following L)||Pontiac Torrent 2wd ('06-'07)
|-
|7 <br> (following L)||Pontiac Torrent Awd ('06-'07)
|-
|3 <br> (following L)||Pontiac Torrent Base model 2wd ('08-'09)
|-
|4 <br> (following L)||Pontiac Torrent Base model Awd ('08-'09)
|-
|5 <br> (following L)||Pontiac Torrent GXP 2wd ('08-'09)
|-
|6 <br> (following L)||Pontiac Torrent GXP Awd ('08-'09)
|-
|0 <br> (following X)||Oldsmobile Silhouette extended length GL 2wd ('00, '03-'04), GLS 2wd ('00-'04)
|-
|1 <br> (following X)||Oldsmobile Silhouette extended length Premiere 2wd ('00-'04)
|-
|2 <br> (following X)||Oldsmobile Silhouette extended length GL 2wd ('01-'02)
|-
|0 <br> (following V)||Oldsmobile Silhouette extended length GLS Awd ('02-'04)
|-
|1 <br> (following V)||Oldsmobile Silhouette extended length Premiere Awd ('02-'04)
|-
|1 <br> (following S)||Oldsmobile Bravada 2wd ('02-'04)
|-
|1 <br> (following T)||Oldsmobile Bravada 4wd ('00-'04)
|-
|1 <br> (following V)||Buick Terraza Mobility (incomplete vehicle) 2wd ('05-'07)
|-
|2 <br> (following V)||Buick Terraza CX 2wd ('05-'07), CX Plus 2wd ('07)
|-
|3 <br> (following V)||Buick Terraza CXL 2wd ('05-'07)
|-
|2 <br> (following X)||Buick Terraza CX Awd ('05-'06)
|-
|3 <br> (following X)||Buick Terraza CXL Awd ('05-'06)
|-
|0 <br> (following A)||Buick Rendezvous 2wd ('02-'07)
|-
|0 <br> (following B)||Buick Rendezvous Awd ('02-'06)
|-
|1 <br> (following S)||Buick Rainier 2wd ('04-'07)
|-
|1 <br> (following T)||Buick Rainier 4wd ('04-'06)
|-
|1 <br> (following R)||Buick Enclave CX 2wd ('08-'09)
|-
|2 <br> (following R)||Buick Enclave CXL 2wd ('08-'09)
|-
|1 <br> (following V)||Buick Enclave CX Awd ('08-'09)
|-
|2 <br> (following V)||Buick Enclave CXL Awd ('08-'09)
|-
|6 <br> (following E)||Cadillac SRX ('04-'07)
|-
|2 <br> (following E)||Cadillac SRX RWD V8 ('08-'09)
|-
|4 <br> (following E)||Cadillac SRX AWD V6 ('08-'09)
|-
|5 <br> (following E)||Cadillac SRX AWD V8 ('08-'09)
|-
|6 <br> (following E)||When Pos. 8 of VIN is 7: Cadillac SRX RWD V6 ('08)
|-
|6 <br> (following E)||When Pos. 8 of VIN is A: Cadillac SRX AWD V8 ('08)
|-
|6 <br> (following E)||Cadillac SRX RWD V6 ('09)
|-
|1 <br> (following K)||Cadillac Escalade 4wd (Early '00)
|-
|4 <br> (following K)||Cadillac Escalade Platinum Edition 4wd ('08), Escalade ESV Platinum Edition 4wd ('08)
|-
|6 <br> (following C)||Cadillac Escalade 2wd ('02-'08), Escalade ESV 2wd ('08)
|-
|6 <br> (following K)||Cadillac Escalade 4wd (Mid '00, '02-'08), Escalade ESV 4wd ('03-'08), Escalade EXT 4wd ('02-'08)
|-
|1 <br> (following C)||Cadillac Escalade 2wd Base model ('09), Escalade ESV 2wd Base model ('09)
|-
|2 <br> (following C)||Cadillac Escalade 2wd w/Ultra Luxury Collection ('09), Escalade ESV 2wd w/Ultra Luxury Collection ('09)
|-
|3 <br> (following C)||Cadillac Escalade 2wd w/Platinum Edition ('09), Escalade ESV 2wd w/Platinum Edition ('09)
|-
|4 <br> (following C)||Cadillac Escalade Hybrid 2wd Base model ('09)
|-
|5 <br> (following C)||Cadillac Escalade 2wd w/Sport Package ('09), Escalade ESV 4wd w/Sport Package ('09)
|-
|1 <br> (following K)||Cadillac Escalade 4wd Base model ('09), Escalade ESV 4wd Base model ('09), Escalade EXT 4wd Base model ('09)
|-
|2 <br> (following K)||Cadillac Escalade 4wd w/Ultra Luxury Collection ('09), Escalade ESV 4wd w/Ultra Luxury Collection ('09),<br> Escalade EXT 4wd w/Ultra Luxury Collection ('09)
|-
|3 <br> (following K)||Cadillac Escalade 4wd w/Platinum Edition ('09), Escalade ESV 4wd w/Platinum Edition ('09)
|-
|4 <br> (following K)||Cadillac Escalade Hybrid 4wd Base model ('09)
|-
|5 <br> (following K)||Cadillac Escalade 4wd w/Sport Package ('09), Escalade ESV 4wd w/Sport Package ('09), Escalade EXT 4wd w/Sport Package ('09)
|-
|1 <br> (following M)||GMC Safari 2wd ('00-'05)
|-
|1 <br> (following L)||GMC Safari Awd ('00-'05)
|-
|1 <br> (following G)||GMC Savana 1500 series 2wd ('00-'09)
|-
|2 <br> (following G)||GMC Savana 2500 series 2wd ('00-'09)
|-
|3 <br> (following G)||GMC Savana 3500 series 2wd ('00-'09)
|-
|3 <br> (following G)||When VIN starts with 1GBK: GMC Savana 4500 series Cutaway 2wd ('09)
|-
|6 <br> (following G)||GMC Savana 1500 series SLT 2wd ('01-'02)
|-
|1 <br> (following H)||GMC Savana 1500 series Awd ('03-'09)
|-
|2 <br> (following H)||GMC Savana 2500 series Awd ('03-'05)
|-
|1 <br> (following R)||GMC Acadia SLE 2wd ('07-'09)
|-
|2 <br> (following R)||GMC Acadia SLT-1 2wd ('07-'09)
|-
|3 <br> (following R)||GMC Acadia SLT-2 2wd ('07-'09)
|-
|1 <br> (following V)||GMC Acadia SLE Awd ('07-'09)
|-
|2 <br> (following V)||GMC Acadia SLT-1 Awd ('07-'09)
|-
|3 <br> (following V)||GMC Acadia SLT-2 Awd ('07-'09)
|-
|1 <br> (following S)||GMC Jimmy 2wd ('00-'01)
|-
|6 <br> (following S)||GMC Jimmy Diamond Edition 2wd ('01)
|-
|1 <br> (following T)||GMC Jimmy 4wd ('00-'01 & '02-'05 in Canada)
|-
|6 <br> (following T)||GMC Jimmy Diamond Edition 4wd ('01)
|-
|1 <br> (following S)||GMC Envoy 2wd ('02-'08), Envoy XL 2wd ('02-'06), Envoy XUV 2wd ('04-'05)
|-
|6 <br> (following S)||GMC Envoy Denali 2wd ('05-'08), Envoy XL Denali 2wd ('05-'06)
|-
|1 <br> (following T)||GMC Envoy 4wd ('02-'08), Envoy XL 4wd ('02-'06), Envoy XUV 4wd ('04-'05)
|-
|6 <br> (following T)||GMC Envoy Denali 4wd ('05-'08), Envoy XL Denali 4wd ('05-'06)
|-
|3 <br> (following S)||GMC Envoy SLE 2wd ('09)
|-
|3 <br> (following T)||GMC Envoy SLE 4wd ('09)
|-
|4 <br> (following S)||GMC Envoy SLT 2wd ('09)
|-
|4 <br> (following T)||GMC Envoy SLT 4wd ('09)
|-
|5 <br> (following S)||GMC Envoy Denali 2wd ('09)
|-
|5 <br> (following T)||GMC Envoy Denali 4wd ('09)
|-
|1 <br> (following C)||GMC Yukon 2wd ('00-'06) [GMT800]
|-
|1 <br> (following K)||GMC Yukon 4wd ('00-'06) [GMT800]
|-
|1 <br> (following C)||GMC Yukon 2wd ('07-'08) [GMT900]
|-
|1 <br> (following K)||GMC Yukon 4wd ('07-'08) [GMT900]
|-
|1 <br> (following C)||GMC Yukon 2wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon 4wd ('09) [GMT900]
|-
|1 <br> (following C)||GMC Yukon Hybrid 2wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following K)||GMC Yukon Hybrid 4wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|2 <br> (following C)||GMC Yukon SLE 2wd ('09) [GMT900]
|-
|3 <br> (following C)||GMC Yukon SLT 2wd ('09) [GMT900]
|-
|2 <br> (following K)||GMC Yukon SLE 4wd ('09) [GMT900]
|-
|3 <br> (following K)||GMC Yukon SLT 4wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon Denali 4wd (Early '00) [GMT400; 8th pos. of VIN is R]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd (Mid '00) [GMT400; 8th pos. of VIN is R]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd ('01-'06) [GMT800]
|-
|6 <br> (following C)||GMC Yukon Denali 2wd ('08) [GMT900]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd ('07-'08) [GMT900]
|-
|0 <br> (following C)||GMC Yukon Denali 2wd ('09) [GMT900]
|-
|0 <br> (following K)||GMC Yukon Denali 4wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon Denali 4wd ('09) [GMT900; 8th pos. of VIN is 2]
|-
|1 <br> (following C)||GMC Yukon Denali Hybrid 2wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following K)||GMC Yukon Denali Hybrid 4wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following C)||GMC Yukon XL 1500 series 2wd ('00-'08)
|-
|2 <br> (following C)||GMC Yukon XL 2500 series 2wd ('00-'08)
|-
|6 <br> (following C)||GMC Yukon XL Denali 1500 series 2wd ('08)
|-
|1 <br> (following K)||GMC Yukon XL 1500 series 4wd ('00-'08)
|-
|2 <br> (following K)||GMC Yukon XL 2500 series 4wd ('00-'08)
|-
|6 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('01-'08)
|-
|1 <br> (following C)||GMC Yukon XL 1500 series 2wd ('09)
|-
|2 <br> (following C)||GMC Yukon XL 1500 series SLE 2wd ('09)
|-
|3 <br> (following C)||GMC Yukon XL 1500 series SLT 2wd ('09)
|-
|4 <br> (following C)||GMC Yukon XL 2500 series 2wd ('09)
|-
|5 <br> (following C)||GMC Yukon XL 2500 series SLE 2wd ('09)
|-
|6 <br> (following C)||GMC Yukon XL 2500 series SLT 2wd ('09)
|-
|0 <br> (following C)||GMC Yukon XL Denali 1500 series 2wd ('09)
|-
|1 <br> (following K)||GMC Yukon XL 1500 series 4wd ('09)
|-
|2 <br> (following K)||GMC Yukon XL 1500 series SLE 4wd ('09)
|-
|3 <br> (following K)||GMC Yukon XL 1500 series SLT 4wd ('09)
|-
|4 <br> (following K)||GMC Yukon XL 2500 series 4wd ('09)
|-
|5 <br> (following K)||GMC Yukon XL 2500 series SLE 4wd ('09)
|-
|6 <br> (following K)||GMC Yukon XL 2500 series SLT 4wd ('09)
|-
|0 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('09)
|-
|1 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('09) [8th pos. of VIN is 2]
|-
|1 <br> (following S)||GMC Sonoma 2wd ('00-'03)
|-
|1 <br> (following T)||GMC Sonoma 4wd ('00-'04)
|-
|1 <br> (following S)||GMC Canyon 2wd ('04-'07)
|-
|1 <br> (following T)||GMC Canyon 4wd ('04-'07)
|-
|0 <br> (following V)||Saturn Relay ''2'' 2wd ('05-'07)
|-
|2 <br> (following V)||Saturn Relay ''3'' 2wd ('05-'07)
|-
|5 <br> (following V)||Saturn Relay ''1'' 2wd ('07)
|-
|2 <br> (following X)||Saturn Relay ''3'' Awd ('05-'06)
|-
|2 <br> (following Z)||Saturn Vue I4, Man. Trans., Fwd ('02-'07)
|-
|3 <br> (following Z)||Saturn Vue I4, Auto. Trans., Fwd ('02-'07)
|-
|4 <br> (following Z)||Saturn Vue I4, Auto. Trans., Awd ('02-'05)
|-
|5 <br> (following Z)||Saturn Vue V6, Auto. Trans., Fwd ('03-'07)
|-
|6 <br> (following Z)||Saturn Vue V6, Auto. Trans., Awd ('02-'07)
|-
|3 <br> (following L)||Saturn Vue XE Fwd ('08-'09)
|-
|4 <br> (following L)||Saturn Vue XE Awd ('08-'09)
|-
|5 <br> (following L)||when 4th pos. of VIN is C: Saturn Vue XR Fwd ('08-'09)
|-
|7 <br> (following L)||Saturn Vue XR Awd (Early '08)
|-
|6 <br> (following L)||Saturn Vue XR Awd (Mid '08-'09)
|-
|5 <br> (following L)||when 4th pos. of VIN is D: Saturn Vue XR Awd ('09)
|-
|1 <br> (following L)||Saturn Vue Red Line Fwd ('08-'09)
|-
|9 <br> (following L)||Saturn Vue Red Line Awd ('08)
|-
|0 <br> (following L)||Saturn Vue Red Line Awd ('09)
|-
|0 <br> (following L)||Saturn Vue Green Line Fwd ('08)
|-
|9 <br> (following L)||Saturn Vue Green Line Fwd ('09)
|-
|1 <br> (following R)||Saturn Outlook XE 2wd ('07-'09)
|-
|2 <br> (following R)||Saturn Outlook XR 2wd ('07-'09)
|-
|3 <br> (following R)||Saturn Outlook XR 2wd w/Touring Package ('07-'09)
|-
|1 <br> (following V)||Saturn Outlook XE Awd ('07-'09)
|-
|2 <br> (following V)||Saturn Outlook XR Awd ('07-'09)
|-
|3 <br> (following V)||Saturn Outlook XR Awd w/Touring Package ('07-'09)
|-
|1 <br> (following N)||Hummer H3 ('06-'07)
|-
|1 <br> (following N)||Hummer H3 Base model ('08)
|-
|3 <br> (following N)||Hummer H3 Adventure ('08)
|-
|4 <br> (following N)||Hummer H3 Luxury ('08)
|-
|5 <br> (following N)||Hummer H3 X ('08)
|-
|6 <br> (following N)||Hummer H3 Alpha ('08)
|-
|1 <br> (following N)||Hummer H3, H3T ('09)
|-
|2 <br> (following N)||Hummer H2 ('03-'08), H2 SUT ('05-'08)
|-
|2 <br> (following N)||Hummer H2 Base model ('09), H2 SUT Base model ('09)
|-
|7 <br> (following N)||Hummer H2 Adventure ('09)
|-
|8 <br> (following N)||Hummer H2 Luxury ('09)
|-
|9 <br> (following N)||Hummer H2 SUT Adventure ('09)
|-
|0 <br> (following N)||Hummer H2 SUT Luxury ('09)
|-
|1 (following S)||Isuzu Hombre 2wd ('00), Isuzu i280 2wd ('06), Isuzu i290 2wd ('07-'08), Isuzu i370 2wd ('07-'08)
|-
|2 (following S)||Isuzu i290 2wd w/Preferred Equip. Pkg. ('08), Isuzu i370 2wd w/Comfort Pkg. or upgrade model ('08)
|-
|1 (following T)||Isuzu Hombre 4wd ('00), Isuzu i350 4wd ('06), Isuzu i370 4wd ('07-'08)
|-
|2 (following T)||Isuzu i370 4wd w/Comfort Pkg. ('08)
|-
|1 (following S)||Isuzu Ascender 2wd ('03-'08)
|-
|1 (following T)||Isuzu Ascender 4wd ('03-'08)
|-
|1 (following T)||Saab 9-7X ('05-'08: All, '09: 4.2i, 5.3i)
|-
|2 (following T)||Saab 9-7X Aero ('09)
|}
====Body style codes 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Body type is specified as character 7 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|0||Sedan Pickup/Pickup Delivery ('81-'87 El Camino, Caballero)
|-
|0||Cadillac, Buick, Chevrolet Commercial Body/Chassis
|-
|0||Chassis Only
|-
|1||Cutaway Van
|-
|2||Forward Control ('81-'03) (includes '93-'95 Chevy G30HD/GMC G3500HD)
|-
|2||Sport Utility Truck (SUT) ('04-'09 Avalanche & Escalade EXT, '04-'05 Envoy XUV, '05-'09 Hummer H2 SUT)
|-
|3||Four-Door Cab pickup (Crew Cab) (includes '06-'08 Isuzu i-Series Crew Cab, '09 Hummer H3T)
|-
|3||4-door Passenger Minivan ('97-'09 U-bodies)
|-
|3||4-door SUV or MPV ('06-'09 HHR) (also includes '02-'03 Avalanche & Escalade EXT) ('05-'09 Saab 9-7X)
|-
|4||Two-Door Cab pickup (includes '83-'87 S-10/S-15 extended cab pickups, '03-'06 Chevy SSR, '96-'00 Isuzu Hombre Reg. Cab)
|-
|5||Van (Astro/Safari & full-size vans & '07-'09 HHR Panel)
|-
|6||Extended length 4-door SUV (Suburban, Yukon XL, Escalade ESV, Trailblazer EXT, Envoy XL, Isuzu Ascender 7-psgr.)
|-
|6||3-door Passenger Minivan ('90-'99 U-bodies)
|-
|7||Motor Home Chassis ('81-'09)
|-
|8||Two-Door SUV (Utility) (2-d Tracker, S-10 Blazer, S-15 Jimmy, Blazer, Jimmy, Tahoe, Yukon)
|-
|9||Stake (81-87)
|-
|9||Extended Cab pickup ('88-) (includes '97-'00 Isuzu Hombre Spacecab, '06-'08 Isuzu i-Series Ext. Cab)
|-
|9||Extended length van ('90-) (Astro/Safari & full-size vans)
|}
===American VIN format 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>K</td><td></td><td></td></tr><tr>
<td>4</td>
<td>L</td><td></td><td></td><td>[[#GVWR/Brake System/Body Style 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|GVWR/Brake System/Body Style 2010-]]</td>
</tr><tr>
<td>5</td>
<td>R</td><td></td><td></td><td>[[#Line & Chassis Type 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 2010-]]</td>
</tr><tr>
<td>6</td>
<td>L</td><td></td><td></td><td>[[#Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle]]</td>
</tr><tr>
<td>7</td>
<td>E</td><td></td><td></td><td>[[#Restraint codes for light trucks 2010-|Restraint type]]</td>
</tr><tr>
<td>8</td>
<td>D</td><td></td><td></td><td>[[#Engine codes for light trucks|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>A</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>J</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====GVWR/Brake System/Body Style 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The GVWR/Brake System is specified as character 4 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!GVWR Range in lbs. & Weight Class
!Brake System
!Body Style
|-
| ||Class A: 0-3,000||Hydraulic||
|-
| ||Class B: 3,001-4,000||Hydraulic||
|-
|A||Class C: 4,001-5,000||Hydraulic||26: 4-door SUV or MPV ('10-'11 Chevy HHR Panel, '10-'26 Chevy Equinox, GMC Terrain, '10 Saturn Vue,<br> '12-'15 Chevy Captiva Sport, '19-'24 Cadillac XT4, '24-'26 Buick Encore GX)
|-
|B||Class C: 4,001-5,000||Hydraulic||46: 4-door MPV ('10-'11 Chevy HHR)
|-
|J||Class C: 4,001-5,000||Hydraulic||48: 4-door, 4 window Hatchback ('18-'23 Chevy Bolt EV w/Rear Seat Delete pkg. - incomplete vehicle)
|-
|C||Class C: 4,001-5,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|D||Class C: 4,001-5,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|E||Class C: 4,001-5,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|7||Class C: 4,001-5,000||Hydraulic||75: Four-Door Wagon - High Roof Monocab (Canada only: '12-'14 Chevy Orlando)
|-
|M||Class C: 4,001-5,000||Hydraulic||06: 4-door SUV ('20-'23 Buick Encore GX)
|-
|9||Class C: 4,001-5,000||Hydraulic||56: 4-door SUV Extended ('21-'26 Chevy Trailblazer)
|-
|7||Class C: 4,001-5,000||Hydraulic||58: 4-door Utility Extended ('24-'26 Chevy Trax, Buick Envista)
|-
|C||Class C: 4,001-5,000||Hydraulic||76: 4-door SUV ('13-'22 Buick Encore, Canada only: '13-'14 Chevy Trax, US & Canada: '15-'22 Chevy Trax)
|-
|F||Class D: 5,001-6,000||Hydraulic||26: 4-door SUV ('10-'17 Chevy Equinox, GMC Terrain, '10 Saturn Vue, '10-'16 Cadillac SRX, '11 Saab 9-4X,<br> '12-'13 Chevy Captiva Sport, '16-'26 Buick Envision, '17 Cadillac XT5, '19-'25 Cadillac XT4)
|-
|H||Class D: 5,001-6,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|G||Class D: 5,001-6,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|J||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|H||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|G||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('15-'24 Chevy Colorado, '15-'22 GMC Canyon)
|-
|K||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|J||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|H||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('15-'22 Chevy Colorado, GMC Canyon)
|-
|T||Class D: 5,001-6,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|7||Class D: 5,001-6,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|L||Class E: 6,001-7,000||Hydraulic||26: 4-door SUV ('10 Chevy Traverse, GMC Acadia, Buick Enclave, Saturn Outlook)
|-
|K||Class E: 6,001-7,000||Hydraulic||26: 4-door SUV ('11-'17 Chevy Traverse, Buick Enclave, '11-'23 GMC Acadia, '17 Acadia Limited,<br> '17-'26 Cadillac XT5, '19-'26 Chevy Blazer, '20-'25 Cadillac XT6, '23-'26 Cadillac Lyriq EV,<br> '24-'26 Chevy Blazer EV, '25-'26 Cadillac Optiq EV, '24-'26 Honda Prologue EV, '24 Acura ZDX EV A-Spec)
|-
|7||Class E: 6,001-7,000||Hydraulic||48: 4-door SUV ('24-'25 Chevy Equinox EV)
|-
|E||Class E: 6,001-7,000||Hydraulic||56: 4-door SUV Extended ('18-'26 Chevy Traverse, Buick Enclave, '24 Chevy Traverse Limited,<br> '24-'26 GMC Acadia
|-
|M||Class E: 6,001-7,000||Hydraulic||05: Cargo Van ('10 Chevy Express, GMC Savana)
|-
|L||Class E: 6,001-7,000||Hydraulic||05: Cargo Van ('11-'14 Chevy Express, GMC Savana)
|-
|M||Class E: 6,001-7,000||Hydraulic||06: 4-door SUV ('10 Chevy Tahoe, GMC Yukon, Hummer H3)
|-
|L||Class E: 6,001-7,000||Hydraulic||06: 4-door SUV ('11-'20 Chevy Tahoe Police Pursuit Vehicle 2wd)
|-
|N||Class E: 6,001-7,000||Hydraulic||36: Sport Utility Truck (SUT) ('10 Chevy Avalanche 2wd)
|-
|M||Class E: 6,001-7,000||Hydraulic||36: Sport Utility Truck (SUT) ('11-13 Chevy Avalanche 2wd)
|-
|P||Class E: 6,001-7,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|N||Class E: 6,001-7,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|R||Class E: 6,001-7,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra, Hummer H3T)
|-
|P||Class E: 6,001-7,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited, '16-'26 Chevy Colorado, GMC Canyon)
|-
|S||Class E: 6,001-7,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|R||Class E: 6,001-7,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '19 Chevy Silverado LD, GMC Sierra Limited, '22 Chevy Silverado LTD, GMC Sierra Limited,<br> '16-'22 Chevy Colorado)
|-
|G||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|8||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|X||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('13-'19 Cadillac XTS chassis for Limo/Hearse)
|-
|U||Class F: 7,001-8,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|S||Class F: 7,001-8,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'14 Chevy Express, GMC Savana)
|-
|U||Class F: 7,001-8,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|S||Class F: 7,001-8,000||Hydraulic||06: Passenger Van ('11-'14 Chevy Express, GMC Savana)
|-
|U||Class F: 7,001-8,000||Hydraulic||06: 4-door SUV ('10 Chevy Tahoe, Suburban 1500, GMC Yukon, Yukon XL 1500, Cadillac Escalade, Escalade ESV)
|-
|S||Class F: 7,001-8,000||Hydraulic||06: 4-door SUV ('11-'26 Chevy Tahoe, Suburban 1500, GMC Yukon, Yukon XL 1500, Cadillac Escalade, Escalade ESV)
|-
|V||Class F: 7,001-8,000||Hydraulic||36: Sport Utility Truck (SUT) ('10 Chevy Avalanche 4wd, Cadillac Escalade EXT 4wd)
|-
|T||Class F: 7,001-8,000||Hydraulic||36: Sport Utility Truck (SUT) ('11-'13 Chevy Avalanche 4wd, Cadillac Escalade EXT 4wd)
|-
|X||Class F: 7,001-8,000||Hydraulic||26: 4-door SUV ('24 Acura ZDX EV Type S)
|-
|C||Class F: 7,001-8,000||Hydraulic||56: 4-door SUV Extended ('26- Cadillac Vistiq EV)
|-
|W||Class F: 7,001-8,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|X||Class F: 7,001-8,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|U||Class F: 7,001-8,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|Y||Class F: 7,001-8,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|V||Class F: 7,001-8,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '19 Chevy Silverado LD, GMC Sierra Limited, '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|U||Class F: 7,001-8,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|9||Class F: 7,001-8,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|Z||Class G: 8,001-9,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|W||Class G: 8,001-9,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'26 Chevy Express, GMC Savana)
|-
|Z||Class G: 8,001-9,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|W||Class G: 8,001-9,000||Hydraulic||06: Passenger Van ('11-'26 Chevy Express, GMC Savana)
|-
|Z||Class G: 8,001-9,000||Hydraulic||06: 4-door SUV ('10 Chevy Suburban 2500, GMC Yukon XL 2500)
|-
|W||Class G: 8,001-9,000||Hydraulic||06: 4-door SUV ('11-'13 Chevy Suburban 2500, GMC Yukon XL 2500)
|-
|2||Class H: 9,001-10,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|Z||Class H: 9,001-10,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'26 Chevy Express, GMC Savana,<br> '23-'24 BrightDrop Zevo 600, '24 BrightDrop Zevo 400, '25-'26 Chevrolet BrightDrop 400/600)
|-
|2||Class H: 9,001-10,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|Z||Class H: 9,001-10,000||Hydraulic||06: Passenger Van ('11-'26 Chevy Express, GMC Savana)
|-
|3||Class H: 9,001-10,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|0||Class H: 9,001-10,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
|3||Class H: 9,001-10,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|0||Class H: 9,001-10,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra)
|-
|4||Class H: 9,001-10,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|1||Class H: 9,001-10,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '24-'25 GMC Hummer EV pickup w/20 module battery pack,<br> '24-'26 Chevy Silverado EV, '25-'26 GMC Sierra EV)
|-
|5||Class H: 9,001-10,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|2||Class H: 9,001-10,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'13, '15-'26 Chevy Silverado, GMC Sierra)
|-
|B||Class H: 9,001-10,000||Hydraulic||26: 4-door SUV ('24-'25 GMC Hummer EV SUV)
|-
|6||Class 3: 10,001-14,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|3||Class 3: 10,001-14,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
|6||Class 3: 10,001-14,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|3||Class 3: 10,001-14,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra)
|-
|7||Class 3: 10,001-14,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|4||Class 3: 10,001-14,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22-'24 GMC Hummer EV pickup w/24 module battery pack, '25 GMC Hummer EV pickup w/20 or 24 module battery pack, '26 GMC Hummer EV pickup, '24-'25 Chevy Silverado EV, GMC Sierra EV)
|-
|8||Class 3: 10,001-14,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|5||Class 3: 10,001-14,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'13, '15-'18, '20-'26 Chevy Silverado, GMC Sierra)
|-
|8||Class 3: 10,001-14,000||Hydraulic||06: 4-door SUV ('16-'19, '24-'26 Chevy Suburban 3500HD)
|-
|8||Class 3: 10,001-14,000||Hydraulic||05: Cargo Van ('22 BrightDrop EV600, '23-'24 BrightDrop Zevo 600, '24 BrightDrop Zevo 400,<br> '25-'26 Chevrolet BrightDrop 400/600)
|-
|T||Class 3: 10,001-14,000||Hydraulic||26: 4-door SUV ('25-'26 GMC Hummer EV SUV, '25-'26 Cadillac Escalade IQ [EV])
|-
|L||Class 3: 10,001-14,000||Hydraulic||56: 4-door SUV Extended ('26- Cadillac Escalade IQL [EV])
|-
|9||Class 4: 14,001-16,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|6||Class 4: 14,001-16,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
| ||Class 5: 16,001-19,500||Hydraulic||
|}
====Line & Chassis Type 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Chevrolet HHR ('10-'11), HHR Panel ('10-'11)
|-
|A||Chevy Silverado 1500 2wd ('22-'26), Silverado HD 2500/3500 2wd ('25-'26)
|-
|B||Chevy Blazer 2wd & Awd '19-'26
|-
|C||Chevy Silverado 2wd ('10-'18), Silverado LD 1500 2wd '19, Silverado HD 2500/3500 2wd '19, GMC Sierra 2wd ('10)
|-
|C||Chevy Tahoe 2wd ('10-'24), Suburban 2wd ('10-'24), Avalanche 2wd ('10-'13),<br /> GMC Yukon 2wd ('10), Yukon XL 2wd ('10), Cadillac Escalade 2wd ('10), Escalade ESV 2wd ('10)
|-
|D||Chevy Silverado 1500 4wd ('22-'24)
|-
|D||Chevy Blazer EV ('24-'26), Chevy Equinox EV ('24-'26)
|-
|E||Cadillac Escalade IQ [EV] ('25-'26), Escalade IQL [EV] ('26-), GMC Hummer EV pickup ('26-), GMC Hummer EV SUV ('26-), GMC Sierra EV ('26-)
|-
|F||Chevy Bolt EV w/Rear Seat Delete pkg. - incomplete vehicle ('18-'23)
|-
|G||Cadillac Chassis for Limousine & for Armored Vehicle (Based on XTS '13-'19)
|-
|G||Cadillac Chassis for Hearse (Based on XTS '13-'19)
|-
|G||Chevy Express 2wd ('10-'26), GMC Savana 2wd ('10)
|-
|H||Chevy Express 4wd ('10-'14), GMC Savana 4wd ('10)
|-
|H||GMC Sierra 1500 2wd ('22-'26), Sierra HD 2500/3500 2wd ('25-'26)
|-
|H||Honda Prologue EV ('24-'26), Acura ZDX EV ('24)
|-
|J||Buick Encore 2wd & Awd ('13-'22), Chevy Trax 2wd & Awd (Canada: '13-'22, US: '15-'22)
|-
|J||BrightDrop EV600 ('22), BrightDrop Zevo 600 ('23-'24), BrightDrop Zevo 400 ('24), Chevrolet BrightDrop 400/600 ('25-'26)
|-
|K||Chevy Silverado 4wd ('10-'18), Silverado LD 1500 4wd ('19), Silverado HD 2500/3500 4wd ('19), GMC Sierra 4wd ('10)
|-
|K||Chevy Silverado 1500 4wd ('25-'26), Silverado HD 2500/3500 4wd ('25-'26)
|-
|K||Chevy Tahoe 4wd ('10-'24), Suburban 4wd ('10-'24), Suburban HD 4wd ('24-'26), Avalanche 4wd ('10-'13), GMC Yukon 4wd ('10), Yukon XL 4wd ('10),<br> Cadillac Escalade 4wd ('10), Escalade ESV 4wd ('10), Escalade EXT 4wd ('10)
|-
|K||Cadillac Professional Chassis for Limousine (Based on DTS '10-'11)
|-
|K||Cadillac Commercial Chassis for Hearse (Based on DTS '10-'11)
|-
|L||Chevy Equinox 2wd & Awd '10-'17, Captiva Sport 2wd '12-'15, Captiva Sport Awd '12, GMC Terrain 2wd & Awd '10-'17, Saturn Vue 2wd & Awd '10
|-
|L||GMC Terrain 2wd & Awd '18-'26
|-
|L||Buick Envista '24-'26, Chevy Trax '24-'26
|-
|M||Buick Encore GX 2wd & Awd ('20-'26), Chevy Trailblazer 2wd & Awd ('21-'26)
|-
|N||Cadillac SRX 2wd & Awd '10-'16, Saab 9-4X 2011
|-
|N||GMC Acadia 2wd & Awd '17-'26, Cadillac XT5 2wd & Awd '17-'26
|-
|N||Hummer H3, H3T 2010
|-
|P||Chevy Orlando (Canada only: '12-'14)
|-
|P||Cadillac XT6 2wd & Awd '20-'25
|-
|P||Cadillac Lyriq EV 2wd & Awd '23-'25
|-
|R||GMC Acadia 2wd '10-'16, Acadia Limited 2wd '17, Saturn Outlook 2wd '10, Buick Enclave 2wd '10-'17, Chevy Traverse 2wd '10-'17
|-
|R||Buick Enclave 2wd '18-'24, Chevy Traverse 2wd '18-'23
|-
|R||Buick Enclave 2wd '25-'26, Chevy Traverse 2wd '24-'26
|-
|S||Chevy Traverse Limited 2wd '24
|-
|S||Chevy Colorado 2wd ('10-'12, '15-'26), GMC Canyon 2wd ('10)
|-
|T||Chevy Colorado 4wd ('10-'12, '15-'26), GMC Canyon 4wd ('10)
|-
|T||Chevy Traverse Limited Awd '24
|-
|U||GMC Sierra 1500 4wd ('22-'26), Sierra HD 2500/3500 4wd ('25-'26)
|-
|V||GMC Acadia Awd '10-'16, Acadia Limited Awd '17, Saturn Outlook Awd '10, Buick Enclave Awd '10-'17, Chevy Traverse Awd '10-'17
|-
|V||Buick Enclave Awd '18-'24, Chevy Traverse Awd '18-'23
|-
|V||Buick Enclave Awd '25-'26, Chevy Traverse Awd '24-'26
|-
|W||Chevy Silverado 1500 2wd ('19-'21), Silverado LTD 1500 2wd ('22), Silverado HD 2500/3500 2wd ('20-'24)
|-
|X||Buick Envision 2wd & Awd '16-'20, Chevy Equinox 2wd & Awd '18-'26
|-
|Y||Chevy Silverado 1500 4wd ('19-'21), Silverado LTD 1500 4wd ('22), Silverado HD 2500/3500 4wd ('20-'24)
|-
|Z||Cadillac XT4 2wd & Awd '19-'25, Buick Envision 2wd '21-'23, Buick Envision Awd '21-'26
|-
|1||GMC Sierra 2wd ('11-'18), Sierra Limited 1500 2wd ('19), Sierra HD 2500/3500 2wd ('19), Yukon 2wd ('11-'26), Yukon XL 2wd ('11-'26)
|-
|1||GMC Canyon 2wd ('25-'26)
|-
|2||GMC Sierra 4wd ('11-'18), Sierra Limited 1500 4wd ('19), Sierra HD 2500/3500 4wd ('19), Yukon 4wd ('11-'26), Yukon XL 4wd ('11-'26)
|-
|2||GMC Canyon 4wd ('25-'26)
|-
|3||Cadillac Escalade 2wd ('11-'24), Escalade ESV 2wd ('11-'24)
|-
|3||Cadillac Optiq EV ('25-), Cadillac Vistiq EV ('26-)
|-
|4||Cadillac Escalade 4wd ('11-'24), Escalade ESV 4wd ('11-'24), Escalade EXT 4wd ('11-'13)
|-
|5||GMC Canyon 2wd ('11-'12, '15-'24)
|-
|5||Chevy Tahoe 2wd ('25-'26), Suburban 2wd ('25-'26)
|-
|6||GMC Canyon 4wd ('11-'12, '15-'24)
|-
|6||Chevy Tahoe 4wd ('25-'26), Suburban 4wd ('25-'26)
|-
|7||GMC Savana 2wd ('11-'26)
|-
|8||GMC Savana 4wd ('11-'14)
|-
|8||GMC Sierra 1500 2wd ('19-'21), Sierra Limited 1500 2wd ('22), Sierra HD 2500/3500 2wd ('20-'24)
|-
|8||Cadillac Escalade 2wd ('25-'26), Escalade ESV 2wd ('25-'26)
|-
|9||GMC Sierra 1500 4wd ('19-'21), Sierra Limited 1500 4wd ('22), Sierra HD 2500/3500 4wd ('20-'24)
|-
|9||Cadillac Escalade 4wd ('25-'26), Escalade ESV 4wd ('25-'26)
|-
|0||GMC Hummer EV pickup ('22-'25), GMC Hummer EV SUV ('24-'25), Chevy Silverado EV ('24-'26), GMC Sierra EV ('24-'25)
|}
====Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A (following L)||Saturn Vue XE 2wd ('10)
|-
|E (following L)||Saturn Vue XR V6 2wd ('10)
|-
|K (following L)||Saturn Vue XR-L V6 2wd ('10)
|-
|T (following R)||Saturn Outlook XE 2wd ('10)
|-
|U (following R)||Saturn Outlook XE Premium 2wd ('10)
|-
|V (following R)||Saturn Outlook XR-L 2wd ('10)
|-
|W (following R)||Saturn Outlook XR-L Premium 2wd ('10)
|-
|T (following V)||Saturn Outlook XE Awd ('10)
|-
|U (following V)||Saturn Outlook XE Premium Awd ('10)
|-
|V (following V)||Saturn Outlook XR-L Awd ('10)
|-
|W (following V)||Saturn Outlook XR-L Premium Awd ('10)
|-
|G (following N)||Hummer H3, H3T Base model ('10)
|-
|H (following N)||Hummer H3, H3T Adventure ('10)
|-
|J (following N)||Hummer H3, H3T Luxury ('10)
|-
|K (following N)||Hummer H3, H3T Alpha w/cloth ('10)
|-
|L (following N)||Hummer H3, H3T Alpha w/Leather ('10)
|-
|P (following N)||Saab 9-4X 3.0i 2wd ('11)
|-
|R (following N)||Saab 9-4X 3.0i Awd ('11)
|-
|S (following N)||Saab 9-4X 3.0i Premium 2wd ('11)
|-
|T (following N)||Saab 9-4X 3.0i Premium Awd ('11)
|-
|U (following N)||Saab 9-4X Aero Awd ('11)
|}
===Platform & Series Codes 1985- Passenger Car===
GM used a lettered system of automobile platform codes for three decades. These letters were used as the 4th position of the VIN. Though today's GM platforms use Greek characters, they are still encoded with Latin characters in the 4th position. Position 5 encodes the specific model and trim level of the vehicle.
{| border=1 style="margin:auto;"
!List of GM platforms
!Platform<br>Code
!Series<br>Code
!:Category:General Motors vehicles|Model
|-
|rowspan=14|GM A platform
|rowspan=14|A||W||Chevrolet Celebrity 1985-1990
|-
|E||Pontiac 6000 ''SE'' 1986-1988
|-
|F||Pontiac 6000 1985-1988, 6000 ''LE'' 1989-1991
|-
|G||Pontiac 6000 ''LE'' 1985-1988
|-
|H||Pontiac 6000 ''STE'' 1985-1989
|-
|J||Pontiac 6000 ''SE'' 1989-1991
|-
|G||Oldsmobile Cutlass Ciera ''S'' Sedan 1993-1994
|-
|J||Oldsmobile Cutlass Ciera ''LS'' 1985, Cutlass Ciera 1986-1989 & Cutlass Cruiser 1985-1989,<br /> Cutlass Ciera ''S'' Coupe 1986-1987, Cutlass Ciera ''S'' 1990-1991 & Cutlass Cruiser ''S'' 1990-1994, Cutlass Ciera ''SL'' & Cutlass Cruiser ''SL'' 1995, Ciera ''SL'' sedan & wagon 1996
|-
|L||Oldsmobile Cutlass Ciera 1990-1991, Cutlass Ciera ''S'' Sedan 1992
|-
|M||Oldsmobile Cutlass Ciera ''Brougham'' 1985-1988, Cutlass Ciera ''SL'' Coupe 1986-1989, Cutlass Ciera ''SL'' Sedan 1989-1993, Cutlass Cruiser ''Brougham'' 1987-1988, Cutlass Cruiser ''SL'' 1989-1993
|-
|S||Oldsmobile Cutlass Ciera ''International Series'' 1988-1990
|-
|G||Buick Century ''T-Type'' 1985-1986, Century ''Special'' 1991-1996
|-
|H||Buick Century ''Custom'' 1985-1995
|-
|L||Buick Century ''Limited'' 1985-1993, Century Estate Wagon 1986-1989
|-
|rowspan=14|GM B platform
|rowspan=14|B||L||Chevrolet Impala 1985, Caprice 1986-1992, Caprice Classic 1993-1996, Impala SS 1995-96
|-
|N||Chevrolet Caprice Classic 1985-1992, Caprice Classic LS 1993-1994,<br /> Caprice Classic LTZ 1991-1993, Impala SS 1994
|-
|U||Chevrolet Caprice Classic Brougham/Brougham LS 1987-1990
|-
|L||Pontiac Parisienne 1985-1986, Safari Wagon 1987-1989
|-
|T||Pontiac Parisienne Brougham 1985-1986
|-
|N||Oldsmobile Delta 88 Royale 1985
|-
|P||Oldsmobile Custom Cruiser 1985-1992
|-
|V||Oldsmobile Delta 88 Royale Brougham LS 1985
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1985
|-
|N||Buick Le Sabre ''Custom'' 1985, Roadmaster sedan 1992-1996
|-
|P||Buick Le Sabre ''Limited'' 1985
|-
|R||Buick Le Sabre Estate Wagon 1985-1989, Estate Wagon 1990,<br /> Roadmaster Estate Wagon 1991-1996
|-
|T||Buick Roadmaster ''Limited'' sedan 1992-1996
|-
|V||Buick Electra Estate Wagon 1985-1989
|-
|rowspan=13|GM C platform - front-wheel drive
|rowspan=13|C
|V||Oldsmobile Touring Sedan 1988-1990, 98 Touring Sedan 1991-1993
|-
|W||Oldsmobile 98 Regency Brougham 1985-1990, 98 Regency Elite 1991-1996
|-
|X||Oldsmobile 98 Regency 1985-1990, 1992-1994
|-
|F||Buick Electra T-Type 1985-1990
|-
|U||Buick Electra Park Avenue Ultra 1989-1990, Park Avenue Ultra 1991-1996
|-
|W||Buick Electra Park Avenue 1985-1990, Park Avenue 1991-1996
|-
|X||Buick Electra 1985-1986, Electra Limited 1987-1990
|-
|B||1985-1992 Cadillac Fleetwood, Fleetwood D'Elegance, 1993 Cadillac Sixty Special
|-
|D||1985-1993 Cadillac DeVille
|-
|G||1991-1992 Cadillac Fleetwood Sixty Special
|-
|H||1985-1987 Cadillac Fleetwood Limousine
|-
|S||1987-1990 Cadillac Fleetwood Sixty Special
|-
|T||1991-1993 Cadillac DeVille Touring Sedan
|-
|rowspan=3|GM G platform (models formerly on C platform)
|rowspan=3|C
|-
|U||Buick Park Avenue Ultra 1997-2005
|-
|W||Buick Park Avenue 1997-2005
|-
|rowspan=2|GM D platform
|rowspan=2|D||W||1985-1986 Cadillac Fleetwood Brougham, 1987-1992 Cadillac Brougham
|-
|W||1993-1996 Cadillac Fleetwood
|-
|rowspan=31|GM Delta I platform
|rowspan=31|A
|-
|A||Chevrolet Cobalt LS w/manual trans. 2010
|-
|B||Chevrolet Cobalt LS w/automatic trans. 2010
|-
|C||Chevrolet Cobalt 1LT w/manual trans. 2010
|-
|D||Chevrolet Cobalt 1LT w/automatic trans. 2010
|-
|E||Chevrolet Cobalt 2LT w/manual trans. 2010
|-
|F||Chevrolet Cobalt 2LT w/automatic trans. 2010
|-
|G||Chevrolet Cobalt SS Turbo 2010
|-
|H||Chevrolet Cobalt (base model w/XFE) 2010
|-
|K||Chevrolet Cobalt (base model) 2005, Cobalt LS 2006-2008, Cobalt LS w/man. trans. 2009
|-
|L||Chevrolet Cobalt LS 2005, Cobalt LT 2006-2008, Cobalt LT w/manual trans. 2009
|-
|M||Chevrolet Cobalt SS 2006-2007, Cobalt Sport 2008
|-
|P||Chevrolet Cobalt SS Supercharged 2005-2007, SS Turbo 2008-2009
|-
|S||Chevrolet Cobalt LS w/automatic trans. 2009
|-
|T||Chevrolet Cobalt LT w/automatic trans. 2009
|-
|Z||Chevrolet Cobalt LT 2005, Cobalt LTZ 2006-2007
|-
|L||Pontiac G5 2007-2008, G5 w/manual trans. 2009
|-
|N||Pontiac G5 GT 2007-2008, G5 GT w/manual trans. 2009
|-
|S||Pontiac G5 w/automatic trans. 2009
|-
|T||Pontiac G5 GT w/automatic trans. 2009
|-
|F||Saturn Ion sedan Level 1 w/manual trans. 2003-2005
|-
|G||Saturn Ion sedan Level 1 w/automatic trans. 2003-2005
|-
|J||Saturn Ion sedan Level 2 w/automatic trans. 2003-2007
|-
|K||Saturn Ion sedan Level 3 w/manual trans. 2003-2007
|-
|L||Saturn Ion sedan Level 3 w/automatic trans. 2003-2007
|-
|M||Saturn Ion coupe Level 2 w/manual trans. 2003-2007
|-
|N||Saturn Ion coupe Level 2 w/automatic trans. 2003-2007
|-
|V||Saturn Ion coupe Level 3 w/manual trans. 2003-2007
|-
|W||Saturn Ion coupe Level 3 w/automatic trans. 2003-2007
|-
|Y||Saturn Ion coupe Red Line 2004-2007
|-
|Z||Saturn Ion sedan Level 2 w/manual trans. 2003-2007
|-
|rowspan=9|GM E platform
|rowspan=9|E
|-
|V||Oldsmobile Toronado Trofeo 1988-1992
|-
|Z||Oldsmobile Toronado Brougham 1985-1986, Toronado 1987-1992
|-
|C||Buick Reatta 1988-1991
|-
|Y||Buick Riviera T-Type 1985-1986
|-
|Z||Buick Riviera 1985-1993
|-
|C||Cadillac Eldorado Collector Series 2002
|-
|L||Cadillac Eldorado 1985-2002
|-
|T||Cadillac Eldorado Touring Coupe 1994-2002
|-
|rowspan=26|GM Epsilon I platform
|rowspan=26|Z||A||Chevrolet Malibu Fleet 2010-2012
|-
|B||Chevrolet Malibu LS 2010-2012
|-
|C||Chevrolet Malibu 1LT 2010-2012
|-
|D||Chevrolet Malibu 2LT 2010-2012
|-
|E||Chevrolet Malibu LTZ 2010-2011, Malibu 1LZ 2012
|-
|F||Chevrolet Malibu Hybrid 2008-2010, Malibu 3LT 2012
|-
|G||Chevrolet Malibu LS 2008-2009, Malibu 2LZ 2012
|-
|H||Chevrolet Malibu 1LT 2008-2009
|-
|J||Chevrolet Malibu 2LT 2008-2009
|-
|K||Chevrolet Malibu LTZ 2008-2009
|-
|S||Chevrolet Malibu 2004-2005, Malibu LS 2006-2007, Malibu Classic LS 2008
|-
|T||Chevrolet Malibu LS 2004-2005, Malibu LT 2006-2007, Malibu Classic LT 2008
|-
|U||Chevrolet Malibu LT 2004-2005, Malibu LTZ 2006-2007
|-
|W||Chevrolet Malibu SS 2006-2007
|-
|A||Pontiac G6 Sedan 2010
|-
|F||Pontiac G6 2.4L Sedan (Base model) 2006, G6 Value Leader (Base model w/1SV) 2007-2008
|-
|G||Pontiac G6 3.5L Sedan (Base model) 2005-2006, G6 (Base model) 2007-2009
|-
|H||Pontiac G6 GT 2005-2009
|-
|J||Pontiac G6 (Base model) 2009 1/2 (Mid-Cycle Revision)
|-
|K||Pontiac G6 GT 2009 1/2 (Mid-Cycle Revision)
|-
|L||Pontiac G6 GXP 2009 1/2 (Mid-Cycle Revision)
|-
|M||Pontiac G6 GTP 2006-2007, G6 GXP 2008-2009
|-
|R||Saturn Aura Green Line 2007-2009
|-
|S||Saturn Aura XE 2007-2009
|-
|V||Saturn Aura XR 2007-2008, Aura XR 2.4L 2009
|-
|X||Saturn Aura XR V6 2009
|-
|rowspan=6|GM F platform
|rowspan=6|F||P||Chevrolet Camaro Sport Coupe 1985-2002, Convertible 1987-1992, 1994-2002
|-
|S||Chevrolet Camaro Berlinetta 1985-1986
|-
|S||Pontiac Firebird 1985-2002, Firebird ''Formula'' 1987-1992
|-
|V||Pontiac Firebird ''Formula / Trans Am'' 1993-2002, Firebird ''Trans Am GT'' 1994
|-
|W||Pontiac Firebird ''Trans Am'' 1985-1992, Firebird ''Trans Am GTA'' 1987-1992
|-
|X||Pontiac Firebird ''S/E'' 1985-1986
|-
|rowspan=13|GM G platform - rear-wheel drive
|rowspan=13|G||Z||Chevrolet Monte Carlo 1985-1988
|-
|J||Pontiac Grand Prix 1985-1987
|-
|K||Pontiac Grand Prix LE 1985-1987
|-
|N||Pontiac Bonneville 1985-1986
|-
|P||Pontiac Grand Prix Brougham 1985-1987
|-
|R||Pontiac Bonneville Brougham 1985-1986
|-
|S||Pontiac Bonneville LE 1985-1986
|-
|K||Oldsmobile Cutlass Salon coupe 1985-1987
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1985-1987,<br /> Cutlass Supreme Classic ''Brougham'' 1988
|-
|R||Oldsmobile Cutlass Supreme 1985-1987, Cutlass Supreme Classic 1988
|-
|J||Buick Regal 1985-1987
|-
|K||Buick Regal T-Type 1985-1987
|-
|M||Buick Regal ''Limited'' 1985-1987
|-
|rowspan=4|GM G platform - front-wheel drive
|rowspan=4|G||D||1995-1999 Buick Riviera
|-
|R||1995-1999 Oldsmobile Aurora
|-
|R||2001-2002 Oldsmobile Aurora 3.5
|-
|S||2001-2003 Oldsmobile Aurora 4.0
|-
|rowspan=9|GM H platform
|rowspan=9|H||H||Buick Le Sabre 1987
|-
|P||Buick Le Sabre ''Custom'' 1986-1999
|-
|R||Buick Le Sabre ''Limited'' 1986-1999
|-
|C||Oldsmobile Regency 1997-1998, Eighty Eight 50th Anniversary Edition 1999
|-
|N||Oldsmobile Delta 88 Royale 1986-1988, 88 Royale 1989-1995, Eighty Eight & Eighty Eight LS 1996-99
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1986-1988, 88 Royale Brougham 1989-91, Eighty Eight Royale LS 1992-1995, LSS 1996-1999
|-
|X||Pontiac Bonneville 1987, Bonneville LE 1988-1991, Bonneville ''SE'' 1992-1999
|-
|Y||Pontiac Bonneville SSE 1988-1991, Bonneville ''SSEi'' 1992-1993
|-
|Z||Pontiac Bonneville LE 1987, Bonneville SE 1988-1991, Bonneville ''SSE'' 1992-1999, Bonneville ''SSEi'' 1994-1999
|-
|rowspan=17|GM G platform (models formerly on H platform or their successors)
|rowspan=17|H||A||Buick Lucerne ''CX'' 2010-2011
|-
|B||Buick Lucerne ''CX-2'' 2010
|-
|C||Buick Lucerne ''CXL'' 2010-2011
|-
|D||Buick Lucerne ''CXL V6'' 2006-2009, Lucerne ''CXL Special Edition'' 2010
|-
|E||Buick Lucerne ''CXS'' 2006-2008, Lucerne ''CXL-3'' 2010
|-
|F||Buick Lucerne ''Super'' 2008-2009, Lucerne ''CXL-4'' 2010
|-
|G||Buick Lucerne ''CXL-5'' 2010
|-
|H||Buick Lucerne ''Super 1SP'' 2010
|-
|J||Buick Lucerne ''CXL Premium'' 2010-2011
|-
|K||Buick Lucerne ''Super 1XS'' 2010, Lucerne ''Super'' 2011
|-
|P||Buick Lucerne ''CX'' 2006-2009
|-
|R||Buick Lucerne ''CXL V8'' 2006-2007, Lucerne ''CXL Special Edition V8'' 2008
|-
|P||Buick Le Sabre ''Custom'' 2000-2005
|-
|R||Buick Le Sabre ''Limited'' 2000-2005
|-
|X||Pontiac Bonneville ''SE'' 2000-2005
|-
|Y||Pontiac Bonneville ''SLE'' 2000-2005
|-
|Z||Pontiac Bonneville ''SSEi'' 2000-2003, Bonneville GXP 2004-2005
|-
|rowspan=23|GM J platform
|rowspan=23|J
|-
|C||Chevrolet Cavalier 1985-1994, RS Convertible 1991-1994
|-
|D||Chevrolet Cavalier CS 1985-1987
|-
|E||Chevrolet Cavalier Type 10 1985, RS 1986-1988,<br /> Type 10 Convertible 1985, RS Convertible 1986-1987
|-
|F||Chevrolet Cavalier Z24 1986-1994, Z24 Convertible 1988-1989, 1992-1994
|-
|C||Chevrolet Cavalier 1995-2005, Cavalier RS 1997-1999
|-
|F||Chevrolet Cavalier LS Sedan 1995-2005, LS Coupe 2003-2005, Z24 Coupe 1995-2001,<br /> LS Convertible 1995-1997, Z24 Convertible 1998-2000
|-
|H||Chevrolet Cavalier Z24 Coupe/Sedan 2002, LS Sport 2002-2005
|-
|S||Chevrolet Cavalier LS Coupe 2002
|-
|B||Pontiac Sunbird 1985-1989, Sunbird LE 1990-1991, Sunbird SE 1992-1993,<br /> Sunbird LE 1994
|-
|C||Pontiac Sunbird LE 1985, Sunbird 1991, Sunbird LE 1992-1993
|-
|D||Pontiac Sunbird SE 1985-1991, Sunbird GT 1992-1993
|-
|L||Pontiac Sunbird SE 1994
|-
|U||Pontiac Sunbird GT 1986-1991
|-
|B||Pontiac Sunfire SE 1995-2002, Convertible 1995-2000, Sunfire 2003-2005
|-
|D||Pontiac Sunfire GT 1995-2002
|-
|C||Oldsmobile Firenza Base model 1985-1987, Firenza S 1985-1987, Firenza 1988
|-
|D||Oldsmobile Firenza LX 1985-1987, Firenza SX 1985, Firenza LC, GT 1986-1987
|-
|E||Buick Skyhawk T-Type 1985-1986
|-
|S||Buick Skyhawk Custom 1985-1987, Skyhawk Sport 1986-1987, Skyhawk 1988-1989
|-
|T||Buick Skyhawk Limited 1985-1987
|-
|G||Cadillac Cimarron 1985-1988
|-
|G, H||Toyota Cavalier (Japan only)
|-
|rowspan=8|GM2900 platform
|rowspan=8|J||C||Saturn L-Series|2004 Saturn L300.1
|-
|D||Saturn L-Series|2004 Saturn L300.2, 2005 Saturn L300
|-
|L||Saturn L-Series|2004 Saturn L300.3
|-
|R||Saturn L-Series|Saturn LS w/manual transmission '00/L100 w/manual transmission '01
|-
|S||Saturn L-Series|Saturn LS w/automatic transmission '00/L100 w/automatic transmission '01-'02
|-
|T||Saturn L-Series|Saturn LS1 w/manual transmission '00/L200 w/manual transmission '01-'03, LW200 w/manual trans. '02
|-
|U||Saturn L-Series|Saturn LS1 w/automatic transmission '00/L200 w/automatic transmission '01-'03,<br> Saturn LW1 w/automatic transmission '00/LW200 w/automatic transmission '01-'03
|-
|W||Saturn L-Series|Saturn LS2 '00, LW2 '00, L300 '01-'03, LW300 '01-'03
|-
|rowspan=5|GM K platform
|rowspan=5|K||D||Cadillac Deville 1994-1999
|-
|E||Cadillac Deville D'Elegance 1997-1999
|-
|F||Cadillac Deville Concours 1994-1999
|-
|S||Cadillac Seville 1985-1993 / Cadillac Seville SLS 1994-1997
|-
|Y||Cadillac Seville Touring Sedan / Cadillac Seville STS 1990-1997
|-
|rowspan=9|GM G platform (models formerly on K platform)
|rowspan=9|K||A||2010-2011 Cadillac DTS
|-
|D||2000-2005 Cadillac Deville, 2006-2009 Cadillac DTS, 2010-2011 DTS Luxury
|-
|E||2000-2005 Cadillac Deville DHS
|-
|F||2000-2005 Cadillac Deville DTS
|-
|H||2010-2011 Cadillac DTS Premium
|-
|P||2010-2011 Cadillac DTS Platinum
|-
|R||2010-2011 Cadillac DTS Livery
|-
|S|| 1998-2004 Cadillac Seville SLS
|-
|Y|| 1998-2003 Cadillac Seville STS
|-
|rowspan=33|GM Kappa platform
|rowspan=33|M||A||Pontiac Solstice w/automatic transmission 2010
|-
|B||Pontiac Solstice 2006-2007, Solstice w/manual transmission 2008-2009
|-
|B||Pontiac Solstice GXP w/automatic transmission 2010
|-
|C||Pontiac Solstice w/automatic transmission 2008
|-
|D||Pontiac Solstice w/manual transmission 2010
|-
|E||Pontiac Solstice GXP w/manual transmission 2010
|-
|F||Pontiac Solstice GXP w/automatic transmission 2008
|-
|G||Pontiac Solstice GXP 2007, Solstice GXP w/manual transmission 2008-2009
|-
|K||Pontiac Solstice Street Edition w/manual transmission 2009
|-
|N||Pontiac Solstice w/automatic transmission 2009
|-
|S||Pontiac Solstice SCCA SSB Championship Edition (2.4L) 2008
|-
|T||Pontiac Solstice SCCA T2 Championship Edition (2.0L Turbo) 2008
|-
|T||Pontiac Solstice GXP w/automatic transmission 2009
|-
|Z||Pontiac Solstice Street Edition w/automatic transmission 2009
|-
|B||Saturn Sky 2007, Sky w/manual transmission 2008-2009
|-
|B||Saturn Sky Redline w/automatic transmission 2010
|-
|C||Saturn Sky w/automatic transmission 2008
|-
|C||Saturn Sky Ruby Red (Merlot Jewel) Special Edition w/manual transmission 2009
|-
|C||Saturn Sky Preferred w/automatic transmission 2010
|-
|D||Saturn Sky Hydro Blue Special Edition w/manual transmission 2009
|-
|E||Saturn Sky Redline w/manual transmission 2010
|-
|F||Saturn Sky Redline w/automatic transmission 2008
|-
|F||Saturn Sky Preferred w/manual transmission 2010
|-
|G||Saturn Sky Redline 2007, Sky Redline w/manual transmission 2008-2009
|-
|H||Saturn Sky Redline Ruby Red (Merlot Jewel) Special Edition w/manual transmission 2009
|-
|L||Saturn Sky Redline Hydro Blue Special Edition w/manual transmission 2009
|-
|N||Saturn Sky w/automatic transmission 2009
|-
|P||Saturn Sky Ruby Red (Merlot Jewel) Special Edition w/automatic transmission 2009
|-
|R||Saturn Sky Hydro Blue Special Edition w/automatic transmission 2009
|-
|T||Saturn Sky Redline w/automatic transmission 2009
|-
|V||Saturn Sky Redline Ruby Red (Merlot Jewel) Special Edition w/automatic transmission 2009
|-
|X||Saturn Sky Redline Hydro Blue Special Edition w/automatic transmission 2009
|-
|G||Opel GT 2007-2010, Daewoo G2X 2007-2009
|-
|rowspan=8|GM L platform
|rowspan=8|L
|-
|D||Chevrolet Corsica ''Base'' 1994-1996
|-
|T||Chevrolet Corsica ''Base'' 1987-1989, Corsica ''LT'' 1990-1993
|-
|V||Chevrolet Beretta ''Base'' 1987-1996
|-
|W||Chevrolet Beretta "GT" 1989-1993 (RPO Z21) & Beretta ''Z26'' 1994-1996 (RPO Z04)
|-
|Z||Chevrolet Corsica ''LTZ'' 1989-1990 (RPO Z54)
|-
|Z||Chevrolet Beretta "GTZ" 1990-1993 (RPO Z04)
|-
|T||Pontiac Tempest (Canada only)
|-
|rowspan=5|GM M platform
|rowspan=5|M||R||Chevrolet Sprint
|-
|R||Geo Metro LSi, Metro
|-
|R||Pontiac Firefly (Canada only)
|-
|S||Chevrolet Sprint ER
|-
|S||Geo Metro, Metro XFi
|-
|rowspan=32|GM N platform
|rowspan=32|N
|-
|B||Oldsmobile Cutlass 1997, Cutlass ''GL'' 1998-1999
|-
|C||Buick Skylark 4-door ''Custom'' 1987-1991
|-
|D||Buick Skylark 4-door ''Limited'' 1987-1989, Skylark 4-door ''Luxury Edition'' 1990-1991
|-
|D||Chevrolet Malibu 1997-2003, Chevrolet Classic 2004-2005
|-
|E||Chevrolet Malibu ''LS'' 1997-2003
|-
|E||Pontiac Grand Am 1985-1988, Grand Am ''LE'' 1989-1991
|-
|E||Pontiac Grand Am ''SE'' 1992-2005
|-
|F||Oldsmobile Calais 1985-1987, Cutlass Calais 1988, Cutlass Calais ''S'' 1989-1991
|-
|F||Oldsmobile Achieva ''SL'' 1992-1994, Achieva ''SC'' 1994
|-
|F||Oldsmobile Alero ''GLS'' 1999-2004
|-
|F||Pontiac Grand Am ''SE1'' 2000-2004
|-
|G||Oldsmobile Cutlass ''GLS'' 1997-1999
|-
|G||Pontiac Grand Am 1991
|-
|G||Pontiac Grand Am ''SE2'' 2000, 2003-2004
|-
|J||Buick Somerset Regal 1985, Somerset ''Custom'' 1986-1987, Skylark 2-door ''Custom'' 1988-91, Skylark 4-door ''Custom'' 1986
|-
|J||Buick Skylark 1992, Skylark ''Limited'' 1993-1994, Skylark ''Custom'' 1996-1998,<br /> Skylark ''Limited'' & ''Gran Sport'' 1996-1997
|-
|K||Buick Somerset ''T-Type'' 1986
|-
|K||Oldsmobile Cutlass Calais ''International Series'' 1988-1991
|-
|K||Oldsmobile Alero ''GX'' 1999-2004
|-
|L||Oldsmobile Cutlass Calais 1989-1991
|-
|L||Oldsmobile Achieva ''S'' 1992-1995, Achieva ''SL'' 1996-1998, Achieva ''SC'' 1996-1997
|-
|L||Oldsmobile Alero ''GL'' 1999-2004
|-
|M||Buick Somerset Regal ''Limited'' 1985, Somerset ''Limited'' 1986-'87, Skylark 2-door ''Limited'' '88-'89, Skylark 2-door ''Gran Sport'' 1990-1991, Skylark 4-door ''Limited'' 1986
|-
|M||Buick Skylark ''Gran Sport'' 1992-1994
|-
|T||Oldsmobile Calais ''Supreme'' 1985-1987, Cutlass Calais ''SL'' 1988-1991
|-
|V||Buick Skylark 1990-1991
|-
|V||Buick Skylark ''Custom'' 1993-1995, ''Limited'' 1995, ''Gran Sport'' 1995
|-
|V||Pontiac Grand Am ''LE'' 1985-1988
|-
|V||Pontiac Grand Am ''GT1'' 2000-2005
|-
|W||Pontiac Grand Am ''SE'' 1986-1991
|-
|W||Pontiac Grand Am ''GT'' 1992-2005
|-
|rowspan=5|GM P platform - rear-wheel drive
|rowspan=5|P
|-
||E||Pontiac Fiero ''Coupe'' 1985-1988
|-
||F||Pontiac Fiero ''SE'' 1985-1987
|-
||G||Pontiac Fiero ''GT'' 1985-1988
|-
||M||Pontiac Fiero ''Sport coupe'' 1985-1987
|-
|rowspan=1|GM P platform - front-wheel drive
|rowspan=1|P||X||General Motors EV1 1997, 1999
|-
|rowspan=6|GM R platform
|rowspan=6|R
|-
||F||1985-1986 Chevrolet Spectrum
|-
||F||1987-1988 Chevrolet Spectrum 3-door hatchback, 1989 Geo Spectrum 3-door hatchback
|-
||F||1990-1993 Geo Storm
|-
||G||1987-1988 Chevrolet Spectrum 4-door sedan, 1989 Geo Spectrum 4-door sedan
|-
||T||1990-1993 Geo Storm GSi
|-
|rowspan=8|GM S platform
|rowspan=8|S||K||1985-1988 Chevrolet Nova
|-
|K||1989-1997 Geo Prizm, 1998-2002 Chevrolet Prizm
|-
|L||1988 Chevrolet Nova Twin Cam, 1990-1992 Geo Prizm GSi
|-
|L||2003-2008 Pontiac Vibe, 2009-2010 Pontiac Vibe FWD w/manual transmission
|-
|M||2003-2006 Pontiac Vibe ''AWD'', 2009-2010 Pontiac Vibe AWD w/automatic transmission
|-
|N||2003-2006 Pontiac Vibe ''GT'', 2009-2010 Pontiac Vibe GT FWD w/manual transmission
|-
|P||2009-2010 Pontiac Vibe FWD w/automatic transmission
|-
|R||2009-2010 Pontiac Vibe GT FWD w/automatic transmission
|-
|rowspan=32|GM Sigma platform
|rowspan=32|D||A||Cadillac CTS Base model RWD 2010-2013, CTS Coupe Base model RWD 2014
|-
|B||Cadillac CTS Wagon Luxury Collection RWD 2014
|-
|C||Cadillac CTS Base model AWD 2010-2013, CTS Coupe/Wagon Performance Collection RWD 2014
|-
|D||Cadillac CTS Coupe/Wagon Premium Collection RWD 2014
|-
|E||Cadillac CTS Luxury Collection RWD 2010-2013, CTS Coupe Base model AWD 2014
|-
|F||Cadillac CTS Auto. Trans. RWD 2008-2009, CTS Luxury Collection RWD w/Navigation 2010-2013, CTS Wagon Luxury Collection AWD 2014
|-
|G||Cadillac CTS Auto. Trans. AWD 2008-2009, CTS Luxury Collection AWD 2010-2013, CTS Coupe/Wagon Performance Collection AWD 2014
|-
|H||Cadillac CTS Auto. Trans. AWD w/Navigation 2008-2009, CTS Luxury Collection AWD w/Navigation 2010-2013, CTS Coupe/Wagon Premium Collection AWD 2014
|-
|J||Cadillac CTS Auto. Trans. RWD w/Navigation 2008-2009, CTS Performance Collection RWD 2010-2013
|-
|K||Cadillac CTS Performance Collection RWD w/Navigation 2010-2013
|-
|L||Cadillac CTS Performance Collection AWD 2010-2013
|-
|M||Cadillac CTS V6 2003-2004, CTS 2.8L 2005-2007, CTS Man. Trans. RWD 2008-2009, CTS Performance Collection AWD w/Navigation 2010-2013
|-
|N||Cadillac CTS V-Series 2004-2007, 2009
|-
|P||Cadillac CTS 3.6L 2005-2007, CTS Direct Inj. V6 Man. Trans. RWD 2008-2009, CTS Premium Collection RWD w/Navigation 2010-2013
|-
|R||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD 2008
|-
|S||Cadillac CTS Direct Inj. V6 Auto. Trans. AWD 2008-2009, CTS Premium Collection AWD w/Navigation 2010-2013
|-
|T||Cadillac CTS Direct Inj. V6 Auto. Trans. AWD w/Navigation 2008-2009
|-
|U||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD 2009
|-
|V||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD w/Navigation 2008-2009, CTS sedan V-Series 2010-2014, CTS Wagon V-Series 2011-2014, CTS Coupe V-Series 2011-2015
|-
|0||Cadillac CTS Sport Appearance Pkg. 2010
|-
|1||Cadillac CTS Eco Luxury Pkg. 2010
|-
|2||Cadillac CTS Sport Appearance Pkg. 2011
|-
|A||Cadillac STS V6 AWD 2008-2009
|-
|B||Cadillac STS V8 AWD 2008-2009
|-
|C||Cadillac STS V8 2005-2007, STS V8 RWD 2008-2009
|-
|D||Cadillac STS V6 AWD w/Navigation 2008-2009
|-
|K||Cadillac STS V6 RWD w/Navigation 2008-2009
|-
|L||Cadillac STS V8 AWD w/Navigation 2008-2009
|-
|U||Cadillac STS (all models) 2010, STS (Base model) 2011
|-
|W||Cadillac STS V6 2005-2007, STS V6 RWD 2008-2009, STS Luxury 2011
|-
|X||Cadillac STS V-Series 2006-2009, STS Luxury Performance 2011
|-
|Z||Cadillac STS V8 RWD w/Navigation 2008-2009
|-
|rowspan=4|GM T platform - rear-wheel drive
|rowspan=4|T||B|| 1985-1987 Chevrolet Chevette CS
|-
|B||1985-1987 Pontiac Acadian (Canada only)
|-
|J||1985 Pontiac Acadian Scooter (Canada only)
|-
|L||1985-1987 Pontiac 1000
|-
|rowspan=4|GM T platform - front-wheel drive
|rowspan=4|T||N|| Pontiac LeMans 1988, LeMans LE 1989-1991, LeMans SE 1992-1993
|-
|R||1988-1989 Pontiac LeMans SE sedan
|-
|S||1988-1990 Pontiac LeMans GSE AeroCoupe
|-
|X||1988-1993 Pontiac LeMans VL AeroCoupe
|-
|rowspan=3|GM T platform - front-wheel drive
|rowspan=3|A
|-
|R||Saturn Astra XE (US: 2008, Canada: 2008-2009)
|-
|T||Saturn Astra XR (US: 2008, Canada: 2008-2009)
|-
|rowspan=4|Daewoo T200 platform
|rowspan=4|T||D||Chevrolet Aveo Special Value 2004-2008, Base model 2004, LS 2005-2011, Aveo 1LT 2009-2011
|-
|G||Chevrolet Aveo LT 2005-2008, Aveo 2LT 2009-2011
|-
|J||Chevrolet Aveo LS 2004
|-
|D||Pontiac G3 2009
|-
|rowspan=2|GM V platform - front-wheel drive
|rowspan=2|V||R||1987-1992 Cadillac Allanté with standard removable hardtop
|-
|S||1990-1993 Cadillac Allanté
|-
|rowspan=2|GM V platform - rear-wheel drive
|rowspan=2|V||R||1997-2001 Cadillac Catera
|-
|X||2004-2006 Pontiac GTO coupe
|-
|rowspan=49|GM W platform
|rowspan=49|W
|-
|A||Chevrolet Impala ''LS'' 2010-2013, Impala Limited ''LS'' 2014-2016
|-
|B||Chevrolet Impala ''LS'' 2006-2009, Impala ''LT'' 2010-2013, Impala Limited ''LT'' 2014-2016
|-
|C||Chevrolet Impala ''LT'' 3.9L 2006-2009, Impala ''LTZ'' 2010-2013, Impala Limited ''LTZ'' 2014-2016
|-
|D||Chevrolet Impala ''SS'' 2006-2009, Impala ''Police'' 2010-2013, Impala Limited ''Police'' 2014-2016
|-
|E||Chevrolet Impala ''Taxi'' 2010-2012
|-
|F||Chevrolet Impala 2000-2005, Impala ''LS'' Fleet (1FL) 2011-2013
|-
|G||Chevrolet Impala ''LT'' Fleet (2FL) 2011-2013
|-
|H||Chevrolet Impala ''LS'' 2000-2005
|-
|J||Chevrolet Monte Carlo ''LS'' 2006-2007
|-
|K||Chevrolet Monte Carlo ''LT'' 3.9L 2006, Monte Carlo ''LT'' 3.5L 2007
|-
|L||Chevrolet Lumina 1990-2001, Lumina ''LS'' 1997-1999
|-
|L||Chevrolet Monte Carlo ''SS'' 2006-2007
|-
|M||Chevrolet Monte Carlo ''LT'' 3.5L 2006
|-
|N||Chevrolet Lumina ''Euro'' 1990-1994, Lumina ''LS'' 1995-1996, Lumina ''LTZ'' 1997-1999
|-
|N||Chevrolet Monte Carlo ''LTZ'' 2006
|-
|P||Chevrolet Lumina ''Z34'' 1991-1994, Impala ''SS'' 2004-2005
|-
|S||Chevrolet Impala ''Police'' 2006-2009
|-
|T||Chevrolet Impala ''LT'' 3.5L 2006-2009
|-
|U||Chevrolet Impala ''LTZ'' 2006-2009
|-
|V||Chevrolet Impala ''50th Anniversary Edition'' 2008
|-
|W||Chevrolet Monte Carlo ''LS'' 1995-2005
|-
|X||Chevrolet Monte Carlo ''Z34'' 1995-1999, Monte Carlo ''SS'' 2000-2004, Monte Carlo ''LT'' 2005
|-
|Z||Chevrolet Monte Carlo ''SS Supercharged'' 2004-2005
|-
|C||Pontiac Grand Prix ''GXP'' 2005-2008
|-
|H||Pontiac Grand Prix ''LE'' 1991-1993
|-
|J||Pontiac Grand Prix 1988-1989, Grand Prix ''LE'' 1990, Grand Prix ''SE'' 1991-2000
|-
|K||Pontiac Grand Prix ''LE'' 1988-1989, Grand Prix ''SE1'' 2000-2003
|-
|P||Pontiac Grand Prix ''SE'' 1988-1990, Grand Prix ''GT'' 1991-1993, 1997-2003,<br /> Grand Prix ''GT1'' 2004, Grand Prix 2005-2008
|-
|R||Pontiac Grand Prix ''GTP'' 1999-2005, Grand Prix ''GT'' 2006-2007
|-
|S||Pontiac Grand Prix ''GT2'' 2004, Grand Prix ''GT'' 2005
|-
|T||Pontiac Grand Prix ''STE'' 1990-1993
|-
|H||Oldsmobile Cutlass Supreme 1988-1991, Cutlass Supreme ''S'' 1992-1994,<br /> Cutlass Supreme ''SL'' 1995-1997, Intrigue 1998, Intrigue ''GX'' 1999-2002
|-
|R||Oldsmobile Cutlass Supreme ''International Series'' 1988-1993
|-
|S||Oldsmobile Cutlass Supreme ''SL'' 1988-1991, Intrigue ''GL'' 1998-2002
|-
|T||Oldsmobile Cutlass Supreme Convertible 1990-1995
|-
|X||Oldsmobile Intrigue ''GLS'' 1998-2002
|-
|B||Buick Regal ''Custom'' 1988-1996, Regal ''GS'' Coupe 1995-1996, Regal ''LS'' 1997-2004
|-
|C||Buick Lacrosse ''CX'' 2005-2009
|-
|D||Buick Regal ''Limited'' 1988-1996, Lacrosse ''CXL'' 2005-2009
|-
|E||Buick Lacrosse ''CXS'' 2005-2008
|-
|F||Buick Regal ''GS'' Coupe 1992-1994, Regal ''GS'' Sedan 1992-2004
|-
|F||Buick Allure ''CX'' 2005-2009 (Canada only)
|-
|H||Buick Allure ''CXS'' 2005-2008 (Canada only)
|-
|J||Buick Allure ''CXL'' 2005-2009 (Canada only)
|-
|N||Buick Lacrosse ''Super'' 2008-2009
|-
|P||Buick Allure ''Super'' 2008-2009 (Canada only)
|-
|S||Buick Century ''Custom'' 1997-2005
|-
|Y||Buick Century ''Limited'' 1997-2002
|-
|rowspan=3|GM X platform
|rowspan=3|X||B||1985 Buick Skylark Custom
|-
|C||1985 Buick Skylark Limited
|-
|X||1985 Chevrolet Citation II
|-
|rowspan=39|GM Y platform
|rowspan=39|Y||V||2004-2009 Cadillac XLR
|-
|X||2006-2009 Cadillac XLR V-Series
|-
|Y||1985-2008 Chevrolet Corvette (all models except '90-'95 ZR-1)
|-
|Z||1990-1995 Chevrolet Corvette ZR-1
|-
|G||2009 Chevrolet Corvette GT1 Championship Edition (Base & Z06)
|-
|R||2009 Chevrolet Corvette ZR1 (after early production)
|-
|Y||2009 Chevrolet Corvette (Base model, Early production Z06, Early production ZR1)
|-
|Z||2009 Chevrolet Corvette Z06 (after early production)
|-
|A||2010-2013 Chevrolet Corvette Standard 1LT Man. Trans.
|-
|B||2010-2013 Chevrolet Corvette Preferred 2LT Man. Trans.
|-
|C||2010-2013 Chevrolet Corvette Premium 3LT Man. Trans.
|-
|D||2010-2013 Chevrolet Corvette Custom 4LT Man. Trans.
|-
|E||2010-2013 Chevrolet Corvette Standard 1LT Auto. Trans.
|-
|F||2010-2013 Chevrolet Corvette Preferred 2LT Auto. Trans.
|-
|G||2010-2013 Chevrolet Corvette Premium 3LT Auto. Trans.
|-
|H||2010-2013 Chevrolet Corvette Custom 4LT Auto. Trans.
|-
|J||2010-2013 Chevrolet Corvette Z06 Standard 1LZ Man. Trans.
|-
|K||2010-2013 Chevrolet Corvette Z06 Premium 2LZ Man. Trans.
|-
|L||2010-2013 Chevrolet Corvette Z06 Custom 3LZ Man. Trans.
|-
|M||2010-2013 Chevrolet Corvette ZR1 Standard 1ZR Man. Trans.
|-
|N||2010-2013 Chevrolet Corvette ZR1 Custom 3ZR Man. Trans.
|-
|P||2010-2013 Chevrolet Corvette Grand Sport Standard 1LT Man. Trans.
|-
|R||2010-2013 Chevrolet Corvette Grand Sport Preferred 2LT Man. Trans.
|-
|S||2010-2013 Chevrolet Corvette Grand Sport Premium 3LT Man. Trans.
|-
|T||2010-2013 Chevrolet Corvette Grand Sport Custom 4LT Man. Trans.
|-
|U||2010-2013 Chevrolet Corvette Grand Sport Standard 1LT Auto. Trans.
|-
|V||2010-2013 Chevrolet Corvette Grand Sport Preferred 2LT Auto. Trans.
|-
|W||2010-2013 Chevrolet Corvette Grand Sport Premium 3LT Auto. Trans.
|-
|X||2010-2013 Chevrolet Corvette Grand Sport Custom 4LT Auto. Trans.
|-
|Y||2013 Chevrolet Corvette 427 Convertible Collector Edition Premium 3LT Man. Trans.
|-
|Z||2013 Chevrolet Corvette 427 Convertible Collector Edition Custom 4LT Man. Trans.
|-
|1||2013 Chevrolet Corvette 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|2||2013 Chevrolet Corvette 60th Anniversary Edition Custom 4LT Auto. Trans.
|-
|3||2013 Chevrolet Corvette Grand Sport 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|4||2013 Chevrolet Corvette Grand Sport 60th Anniversary Edition Custom 4LT Auto. Trans.
|-
|5||2013 Chevrolet Corvette Z06 60th Anniversary Edition Custom 3LZ Man. Trans.
|-
|6||2013 Chevrolet Corvette ZR1 60th Anniversary Edition Custom 3ZR Man. Trans.
|-
|7||2013 Chevrolet Corvette 427 Convertible 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|8||2013 Chevrolet Corvette 427 Convertible Collector Edition Preferred 2LT Man. Trans.
|-
|rowspan=13|GM Z platform
|rowspan=13|Z
|-
|E||Saturn SC1 (manual transmission 2-Door) 1993-1999
|-
|F||Saturn SC1 (automatic transmission 2-Door) 1993-1999, SL (manual transmission) 1991-02
|-
|G||Saturn SC (manual transmission) 1991-1992, SC2 (manual transmission 2-Door) 1993-99,<br /> SL1 (manual transmission) 1991-2002, SW1 (manual transmission) 1993-1999
|-
|H||Saturn SC (automatic transmission) 1991-92, SC2 (automatic transmission 2-Door) '93-'99,<br /> SL1 (automatic transmission) 1991-02, SW1 (automatic transmission LHD) '93-'99
|-
|J||Saturn SL2 (manual transmission) 1991-2002, SW2 (manual transmission) 1993-2001
|-
|K||Saturn SL2 (automatic transmission) 1991-2002, SW2 (automatic transmission 1993-1999)
|-
|M||Saturn SW1 "Postal" [SWP] (automatic transmission RHD) 1999-2001 <br>(Made for US Postal Service rural route mail carriers)
|-
|N||Saturn SC1 (manual transmission 3-Door) 1999-2002, SW2 (automatic transmission 2000-01)
|-
|P||Saturn SC1 (automatic transmission 3-Door) 1999-2002
|-
|R||Saturn SC2 (manual transmission 3-Door) 1999-2002
|-
|S||Saturn SL Spring Special 2002
|-
|Y||Saturn SC2 (automatic transmission 3-Door) 1999-2002
|-
|rowspan=3|GM Zeta platform (VE)
|rowspan=3|E||C||Pontiac G8 GT
|-
|P||Pontiac G8 GXP
|-
|R||Pontiac G8 (Base model)
|-
|rowspan=2|GM Zeta platform (VF)
|rowspan=2|F||1||2014-2017 Chevrolet SS w/automatic transmission
|-
|2||2015-2017 Chevrolet SS w/manual transmission
|-
|GM Zeta platform (WM)
|M||K||2011-2013 Chevrolet Caprice PPV
|-
|GM Zeta platform (WN)
|N||S||2014-2017 Chevrolet Caprice PPV
|-
|rowspan=19|GM Zeta platform (models formerly on F platform)
|rowspan=19|F||A||Chevrolet Camaro ''LS'' automatic transmission 2010-2011, ''2LS'' automatic transmission 2012-2014, ''LS'' manual transmission 2015
|-
|B||Chevrolet Camaro ''LT'' automatic transmission 2010-2014, ''2LS'' automatic transmission 2015
|-
|C||Chevrolet Camaro ''2LT'' automatic transmission 2010-2014, ''LT'' manual transmission 2015
|-
|D||Chevrolet Camaro ''LT'' automatic transmission 2015
|-
|E||Chevrolet Camaro ''LS'' manual transmission 2010-2014, ''2LT'' manual transmission 2015
|-
|F||Chevrolet Camaro ''LT'' manual transmission 2010-2014, ''2LT'' automatic transmission 2015
|-
|G||Chevrolet Camaro ''2LT'' manual transmission 2010-2014, ''SS'' manual transmission 2015
|-
|H||Chevrolet Camaro ''SS'' automatic transmission 2015
|-
|J||Chevrolet Camaro ''SS'' automatic transmission 2010-2014. Note: Must have "J" in 8th position of VIN.
|-
|J||Chevrolet Camaro ''ZL1'' automatic transmission 2012. Note: Must have "P" in 8th position of VIN.
|-
|J||Chevrolet Camaro ''2SS'' manual transmission 2015
|-
|K||Chevrolet Camaro ''2SS'' automatic transmission 2010-2015
|-
|L||Chevrolet Camaro ''ZL1'' automatic transmission 2013-2014, ''ZL1'' manual transmission 2015
|-
|M||Chevrolet Camaro ''ZL1'' automatic transmission 2015
|-
|S||Chevrolet Camaro ''SS'' manual transmission 2010-2014. Note: Must have "W" in 8th position of VIN.
|-
|S||Chevrolet Camaro ''ZL1'' manual transmission 2012. Note: Must have "P" in 8th position of VIN.
|-
|S||Chevrolet Camaro ''Z/28'' manual transmission 2014. Note: Must have "E" in 8th position of VIN.
|-
|T||Chevrolet Camaro ''2SS'' manual transmission 2010-2014
|-
|Z||Chevrolet Camaro ''ZL1'' manual transmission 2013-2014, ''Z/28'' manual transmission 2015
|-
|}
RHD= Right-Hand Drive
====Model Line 2010- Passenger Car (Using Vehicle Platforms introduced 2010 or later)====
The Model Line is specified as character 4 of the American GM VIN for Passenger Cars.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Cadillac ATS 2013-2019
|-
|A||Cadillac CTS sedan 2014-2019, CTS V-Series sedan 2016-2019
|-
|B||Chevrolet Cruze 2016-2019
|-
|C||Chevrolet Spark 2013-2022, Spark EV 2014-2016
|-
|D||Cadillac CT4 2020-2026
|-
|D||Cadillac CT5 2020-
|-
|F||Chevrolet Camaro 2016-2024
|-
|F||Chevrolet Bolt EV 2017-2023, Bolt EUV 2022-2023, Bolt 2027
|-
|G||Buick LaCrosse 2010-2016
|-
|G||Buick Regal 2011-2020, Buick Regal TourX 2018-2020
|-
|J||Chevrolet Sonic 2016-2020
|-
|K||Cadillac CT6 2016-2020
|-
|M||Cadillac Celestiq EV 2025-
|-
|P||Buick Verano 2012-2017
|-
|P||Chevrolet Cruze 2011-2015, Cruze Limited 2016
|-
|R||Cadillac ELR 2014, 2016
|-
|R||Chevrolet Volt 2011-2019
|-
|W||Buick Cascada 2016-2019
|-
|Y||Chevrolet Corvette 2014-
|-
|Z||Buick LaCrosse 2017-2019
|-
|Z||Chevrolet Malibu 2016-2025
|-
|1||Cadillac XTS 2013-2019
|-
|1||Chevrolet Impala 2014-2020
|-
|1||Chevrolet Malibu 2013-2015, Malibu Limited 2016
|-
|}
===Body style codes 1987- Passenger Car===
The Body type is specified as character 6 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1||Two-Door Coupe/Sedan
|-
|2||Two-Door Hatchback
|-
|3||Two-Door Convertible
|-
|4||Two-Door Wagon ('91-'92 Geo Storm Hatchback)
|-
|5||Four-Door Sedan
|-
|6||Four-Door Hatchback
|-
|7||Four-Door Hatchback ('89-'90 Geo Prizm hatchback)
|-
|8||Four-Door Station Wagon
|-
|9||Four-Door Station Wagon - High Roof Monocab
|}
===American restraint types 1987-===
The restraint type is specified as character 7 of the American GM VIN for passenger cars.
{{center/top}}
====Restraint codes for passenger cars 1987-2009====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|1||Active (Manual) belts 1987-1996
|-
|2||Active (Manual) belts plus driver and passenger front airbags 1992-2005<br />(For '94-'96 Pontiac Grand Prix coupe: Passive (Automatic) belts plus driver and passenger front airbags)
|-
|3||Active (Manual) belts plus driver side front airbag 1988-1996 <br />(For '94 Geo Prizm: Active (Manual) belts plus driver and passenger front airbags)
|-
|4||Passive (Automatic) belts 1987-1996
|-
|4||Active (Manual) belts plus driver and passenger front & side airbags 1997-2005
|-
|4||Active (Manual) belts plus driver and passenger front & side curtain airbags 2006-2009
|-
|5||Passive (Automatic) belts plus driver side front airbag 1992-1996
|-
|5||Active (Manual) belts plus driver and passenger front airbags & driver-side side impact airbag 2000-2005
|-
|5||Active (Manual) belts plus driver and passenger front airbags & occupant sensor 2006-2009
|-
|6||Passive (Automatic) belts plus driver and passenger front airbags 1994-1996
|-
|6||Active (Manual) belts plus driver and passenger front & side airbags & occupant sensor 2000-2009
|-
|7||Active (Manual) belt driver & Passive (Automatic) belt passenger plus driver and passenger front airbags 1996
|-
|7||Active (Manual) belts plus driver and passenger front & side airbags & rear side airbags 2000-2005
|-
|7||Active (Manual) belts plus driver and passenger front & side & side curtain airbags & occupant sensor 2006-2009
|-
|8||Active (Manual) belts plus driver and passenger front & side curtain airbags & occupant sensor 2006-2009
|-
|9||
|}
{{center/top}}
====Restraint codes for passenger cars 2010-====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|D||Active (Manual) belts plus driver and passenger front & side airbags 2010-
|-
|E||Active (Manual) belts plus driver and passenger front & side & side curtain airbags 2010-2017, 2027
|-
|F||Active (Manual) belts plus driver and passenger front & side curtain airbags 2010
|-
|G||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain airbags 2010-2017
|-
|N||Active (Manual) belts plus driver and passenger front & side & front knee airbags 2016-2019
|-
|R||Active (Manual) belts plus driver and passenger front & side & side curtain & front knee airbags 2012-
|-
|S||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain & front knee airbags 2011-
|-
|T||Active (Manual) belts plus driver and passenger front & side & front row side curtain airbags 2011
|-
|U||Active (Manual) belts plus driver and passenger front & side & front row side curtain & front knee airbags 2012-2017
|}
{{center/top}}
====Restraint codes for light trucks 2010-====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|A||Active (Manual) belts plus driver-side front airbag 2010
|-
|B||Active (Manual) belts plus driver-side front airbag 2011-
|-
|B||Active (Manual) belts plus driver and passenger front airbags 2010
|-
|C||Active (Manual) belts plus driver and passenger front airbags 2011-
|-
|C||Active (Manual) belts plus driver and passenger front & side airbags 2010
|-
|D||Active (Manual) belts plus driver and passenger front & side airbags 2011-
|-
|D||Active (Manual) belts plus driver and passenger front airbags & side curtain airbags for up to 3 rows of seating 2010
|-
|E||Active (Manual) belts plus driver and passenger front & side & side curtain airbags 2010-
|-
|F||Active (Manual) belts plus driver and passenger front airbags & side curtain airbags for up to 3 rows of seating 2011-2015
|-
|F||Active (Manual) belts plus driver and passenger front & side airbags & side curtain airbags for up to 3 rows of seating 2016-
|-
|H||Active (Manual) belts plus driver-side front airbag & driver-side side-impact airbag & driver-side side curtain airbag 2023-2024
|-
|K||Active (Manual) belts plus driver and passenger front & side & side curtain & front center airbags 2013-
|-
|L||Active (Manual) belts plus driver and passenger front & side & side curtain & front center & driver-side knee airbags 2017-2023
|-
|M||Active (Manual) belts plus driver and passenger front & side & side curtain & front center & front knee airbags 2025-
|-
|R||Active (Manual) belts plus driver and passenger front & side & side curtain & front knee airbags 2017-
|-
|S||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain & front knee airbags 2013-
|-
|T||Active (Manual) belts plus driver-side front airbag & driver- and passenger-side side-impact airbags & side curtain airbags 2023-
|-
|U||Active (Manual) belts plus driver and passenger front & side & front row side curtain & front knee airbags 2013-2019
|}
===American engine codes 1981-===
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
====Engine codes for passenger cars====
Warning: Issues with decoding are related to year/model combinations. Each year has a different breakdown for each code along with plants and some model/trim breakdowns over years.
Entry: 1985-1988 Pontiac Fiero has a 9 engine code for the 2.8L L44 V6. Entry: 1986-1990 Cadillac Brougham, Oldsmobile 307 Cu. In. V8 vin code Y.
{| border=1 style="margin:auto;"
!VIN
!RPO
!Size
!Type
!Fuel
!Valvetrain
!Engine Family/Notes/Applications
|-
|A||LD5||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Buick V6. (231 cu. in.) '81 Chevy Camaro (CA), Pontiac Catalina, Firebird, LeMans, Buick Century,<br /> '81-'83 Chevy Malibu (CA), '81-'84 Monte Carlo, Caprice, Impala (CA), '81-'87 Pontiac Grand Prix, Oldsmobile Cutlass/Cutlass Supreme, Buick Regal, '81-'85 Oldsmobile Delta 88, Buick LeSabre,<br /> '81-'86 Pontiac Bonneville, '84 Parisienne
|-
|A||LG0||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4 H.O. '89-'94 Pontiac Grand Am, '89-'91 Oldsmobile Cutlass Calais, '92-'94 Achieva, '90 Cutlass Supreme, '90-'94 Chevy Beretta
|-
|A||LH2||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (For RWD) (Premium V). '04-'09 Cadillac XLR, '05-'10 Cadillac STS
|-
|A||LCV||2.5 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. '13 Chevy Malibu, '16 Malibu Limited, '16-'19 Impala,<br /> '13-'16 Cadillac ATS
|-
|A||LV7||1.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. Made in Changwon, S. Korea. '16-'22 Chevy Spark.
|-
|B||LG2||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6. '86 Oldsmobile 98, Toronado, Buick Electra, Riviera.
|-
|B||L26||4.9 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8.<br /> '91-'93 Cadillac Eldorado, Seville, '91-'95 DeVille, '91-'92 Fleetwood, '91-'93 Sixty Special
|-
|B||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '06-'08 Chevy Cobalt, '06-'07 Saturn Ion, '06-'10 Pontiac G6, Solstice,<br /> '07-'08 Pontiac G5, '07-'10 Saturn Sky, '08-'09 Saturn Aura, '08-'10 Chevy Malibu
|-
|B||LUV||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. '12-'20 Chevy Sonic, '13-'15 Chevy Cruze, '16 Cruze Limited
|-
|C||L17||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu G161Z engine made by GM in US. '82-'87 Chevy Chevette, Pontiac T1000/1000
|-
|C||LN3||3.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6 (3800). '88-'90 Oldsmobile 98, Toronado, Buick Electra, Riviera, Reatta, <br /> '88-'91 Buick LeSabre, Oldsmobile Delta 88/Eighty Eight, Pontiac Bonneville
|-
|C||L47||4.0 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Oldsmobile Aurora V8 (Premium V). Oldsmobile Aurora '95-'99, Aurora 4.0 '01-'03
|-
|C||LS4||5.3 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. Active Fuel Management.<br /> Transversely mounted for FWD. '05-'08 Pontiac Grand Prix GXP, '06-'07 Chevy Monte Carlo SS,<br /> '06-'09 Chevy Impala SS, '08-'09 Buick LaCrosse Super.
|-
|C||LAF||2.4 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. VVT. Buick LaCrosse '10-'11, Regal '11.
|-
|C||LUJ||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. Early production engines were made in Aspern, Austria; later made in Flint, MI. '12 Chevy Cruze
|-
|D||LJ5||1.8 L||Straight-4|I4||Indirect injection Diesel||SOHC,<br /> 8 valve||Isuzu 4FB1 diesel engine imported from Japan. '81-'86 Chevy Chevette
|-
|D||LD2||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4. '88-'95 Pontiac Grand Am, '88-'91 Oldsmobile Cutlass Calais, '92-'95 Achieva,<br /> '88-'91 &'95 Buick Skylark, '90-'91 Pontiac Grand Prix, Oldsmobile Cutlass Supreme,<br /> '95 Chevy Cavalier, Pontiac Sunfire
|-
|D||LC3||4.4 L||V8 Supercharged||Fuel injection#Sequential Multi-port point injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (Premium V). '06-'09 Cadillac XLR V-Series, Cadillac STS V-Series
|-
|E||LK9||3.0 L||V6||2 Barrel Carburetor |2BBL||OHV||Buick V6. '82-'85 Oldsmobile Cutlass Ciera, Buick Century, '85 Oldsmobile 98, Buick Electra
|-
|E||LA1||3.4 L||V6||Fuel injection#Sequential Multi-port point injection|SFI||OHV||Chevrolet 60° V6. '99-'05 Grand Am, '99-'04 Alero, '00-'05 Impala, Monte Carlo
|-
|E||L03||5.0 L||V8||Fuel injection#Throttle Body injection|TBI||OHV||Gen I Chevy Small-Block V8 (305 cu. in.). '88-'92 Camaro/Firebird, '89-'93 Chevy Caprice,<br /> '91 Buick Roadmaster Estate wagon, '91-'92 Oldsmobile Custom Cruiser, Cadillac Brougham.
|-
|E||LXV||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Family 1 Gen 3 engine. W/VVT. '09-'11 Chevy Aveo, '09 Pontiac G3
|-
|E||LS7||7.0 L||V8||Fuel injection#Sequential Multi-port point injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '06-'13 Corvette Z06, '13 Corvette 427, '14-'15 Camaro Z/28
|-
|E||LH7||1.6 L||I4 Turbo||Direct injection <br /> Common-rail Diesel||DOHC,<br /> 16 valve||GM Medium Diesel engine ("Whisper Diesel"). Made by Opel in Szentgotthárd, Hungary.<br /> Aluminum Block & Heads. '17-'19 Chevy Cruze Diesel.
|-
|F||LV8||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Oldsmobile "Rocket" V8 (260 cu. in.) '81 Oldsmobile Cutlass, Delta 88.
|-
|F||L61||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen I. '00-'04 Saturn L-Series, '02-'05 Chevy Cavalier, Pontiac Sunfire, Grand Am,<br /> '02-'04 Oldsmobile Alero, '03-'06 Saturn Ion, '04-'06 Chevy Malibu, '05-'06 Chevy Cobalt
|-
|F||L61||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. '07-'08 Chevy Cobalt, Malibu, Pontiac G5, '07 Saturn Ion.
|-
|F||LB9||5.0 L||V8||Tuned-port fuel injection|TPI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.). '85-'92 Chevy Camaro, Pontiac Firebird.
|-
|G||L46||1.8 L||I4||2 Barrel Carburetor |2BBL||OHV||Chevrolet "122" engine. '82 J-cars.
|-
|G||L69||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8 (High Output 5.0L). (305 cu. in.)<br /> '84-'86 Camaro/Firebird, '84-'88 Chevy Monte Carlo SS
|-
|G||LM3||2.2 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '90-'91 Chevy Cavalier & Corsica/Beretta.
|-
|G||LS1||5.7 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Gen III Chevy Small-Block V8. (346 cu. in.) Aluminum Block & Heads.<br /> '97-'04 Corvette, '98-'02 Camaro/Firebird, '04 Pontiac GTO
|-
|G||LF1||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. 2010 Buick LaCrosse, Cadillac CTS
|-
|G||LWE||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. PZEV emissions.<br /> '13-'15 Chevy Cruze, '16 Cruze Limited, '13-'18 Sonic.
|-
|H||LG4||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '81-'87 F-bodies, '81-'83 Chevy Malibu, '81-'85 Impala,<br /> '81-'88 Caprice, Monte Carlo, '83-'86 Pontiac Bonneville, Parisienne, '83-'87 Grand Prix
|-
|H||LE4||2.0 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil. '92-'94 Pontiac Sunbird.
|-
|H||LX5||3.5 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||Oldsmobile "Shortstar" V6 (Premium V). Oldsmobile Intrigue '99-'02, Aurora 3.5 '01-'02.
|-
|H||LAP||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '09 Chevy Cobalt, Pontiac G5.
|-
|H||LUW||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. '11-'15 Chevy Cruze, '16 Cruze Limited, '12-'18 Sonic.
|-
|J||L39||4.4 L||V8||2 Barrel Carburetor |2BBL||OHV||Gen I Chevy Small-Block V8 (267 cu. in.) '81-'82 Chevy Caprice, Impala, Malibu, Monte Carlo,<br /> '81 Chevy Camaro
|-
|J||LA5||1.8 L||Straight-4|I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil. '84-'86 Pontiac Sunbird, Buick Skyhawk.
|-
|J||LT5||5.7 L||V8||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 32 valve||Based on Chevy Small-Block V8. Designed with Lotus Engineering.<br /> Made by Mercury Marine. Aluminum Block & Heads. '90-'95 Corvette ZR-1
|-
|J||LG8||3.1 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Chevrolet 60° V6. Gen III. 3100. '99-'03 Chevy Malibu, '99 Oldsmobile Cutlass, '00-'01 Chevy Lumina,<br /> '00-'03 Pontiac Grand Prix SE, '00-'05 Buick Century
|-
|J||L99||6.2 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. VVT. With Active Fuel Management. Aluminum Block & Heads.<br /> '10-'15 Camaro SS (auto. trans.)
|-
|J||LTA||4.2 L||V8 Twin Turbo||Direct injection|DI||DOHC,<br /> 32 valve||Cadillac Blackwing V8. VVT. '19-'20 Cadillac CT6 Platinum & V-series
|-
|K||LC3||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '81-'82 Malibu, Monte Carlo, Impala, Caprice, '81 Camaro.
|-
|K||LC5||1.5 L||I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu 4XC1 engine. '85 Chevrolet Spectrum.
|-
|K||LT2||2.0 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '87-'91 Pontiac Sunbird, '87-'88 Oldsmobile Firenza, Buick Skyhawk.
|-
|K||LT2||2.0 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Australia by Holden.<br /> '89-'90 Pontiac LeMans GSE Aerocoupe, '89 LeMans SE sedan
|-
|K||L36||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Series II). '95-'05: Various W-, H-, C-, & G-body models. '95-'02 Camaro/Firebird.
|-
|K||LZE||3.5L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3510cc. VVT. Flex-Fuel E85 compatible.<br /> '06-'07 Chevy Monte Carlo, '06-'11 Chevy Impala, '09-'10 Chevy Malibu, Pontiac G6
|-
|K||LEA||2.4 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||E85 Flex Fuel. GM Ecotec engine, Gen II. VVT. Buick Regal, Verano '12-'17 (except '13 Regal).
|-
|K||LSY||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Active Fuel Management. VVT. VVL.<br /> '19 Cadillac CT6, '20+ Cadillac CT4, CT5
|-
|L||LM1||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8.<br> '81 Camaro Z28 (only w/auto. trans. in US), '81-'82 Impala 9C1 Police, '81 Malibu 9C1 Police
|-
|L||LL1||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 H.O. (longitudinally mounted). '83-'84 Pontiac Firebird.
|-
|L||LN7||3.0 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6. '85-'87 Pontiac Grand Am, '85-'88 Oldsmobile & Buick N-bodies,<br /> '86 Oldsmobile Delta 88, Buick LeSabre
|-
|L||L27||3.8 L||V6||Fuel injection#Tuned port injection|TPI||OHV||Buick V6 (3800 Series I). '90-'95 Buick Regal, '91-'94 Oldsmobile 98, Buick Park Avenue, '91 Reatta, '91-'93 Riviera, '91-'92 Oldsmobile Toronado, '92-'95 Buick LeSabre, '92-'94 Pontiac Bonneville, Oldsmobile 88
|-
|L||LNK||1.8 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2ZZ-GE engine. VVTL-i. '03-'06 Pontiac Vibe GT
|-
|L||LKW||2.5 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. VVL. '14-'15 Chevy Malibu, Impala
|-
|L||L3B||2.7L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM L3B Tripower engine. VVT, VVL. Active Fuel Management. '20+ Cadillac CT4, CT4-V
|-
|M||LY9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '85 Chevrolet Sprint
|-
|M||LT3||2.0 L||Straight-4|I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '87-'90 Pontiac Sunbird, '87 Buick Skyhawk T-Type, '87-'89 Pontiac Grand Am SE.
|-
|M||L82||3.1 L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||Chevrolet 60° V6 (transversely mounted). Gen III. 3100. '93-'97 Oldsmobile Cutlass Supreme,<br /> '94-'98 Pontiac Grand Am, Oldsmobile Achieva, Buick Skylark, '94-'99 Pontiac Grand Prix,<br /> '94-'96 Chevy Corsica/Beretta, Oldsmobile Cutlass Ciera, Buick Regal, '94-'99 Century,<br /> '95-'99 Chevy Lumina, Monte Carlo, '97-'99 Chevy Malibu, Oldsmobile Cutlass
|-
|M||LY9||2.6 L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). Euro-market Cadillac CTS '03-'04.
|-
|M||LGD||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||E85 Flex Fuel. GM High Value 60° V6. VVT. '09-'11 Chevy Impala, Buick Lucerne
|-
|M||LE2||1.4 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. '16-'19 Chevy Cruze.
|-
|N||LF9||5.7 L||V8||Indirect injection Diesel||OHV||Oldsmobile Diesel V8. '81-'85 Chevy Caprice, Impala, '82-'83 Malibu, '82-'84 Monte Carlo,<br /> '81-'84 Pontiac Grand Prix, Bonneville, '81 Catalina, '83-'85 Parisienne,<br /> '81-'84 Oldsmobile 98, '81-'85 Cutlass/Cutlass Supreme, Delta 88, Custom Cruiser, Toronado,<br /> '81-'83 Buick Electra, '81-'85 LeSabre, Electra Estate wagon, Riviera, '82-'83 Regal,<br /> '81-'84 Cadillac DeVille, '81-'85 Fleetwood Brougham, Eldorado, Seville
|-
|N||LG7||3.3 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6 (3300). '89-'93 Buick Century, Skylark, Oldsmobile Cutlass Ciera, '89-'91 Cutlass Calais,<br /> '92-'93 Achieva, Pontiac Grand Am.
|-
|N||LA3||3.2 L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). '03-'04 Cadillac CTS
|-
|N||LZ4||3.5L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3510cc. VVT. '06-'07 Chevy Monte Carlo, '06-'10 Chevy Impala,<br /> '07-'10 Chevy Malibu, Pontiac G6, '07-'08 Saturn Aura
|-
|N||LFR||3.6L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||(Bi-Fuel Gas/CNG). GM High Feature V6. '15-'17 Chevy Impala Bi-Fuel
|-
|P||LQ5||2.0 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '83-'86 J-cars ('83-'84 for Pontiac).
|-
|P||LT1||5.7 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. Aluminum Heads: '92-'96 Corvette, '93-'97 Camaro/Firebird.<br /> Iron Heads: '94-'96 Chevy Caprice, Impala SS, Buick Roadmaster, Cadillac Fleetwood.
|-
|P||LSJ||2.0 L||SC Straight-4|I4 Supercharged||Fuel injection#Sequential central point injection|SFI||DOHC,<br /> 16 valve||GM Ecotec Gen I. Made by Opel in Kaiserslautern, Germany.<br /> '04-'07 Saturn Ion Red Line, '05-'07 Chevy Cobalt SS Supercharged.
|-
|P||LSA||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> Cadillac CTS V-Series '09-'15, Camaro ZL1 '12-'15
|-
|P||LF4||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. Cadillac CT4-V Blackwing '22+
|-
|R||LR8||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Transversely mounted. '82-'85 Chevy Citation, Buick Skylark,<br /> '82-'84 Pontiac Phoenix, Oldsmobile Omega, '82-'90 Chevy Celebrity, '82-'91 Pontiac 6000,<br /> '82-'92 Oldsmobile Cutlass Ciera, Buick Century, '84-'88 Pontiac Fiero, '90-'92 Chevy Lumina
|-
|R||L81||3.0 L||V6||Fuel injection#Multi-port fuel injection|SFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). '97-'01 Cadillac Catera, '00-'05 Saturn L-Series
|-
|R||LZ8||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||GM High Value 60° V6. VVT. Active Fuel Management. '07 Chevy Impala
|-
|R||LS9||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. '09 Corvette ZR1.
|-
|R||LUK||2.4L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '12-'16 Buick LaCrosse eAssist, Regal eAssist,<br /> '13-'14 Chevy Malibu Eco, '14 Chevy Impala Eco
|-
|S||LS5||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Pontiac V8. 265 cu. in.<br /> '81 Pontiac Bonneville, Catalina, Firebird, Grand Prix, LeMans, Buick Century, Regal.
|-
|S||LU5||5.0 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '83 Camaro, Firebird. Dual throttle-body fuel injection.
|-
|S||LB8||2.8 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '85-'89 Chevy Camaro, Pontiac Firebird.
|-
|S||L32||3.4 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '93-'95 Chevy Camaro, Pontiac Firebird.
|-
|S||LS6||5.7 L||V8||Fuel injection#Sequential Multi Port injection|SFI||OHV||Gen III Chevy Small-Block V8. (346 cu. in.) Aluminum Block & Heads.<br /> '01-'04 Corvette Z06, '04-'05 Cadillac CTS V-Series
|-
|S||LGX||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '16-'19 Cadillac ATS, CTS, '16-'20 CT6, '16-'24 Chevrolet Camaro, '17-'19 Buick LaCrosse, '18–'20 Buick Regal GS
|-
|T||LU8||4.9 L||V8 Turbo||4 Barrel Carburetor |4BBL||OHV||Pontiac V8. 301 cu. in. '81 Pontiac Firebird Formula & Trans Am.
|-
|T||LT7||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. FWD version for '82-'85 GM A-bodies.
|-
|T||LS2||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. FWD version for '85 GM C-bodies.
|-
|T||LH0||3.1 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '90-'92 Chevy Camaro, Pontiac Firebird.
|-
|T||LH0||3.1 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (transversely mounted). Gen II. '88-'91 Pontiac 6000,<br /> '89-'93 Grand Prix, Oldsmobile Cutlass Supreme, Buick Regal, '90-'94 Chevy Cavalier, Lumina,<br /> '91-'94 Pontiac Sunbird, '90-'93 Chevy Corsica/Beretta, '90 Celebrity
|-
|T||LD9||2.4 L||Straight-4|I4||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4 ("2.4 Twin Cam"). '96-'01 Pontiac Grand Am, '96-'97 Oldsmobile Achieva, Buick Skylark, '99-'01 Oldsmobile Alero, '97-'99 Chevy Malibu, '96-'02 Chevy Cavalier, Pontiac Sunfire
|-
|T||LP1||2.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||GM High Feature V6. '05-'07 Cadillac CTS
|-
|T||LS9||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. '10-'13 Corvette ZR1.
|-
|T||LFV||1.5L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. '16-'25 Chevy Malibu.
|-
|U||L68||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Transversely mounted. '85-'91 N-bodies
|-
|U||LS2||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '05-'07 Corvette, '05-'06 Pontiac GTO, '06-'07 Cadillac CTS V-Series
|-
|U||LE9||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. E85 Flex-Fuel. 2011-12 Chevy Malibu.
|-
|U||LKN||1.8L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||Full Hybrid. GM Medium Gasoline Engine. VVT. Made in Szentgotthárd, Hungary.<br> '16-'19 Chevy Malibu Hybrid
|-
|V||LT6||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. RWD version.<br /> '82-'83 Chevy Malibu, Monte Carlo, '82-'85 Oldsmobile Cutlass Supreme, Buick Regal
|-
|V||LG5||3.1 L||V6 Turbo||Fuel injection#Multi-port fuel injection|MPFI||OHV||Chevrolet 60° V6. Gen II. Intercooled. (ASC/McLaren modified).<br /> '89-'90 Pontiac Grand Prix Turbo coupe, '90 Grand Prix STE Turbo sedan
|-
|V||LLT||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. '08-'11 Cadillac CTS, STS, '10-'11 Chevrolet Camaro, Buick LaCrosse
|-
|V||LHU||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||E85 Flex Fuel (N/A on Regal GS). GM Ecotec engine, Gen II. VVT.<br /> Buick Regal '11-'13, Verano '13-'16.
|-
|W||L37||4.9 L||V8||4 Barrel Carburetor |4BBL||OHV||Pontiac V8. 301 cu. in. '81 Pontiac Firebird, LeMans Safari wagon.
|-
|W||LB6||2.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Gen I/II Chevrolet 60° V6 (transversely mounted). '85 Chevy Citation, Buick Skylark,<br /> '85-'89 Chevy Cavalier, Celebrity, Pontiac 6000, '85-'88 Cadillac Cimarron,<br /> '85-'87 Oldsmobile Firenza, '86-'89 Cutlass Ciera, '87-'88 Buick Century, '87-'89 Chevy Corsica/Beretta, '88-'89 Pontiac Grand Prix, Oldsmobile Cutlass Supreme, Buick Regal
|-
|W||L64||3.1 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Flex-fuel: Gas/M85 or Gas/E85 (2 versions). Gen II Chevrolet 60° V6. '93 Chevy Lumina VFV
|-
|W||L99||4.3 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. '94-'96 Chevy Caprice.
|-
|W||LS3||6.2 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '08-'13 Corvette, '10-'15 Camaro SS (man. trans.), '09 Pontiac G8 GXP, '14-'17 Chevy SS
|-
|W||LGY||3.0L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '20+ Cadillac CT5, CT5-V
|-
|X||LE2||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (transversely mounted). '81-'85 Chevy Citation, Buick Skylark,<br /> '81-'84 Pontiac Phoenix, Oldsmobile Omega, '82-'86 Chevy Celebrity, Pontiac 6000,<br /> '86 Oldsmobile Cutlass Ciera, Buick Century
|-
|X||LQ1||3.4 L||V6||Fuel injection#Multi-port fuel injection|MPFI||DOHC,<br /> 24 valve||Chevrolet 60° V6 ("Twin Dual Cam V6"). '91-'97 Chevy Lumina, '95-'97 Chevy Monte Carlo,<br /> '91-'96 Pontiac Grand Prix, Oldsmobile Cutlass Supreme
|-
|X||LNF||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. VVT.<br /> '07-'10 Pontiac Solstice GXP, Saturn Sky Red Line, '08-'10 Chevy Cobalt SS Turbo.
|-
|X||LTG||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. '13-'22 Chevy Malibu, '13-'19 Cadillac ATS, '14-'20 Buick Regal,<br /> '14-'19 Cadillac CTS, '16-'23 Chevy Camaro, '16-'18 Cadillac CT6.
|-
|X||LTG||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||Plug-in hybrid. GM Ecotec engine, Gen III. VVT. '17-'18 Cadillac CT6 PHEV. (VIN starts with LRE)
|-
|Y||LV2||5.0 L||V8||4 Barrel Carburetor |4BBL||OHV||Oldsmobile "Rocket" V8 (307 cu. in.) '86-'90 Chevy Caprice wagon, '87 Caprice sedan (Can.),<br /> '81 Pontiac Bonneville, Catalina, '86 Parisienne, '87-'89 Safari wagon, '81-'84 Oldsmobile 98,<br /> '81-'85 Delta 88, Toronado, '81-'90 Custom Cruiser, '81 Cutlass Cruiser, '82-'87 Cutlass Supreme,<br /> '88 Cutlass Supreme Classic, '81-'84 Buick Electra, '85-'89 Electra Estate wagon,<br /> '81-'85 LeSabre, Riviera, '86-'89 LeSabre Estate wagon, '90 Estate wagon, '86-'87 Regal,<br /> '86 Cadillac Fleetwood Brougham, '87-'90 Brougham
|-
|Y||LD8||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (Torque tuned FWD) (Premium V). '93-'02 Cadillac Eldorado,<br /> '94-'04 Cadillac Seville SLS, '94-'05 Cadillac DeVille, '06-'11 Cadillac DTS,<br /> '04-'05 Pontiac Bonneville GXP, '06-'08 Buick Lucerne
|-
|Y||L76||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management.<br /> '08-'09 Pontiac G8 GT.
|-
|Y||LF1||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. 2011 Cadillac CTS
|-
|Y||LF4||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. Cadillac ATS-V '16-'19
|-
|Z||LH7||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (transversely mounted). H.O. '81-'84 Chevy Citation, '82-'84 Pontiac Phoenix, Oldsmobile Omega ES, Buick Skylark, '83-'84 Pontiac 6000 STE, '84 Chevy Celebrity
|-
|Z||LB4||4.3L||V6||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '85 Chevy Impala, '85-'90 Caprice,<br /> '92-'93 Caprice 9C6 taxi, '85-'88 Monte Carlo, '85-'86 Pontiac Parisienne, '86-'87 Grand Prix,<br> '86 Bonneville.
|-
|Z||LAT||2.4L||I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '10 Chevy Malibu Hybrid
|-
|Z||LUZ||2.0 L||I4 Turbo||Direct injection <br /> Common-rail Diesel||DOHC,<br /> 16 valve||GM Family B Diesel (Based on Fiat JTD engine). Made by Opel in Kaiserslautern, Germany.<br /> Iron Block, Aluminum Heads. '14-'15 Chevy Cruze Diesel.
|-
|1||LC1||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (longitudinally mounted). '82-'84 Camaro/Firebird.
|-
|1||LL8||2.0 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '87-'89 Chevy/Olds/Buick J-cars & Chevy L-cars.
|-
|1||L67||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series I). '91-'95 Buick Park Avenue Ultra,<br /> '92-'95 Pontiac Bonneville, Oldsmobile 98, '95 Buick Riviera, Oldsmobile LSS
|-
|1||L67||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series II). '96-'05 Buick Park Avenue Ultra,<br /> '96-'99 Buick Riviera, Oldsmobile LSS, '96-'03 Pontiac Bonneville, '97-'03 Grand Prix,<br /> '97-'04 Buick Regal, '04-'05 Chevy Impala SS, Monte Carlo SS Supercharged
|-
|1||LZ9||3.9L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. VVT.<br /> '06-'07 Chevy Malibu SS, '06-'09 Pontiac G6, '06 Chevy Monte Carlo, Impala, '09-'10 Buick Lucerne
|-
|1||2H0||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. Made in Szentgotthárd, Hungary. '08 (& '09 in Canada) Saturn Astra
|-
|1||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '11 & some '12 Chevy Malibu w/LE5 engine.
|-
|2||LQ9||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Longitudinally mounted. '82-'85 Camaro/Firebird.
|-
|2||LS3||1.0 L||Straight-3|I3 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 6 valve ||Suzuki G10T engine. '87-'88 Chevrolet Sprint Turbo
|-
|2||LY8||1.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 16 valve||Suzuki G13BB engine. '98-'01 Chevrolet Metro
|-
|2||L26||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Series III). '04-'08 Pontiac Grand Prix, '05-'09 Buick LaCrosse, '06-'08 Buick Lucerne
|-
|2||L77||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management.<br /> E85 Flex Fuel. '11-'17 Chevy Caprice PPV.
|-
|3||LC8||3.8 L||V6|V6 Turbo||4 Barrel Carburetor |4BBL||OHV||Buick V6. 231 cu. in. '81-'82 Buick Regal, Riviera, '81 Chevy Monte Carlo.
|-
|3||LG3||3.8 L||V6||Fuel injection#(Sequential) Multi-port injection|MFI/SFI||OHV||Buick V6. '84-'88 Oldsmobile Cutlass Ciera, Buick Century, '85 & '87 Oldsmobile 98, Buick Electra,<br /> '86-'88 Oldsmobile Delta 88, Buick LeSabre, '87 Oldsmobile Toronado, Buick Riviera,<br /> '87-'88 Pontiac Bonneville.
|-
|3||LW2||4.5 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '90 Cadillac DeVille/Fleetwood/Sixty Special/Eldorado/Seville.
|-
|3||L40||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||Oldsmobile Quad 4 ("Quad OHC"). '92-'94 Pontiac Grand Am, Oldsmobile Achieva, Buick Skylark
|-
|3||LZG||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||E85 Flex Fuel. GM High Value 60° V6. VVT. Active Fuel Management. '08 Chevy Impala
|-
|3||LFX||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. E85 Flex Fuel.<br /> '12-'16 Buick LaCrosse, '12-'15 Chevrolet Camaro, Cadillac CTS, '12-'17 Chevrolet Caprice PPV,<br /> '12-'20 Chevrolet Impala, '14-'16 Chevrolet Impala Limited, '13-'15 Cadillac ATS, '13-'19 Cadillac XTS
|-
|3||LT6||5.5 L||V8||Direct injection|DI||DOHC,<br /> 32 valve||Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette Z06 '23+.
|-
|4||LC4||4.1 L||V6|V6||4 Barrel Carburetor |4BBL||OHV||Buick V6. '81-'84 Buick LeSabre, Electra, Riviera, Oldsmobile Toronado, '81-'82 Cadillac DeVille, Fleetwood Brougham, Eldorado, Seville, '81-'83 Oldsmobile 98, '82-'84 Buick Regal,<br /> '82 Pontiac Grand Prix, Bonneville G
|-
|4||LC9||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Toyota 4A-C engine. '85-'88 Chevy Nova
|-
|4||LN2||2.2 L||Straight-4|I4||Fuel injection#(Sequential) Multi-port injection|MPI/SFI||OHV||Chevrolet "122" engine. '92-'02 Cavalier, '95-'02 Sunfire, '92-'96 Corsica/Beretta, '93 Lumina,<br /> '93-'96 Cutlass Ciera, Century.
|-
|4||L32||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series III). '04-'07 Pontiac Grand Prix
|-
|4||LUU||1.4L||I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. ([[w:EREV|Range extender]]). Early production engines were made in Aspern, Austria; later made in Flint, MI. '11-'15 Chevy Volt, '14 & '16 Cadillac ELR.
|-
|4||LT2||6.2 L||V8||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Stingray '20+.
|-
|4||LT2||6.2 L||V8||Direct injection|DI||OHV||Full Hybrid. Gen V Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette E-Ray '24+.
|-
|5||LW9||2.5L||I4||2 Barrel Carburetor |2BBL||OHV||Pontiac Iron Duke engine. '81 Chevy Citation, Pontiac Phoenix, Oldsmobile Omega, Buick Skylark.
|-
|5||LR6||4.5 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac High Technology V8. '88-'89 Cadillac DeVille/Fleetwood/Sixty Special/Eldorado/Seville.
|-
|5||LY9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '86 Chevrolet Sprint
|-
|5||LM9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '87-'88 Chevrolet Sprint
|-
|5||LW0||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 4A-GE engine. '88 Chevy Nova Twin Cam, '90-'92 Geo Prizm GSi
|-
|5||LW0||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Isuzu 4XE1-UW engine. '90-'91 Geo Storm GSi
|-
|5||LT4||5.7 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. '96 Corvette (man. trans.)
|-
|5||LAT||2.4L||I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '07-'09 Saturn Aura Green Line, '08-'09 Chevy Malibu Hybrid
|-
|5||LAP||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '10 Chevy Cobalt.
|-
|5||LFW||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. '12-'13 Cadillac CTS, '14 CTS wagon
|-
|5||L3A||1.5L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. ([[w:EREV|Range extender]]). '16-'19 Chevy Volt.
|-
|5||LWC||1.6L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Medium Gasoline Engine, H.O. VVT. Made in Szentgotthárd, Hungary. '16-'19 Buick Cascada
|-
|5||LS6||6.7 L||V8||Port/Direct injection||OHV||Gen VI Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Stingray, Grand Sport '27+.
|-
|5||LS6||6.7 L||V8||Port/Direct injection||OHV||Full Hybrid. Gen VI Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Grand Sport X '27+.
|-
|6||L81||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. '81 Corvette
|-
|6||LM1||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. '83-'85 Impala 9C1 Police, '86-'88 Caprice 9C1 Police
|-
|6||L73||1.6 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family 1 engine. Made in South Korea by Daewoo. '88-'93 Pontiac LeMans
|-
|6||LP2||1.0 L||Straight-3|I3||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 6 valve ||Suzuki G10A engine. '89-'97 Geo Metro, '98-'00 Chevrolet Metro
|-
|6||L01||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 4A-FE engine. '89-'97 Geo Prizm base/LSi
|-
|6||L01||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 12 valve||Isuzu 4XE1-V engine. '90-'93 Geo Storm (base model)
|-
|6||L42||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen I (Bi-Fuel Gas/CNG). '03-'04 Chevy Cavalier
|-
|6||L91||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||E-TEC II. '04-'07 Chevy Aveo
|-
|6||LXT||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||E-TEC II. '08 Chevy Aveo
|-
|6||LGW||3.0L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '16-'19 Cadillac CT6
|-
|6||LT4||6.2 L||V8 Supercharged||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management. VVT.<br /> '15-'19 Corvette Z06, '17-'24 Camaro ZL1, '16-'19 Cadillac CTS V-Series,<br /> '22+ Cadillac CT5-V Blackwing
|-
|7||LU5||5.0 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '82 Camaro, Firebird. Dual throttle-body fuel injection.
|-
|7||L69||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8 (High Output 5.0L). (305 cu. in.). '83 F-cars, '83 Chevy Monte Carlo SS
|-
|7||LC5||1.5 L||I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu 4XC1 engine. '86-'88 Chevrolet Spectrum, '89 Geo Spectrum.
|-
|7||LC2||3.8 L||V6|V6 Turbo||Fuel injection#Sequential multi-port injection|SFI||OHV||Intercooled. Buick V6. '86-'87 Buick Regal. '89 Pontiac 20th Anniversary Turbo Trans Am
|-
|7||LC7||4.1 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '87-'88 Cadillac Allante.
|-
|7||L05||5.7 L||V8||Fuel injection#Throttle Body injection|TBI||OHV||Gen I Chevy Small-Block V8. '89-'93 Chevy Caprice (police only for '89-'91),<br /> '92-'93 Buick Roadmaster, '92 Oldsmobile Custom Cruiser, '90-'92 Cadillac Brougham, '93 Fleetwood.
|-
|7||LL0||1.9 L||Straight-4|I4||Fuel injection#Multi-port injection|MFI||DOHC,<br /> 16 valve||Saturn I4 engine. '91-'02 Saturn S-Series
|-
|7||LY7||3.6 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. '04-'09 Cadillac CTS, '05-'07 STS, '05-'08 Buick LaCrosse,<br /> '07-'09 Pontiac G6, Saturn Aura, '08-'09 Pontiac G8, '08-'12 Chevy Malibu
|-
|7||LT1||6.2 L||V8||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management. VVT.<br /> '14-'19 Corvette, '16-'24 Camaro SS
|-
|7||LT7||5.5 L||V8 Twin Turbo||Port/Direct injection||DOHC,<br /> 32 valve||Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette ZR1 '25+. (1,064 hp)
|-
|7||LT7||5.5 L||V8 Twin Turbo||Port/Direct injection||DOHC,<br /> 32 valve||Full Hybrid. Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette ZR1X '26+. (1,250 hp)
|-
|8||LV8||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Oldsmobile "Rocket" V8 (260 cu. in.) '82 Oldsmobile Cutlass, Delta 88.
|-
|8||LT8||4.1 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac High Technology V8. '82-'87 Cadillac DeVille, Eldorado, Seville, '82-'85 Fleetwood Brougham, '85-'87 Fleetwood, '87 Fleetwood Sixty Special.
|-
|8||LC8||3.8 L||V6|V6 Turbo||4 Barrel Carburetor |4BBL||OHV||Buick V6. '83 Buick Regal, Riviera.
|-
|8||L83||5.7 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. '82, '84 Corvette. Dual throttle-body fuel injection. 1st fuel injected Corvette since 1965.
|-
|8||L98||5.7 L||V8||Tuned-port fuel injection|TPI||OHV||Gen I Chevy Small-Block V8. '85-'91 Corvette, '87-'92 Chevy Camaro, Pontiac Firebird.
|-
|8||LQ6||4.5 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '89-'92 Cadillac Allante.
|-
|8||L24||1.9 L||Straight-4|I4||Fuel injection#Multi-port injection|MFI||SOHC,<br /> 8 valve||Saturn I4 engine. '95-'02 Saturn S-Series
|-
|8||LX9||3.5 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3498cc. '04-'06 Chevy Malibu, '05-'06 Pontiac G6
|-
|8||LF3||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. '14-'19 Cadillac CTS V-Sport, XTS V-Sport
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Isuzu 4XF1 engine. '92-'93 Geo Storm GSi.
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 7A-FE engine. '93-'97 Geo Prizm
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 1ZZ-FE engine. VVT-i from '00. '98-'02 Chevrolet Prizm, '03-'08 Pontiac Vibe
|-
|8||LAY||1.8 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2ZR-FE engine. Dual VVT-i. '09-'10 Pontiac Vibe
|-
|9||L17||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu G161Z engine made by GM in US. '81 Chevy Chevette, Pontiac T1000
|-
|9||L62||6.0 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac 472-series V8 engine family. V8-6-4 cylinder deactivation.<br /> '81 Cadillacs, '82-'84 Fleetwood Limousine.
|-
|9||LC3||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '83 Malibu, '83-'84 Monte Carlo, Impala, Caprice, '83 Pontiac Parisienne.
|-
|9||LG8||5.0 L||V8||4 Barrel Carburetor |4BBL||OHV||Oldsmobile "Rocket" V8 (307 cu. in.) H.O. '83-'84 Hurst/Olds, '85-'87 Oldsmobile Cutlass 442
|-
|9||LM9||3.8 L||V6|V6 Turbo||Fuel injection#Sequential multi-port injection|SFI||OHV||Buick V6. '84-'85 Buick Regal, Riviera.
|-
|9||L44||2.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Chevrolet 60° V6 (transversely mounted). H.O. '85-'88 Pontiac Fiero
|-
|9||LC0||1.5 L||I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||Isuzu 4XC1-T engine. '87-'88 Chevrolet Spectrum Turbo
|-
|9||LK0||1.9 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||Saturn I4 engine. '91-'94 Saturn S-Series
|-
|9||L37||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (H.O. FWD) (Premium V). '93 Cadillac Allanté,<br /> '93-'02 Cadillac Eldorado Touring Coupe, '93-'04 Cadillac Seville STS, '96-'05 Cadillac DeVille,<br /> '06-'11 Cadillac DTS, '08-'11 Buick Lucerne Super
|-
|9||L72||1.3 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve ||Suzuki G13BA engine. '95-'97 Geo Metro
|-
|9||LUJ||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. Early production engines were made in Aspern, Austria; later made in Flint, MI. '11 Chevy Cruze
|-
|9||LL0||1.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Daewoo S-TEC II engine (1249 cc). VVT. Made in Changwon, S. Korea. '13-'15 Chevy Spark.
|-
|9||LT5||6.2 L||V8 Supercharged||Port/Direct injection||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. VVT. '19 Corvette ZR1.
|-
|0||LH8||1.8 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '82-'86 Pontiac J2000/2000/Sunbird, Oldsmobile Firenza, Buick Skyhawk.
|-
|0||LAX||2.4 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2AZ-FE engine. VVT-i. '09-'10 Pontiac Vibe
|-
|0||LE9||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. E85 Flex-Fuel. 2010 Chevy Malibu.
|-
|0||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. Most '12 Chevy Malibu w/LE5 engine.
|}
H.O.=High Output, CNG=Compressed Natural Gas, VVT=Variable Valve Timing, VVL=Variable Valve Lift
====Motor codes for electric passenger cars====
{| class="wikitable"
|-
! VIN !! RPO !! Fuel !! Drive Wheels !! Application/Notes
|-
| 5 ||LN1|| Electricity || Front || '97, '99 General Motors EV1
|-
| 0 ||EN0|| Electricity || Front || '14-'16 Chevrolet Spark EV
|-
| 0 ||EN0|| Electricity || Front || '17-'23 Chevrolet Bolt EV
|-
| 0 ||EN0|| Electricity || Front || '22-'23 Chevrolet Bolt EUV
|-
|}
====Motor codes for LFP-powered electric passenger cars====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Pack <br /> RPO code !! Fuel !! Drive Wheels !! Application/Notes
|-
|-
| V ||P9D (HPB)|| 1 || EJW || Electricity || Front || '27 Chevrolet Bolt
|}
LFP=Lithium Iron Phosphate
====Motor codes for Ultium-powered electric passenger cars====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Module <br /> RPO code !! # of Modules !! Fuel !! Drive Wheels !! Application/Notes
|-
|-
| 1 ||X0E|| 2 || EXN || 16 || Electricity || All || '25- Cadillac Celestiq
|-
| 2 ||X0E|| 2 || EHT || 16 || Electricity || All || '25- Cadillac Celestiq <br> (Battery Module RPO code EHT is Configuration B)
|}
====Engine codes for light trucks====
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes/Applications
|-
| A ||LD5|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Buick V6. (231 cu. in.) '81-'84 Chevy El Camino, GMC Caballero (CA emissions).
|-
| A ||LR1|| 1.9L || I4 || Gas ||SOHC,<br /> 8 valve||2-bbl carb. Isuzu G200 engine imported from Japan.<br /> '82-'85 Chevy S-10/GMC S-15, '83-'85 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| A ||L38|| 2.5L || I4 || Gas ||OHV||TBI. Pontiac Iron Duke/Tech IV engine. '91-'93 Chevy S-10/GMC Sonoma.
|-
| A ||LH2|| 4.6L || V8 || Gas ||DOHC,<br /> 32 valve||SFI. Cadillac Northstar V8 (For RWD) (Premium V). '04-'09 Cadillac SRX
|-
| A ||L20|| 4.8L || V8 || Gas/E85 ||OHV|| Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads. VVT.<br /> '10-'13 GMT900 pickups, '10-'14 Express/Savana
|-
| A ||LCV|| 2.5L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. VVT. '15-'22 Chevy Colorado, GMC Canyon,<br /> '17-'20 Buick Envision, '17-'21 GMC Acadia, '19-'21 Chevy Blazer
|-
| B ||LR2|| 2.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 60° V6.<br /> '82-'85 Chevy S-10/GMC S-15, '83-'85 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| B ||LU2|| 4.3L || V6 || Gas ||OHV|| TBI. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '90-'91 Astro/Safari higher output engine option.
|-
| B ||L81|| 3.0L || V6 || Gas ||DOHC,<br /> 24 valve||SFI. Opel 54° V6 engine (Made in the UK). '02-'03 Saturn Vue
|-
| B ||L33|| 5.3L || V8 || Gas ||OHV||SFI. Gen III Chevrolet Small-Block V8. Vortec 5300 H.O. 310hp. Aluminum Block & Heads.<br /> '05-'06 Silverado/Sierra 1500 4wd ext. cab short bed,<br> '07 Silverado Classic 1500/Sierra Classic 1500 4wd ext. cab short bed.
|-
| B ||LE8|| 2.2L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. SFI. GM Ecotec Gen II. VVT. '09-'10 Chevy HHR
|-
| B ||LC8|| 6.0L || V8 || Gas/CNG ||OHV||Bi-Fuel (Also Gas/LPG in Express/Savana). SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT. '11-'20 Express/Savana, '13-'19 Silverado HD/Sierra HD.
|-
| B ||LUV|| 1.4L ||I4 Turbo|| Gas ||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. SFI. VVT.<br /> '13-'21 Buick Encore, '15-'21 Chevy Trax (also '13-'14 Trax in Canada)
|-
| C ||LH6|| 6.2L || V8 || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR trucks '82-'93. '82-'86 C/K pickups, '87 R/V pickups,<br /> '88-'93 C/K, Sierra pickups, '82-'91 Blazer/Jimmy, Suburban, '83-'93 full-size vans
|-
| C ||L34|| 2.0L || I4 || Gas ||DOHC,<br /> 16 valve||Suzuki J20A engine. MFI. '99-'03 Chevrolet Tracker
|-
| C ||LY2|| 4.8L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads.<br /> '07-'09 GMT900 pickups, '07-'09 Tahoe/Yukon, '08-'09 Express/Savana
|-
| C ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '11.
|-
| C ||L83|| 5.3L || V8 || Gas/E85 ||OHV|| Flex Fuel. Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management<br /> '14-'19 K2XX pickups, '15-'20 K2XX SUVs.
|-
| C ||L2R|| 2.7L ||I4 Turbo||| Gas ||DOHC,<br /> 16 valve||GM L3B Tripower engine ("TurboMax") - Detuned version. Direct Injection. VVT, VVL. Active Fuel Management. '23-'24 Chevy Colorado.
|-
| D ||LE3|| 4.1L || I6 || Gas ||OHV||2-bbl carb. Chevrolet Turbo-Thrift I6.<br /> '81-'84 Chevy/GMC C/K pickups, full-size vans, '81-'82 Blazer/Jimmy
|-
| D ||LG6|| 3.1L || V6 || Gas ||OHV||TBI. Chevrolet 60° V6. '90-'95 U-body minivans.
|-
| D ||L61|| 2.2L || I4 || Gas ||DOHC,<br /> 16 valve||SFI. GM Ecotec Gen I. '02-'07 Saturn Vue, '06 Chevy HHR.
|-
| D ||L61|| 2.2L || I4 || Gas ||DOHC,<br /> 16 valve||SFI. GM Ecotec Gen II. '07-'08 Chevy HHR.
|-
| D ||LLT|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. '09-'16 GMC Acadia, '17 GMC Acadia Limited,<br /> '09-'17 Chevrolet Traverse, Buick Enclave, '09-'10 Saturn Outlook
|-
| D ||LBZ|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine.<br /> Mid '06 Silverado HD/Sierra HD & '07 Silverado Classic HD/Sierra Classic HD
|-
| D ||L84|| 5.3L || V8 || Gas/E85 ||OHV|| Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. With Dynamic Fuel Management<br /> '19+ Chevy/GMC Silverado 1500/Sierra 1500, '21+ Tahoe/Yukon, Suburban/Yukon XL.
|-
| E ||LN8|| 2.5L || I4 || Gas ||OHV||TBI. Pontiac Iron Duke/Tech IV engine.<br /> '85-'90 Chevy/GMC S-10/S-15, Astro/Safari Cargo Van, '85-'88 S-10 Blazer/S-15 Jimmy.
|-
| E ||LLR|| 3.7L || I5 || Gas ||DOHC,<br /> 20 valve||Atlas I5. SFI. VVT.<br /> '07-'12 Colorado/Canyon, '07-'08 Isuzu i-370, '07-'10 Hummer H3, '09-'10 Hummer H3T
|-
| E ||LA1|| 3.4L || V6 || Gas ||OHV||Chevrolet 60° V6. '96 GMT199 (U-body) minivans, '97-'05 GMT200 (U-body) minivans,<br /> '01-'05 Pontiac Aztek, '02-'05 Buick Rendezvous
|-
| F ||LF3|| 5.0L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. '81-'86 C/K, full-size vans, '81-'82 Blazer/Jimmy.<br /> CA emissions version of LE9 5.0 V8.
|-
| F ||L65|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks '92-'02,<br /> Chevy/GMC Suburban 1500/2500 '94-'99, over-8,500 lb. GVWR Express/Savana '96-'02
|-
| F ||LNJ|| 3.4L || V6 || Gas ||OHV||Chevrolet 60° V6. Made in China by SAIC-GM. '05-'09 Chevy Equinox, '06-'09 Pontiac Torrent.
|-
| F ||L94|| 6.2L || V8 || Gas/E85 ||OHV||Flex-Fuel. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT. Active Fuel Management. '10-'14 GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV.
|-
| F ||L20|| 4.8L || V8 || Gas/E85 ||OHV|| Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads. VVT.<br /> '15-'17 Express/Savana
|-
| F ||L82|| 5.3L || V8 || Gas ||OHV|| Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. With Active Fuel Management<br /> '19-'21 Chevy Silverado 1500, GMC Sierra 1500 (T1XX).
|-
| G ||LG9|| 5.0L || V8 || Gas ||OHV|| 2-bbl carb. Gen I Chevrolet Small-Block V8. '81 Chevy/GMC C/K pickups, Blazer/Jimmy, full-size van
|-
| G ||L18|| 8.1L || V8 || Gas ||OHV||MFI. Vortec 8100. Gen VII Chevrolet Big-Block V8. '01-'02 C3500HD, '01-'06 Silverado HD/Sierra HD, '07 Silverado Classic HD/Sierra Classic HD, '01-'06 Suburban/Yukon XL 2500, '02-'06 Avalanche 2500, '01-'02 Express/Savana
|-
| G ||L96|| 6.0L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '10-'19 Silverado HD/Sierra HD, '10-'13 Suburban 2500/Yukon XL 2500, '16-'19 Suburban 3500,<br /> '10-'20 Express/Savana.
|-
| G ||LSD|| 1.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '23+ Chevy Equinox, GMC Terrain
|-
| H ||LG4|| 5.0L || V8 || Gas ||OHV||4-bbl carb. Gen I Chevy Small-Block V8. (305 cu. in.) '81-'87 Chevy El Camino, GMC Caballero.
|-
| H ||LE9|| 5.0L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. '81-'86 C/K pickups, Blazer/Jimmy, Suburban, full-size vans
|-
| H ||L03|| 5.0L || V8 || Gas ||OHV|| TBI. Gen I Chevrolet Small-Block V8. '87 R/V pickups, '88-'95 C/K, Sierra pickups, '87-'95 full-size vans, '87 Blazer/Jimmy, Suburban.
|-
| H ||LN2|| 2.2L || I4 || Gas ||OHV||SFI. Chevrolet "122" engine. '03 Chevy S-10/GMC Sonoma
|-
| H ||LS2|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevy Small-Block V8. Chevy SSR '05-'06, Trailblazer SS '06-'09, Saab 9-7X Aero '08-'09.
|-
| H ||LV3|| 4.3L || V6 || Gas/E85 ||OHV||Flex Fuel. Chevrolet 90° V6 - Gen V Chevrolet Small-Block V6 (EcoTec3). Direct injection, VVT. Active Fuel Management. '14-'21 Chevy Silverado 1500/GMC Sierra 1500.
|-
| J ||L39|| 4.4L || V8 || Gas ||OHV||2-bbl carb. Gen I Chevy Small-Block V8 (267 cu. in.) '81-82 Chevy El Camino, GMC Caballero.
|-
| J ||LL4|| 6.2L || V8 || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR trucks '82-'93. '82-'86 C/K pickups, '87-'91 R/V pickups,<br /> '88-'93 C/K, Sierra pickups, '82-'91 Blazer/Jimmy, Suburban, '83-'93 full-size vans
|-
| J ||L29|| 7.4L || V8 || Gas ||OHV|| MFI. Vortec 7400. Gen VI Chevrolet Big-Block V8.<br /> '96-'00 C/K, Sierra pickups, Express/Savana, '96-'99 Suburban 2500
|-
| J ||LY5|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. Iron Block & Aluminum Heads.<br /> '07-'09 Silverado/Sierra 1500, Tahoe/Yukon, Suburban/Yukon XL 1500, Avalanche
|-
| J ||LZ1|| 6.0L || V8 || Gas-Electric Hybrid ||OHV||2-Mode Hybrid. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT. Active Fuel Management. '10-'13 Tahoe Hybrid, Yukon Hybrid, Escalade Hybrid, Silverado Hybrid, Sierra Hybrid
|-
| J ||L86|| 6.2L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management. <br /> '14-18 Chevy/GMC Silverado 1500/Sierra 1500,<br /> '18-20 Chevy Tahoe Premier, '19-'20 Chevy Suburban Premier, GMC Yukon/Yukon XL SLT,<br /> '15-'20 GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV.
|-
| K ||LC3|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '81-'82 Chevy El Camino, GMC Caballero (49-state emissions)
|-
| K ||L05|| 5.7L || V8 || Gas ||OHV|| TBI. Gen I Chevrolet Small-Block V8. '87 R/V pickups, '88-'95 C/K, Sierra pickups, '87-'95 full-size vans, '96 G-Classic full-size vans, '87-'94 Blazer, '95 Tahoe, '87-'91 Jimmy, '92-'95 Yukon, '87-'95 Suburban.
|-
| K ||LY6|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '07-'09 Silverado HD/Sierra HD, '07-'09 Suburban 2500/Yukon XL 2500, '08-'09 Express/Savana
|-
| K ||LEA|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex Fuel. GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '12-'17,<br /> Chevy Captiva Sport '12-'14, Chevy Orlando '14.
|-
| K ||L3B|| 2.7L ||I4 Turbo||| Gas ||DOHC,<br /> 16 valve||GM L3B Tripower engine ("TurboMax"). Direct Injection. VVT, VVL. Active Fuel Management.<br /> '19+ Chevy Silverado 1500, GMC Sierra 1500, '23+ Chevy Colorado, GMC Canyon.
|-
| L ||LS9|| 5.7L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. For sub-8,500 lb. GVWR trucks, vans, Suburban, Blazer/Jimmy (CA) '81-'86.
|-
| L ||L27|| 3.8L || V6 || Gas ||OHV||Buick V6 (3800 Series I). '92-'95 U-body minivans
|-
| L ||LX9|| 3.5L || V6 || Gas ||OHV||GM High Value 60° V6. 3498cc. SFI. '05-'06 GMT201 minivans, '06-'07 Buick Rendezvous
|-
| L ||LH8|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads.<br /> '08-'09 Hummer H3 Alpha, '09 Colorado/Canyon, Hummer H3T Alpha
|-
| L ||LGH|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. Mid '10-'16 Express/Savana, '11-'12 Silverado HD/Sierra HD chassis cabs
|-
| L ||L87|| 6.2L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Dynamic Fuel Management.<br /> '19+ Chevy/GMC Silverado 1500/Sierra 1500, '21+ Tahoe/Yukon, Suburban/Yukon XL,<br /> Cadillac Escalade/Escalade ESV.
|-
| L ||L3T|| 1.3L || I3 Turbo || Gas ||DOHC,<br /> 12 valve||GM E-Turbo Engine. Direct Injection. VVT. '20+ Buick Encore GX, '21+ Chevy Trailblazer.
|-
| M ||LT9|| 5.7L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevy Small-Block V8.<br /> For over-8,500 lb. GVWR C/K trucks, full-size vans, Suburban '81-'86, full-size van cutaway '81-'88.<br /> '88 Chevy/GMC R30/3500 Chassis Cab w/C7C (10,500 lb. GVWR),<br /> V30/3500 Chassis Cab w/C7E (11,000 lb. GVWR)
|-
| M ||L30|| 5.0L || V8 || Gas ||OHV||Gen 1+ Chevrolet Small-Block V8. Vortec 5000. CPI.<br /> '96-'99 Chevy C/K, GMC Sierra, '96-'02 Express/Savana
|-
| M ||LNF|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. 2010 Chevy HHR SS.
|-
| M ||LH6|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. Aluminum Block & Heads.<br /> '05-'06 GMT370 SUVs (Trailblazer EXT/Envoy XL/Isuzu Ascender 7-psgr.), '05-'07 Buick Rainier,<br /> '05-'09 GMC Envoy Denali, Saab 9-7X, '06-'08 Chevy Trailblazer, '05 GMC Envoy XUV,<br /> '07-'09 Silverado/Sierra 1500
|-
| M ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Orlando '12.
|-
| M ||LE2|| 1.4L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '16-'19 & '21-'22 Buick Encore, '21-'22 Chevy Trax.
|-
| N ||L10|| 1.8L || I4 || Gas ||SOHC,<br /> 8 valve||2-bbl carb. Isuzu G180Z engine imported from Japan. '81-'82 Chevy LUV
|-
| N ||LF9|| 5.7L || V8 || Diesel ||OHV||Oldsmobile Diesel V8. '83-'84 Chevy El Camino/GMC Caballero.
|-
| N ||LB1|| 4.3L || V6 || Gas ||OHV|| 4-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '85 Astro/Safari, '85-'86 C/K pickups & full-size vans
|-
| N ||L19|| 7.4L || V8 || Gas ||OHV|| Mark IV Chevrolet Big-Block V8. TBI.<br /> '87-'90 R/V pickups, Suburban 2500, '88-'90 C/K, Sierra pickups, full-size vans
|-
| N ||L19|| 7.4L || V8 || Gas ||OHV|| Gen V Chevrolet Big-Block V8. TBI.<br /> '91 R/V pickups, '91-'95 C/K, Sierra pickups, Suburban 2500, full-size vans. '96 G-Classic full-size vans
|-
| N ||LZ4|| 3.5L || V6 || Gas ||OHV||GM High Value 60° V6. 3510cc. SFI. VVT. '08-'09 Saturn Vue
|-
| N ||LQ9|| 6.0L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Vortec 6000 H.O. or VortecMAX. Iron Block/Aluminum Heads.<br /> 345 hp. '02-'06 Cadillac Escalade, '03-'06 Cadillac Escalade ESV, '03-'06 Chevy Silverado SS,<br /> '05-'06 GMC Sierra Denali, '07 GMC Sierra Classic Denali.
|-
| N ||LGZ|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. Direct Injection. VVT. Active Fuel Management.<br /> '17-'22 Chevy Colorado, GMC Canyon.
|-
| P ||L49|| 6.5L || V8 || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks & full-size vans '94-'95
|-
| P ||LM4|| 5.3L || V8 || Gas ||OHV||Gen III Chevrolet Small-Block V8. Vortec 5300. 290hp. Aluminum Block & Heads.<br /> '03-'04 Chevy SSR, '03-'04 GMT370 SUVs (Trailblazer EXT/Envoy XL/Isuzu Ascender 7-psgr.),<br /> '04 Buick Rainier, GMC Envoy XUV
|-
| P ||LE5|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||MFI. GM Ecotec Gen II. VVT. '06-'08 Chevy HHR, '08-'09 Saturn Vue
|-
| P ||LH9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT.<br /> '10-'12 Colorado/Canyon, '10 Hummer H3 Alpha, H3T Alpha
|-
| P ||LV1|| 4.3L || V6 || Gas ||OHV||Chevrolet 90° V6 - Gen V Chevrolet Small-Block V6 (EcoTec3). Direct injection, VVT.<br /> '18+ Chevy Express/GMC Savana.
|-
| P ||LBP|| 1.2L || I3 Turbo || Gas/E85 ||DOHC,<br /> 12 valve||Flex Fuel. GM E-Turbo Engine. Direct Injection. VVT.<br /> '25+ Buick Encore GX, Chevy Trailblazer, '25- Chevy Trax, Buick Envista.
|-
| R ||LL2|| 2.8L || V6 || Gas ||OHV||TBI. Chevrolet 60° V6. '86-'93 Chevy S-10, GMC S-15/Sonoma,<br /> '86-'89 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| R ||L31|| 5.7L || V8 || Gas ||OHV||Gen 1+ Chevrolet Small-Block V8. Vortec 5700. CPI.<br /> '96-'99 Chevy C/K, GMC Sierra, '96-'99 Chevy Tahoe/GMC Yukon, Chevy/GMC Suburban, '99-'00 GMC Yukon Denali, Cadillac Escalade, '00 Chevy Tahoe Limited/Z71, '96-'02 Chevy Express/GMC Savana.
|-
| R ||L8B|| 5.3L || V8 || Gas ||OHV||Mild Hybrid. Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management. '16-'18 Chevy Silverado 1500, GMC Sierra 1500.
|-
| S ||LQ7|| 2.2L || I4 || Diesel ||OHV||Isuzu C220 engine imported from Japan. '81-'82 Chevy LUV, '84-'85 Chevy S-10/GMC S-15
|-
| S ||L56|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks '94-'99,<br /> Chevy Blazer '94, Chevy Tahoe 2-d '95-'99, GMC Yukon 2-d '94-'97
|-
| S ||LL8|| 4.2L || I6 || Gas ||DOHC,<br /> 24 valve||Atlas I6. SFI. VVT. '02-'09 GMT360/370 SUVs (Chevy Trailblazer, GMC Envoy, Oldsmobile Bravada, Buick Rainier, Isuzu Ascender, Saab 9-7X)
|-
| S ||LGX|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. Direct Injection. VVT. Active Fuel Management.<br /> '17+ Cadillac XT5, '17-'23 GMC Acadia, '19+ Chevrolet Blazer, '20-'25 Cadillac XT6.
|-
| S ||LK0|| 2.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||L3B engine family. Direct Injection. VVT. '24- Chevy Traverse, GMC Acadia, '25- Buick Enclave
|-
| T ||L25|| 4.8L || I6 || Gas ||OHV||1-bbl carb. Chevrolet Turbo-Thrift I6. '81-'86 Chevy/GMC C/K pickups, '88 R/V pickups
|-
| T ||LM7|| 5.3L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads. Vortec 5300. 270/285/295hp.<br /> '99-'07 GMT800 pickups & SUVs including '02-'05 Escalade 2wd, '07 Silverado Classic 1500/<br> Sierra Classic 1500, '03-'07 Express/Savana
|-
| T ||LEA|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex Fuel. GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Orlando '13.
|-
| T ||LM2|| 3.0L || I6 Turbo|| Diesel ||DOHC,<br /> 24 valve|| Duramax Diesel I6. Aluminum Block & Heads. '20-'22 Silverado/Sierra 1500, '21-'24 Tahoe/Suburban, Yukon/Yukon XL, Escalade/Escalade ESV.
|-
| U ||LS5|| 1.6L || I4 || Gas ||SOHC,<br /> 8 valve||Suzuki G16A engine. TBI. '89-'95 Geo Tracker
|-
| U ||LQ4|| 6.0L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads (Iron Heads in '99-'00).<br /> '99-'06 GMT800 pickups, '07 Silverado Classic 1500HD/Sierra Classic 1500HD,<br> '00-'06 Suburban/Yukon XL 2500, '01-'06 Yukon Denali/Yukon XL Denali,<br> '06 Suburban LTZ, '03-'07 Express/Savana, '03-'07 Hummer H2.
|-
| U ||LE9|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. GM Ecotec Gen II. 2011 Chevy HHR
|-
| U ||LH7|| 1.6L ||I4 Turbo|| Diesel ||DOHC,<br /> 16 valve||GM Medium Diesel engine ("Whisper Diesel"). Made by Opel in Szentgotthárd, Hungary.<br /> Aluminum Block & Heads. '18-'19 Chevy Equinox & GMC Terrain Diesel.
|-
| V ||LR4|| 4.8L || V8 || Gas ||OHV||Gen III Chevrolet Small-Block V8. Iron Block/Aluminum Heads.<br> '99-'06 GMT800 pickups, '07 Silverado Classic 1500/Sierra Classic 1500,<br /> '00-'06 Tahoe/Yukon, '03-'07 Express/Savana
|-
| V ||LE9|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. GM Ecotec Gen II. 2009-2010 Chevy HHR
|-
| V ||LYX|| 1.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '18-'22 Chevy Equinox, GMC Terrain
|-
| W ||LE8|| 7.4L || V8 || Gas ||OHV|| Mark IV Chevrolet Big-Block V8. 4bbl carb. '81-'86 Chevy/GMC C/K pickups, Suburban.<br /> '88-'89 Chevy/GMC R30/3500 Chassis Cab w/C7C (10,500 lb. GVWR),<br /> V30/3500 Chassis Cab w/C7E (11,000 lb. GVWR)
|-
| W ||L35|| 4.3L || V6 || Gas ||OHV|| CPI. Vortec 4300 H.O. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '92-'95 Sonoma, S-10 Blazer/Jimmy, Astro/Safari, '94-'95 S-10, '92-'94 Oldsmobile Bravada
|-
| W ||L35|| 4.3L || V6 || Gas ||OHV|| SFI. Vortec 4300 H.O. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '96-'02 S-10/Sonoma, Blazer/Jimmy, Express/Savana, C/K, Silverado, Sierra, '96-'01 Bravada, Astro/Safari, '00 Isuzu Hombre
|-
| W ||LGD|| 3.9L || V6 || Gas/E85 ||OHV||Flex Fuel. GM High Value 60° V6. SFI. VVT. '07-'09 GMT201 minivans
|-
| W ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '10.
|-
| W ||LE8|| 2.2L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. SFI. GM Ecotec Gen II. VVT. 2011 Chevy HHR.
|-
| W ||LFY|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection.<br> '18-'23 Chevrolet Traverse, '24 Chevrolet Traverse Limited, '18-'24 Buick Enclave.
|-
| X ||LF6|| 4.3L || V6 || Gas ||OHV||SFI. Vortec 4300. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '96-'99 S-10/Sonoma, '97-'99 Isuzu Hombre.
|-
| X ||LU3|| 4.3L || V6 || Gas ||OHV||Vortec 4300. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '03-'04 S-10/Sonoma,<br /> '03-'05 Blazer/Jimmy, '02-'05 Astro/Safari, '03-'14 Express/Savana, '03-'13 Silverado/Sierra,<br> '07 Silverado Classic 1500/Sierra Classic 1500
|-
| X ||LNF|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. '08-'09 Chevy HHR SS.
|-
| X ||LTG|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. VVT.<br /> '16-'20 Buick Envision, '18-'20 Chevy Equinox, GMC Terrain, '18-'19 Chevy Traverse RS
|-
| Y ||LQ2|| 2.0L || I4 || Gas ||OHV||2-bbl carb. Chevrolet "122" engine.<br /> '83-'84 Chevy S-10/GMC S-15, '83-'84 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| Y ||L57|| 6.5L || V8 || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR full-size vans '94-'95 & '96 G-Classic full-size vans
|-
| Y ||L76|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevy Small-Block V8. Aluminum Block & Heads. VVT. With Active Fuel Management.<br /> '07-'09 Silverado/Sierra, Suburban/Yukon XL, Chevy Avalanche
|-
| Y ||LF1|| 3.0L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. VVT.<br /> '10-'11 Cadillac SRX, '11 Saab 9-4X, '10 Chevy Equinox, GMC Terrain
|-
| Y ||L5P|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '17+ Silverado HD/Sierra HD. Engine updated in '24.
|-
| Z ||LF9|| 5.7L || V8 || Diesel ||OHV||Oldsmobile Diesel V8. '81 Chevy C10/GMC C1500 full-size pickups.
|-
| Z ||LB4|| 4.3L || V6 || Gas ||OHV|| TBI. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '85-'87 Chevy El Camino/GMC Caballero,<br /> '86-'94 Astro/Safari, '87 R/V pickups, '88-'95 C/K & Sierra pickups, '87-'95 full-size vans & <br /> '96 G-Classic full-size vans, '88-'95 S-10, S-15/Sonoma, '88-'94 S-10 Blazer, S-15 Jimmy,<br /> '91-'92 Oldsmobile Bravada
|-
| Z ||LB4|| 4.3L || V6 Turbo || Gas ||OHV|| MPI. For GMC Syclone & Typhoon. Chevrolet 90° V6 (Chevy Small-Block V8 Derived)
|-
| Z ||L59|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads. Vortec 5300. 285/295hp.<br /> '02-'07 GMT800 pickups, '02-'06 Suburban/Yukon XL, Avalanche.
|-
| Z ||LAT|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||Mild Hybrid. MFI. GM Ecotec Gen II. VVT. '07-'09 Saturn Vue Green Line
|-
| 1 ||LZ9|| 3.9L || V6 || Gas ||OHV||GM High Value 60° V6. SFI. VVT. '06-'09 GMT201 minivans
|-
| 1 ||LE5|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||MFI. GM Ecotec Gen II. VVT. '10 Saturn Vue.
|-
| 1 ||LB7|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. First version of the Duramax V8. '01-Mid '04 Silverado HD/Sierra HD
|-
| 1 ||LWN|| 2.8L || I4 Turbo || Diesel ||DOHC,<br /> 16 valve||Based on VM Motori A428 engine. Made by GM Powertrain Thailand 2016-2020. Made in Brazil for '22. '16-'22 Colorado/Canyon, '17-'22 Express/Savana.
|-
| 2 ||LLY|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. Mid '04-Mid '06 Silverado HD/Sierra HD, '06-Mid '07 Express/Savana
|-
| 2 ||L9H|| 6.2L || V8 || Gas/E85 ||OHV||Flex-Fuel. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT.<br /> '09-'13 Chevy Silverado 1500, GMC Sierra 1500, Sierra Denali 1500,<br /> '09 Chevy Tahoe LTZ, GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV,<br> Hummer H2
|-
| 2 ||LIH|| 1.2L || I3 Turbo || Gas ||DOHC,<br /> 12 valve||GM E-Turbo Engine. Direct Injection. VVT.<br /> '20-'24 Buick Encore GX, '21-'24 Chevy Trailblazer, '24 Chevy Trax, Buick Envista,<br> '25 Chevy Trax, Buick Envista (Canada only).
|-
| 3 ||LC9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT added for '10. Aluminum Block & Heads.<br /> '07-'11 Silverado/Sierra 1500, Tahoe/Yukon, Suburban/Yukon XL 1500, '07-'09 & '11 Avalanche
|-
| 3 ||LFX|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. VVT. E85 Flex Fuel.<br /> '12-'16 Cadillac SRX, '13-'17 Chevrolet Equinox, GMC Terrain, '15-'16 Colorado/Canyon
|-
| 4 ||LN2|| 2.2L || I4 || Gas ||OHV||MFI (94-95). SFI (96-00). Chevrolet "122" engine. '94-'00 S-10/Sonoma, '96-'00 Isuzu Hombre
|-
| 4 ||LE8|| 2.5L || V6 || Gas ||DOHC,<br /> 24 valve||Suzuki H25A engine. MFI. '01-'04 Chevrolet Tracker
|-
| 4 ||L66|| 3.5L || V6 || Gas ||SOHC,<br /> 24 valve||Honda J35S1 V6. VTEC. '04-'07 Saturn Vue
|-
| 4 ||LMF|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '08-'14 Express/Savana 1500
|-
| 4 ||LAU|| 2.8L || V6 Turbo || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. SFI. '10 Cadillac SRX
|-
| 4 ||LSY|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. Active Fuel Management. VVT. VVL.<br /> '19-'25 Cadillac XT4, '20+ Chevy Blazer, Cadillac XT5, '20-'23 GMC Acadia,<br /> '21+ Buick Envision, '21-'25 Cadillac XT6
|-
| 5 ||L43|| 2.2L || I4 || Gas/E85 ||OHV||Flex-Fuel. SFI. Chevrolet "122" engine. '00-'02 S-10/Sonoma, '00 Isuzu Hombre
|-
| 5 ||LFA|| 6.0L || V8 || Gas-Electric Hybrid ||OHV||2-Mode Hybrid. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT. Active Fuel Management. '08-'09 Tahoe Hybrid/Yukon Hybrid, '09 Escalade Hybrid, Silverado Hybrid/Sierra Hybrid
|-
| 5 ||LFW|| 3.0L || V6 || Gas/E85 ||DOHC,<br /> 24 valve||Flex-Fuel. GM High Feature V6. Direct Injection. VVT. '11-'12 Chevy Equinox, GMC Terrain,<br /> '12 Chevy Captiva Sport
|-
| 6 ||L01|| 1.6L || I4 || Gas ||SOHC,<br /> 16 valve||Suzuki G16B engine. MFI. '94-'97 Geo Tracker, '98-'00 Chevrolet Tracker
|-
| 6 ||L52|| 3.5L || I5 || Gas ||DOHC,<br /> 20 valve||Atlas I5. SFI. VVT. '04-'06 Colorado/Canyon, '06 Isuzu i-350, '06 Hummer H3
|-
| 6 ||LAU|| 2.8L || V6 Turbo || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. SFI. '11 Cadillac SRX, Saab 9-4X
|-
| 6 ||LMM|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '07-'10 Silverado HD/Sierra HD (GMT900), Mid '07-Mid '10 Express/Savana
|-
| 7 ||LY7|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. '04-'06 Buick Rendezvous, '04-'09 Cadillac SRX,<br /> '07-'08 GMC Acadia, Saturn Outlook, '08 Buick Enclave, '08-'10 Saturn Vue
|-
| 7 ||LC9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT.<br /> Aluminum Block & Heads.<br /> '12-'13 Silverado/Sierra 1500, Avalanche, '12-'14 Tahoe/Yukon, Suburban/Yukon XL 1500
|-
| 7 ||L8T|| 6.6L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8. Iron Block/Aluminum Heads. Direct injection, VVT.<br /> '20+ Silverado HD/Sierra HD, '21+ Express/Savana
|-
| 8 ||LK5|| 2.8L || I4 || Gas ||DOHC,<br /> 16 valve||Atlas I4. SFI. VVT. '04-'06 Colorado/Canyon, '06 Isuzu i-280.
|-
| 8 ||L92|| 6.2L || V8 || Gas ||OHV||Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT.<br /> '07-'08 GMC Sierra Denali, Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV,<br> '08 Chevy Tahoe LTZ, Hummer H2.
|-
| 8 ||LML|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine.<br /> '11-'16 Silverado HD/Sierra HD pickups, '13-'16 Silverado HD/Sierra HD chassis cabs.
|-
| 8 ||LZ0|| 3.0L || I6 Turbo|| Diesel ||DOHC,<br /> 24 valve|| Duramax Diesel I6. Aluminum Block & Heads.<br> '23+ Silverado/Sierra 1500, '24+ Suburban HD, '25+ Tahoe/Suburban, Yukon/Yukon XL.
|-
| 9 ||LC3|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '83-'84 Chevy El Camino, GMC Caballero (49-state emissions).
|-
| 9 ||LLV|| 2.9L || I4 || Gas ||DOHC,<br /> 16 valve||Atlas I4. SFI. VVT. '07-'12 Colorado/Canyon, '07-'08 Isuzu i-290.
|-
| 9 ||LT4|| 6.2L ||V8 Supercharged|| Gas ||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. Direct injection. VVT. Active Fuel Management. '23+ Cadillac Escalade/Escalade ESV V-Series.
|-
| 0 ||LMG|| 5.3L || V8 || Gas/E85 ||OHV||Flex-Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT added for '10.<br /> Iron Block & Aluminum Heads.<br /> '07-'13 Silverado/Sierra 1500, Avalanche, '07-'14 Tahoe/Yukon, Suburban/Yukon XL 1500.
|}
H.O.=High Output, VVT=Variable Valve Timing, VVL=Variable Valve Lift, GVWR=Gross Vehicle Weight Rating, CNG=Compressed Natural Gas, LPG=Liquefied Petroleum Gas (Propane Autogas)
====Motor codes for electric light trucks====
{| class="wikitable"
|-
! VIN !! RPO !! Fuel !! Drive Wheels !! Application/Notes
|-
| H ||LN1|| Electricity || Front || '97-'98 Chevrolet S-10 Electric.
|-
|}
====Motor codes for Ultium-powered electric light trucks====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Module <br /> RPO code !! # of Modules !! Fuel !! Drive Wheels !! Application/Notes
|-
| A ||XRL|| 3 || ETN || 24 || Electricity || All || '22- GMC Hummer EV pickup 3X
|-
| B ||XRL|| 3 || ETI || 20 || Electricity || All || '24- GMC Hummer EV pickup 3X
|-
| C ||XRL|| 3 || ETJ || 20 || Electricity || All || '24- GMC Hummer EV SUV 3X
|-
| D ||XRJ|| 2 || ETI || 20 || Electricity || All || '24 Chevrolet Silverado EV 3WT, '25- Silverado EV 5WT, 3LT,<br> '25 Silverado EV RST (2SP), '26- Silverado EV Trail Boss (2TR),<br> '24- GMC Hummer EV pickup 2X, '25- GMC Sierra EV Denali 5SC,<br> '26- Sierra EV Elevation 3SC, AT4 4SC
|-
| E ||XRJ|| 2 || ETJ || 20 || Electricity || All || '24- GMC Hummer EV SUV 2X
|-
| G ||XRJ|| 2 || ETJ || 20 || Electricity || All || '23 BrightDrop Zevo 600
|-
| H ||XRJ|| 2 || EWX || 14 || Electricity || All ||'26- Chevrolet Silverado EV 4WT, 2LT,<br> '26- GMC Sierra EV Elevation 3SB, Denali 5SB
|-
| J ||X0C|| 2 || EC5 || 10 || Electricity || All || '24 Chevy Blazer EV 2LT, 1RS AWD,<br> '25- Chevy Blazer EV 4LT, 3RS AWD, '24-'26 Honda Prologue AWD
|-
| K ||X0D|| 1 || EC6 || 12 || Electricity || Rear || '23- Cadillac Lyriq RWD, '24-'25 Chevrolet Blazer EV 2RS RWD,<br> '24 Acura ZDX A-Spec RWD
|-
| L ||X0E|| 2 || EC6 || 12 || Electricity || All || '23- Cadillac Lyriq AWD, '24- Chevrolet Blazer EV PPV AWD,<br> '25- Chevrolet Blazer EV SS AWD, '26- Cadillac Vistiq AWD,<br> '24 Acura ZDX A-Spec, Type S AWD
|-
| L ||XRJ|| 2 || ETN || 24 || Electricity || All || '24 Chevrolet Silverado EV 4WT, RST (3SP), '25- Silverado EV 8WT,<br> '25 Silverado EV RST (3SP), '26- Silverado EV 4LT, Trail Boss (3TR),<br> '24- GMC Sierra EV Denali 5SD, '26- Sierra EV AT4 4SD,<br> '25- Cadillac Escalade IQ, '26- Cadillac Escalade IQL
|-
| M ||X0B|| 1 || EC5 || 10 || Electricity || Front || '24-'26 Honda Prologue FWD, '25- Chevy Blazer EV 2LT, 1RS FWD
|-
| P ||X0B|| 1 || EC3 || 10 || Electricity || Front || '24- Chevrolet Equinox EV FWD
|-
| R ||X0C|| 2 || EC3 || 10 || Electricity || All || '24- Chevrolet Equinox EV AWD, '25 Cadillac Optiq AWD
|-
| Y ||XRJ|| 2 || ETC || 12 || Electricity || All || '24 BrightDrop Zevo 400, Zevo 600,<br> '25-'26 Chevrolet BrightDrop 400/600 AWD
|-
| Z ||XRJ|| 2 || ETJ || 20 || Electricity || All || '24 BrightDrop Zevo 400, Zevo 600,<br> '25-'26 Chevrolet BrightDrop 400/600 AWD
|-
| 4 ||X0E|| 2 || EC3 || 10 || Electricity || All || '26- Cadillac Optiq AWD
|-
| 5 ||X0D|| 1 || EC3 || 10 || Electricity || Rear|| '26- Cadillac Optiq RWD
|-
| 6 ||XRM|| 1 || ETC || 12 || Electricity || Front || '25-'26 Chevrolet BrightDrop 400/600 FWD
|-
| 7 ||XRJ|| 2 || EWU || 14 || Electricity || All || '26 Chevrolet BrightDrop 600 AWD
|}
SB=Standard Range, SC=Extended Range, SD=Max Range
====Engine codes for medium duty trucks 2016-====
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes/Applications
|-
| B ||L96|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '16-'20 Chevy LCF 3500/4500.
|-
| C ||LC8|| 6.0L || V8 || Gas/CNG or<br>Gas/LPG ||OHV||Bi-Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '16-'20 Chevy LCF 3500/4500.
|-
| D ||L8T|| 6.6L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8. Iron Block/Aluminum Heads. Direct injection, VVT.<br /> '21-'23 Chevy LCF 3500/4500, '24- Chevy LCF 3500HG/4500HG/5500HG/5500XG.
|-
| F ||LCB|| 6.7L || I6 Turbo || Diesel ||OHV,<br /> 32 valve||Cummins B Series ISB engine. '22- Chevy LCF 6500XD, '23- Chevy LCF 7500XD.
|-
| 6 ||I1B|| 5.2L || I4 Turbo || Diesel ||SOHC,<br /> 16 valve||Isuzu 4HK1-TC engine. '17- Chevy LCF 4500HD/XD, 5500XD, '17-'24 Chevy LCF 5500HD,<br /> '18-'21 Chevy LCF 6500XD.
|-
| 7 ||IZ3|| 3.0L || I4 Turbo || Diesel ||DOHC,<br /> 16 valve||Isuzu 4JJ1-TC engine. '16-'18 Chevy LCF 3500HD.
|-
|}
====Engine codes for AM General-built Hummer H1 2000-2006====
AM General encodes the engine type in character 4 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| F || || 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8 built by GEP (General Engine Products), a subsidiary of AM General.<br> '01-'04 Hummer H1 & '06 H1 Fleet models.
|-
| P ||LLY|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '06 Hummer H1 Alpha.
|-
| Z ||L65|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8 built by GM. '00-'01 Hummer H1.
|-
|}
====Engine codes for Nissan-built vans====
Nissan encodes the engine type in character 4 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| 3 ||L0A|| 2.0L || I4 || Gas ||DOHC,<br /> 16 valve||Nissan MR20DE engine. SFI. VVT. For the '15-'18 Chevrolet City Express.
|-
|}
====Engine codes for Navistar-built medium-duty trucks====
Navistar encodes the engine type in character 6 & 7 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| PV ||L5D|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. For the Chevy Silverado Medium Duty '19+.
|-
|}
==GM factories supplying North America==
===North American GM factories===
[[w:List_of_General_Motors_factories | List of GM Factories]]
{| class="wikitable"
!VIN code
!Location
!Notes
|-
|A
|Lakewood Assembly (Lakewood Heights, Atlanta, Georgia)
|through 1990 model year
|-
|A
|Artisan Center (Warren, Michigan)
|From 2026 model year. Cadillac CT5-V Blackwing "Curated by Cadillac" program only.
|-
|B
|Baltimore Assembly (Baltimore, Maryland)
|through 2005 model year
|-
|B
|Reatta Craft Centre/Lansing Craft Centre (Lansing Township, Michigan)
|1988-2006 model year (except GM EV1)
|-
|B
|GM Defense-Manufacturing Customer Innovation Center (MCIC) (Concord, North Carolina)
|From 2024 model year. Chevrolet Suburban HD (a.k.a. HD SUV) (for US govt. only).
|-
|C
|South Gate Assembly (South Gate, California)
|through 1982 model year
|-
|C
|Lansing Car Assembly (Lansing, Michigan)
|South assembly line 1985-2004 model year
|-
|D
|Doraville Assembly (Doraville, Georgia)
|through 2009 model year
|-
|E
|Linden Assembly (Linden, New Jersey)
|through 1991 model year
|-
|E
|Pontiac East Assembly (Pontiac, Michigan)
|1988-2009 model year
|-
|E
|AM General Military plant (Mishawaka, Indiana)
|1992-2006 Hummer H1
|-
|F
|Flint Truck Assembly (Flint, Michigan)
|since 1953
|-
|F
|Fairfax II Assembly (Kansas City, Kansas)
|since 1988 model year
|-
|G
|Framingham Assembly (Framingham, Massachusetts)
|through 1989 model year
|-
|G
|Silao Assembly (Silao, Guanajuato, Mexico)
|since 1995 model year
|-
|H
|Buick City Assembly (Flint, Michigan)
|through 1999 model year
|-
|H
|AM General Commercial plant (Mishawaka, Indiana)
|2003-2009 Hummer H2
|-
|H
|Navistar Springfield plant (Main Line) (Springfield, Ohio)
|2019- Chevrolet Silverado Medium Duty (4500HD/5500HD/6500HD)
|-
|J
|Janesville Assembly (Janesville, Wisconsin)
|through 2009 model year
|-
|J
|Lansing Delta Township Assembly (Lansing, Michigan)
|since 2007 model year
|-
|K
|Leeds Assembly (Leeds, Kansas City, Missouri)
|through 1988 model year
|-
|K
|Linden Assembly (Linden, New Jersey)
|from 1994-2005 model year
|-
|K
|Nissan plant (Cuernavaca, Morelos, Mexico)
|2015-2018 Chevrolet City Express
|-
|L
|Van Nuys Assembly (Van Nuys, California)
|through 1992 model year
|-
|L
|San Luis Potosí Assembly (San Luis Potosí, Mexico)
|since 2009 model year
|-
|M
|Lansing Car Assembly (Lansing, Michigan)
|through 1984 model year, North assembly line 1985-2005 model year
|-
|M
|Toluca Assembly (Toluca, Mexico state, Mexico)
|through 2008 model year
|-
|N
|Norwood Assembly (Norwood, Ohio)
|through 1987 model year
|-
|N
|Navistar Springfield plant (Secondary Line) (Springfield, Ohio)
|2017- Chevrolet Express cutaway, GMC Savana cutaway
|-
|P
|Pontiac Assembly (Pontiac, Michigan)
|through 1988 model year
|-
|R
|Arlington Assembly (Arlington, Texas)
|since 1965 [all GM brands]. (R plant code used only by Chevrolet in 1963-64)
|-
|S
|St. Louis Assembly (St. Louis, Missouri)
|through 1987 model year
|-
|S
|Spring Hill Manufacturing (Spring Hill, Tennessee)
|2002-2007 Saturn Vue & 2009-2010 Chevrolet Traverse only
|-
|S
|Spartan Motors/Shyft Group plant (Charlotte, Michigan)
|2016- Chevrolet Low Cab Forward 3500/3500HG/4500/4500HG/5500HG/5500XG/6500XD/7500XD
|-
|S
|Ramos Arizpe Assembly (Ramos Arizpe, Coahuila, Mexico)
|since 1982
|-
|T
|Tarrytown Assembly (North Tarrytown, New York)
|through 1996 model year
|-
|U
|Detroit/Hamtramck Assembly (Factory Zero) <br /> (Detroit & Hamtramck, Michigan)
|since 1986 model year
|-
|U
|Artisan Center (Warren, Michigan)
|From 2025 model year. Cadillac Celestiq only.
|-
|V
|Pontiac Central Assembly (Pontiac, Michigan)
|through 1991 model year
|-
|V
|Pontiac East Assembly (Pontiac, Michigan)
|through 1985 model year
|-
|W
|Willow Run Assembly (Ypsilanti Township, Michigan)
|through 1993 model year
|-
|X
|Fairfax Assembly (Fairfax I) (Kansas City, Kansas)
|through 1987 model year
|-
|Y
|Wilmington Assembly (Wilmington, Delaware)
|through 2010 model year
|-
|Z
|Fremont Assembly (Fremont, California)
|through 1982 model year
|-
|Z
|NUMMI (Fremont, California)
|1985-2010 model year
|-
|Z
|Spring Hill Manufacturing (Spring Hill, Tennessee)
|since 1991 model year (except Vue & Traverse)
|-
|Z
|Fort Wayne Assembly (Roanoke, Indiana)
|since 1988 model year
|-
|0
|Pontiac West Assembly (Pontiac, Michigan)
|through 1994 model year
|-
|0
|Lansing Craft Centre (Lansing Township, Michigan)
|GM EV1 only
|-
|0
|Lansing Grand River Assembly (Lansing, Michigan)
|since 2003 model year
|-
|0
|Artisan Center (Warren, Michigan)
|2024 Cadillac CT5-V Blackwing 20th Anniversary Edition where the final eight digits of the VIN are R0912004 through R0912024 or R0962004 through R0962024
|-
|1
|Wentzville Assembly (Wentzville, Missouri)
|since 1985 model year
|-
|1
|Oshawa Car Assembly (Oshawa, Ontario, Canada)
|from 1967-1983 model year
|-
|1
|Oshawa Car Assembly (Line 2 a.k.a. Consolidated Line) (Oshawa, Ontario, Canada)
|from 1984-2019 model year; switched to pickup trucks for 2019 model year
|-
|1
|Oshawa Car Assembly (Oshawa, Ontario, Canada)
|Silverado pickup trucks since 2022 model year
|-
|1
|Oshawa Truck Assembly (Oshawa, Ontario, Canada)
|through 2009 model year
|-
|2
|Moraine Assembly (Moraine, Ohio)
|through 2009 model year
|-
|2
|Sainte-Thérèse Assembly (Boisbriand, Quebec, Canada)
|through 2002 model year
|-
|3
|Detroit Truck & Bus plant (Piquette Ave., Detroit, Michigan)
|through 1999 model year
|-
|3
|Saint-Eustache Bus Plant (Saint-Eustache, Quebec, Canada)
|through 1987 model year
|-
|4
|Orion Assembly (Orion Township, Michigan)
|since 1985 model year
|-
|4
|Scarborough Van Assembly (Scarborough, Ontario, Canada)
|through 1993 model year
|-
|5
|Bowling Green Assembly (Bowling Green, Kentucky)
|since 1981 model year
|-
|6
|Oklahoma City Assembly (Oklahoma City, Oklahoma)
|through 2006 model year
|-
|6
|CAMI plant (Ingersoll, Ontario, Canada)
|1990-2022 model year
|-
|7
|Lordstown Assembly (Warren, Ohio)
|from 1979-2019 model year
|-
|8
|Shreveport Assembly (Shreveport, Louisiana)
|through 2012 model year
|-
|9
|Detroit Assembly (Clark Street, Detroit, Michigan)<br> (Cadillac plant)
|from 1979-1988 model year
|-
|9
|Oshawa Car Assembly (Line 1 a.k.a. Flex Line)<br> (Oshawa, Ontario, Canada)
|from 1984-2020 model year
|-
|9
|KUKA plant (Livonia, Michigan)
|2022 model year only (BrightDrop Zevo 600)
|-
|9
|CAMI plant (Ingersoll, Ontario, Canada)
|2023-2026 model year (BrightDrop Zevo/Chevrolet BrightDrop)
|}
===Non-North American GM factories supplying North America===
{| class="wikitable"
!VIN code
!Location
!Models Sourced
|-
|A
|SAIC-GM plant: Jinqiao, Pudong district, Shanghai, China
|2017-2018 Cadillac CT6 Plug-in Hybrid
|-
|B
|Daewoo/GM Daewoo/GM Korea plant: Bupyeong, South Korea
|1988-1993 Pontiac LeMans, 2004-2011 Chevrolet Aveo, 2005-2010 Pontiac Wave/G3, 2004-2006 Chevrolet <br /> Epica (Canada), 2013-2022 Chevrolet Trax, Buick Encore, 2021- Chevrolet Trailblazer, 2020- Buick Encore GX, 2024- Buick Envista
|-
|C
|GM Daewoo/GM Korea plant: Changwon, South Korea
|2003-2010 Pontiac Matiz/Matiz G2 (Mexico), 2013-2022 Chevrolet Spark, 2024- Chevrolet Trax
|-
|D
|SAIC-GM Dongyue Motors plant: Yantai, Shandong province, China
|2016- Buick Envision, 2019-2023 Chevrolet Aveo (Mexico), 2023- Chevrolet Onix (Mexico)
|-
|G
|Opel plant: Gliwice, Poland
|2016-2019 Buick Cascada
|-
|K
|Suzuki plant: Kosai, Shizuoka prefecture, Japan
|1985-1988 Chevrolet Sprint, 1989-1990 Geo Metro hatchback, 1990-1993 Geo Metro convertible, 1985-1990 Pontiac Firefly (Canada), 1991 & 1994 Pontiac Firefly convertible & sedan (Canada)
|-
|K
|GM Daewoo/GM Korea plant: Kunsan, South Korea
|2004-2007 Chevrolet Optra (Canada), 2012-2014 Chevrolet Orlando (Canada)
|-
|L
|Holden plant: Elizabeth, South Australia, Australia
|2004-2006 Pontiac GTO, 2008-2009 Pontiac G8, 2011-2017 Chevrolet Caprice PPV, 2014-2017 Chevrolet SS
|-
|R
|Opel plant: Rüsselsheim, Germany
|1997-2001 Cadillac Catera
|-
|T
|GM India plant: Talegaon, Maharashtra, India
|2017-2021 Chevrolet Spark Classic/Beat (Mexico)
|-
|V
|SAIC-GM Wuhan plant: Wuhan, Hubei province, China
|2018-2021 Chevrolet Cavalier (Mexico), 2022- Chevrolet Cavalier Turbo (Mexico)
|-
|W
|Suzuki plant: Iwata, Shizuoka prefecture, Japan
|1989-1990 Geo Tracker
|-
|1
|Opel plant: Rüsselsheim, Germany
|2011, 2018-2020 Buick Regal
|-
|3
|Isuzu plant: Kawasaki, Kanagawa prefecture, Japan
|1987-1998 Chevrolet/GMC W5, 1989-1996 Chevrolet/GMC W6, 1984-1996 Chevrolet/GMC W7
|-
|5
|Opel plant: Antwerp, Belgium
|2008-2009 Saturn Astra
|-
|7
|Isuzu plant: Fujisawa, Kanagawa prefecture, Japan
|1988 Chevrolet Spectrum, 1988 Pontiac Sunburst (Canada), 1989 Geo Spectrum, 1990-1993 Geo Storm,<br /> 1999-2008 Chevrolet/GMC W3500, 1988-2009 Chevrolet/GMC W4, 1999-2009 Chevrolet/GMC W5,<br /> 2000-2004 Chevrolet/GMC WT5500,<br /> 2016- Chevrolet Low Cab Forward 3500HD/4500HD/4500XD/5500HD/5500XD
|-
|8
|Isuzu plant: Fujisawa, Kanagawa prefecture, Japan
|1981-1982 Chevrolet LUV, 1985-1987 Chevrolet Spectrum, 1985-1987 Pontiac Sunburst (Canada),<br /> 1986-1987 Chevrolet/GMC W4
|}
==GM WMIs==
{| class=wikitable
!WMI
!Marque
!Country
|-
|1G1||rowspan=57|Chevrolet||United States
|-
|1G8||United States (MPV 1981-1986)
|-
|1GA||United States (bus [van with more than 3 rows of seats])
|-
|1GB||United States (incomplete vehicle)
|-
|1GC||United States (truck)
|-
|1GN||United States (MPV 1987-)
|-
|1HA||United States (Express incomplete vehicle made by Navistar)
|-
|1HT||United States ([[w:Chevrolet Silverado#Medium duty version_(4500HD,_5500HD,_6500HD,_and_International_CV)|Silverado Medium Duty]] incomplete vehicle made by Navistar)
|-
|1Y1||United States (made by NUMMI)
|-
|2C1||Canada (car made by CAMI)
|-
|2CN||Canada (SUV made by CAMI - 1998-2011)
|-
|2G1||Canada
|-
|2G5||Canada (truck - Chevrolet BrightDrop '25)
|-
|2G8||Canada (MPV 1981-1986)
|-
|2GA||Canada (bus [van with more than 3 rows of seats])
|-
|2GB||Canada (incomplete vehicle)
|-
|2GC||Canada (truck - includes Chevrolet BrightDrop '26)
|-
|2GN||Canada (MPV 1987-)
|-
|3G1||Mexico
|-
|3GC||Mexico (truck)
|-
|3GN||Mexico (MPV)
|-
|3N6||Mexico (Truck - City Express made by Nissan)
|-
|4G1||United States (made by Genasys L.C.)
|-
|4KB||United States (W-Series incomplete vehicle made by GM - through 2009)
|-
|4W1||United States (MPV - Chevrolet Suburban HD made for US govt. in Concord, NC)
|-
|54D||United States (incomplete vehicle made by Spartan Motors/The Shyft Group)
|-
|6G1||Australia (2011-2013 Caprice PPV)
|-
|6G3||Australia (2014-2017 Caprice PPV & SS performance sedan)
|-
|ADM||South Africa
|-
|J81||Japan (car made by Isuzu)
|-
|J8B||Japan (incomplete vehicle made by Isuzu - through 2009)
|-
|J8Z||Japan (LUV pickup made by Isuzu)
|-
|JAL||Japan (incomplete vehicle made by Isuzu - 2016+)
|-
|JG1||Japan (car made by Suzuki)
|-
|KL1||South Korea (car)
|-
|KL7||South Korea (MPV - 2012+)
|-
|KL8||South Korea (Spark)
|-
|LSF||China (S-10 Max made by SAIC-Maxus - Mexico only)
|-
|LSG||China (SAIC-GM)
|-
|LSH||China (Express Max made by SAIC-Maxus - Mexico only)
|-
|LZW||China (SAIC-GM-Wuling)
|-
|MA6||India
|-
|MJB||Indonesia (GM Indonesia)
|-
|MK3||Indonesia (SGMW Motor Indonesia)
|-
|MMM||Thailand
|-
|XUF||Russia (GM Russia - St. Petersburg plant)
|-
|XUU||Russia (Chevrolet Korea models made by Avtotor in Kaliningrad)
|-
|XWB||Uzbekistan (GM Uzbekistan, UzAuto Motors)
|-
|XWF||Russia (Chevrolet Tahoe & Trailblazer [GMT360] made by Avtotor in Kaliningrad)
|-
|X9L||Russia (GM-AvtoVAZ)
|-
|8AG||Argentina
|-
|8GG||Chile
|-
|8LD||Ecuador
|-
|8Z1||Venezuela
|-
|9BG||Brazil
|-
|93C||Brazil
|-
|9GC||Colombia
|-
|J81||rowspan=6|Geo||Japan (car made by Isuzu)
|-
|JG1||Japan (car made by Suzuki)
|-
|JGC||Japan (SUV made by Suzuki)
|-
|1Y1||United States (car made by NUMMI)
|-
|2C1||Canada (car made by CAMI)
|-
|2CN||Canada (SUV made by CAMI - 1990-1997)
|-
|KLA||rowspan=3|GM Daewoo/<br />GM Korea||South Korea (Bupyeong & Kunsan plants)
|-
|KLY||South Korea (Changwon plant)
|-
|5GD||United States (G2X)
|-
|1G2||rowspan=12|Pontiac||United States
|-
|1G5||United States (incomplete vehicle - for '89-'90 Turbo Grand Prix by ASC/McLaren & '03-'05 Montana Mobility, '06 Montana SV6 Mobility)
|-
|1GM||United States (MPV)
|-
|2CK||Canada (2006-2009 Torrent made by CAMI)
|-
|2G2||Canada
|-
|2G7||Canada (US market 1983 Pontiac Parisienne)
|-
|3G2||Mexico
|-
|3G7||Mexico (MPV: 2001-2005 Aztek)
|-
|4G2||United States (made by Genasys L.C.)
|-
|5Y2||United States (made by NUMMI)
|-
|6G2||Australia
|-
|KL2||South Korea (made by Daewoo/GM Daewoo)
|-
|1G7||rowspan=6|Pontiac<br />(Canada only)||United States
|-
|2C7||Canada (car made by CAMI)
|-
|2CG||Canada (SUV made by CAMI)
|-
|2G7||Canada
|-
|J87||Japan (car made by Isuzu)
|-
|JG7||Japan (car made by Suzuki)
|-
|KL7||Passport<br />(Canada only)||South Korea (car made by Daewoo)
|-
|J87||rowspan=3|Asüna<br />(Canada only)||Japan (car made by Isuzu)
|-
|KL7||South Korea (car made by Daewoo)
|-
|2CG||Canada (SUV made by CAMI)
|-
|1G3||rowspan=3|Oldsmobile||United States
|-
|1GH||United States (MPV/SUV)
|-
|2G3||Canada
|-
|1G4||rowspan=9|Buick||United States
|-
|2G4||Canada
|-
|3G4||Mexico
|-
|3G5||Mexico (MPV)
|-
|4GL||United States (incomplete vehicle)
|-
|5GA||United States (MPV)
|-
|KL4||South Korea (MPV)
|-
|LRB||China (SAIC-GM)
|-
|W04||Germany & Poland
|-
|KLA||Alpheon||South Korea (2011-2015)
|-
|1G6||rowspan=10|Cadillac||United States
|-
|1GE||United States (incomplete vehicle)
|-
|1GY||United States (SUV)
|-
|2G6||Canada
|-
|2GE||Canada (incomplete vehicle)
|-
|3GY||Mexico (SUV)
|-
|LRE||China (SAIC-GM)
|-
|W06||Germany
|-
|XWF||Russia (made by Avtotor in Kaliningrad)
|-
|YSC||Sweden
|-
|1G8||rowspan=4|Saturn||United States
|-
|3GS||Mexico (SUV)
|-
|5GZ||United States (MPV/SUV)
|-
|W08||Belgium
|-
|1G0||rowspan=22|GMC||United States (bus 1981-1986)
|-
|1G5||United States (MPV 1981-1986)
|-
|1GD||United States (incomplete vehicle)
|-
|1GJ||United States (bus 1987-)
|-
|1GK||United States (MPV 1987-)
|-
|1GT||United States (truck)
|-
|2CK||Canada (1990-1991 Tracker made by CAMI - Canada only)
|-
|2CT||Canada (2010-2011 Terrain made by CAMI)
|-
|2G0||Canada (bus [van with more than 3 rows of seats] 1981-1986)
|-
|2G5||Canada (MPV 1981-1986)
|-
|2GD||Canada (incomplete vehicle)
|-
|2GH||Canada (transit bus)
|-
|2GJ||Canada (bus [van with more than 3 rows of seats] 1987-)
|-
|2GK||Canada (MPV 1987-)
|-
|2GT||Canada (truck)
|-
|3GK||Mexico (SUV)
|-
|3GT||Mexico (truck)
|-
|4KD||United States (W-Series incomplete vehicle made by GM - through 2009)
|-
|7GZ||United States (incomplete vehicle made by Navistar)
|-
|J8D||Japan (incomplete vehicle made by Isuzu - through 2009)
|-
|JGT||Japan (SUV made by Suzuki - Canada only)
|-
|KL6||South Korea (Middle East market Terrain '08-'10)
|-
|4GD||WhiteGMC||United States (1988-1989 Brigadier made by GM)
|-
|137||rowspan=6|Hummer||United States (H1 made by AM General)
|-
|5GN||United States (H3T)
|-
|5GR||United States (H2 made by AM General)
|-
|5GT||United States (H3)
|-
|ADM||South Africa (H3)
|-
|XWF||Russia (H2 & H3 made by Avtotor in Kaliningrad)
|-
|4G5||General Motors||United States (EV1)
|-
|2G5||rowspan=2|BrightDrop||Canada (Truck 2023-2024)
|-
|5G5||United States (Truck made by Kuka AG - 2022 only)
|-
|5G2||rowspan=2|Cruise||United States (car) (Cruise AV)
|-
|5G3||United States (MPV) (Cruise Origin AV)
|-
|YS3||rowspan=4|Saab||Sweden
|-
|JF4||Japan (9-2X made by Subaru)
|-
|3G0||Mexico (9-4X)
|-
|5S3||United States (9-7X)
|-
|W0L||rowspan=19|Opel/Vauxhall||Germany & the rest of Europe (2017 and earlier)
|-
|W0V||Germany & the rest of Europe (2018 and later) & Opel Ampera-e Mid-2017 - 2019
|-
|W0L||when plant code is H: Thailand (Zafira A)
|-
|W0L||when plant code is 0: South Korea (Antara) or B: South Korea (Antara, Mokka A, Mokka X [A])
|-
|W0L||when plant code is C: South Korea (Opel Karl/Vauxhall Viva)
|-
|W0V||when plant code is B: South Korea (Mokka X [A]) or C: South Korea (Opel Karl/Vauxhall Viva)
|-
|SCC||UK (Opel Lotus Omega made by Lotus)
|-
|SED||UK (made by IBC Vehicles)
|-
|TW8||Portugal
|-
|VF1||France (Arena made by Renault)
|-
|VN1||France (Movano A made by Renault at SOVAB plant in Batilly, France)
|-
|VSX||Spain
|-
|XUF||Russia (Opel made by GM Russia - St. Petersburg plant)
|-
|XWF||Russia (Opel made by Avtotor in Kaliningrad)
|-
|1G0||United States (Opel GT, Opel/Vauxhall Ampera, Opel Ampera-e Early - Mid-2017)
|-
|4GD||United States (Sintra)
|-
|ADM||South Africa
|-
|JAA||Japan (Opel Campo made by Isuzu)
|-
|JAC||Japan (Monterey made by Isuzu)
|-
|SKA||rowspan=4|Vauxhall Motors||UK
|-
|SCC||UK (Vauxhall Lotus Carlton made by Lotus)
|-
|6G1||Australia (Vauxhall Monaro & VXR8 made by Holden)
|-
|JAA||Japan (Vauxhall Brava made by Isuzu)
|-
|SKF||rowspan=2|Bedford Vehicles||UK
|-
|JAA||Japan (Bedford Brava made by Isuzu)
|-
|6G1||rowspan=18|Holden||Australia (2003-2017)
|-
|6H8||Australia (1989-2002)
|-
|JAA||Japan (Rodeo pickup [TF] made by Isuzu)
|-
|JAC||Japan (Jackaroo/Monterey made by Isuzu)
|-
|JSA||Japan (YG Cruze made by Suzuki)
|-
|KL3||South Korea
|-
|MMM||Thailand ('09-'11 Colorado pickup [RC] made by GM Thailand)
|-
|MMU||Thailand ('13-'20 Colorado pickup [RG], '13-'16 Colorado 7, '17-'20 Trailblazer made by GM Thailand)
|-
|MPA||Thailand ('04-'08 Rodeo pickup [RA] made by Isuzu Thailand)
|-
|SED||UK (1st gen. Frontera made by IBC Vehicles)
|-
|W0L||Germany & the rest of Europe (2017 and earlier)
|-
|W0L||when plant code is H: Thailand (Zafira A)
|-
|W0V||Germany & the rest of Europe (2018-2020)
|-
|1GH||United States (Acadia)
|-
|3G0||Mexico (Equinox)
|-
|3GM||Mexico (Suburban)
|-
|4S2||United States (2nd gen. Frontera made by [[w:Subaru Isuzu Automotive|SIA]])
|-
|5G8||United States (Volt)
|-
|1GG||rowspan=4|Isuzu||United States (Truck - Hombre & i-Series made by GM)
|-
|4GT||United States (H-Series & T-Series incomplete vehicle made by GM - through 2009)
|-
|4KL||United States (N-Series incomplete vehicle made by GM - through 2009)
|-
|4NU||United States (MPV/SUV - Ascender made by GM)
|-
|W0L||Subaru||Thailand [plant code H] (Traviq made by GM Thailand for export to Japan)
|-
|4G3||Toyota||United States (Cavalier made by GM for export to Japan)
|-
|3GP||Honda||Mexico (MPV/SUV: 2024-2026 Prologue made by GM)
|-
|4W5||Acura||United States (MPV/SUV: 2024 ZDX EV made by GM)
|}
{{BookCat}}
luwm14atlhsof0f6a92ikkx9bzhoago
4655961
4655958
2026-07-31T19:52:07Z
JustTheFacts33
3434282
/* Engine codes for light trucks */
4655961
wikitext
text/x-wiki
{{Vehicle Identification Numbers (VIN codes)/Warning}}{{clear}}
It is the tenth digit that gives you the model year for GM. I've been working at a Chevy dealer for years running codes/vins. For example (my examples only apply to 2001-2015 gm vehicles)
Remember 10th digit from the beginning, (left to right).
2001... 1,
2002...2,
2003...3,
etc.,
2009...9.
After 2009, the tenth digit was given a letter
2010... A,
2011...B,
2012...C,
2013...D,
2014...E,
2015...F,
Etc...
We have another 20 years worth of letters.
Thanks for reading.
You can always check your model year by looking in your drivers side door jamb and it will give you model year. If it was assembled in July or later, the model year is probably a year later than the calendar year of the manufacturing date listed.
==American GM==
===American VIN format 1981-1984 Passenger Car===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>A</td><td></td><td></td><td>[[#American restraint types 1981-1984|Restraint type]]</td>
</tr><tr>
<td>5</td>
<td>M</td><td></td><td></td><td>[[#Car Line & Series Code 1981-1984|Car Line & Series Code]]</td>
</tr><tr>
<td>6</td>
<td>4</td><td></td><td></td><td rowspan=2>[[#Body style codes 1981-1986|Body style]]</td>
</tr><tr>
<td>7</td>
<td>7</td><td></td><td></td><td> </td>
</tr><tr>
<td>8</td>
<td>8</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>E</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>9</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====American restraint types 1981-1984====
The restraint type is specified as character 4 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|A||Manual Seatbelts only - No Passive Restraint
|}
====Car Line & Series Code 1981-1984====
The Car Line & Series Code is specified as character 5 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!List of GM platforms
!Car Line & <br> Series Code
!:Category:General Motors vehicles|Model
|-
|rowspan=19|GM A platform - rear-wheel drive
|T||Chevrolet Malibu 1981
|-
|W||Chevrolet Malibu Classic 1981
|-
|Z||Chevrolet Monte Carlo 1981
|-
|D||Pontiac LeMans 1981
|-
|F||Pontiac Grand LeMans 1981
|-
|J||Pontiac Grand Prix 1981
|-
|K||Pontiac Grand Prix LJ 1981
|-
|P||Pontiac Grand Prix Brougham 1981
|-
|G||Oldsmobile Cutlass sedan, Cutlass Cruiser wagon 1981
|-
|H||Oldsmobile Cutlass Cruiser ''Brougham'' wagon 1981
|-
|K||Oldsmobile Cutlass Calais coupe 1981
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1981
|-
|R||Oldsmobile Cutlass Supreme coupe, Cutlass LS sedan 1981
|-
|E||Buick Century wagon 1981
|-
|H||Buick Century sedan, Estate wagon 1981
|-
|J||Buick Regal 1981
|-
|K||Buick Regal ''Sport'' 1981
|-
|L||Buick Century ''Limited'' 1981
|-
|M||Buick Regal ''Limited'' 1981
|-
|rowspan=10|GM A platform - front-wheel drive
|W||Chevrolet Celebrity 1982-1984
|-
|F||Pontiac 6000 1982-1984
|-
|G||Pontiac 6000 ''LE'' 1982-1984
|-
|H||Pontiac 6000 ''STE'' 1983-1984
|-
|G||Oldsmobile Cutlass Ciera 1982
|-
|J||Oldsmobile Cutlass Ciera ''LS'' 1982-1984, Cutlass Cruiser ''LS'' 1984
|-
|M||Oldsmobile Cutlass Ciera ''Brougham'' 1982-1984
|-
|G||Buick Century ''T-Type'' 1983-1984
|-
|H||Buick Century ''Custom'' 1982-1984
|-
|L||Buick Century ''Limited'' 1982-1984
|-
|rowspan=19|GM B platform
|D||Chevrolet Bel Air 1981 (Canada only)
|-
|L||Chevrolet Impala 1981-1984
|-
|N||Chevrolet Caprice Classic 1981-1984
|-
|F||Pontiac Laurentian 1981 (Canada only)
|-
|L||Pontiac Catalina 1981, Parisienne 1984
|-
|L||Pontiac Parisienne 1982-1983 (Canada only)
|-
|N||Pontiac Bonneville 1981
|-
|N||Pontiac Parisienne 1981, Parisienne Brougham 1982-1983 (Canada only)
|-
|R||Pontiac Bonneville Brougham 1981
|-
|T||Pontiac Parisienne Brougham 1984
|-
|L||Oldsmobile Delta 88 1981-1983
|-
|N||Oldsmobile Delta 88 Royale 1981-1984
|-
|P||Oldsmobile Custom Cruiser 1981-1984
|-
|V||Oldsmobile Delta 88 Royale Brougham LS 1984
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1981-1984
|-
|N||Buick Le Sabre 1981, Le Sabre ''Custom'' 1982-1984
|-
|P||Buick Le Sabre ''Limited'' 1981-1984
|-
|R||Buick Le Sabre Estate Wagon 1981-1983
|-
|V||Buick Electra Estate Wagon 1981-1984
|-
|rowspan=13|GM C platform - rear-wheel drive
|G||Oldsmobile 98 Regency 1984
|-
|H||Oldsmobile 98 Regency Brougham 1984
|-
|V||Oldsmobile 98 Luxury 1981
|-
|W||Oldsmobile 98 Regency Brougham 1982-1983
|-
|X||Oldsmobile 98 Regency 1981-1983
|-
|R||Buick Electra Limited 1984
|-
|U||Buick Electra Park Avenue 1984
|-
|W||Buick Electra Park Avenue 1981-1983
|-
|X||Buick Electra Limited 1981-1983
|-
|B||Cadillac Fleetwood Brougham 1981-1983
|-
|D||Cadillac DeVille 1981-1983
|-
|M||Cadillac DeVille 1984
|-
|W||Cadillac Fleetwood Brougham 1984
|-
|rowspan=1|GM D platform - rear-wheel drive
|F||Cadillac Fleetwood Limousine 1981-1984
|-
|rowspan=4|GM E platform
|Z||Oldsmobile Toronado Brougham 1981-1984
|-
|Y||Buick Riviera T-Type 1981-1984
|-
|Z||Buick Riviera 1981-1984
|-
|L||Cadillac Eldorado 1981-1984
|-
|rowspan=7|GM F platform
|P||Chevrolet Camaro Sport Coupe 1981-1984
|-
|S||Chevrolet Camaro Berlinetta 1981-1984
|-
|S||Pontiac Firebird 1981-1984
|-
|T||Pontiac Firebird ''Esprit'' 1981
|-
|V||Pontiac Firebird ''Formula'' 1981
|-
|W||Pontiac Firebird ''Trans Am'' 1981-1984
|-
|X||Pontiac Firebird ''Trans Am'' Turbo Special Edition 1981, Firebird ''S/E'' 1982-1984
|-
|rowspan=15|GM G platform - rear-wheel drive
|W||Chevrolet Malibu Classic 1982, Malibu 1983
|-
|Z||Chevrolet Monte Carlo 1982-1984
|-
|J||Pontiac Grand Prix 1982-1984
|-
|K||Pontiac Grand Prix LJ 1982-1983, Grand Prix LE 1984
|-
|N||Pontiac Bonneville G 1982-1984
|-
|P||Pontiac Grand Prix Brougham 1982-1984
|-
|R||Pontiac Bonneville G Brougham 1982-1984
|-
|S||Pontiac Bonneville G ''LE'' 1984
|-
|H||Oldsmobile Cutlass Cruiser wagon 1982-1983
|-
|K||Oldsmobile Cutlass Calais coupe 1982-1984
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1982-1984
|-
|R||Oldsmobile Cutlass Supreme coupe & sedan 1982-1984
|-
|J||Buick Regal 1982-1984
|-
|K||Buick Regal ''Sport'' 1982, Regal ''T-Type'' 1983-1984
|-
|M||Buick Regal ''Limited'' 1982-1984
|-
|rowspan=13|GM J platform
|C||Chevrolet Cavalier 1983-1984
|-
|D||Chevrolet Cavalier 2-d/4-d/wagon 1982, Cavalier CS 1983-1984
|-
|E||Chevrolet Cavalier 3-door hatchback 1982, Cavalier CS 3-door hatchback 1983, Cavalier Type 10 2-d/3-d/Convertible 1984
|-
|B||Pontiac J2000 1982, 2000 1983, 2000 Sunbird 1984
|-
|C||Pontiac J2000 LE 1982, 2000 LE 1983, 2000 Sunbird LE Convertible 1983, 2000 Sunbird LE 1984
|-
|D||Pontiac J2000 SE 1982, 2000 SE 1983, 2000 Sunbird SE 1984
|-
|E||Pontiac J2000 S 1982
|-
|C||Oldsmobile Firenza Base model 1982-1984, Firenza S 1982-1984
|-
|D||Oldsmobile Firenza LX 1982-1984, Firenza SX 1982-1984
|-
|E||Buick Skyhawk T-Type 1983-1984
|-
|S||Buick Skyhawk Custom 1982-1984
|-
|T||Buick Skyhawk Limited 1982-1984
|-
|G||Cadillac Cimarron 1982-1984
|-
|rowspan=1|GM K platform
|S||Cadillac Seville 1981-1984
|-
|rowspan=3|GM P platform
||E||Pontiac Fiero ''Coupe'' 1984
|-
||F||Pontiac Fiero ''SE'' 1984
|-
||M||Pontiac Fiero ''Sport coupe'' 1984
|-
|rowspan=6|GM T platform - rear-wheel drive
|B||Chevrolet Chevette 1981-1983, Chevette CS 1984
|-
|J||Chevrolet Chevette Scooter 1981-1983, Chevette 1984
|-
|B||Pontiac Acadian 1981-1984 (Canada only)
|-
|J||Pontiac Acadian S 1981-1982, Pontiac Acadian Scooter 1983-1984 (Canada only)
|-
|L||Pontiac T1000 1982, 1000 1983-1984
|-
|M||Pontiac T1000 1981
|-
|rowspan=10|GM X platform
|H||Chevrolet Citation 2-door coupe 1982-1983, Citation II 2-door coupe 1984
|-
|X||Chevrolet Citation hatchback 1981-1983, Citation II hatchback 1984
|-
|T||Pontiac Phoenix SJ 1982-1983, Phoenix SE 1984
|-
|Y||Pontiac Phoenix 1981-1984
|-
|Z||Pontiac Phoenix LJ 1981-1983, Phoenix LE 1984
|-
|B||Oldsmobile Omega 1981-1984
|-
|E||Oldsmobile Omega Brougham 1981-1984
|-
|B||Buick Skylark 1981-1982, Skylark Custom 1983-1984
|-
|C||Buick Skylark Limited 1981-1984
|-
|D||Buick Skylark Sport 1981-1982, Skylark T-Type 1983-1984
|-
|rowspan=1|GM Y platform
|Y||Chevrolet Corvette 1981-1982, 1984
|}
===American VIN format 1985-1986 Passenger Car===
GM has traditionally encoded the platform as the 4th character of the VIN. Other content includes an engine code and manufacturing plant. GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>D</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Platform]]</td>
</tr><tr>
<td>5</td>
<td>W</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Series Code]]</td>
</tr><tr>
<td>6</td>
<td>6</td><td></td><td></td><td rowspan=2>[[#Body style codes 1981-1986|Body style]]</td>
</tr><tr>
<td>7</td>
<td>9</td><td></td><td></td><td> </td>
</tr><tr>
<td>8</td>
<td>Y</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>G</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>9</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====Body style codes 1981-1986====
The Body type is specified as characters 6 and 7 of the American GM VIN for passenger cars from 1981-1986.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|11,27,37,47,57,97||Two-Door Coupe/Sedan
|-
|07,08,77,87||Two-Door Hatchback
|-
|67||Two-Door Convertible
|-
|19,69||Four-Door Sedan
|-
|68||Four-Door Hatchback
|-
|23||Four-Door Limousine, 8-passenger ("Limousine")
|-
|33||Four-Door Limousine w/Center Partition, 7-passenger ("Formal Limousine")
|-
|35||Four-Door Station Wagon
|}
===American VIN format 1987- Passenger Car===
GM has traditionally encoded the platform as the 4th character of the VIN. Other content includes an engine code and manufacturing plant. GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>D</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Platform]]</td>
</tr><tr>
<td>5</td>
<td>M</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Series Code]]</td>
</tr><tr>
<td>6</td>
<td>5</td><td></td><td></td><td>[[#Body style codes 1987- Passenger Car|Body style]]</td>
</tr><tr>
<td>7</td>
<td>7</td><td></td><td></td><td>[[#American restraint types 1987-|Restraint type]]</td>
</tr><tr>
<td>8</td>
<td>N</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>3</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>0</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
===American VIN format 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>K</td><td></td><td></td></tr><tr>
<td>4</td>
<td>E</td><td></td><td></td><td>[[#GVWR/Brake System 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|GVWR/Brake System]]</td>
</tr><tr>
<td>5</td>
<td>K</td><td></td><td></td><td>[[#Line & Chassis Type 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 1981-1999]]</td>
</tr><tr>
<td>5</td>
<td>K</td><td></td><td></td><td>[[#Line & Chassis Type 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 2000-2009]]</td>
</tr><tr>
<td>6</td>
<td>1</td><td></td><td></td><td>[[#Series 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle|Series]]</td>
</tr><tr>
<td>7</td>
<td>8</td><td></td><td></td><td>[[#Body style codes 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|Body type]]</td>
</tr><tr>
<td>8</td>
<td>K</td><td></td><td></td><td>[[#Engine codes for light trucks|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>N</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>J</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====GVWR/Brake System 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The GVWR/Brake System is specified as character 4 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!GVWR Range in lbs. & Weight Class
!Brake System
|-
|A||Class A: 0-3,000||Hydraulic
|-
|B||Class B: 3,001-4,000||Hydraulic
|-
|C||Class C: 4,001-5,000||Hydraulic
|-
|D||Class D: 5,001-6,000||Hydraulic
|-
|E||Class E: 6,001-7,000||Hydraulic
|-
|F||Class F: 7,001-8,000||Hydraulic
|-
|G||Class G: 8,001-9,000||Hydraulic
|-
|H||Class H: 9,001-10,000||Hydraulic
|-
|J||Class 3: 10,001-14,000||Hydraulic
|-
|K||Class 4: 14,001-16,000||Hydraulic
|-
|L||Class 5: 16,001-19,500||Hydraulic
|}
====Line & Chassis Type 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|B||Special Body Buick, Chevrolet
|-
|C||Chevy full-size pickups & chassis cabs 2wd (C-series) '81-'86, '88-'99,<br /> GMC full-size pickups & chassis cabs 2wd (C-series) '81-'86, Sierra 2wd (C-series) '88-'99
|-
|C||Chevy C10 Blazer 2wd ('81-'82), Tahoe 4-door 2wd ('95-'99), Suburban 2wd ('81-'86, '92-'99),<br /> GMC C1500 Jimmy 2wd ('81-'82), Yukon 4-door 2wd ('95-'99), Suburban 2wd ('81-'86, '92-'99)
|-
|D||Military Truck 4wd
|-
|E||'91-'97 Geo Tracker 2wd, '98-'99 Chevrolet Tracker 2wd
|-
|E||'97-'98 Chevy S-10 EV
|-
|G||Chevy/GMC full-size vans (Chevy Van, Sportvan, Express, GMC Vandura, Rally Van, Savana)
|-
|H||'93-'96 Chevy G30HD/GMC G3500HD cutaway van
|-
|H||Cadillac chassis cutaway/special body (Based on Rwd Fleetwood '93-'96, Fwd DeVille '97-'99)
|-
|J||'89-'97 Geo Tracker 4wd, '98-'99 Chevrolet Tracker 4wd
|-
|K||Chevy full-size pickups & chassis cabs 4wd (K-series) '81-'86, '88-'99,<br /> GMC full-size pickups & chassis cabs 4wd (K-series) '81-'86, Sierra 4wd (K-series) '88-'99
|-
|K||Chevy K10/K5 Blazer 4wd ('81-'86, '92-'94), Tahoe 4wd ('95-'99), Suburban 4wd ('81-'86, '92-'99),<br /> GMC K1500 Jimmy 4wd ('81-'86), Yukon 4wd ('92-'99), Suburban 4wd ('81-'86, '92-'99), '99 Cadillac Escalade 4wd
|-
|L||Chevy Luv 2wd '81-'82
|-
|L||Chevy Astro/GMC Safari 4wd '90-'99
|-
|M||Chevy Astro/GMC Safari 2wd '85-'99
|-
|P||Forward Control (includes Chevrolet Step-Van/GMC Value-Van, Chevy/GMC P-Series)
|-
|R||Chevy Luv 4wd '81-'82
|-
|R||Chevy full-size pickups & chassis cabs 2wd (R-series), Suburban 2wd '87-'91,<br /> GMC full-size pickups & chassis cabs 2wd (R-series), Suburban 2wd '87-'91
|-
|S||Chevy S-10 2wd ('82-'99), S-10 Blazer 2wd ('83-'94), Blazer 2wd ('95-'99), GMC S-15 2wd ('82-'90), Sonoma 2wd ('91-'99),<br> S-15 Jimmy 2wd ('83-'91), Jimmy 2wd ('92-'99), Isuzu Hombre 2wd ('96-'99)
|-
|T||Chevy S-10 4wd ('83-'99), S-10 Blazer 4wd ('83-'94), Blazer 4wd ('95-'99), GMC S-15 4wd ('83-'90), Sonoma 4wd ('91-'99), Syclone 4wd ('91),<br> S-15 Jimmy 4wd ('83-'91), Jimmy 4wd ('92-'99), Typhoon 4wd ('92-93), Envoy 4wd ('98-'99), Oldsmobile Bravada 4wd ('91-'94, '96-'99),<br> Isuzu Hombre 4wd ('98-'99)
|-
|U||Regular length All-Purpose Vehicle ('90-'99 U-body fwd minivans)
|-
|V||Chevy full-size pickups & chassis cabs 4wd (V-series), V10/V1500 Blazer 4wd, Suburban 4wd '87-'91,<br /> GMC full-size pickups & chassis cabs 4wd (V-series), V1500 Jimmy 4wd, Suburban 4wd '87-'91
|-
|W||'81-'87 Chevy El Camino, GMC Caballero
|-
|X||Extended length All-Purpose Vehicle ('97-'99 U-body fwd extended length minivans)
|-
|Z||Cadillac chassis cutaway/special body (Based on Rwd Fleetwood '81-'84, Fwd Fleetwood '85-'92)
|}
====Line & Chassis Type 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Pontiac Aztek 2wd '01-'05, Buick Rendezvous 2wd '02-'07
|-
|A||Chevrolet HHR '06-'09, HHR Panel '07-'09
|-
|B||Pontiac Aztek Awd '01-'05, Buick Rendezvous Awd '02-'06
|-
|C||Chevy full-size pickups & chassis cabs 2wd (C-series) '00, full-size chassis cabs 2wd (C3500HD) '01-'02, Silverado 2wd '00-'09, Silverado Classic 2wd '07,<br /> GMC Sierra 2wd (C-series) '00-'09, Sierra Classic 2wd '00, '07
|-
|C||Chevy Tahoe 2wd ('00-'09), Suburban 2wd ('00-'09), Avalanche 2wd ('02-'09),<br /> GMC Yukon 2wd ('00-'09), Yukon XL 2wd ('00-'09), Cadillac Escalade 2wd ('02-'09), Escalade ESV 2wd ('08-'09)
|-
|E||Chevrolet Tracker 2wd '00-'04
|-
|E||Cadillac SRX 2wd & Awd '04-'09
|-
|G||Chevy/GMC full-size vans 2wd (Chevy Express, GMC Savana) '00-09
|-
|H||Chevy/GMC full-size vans 4wd (Chevy Express, GMC Savana) '03-09
|-
|H||Cadillac Commercial Chassis for Hearse (Based on Fwd DeVille '02-'05, DTS '06-'09)
|-
|H||Cadillac Professional Chassis for Limousine (Based on Fwd DeVille '00-'05, DTS '06-'07)
|-
|J||Chevrolet Tracker 4wd '00-'04
|-
|K||Chevy full-size pickups & chassis cabs 4wd (K-series) '00, Silverado 4wd '00-'09, Silverado Classic 4wd '07,<br /> GMC Sierra 4wd (K-series) '00-'09, Sierra Classic 4wd '00, '07
|-
|K||Chevy Tahoe 4wd ('00-'09), Suburban 4wd ('00-'09), Avalanche 4wd ('02-'09), GMC Yukon 4wd ('00-'09), Yukon XL 4wd ('00-'09),<br> Cadillac Escalade 4wd ('00, '02-'09), Escalade ESV 4wd ('03-'09), Escalade EXT 4wd ('02-'09)
|-
|K||Cadillac Professional Chassis for Limousine (Based on Fwd DTS '08-'09)
|-
|L||Chevy Astro/GMC Safari 4wd '00-'05
|-
|L||Chevy Equinox 2wd & Awd '05-'09, Pontiac Torrent 2wd & Awd '06-'09, Saturn Vue 2wd & Awd '08-'09
|-
|M||Chevy Astro/GMC Safari 2wd '00-'05
|-
|N||Hummer H2 '03-'09, H2 SUT '05-'09
|-
|N||Hummer H3 '06-'09, H3T '09
|-
|R||GMC Acadia 2wd, Saturn Outlook 2wd '07-'09, Buick Enclave 2wd '08-'09, Chevy Traverse 2wd '09
|-
|S||Chevy S-10 2wd ('00-'03), Blazer 2wd ('00-'05), GMC Sonoma 2wd ('00-'03), Jimmy 2wd ('00-'01), Isuzu Hombre 2wd ('00)
|-
|S||Chevy Trailblazer 2wd ('02-'09), SSR ('03-'06), GMC Envoy 2wd ('02-'09), Envoy XUV 2wd ('04-'05), Oldsmobile Bravada 2wd ('02-'04),<br> Buick Rainier 2wd ('04-'07), Isuzu Ascender 2wd ('03-'08)
|-
|S||Chevy Colorado 2wd ('04-'09), GMC Canyon 2wd ('04-'09), Isuzu i-series 2wd ('06-'08)
|-
|T||Chevy S-10 4wd ('00-'04), Blazer 4wd ('00-'05), GMC Sonoma 4wd ('00-'04), Jimmy 4wd ('00-'01, Canada only: '02-'05), Envoy 4wd ('00),<br> Oldsmobile Bravada 4wd ('00-'01), Isuzu Hombre 4wd ('00)
|-
|T||Chevy Trailblazer 4wd ('02-'09), GMC Envoy 4wd ('02-'09), Envoy XUV 2wd ('04-'05), Oldsmobile Bravada 4wd ('02-'04), Buick Rainier 4wd ('04-'07),<br> Isuzu Ascender 4wd ('03-'08), Saab 9-7X 4wd ('05-'09)
|-
|T||Chevy Colorado 4wd ('04-'09), GMC Canyon 4wd ('04-'09), Isuzu i-series 4wd ('06-'08)
|-
|U||Regular length All-Purpose Vehicle [Minivan] ('00-'04 Chevy Venture, Pontiac Montana)
|-
|U||Regular length All-Purpose Vehicle [Minivan] (Chevy Uplander [US: '06-'08, Canada only: '05-'09], Pontiac Montana SV6 [Canada only: '05-'09])
|-
|V||Extended length AWD All-Purpose Vehicle [Minivan] ('02-'04 Chevy Venture, Pontiac Montana, Oldsmobile Silhouette Extended length AWD)
|-
|V||Extended length FWD All-Purpose Vehicle [Minivan] ('05 Chevy Venture, Pontiac Montana Extended length FWD)
|-
|V||Extended length FWD All-Purpose Vehicle [Minivan] (Chevy Uplander ['05-'08, Canada only: '09], Pontiac Montana SV6 ['05-'06, Canada only: '07-'09],<br> Buick Terraza ['05-'07], Saturn Relay ['05-'07])
|-
|V||GMC Acadia Awd, Saturn Outlook Awd '07-'09, Buick Enclave Awd '08-'09, Chevy Traverse Awd '09
|-
|X||Extended length FWD All-Purpose Vehicle [Minivan] ('00-'04 Chevy Venture, Pontiac Montana, Oldsmobile Silhouette Extended length FWD)
|-
|X||Extended length AWD All-Purpose Vehicle [Minivan] ('05-'06 Chevy Uplander AWD, Pontiac Montana SV6 AWD, Buick Terraza AWD, Saturn Relay AWD)
|-
|Z||Saturn Vue 2wd & Awd '02-'07
|}
====Series 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1||1/2 Ton (includes '96-'99 Isuzu Hombre)
|-
|2||3/4 Ton
|-
|3||1 Ton
|-
|8||1/2 Ton ('81-'87 El Camino, Caballero)
|-
|9||Cadillac, Buick, Chevrolet Commercial Body/Chassis
|-
|0||All-Purpose Vehicle ('90-'99 U-body fwd minivans)
|}
====Series 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1 <br> (following A)||Chevrolet HHR LS ('06-'07)
|-
|2 <br> (following A)||Chevrolet HHR LT ('06-'07)
|-
|3 <br> (following A)||Chevrolet HHR LT ('07)
|-
|1 <br> (following A)||Chevrolet HHR LS w/auto. trans. ('08-'09)
|-
|2 <br> (following A)||Chevrolet HHR 1LT w/auto. trans. ('08-'09)
|-
|3 <br> (following A)||Chevrolet HHR LS w/man. trans. ('08-'09)
|-
|4 <br> (following A)||Chevrolet HHR 1LT w/man. trans. ('08-'09)
|-
|5 <br> (following A)||Chevrolet HHR 2LT (all transmissions) ('08-'09)
|-
|6 <br> (following A)||Chevrolet HHR SS w/auto. trans. ('08-'09) (Pos. 1-3 of VIN is 3GN)
|-
|7 <br> (following A)||Chevrolet HHR SS w/man. trans. ('08-'09) (Pos. 1-3 of VIN is 3GN)
|-
|6 <br> (following A)||Chevrolet HHR Panel SS w/auto. trans. ('09) (Pos. 1-3 of VIN is 3GC)
|-
|7 <br> (following A)||Chevrolet HHR Panel SS w/man. trans. ('09) (Pos. 1-3 of VIN is 3GC)
|-
|8 <br> (following A)||Chevrolet HHR Panel LS w/auto. trans. ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|9 <br> (following A)||Chevrolet HHR Panel LS w/man. trans. ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|0 <br> (following A)||Chevrolet HHR Panel LT (all transmissions) ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|1 <br> (following A)||Chevrolet HHR Panel LS ('08) (Pos. 1-3 of VIN is 3GC)
|-
|2 <br> (following A)||Chevrolet HHR Panel LT ('08) (Pos. 1-3 of VIN is 3GC)
|-
|3 <br> (following A)||Chevrolet HHR Panel LT ('08) (Pos. 1-3 of VIN is 3GC)
|-
|0 <br> (following V)||Chevrolet Venture Plus ('05) (Pos. 8 of VIN is E)
|-
|1 <br> (following V)||Chevrolet Venture Cargo ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following V)||Chevrolet Venture LS ('05) (Pos. 8 of VIN is E)
|-
|3 <br> (following V)||Chevrolet Venture LT ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following U)||Chevrolet Uplander LS SWB 2wd ('06-'08)
|-
|0 <br> (following V)||Chevrolet Uplander Base model 2wd ('05)
|-
|1 <br> (following V)||Chevrolet Uplander Cargo Van 2wd, Mobility (incomplete vehicle) 2wd ('05-'08)
|-
|2 <br> (following V)||Chevrolet Uplander LS 2wd ('05-'08)
|-
|3 <br> (following V)||Chevrolet Uplander LT 2wd ('05-'08)
|-
|3 <br> (following X)||Chevrolet Uplander LT Awd ('05-'06)
|-
|1 <br> (following M)||Chevrolet Astro 2wd ('00-'05)
|-
|1 <br> (following L)||Chevrolet Astro Awd ('00-'05)
|-
|1 <br> (following G)||Chevrolet Express 1500 series 2wd ('00-'09)
|-
|2 <br> (following G)||Chevrolet Express 2500 series 2wd ('00-'09)
|-
|3 <br> (following G)||Chevrolet Express 3500 series 2wd ('00-'09)
|-
|3 <br> (following G)||When VIN starts with 1GBK: Chevrolet Express 4500 series Cutaway 2wd ('09)
|-
|6 <br> (following G)||Chevrolet Express 1500 series LT 2wd ('01-'02)
|-
|1 <br> (following H)||Chevrolet Express 1500 series Awd ('03-'09)
|-
|2 <br> (following H)||Chevrolet Express 2500 series Awd ('03-'05)
|-
|1 <br> (following E)||Chevrolet Tracker Base model 2wd ('00-'04)
|-
|6 <br> (following E)||Chevrolet Tracker LT 2wd ('01-'04)
|-
|1 <br> (following J)||Chevrolet Tracker Base model 4wd ('00-'01, '04)
|-
|1 <br> (following J)||Chevrolet Tracker Base model w/1SB (Preferred) Equip. Group 4wd ('02-'03)
|-
|2 <br> (following J)||Chevrolet Tracker Base model w/1SA (Base) Equip. Group 4wd ('02-'03)
|-
|6 <br> (following J)||Chevrolet Tracker LT 4wd ('01-'04)
|-
|7 <br> (following J)||Chevrolet Tracker ZR2 4wd ('01-'04)
|-
|1 <br> (following L)||Chevrolet Equinox LS 2wd ('05-'09)
|-
|2 <br> (following L)||Chevrolet Equinox LS Awd ('05-'09)
|-
|6 <br> (following L)||Chevrolet Equinox LT 2wd ('05-'07)
|-
|7 <br> (following L)||Chevrolet Equinox LT Awd ('05-'07)
|-
|3 <br> (following L)||Chevrolet Equinox 1LT 2wd ('08-'09)
|-
|4 <br> (following L)||Chevrolet Equinox 1LT Awd ('08-'09)
|-
|5 <br> (following L)||Chevrolet Equinox 2LT 2wd ('08-'09)
|-
|6 <br> (following L)||Chevrolet Equinox 2LT Awd ('08-'09)
|-
|7 <br> (following L)||Chevrolet Equinox LTZ 2wd ('08-'09)
|-
|8 <br> (following L)||Chevrolet Equinox LTZ Awd ('08-'09)
|-
|9 <br> (following L)||Chevrolet Equinox Sport 2wd ('08-'09)
|-
|0 <br> (following L)||Chevrolet Equinox Sport Awd ('08-'09)
|-
|1 <br> (following R)||Chevrolet Traverse LS 2wd ('09)
|-
|2 <br> (following R)||Chevrolet Traverse LT 2wd ('09)
|-
|3 <br> (following R)||Chevrolet Traverse LTZ 2wd ('09)
|-
|1 <br> (following V)||Chevrolet Traverse LS Awd ('09)
|-
|2 <br> (following V)||Chevrolet Traverse LT Awd ('09)
|-
|3 <br> (following V)||Chevrolet Traverse LTZ Awd ('09)
|-
|1 <br> (following S)||Chevrolet Blazer 2wd ('00-'05)
|-
|1 <br> (following T)||Chevrolet Blazer 4wd ('00-'05)
|-
|1 <br> (following S)||Chevrolet Trailblazer 2wd ('02-'08), Trailblazer EXT 2wd ('02-'06)
|-
|1 <br> (following T)||Chevrolet Trailblazer 4wd ('02-'08), Trailblazer EXT 4wd ('02-'06)
|-
|3 <br> (following S)||Chevrolet Trailblazer LT 2wd ('09)
|-
|3 <br> (following T)||Chevrolet Trailblazer LT 4wd ('09)
|-
|5 <br> (following S)||Chevrolet Trailblazer SS 2wd ('09)
|-
|5 <br> (following T)||Chevrolet Trailblazer SS 4wd ('09)
|-
|1 <br> (following C)||Chevrolet Tahoe Limited 2wd ('00) [GMT400; 8th pos. of VIN is R]
|-
|1 <br> (following K)||Chevrolet Tahoe Z71 4wd ('00) [GMT400; 8th pos. of VIN is R]
|-
|1 <br> (following C)||Chevrolet Tahoe 2wd ('00-'06) [GMT800]
|-
|1 <br> (following K)||Chevrolet Tahoe 4wd ('00-'06) [GMT800]
|-
|1 <br> (following C)||Chevrolet Tahoe 2wd ('07-'08) [GMT900]
|-
|0 <br> (following C)||Chevrolet Tahoe Police/Special Service 2wd ('07-'09) [GMT900]
|-
|1 <br> (following C)||Chevrolet Tahoe LS 2wd ('09) [GMT900]
|-
|2 <br> (following C)||Chevrolet Tahoe LT 2wd ('09) [GMT900]
|-
|3 <br> (following C)||Chevrolet Tahoe LTZ 2wd ('09) [GMT900]
|-
|1 <br> (following K)||Chevrolet Tahoe 4wd ('07-'08) [GMT900]
|-
|0 <br> (following K)||Chevrolet Tahoe Police/Special Service 4wd ('07-'09) [GMT900]
|-
|1 <br> (following K)||Chevrolet Tahoe LS 4wd ('09) [GMT900]
|-
|2 <br> (following K)||Chevrolet Tahoe LT 4wd ('09) [GMT900]
|-
|3 <br> (following K)||Chevrolet Tahoe LTZ 4wd ('09) [GMT900]
|-
|1 <br> (following C)||Chevrolet Suburban 1500 series 2wd ('00-'08)
|-
|2 <br> (following C)||Chevrolet Suburban 2500 series 2wd ('00-'08)
|-
|1 <br> (following K)||Chevrolet Suburban 1500 series 4wd ('00-'08)
|-
|2 <br> (following K)||Chevrolet Suburban 2500 series 4wd ('00-'08)
|-
|1 <br> (following C)||Chevrolet Suburban 1500 series LS 2wd ('09)
|-
|2 <br> (following C)||Chevrolet Suburban 1500 series LT 2wd ('09)
|-
|3 <br> (following C)||Chevrolet Suburban 1500 series LTZ 2wd ('09)
|-
|4 <br> (following C)||Chevrolet Suburban 2500 series LS 2wd ('09)
|-
|5 <br> (following C)||Chevrolet Suburban 2500 series LT 2wd ('09)
|-
|1 <br> (following K)||Chevrolet Suburban 1500 series LS 4wd ('09)
|-
|2 <br> (following K)||Chevrolet Suburban 1500 series LT 4wd ('09)
|-
|3 <br> (following K)||Chevrolet Suburban 1500 series LTZ 4wd ('09)
|-
|4 <br> (following K)||Chevrolet Suburban 2500 series LS 4wd ('09)
|-
|5 <br> (following K)||Chevrolet Suburban 2500 series LT 4wd ('09)
|-
|1 <br> (following C)||Chevrolet Avalanche 1500 series 2wd ('02-'08)
|-
|2 <br> (following C)||Chevrolet Avalanche 2500 series 2wd ('02-'03)
|-
|1 <br> (following K)||Chevrolet Avalanche 1500 series 4wd ('02-'08)
|-
|2 <br> (following K)||Chevrolet Avalanche 2500 series 4wd ('02-'06)
|-
|1 <br> (following C)||Chevrolet Avalanche 1500 series LS 2wd ('09)
|-
|2 <br> (following C)||Chevrolet Avalanche 1500 series LT 2wd ('09)
|-
|3 <br> (following C)||Chevrolet Avalanche 1500 series LTZ 2wd ('09)
|-
|1 <br> (following K)||Chevrolet Avalanche 1500 series LS 4wd ('09)
|-
|2 <br> (following K)||Chevrolet Avalanche 1500 series LT 4wd ('09)
|-
|3 <br> (following K)||Chevrolet Avalanche 1500 series LTZ 4wd ('09)
|-
|1 <br> (following S)||Chevrolet SSR 2wd ('03-'06)
|-
|6 <br> (following S)||Chevrolet SSR Signature Series 2wd ('03) <br> [All SSR Signature Series also have a 0 in the 12th pos. of VIN whereas all other SSRs have a 1 in the 12th pos. of VIN]
|-
|1 <br> (following S)||Chevrolet S-10 2wd ('00-'03)
|-
|1 <br> (following T)||Chevrolet S-10 4wd ('00-'04)
|-
|1 <br> (following S)||Chevrolet Colorado 2wd ('04-'07)
|-
|1 <br> (following T)||Chevrolet Colorado 4wd ('04-'07)
|-
|1 <br> (following V)||Pontiac Montana Mobility (incomplete vehicle) 2wd ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following V)||Pontiac Montana ('05) (Pos. 8 of VIN is E)
|-
|0 <br> (following V)||Pontiac Montana SV6 1SA 2wd ('05)
|-
|3 <br> (following V)||Pontiac Montana SV6 1SB 2wd ('05)
|-
|2 <br> (following X)||Pontiac Montana SV6 1SA Awd ('05)
|-
|3 <br> (following X)||Pontiac Montana SV6 1SB Awd ('05)
|-
|1 <br> (following V)||Pontiac Montana SV6 Mobility (incomplete vehicle) 2wd ('06)
|-
|3 <br> (following V)||Pontiac Montana SV6 2wd ('06)
|-
|3 <br> (following X)||Pontiac Montana SV6 Awd ('06)
|-
|0 <br> (following A)||Pontiac Aztek 2wd ('01-'05)
|-
|0 <br> (following B)||Pontiac Aztek Awd ('01-'05)
|-
|6 <br> (following L)||Pontiac Torrent 2wd ('06-'07)
|-
|7 <br> (following L)||Pontiac Torrent Awd ('06-'07)
|-
|3 <br> (following L)||Pontiac Torrent Base model 2wd ('08-'09)
|-
|4 <br> (following L)||Pontiac Torrent Base model Awd ('08-'09)
|-
|5 <br> (following L)||Pontiac Torrent GXP 2wd ('08-'09)
|-
|6 <br> (following L)||Pontiac Torrent GXP Awd ('08-'09)
|-
|0 <br> (following X)||Oldsmobile Silhouette extended length GL 2wd ('00, '03-'04), GLS 2wd ('00-'04)
|-
|1 <br> (following X)||Oldsmobile Silhouette extended length Premiere 2wd ('00-'04)
|-
|2 <br> (following X)||Oldsmobile Silhouette extended length GL 2wd ('01-'02)
|-
|0 <br> (following V)||Oldsmobile Silhouette extended length GLS Awd ('02-'04)
|-
|1 <br> (following V)||Oldsmobile Silhouette extended length Premiere Awd ('02-'04)
|-
|1 <br> (following S)||Oldsmobile Bravada 2wd ('02-'04)
|-
|1 <br> (following T)||Oldsmobile Bravada 4wd ('00-'04)
|-
|1 <br> (following V)||Buick Terraza Mobility (incomplete vehicle) 2wd ('05-'07)
|-
|2 <br> (following V)||Buick Terraza CX 2wd ('05-'07), CX Plus 2wd ('07)
|-
|3 <br> (following V)||Buick Terraza CXL 2wd ('05-'07)
|-
|2 <br> (following X)||Buick Terraza CX Awd ('05-'06)
|-
|3 <br> (following X)||Buick Terraza CXL Awd ('05-'06)
|-
|0 <br> (following A)||Buick Rendezvous 2wd ('02-'07)
|-
|0 <br> (following B)||Buick Rendezvous Awd ('02-'06)
|-
|1 <br> (following S)||Buick Rainier 2wd ('04-'07)
|-
|1 <br> (following T)||Buick Rainier 4wd ('04-'06)
|-
|1 <br> (following R)||Buick Enclave CX 2wd ('08-'09)
|-
|2 <br> (following R)||Buick Enclave CXL 2wd ('08-'09)
|-
|1 <br> (following V)||Buick Enclave CX Awd ('08-'09)
|-
|2 <br> (following V)||Buick Enclave CXL Awd ('08-'09)
|-
|6 <br> (following E)||Cadillac SRX ('04-'07)
|-
|2 <br> (following E)||Cadillac SRX RWD V8 ('08-'09)
|-
|4 <br> (following E)||Cadillac SRX AWD V6 ('08-'09)
|-
|5 <br> (following E)||Cadillac SRX AWD V8 ('08-'09)
|-
|6 <br> (following E)||When Pos. 8 of VIN is 7: Cadillac SRX RWD V6 ('08)
|-
|6 <br> (following E)||When Pos. 8 of VIN is A: Cadillac SRX AWD V8 ('08)
|-
|6 <br> (following E)||Cadillac SRX RWD V6 ('09)
|-
|1 <br> (following K)||Cadillac Escalade 4wd (Early '00)
|-
|4 <br> (following K)||Cadillac Escalade Platinum Edition 4wd ('08), Escalade ESV Platinum Edition 4wd ('08)
|-
|6 <br> (following C)||Cadillac Escalade 2wd ('02-'08), Escalade ESV 2wd ('08)
|-
|6 <br> (following K)||Cadillac Escalade 4wd (Mid '00, '02-'08), Escalade ESV 4wd ('03-'08), Escalade EXT 4wd ('02-'08)
|-
|1 <br> (following C)||Cadillac Escalade 2wd Base model ('09), Escalade ESV 2wd Base model ('09)
|-
|2 <br> (following C)||Cadillac Escalade 2wd w/Ultra Luxury Collection ('09), Escalade ESV 2wd w/Ultra Luxury Collection ('09)
|-
|3 <br> (following C)||Cadillac Escalade 2wd w/Platinum Edition ('09), Escalade ESV 2wd w/Platinum Edition ('09)
|-
|4 <br> (following C)||Cadillac Escalade Hybrid 2wd Base model ('09)
|-
|5 <br> (following C)||Cadillac Escalade 2wd w/Sport Package ('09), Escalade ESV 4wd w/Sport Package ('09)
|-
|1 <br> (following K)||Cadillac Escalade 4wd Base model ('09), Escalade ESV 4wd Base model ('09), Escalade EXT 4wd Base model ('09)
|-
|2 <br> (following K)||Cadillac Escalade 4wd w/Ultra Luxury Collection ('09), Escalade ESV 4wd w/Ultra Luxury Collection ('09),<br> Escalade EXT 4wd w/Ultra Luxury Collection ('09)
|-
|3 <br> (following K)||Cadillac Escalade 4wd w/Platinum Edition ('09), Escalade ESV 4wd w/Platinum Edition ('09)
|-
|4 <br> (following K)||Cadillac Escalade Hybrid 4wd Base model ('09)
|-
|5 <br> (following K)||Cadillac Escalade 4wd w/Sport Package ('09), Escalade ESV 4wd w/Sport Package ('09), Escalade EXT 4wd w/Sport Package ('09)
|-
|1 <br> (following M)||GMC Safari 2wd ('00-'05)
|-
|1 <br> (following L)||GMC Safari Awd ('00-'05)
|-
|1 <br> (following G)||GMC Savana 1500 series 2wd ('00-'09)
|-
|2 <br> (following G)||GMC Savana 2500 series 2wd ('00-'09)
|-
|3 <br> (following G)||GMC Savana 3500 series 2wd ('00-'09)
|-
|3 <br> (following G)||When VIN starts with 1GBK: GMC Savana 4500 series Cutaway 2wd ('09)
|-
|6 <br> (following G)||GMC Savana 1500 series SLT 2wd ('01-'02)
|-
|1 <br> (following H)||GMC Savana 1500 series Awd ('03-'09)
|-
|2 <br> (following H)||GMC Savana 2500 series Awd ('03-'05)
|-
|1 <br> (following R)||GMC Acadia SLE 2wd ('07-'09)
|-
|2 <br> (following R)||GMC Acadia SLT-1 2wd ('07-'09)
|-
|3 <br> (following R)||GMC Acadia SLT-2 2wd ('07-'09)
|-
|1 <br> (following V)||GMC Acadia SLE Awd ('07-'09)
|-
|2 <br> (following V)||GMC Acadia SLT-1 Awd ('07-'09)
|-
|3 <br> (following V)||GMC Acadia SLT-2 Awd ('07-'09)
|-
|1 <br> (following S)||GMC Jimmy 2wd ('00-'01)
|-
|6 <br> (following S)||GMC Jimmy Diamond Edition 2wd ('01)
|-
|1 <br> (following T)||GMC Jimmy 4wd ('00-'01 & '02-'05 in Canada)
|-
|6 <br> (following T)||GMC Jimmy Diamond Edition 4wd ('01)
|-
|1 <br> (following S)||GMC Envoy 2wd ('02-'08), Envoy XL 2wd ('02-'06), Envoy XUV 2wd ('04-'05)
|-
|6 <br> (following S)||GMC Envoy Denali 2wd ('05-'08), Envoy XL Denali 2wd ('05-'06)
|-
|1 <br> (following T)||GMC Envoy 4wd ('02-'08), Envoy XL 4wd ('02-'06), Envoy XUV 4wd ('04-'05)
|-
|6 <br> (following T)||GMC Envoy Denali 4wd ('05-'08), Envoy XL Denali 4wd ('05-'06)
|-
|3 <br> (following S)||GMC Envoy SLE 2wd ('09)
|-
|3 <br> (following T)||GMC Envoy SLE 4wd ('09)
|-
|4 <br> (following S)||GMC Envoy SLT 2wd ('09)
|-
|4 <br> (following T)||GMC Envoy SLT 4wd ('09)
|-
|5 <br> (following S)||GMC Envoy Denali 2wd ('09)
|-
|5 <br> (following T)||GMC Envoy Denali 4wd ('09)
|-
|1 <br> (following C)||GMC Yukon 2wd ('00-'06) [GMT800]
|-
|1 <br> (following K)||GMC Yukon 4wd ('00-'06) [GMT800]
|-
|1 <br> (following C)||GMC Yukon 2wd ('07-'08) [GMT900]
|-
|1 <br> (following K)||GMC Yukon 4wd ('07-'08) [GMT900]
|-
|1 <br> (following C)||GMC Yukon 2wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon 4wd ('09) [GMT900]
|-
|1 <br> (following C)||GMC Yukon Hybrid 2wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following K)||GMC Yukon Hybrid 4wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|2 <br> (following C)||GMC Yukon SLE 2wd ('09) [GMT900]
|-
|3 <br> (following C)||GMC Yukon SLT 2wd ('09) [GMT900]
|-
|2 <br> (following K)||GMC Yukon SLE 4wd ('09) [GMT900]
|-
|3 <br> (following K)||GMC Yukon SLT 4wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon Denali 4wd (Early '00) [GMT400; 8th pos. of VIN is R]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd (Mid '00) [GMT400; 8th pos. of VIN is R]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd ('01-'06) [GMT800]
|-
|6 <br> (following C)||GMC Yukon Denali 2wd ('08) [GMT900]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd ('07-'08) [GMT900]
|-
|0 <br> (following C)||GMC Yukon Denali 2wd ('09) [GMT900]
|-
|0 <br> (following K)||GMC Yukon Denali 4wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon Denali 4wd ('09) [GMT900; 8th pos. of VIN is 2]
|-
|1 <br> (following C)||GMC Yukon Denali Hybrid 2wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following K)||GMC Yukon Denali Hybrid 4wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following C)||GMC Yukon XL 1500 series 2wd ('00-'08)
|-
|2 <br> (following C)||GMC Yukon XL 2500 series 2wd ('00-'08)
|-
|6 <br> (following C)||GMC Yukon XL Denali 1500 series 2wd ('08)
|-
|1 <br> (following K)||GMC Yukon XL 1500 series 4wd ('00-'08)
|-
|2 <br> (following K)||GMC Yukon XL 2500 series 4wd ('00-'08)
|-
|6 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('01-'08)
|-
|1 <br> (following C)||GMC Yukon XL 1500 series 2wd ('09)
|-
|2 <br> (following C)||GMC Yukon XL 1500 series SLE 2wd ('09)
|-
|3 <br> (following C)||GMC Yukon XL 1500 series SLT 2wd ('09)
|-
|4 <br> (following C)||GMC Yukon XL 2500 series 2wd ('09)
|-
|5 <br> (following C)||GMC Yukon XL 2500 series SLE 2wd ('09)
|-
|6 <br> (following C)||GMC Yukon XL 2500 series SLT 2wd ('09)
|-
|0 <br> (following C)||GMC Yukon XL Denali 1500 series 2wd ('09)
|-
|1 <br> (following K)||GMC Yukon XL 1500 series 4wd ('09)
|-
|2 <br> (following K)||GMC Yukon XL 1500 series SLE 4wd ('09)
|-
|3 <br> (following K)||GMC Yukon XL 1500 series SLT 4wd ('09)
|-
|4 <br> (following K)||GMC Yukon XL 2500 series 4wd ('09)
|-
|5 <br> (following K)||GMC Yukon XL 2500 series SLE 4wd ('09)
|-
|6 <br> (following K)||GMC Yukon XL 2500 series SLT 4wd ('09)
|-
|0 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('09)
|-
|1 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('09) [8th pos. of VIN is 2]
|-
|1 <br> (following S)||GMC Sonoma 2wd ('00-'03)
|-
|1 <br> (following T)||GMC Sonoma 4wd ('00-'04)
|-
|1 <br> (following S)||GMC Canyon 2wd ('04-'07)
|-
|1 <br> (following T)||GMC Canyon 4wd ('04-'07)
|-
|0 <br> (following V)||Saturn Relay ''2'' 2wd ('05-'07)
|-
|2 <br> (following V)||Saturn Relay ''3'' 2wd ('05-'07)
|-
|5 <br> (following V)||Saturn Relay ''1'' 2wd ('07)
|-
|2 <br> (following X)||Saturn Relay ''3'' Awd ('05-'06)
|-
|2 <br> (following Z)||Saturn Vue I4, Man. Trans., Fwd ('02-'07)
|-
|3 <br> (following Z)||Saturn Vue I4, Auto. Trans., Fwd ('02-'07)
|-
|4 <br> (following Z)||Saturn Vue I4, Auto. Trans., Awd ('02-'05)
|-
|5 <br> (following Z)||Saturn Vue V6, Auto. Trans., Fwd ('03-'07)
|-
|6 <br> (following Z)||Saturn Vue V6, Auto. Trans., Awd ('02-'07)
|-
|3 <br> (following L)||Saturn Vue XE Fwd ('08-'09)
|-
|4 <br> (following L)||Saturn Vue XE Awd ('08-'09)
|-
|5 <br> (following L)||when 4th pos. of VIN is C: Saturn Vue XR Fwd ('08-'09)
|-
|7 <br> (following L)||Saturn Vue XR Awd (Early '08)
|-
|6 <br> (following L)||Saturn Vue XR Awd (Mid '08-'09)
|-
|5 <br> (following L)||when 4th pos. of VIN is D: Saturn Vue XR Awd ('09)
|-
|1 <br> (following L)||Saturn Vue Red Line Fwd ('08-'09)
|-
|9 <br> (following L)||Saturn Vue Red Line Awd ('08)
|-
|0 <br> (following L)||Saturn Vue Red Line Awd ('09)
|-
|0 <br> (following L)||Saturn Vue Green Line Fwd ('08)
|-
|9 <br> (following L)||Saturn Vue Green Line Fwd ('09)
|-
|1 <br> (following R)||Saturn Outlook XE 2wd ('07-'09)
|-
|2 <br> (following R)||Saturn Outlook XR 2wd ('07-'09)
|-
|3 <br> (following R)||Saturn Outlook XR 2wd w/Touring Package ('07-'09)
|-
|1 <br> (following V)||Saturn Outlook XE Awd ('07-'09)
|-
|2 <br> (following V)||Saturn Outlook XR Awd ('07-'09)
|-
|3 <br> (following V)||Saturn Outlook XR Awd w/Touring Package ('07-'09)
|-
|1 <br> (following N)||Hummer H3 ('06-'07)
|-
|1 <br> (following N)||Hummer H3 Base model ('08)
|-
|3 <br> (following N)||Hummer H3 Adventure ('08)
|-
|4 <br> (following N)||Hummer H3 Luxury ('08)
|-
|5 <br> (following N)||Hummer H3 X ('08)
|-
|6 <br> (following N)||Hummer H3 Alpha ('08)
|-
|1 <br> (following N)||Hummer H3, H3T ('09)
|-
|2 <br> (following N)||Hummer H2 ('03-'08), H2 SUT ('05-'08)
|-
|2 <br> (following N)||Hummer H2 Base model ('09), H2 SUT Base model ('09)
|-
|7 <br> (following N)||Hummer H2 Adventure ('09)
|-
|8 <br> (following N)||Hummer H2 Luxury ('09)
|-
|9 <br> (following N)||Hummer H2 SUT Adventure ('09)
|-
|0 <br> (following N)||Hummer H2 SUT Luxury ('09)
|-
|1 (following S)||Isuzu Hombre 2wd ('00), Isuzu i280 2wd ('06), Isuzu i290 2wd ('07-'08), Isuzu i370 2wd ('07-'08)
|-
|2 (following S)||Isuzu i290 2wd w/Preferred Equip. Pkg. ('08), Isuzu i370 2wd w/Comfort Pkg. or upgrade model ('08)
|-
|1 (following T)||Isuzu Hombre 4wd ('00), Isuzu i350 4wd ('06), Isuzu i370 4wd ('07-'08)
|-
|2 (following T)||Isuzu i370 4wd w/Comfort Pkg. ('08)
|-
|1 (following S)||Isuzu Ascender 2wd ('03-'08)
|-
|1 (following T)||Isuzu Ascender 4wd ('03-'08)
|-
|1 (following T)||Saab 9-7X ('05-'08: All, '09: 4.2i, 5.3i)
|-
|2 (following T)||Saab 9-7X Aero ('09)
|}
====Body style codes 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Body type is specified as character 7 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|0||Sedan Pickup/Pickup Delivery ('81-'87 El Camino, Caballero)
|-
|0||Cadillac, Buick, Chevrolet Commercial Body/Chassis
|-
|0||Chassis Only
|-
|1||Cutaway Van
|-
|2||Forward Control ('81-'03) (includes '93-'95 Chevy G30HD/GMC G3500HD)
|-
|2||Sport Utility Truck (SUT) ('04-'09 Avalanche & Escalade EXT, '04-'05 Envoy XUV, '05-'09 Hummer H2 SUT)
|-
|3||Four-Door Cab pickup (Crew Cab) (includes '06-'08 Isuzu i-Series Crew Cab, '09 Hummer H3T)
|-
|3||4-door Passenger Minivan ('97-'09 U-bodies)
|-
|3||4-door SUV or MPV ('06-'09 HHR) (also includes '02-'03 Avalanche & Escalade EXT) ('05-'09 Saab 9-7X)
|-
|4||Two-Door Cab pickup (includes '83-'87 S-10/S-15 extended cab pickups, '03-'06 Chevy SSR, '96-'00 Isuzu Hombre Reg. Cab)
|-
|5||Van (Astro/Safari & full-size vans & '07-'09 HHR Panel)
|-
|6||Extended length 4-door SUV (Suburban, Yukon XL, Escalade ESV, Trailblazer EXT, Envoy XL, Isuzu Ascender 7-psgr.)
|-
|6||3-door Passenger Minivan ('90-'99 U-bodies)
|-
|7||Motor Home Chassis ('81-'09)
|-
|8||Two-Door SUV (Utility) (2-d Tracker, S-10 Blazer, S-15 Jimmy, Blazer, Jimmy, Tahoe, Yukon)
|-
|9||Stake (81-87)
|-
|9||Extended Cab pickup ('88-) (includes '97-'00 Isuzu Hombre Spacecab, '06-'08 Isuzu i-Series Ext. Cab)
|-
|9||Extended length van ('90-) (Astro/Safari & full-size vans)
|}
===American VIN format 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>K</td><td></td><td></td></tr><tr>
<td>4</td>
<td>L</td><td></td><td></td><td>[[#GVWR/Brake System/Body Style 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|GVWR/Brake System/Body Style 2010-]]</td>
</tr><tr>
<td>5</td>
<td>R</td><td></td><td></td><td>[[#Line & Chassis Type 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 2010-]]</td>
</tr><tr>
<td>6</td>
<td>L</td><td></td><td></td><td>[[#Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle]]</td>
</tr><tr>
<td>7</td>
<td>E</td><td></td><td></td><td>[[#Restraint codes for light trucks 2010-|Restraint type]]</td>
</tr><tr>
<td>8</td>
<td>D</td><td></td><td></td><td>[[#Engine codes for light trucks|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>A</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>J</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====GVWR/Brake System/Body Style 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The GVWR/Brake System is specified as character 4 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!GVWR Range in lbs. & Weight Class
!Brake System
!Body Style
|-
| ||Class A: 0-3,000||Hydraulic||
|-
| ||Class B: 3,001-4,000||Hydraulic||
|-
|A||Class C: 4,001-5,000||Hydraulic||26: 4-door SUV or MPV ('10-'11 Chevy HHR Panel, '10-'26 Chevy Equinox, GMC Terrain, '10 Saturn Vue,<br> '12-'15 Chevy Captiva Sport, '19-'24 Cadillac XT4, '24-'26 Buick Encore GX)
|-
|B||Class C: 4,001-5,000||Hydraulic||46: 4-door MPV ('10-'11 Chevy HHR)
|-
|J||Class C: 4,001-5,000||Hydraulic||48: 4-door, 4 window Hatchback ('18-'23 Chevy Bolt EV w/Rear Seat Delete pkg. - incomplete vehicle)
|-
|C||Class C: 4,001-5,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|D||Class C: 4,001-5,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|E||Class C: 4,001-5,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|7||Class C: 4,001-5,000||Hydraulic||75: Four-Door Wagon - High Roof Monocab (Canada only: '12-'14 Chevy Orlando)
|-
|M||Class C: 4,001-5,000||Hydraulic||06: 4-door SUV ('20-'23 Buick Encore GX)
|-
|9||Class C: 4,001-5,000||Hydraulic||56: 4-door SUV Extended ('21-'26 Chevy Trailblazer)
|-
|7||Class C: 4,001-5,000||Hydraulic||58: 4-door Utility Extended ('24-'26 Chevy Trax, Buick Envista)
|-
|C||Class C: 4,001-5,000||Hydraulic||76: 4-door SUV ('13-'22 Buick Encore, Canada only: '13-'14 Chevy Trax, US & Canada: '15-'22 Chevy Trax)
|-
|F||Class D: 5,001-6,000||Hydraulic||26: 4-door SUV ('10-'17 Chevy Equinox, GMC Terrain, '10 Saturn Vue, '10-'16 Cadillac SRX, '11 Saab 9-4X,<br> '12-'13 Chevy Captiva Sport, '16-'26 Buick Envision, '17 Cadillac XT5, '19-'25 Cadillac XT4)
|-
|H||Class D: 5,001-6,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|G||Class D: 5,001-6,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|J||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|H||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|G||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('15-'24 Chevy Colorado, '15-'22 GMC Canyon)
|-
|K||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|J||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|H||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('15-'22 Chevy Colorado, GMC Canyon)
|-
|T||Class D: 5,001-6,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|7||Class D: 5,001-6,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|L||Class E: 6,001-7,000||Hydraulic||26: 4-door SUV ('10 Chevy Traverse, GMC Acadia, Buick Enclave, Saturn Outlook)
|-
|K||Class E: 6,001-7,000||Hydraulic||26: 4-door SUV ('11-'17 Chevy Traverse, Buick Enclave, '11-'23 GMC Acadia, '17 Acadia Limited,<br> '17-'26 Cadillac XT5, '19-'26 Chevy Blazer, '20-'25 Cadillac XT6, '23-'26 Cadillac Lyriq EV,<br> '24-'26 Chevy Blazer EV, '25-'26 Cadillac Optiq EV, '24-'26 Honda Prologue EV, '24 Acura ZDX EV A-Spec)
|-
|7||Class E: 6,001-7,000||Hydraulic||48: 4-door SUV ('24-'25 Chevy Equinox EV)
|-
|E||Class E: 6,001-7,000||Hydraulic||56: 4-door SUV Extended ('18-'26 Chevy Traverse, Buick Enclave, '24 Chevy Traverse Limited,<br> '24-'26 GMC Acadia
|-
|M||Class E: 6,001-7,000||Hydraulic||05: Cargo Van ('10 Chevy Express, GMC Savana)
|-
|L||Class E: 6,001-7,000||Hydraulic||05: Cargo Van ('11-'14 Chevy Express, GMC Savana)
|-
|M||Class E: 6,001-7,000||Hydraulic||06: 4-door SUV ('10 Chevy Tahoe, GMC Yukon, Hummer H3)
|-
|L||Class E: 6,001-7,000||Hydraulic||06: 4-door SUV ('11-'20 Chevy Tahoe Police Pursuit Vehicle 2wd)
|-
|N||Class E: 6,001-7,000||Hydraulic||36: Sport Utility Truck (SUT) ('10 Chevy Avalanche 2wd)
|-
|M||Class E: 6,001-7,000||Hydraulic||36: Sport Utility Truck (SUT) ('11-13 Chevy Avalanche 2wd)
|-
|P||Class E: 6,001-7,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|N||Class E: 6,001-7,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|R||Class E: 6,001-7,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra, Hummer H3T)
|-
|P||Class E: 6,001-7,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited, '16-'26 Chevy Colorado, GMC Canyon)
|-
|S||Class E: 6,001-7,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|R||Class E: 6,001-7,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '19 Chevy Silverado LD, GMC Sierra Limited, '22 Chevy Silverado LTD, GMC Sierra Limited,<br> '16-'22 Chevy Colorado)
|-
|G||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|8||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|X||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('13-'19 Cadillac XTS chassis for Limo/Hearse)
|-
|U||Class F: 7,001-8,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|S||Class F: 7,001-8,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'14 Chevy Express, GMC Savana)
|-
|U||Class F: 7,001-8,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|S||Class F: 7,001-8,000||Hydraulic||06: Passenger Van ('11-'14 Chevy Express, GMC Savana)
|-
|U||Class F: 7,001-8,000||Hydraulic||06: 4-door SUV ('10 Chevy Tahoe, Suburban 1500, GMC Yukon, Yukon XL 1500, Cadillac Escalade, Escalade ESV)
|-
|S||Class F: 7,001-8,000||Hydraulic||06: 4-door SUV ('11-'26 Chevy Tahoe, Suburban 1500, GMC Yukon, Yukon XL 1500, Cadillac Escalade, Escalade ESV)
|-
|V||Class F: 7,001-8,000||Hydraulic||36: Sport Utility Truck (SUT) ('10 Chevy Avalanche 4wd, Cadillac Escalade EXT 4wd)
|-
|T||Class F: 7,001-8,000||Hydraulic||36: Sport Utility Truck (SUT) ('11-'13 Chevy Avalanche 4wd, Cadillac Escalade EXT 4wd)
|-
|X||Class F: 7,001-8,000||Hydraulic||26: 4-door SUV ('24 Acura ZDX EV Type S)
|-
|C||Class F: 7,001-8,000||Hydraulic||56: 4-door SUV Extended ('26- Cadillac Vistiq EV)
|-
|W||Class F: 7,001-8,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|X||Class F: 7,001-8,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|U||Class F: 7,001-8,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|Y||Class F: 7,001-8,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|V||Class F: 7,001-8,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '19 Chevy Silverado LD, GMC Sierra Limited, '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|U||Class F: 7,001-8,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|9||Class F: 7,001-8,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|Z||Class G: 8,001-9,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|W||Class G: 8,001-9,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'26 Chevy Express, GMC Savana)
|-
|Z||Class G: 8,001-9,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|W||Class G: 8,001-9,000||Hydraulic||06: Passenger Van ('11-'26 Chevy Express, GMC Savana)
|-
|Z||Class G: 8,001-9,000||Hydraulic||06: 4-door SUV ('10 Chevy Suburban 2500, GMC Yukon XL 2500)
|-
|W||Class G: 8,001-9,000||Hydraulic||06: 4-door SUV ('11-'13 Chevy Suburban 2500, GMC Yukon XL 2500)
|-
|2||Class H: 9,001-10,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|Z||Class H: 9,001-10,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'26 Chevy Express, GMC Savana,<br> '23-'24 BrightDrop Zevo 600, '24 BrightDrop Zevo 400, '25-'26 Chevrolet BrightDrop 400/600)
|-
|2||Class H: 9,001-10,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|Z||Class H: 9,001-10,000||Hydraulic||06: Passenger Van ('11-'26 Chevy Express, GMC Savana)
|-
|3||Class H: 9,001-10,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|0||Class H: 9,001-10,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
|3||Class H: 9,001-10,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|0||Class H: 9,001-10,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra)
|-
|4||Class H: 9,001-10,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|1||Class H: 9,001-10,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '24-'25 GMC Hummer EV pickup w/20 module battery pack,<br> '24-'26 Chevy Silverado EV, '25-'26 GMC Sierra EV)
|-
|5||Class H: 9,001-10,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|2||Class H: 9,001-10,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'13, '15-'26 Chevy Silverado, GMC Sierra)
|-
|B||Class H: 9,001-10,000||Hydraulic||26: 4-door SUV ('24-'25 GMC Hummer EV SUV)
|-
|6||Class 3: 10,001-14,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|3||Class 3: 10,001-14,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
|6||Class 3: 10,001-14,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|3||Class 3: 10,001-14,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra)
|-
|7||Class 3: 10,001-14,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|4||Class 3: 10,001-14,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22-'24 GMC Hummer EV pickup w/24 module battery pack, '25 GMC Hummer EV pickup w/20 or 24 module battery pack, '26 GMC Hummer EV pickup, '24-'25 Chevy Silverado EV, GMC Sierra EV)
|-
|8||Class 3: 10,001-14,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|5||Class 3: 10,001-14,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'13, '15-'18, '20-'26 Chevy Silverado, GMC Sierra)
|-
|8||Class 3: 10,001-14,000||Hydraulic||06: 4-door SUV ('16-'19, '24-'26 Chevy Suburban 3500HD)
|-
|8||Class 3: 10,001-14,000||Hydraulic||05: Cargo Van ('22 BrightDrop EV600, '23-'24 BrightDrop Zevo 600, '24 BrightDrop Zevo 400,<br> '25-'26 Chevrolet BrightDrop 400/600)
|-
|T||Class 3: 10,001-14,000||Hydraulic||26: 4-door SUV ('25-'26 GMC Hummer EV SUV, '25-'26 Cadillac Escalade IQ [EV])
|-
|L||Class 3: 10,001-14,000||Hydraulic||56: 4-door SUV Extended ('26- Cadillac Escalade IQL [EV])
|-
|9||Class 4: 14,001-16,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|6||Class 4: 14,001-16,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
| ||Class 5: 16,001-19,500||Hydraulic||
|}
====Line & Chassis Type 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Chevrolet HHR ('10-'11), HHR Panel ('10-'11)
|-
|A||Chevy Silverado 1500 2wd ('22-'26), Silverado HD 2500/3500 2wd ('25-'26)
|-
|B||Chevy Blazer 2wd & Awd '19-'26
|-
|C||Chevy Silverado 2wd ('10-'18), Silverado LD 1500 2wd '19, Silverado HD 2500/3500 2wd '19, GMC Sierra 2wd ('10)
|-
|C||Chevy Tahoe 2wd ('10-'24), Suburban 2wd ('10-'24), Avalanche 2wd ('10-'13),<br /> GMC Yukon 2wd ('10), Yukon XL 2wd ('10), Cadillac Escalade 2wd ('10), Escalade ESV 2wd ('10)
|-
|D||Chevy Silverado 1500 4wd ('22-'24)
|-
|D||Chevy Blazer EV ('24-'26), Chevy Equinox EV ('24-'26)
|-
|E||Cadillac Escalade IQ [EV] ('25-'26), Escalade IQL [EV] ('26-), GMC Hummer EV pickup ('26-), GMC Hummer EV SUV ('26-), GMC Sierra EV ('26-)
|-
|F||Chevy Bolt EV w/Rear Seat Delete pkg. - incomplete vehicle ('18-'23)
|-
|G||Cadillac Chassis for Limousine & for Armored Vehicle (Based on XTS '13-'19)
|-
|G||Cadillac Chassis for Hearse (Based on XTS '13-'19)
|-
|G||Chevy Express 2wd ('10-'26), GMC Savana 2wd ('10)
|-
|H||Chevy Express 4wd ('10-'14), GMC Savana 4wd ('10)
|-
|H||GMC Sierra 1500 2wd ('22-'26), Sierra HD 2500/3500 2wd ('25-'26)
|-
|H||Honda Prologue EV ('24-'26), Acura ZDX EV ('24)
|-
|J||Buick Encore 2wd & Awd ('13-'22), Chevy Trax 2wd & Awd (Canada: '13-'22, US: '15-'22)
|-
|J||BrightDrop EV600 ('22), BrightDrop Zevo 600 ('23-'24), BrightDrop Zevo 400 ('24), Chevrolet BrightDrop 400/600 ('25-'26)
|-
|K||Chevy Silverado 4wd ('10-'18), Silverado LD 1500 4wd ('19), Silverado HD 2500/3500 4wd ('19), GMC Sierra 4wd ('10)
|-
|K||Chevy Silverado 1500 4wd ('25-'26), Silverado HD 2500/3500 4wd ('25-'26)
|-
|K||Chevy Tahoe 4wd ('10-'24), Suburban 4wd ('10-'24), Suburban HD 4wd ('24-'26), Avalanche 4wd ('10-'13), GMC Yukon 4wd ('10), Yukon XL 4wd ('10),<br> Cadillac Escalade 4wd ('10), Escalade ESV 4wd ('10), Escalade EXT 4wd ('10)
|-
|K||Cadillac Professional Chassis for Limousine (Based on DTS '10-'11)
|-
|K||Cadillac Commercial Chassis for Hearse (Based on DTS '10-'11)
|-
|L||Chevy Equinox 2wd & Awd '10-'17, Captiva Sport 2wd '12-'15, Captiva Sport Awd '12, GMC Terrain 2wd & Awd '10-'17, Saturn Vue 2wd & Awd '10
|-
|L||GMC Terrain 2wd & Awd '18-'26
|-
|L||Buick Envista '24-'26, Chevy Trax '24-'26
|-
|M||Buick Encore GX 2wd & Awd ('20-'26), Chevy Trailblazer 2wd & Awd ('21-'26)
|-
|N||Cadillac SRX 2wd & Awd '10-'16, Saab 9-4X 2011
|-
|N||GMC Acadia 2wd & Awd '17-'26, Cadillac XT5 2wd & Awd '17-'26
|-
|N||Hummer H3, H3T 2010
|-
|P||Chevy Orlando (Canada only: '12-'14)
|-
|P||Cadillac XT6 2wd & Awd '20-'25
|-
|P||Cadillac Lyriq EV 2wd & Awd '23-'25
|-
|R||GMC Acadia 2wd '10-'16, Acadia Limited 2wd '17, Saturn Outlook 2wd '10, Buick Enclave 2wd '10-'17, Chevy Traverse 2wd '10-'17
|-
|R||Buick Enclave 2wd '18-'24, Chevy Traverse 2wd '18-'23
|-
|R||Buick Enclave 2wd '25-'26, Chevy Traverse 2wd '24-'26
|-
|S||Chevy Traverse Limited 2wd '24
|-
|S||Chevy Colorado 2wd ('10-'12, '15-'26), GMC Canyon 2wd ('10)
|-
|T||Chevy Colorado 4wd ('10-'12, '15-'26), GMC Canyon 4wd ('10)
|-
|T||Chevy Traverse Limited Awd '24
|-
|U||GMC Sierra 1500 4wd ('22-'26), Sierra HD 2500/3500 4wd ('25-'26)
|-
|V||GMC Acadia Awd '10-'16, Acadia Limited Awd '17, Saturn Outlook Awd '10, Buick Enclave Awd '10-'17, Chevy Traverse Awd '10-'17
|-
|V||Buick Enclave Awd '18-'24, Chevy Traverse Awd '18-'23
|-
|V||Buick Enclave Awd '25-'26, Chevy Traverse Awd '24-'26
|-
|W||Chevy Silverado 1500 2wd ('19-'21), Silverado LTD 1500 2wd ('22), Silverado HD 2500/3500 2wd ('20-'24)
|-
|X||Buick Envision 2wd & Awd '16-'20, Chevy Equinox 2wd & Awd '18-'26
|-
|Y||Chevy Silverado 1500 4wd ('19-'21), Silverado LTD 1500 4wd ('22), Silverado HD 2500/3500 4wd ('20-'24)
|-
|Z||Cadillac XT4 2wd & Awd '19-'25, Buick Envision 2wd '21-'23, Buick Envision Awd '21-'26
|-
|1||GMC Sierra 2wd ('11-'18), Sierra Limited 1500 2wd ('19), Sierra HD 2500/3500 2wd ('19), Yukon 2wd ('11-'26), Yukon XL 2wd ('11-'26)
|-
|1||GMC Canyon 2wd ('25-'26)
|-
|2||GMC Sierra 4wd ('11-'18), Sierra Limited 1500 4wd ('19), Sierra HD 2500/3500 4wd ('19), Yukon 4wd ('11-'26), Yukon XL 4wd ('11-'26)
|-
|2||GMC Canyon 4wd ('25-'26)
|-
|3||Cadillac Escalade 2wd ('11-'24), Escalade ESV 2wd ('11-'24)
|-
|3||Cadillac Optiq EV ('25-), Cadillac Vistiq EV ('26-)
|-
|4||Cadillac Escalade 4wd ('11-'24), Escalade ESV 4wd ('11-'24), Escalade EXT 4wd ('11-'13)
|-
|5||GMC Canyon 2wd ('11-'12, '15-'24)
|-
|5||Chevy Tahoe 2wd ('25-'26), Suburban 2wd ('25-'26)
|-
|6||GMC Canyon 4wd ('11-'12, '15-'24)
|-
|6||Chevy Tahoe 4wd ('25-'26), Suburban 4wd ('25-'26)
|-
|7||GMC Savana 2wd ('11-'26)
|-
|8||GMC Savana 4wd ('11-'14)
|-
|8||GMC Sierra 1500 2wd ('19-'21), Sierra Limited 1500 2wd ('22), Sierra HD 2500/3500 2wd ('20-'24)
|-
|8||Cadillac Escalade 2wd ('25-'26), Escalade ESV 2wd ('25-'26)
|-
|9||GMC Sierra 1500 4wd ('19-'21), Sierra Limited 1500 4wd ('22), Sierra HD 2500/3500 4wd ('20-'24)
|-
|9||Cadillac Escalade 4wd ('25-'26), Escalade ESV 4wd ('25-'26)
|-
|0||GMC Hummer EV pickup ('22-'25), GMC Hummer EV SUV ('24-'25), Chevy Silverado EV ('24-'26), GMC Sierra EV ('24-'25)
|}
====Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A (following L)||Saturn Vue XE 2wd ('10)
|-
|E (following L)||Saturn Vue XR V6 2wd ('10)
|-
|K (following L)||Saturn Vue XR-L V6 2wd ('10)
|-
|T (following R)||Saturn Outlook XE 2wd ('10)
|-
|U (following R)||Saturn Outlook XE Premium 2wd ('10)
|-
|V (following R)||Saturn Outlook XR-L 2wd ('10)
|-
|W (following R)||Saturn Outlook XR-L Premium 2wd ('10)
|-
|T (following V)||Saturn Outlook XE Awd ('10)
|-
|U (following V)||Saturn Outlook XE Premium Awd ('10)
|-
|V (following V)||Saturn Outlook XR-L Awd ('10)
|-
|W (following V)||Saturn Outlook XR-L Premium Awd ('10)
|-
|G (following N)||Hummer H3, H3T Base model ('10)
|-
|H (following N)||Hummer H3, H3T Adventure ('10)
|-
|J (following N)||Hummer H3, H3T Luxury ('10)
|-
|K (following N)||Hummer H3, H3T Alpha w/cloth ('10)
|-
|L (following N)||Hummer H3, H3T Alpha w/Leather ('10)
|-
|P (following N)||Saab 9-4X 3.0i 2wd ('11)
|-
|R (following N)||Saab 9-4X 3.0i Awd ('11)
|-
|S (following N)||Saab 9-4X 3.0i Premium 2wd ('11)
|-
|T (following N)||Saab 9-4X 3.0i Premium Awd ('11)
|-
|U (following N)||Saab 9-4X Aero Awd ('11)
|}
===Platform & Series Codes 1985- Passenger Car===
GM used a lettered system of automobile platform codes for three decades. These letters were used as the 4th position of the VIN. Though today's GM platforms use Greek characters, they are still encoded with Latin characters in the 4th position. Position 5 encodes the specific model and trim level of the vehicle.
{| border=1 style="margin:auto;"
!List of GM platforms
!Platform<br>Code
!Series<br>Code
!:Category:General Motors vehicles|Model
|-
|rowspan=14|GM A platform
|rowspan=14|A||W||Chevrolet Celebrity 1985-1990
|-
|E||Pontiac 6000 ''SE'' 1986-1988
|-
|F||Pontiac 6000 1985-1988, 6000 ''LE'' 1989-1991
|-
|G||Pontiac 6000 ''LE'' 1985-1988
|-
|H||Pontiac 6000 ''STE'' 1985-1989
|-
|J||Pontiac 6000 ''SE'' 1989-1991
|-
|G||Oldsmobile Cutlass Ciera ''S'' Sedan 1993-1994
|-
|J||Oldsmobile Cutlass Ciera ''LS'' 1985, Cutlass Ciera 1986-1989 & Cutlass Cruiser 1985-1989,<br /> Cutlass Ciera ''S'' Coupe 1986-1987, Cutlass Ciera ''S'' 1990-1991 & Cutlass Cruiser ''S'' 1990-1994, Cutlass Ciera ''SL'' & Cutlass Cruiser ''SL'' 1995, Ciera ''SL'' sedan & wagon 1996
|-
|L||Oldsmobile Cutlass Ciera 1990-1991, Cutlass Ciera ''S'' Sedan 1992
|-
|M||Oldsmobile Cutlass Ciera ''Brougham'' 1985-1988, Cutlass Ciera ''SL'' Coupe 1986-1989, Cutlass Ciera ''SL'' Sedan 1989-1993, Cutlass Cruiser ''Brougham'' 1987-1988, Cutlass Cruiser ''SL'' 1989-1993
|-
|S||Oldsmobile Cutlass Ciera ''International Series'' 1988-1990
|-
|G||Buick Century ''T-Type'' 1985-1986, Century ''Special'' 1991-1996
|-
|H||Buick Century ''Custom'' 1985-1995
|-
|L||Buick Century ''Limited'' 1985-1993, Century Estate Wagon 1986-1989
|-
|rowspan=14|GM B platform
|rowspan=14|B||L||Chevrolet Impala 1985, Caprice 1986-1992, Caprice Classic 1993-1996, Impala SS 1995-96
|-
|N||Chevrolet Caprice Classic 1985-1992, Caprice Classic LS 1993-1994,<br /> Caprice Classic LTZ 1991-1993, Impala SS 1994
|-
|U||Chevrolet Caprice Classic Brougham/Brougham LS 1987-1990
|-
|L||Pontiac Parisienne 1985-1986, Safari Wagon 1987-1989
|-
|T||Pontiac Parisienne Brougham 1985-1986
|-
|N||Oldsmobile Delta 88 Royale 1985
|-
|P||Oldsmobile Custom Cruiser 1985-1992
|-
|V||Oldsmobile Delta 88 Royale Brougham LS 1985
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1985
|-
|N||Buick Le Sabre ''Custom'' 1985, Roadmaster sedan 1992-1996
|-
|P||Buick Le Sabre ''Limited'' 1985
|-
|R||Buick Le Sabre Estate Wagon 1985-1989, Estate Wagon 1990,<br /> Roadmaster Estate Wagon 1991-1996
|-
|T||Buick Roadmaster ''Limited'' sedan 1992-1996
|-
|V||Buick Electra Estate Wagon 1985-1989
|-
|rowspan=13|GM C platform - front-wheel drive
|rowspan=13|C
|V||Oldsmobile Touring Sedan 1988-1990, 98 Touring Sedan 1991-1993
|-
|W||Oldsmobile 98 Regency Brougham 1985-1990, 98 Regency Elite 1991-1996
|-
|X||Oldsmobile 98 Regency 1985-1990, 1992-1994
|-
|F||Buick Electra T-Type 1985-1990
|-
|U||Buick Electra Park Avenue Ultra 1989-1990, Park Avenue Ultra 1991-1996
|-
|W||Buick Electra Park Avenue 1985-1990, Park Avenue 1991-1996
|-
|X||Buick Electra 1985-1986, Electra Limited 1987-1990
|-
|B||1985-1992 Cadillac Fleetwood, Fleetwood D'Elegance, 1993 Cadillac Sixty Special
|-
|D||1985-1993 Cadillac DeVille
|-
|G||1991-1992 Cadillac Fleetwood Sixty Special
|-
|H||1985-1987 Cadillac Fleetwood Limousine
|-
|S||1987-1990 Cadillac Fleetwood Sixty Special
|-
|T||1991-1993 Cadillac DeVille Touring Sedan
|-
|rowspan=3|GM G platform (models formerly on C platform)
|rowspan=3|C
|-
|U||Buick Park Avenue Ultra 1997-2005
|-
|W||Buick Park Avenue 1997-2005
|-
|rowspan=2|GM D platform
|rowspan=2|D||W||1985-1986 Cadillac Fleetwood Brougham, 1987-1992 Cadillac Brougham
|-
|W||1993-1996 Cadillac Fleetwood
|-
|rowspan=31|GM Delta I platform
|rowspan=31|A
|-
|A||Chevrolet Cobalt LS w/manual trans. 2010
|-
|B||Chevrolet Cobalt LS w/automatic trans. 2010
|-
|C||Chevrolet Cobalt 1LT w/manual trans. 2010
|-
|D||Chevrolet Cobalt 1LT w/automatic trans. 2010
|-
|E||Chevrolet Cobalt 2LT w/manual trans. 2010
|-
|F||Chevrolet Cobalt 2LT w/automatic trans. 2010
|-
|G||Chevrolet Cobalt SS Turbo 2010
|-
|H||Chevrolet Cobalt (base model w/XFE) 2010
|-
|K||Chevrolet Cobalt (base model) 2005, Cobalt LS 2006-2008, Cobalt LS w/man. trans. 2009
|-
|L||Chevrolet Cobalt LS 2005, Cobalt LT 2006-2008, Cobalt LT w/manual trans. 2009
|-
|M||Chevrolet Cobalt SS 2006-2007, Cobalt Sport 2008
|-
|P||Chevrolet Cobalt SS Supercharged 2005-2007, SS Turbo 2008-2009
|-
|S||Chevrolet Cobalt LS w/automatic trans. 2009
|-
|T||Chevrolet Cobalt LT w/automatic trans. 2009
|-
|Z||Chevrolet Cobalt LT 2005, Cobalt LTZ 2006-2007
|-
|L||Pontiac G5 2007-2008, G5 w/manual trans. 2009
|-
|N||Pontiac G5 GT 2007-2008, G5 GT w/manual trans. 2009
|-
|S||Pontiac G5 w/automatic trans. 2009
|-
|T||Pontiac G5 GT w/automatic trans. 2009
|-
|F||Saturn Ion sedan Level 1 w/manual trans. 2003-2005
|-
|G||Saturn Ion sedan Level 1 w/automatic trans. 2003-2005
|-
|J||Saturn Ion sedan Level 2 w/automatic trans. 2003-2007
|-
|K||Saturn Ion sedan Level 3 w/manual trans. 2003-2007
|-
|L||Saturn Ion sedan Level 3 w/automatic trans. 2003-2007
|-
|M||Saturn Ion coupe Level 2 w/manual trans. 2003-2007
|-
|N||Saturn Ion coupe Level 2 w/automatic trans. 2003-2007
|-
|V||Saturn Ion coupe Level 3 w/manual trans. 2003-2007
|-
|W||Saturn Ion coupe Level 3 w/automatic trans. 2003-2007
|-
|Y||Saturn Ion coupe Red Line 2004-2007
|-
|Z||Saturn Ion sedan Level 2 w/manual trans. 2003-2007
|-
|rowspan=9|GM E platform
|rowspan=9|E
|-
|V||Oldsmobile Toronado Trofeo 1988-1992
|-
|Z||Oldsmobile Toronado Brougham 1985-1986, Toronado 1987-1992
|-
|C||Buick Reatta 1988-1991
|-
|Y||Buick Riviera T-Type 1985-1986
|-
|Z||Buick Riviera 1985-1993
|-
|C||Cadillac Eldorado Collector Series 2002
|-
|L||Cadillac Eldorado 1985-2002
|-
|T||Cadillac Eldorado Touring Coupe 1994-2002
|-
|rowspan=26|GM Epsilon I platform
|rowspan=26|Z||A||Chevrolet Malibu Fleet 2010-2012
|-
|B||Chevrolet Malibu LS 2010-2012
|-
|C||Chevrolet Malibu 1LT 2010-2012
|-
|D||Chevrolet Malibu 2LT 2010-2012
|-
|E||Chevrolet Malibu LTZ 2010-2011, Malibu 1LZ 2012
|-
|F||Chevrolet Malibu Hybrid 2008-2010, Malibu 3LT 2012
|-
|G||Chevrolet Malibu LS 2008-2009, Malibu 2LZ 2012
|-
|H||Chevrolet Malibu 1LT 2008-2009
|-
|J||Chevrolet Malibu 2LT 2008-2009
|-
|K||Chevrolet Malibu LTZ 2008-2009
|-
|S||Chevrolet Malibu 2004-2005, Malibu LS 2006-2007, Malibu Classic LS 2008
|-
|T||Chevrolet Malibu LS 2004-2005, Malibu LT 2006-2007, Malibu Classic LT 2008
|-
|U||Chevrolet Malibu LT 2004-2005, Malibu LTZ 2006-2007
|-
|W||Chevrolet Malibu SS 2006-2007
|-
|A||Pontiac G6 Sedan 2010
|-
|F||Pontiac G6 2.4L Sedan (Base model) 2006, G6 Value Leader (Base model w/1SV) 2007-2008
|-
|G||Pontiac G6 3.5L Sedan (Base model) 2005-2006, G6 (Base model) 2007-2009
|-
|H||Pontiac G6 GT 2005-2009
|-
|J||Pontiac G6 (Base model) 2009 1/2 (Mid-Cycle Revision)
|-
|K||Pontiac G6 GT 2009 1/2 (Mid-Cycle Revision)
|-
|L||Pontiac G6 GXP 2009 1/2 (Mid-Cycle Revision)
|-
|M||Pontiac G6 GTP 2006-2007, G6 GXP 2008-2009
|-
|R||Saturn Aura Green Line 2007-2009
|-
|S||Saturn Aura XE 2007-2009
|-
|V||Saturn Aura XR 2007-2008, Aura XR 2.4L 2009
|-
|X||Saturn Aura XR V6 2009
|-
|rowspan=6|GM F platform
|rowspan=6|F||P||Chevrolet Camaro Sport Coupe 1985-2002, Convertible 1987-1992, 1994-2002
|-
|S||Chevrolet Camaro Berlinetta 1985-1986
|-
|S||Pontiac Firebird 1985-2002, Firebird ''Formula'' 1987-1992
|-
|V||Pontiac Firebird ''Formula / Trans Am'' 1993-2002, Firebird ''Trans Am GT'' 1994
|-
|W||Pontiac Firebird ''Trans Am'' 1985-1992, Firebird ''Trans Am GTA'' 1987-1992
|-
|X||Pontiac Firebird ''S/E'' 1985-1986
|-
|rowspan=13|GM G platform - rear-wheel drive
|rowspan=13|G||Z||Chevrolet Monte Carlo 1985-1988
|-
|J||Pontiac Grand Prix 1985-1987
|-
|K||Pontiac Grand Prix LE 1985-1987
|-
|N||Pontiac Bonneville 1985-1986
|-
|P||Pontiac Grand Prix Brougham 1985-1987
|-
|R||Pontiac Bonneville Brougham 1985-1986
|-
|S||Pontiac Bonneville LE 1985-1986
|-
|K||Oldsmobile Cutlass Salon coupe 1985-1987
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1985-1987,<br /> Cutlass Supreme Classic ''Brougham'' 1988
|-
|R||Oldsmobile Cutlass Supreme 1985-1987, Cutlass Supreme Classic 1988
|-
|J||Buick Regal 1985-1987
|-
|K||Buick Regal T-Type 1985-1987
|-
|M||Buick Regal ''Limited'' 1985-1987
|-
|rowspan=4|GM G platform - front-wheel drive
|rowspan=4|G||D||1995-1999 Buick Riviera
|-
|R||1995-1999 Oldsmobile Aurora
|-
|R||2001-2002 Oldsmobile Aurora 3.5
|-
|S||2001-2003 Oldsmobile Aurora 4.0
|-
|rowspan=9|GM H platform
|rowspan=9|H||H||Buick Le Sabre 1987
|-
|P||Buick Le Sabre ''Custom'' 1986-1999
|-
|R||Buick Le Sabre ''Limited'' 1986-1999
|-
|C||Oldsmobile Regency 1997-1998, Eighty Eight 50th Anniversary Edition 1999
|-
|N||Oldsmobile Delta 88 Royale 1986-1988, 88 Royale 1989-1995, Eighty Eight & Eighty Eight LS 1996-99
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1986-1988, 88 Royale Brougham 1989-91, Eighty Eight Royale LS 1992-1995, LSS 1996-1999
|-
|X||Pontiac Bonneville 1987, Bonneville LE 1988-1991, Bonneville ''SE'' 1992-1999
|-
|Y||Pontiac Bonneville SSE 1988-1991, Bonneville ''SSEi'' 1992-1993
|-
|Z||Pontiac Bonneville LE 1987, Bonneville SE 1988-1991, Bonneville ''SSE'' 1992-1999, Bonneville ''SSEi'' 1994-1999
|-
|rowspan=17|GM G platform (models formerly on H platform or their successors)
|rowspan=17|H||A||Buick Lucerne ''CX'' 2010-2011
|-
|B||Buick Lucerne ''CX-2'' 2010
|-
|C||Buick Lucerne ''CXL'' 2010-2011
|-
|D||Buick Lucerne ''CXL V6'' 2006-2009, Lucerne ''CXL Special Edition'' 2010
|-
|E||Buick Lucerne ''CXS'' 2006-2008, Lucerne ''CXL-3'' 2010
|-
|F||Buick Lucerne ''Super'' 2008-2009, Lucerne ''CXL-4'' 2010
|-
|G||Buick Lucerne ''CXL-5'' 2010
|-
|H||Buick Lucerne ''Super 1SP'' 2010
|-
|J||Buick Lucerne ''CXL Premium'' 2010-2011
|-
|K||Buick Lucerne ''Super 1XS'' 2010, Lucerne ''Super'' 2011
|-
|P||Buick Lucerne ''CX'' 2006-2009
|-
|R||Buick Lucerne ''CXL V8'' 2006-2007, Lucerne ''CXL Special Edition V8'' 2008
|-
|P||Buick Le Sabre ''Custom'' 2000-2005
|-
|R||Buick Le Sabre ''Limited'' 2000-2005
|-
|X||Pontiac Bonneville ''SE'' 2000-2005
|-
|Y||Pontiac Bonneville ''SLE'' 2000-2005
|-
|Z||Pontiac Bonneville ''SSEi'' 2000-2003, Bonneville GXP 2004-2005
|-
|rowspan=23|GM J platform
|rowspan=23|J
|-
|C||Chevrolet Cavalier 1985-1994, RS Convertible 1991-1994
|-
|D||Chevrolet Cavalier CS 1985-1987
|-
|E||Chevrolet Cavalier Type 10 1985, RS 1986-1988,<br /> Type 10 Convertible 1985, RS Convertible 1986-1987
|-
|F||Chevrolet Cavalier Z24 1986-1994, Z24 Convertible 1988-1989, 1992-1994
|-
|C||Chevrolet Cavalier 1995-2005, Cavalier RS 1997-1999
|-
|F||Chevrolet Cavalier LS Sedan 1995-2005, LS Coupe 2003-2005, Z24 Coupe 1995-2001,<br /> LS Convertible 1995-1997, Z24 Convertible 1998-2000
|-
|H||Chevrolet Cavalier Z24 Coupe/Sedan 2002, LS Sport 2002-2005
|-
|S||Chevrolet Cavalier LS Coupe 2002
|-
|B||Pontiac Sunbird 1985-1989, Sunbird LE 1990-1991, Sunbird SE 1992-1993,<br /> Sunbird LE 1994
|-
|C||Pontiac Sunbird LE 1985, Sunbird 1991, Sunbird LE 1992-1993
|-
|D||Pontiac Sunbird SE 1985-1991, Sunbird GT 1992-1993
|-
|L||Pontiac Sunbird SE 1994
|-
|U||Pontiac Sunbird GT 1986-1991
|-
|B||Pontiac Sunfire SE 1995-2002, Convertible 1995-2000, Sunfire 2003-2005
|-
|D||Pontiac Sunfire GT 1995-2002
|-
|C||Oldsmobile Firenza Base model 1985-1987, Firenza S 1985-1987, Firenza 1988
|-
|D||Oldsmobile Firenza LX 1985-1987, Firenza SX 1985, Firenza LC, GT 1986-1987
|-
|E||Buick Skyhawk T-Type 1985-1986
|-
|S||Buick Skyhawk Custom 1985-1987, Skyhawk Sport 1986-1987, Skyhawk 1988-1989
|-
|T||Buick Skyhawk Limited 1985-1987
|-
|G||Cadillac Cimarron 1985-1988
|-
|G, H||Toyota Cavalier (Japan only)
|-
|rowspan=8|GM2900 platform
|rowspan=8|J||C||Saturn L-Series|2004 Saturn L300.1
|-
|D||Saturn L-Series|2004 Saturn L300.2, 2005 Saturn L300
|-
|L||Saturn L-Series|2004 Saturn L300.3
|-
|R||Saturn L-Series|Saturn LS w/manual transmission '00/L100 w/manual transmission '01
|-
|S||Saturn L-Series|Saturn LS w/automatic transmission '00/L100 w/automatic transmission '01-'02
|-
|T||Saturn L-Series|Saturn LS1 w/manual transmission '00/L200 w/manual transmission '01-'03, LW200 w/manual trans. '02
|-
|U||Saturn L-Series|Saturn LS1 w/automatic transmission '00/L200 w/automatic transmission '01-'03,<br> Saturn LW1 w/automatic transmission '00/LW200 w/automatic transmission '01-'03
|-
|W||Saturn L-Series|Saturn LS2 '00, LW2 '00, L300 '01-'03, LW300 '01-'03
|-
|rowspan=5|GM K platform
|rowspan=5|K||D||Cadillac Deville 1994-1999
|-
|E||Cadillac Deville D'Elegance 1997-1999
|-
|F||Cadillac Deville Concours 1994-1999
|-
|S||Cadillac Seville 1985-1993 / Cadillac Seville SLS 1994-1997
|-
|Y||Cadillac Seville Touring Sedan / Cadillac Seville STS 1990-1997
|-
|rowspan=9|GM G platform (models formerly on K platform)
|rowspan=9|K||A||2010-2011 Cadillac DTS
|-
|D||2000-2005 Cadillac Deville, 2006-2009 Cadillac DTS, 2010-2011 DTS Luxury
|-
|E||2000-2005 Cadillac Deville DHS
|-
|F||2000-2005 Cadillac Deville DTS
|-
|H||2010-2011 Cadillac DTS Premium
|-
|P||2010-2011 Cadillac DTS Platinum
|-
|R||2010-2011 Cadillac DTS Livery
|-
|S|| 1998-2004 Cadillac Seville SLS
|-
|Y|| 1998-2003 Cadillac Seville STS
|-
|rowspan=33|GM Kappa platform
|rowspan=33|M||A||Pontiac Solstice w/automatic transmission 2010
|-
|B||Pontiac Solstice 2006-2007, Solstice w/manual transmission 2008-2009
|-
|B||Pontiac Solstice GXP w/automatic transmission 2010
|-
|C||Pontiac Solstice w/automatic transmission 2008
|-
|D||Pontiac Solstice w/manual transmission 2010
|-
|E||Pontiac Solstice GXP w/manual transmission 2010
|-
|F||Pontiac Solstice GXP w/automatic transmission 2008
|-
|G||Pontiac Solstice GXP 2007, Solstice GXP w/manual transmission 2008-2009
|-
|K||Pontiac Solstice Street Edition w/manual transmission 2009
|-
|N||Pontiac Solstice w/automatic transmission 2009
|-
|S||Pontiac Solstice SCCA SSB Championship Edition (2.4L) 2008
|-
|T||Pontiac Solstice SCCA T2 Championship Edition (2.0L Turbo) 2008
|-
|T||Pontiac Solstice GXP w/automatic transmission 2009
|-
|Z||Pontiac Solstice Street Edition w/automatic transmission 2009
|-
|B||Saturn Sky 2007, Sky w/manual transmission 2008-2009
|-
|B||Saturn Sky Redline w/automatic transmission 2010
|-
|C||Saturn Sky w/automatic transmission 2008
|-
|C||Saturn Sky Ruby Red (Merlot Jewel) Special Edition w/manual transmission 2009
|-
|C||Saturn Sky Preferred w/automatic transmission 2010
|-
|D||Saturn Sky Hydro Blue Special Edition w/manual transmission 2009
|-
|E||Saturn Sky Redline w/manual transmission 2010
|-
|F||Saturn Sky Redline w/automatic transmission 2008
|-
|F||Saturn Sky Preferred w/manual transmission 2010
|-
|G||Saturn Sky Redline 2007, Sky Redline w/manual transmission 2008-2009
|-
|H||Saturn Sky Redline Ruby Red (Merlot Jewel) Special Edition w/manual transmission 2009
|-
|L||Saturn Sky Redline Hydro Blue Special Edition w/manual transmission 2009
|-
|N||Saturn Sky w/automatic transmission 2009
|-
|P||Saturn Sky Ruby Red (Merlot Jewel) Special Edition w/automatic transmission 2009
|-
|R||Saturn Sky Hydro Blue Special Edition w/automatic transmission 2009
|-
|T||Saturn Sky Redline w/automatic transmission 2009
|-
|V||Saturn Sky Redline Ruby Red (Merlot Jewel) Special Edition w/automatic transmission 2009
|-
|X||Saturn Sky Redline Hydro Blue Special Edition w/automatic transmission 2009
|-
|G||Opel GT 2007-2010, Daewoo G2X 2007-2009
|-
|rowspan=8|GM L platform
|rowspan=8|L
|-
|D||Chevrolet Corsica ''Base'' 1994-1996
|-
|T||Chevrolet Corsica ''Base'' 1987-1989, Corsica ''LT'' 1990-1993
|-
|V||Chevrolet Beretta ''Base'' 1987-1996
|-
|W||Chevrolet Beretta "GT" 1989-1993 (RPO Z21) & Beretta ''Z26'' 1994-1996 (RPO Z04)
|-
|Z||Chevrolet Corsica ''LTZ'' 1989-1990 (RPO Z54)
|-
|Z||Chevrolet Beretta "GTZ" 1990-1993 (RPO Z04)
|-
|T||Pontiac Tempest (Canada only)
|-
|rowspan=5|GM M platform
|rowspan=5|M||R||Chevrolet Sprint
|-
|R||Geo Metro LSi, Metro
|-
|R||Pontiac Firefly (Canada only)
|-
|S||Chevrolet Sprint ER
|-
|S||Geo Metro, Metro XFi
|-
|rowspan=32|GM N platform
|rowspan=32|N
|-
|B||Oldsmobile Cutlass 1997, Cutlass ''GL'' 1998-1999
|-
|C||Buick Skylark 4-door ''Custom'' 1987-1991
|-
|D||Buick Skylark 4-door ''Limited'' 1987-1989, Skylark 4-door ''Luxury Edition'' 1990-1991
|-
|D||Chevrolet Malibu 1997-2003, Chevrolet Classic 2004-2005
|-
|E||Chevrolet Malibu ''LS'' 1997-2003
|-
|E||Pontiac Grand Am 1985-1988, Grand Am ''LE'' 1989-1991
|-
|E||Pontiac Grand Am ''SE'' 1992-2005
|-
|F||Oldsmobile Calais 1985-1987, Cutlass Calais 1988, Cutlass Calais ''S'' 1989-1991
|-
|F||Oldsmobile Achieva ''SL'' 1992-1994, Achieva ''SC'' 1994
|-
|F||Oldsmobile Alero ''GLS'' 1999-2004
|-
|F||Pontiac Grand Am ''SE1'' 2000-2004
|-
|G||Oldsmobile Cutlass ''GLS'' 1997-1999
|-
|G||Pontiac Grand Am 1991
|-
|G||Pontiac Grand Am ''SE2'' 2000, 2003-2004
|-
|J||Buick Somerset Regal 1985, Somerset ''Custom'' 1986-1987, Skylark 2-door ''Custom'' 1988-91, Skylark 4-door ''Custom'' 1986
|-
|J||Buick Skylark 1992, Skylark ''Limited'' 1993-1994, Skylark ''Custom'' 1996-1998,<br /> Skylark ''Limited'' & ''Gran Sport'' 1996-1997
|-
|K||Buick Somerset ''T-Type'' 1986
|-
|K||Oldsmobile Cutlass Calais ''International Series'' 1988-1991
|-
|K||Oldsmobile Alero ''GX'' 1999-2004
|-
|L||Oldsmobile Cutlass Calais 1989-1991
|-
|L||Oldsmobile Achieva ''S'' 1992-1995, Achieva ''SL'' 1996-1998, Achieva ''SC'' 1996-1997
|-
|L||Oldsmobile Alero ''GL'' 1999-2004
|-
|M||Buick Somerset Regal ''Limited'' 1985, Somerset ''Limited'' 1986-'87, Skylark 2-door ''Limited'' '88-'89, Skylark 2-door ''Gran Sport'' 1990-1991, Skylark 4-door ''Limited'' 1986
|-
|M||Buick Skylark ''Gran Sport'' 1992-1994
|-
|T||Oldsmobile Calais ''Supreme'' 1985-1987, Cutlass Calais ''SL'' 1988-1991
|-
|V||Buick Skylark 1990-1991
|-
|V||Buick Skylark ''Custom'' 1993-1995, ''Limited'' 1995, ''Gran Sport'' 1995
|-
|V||Pontiac Grand Am ''LE'' 1985-1988
|-
|V||Pontiac Grand Am ''GT1'' 2000-2005
|-
|W||Pontiac Grand Am ''SE'' 1986-1991
|-
|W||Pontiac Grand Am ''GT'' 1992-2005
|-
|rowspan=5|GM P platform - rear-wheel drive
|rowspan=5|P
|-
||E||Pontiac Fiero ''Coupe'' 1985-1988
|-
||F||Pontiac Fiero ''SE'' 1985-1987
|-
||G||Pontiac Fiero ''GT'' 1985-1988
|-
||M||Pontiac Fiero ''Sport coupe'' 1985-1987
|-
|rowspan=1|GM P platform - front-wheel drive
|rowspan=1|P||X||General Motors EV1 1997, 1999
|-
|rowspan=6|GM R platform
|rowspan=6|R
|-
||F||1985-1986 Chevrolet Spectrum
|-
||F||1987-1988 Chevrolet Spectrum 3-door hatchback, 1989 Geo Spectrum 3-door hatchback
|-
||F||1990-1993 Geo Storm
|-
||G||1987-1988 Chevrolet Spectrum 4-door sedan, 1989 Geo Spectrum 4-door sedan
|-
||T||1990-1993 Geo Storm GSi
|-
|rowspan=8|GM S platform
|rowspan=8|S||K||1985-1988 Chevrolet Nova
|-
|K||1989-1997 Geo Prizm, 1998-2002 Chevrolet Prizm
|-
|L||1988 Chevrolet Nova Twin Cam, 1990-1992 Geo Prizm GSi
|-
|L||2003-2008 Pontiac Vibe, 2009-2010 Pontiac Vibe FWD w/manual transmission
|-
|M||2003-2006 Pontiac Vibe ''AWD'', 2009-2010 Pontiac Vibe AWD w/automatic transmission
|-
|N||2003-2006 Pontiac Vibe ''GT'', 2009-2010 Pontiac Vibe GT FWD w/manual transmission
|-
|P||2009-2010 Pontiac Vibe FWD w/automatic transmission
|-
|R||2009-2010 Pontiac Vibe GT FWD w/automatic transmission
|-
|rowspan=32|GM Sigma platform
|rowspan=32|D||A||Cadillac CTS Base model RWD 2010-2013, CTS Coupe Base model RWD 2014
|-
|B||Cadillac CTS Wagon Luxury Collection RWD 2014
|-
|C||Cadillac CTS Base model AWD 2010-2013, CTS Coupe/Wagon Performance Collection RWD 2014
|-
|D||Cadillac CTS Coupe/Wagon Premium Collection RWD 2014
|-
|E||Cadillac CTS Luxury Collection RWD 2010-2013, CTS Coupe Base model AWD 2014
|-
|F||Cadillac CTS Auto. Trans. RWD 2008-2009, CTS Luxury Collection RWD w/Navigation 2010-2013, CTS Wagon Luxury Collection AWD 2014
|-
|G||Cadillac CTS Auto. Trans. AWD 2008-2009, CTS Luxury Collection AWD 2010-2013, CTS Coupe/Wagon Performance Collection AWD 2014
|-
|H||Cadillac CTS Auto. Trans. AWD w/Navigation 2008-2009, CTS Luxury Collection AWD w/Navigation 2010-2013, CTS Coupe/Wagon Premium Collection AWD 2014
|-
|J||Cadillac CTS Auto. Trans. RWD w/Navigation 2008-2009, CTS Performance Collection RWD 2010-2013
|-
|K||Cadillac CTS Performance Collection RWD w/Navigation 2010-2013
|-
|L||Cadillac CTS Performance Collection AWD 2010-2013
|-
|M||Cadillac CTS V6 2003-2004, CTS 2.8L 2005-2007, CTS Man. Trans. RWD 2008-2009, CTS Performance Collection AWD w/Navigation 2010-2013
|-
|N||Cadillac CTS V-Series 2004-2007, 2009
|-
|P||Cadillac CTS 3.6L 2005-2007, CTS Direct Inj. V6 Man. Trans. RWD 2008-2009, CTS Premium Collection RWD w/Navigation 2010-2013
|-
|R||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD 2008
|-
|S||Cadillac CTS Direct Inj. V6 Auto. Trans. AWD 2008-2009, CTS Premium Collection AWD w/Navigation 2010-2013
|-
|T||Cadillac CTS Direct Inj. V6 Auto. Trans. AWD w/Navigation 2008-2009
|-
|U||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD 2009
|-
|V||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD w/Navigation 2008-2009, CTS sedan V-Series 2010-2014, CTS Wagon V-Series 2011-2014, CTS Coupe V-Series 2011-2015
|-
|0||Cadillac CTS Sport Appearance Pkg. 2010
|-
|1||Cadillac CTS Eco Luxury Pkg. 2010
|-
|2||Cadillac CTS Sport Appearance Pkg. 2011
|-
|A||Cadillac STS V6 AWD 2008-2009
|-
|B||Cadillac STS V8 AWD 2008-2009
|-
|C||Cadillac STS V8 2005-2007, STS V8 RWD 2008-2009
|-
|D||Cadillac STS V6 AWD w/Navigation 2008-2009
|-
|K||Cadillac STS V6 RWD w/Navigation 2008-2009
|-
|L||Cadillac STS V8 AWD w/Navigation 2008-2009
|-
|U||Cadillac STS (all models) 2010, STS (Base model) 2011
|-
|W||Cadillac STS V6 2005-2007, STS V6 RWD 2008-2009, STS Luxury 2011
|-
|X||Cadillac STS V-Series 2006-2009, STS Luxury Performance 2011
|-
|Z||Cadillac STS V8 RWD w/Navigation 2008-2009
|-
|rowspan=4|GM T platform - rear-wheel drive
|rowspan=4|T||B|| 1985-1987 Chevrolet Chevette CS
|-
|B||1985-1987 Pontiac Acadian (Canada only)
|-
|J||1985 Pontiac Acadian Scooter (Canada only)
|-
|L||1985-1987 Pontiac 1000
|-
|rowspan=4|GM T platform - front-wheel drive
|rowspan=4|T||N|| Pontiac LeMans 1988, LeMans LE 1989-1991, LeMans SE 1992-1993
|-
|R||1988-1989 Pontiac LeMans SE sedan
|-
|S||1988-1990 Pontiac LeMans GSE AeroCoupe
|-
|X||1988-1993 Pontiac LeMans VL AeroCoupe
|-
|rowspan=3|GM T platform - front-wheel drive
|rowspan=3|A
|-
|R||Saturn Astra XE (US: 2008, Canada: 2008-2009)
|-
|T||Saturn Astra XR (US: 2008, Canada: 2008-2009)
|-
|rowspan=4|Daewoo T200 platform
|rowspan=4|T||D||Chevrolet Aveo Special Value 2004-2008, Base model 2004, LS 2005-2011, Aveo 1LT 2009-2011
|-
|G||Chevrolet Aveo LT 2005-2008, Aveo 2LT 2009-2011
|-
|J||Chevrolet Aveo LS 2004
|-
|D||Pontiac G3 2009
|-
|rowspan=2|GM V platform - front-wheel drive
|rowspan=2|V||R||1987-1992 Cadillac Allanté with standard removable hardtop
|-
|S||1990-1993 Cadillac Allanté
|-
|rowspan=2|GM V platform - rear-wheel drive
|rowspan=2|V||R||1997-2001 Cadillac Catera
|-
|X||2004-2006 Pontiac GTO coupe
|-
|rowspan=49|GM W platform
|rowspan=49|W
|-
|A||Chevrolet Impala ''LS'' 2010-2013, Impala Limited ''LS'' 2014-2016
|-
|B||Chevrolet Impala ''LS'' 2006-2009, Impala ''LT'' 2010-2013, Impala Limited ''LT'' 2014-2016
|-
|C||Chevrolet Impala ''LT'' 3.9L 2006-2009, Impala ''LTZ'' 2010-2013, Impala Limited ''LTZ'' 2014-2016
|-
|D||Chevrolet Impala ''SS'' 2006-2009, Impala ''Police'' 2010-2013, Impala Limited ''Police'' 2014-2016
|-
|E||Chevrolet Impala ''Taxi'' 2010-2012
|-
|F||Chevrolet Impala 2000-2005, Impala ''LS'' Fleet (1FL) 2011-2013
|-
|G||Chevrolet Impala ''LT'' Fleet (2FL) 2011-2013
|-
|H||Chevrolet Impala ''LS'' 2000-2005
|-
|J||Chevrolet Monte Carlo ''LS'' 2006-2007
|-
|K||Chevrolet Monte Carlo ''LT'' 3.9L 2006, Monte Carlo ''LT'' 3.5L 2007
|-
|L||Chevrolet Lumina 1990-2001, Lumina ''LS'' 1997-1999
|-
|L||Chevrolet Monte Carlo ''SS'' 2006-2007
|-
|M||Chevrolet Monte Carlo ''LT'' 3.5L 2006
|-
|N||Chevrolet Lumina ''Euro'' 1990-1994, Lumina ''LS'' 1995-1996, Lumina ''LTZ'' 1997-1999
|-
|N||Chevrolet Monte Carlo ''LTZ'' 2006
|-
|P||Chevrolet Lumina ''Z34'' 1991-1994, Impala ''SS'' 2004-2005
|-
|S||Chevrolet Impala ''Police'' 2006-2009
|-
|T||Chevrolet Impala ''LT'' 3.5L 2006-2009
|-
|U||Chevrolet Impala ''LTZ'' 2006-2009
|-
|V||Chevrolet Impala ''50th Anniversary Edition'' 2008
|-
|W||Chevrolet Monte Carlo ''LS'' 1995-2005
|-
|X||Chevrolet Monte Carlo ''Z34'' 1995-1999, Monte Carlo ''SS'' 2000-2004, Monte Carlo ''LT'' 2005
|-
|Z||Chevrolet Monte Carlo ''SS Supercharged'' 2004-2005
|-
|C||Pontiac Grand Prix ''GXP'' 2005-2008
|-
|H||Pontiac Grand Prix ''LE'' 1991-1993
|-
|J||Pontiac Grand Prix 1988-1989, Grand Prix ''LE'' 1990, Grand Prix ''SE'' 1991-2000
|-
|K||Pontiac Grand Prix ''LE'' 1988-1989, Grand Prix ''SE1'' 2000-2003
|-
|P||Pontiac Grand Prix ''SE'' 1988-1990, Grand Prix ''GT'' 1991-1993, 1997-2003,<br /> Grand Prix ''GT1'' 2004, Grand Prix 2005-2008
|-
|R||Pontiac Grand Prix ''GTP'' 1999-2005, Grand Prix ''GT'' 2006-2007
|-
|S||Pontiac Grand Prix ''GT2'' 2004, Grand Prix ''GT'' 2005
|-
|T||Pontiac Grand Prix ''STE'' 1990-1993
|-
|H||Oldsmobile Cutlass Supreme 1988-1991, Cutlass Supreme ''S'' 1992-1994,<br /> Cutlass Supreme ''SL'' 1995-1997, Intrigue 1998, Intrigue ''GX'' 1999-2002
|-
|R||Oldsmobile Cutlass Supreme ''International Series'' 1988-1993
|-
|S||Oldsmobile Cutlass Supreme ''SL'' 1988-1991, Intrigue ''GL'' 1998-2002
|-
|T||Oldsmobile Cutlass Supreme Convertible 1990-1995
|-
|X||Oldsmobile Intrigue ''GLS'' 1998-2002
|-
|B||Buick Regal ''Custom'' 1988-1996, Regal ''GS'' Coupe 1995-1996, Regal ''LS'' 1997-2004
|-
|C||Buick Lacrosse ''CX'' 2005-2009
|-
|D||Buick Regal ''Limited'' 1988-1996, Lacrosse ''CXL'' 2005-2009
|-
|E||Buick Lacrosse ''CXS'' 2005-2008
|-
|F||Buick Regal ''GS'' Coupe 1992-1994, Regal ''GS'' Sedan 1992-2004
|-
|F||Buick Allure ''CX'' 2005-2009 (Canada only)
|-
|H||Buick Allure ''CXS'' 2005-2008 (Canada only)
|-
|J||Buick Allure ''CXL'' 2005-2009 (Canada only)
|-
|N||Buick Lacrosse ''Super'' 2008-2009
|-
|P||Buick Allure ''Super'' 2008-2009 (Canada only)
|-
|S||Buick Century ''Custom'' 1997-2005
|-
|Y||Buick Century ''Limited'' 1997-2002
|-
|rowspan=3|GM X platform
|rowspan=3|X||B||1985 Buick Skylark Custom
|-
|C||1985 Buick Skylark Limited
|-
|X||1985 Chevrolet Citation II
|-
|rowspan=39|GM Y platform
|rowspan=39|Y||V||2004-2009 Cadillac XLR
|-
|X||2006-2009 Cadillac XLR V-Series
|-
|Y||1985-2008 Chevrolet Corvette (all models except '90-'95 ZR-1)
|-
|Z||1990-1995 Chevrolet Corvette ZR-1
|-
|G||2009 Chevrolet Corvette GT1 Championship Edition (Base & Z06)
|-
|R||2009 Chevrolet Corvette ZR1 (after early production)
|-
|Y||2009 Chevrolet Corvette (Base model, Early production Z06, Early production ZR1)
|-
|Z||2009 Chevrolet Corvette Z06 (after early production)
|-
|A||2010-2013 Chevrolet Corvette Standard 1LT Man. Trans.
|-
|B||2010-2013 Chevrolet Corvette Preferred 2LT Man. Trans.
|-
|C||2010-2013 Chevrolet Corvette Premium 3LT Man. Trans.
|-
|D||2010-2013 Chevrolet Corvette Custom 4LT Man. Trans.
|-
|E||2010-2013 Chevrolet Corvette Standard 1LT Auto. Trans.
|-
|F||2010-2013 Chevrolet Corvette Preferred 2LT Auto. Trans.
|-
|G||2010-2013 Chevrolet Corvette Premium 3LT Auto. Trans.
|-
|H||2010-2013 Chevrolet Corvette Custom 4LT Auto. Trans.
|-
|J||2010-2013 Chevrolet Corvette Z06 Standard 1LZ Man. Trans.
|-
|K||2010-2013 Chevrolet Corvette Z06 Premium 2LZ Man. Trans.
|-
|L||2010-2013 Chevrolet Corvette Z06 Custom 3LZ Man. Trans.
|-
|M||2010-2013 Chevrolet Corvette ZR1 Standard 1ZR Man. Trans.
|-
|N||2010-2013 Chevrolet Corvette ZR1 Custom 3ZR Man. Trans.
|-
|P||2010-2013 Chevrolet Corvette Grand Sport Standard 1LT Man. Trans.
|-
|R||2010-2013 Chevrolet Corvette Grand Sport Preferred 2LT Man. Trans.
|-
|S||2010-2013 Chevrolet Corvette Grand Sport Premium 3LT Man. Trans.
|-
|T||2010-2013 Chevrolet Corvette Grand Sport Custom 4LT Man. Trans.
|-
|U||2010-2013 Chevrolet Corvette Grand Sport Standard 1LT Auto. Trans.
|-
|V||2010-2013 Chevrolet Corvette Grand Sport Preferred 2LT Auto. Trans.
|-
|W||2010-2013 Chevrolet Corvette Grand Sport Premium 3LT Auto. Trans.
|-
|X||2010-2013 Chevrolet Corvette Grand Sport Custom 4LT Auto. Trans.
|-
|Y||2013 Chevrolet Corvette 427 Convertible Collector Edition Premium 3LT Man. Trans.
|-
|Z||2013 Chevrolet Corvette 427 Convertible Collector Edition Custom 4LT Man. Trans.
|-
|1||2013 Chevrolet Corvette 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|2||2013 Chevrolet Corvette 60th Anniversary Edition Custom 4LT Auto. Trans.
|-
|3||2013 Chevrolet Corvette Grand Sport 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|4||2013 Chevrolet Corvette Grand Sport 60th Anniversary Edition Custom 4LT Auto. Trans.
|-
|5||2013 Chevrolet Corvette Z06 60th Anniversary Edition Custom 3LZ Man. Trans.
|-
|6||2013 Chevrolet Corvette ZR1 60th Anniversary Edition Custom 3ZR Man. Trans.
|-
|7||2013 Chevrolet Corvette 427 Convertible 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|8||2013 Chevrolet Corvette 427 Convertible Collector Edition Preferred 2LT Man. Trans.
|-
|rowspan=13|GM Z platform
|rowspan=13|Z
|-
|E||Saturn SC1 (manual transmission 2-Door) 1993-1999
|-
|F||Saturn SC1 (automatic transmission 2-Door) 1993-1999, SL (manual transmission) 1991-02
|-
|G||Saturn SC (manual transmission) 1991-1992, SC2 (manual transmission 2-Door) 1993-99,<br /> SL1 (manual transmission) 1991-2002, SW1 (manual transmission) 1993-1999
|-
|H||Saturn SC (automatic transmission) 1991-92, SC2 (automatic transmission 2-Door) '93-'99,<br /> SL1 (automatic transmission) 1991-02, SW1 (automatic transmission LHD) '93-'99
|-
|J||Saturn SL2 (manual transmission) 1991-2002, SW2 (manual transmission) 1993-2001
|-
|K||Saturn SL2 (automatic transmission) 1991-2002, SW2 (automatic transmission 1993-1999)
|-
|M||Saturn SW1 "Postal" [SWP] (automatic transmission RHD) 1999-2001 <br>(Made for US Postal Service rural route mail carriers)
|-
|N||Saturn SC1 (manual transmission 3-Door) 1999-2002, SW2 (automatic transmission 2000-01)
|-
|P||Saturn SC1 (automatic transmission 3-Door) 1999-2002
|-
|R||Saturn SC2 (manual transmission 3-Door) 1999-2002
|-
|S||Saturn SL Spring Special 2002
|-
|Y||Saturn SC2 (automatic transmission 3-Door) 1999-2002
|-
|rowspan=3|GM Zeta platform (VE)
|rowspan=3|E||C||Pontiac G8 GT
|-
|P||Pontiac G8 GXP
|-
|R||Pontiac G8 (Base model)
|-
|rowspan=2|GM Zeta platform (VF)
|rowspan=2|F||1||2014-2017 Chevrolet SS w/automatic transmission
|-
|2||2015-2017 Chevrolet SS w/manual transmission
|-
|GM Zeta platform (WM)
|M||K||2011-2013 Chevrolet Caprice PPV
|-
|GM Zeta platform (WN)
|N||S||2014-2017 Chevrolet Caprice PPV
|-
|rowspan=19|GM Zeta platform (models formerly on F platform)
|rowspan=19|F||A||Chevrolet Camaro ''LS'' automatic transmission 2010-2011, ''2LS'' automatic transmission 2012-2014, ''LS'' manual transmission 2015
|-
|B||Chevrolet Camaro ''LT'' automatic transmission 2010-2014, ''2LS'' automatic transmission 2015
|-
|C||Chevrolet Camaro ''2LT'' automatic transmission 2010-2014, ''LT'' manual transmission 2015
|-
|D||Chevrolet Camaro ''LT'' automatic transmission 2015
|-
|E||Chevrolet Camaro ''LS'' manual transmission 2010-2014, ''2LT'' manual transmission 2015
|-
|F||Chevrolet Camaro ''LT'' manual transmission 2010-2014, ''2LT'' automatic transmission 2015
|-
|G||Chevrolet Camaro ''2LT'' manual transmission 2010-2014, ''SS'' manual transmission 2015
|-
|H||Chevrolet Camaro ''SS'' automatic transmission 2015
|-
|J||Chevrolet Camaro ''SS'' automatic transmission 2010-2014. Note: Must have "J" in 8th position of VIN.
|-
|J||Chevrolet Camaro ''ZL1'' automatic transmission 2012. Note: Must have "P" in 8th position of VIN.
|-
|J||Chevrolet Camaro ''2SS'' manual transmission 2015
|-
|K||Chevrolet Camaro ''2SS'' automatic transmission 2010-2015
|-
|L||Chevrolet Camaro ''ZL1'' automatic transmission 2013-2014, ''ZL1'' manual transmission 2015
|-
|M||Chevrolet Camaro ''ZL1'' automatic transmission 2015
|-
|S||Chevrolet Camaro ''SS'' manual transmission 2010-2014. Note: Must have "W" in 8th position of VIN.
|-
|S||Chevrolet Camaro ''ZL1'' manual transmission 2012. Note: Must have "P" in 8th position of VIN.
|-
|S||Chevrolet Camaro ''Z/28'' manual transmission 2014. Note: Must have "E" in 8th position of VIN.
|-
|T||Chevrolet Camaro ''2SS'' manual transmission 2010-2014
|-
|Z||Chevrolet Camaro ''ZL1'' manual transmission 2013-2014, ''Z/28'' manual transmission 2015
|-
|}
RHD= Right-Hand Drive
====Model Line 2010- Passenger Car (Using Vehicle Platforms introduced 2010 or later)====
The Model Line is specified as character 4 of the American GM VIN for Passenger Cars.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Cadillac ATS 2013-2019
|-
|A||Cadillac CTS sedan 2014-2019, CTS V-Series sedan 2016-2019
|-
|B||Chevrolet Cruze 2016-2019
|-
|C||Chevrolet Spark 2013-2022, Spark EV 2014-2016
|-
|D||Cadillac CT4 2020-2026
|-
|D||Cadillac CT5 2020-
|-
|F||Chevrolet Camaro 2016-2024
|-
|F||Chevrolet Bolt EV 2017-2023, Bolt EUV 2022-2023, Bolt 2027
|-
|G||Buick LaCrosse 2010-2016
|-
|G||Buick Regal 2011-2020, Buick Regal TourX 2018-2020
|-
|J||Chevrolet Sonic 2016-2020
|-
|K||Cadillac CT6 2016-2020
|-
|M||Cadillac Celestiq EV 2025-
|-
|P||Buick Verano 2012-2017
|-
|P||Chevrolet Cruze 2011-2015, Cruze Limited 2016
|-
|R||Cadillac ELR 2014, 2016
|-
|R||Chevrolet Volt 2011-2019
|-
|W||Buick Cascada 2016-2019
|-
|Y||Chevrolet Corvette 2014-
|-
|Z||Buick LaCrosse 2017-2019
|-
|Z||Chevrolet Malibu 2016-2025
|-
|1||Cadillac XTS 2013-2019
|-
|1||Chevrolet Impala 2014-2020
|-
|1||Chevrolet Malibu 2013-2015, Malibu Limited 2016
|-
|}
===Body style codes 1987- Passenger Car===
The Body type is specified as character 6 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1||Two-Door Coupe/Sedan
|-
|2||Two-Door Hatchback
|-
|3||Two-Door Convertible
|-
|4||Two-Door Wagon ('91-'92 Geo Storm Hatchback)
|-
|5||Four-Door Sedan
|-
|6||Four-Door Hatchback
|-
|7||Four-Door Hatchback ('89-'90 Geo Prizm hatchback)
|-
|8||Four-Door Station Wagon
|-
|9||Four-Door Station Wagon - High Roof Monocab
|}
===American restraint types 1987-===
The restraint type is specified as character 7 of the American GM VIN for passenger cars.
{{center/top}}
====Restraint codes for passenger cars 1987-2009====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|1||Active (Manual) belts 1987-1996
|-
|2||Active (Manual) belts plus driver and passenger front airbags 1992-2005<br />(For '94-'96 Pontiac Grand Prix coupe: Passive (Automatic) belts plus driver and passenger front airbags)
|-
|3||Active (Manual) belts plus driver side front airbag 1988-1996 <br />(For '94 Geo Prizm: Active (Manual) belts plus driver and passenger front airbags)
|-
|4||Passive (Automatic) belts 1987-1996
|-
|4||Active (Manual) belts plus driver and passenger front & side airbags 1997-2005
|-
|4||Active (Manual) belts plus driver and passenger front & side curtain airbags 2006-2009
|-
|5||Passive (Automatic) belts plus driver side front airbag 1992-1996
|-
|5||Active (Manual) belts plus driver and passenger front airbags & driver-side side impact airbag 2000-2005
|-
|5||Active (Manual) belts plus driver and passenger front airbags & occupant sensor 2006-2009
|-
|6||Passive (Automatic) belts plus driver and passenger front airbags 1994-1996
|-
|6||Active (Manual) belts plus driver and passenger front & side airbags & occupant sensor 2000-2009
|-
|7||Active (Manual) belt driver & Passive (Automatic) belt passenger plus driver and passenger front airbags 1996
|-
|7||Active (Manual) belts plus driver and passenger front & side airbags & rear side airbags 2000-2005
|-
|7||Active (Manual) belts plus driver and passenger front & side & side curtain airbags & occupant sensor 2006-2009
|-
|8||Active (Manual) belts plus driver and passenger front & side curtain airbags & occupant sensor 2006-2009
|-
|9||
|}
{{center/top}}
====Restraint codes for passenger cars 2010-====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|D||Active (Manual) belts plus driver and passenger front & side airbags 2010-
|-
|E||Active (Manual) belts plus driver and passenger front & side & side curtain airbags 2010-2017, 2027
|-
|F||Active (Manual) belts plus driver and passenger front & side curtain airbags 2010
|-
|G||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain airbags 2010-2017
|-
|N||Active (Manual) belts plus driver and passenger front & side & front knee airbags 2016-2019
|-
|R||Active (Manual) belts plus driver and passenger front & side & side curtain & front knee airbags 2012-
|-
|S||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain & front knee airbags 2011-
|-
|T||Active (Manual) belts plus driver and passenger front & side & front row side curtain airbags 2011
|-
|U||Active (Manual) belts plus driver and passenger front & side & front row side curtain & front knee airbags 2012-2017
|}
{{center/top}}
====Restraint codes for light trucks 2010-====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|A||Active (Manual) belts plus driver-side front airbag 2010
|-
|B||Active (Manual) belts plus driver-side front airbag 2011-
|-
|B||Active (Manual) belts plus driver and passenger front airbags 2010
|-
|C||Active (Manual) belts plus driver and passenger front airbags 2011-
|-
|C||Active (Manual) belts plus driver and passenger front & side airbags 2010
|-
|D||Active (Manual) belts plus driver and passenger front & side airbags 2011-
|-
|D||Active (Manual) belts plus driver and passenger front airbags & side curtain airbags for up to 3 rows of seating 2010
|-
|E||Active (Manual) belts plus driver and passenger front & side & side curtain airbags 2010-
|-
|F||Active (Manual) belts plus driver and passenger front airbags & side curtain airbags for up to 3 rows of seating 2011-2015
|-
|F||Active (Manual) belts plus driver and passenger front & side airbags & side curtain airbags for up to 3 rows of seating 2016-
|-
|H||Active (Manual) belts plus driver-side front airbag & driver-side side-impact airbag & driver-side side curtain airbag 2023-2024
|-
|K||Active (Manual) belts plus driver and passenger front & side & side curtain & front center airbags 2013-
|-
|L||Active (Manual) belts plus driver and passenger front & side & side curtain & front center & driver-side knee airbags 2017-2023
|-
|M||Active (Manual) belts plus driver and passenger front & side & side curtain & front center & front knee airbags 2025-
|-
|R||Active (Manual) belts plus driver and passenger front & side & side curtain & front knee airbags 2017-
|-
|S||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain & front knee airbags 2013-
|-
|T||Active (Manual) belts plus driver-side front airbag & driver- and passenger-side side-impact airbags & side curtain airbags 2023-
|-
|U||Active (Manual) belts plus driver and passenger front & side & front row side curtain & front knee airbags 2013-2019
|}
===American engine codes 1981-===
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
====Engine codes for passenger cars====
Warning: Issues with decoding are related to year/model combinations. Each year has a different breakdown for each code along with plants and some model/trim breakdowns over years.
Entry: 1985-1988 Pontiac Fiero has a 9 engine code for the 2.8L L44 V6. Entry: 1986-1990 Cadillac Brougham, Oldsmobile 307 Cu. In. V8 vin code Y.
{| border=1 style="margin:auto;"
!VIN
!RPO
!Size
!Type
!Fuel
!Valvetrain
!Engine Family/Notes/Applications
|-
|A||LD5||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Buick V6. (231 cu. in.) '81 Chevy Camaro (CA), Pontiac Catalina, Firebird, LeMans, Buick Century,<br /> '81-'83 Chevy Malibu (CA), '81-'84 Monte Carlo, Caprice, Impala (CA), '81-'87 Pontiac Grand Prix, Oldsmobile Cutlass/Cutlass Supreme, Buick Regal, '81-'85 Oldsmobile Delta 88, Buick LeSabre,<br /> '81-'86 Pontiac Bonneville, '84 Parisienne
|-
|A||LG0||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4 H.O. '89-'94 Pontiac Grand Am, '89-'91 Oldsmobile Cutlass Calais, '92-'94 Achieva, '90 Cutlass Supreme, '90-'94 Chevy Beretta
|-
|A||LH2||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (For RWD) (Premium V). '04-'09 Cadillac XLR, '05-'10 Cadillac STS
|-
|A||LCV||2.5 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. '13 Chevy Malibu, '16 Malibu Limited, '16-'19 Impala,<br /> '13-'16 Cadillac ATS
|-
|A||LV7||1.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. Made in Changwon, S. Korea. '16-'22 Chevy Spark.
|-
|B||LG2||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6. '86 Oldsmobile 98, Toronado, Buick Electra, Riviera.
|-
|B||L26||4.9 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8.<br /> '91-'93 Cadillac Eldorado, Seville, '91-'95 DeVille, '91-'92 Fleetwood, '91-'93 Sixty Special
|-
|B||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '06-'08 Chevy Cobalt, '06-'07 Saturn Ion, '06-'10 Pontiac G6, Solstice,<br /> '07-'08 Pontiac G5, '07-'10 Saturn Sky, '08-'09 Saturn Aura, '08-'10 Chevy Malibu
|-
|B||LUV||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. '12-'20 Chevy Sonic, '13-'15 Chevy Cruze, '16 Cruze Limited
|-
|C||L17||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu G161Z engine made by GM in US. '82-'87 Chevy Chevette, Pontiac T1000/1000
|-
|C||LN3||3.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6 (3800). '88-'90 Oldsmobile 98, Toronado, Buick Electra, Riviera, Reatta, <br /> '88-'91 Buick LeSabre, Oldsmobile Delta 88/Eighty Eight, Pontiac Bonneville
|-
|C||L47||4.0 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Oldsmobile Aurora V8 (Premium V). Oldsmobile Aurora '95-'99, Aurora 4.0 '01-'03
|-
|C||LS4||5.3 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. Active Fuel Management.<br /> Transversely mounted for FWD. '05-'08 Pontiac Grand Prix GXP, '06-'07 Chevy Monte Carlo SS,<br /> '06-'09 Chevy Impala SS, '08-'09 Buick LaCrosse Super.
|-
|C||LAF||2.4 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. VVT. Buick LaCrosse '10-'11, Regal '11.
|-
|C||LUJ||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. Early production engines were made in Aspern, Austria; later made in Flint, MI. '12 Chevy Cruze
|-
|D||LJ5||1.8 L||Straight-4|I4||Indirect injection Diesel||SOHC,<br /> 8 valve||Isuzu 4FB1 diesel engine imported from Japan. '81-'86 Chevy Chevette
|-
|D||LD2||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4. '88-'95 Pontiac Grand Am, '88-'91 Oldsmobile Cutlass Calais, '92-'95 Achieva,<br /> '88-'91 &'95 Buick Skylark, '90-'91 Pontiac Grand Prix, Oldsmobile Cutlass Supreme,<br /> '95 Chevy Cavalier, Pontiac Sunfire
|-
|D||LC3||4.4 L||V8 Supercharged||Fuel injection#Sequential Multi-port point injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (Premium V). '06-'09 Cadillac XLR V-Series, Cadillac STS V-Series
|-
|E||LK9||3.0 L||V6||2 Barrel Carburetor |2BBL||OHV||Buick V6. '82-'85 Oldsmobile Cutlass Ciera, Buick Century, '85 Oldsmobile 98, Buick Electra
|-
|E||LA1||3.4 L||V6||Fuel injection#Sequential Multi-port point injection|SFI||OHV||Chevrolet 60° V6. '99-'05 Grand Am, '99-'04 Alero, '00-'05 Impala, Monte Carlo
|-
|E||L03||5.0 L||V8||Fuel injection#Throttle Body injection|TBI||OHV||Gen I Chevy Small-Block V8 (305 cu. in.). '88-'92 Camaro/Firebird, '89-'93 Chevy Caprice,<br /> '91 Buick Roadmaster Estate wagon, '91-'92 Oldsmobile Custom Cruiser, Cadillac Brougham.
|-
|E||LXV||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Family 1 Gen 3 engine. W/VVT. '09-'11 Chevy Aveo, '09 Pontiac G3
|-
|E||LS7||7.0 L||V8||Fuel injection#Sequential Multi-port point injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '06-'13 Corvette Z06, '13 Corvette 427, '14-'15 Camaro Z/28
|-
|E||LH7||1.6 L||I4 Turbo||Direct injection <br /> Common-rail Diesel||DOHC,<br /> 16 valve||GM Medium Diesel engine ("Whisper Diesel"). Made by Opel in Szentgotthárd, Hungary.<br /> Aluminum Block & Heads. '17-'19 Chevy Cruze Diesel.
|-
|F||LV8||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Oldsmobile "Rocket" V8 (260 cu. in.) '81 Oldsmobile Cutlass, Delta 88.
|-
|F||L61||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen I. '00-'04 Saturn L-Series, '02-'05 Chevy Cavalier, Pontiac Sunfire, Grand Am,<br /> '02-'04 Oldsmobile Alero, '03-'06 Saturn Ion, '04-'06 Chevy Malibu, '05-'06 Chevy Cobalt
|-
|F||L61||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. '07-'08 Chevy Cobalt, Malibu, Pontiac G5, '07 Saturn Ion.
|-
|F||LB9||5.0 L||V8||Tuned-port fuel injection|TPI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.). '85-'92 Chevy Camaro, Pontiac Firebird.
|-
|G||L46||1.8 L||I4||2 Barrel Carburetor |2BBL||OHV||Chevrolet "122" engine. '82 J-cars.
|-
|G||L69||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8 (High Output 5.0L). (305 cu. in.)<br /> '84-'86 Camaro/Firebird, '84-'88 Chevy Monte Carlo SS
|-
|G||LM3||2.2 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '90-'91 Chevy Cavalier & Corsica/Beretta.
|-
|G||LS1||5.7 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Gen III Chevy Small-Block V8. (346 cu. in.) Aluminum Block & Heads.<br /> '97-'04 Corvette, '98-'02 Camaro/Firebird, '04 Pontiac GTO
|-
|G||LF1||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. 2010 Buick LaCrosse, Cadillac CTS
|-
|G||LWE||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. PZEV emissions.<br /> '13-'15 Chevy Cruze, '16 Cruze Limited, '13-'18 Sonic.
|-
|H||LG4||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '81-'87 F-bodies, '81-'83 Chevy Malibu, '81-'85 Impala,<br /> '81-'88 Caprice, Monte Carlo, '83-'86 Pontiac Bonneville, Parisienne, '83-'87 Grand Prix
|-
|H||LE4||2.0 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil. '92-'94 Pontiac Sunbird.
|-
|H||LX5||3.5 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||Oldsmobile "Shortstar" V6 (Premium V). Oldsmobile Intrigue '99-'02, Aurora 3.5 '01-'02.
|-
|H||LAP||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '09 Chevy Cobalt, Pontiac G5.
|-
|H||LUW||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. '11-'15 Chevy Cruze, '16 Cruze Limited, '12-'18 Sonic.
|-
|J||L39||4.4 L||V8||2 Barrel Carburetor |2BBL||OHV||Gen I Chevy Small-Block V8 (267 cu. in.) '81-'82 Chevy Caprice, Impala, Malibu, Monte Carlo,<br /> '81 Chevy Camaro
|-
|J||LA5||1.8 L||Straight-4|I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil. '84-'86 Pontiac Sunbird, Buick Skyhawk.
|-
|J||LT5||5.7 L||V8||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 32 valve||Based on Chevy Small-Block V8. Designed with Lotus Engineering.<br /> Made by Mercury Marine. Aluminum Block & Heads. '90-'95 Corvette ZR-1
|-
|J||LG8||3.1 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Chevrolet 60° V6. Gen III. 3100. '99-'03 Chevy Malibu, '99 Oldsmobile Cutlass, '00-'01 Chevy Lumina,<br /> '00-'03 Pontiac Grand Prix SE, '00-'05 Buick Century
|-
|J||L99||6.2 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. VVT. With Active Fuel Management. Aluminum Block & Heads.<br /> '10-'15 Camaro SS (auto. trans.)
|-
|J||LTA||4.2 L||V8 Twin Turbo||Direct injection|DI||DOHC,<br /> 32 valve||Cadillac Blackwing V8. VVT. '19-'20 Cadillac CT6 Platinum & V-series
|-
|K||LC3||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '81-'82 Malibu, Monte Carlo, Impala, Caprice, '81 Camaro.
|-
|K||LC5||1.5 L||I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu 4XC1 engine. '85 Chevrolet Spectrum.
|-
|K||LT2||2.0 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '87-'91 Pontiac Sunbird, '87-'88 Oldsmobile Firenza, Buick Skyhawk.
|-
|K||LT2||2.0 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Australia by Holden.<br /> '89-'90 Pontiac LeMans GSE Aerocoupe, '89 LeMans SE sedan
|-
|K||L36||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Series II). '95-'05: Various W-, H-, C-, & G-body models. '95-'02 Camaro/Firebird.
|-
|K||LZE||3.5L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3510cc. VVT. Flex-Fuel E85 compatible.<br /> '06-'07 Chevy Monte Carlo, '06-'11 Chevy Impala, '09-'10 Chevy Malibu, Pontiac G6
|-
|K||LEA||2.4 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||E85 Flex Fuel. GM Ecotec engine, Gen II. VVT. Buick Regal, Verano '12-'17 (except '13 Regal).
|-
|K||LSY||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Active Fuel Management. VVT. VVL.<br /> '19 Cadillac CT6, '20+ Cadillac CT4, CT5
|-
|L||LM1||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8.<br> '81 Camaro Z28 (only w/auto. trans. in US), '81-'82 Impala 9C1 Police, '81 Malibu 9C1 Police
|-
|L||LL1||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 H.O. (longitudinally mounted). '83-'84 Pontiac Firebird.
|-
|L||LN7||3.0 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6. '85-'87 Pontiac Grand Am, '85-'88 Oldsmobile & Buick N-bodies,<br /> '86 Oldsmobile Delta 88, Buick LeSabre
|-
|L||L27||3.8 L||V6||Fuel injection#Tuned port injection|TPI||OHV||Buick V6 (3800 Series I). '90-'95 Buick Regal, '91-'94 Oldsmobile 98, Buick Park Avenue, '91 Reatta, '91-'93 Riviera, '91-'92 Oldsmobile Toronado, '92-'95 Buick LeSabre, '92-'94 Pontiac Bonneville, Oldsmobile 88
|-
|L||LNK||1.8 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2ZZ-GE engine. VVTL-i. '03-'06 Pontiac Vibe GT
|-
|L||LKW||2.5 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. VVL. '14-'15 Chevy Malibu, Impala
|-
|L||L3B||2.7L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM L3B Tripower engine. VVT, VVL. Active Fuel Management. '20+ Cadillac CT4, CT4-V
|-
|M||LY9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '85 Chevrolet Sprint
|-
|M||LT3||2.0 L||Straight-4|I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '87-'90 Pontiac Sunbird, '87 Buick Skyhawk T-Type, '87-'89 Pontiac Grand Am SE.
|-
|M||L82||3.1 L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||Chevrolet 60° V6 (transversely mounted). Gen III. 3100. '93-'97 Oldsmobile Cutlass Supreme,<br /> '94-'98 Pontiac Grand Am, Oldsmobile Achieva, Buick Skylark, '94-'99 Pontiac Grand Prix,<br /> '94-'96 Chevy Corsica/Beretta, Oldsmobile Cutlass Ciera, Buick Regal, '94-'99 Century,<br /> '95-'99 Chevy Lumina, Monte Carlo, '97-'99 Chevy Malibu, Oldsmobile Cutlass
|-
|M||LY9||2.6 L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). Euro-market Cadillac CTS '03-'04.
|-
|M||LGD||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||E85 Flex Fuel. GM High Value 60° V6. VVT. '09-'11 Chevy Impala, Buick Lucerne
|-
|M||LE2||1.4 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. '16-'19 Chevy Cruze.
|-
|N||LF9||5.7 L||V8||Indirect injection Diesel||OHV||Oldsmobile Diesel V8. '81-'85 Chevy Caprice, Impala, '82-'83 Malibu, '82-'84 Monte Carlo,<br /> '81-'84 Pontiac Grand Prix, Bonneville, '81 Catalina, '83-'85 Parisienne,<br /> '81-'84 Oldsmobile 98, '81-'85 Cutlass/Cutlass Supreme, Delta 88, Custom Cruiser, Toronado,<br /> '81-'83 Buick Electra, '81-'85 LeSabre, Electra Estate wagon, Riviera, '82-'83 Regal,<br /> '81-'84 Cadillac DeVille, '81-'85 Fleetwood Brougham, Eldorado, Seville
|-
|N||LG7||3.3 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6 (3300). '89-'93 Buick Century, Skylark, Oldsmobile Cutlass Ciera, '89-'91 Cutlass Calais,<br /> '92-'93 Achieva, Pontiac Grand Am.
|-
|N||LA3||3.2 L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). '03-'04 Cadillac CTS
|-
|N||LZ4||3.5L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3510cc. VVT. '06-'07 Chevy Monte Carlo, '06-'10 Chevy Impala,<br /> '07-'10 Chevy Malibu, Pontiac G6, '07-'08 Saturn Aura
|-
|N||LFR||3.6L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||(Bi-Fuel Gas/CNG). GM High Feature V6. '15-'17 Chevy Impala Bi-Fuel
|-
|P||LQ5||2.0 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '83-'86 J-cars ('83-'84 for Pontiac).
|-
|P||LT1||5.7 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. Aluminum Heads: '92-'96 Corvette, '93-'97 Camaro/Firebird.<br /> Iron Heads: '94-'96 Chevy Caprice, Impala SS, Buick Roadmaster, Cadillac Fleetwood.
|-
|P||LSJ||2.0 L||SC Straight-4|I4 Supercharged||Fuel injection#Sequential central point injection|SFI||DOHC,<br /> 16 valve||GM Ecotec Gen I. Made by Opel in Kaiserslautern, Germany.<br /> '04-'07 Saturn Ion Red Line, '05-'07 Chevy Cobalt SS Supercharged.
|-
|P||LSA||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> Cadillac CTS V-Series '09-'15, Camaro ZL1 '12-'15
|-
|P||LF4||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. Cadillac CT4-V Blackwing '22+
|-
|R||LR8||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Transversely mounted. '82-'85 Chevy Citation, Buick Skylark,<br /> '82-'84 Pontiac Phoenix, Oldsmobile Omega, '82-'90 Chevy Celebrity, '82-'91 Pontiac 6000,<br /> '82-'92 Oldsmobile Cutlass Ciera, Buick Century, '84-'88 Pontiac Fiero, '90-'92 Chevy Lumina
|-
|R||L81||3.0 L||V6||Fuel injection#Multi-port fuel injection|SFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). '97-'01 Cadillac Catera, '00-'05 Saturn L-Series
|-
|R||LZ8||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||GM High Value 60° V6. VVT. Active Fuel Management. '07 Chevy Impala
|-
|R||LS9||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. '09 Corvette ZR1.
|-
|R||LUK||2.4L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '12-'16 Buick LaCrosse eAssist, Regal eAssist,<br /> '13-'14 Chevy Malibu Eco, '14 Chevy Impala Eco
|-
|S||LS5||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Pontiac V8. 265 cu. in.<br /> '81 Pontiac Bonneville, Catalina, Firebird, Grand Prix, LeMans, Buick Century, Regal.
|-
|S||LU5||5.0 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '83 Camaro, Firebird. Dual throttle-body fuel injection.
|-
|S||LB8||2.8 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '85-'89 Chevy Camaro, Pontiac Firebird.
|-
|S||L32||3.4 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '93-'95 Chevy Camaro, Pontiac Firebird.
|-
|S||LS6||5.7 L||V8||Fuel injection#Sequential Multi Port injection|SFI||OHV||Gen III Chevy Small-Block V8. (346 cu. in.) Aluminum Block & Heads.<br /> '01-'04 Corvette Z06, '04-'05 Cadillac CTS V-Series
|-
|S||LGX||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '16-'19 Cadillac ATS, CTS, '16-'20 CT6, '16-'24 Chevrolet Camaro, '17-'19 Buick LaCrosse, '18–'20 Buick Regal GS
|-
|T||LU8||4.9 L||V8 Turbo||4 Barrel Carburetor |4BBL||OHV||Pontiac V8. 301 cu. in. '81 Pontiac Firebird Formula & Trans Am.
|-
|T||LT7||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. FWD version for '82-'85 GM A-bodies.
|-
|T||LS2||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. FWD version for '85 GM C-bodies.
|-
|T||LH0||3.1 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '90-'92 Chevy Camaro, Pontiac Firebird.
|-
|T||LH0||3.1 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (transversely mounted). Gen II. '88-'91 Pontiac 6000,<br /> '89-'93 Grand Prix, Oldsmobile Cutlass Supreme, Buick Regal, '90-'94 Chevy Cavalier, Lumina,<br /> '91-'94 Pontiac Sunbird, '90-'93 Chevy Corsica/Beretta, '90 Celebrity
|-
|T||LD9||2.4 L||Straight-4|I4||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4 ("2.4 Twin Cam"). '96-'01 Pontiac Grand Am, '96-'97 Oldsmobile Achieva, Buick Skylark, '99-'01 Oldsmobile Alero, '97-'99 Chevy Malibu, '96-'02 Chevy Cavalier, Pontiac Sunfire
|-
|T||LP1||2.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||GM High Feature V6. '05-'07 Cadillac CTS
|-
|T||LS9||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. '10-'13 Corvette ZR1.
|-
|T||LFV||1.5L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. '16-'25 Chevy Malibu.
|-
|U||L68||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Transversely mounted. '85-'91 N-bodies
|-
|U||LS2||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '05-'07 Corvette, '05-'06 Pontiac GTO, '06-'07 Cadillac CTS V-Series
|-
|U||LE9||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. E85 Flex-Fuel. 2011-12 Chevy Malibu.
|-
|U||LKN||1.8L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||Full Hybrid. GM Medium Gasoline Engine. VVT. Made in Szentgotthárd, Hungary.<br> '16-'19 Chevy Malibu Hybrid
|-
|V||LT6||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. RWD version.<br /> '82-'83 Chevy Malibu, Monte Carlo, '82-'85 Oldsmobile Cutlass Supreme, Buick Regal
|-
|V||LG5||3.1 L||V6 Turbo||Fuel injection#Multi-port fuel injection|MPFI||OHV||Chevrolet 60° V6. Gen II. Intercooled. (ASC/McLaren modified).<br /> '89-'90 Pontiac Grand Prix Turbo coupe, '90 Grand Prix STE Turbo sedan
|-
|V||LLT||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. '08-'11 Cadillac CTS, STS, '10-'11 Chevrolet Camaro, Buick LaCrosse
|-
|V||LHU||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||E85 Flex Fuel (N/A on Regal GS). GM Ecotec engine, Gen II. VVT.<br /> Buick Regal '11-'13, Verano '13-'16.
|-
|W||L37||4.9 L||V8||4 Barrel Carburetor |4BBL||OHV||Pontiac V8. 301 cu. in. '81 Pontiac Firebird, LeMans Safari wagon.
|-
|W||LB6||2.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Gen I/II Chevrolet 60° V6 (transversely mounted). '85 Chevy Citation, Buick Skylark,<br /> '85-'89 Chevy Cavalier, Celebrity, Pontiac 6000, '85-'88 Cadillac Cimarron,<br /> '85-'87 Oldsmobile Firenza, '86-'89 Cutlass Ciera, '87-'88 Buick Century, '87-'89 Chevy Corsica/Beretta, '88-'89 Pontiac Grand Prix, Oldsmobile Cutlass Supreme, Buick Regal
|-
|W||L64||3.1 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Flex-fuel: Gas/M85 or Gas/E85 (2 versions). Gen II Chevrolet 60° V6. '93 Chevy Lumina VFV
|-
|W||L99||4.3 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. '94-'96 Chevy Caprice.
|-
|W||LS3||6.2 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '08-'13 Corvette, '10-'15 Camaro SS (man. trans.), '09 Pontiac G8 GXP, '14-'17 Chevy SS
|-
|W||LGY||3.0L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '20+ Cadillac CT5, CT5-V
|-
|X||LE2||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (transversely mounted). '81-'85 Chevy Citation, Buick Skylark,<br /> '81-'84 Pontiac Phoenix, Oldsmobile Omega, '82-'86 Chevy Celebrity, Pontiac 6000,<br /> '86 Oldsmobile Cutlass Ciera, Buick Century
|-
|X||LQ1||3.4 L||V6||Fuel injection#Multi-port fuel injection|MPFI||DOHC,<br /> 24 valve||Chevrolet 60° V6 ("Twin Dual Cam V6"). '91-'97 Chevy Lumina, '95-'97 Chevy Monte Carlo,<br /> '91-'96 Pontiac Grand Prix, Oldsmobile Cutlass Supreme
|-
|X||LNF||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. VVT.<br /> '07-'10 Pontiac Solstice GXP, Saturn Sky Red Line, '08-'10 Chevy Cobalt SS Turbo.
|-
|X||LTG||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. '13-'22 Chevy Malibu, '13-'19 Cadillac ATS, '14-'20 Buick Regal,<br /> '14-'19 Cadillac CTS, '16-'23 Chevy Camaro, '16-'18 Cadillac CT6.
|-
|X||LTG||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||Plug-in hybrid. GM Ecotec engine, Gen III. VVT. '17-'18 Cadillac CT6 PHEV. (VIN starts with LRE)
|-
|Y||LV2||5.0 L||V8||4 Barrel Carburetor |4BBL||OHV||Oldsmobile "Rocket" V8 (307 cu. in.) '86-'90 Chevy Caprice wagon, '87 Caprice sedan (Can.),<br /> '81 Pontiac Bonneville, Catalina, '86 Parisienne, '87-'89 Safari wagon, '81-'84 Oldsmobile 98,<br /> '81-'85 Delta 88, Toronado, '81-'90 Custom Cruiser, '81 Cutlass Cruiser, '82-'87 Cutlass Supreme,<br /> '88 Cutlass Supreme Classic, '81-'84 Buick Electra, '85-'89 Electra Estate wagon,<br /> '81-'85 LeSabre, Riviera, '86-'89 LeSabre Estate wagon, '90 Estate wagon, '86-'87 Regal,<br /> '86 Cadillac Fleetwood Brougham, '87-'90 Brougham
|-
|Y||LD8||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (Torque tuned FWD) (Premium V). '93-'02 Cadillac Eldorado,<br /> '94-'04 Cadillac Seville SLS, '94-'05 Cadillac DeVille, '06-'11 Cadillac DTS,<br /> '04-'05 Pontiac Bonneville GXP, '06-'08 Buick Lucerne
|-
|Y||L76||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management.<br /> '08-'09 Pontiac G8 GT.
|-
|Y||LF1||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. 2011 Cadillac CTS
|-
|Y||LF4||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. Cadillac ATS-V '16-'19
|-
|Z||LH7||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (transversely mounted). H.O. '81-'84 Chevy Citation, '82-'84 Pontiac Phoenix, Oldsmobile Omega ES, Buick Skylark, '83-'84 Pontiac 6000 STE, '84 Chevy Celebrity
|-
|Z||LB4||4.3L||V6||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '85 Chevy Impala, '85-'90 Caprice,<br /> '92-'93 Caprice 9C6 taxi, '85-'88 Monte Carlo, '85-'86 Pontiac Parisienne, '86-'87 Grand Prix,<br> '86 Bonneville.
|-
|Z||LAT||2.4L||I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '10 Chevy Malibu Hybrid
|-
|Z||LUZ||2.0 L||I4 Turbo||Direct injection <br /> Common-rail Diesel||DOHC,<br /> 16 valve||GM Family B Diesel (Based on Fiat JTD engine). Made by Opel in Kaiserslautern, Germany.<br /> Iron Block, Aluminum Heads. '14-'15 Chevy Cruze Diesel.
|-
|1||LC1||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (longitudinally mounted). '82-'84 Camaro/Firebird.
|-
|1||LL8||2.0 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '87-'89 Chevy/Olds/Buick J-cars & Chevy L-cars.
|-
|1||L67||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series I). '91-'95 Buick Park Avenue Ultra,<br /> '92-'95 Pontiac Bonneville, Oldsmobile 98, '95 Buick Riviera, Oldsmobile LSS
|-
|1||L67||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series II). '96-'05 Buick Park Avenue Ultra,<br /> '96-'99 Buick Riviera, Oldsmobile LSS, '96-'03 Pontiac Bonneville, '97-'03 Grand Prix,<br /> '97-'04 Buick Regal, '04-'05 Chevy Impala SS, Monte Carlo SS Supercharged
|-
|1||LZ9||3.9L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. VVT.<br /> '06-'07 Chevy Malibu SS, '06-'09 Pontiac G6, '06 Chevy Monte Carlo, Impala, '09-'10 Buick Lucerne
|-
|1||2H0||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. Made in Szentgotthárd, Hungary. '08 (& '09 in Canada) Saturn Astra
|-
|1||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '11 & some '12 Chevy Malibu w/LE5 engine.
|-
|2||LQ9||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Longitudinally mounted. '82-'85 Camaro/Firebird.
|-
|2||LS3||1.0 L||Straight-3|I3 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 6 valve ||Suzuki G10T engine. '87-'88 Chevrolet Sprint Turbo
|-
|2||LY8||1.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 16 valve||Suzuki G13BB engine. '98-'01 Chevrolet Metro
|-
|2||L26||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Series III). '04-'08 Pontiac Grand Prix, '05-'09 Buick LaCrosse, '06-'08 Buick Lucerne
|-
|2||L77||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management.<br /> E85 Flex Fuel. '11-'17 Chevy Caprice PPV.
|-
|3||LC8||3.8 L||V6|V6 Turbo||4 Barrel Carburetor |4BBL||OHV||Buick V6. 231 cu. in. '81-'82 Buick Regal, Riviera, '81 Chevy Monte Carlo.
|-
|3||LG3||3.8 L||V6||Fuel injection#(Sequential) Multi-port injection|MFI/SFI||OHV||Buick V6. '84-'88 Oldsmobile Cutlass Ciera, Buick Century, '85 & '87 Oldsmobile 98, Buick Electra,<br /> '86-'88 Oldsmobile Delta 88, Buick LeSabre, '87 Oldsmobile Toronado, Buick Riviera,<br /> '87-'88 Pontiac Bonneville.
|-
|3||LW2||4.5 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '90 Cadillac DeVille/Fleetwood/Sixty Special/Eldorado/Seville.
|-
|3||L40||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||Oldsmobile Quad 4 ("Quad OHC"). '92-'94 Pontiac Grand Am, Oldsmobile Achieva, Buick Skylark
|-
|3||LZG||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||E85 Flex Fuel. GM High Value 60° V6. VVT. Active Fuel Management. '08 Chevy Impala
|-
|3||LFX||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. E85 Flex Fuel.<br /> '12-'16 Buick LaCrosse, '12-'15 Chevrolet Camaro, Cadillac CTS, '12-'17 Chevrolet Caprice PPV,<br /> '12-'20 Chevrolet Impala, '14-'16 Chevrolet Impala Limited, '13-'15 Cadillac ATS, '13-'19 Cadillac XTS
|-
|3||LT6||5.5 L||V8||Direct injection|DI||DOHC,<br /> 32 valve||Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette Z06 '23+.
|-
|4||LC4||4.1 L||V6|V6||4 Barrel Carburetor |4BBL||OHV||Buick V6. '81-'84 Buick LeSabre, Electra, Riviera, Oldsmobile Toronado, '81-'82 Cadillac DeVille, Fleetwood Brougham, Eldorado, Seville, '81-'83 Oldsmobile 98, '82-'84 Buick Regal,<br /> '82 Pontiac Grand Prix, Bonneville G
|-
|4||LC9||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Toyota 4A-C engine. '85-'88 Chevy Nova
|-
|4||LN2||2.2 L||Straight-4|I4||Fuel injection#(Sequential) Multi-port injection|MPI/SFI||OHV||Chevrolet "122" engine. '92-'02 Cavalier, '95-'02 Sunfire, '92-'96 Corsica/Beretta, '93 Lumina,<br /> '93-'96 Cutlass Ciera, Century.
|-
|4||L32||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series III). '04-'07 Pontiac Grand Prix
|-
|4||LUU||1.4L||I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. ([[w:EREV|Range extender]]). Early production engines were made in Aspern, Austria; later made in Flint, MI. '11-'15 Chevy Volt, '14 & '16 Cadillac ELR.
|-
|4||LT2||6.2 L||V8||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Stingray '20+.
|-
|4||LT2||6.2 L||V8||Direct injection|DI||OHV||Full Hybrid. Gen V Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette E-Ray '24+.
|-
|5||LW9||2.5L||I4||2 Barrel Carburetor |2BBL||OHV||Pontiac Iron Duke engine. '81 Chevy Citation, Pontiac Phoenix, Oldsmobile Omega, Buick Skylark.
|-
|5||LR6||4.5 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac High Technology V8. '88-'89 Cadillac DeVille/Fleetwood/Sixty Special/Eldorado/Seville.
|-
|5||LY9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '86 Chevrolet Sprint
|-
|5||LM9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '87-'88 Chevrolet Sprint
|-
|5||LW0||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 4A-GE engine. '88 Chevy Nova Twin Cam, '90-'92 Geo Prizm GSi
|-
|5||LW0||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Isuzu 4XE1-UW engine. '90-'91 Geo Storm GSi
|-
|5||LT4||5.7 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. '96 Corvette (man. trans.)
|-
|5||LAT||2.4L||I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '07-'09 Saturn Aura Green Line, '08-'09 Chevy Malibu Hybrid
|-
|5||LAP||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '10 Chevy Cobalt.
|-
|5||LFW||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. '12-'13 Cadillac CTS, '14 CTS wagon
|-
|5||L3A||1.5L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. ([[w:EREV|Range extender]]). '16-'19 Chevy Volt.
|-
|5||LWC||1.6L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Medium Gasoline Engine, H.O. VVT. Made in Szentgotthárd, Hungary. '16-'19 Buick Cascada
|-
|5||LS6||6.7 L||V8||Port/Direct injection||OHV||Gen VI Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Stingray, Grand Sport '27+.
|-
|5||LS6||6.7 L||V8||Port/Direct injection||OHV||Full Hybrid. Gen VI Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Grand Sport X '27+.
|-
|6||L81||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. '81 Corvette
|-
|6||LM1||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. '83-'85 Impala 9C1 Police, '86-'88 Caprice 9C1 Police
|-
|6||L73||1.6 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family 1 engine. Made in South Korea by Daewoo. '88-'93 Pontiac LeMans
|-
|6||LP2||1.0 L||Straight-3|I3||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 6 valve ||Suzuki G10A engine. '89-'97 Geo Metro, '98-'00 Chevrolet Metro
|-
|6||L01||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 4A-FE engine. '89-'97 Geo Prizm base/LSi
|-
|6||L01||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 12 valve||Isuzu 4XE1-V engine. '90-'93 Geo Storm (base model)
|-
|6||L42||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen I (Bi-Fuel Gas/CNG). '03-'04 Chevy Cavalier
|-
|6||L91||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||E-TEC II. '04-'07 Chevy Aveo
|-
|6||LXT||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||E-TEC II. '08 Chevy Aveo
|-
|6||LGW||3.0L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '16-'19 Cadillac CT6
|-
|6||LT4||6.2 L||V8 Supercharged||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management. VVT.<br /> '15-'19 Corvette Z06, '17-'24 Camaro ZL1, '16-'19 Cadillac CTS V-Series,<br /> '22+ Cadillac CT5-V Blackwing
|-
|7||LU5||5.0 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '82 Camaro, Firebird. Dual throttle-body fuel injection.
|-
|7||L69||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8 (High Output 5.0L). (305 cu. in.). '83 F-cars, '83 Chevy Monte Carlo SS
|-
|7||LC5||1.5 L||I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu 4XC1 engine. '86-'88 Chevrolet Spectrum, '89 Geo Spectrum.
|-
|7||LC2||3.8 L||V6|V6 Turbo||Fuel injection#Sequential multi-port injection|SFI||OHV||Intercooled. Buick V6. '86-'87 Buick Regal. '89 Pontiac 20th Anniversary Turbo Trans Am
|-
|7||LC7||4.1 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '87-'88 Cadillac Allante.
|-
|7||L05||5.7 L||V8||Fuel injection#Throttle Body injection|TBI||OHV||Gen I Chevy Small-Block V8. '89-'93 Chevy Caprice (police only for '89-'91),<br /> '92-'93 Buick Roadmaster, '92 Oldsmobile Custom Cruiser, '90-'92 Cadillac Brougham, '93 Fleetwood.
|-
|7||LL0||1.9 L||Straight-4|I4||Fuel injection#Multi-port injection|MFI||DOHC,<br /> 16 valve||Saturn I4 engine. '91-'02 Saturn S-Series
|-
|7||LY7||3.6 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. '04-'09 Cadillac CTS, '05-'07 STS, '05-'08 Buick LaCrosse,<br /> '07-'09 Pontiac G6, Saturn Aura, '08-'09 Pontiac G8, '08-'12 Chevy Malibu
|-
|7||LT1||6.2 L||V8||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management. VVT.<br /> '14-'19 Corvette, '16-'24 Camaro SS
|-
|7||LT7||5.5 L||V8 Twin Turbo||Port/Direct injection||DOHC,<br /> 32 valve||Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette ZR1 '25+. (1,064 hp)
|-
|7||LT7||5.5 L||V8 Twin Turbo||Port/Direct injection||DOHC,<br /> 32 valve||Full Hybrid. Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette ZR1X '26+. (1,250 hp)
|-
|8||LV8||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Oldsmobile "Rocket" V8 (260 cu. in.) '82 Oldsmobile Cutlass, Delta 88.
|-
|8||LT8||4.1 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac High Technology V8. '82-'87 Cadillac DeVille, Eldorado, Seville, '82-'85 Fleetwood Brougham, '85-'87 Fleetwood, '87 Fleetwood Sixty Special.
|-
|8||LC8||3.8 L||V6|V6 Turbo||4 Barrel Carburetor |4BBL||OHV||Buick V6. '83 Buick Regal, Riviera.
|-
|8||L83||5.7 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. '82, '84 Corvette. Dual throttle-body fuel injection. 1st fuel injected Corvette since 1965.
|-
|8||L98||5.7 L||V8||Tuned-port fuel injection|TPI||OHV||Gen I Chevy Small-Block V8. '85-'91 Corvette, '87-'92 Chevy Camaro, Pontiac Firebird.
|-
|8||LQ6||4.5 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '89-'92 Cadillac Allante.
|-
|8||L24||1.9 L||Straight-4|I4||Fuel injection#Multi-port injection|MFI||SOHC,<br /> 8 valve||Saturn I4 engine. '95-'02 Saturn S-Series
|-
|8||LX9||3.5 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3498cc. '04-'06 Chevy Malibu, '05-'06 Pontiac G6
|-
|8||LF3||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. '14-'19 Cadillac CTS V-Sport, XTS V-Sport
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Isuzu 4XF1 engine. '92-'93 Geo Storm GSi.
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 7A-FE engine. '93-'97 Geo Prizm
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 1ZZ-FE engine. VVT-i from '00. '98-'02 Chevrolet Prizm, '03-'08 Pontiac Vibe
|-
|8||LAY||1.8 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2ZR-FE engine. Dual VVT-i. '09-'10 Pontiac Vibe
|-
|9||L17||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu G161Z engine made by GM in US. '81 Chevy Chevette, Pontiac T1000
|-
|9||L62||6.0 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac 472-series V8 engine family. V8-6-4 cylinder deactivation.<br /> '81 Cadillacs, '82-'84 Fleetwood Limousine.
|-
|9||LC3||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '83 Malibu, '83-'84 Monte Carlo, Impala, Caprice, '83 Pontiac Parisienne.
|-
|9||LG8||5.0 L||V8||4 Barrel Carburetor |4BBL||OHV||Oldsmobile "Rocket" V8 (307 cu. in.) H.O. '83-'84 Hurst/Olds, '85-'87 Oldsmobile Cutlass 442
|-
|9||LM9||3.8 L||V6|V6 Turbo||Fuel injection#Sequential multi-port injection|SFI||OHV||Buick V6. '84-'85 Buick Regal, Riviera.
|-
|9||L44||2.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Chevrolet 60° V6 (transversely mounted). H.O. '85-'88 Pontiac Fiero
|-
|9||LC0||1.5 L||I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||Isuzu 4XC1-T engine. '87-'88 Chevrolet Spectrum Turbo
|-
|9||LK0||1.9 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||Saturn I4 engine. '91-'94 Saturn S-Series
|-
|9||L37||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (H.O. FWD) (Premium V). '93 Cadillac Allanté,<br /> '93-'02 Cadillac Eldorado Touring Coupe, '93-'04 Cadillac Seville STS, '96-'05 Cadillac DeVille,<br /> '06-'11 Cadillac DTS, '08-'11 Buick Lucerne Super
|-
|9||L72||1.3 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve ||Suzuki G13BA engine. '95-'97 Geo Metro
|-
|9||LUJ||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. Early production engines were made in Aspern, Austria; later made in Flint, MI. '11 Chevy Cruze
|-
|9||LL0||1.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Daewoo S-TEC II engine (1249 cc). VVT. Made in Changwon, S. Korea. '13-'15 Chevy Spark.
|-
|9||LT5||6.2 L||V8 Supercharged||Port/Direct injection||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. VVT. '19 Corvette ZR1.
|-
|0||LH8||1.8 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '82-'86 Pontiac J2000/2000/Sunbird, Oldsmobile Firenza, Buick Skyhawk.
|-
|0||LAX||2.4 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2AZ-FE engine. VVT-i. '09-'10 Pontiac Vibe
|-
|0||LE9||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. E85 Flex-Fuel. 2010 Chevy Malibu.
|-
|0||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. Most '12 Chevy Malibu w/LE5 engine.
|}
H.O.=High Output, CNG=Compressed Natural Gas, VVT=Variable Valve Timing, VVL=Variable Valve Lift
====Motor codes for electric passenger cars====
{| class="wikitable"
|-
! VIN !! RPO !! Fuel !! Drive Wheels !! Application/Notes
|-
| 5 ||LN1|| Electricity || Front || '97, '99 General Motors EV1
|-
| 0 ||EN0|| Electricity || Front || '14-'16 Chevrolet Spark EV
|-
| 0 ||EN0|| Electricity || Front || '17-'23 Chevrolet Bolt EV
|-
| 0 ||EN0|| Electricity || Front || '22-'23 Chevrolet Bolt EUV
|-
|}
====Motor codes for LFP-powered electric passenger cars====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Pack <br /> RPO code !! Fuel !! Drive Wheels !! Application/Notes
|-
|-
| V ||P9D (HPB)|| 1 || EJW || Electricity || Front || '27 Chevrolet Bolt
|}
LFP=Lithium Iron Phosphate
====Motor codes for Ultium-powered electric passenger cars====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Module <br /> RPO code !! # of Modules !! Fuel !! Drive Wheels !! Application/Notes
|-
|-
| 1 ||X0E|| 2 || EXN || 16 || Electricity || All || '25- Cadillac Celestiq
|-
| 2 ||X0E|| 2 || EHT || 16 || Electricity || All || '25- Cadillac Celestiq <br> (Battery Module RPO code EHT is Configuration B)
|}
====Engine codes for light trucks====
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes/Applications
|-
| A ||LD5|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Buick V6. (231 cu. in.) '81-'84 Chevy El Camino, GMC Caballero (CA emissions).
|-
| A ||LR1|| 1.9L || I4 || Gas ||SOHC,<br /> 8 valve||2-bbl carb. Isuzu G200 engine imported from Japan.<br /> '82-'85 Chevy S-10/GMC S-15, '83-'85 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| A ||L38|| 2.5L || I4 || Gas ||OHV||TBI. Pontiac Iron Duke/Tech IV engine. '91-'93 Chevy S-10/GMC Sonoma.
|-
| A ||LH2|| 4.6L || V8 || Gas ||DOHC,<br /> 32 valve||SFI. Cadillac Northstar V8 (For RWD) (Premium V). '04-'09 Cadillac SRX
|-
| A ||L20|| 4.8L || V8 || Gas/E85 ||OHV|| Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads. VVT.<br /> '10-'13 GMT900 pickups, '10-'14 Express/Savana
|-
| A ||LCV|| 2.5L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. VVT. '15-'22 Chevy Colorado, GMC Canyon,<br /> '17-'20 Buick Envision, '17-'21 GMC Acadia, '19-'21 Chevy Blazer
|-
| B ||LR2|| 2.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 60° V6.<br /> '82-'85 Chevy S-10/GMC S-15, '83-'85 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| B ||LU2|| 4.3L || V6 || Gas ||OHV|| TBI. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '90-'91 Astro/Safari higher output engine option.
|-
| B ||L81|| 3.0L || V6 || Gas ||DOHC,<br /> 24 valve||SFI. Opel 54° V6 engine (Made in the UK). '02-'03 Saturn Vue
|-
| B ||L33|| 5.3L || V8 || Gas ||OHV||SFI. Gen III Chevrolet Small-Block V8. Vortec 5300 H.O. 310hp. Aluminum Block & Heads.<br /> '05-'06 Silverado/Sierra 1500 4wd ext. cab short bed,<br> '07 Silverado Classic 1500/Sierra Classic 1500 4wd ext. cab short bed.
|-
| B ||LE8|| 2.2L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. SFI. GM Ecotec Gen II. VVT. '09-'10 Chevy HHR
|-
| B ||LC8|| 6.0L || V8 || Gas/CNG ||OHV||Bi-Fuel (Also Gas/LPG in Express/Savana). SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT. '11-'20 Express/Savana, '13-'19 Silverado HD/Sierra HD.
|-
| B ||LUV|| 1.4L ||I4 Turbo|| Gas ||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. SFI. VVT.<br /> '13-'21 Buick Encore, '15-'21 Chevy Trax (also '13-'14 Trax in Canada)
|-
| C ||LH6|| 6.2L || V8 || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR trucks '82-'93. '82-'86 C/K pickups, '87 R/V pickups,<br /> '88-'93 C/K, Sierra pickups, '82-'91 Blazer/Jimmy, Suburban, '83-'93 full-size vans
|-
| C ||L34|| 2.0L || I4 || Gas ||DOHC,<br /> 16 valve||Suzuki J20A engine. MFI. '99-'03 Chevrolet Tracker
|-
| C ||LY2|| 4.8L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads.<br /> '07-'09 GMT900 pickups, '07-'09 Tahoe/Yukon, '08-'09 Express/Savana
|-
| C ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '11.
|-
| C ||L83|| 5.3L || V8 || Gas/E85 ||OHV|| Flex Fuel. Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management<br /> '14-'19 K2XX pickups, '15-'20 K2XX SUVs.
|-
| C ||L2R|| 2.7L ||I4 Turbo||| Gas ||DOHC,<br /> 16 valve||GM L3B Tripower engine ("TurboMax") - Detuned version. Direct Injection. VVT, VVL. Active Fuel Management. '23-'24 Chevy Colorado.
|-
| D ||LE3|| 4.1L || I6 || Gas ||OHV||2-bbl carb. Chevrolet Turbo-Thrift I6.<br /> '81-'84 Chevy/GMC C/K pickups, full-size vans, '81-'82 Blazer/Jimmy
|-
| D ||LG6|| 3.1L || V6 || Gas ||OHV||TBI. Chevrolet 60° V6. '90-'95 U-body minivans.
|-
| D ||L61|| 2.2L || I4 || Gas ||DOHC,<br /> 16 valve||SFI. GM Ecotec Gen I. '02-'07 Saturn Vue, '06 Chevy HHR.
|-
| D ||L61|| 2.2L || I4 || Gas ||DOHC,<br /> 16 valve||SFI. GM Ecotec Gen II. '07-'08 Chevy HHR.
|-
| D ||LLT|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. '09-'16 GMC Acadia, '17 GMC Acadia Limited,<br /> '09-'17 Chevrolet Traverse, Buick Enclave, '09-'10 Saturn Outlook
|-
| D ||LBZ|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine.<br /> Mid '06 Silverado HD/Sierra HD & '07 Silverado Classic HD/Sierra Classic HD
|-
| D ||L84|| 5.3L || V8 || Gas/E85 ||OHV|| Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. With Dynamic Fuel Management<br /> '19+ Chevy/GMC Silverado 1500/Sierra 1500, '21+ Tahoe/Yukon, Suburban/Yukon XL.
|-
| E ||LN8|| 2.5L || I4 || Gas ||OHV||TBI. Pontiac Iron Duke/Tech IV engine.<br /> '85-'90 Chevy/GMC S-10/S-15, Astro/Safari Cargo Van, '85-'88 S-10 Blazer/S-15 Jimmy.
|-
| E ||LLR|| 3.7L || I5 || Gas ||DOHC,<br /> 20 valve||Atlas I5. SFI. VVT.<br /> '07-'12 Colorado/Canyon, '07-'08 Isuzu i-370, '07-'10 Hummer H3, '09-'10 Hummer H3T
|-
| E ||LA1|| 3.4L || V6 || Gas ||OHV||Chevrolet 60° V6. '96 GMT199 (U-body) minivans, '97-'05 GMT200 (U-body) minivans,<br /> '01-'05 Pontiac Aztek, '02-'05 Buick Rendezvous
|-
| F ||LF3|| 5.0L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. '81-'86 C/K, full-size vans, '81-'82 Blazer/Jimmy.<br /> CA emissions version of LE9 5.0 V8.
|-
| F ||L65|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks '92-'02,<br /> Chevy/GMC Suburban 1500/2500 '94-'99, over-8,500 lb. GVWR Express/Savana '96-'02
|-
| F ||LNJ|| 3.4L || V6 || Gas ||OHV||Chevrolet 60° V6. Made in China by SAIC-GM. '05-'09 Chevy Equinox, '06-'09 Pontiac Torrent.
|-
| F ||L94|| 6.2L || V8 || Gas/E85 ||OHV||Flex-Fuel. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT. Active Fuel Management. '10-'14 GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV.
|-
| F ||L20|| 4.8L || V8 || Gas/E85 ||OHV|| Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads. VVT.<br /> '15-'17 Express/Savana
|-
| F ||L82|| 5.3L || V8 || Gas ||OHV|| Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. With Active Fuel Management<br /> '19-'21 Chevy Silverado 1500, GMC Sierra 1500 (T1XX).
|-
| G ||LG9|| 5.0L || V8 || Gas ||OHV|| 2-bbl carb. Gen I Chevrolet Small-Block V8. '81 Chevy/GMC C/K pickups, Blazer/Jimmy, full-size van
|-
| G ||L18|| 8.1L || V8 || Gas ||OHV||MFI. Vortec 8100. Gen VII Chevrolet Big-Block V8. '01-'02 C3500HD, '01-'06 Silverado HD/Sierra HD, '07 Silverado Classic HD/Sierra Classic HD, '01-'06 Suburban/Yukon XL 2500, '02-'06 Avalanche 2500, '01-'02 Express/Savana
|-
| G ||L96|| 6.0L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '10-'19 Silverado HD/Sierra HD, '10-'13 Suburban 2500/Yukon XL 2500, '16-'19 Suburban 3500,<br /> '10-'20 Express/Savana.
|-
| G ||LSD|| 1.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '23+ Chevy Equinox, GMC Terrain
|-
| H ||LG4|| 5.0L || V8 || Gas ||OHV||4-bbl carb. Gen I Chevy Small-Block V8. (305 cu. in.) '81-'87 Chevy El Camino, GMC Caballero.
|-
| H ||LE9|| 5.0L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. '81-'86 C/K pickups, Blazer/Jimmy, Suburban, full-size vans
|-
| H ||L03|| 5.0L || V8 || Gas ||OHV|| TBI. Gen I Chevrolet Small-Block V8. '87 R/V pickups, '88-'95 C/K, Sierra pickups, '87-'95 full-size vans, '87 Blazer/Jimmy, Suburban.
|-
| H ||LN2|| 2.2L || I4 || Gas ||OHV||SFI. Chevrolet "122" engine. '03 Chevy S-10/GMC Sonoma
|-
| H ||LS2|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevy Small-Block V8. Chevy SSR '05-'06, Trailblazer SS '06-'09, Saab 9-7X Aero '08-'09.
|-
| H ||LV3|| 4.3L || V6 || Gas/E85 ||OHV||Flex Fuel. Chevrolet 90° V6 - Gen V Chevrolet Small-Block V6 (EcoTec3). Direct injection, VVT. Active Fuel Management. '14-'21 Chevy Silverado 1500/GMC Sierra 1500.
|-
| J ||L39|| 4.4L || V8 || Gas ||OHV||2-bbl carb. Gen I Chevy Small-Block V8 (267 cu. in.) '81-82 Chevy El Camino, GMC Caballero.
|-
| J ||LL4|| 6.2L || V8 || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR trucks '82-'93. '82-'86 C/K pickups, '87-'91 R/V pickups,<br /> '88-'93 C/K, Sierra pickups, '82-'91 Blazer/Jimmy, Suburban, '83-'93 full-size vans
|-
| J ||L29|| 7.4L || V8 || Gas ||OHV|| MFI. Vortec 7400. Gen VI Chevrolet Big-Block V8.<br /> '96-'00 C/K, Sierra pickups, Express/Savana, '96-'99 Suburban 2500
|-
| J ||LY5|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. Iron Block & Aluminum Heads.<br /> '07-'09 Silverado/Sierra 1500, Tahoe/Yukon, Suburban/Yukon XL 1500, Avalanche
|-
| J ||LZ1|| 6.0L || V8 || Gas-Electric Hybrid ||OHV||2-Mode Hybrid. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT. Active Fuel Management. '10-'13 Tahoe Hybrid, Yukon Hybrid, Escalade Hybrid, Silverado Hybrid, Sierra Hybrid
|-
| J ||L86|| 6.2L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management. <br /> '14-18 Chevy/GMC Silverado 1500/Sierra 1500,<br /> '18-20 Chevy Tahoe Premier, '19-'20 Chevy Suburban Premier, GMC Yukon/Yukon XL SLT,<br /> '15-'20 GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV.
|-
| K ||LC3|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '81-'82 Chevy El Camino, GMC Caballero (49-state emissions)
|-
| K ||L05|| 5.7L || V8 || Gas ||OHV|| TBI. Gen I Chevrolet Small-Block V8. '87 R/V pickups, '88-'95 C/K, Sierra pickups, '87-'95 full-size vans, '96 G-Classic full-size vans, '87-'94 Blazer, '95 Tahoe, '87-'91 Jimmy, '92-'95 Yukon, '87-'95 Suburban.
|-
| K ||LY6|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '07-'09 Silverado HD/Sierra HD, '07-'09 Suburban 2500/Yukon XL 2500, '08-'09 Express/Savana
|-
| K ||LEA|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex Fuel. GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '12-'17,<br /> Chevy Captiva Sport '12-'14, Chevy Orlando '14.
|-
| K ||L3B|| 2.7L ||I4 Turbo||| Gas ||DOHC,<br /> 16 valve||GM L3B Tripower engine ("TurboMax"). Direct Injection. VVT, VVL. Active Fuel Management.<br /> '19+ Chevy Silverado 1500, GMC Sierra 1500, '23+ Chevy Colorado, GMC Canyon.
|-
| L ||LS9|| 5.7L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. For sub-8,500 lb. GVWR trucks, vans, Suburban, Blazer/Jimmy (CA) '81-'86.
|-
| L ||L27|| 3.8L || V6 || Gas ||OHV||Buick V6 (3800 Series I). '92-'95 U-body minivans
|-
| L ||LX9|| 3.5L || V6 || Gas ||OHV||GM High Value 60° V6. 3498cc. SFI. '05-'06 GMT201 minivans, '06-'07 Buick Rendezvous
|-
| L ||LH8|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads.<br /> '08-'09 Hummer H3 Alpha, '09 Colorado/Canyon, Hummer H3T Alpha
|-
| L ||LGH|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. Mid '10-'16 Express/Savana, '11-'12 Silverado HD/Sierra HD chassis cabs
|-
| L ||L87|| 6.2L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Dynamic Fuel Management.<br /> '19+ Chevy/GMC Silverado 1500/Sierra 1500, '21+ Tahoe/Yukon, Suburban/Yukon XL,<br /> Cadillac Escalade/Escalade ESV.
|-
| L ||L3T|| 1.3L || I3 Turbo || Gas ||DOHC,<br /> 12 valve||GM E-Turbo Engine. Direct Injection. VVT. '20+ Buick Encore GX, '21+ Chevy Trailblazer.
|-
| M ||LT9|| 5.7L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevy Small-Block V8.<br /> For over-8,500 lb. GVWR C/K trucks, full-size vans, Suburban '81-'86, full-size van cutaway '81-'88.<br /> '88 Chevy/GMC R30/3500 Chassis Cab w/C7C (10,500 lb. GVWR),<br /> V30/3500 Chassis Cab w/C7E (11,000 lb. GVWR)
|-
| M ||L30|| 5.0L || V8 || Gas ||OHV||Gen 1+ Chevrolet Small-Block V8. Vortec 5000. CPI.<br /> '96-'99 Chevy C/K, GMC Sierra, '96-'02 Express/Savana
|-
| M ||LNF|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. 2010 Chevy HHR SS.
|-
| M ||LH6|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. Aluminum Block & Heads.<br /> '05-'06 GMT370 SUVs (Trailblazer EXT/Envoy XL/Isuzu Ascender 7-psgr.), '05-'07 Buick Rainier,<br /> '05-'09 GMC Envoy Denali, Saab 9-7X, '06-'08 Chevy Trailblazer, '05 GMC Envoy XUV,<br /> '07-'09 Silverado/Sierra 1500
|-
| M ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Orlando '12.
|-
| M ||LE2|| 1.4L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '16-'19 & '21-'22 Buick Encore, '21-'22 Chevy Trax.
|-
| N ||L10|| 1.8L || I4 || Gas ||SOHC,<br /> 8 valve||2-bbl carb. Isuzu G180Z engine imported from Japan. '81-'82 Chevy LUV
|-
| N ||LF9|| 5.7L || V8 || Diesel ||OHV||Oldsmobile Diesel V8. '83-'84 Chevy El Camino/GMC Caballero.
|-
| N ||LB1|| 4.3L || V6 || Gas ||OHV|| 4-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '85 Astro/Safari, '85-'86 C/K pickups & full-size vans
|-
| N ||L19|| 7.4L || V8 || Gas ||OHV|| Mark IV Chevrolet Big-Block V8. TBI.<br /> '87-'90 R/V pickups, Suburban 2500, '88-'90 C/K, Sierra pickups, full-size vans
|-
| N ||L19|| 7.4L || V8 || Gas ||OHV|| Gen V Chevrolet Big-Block V8. TBI.<br /> '91 R/V pickups, '91-'95 C/K, Sierra pickups, Suburban 2500, full-size vans. '96 G-Classic full-size vans
|-
| N ||LZ4|| 3.5L || V6 || Gas ||OHV||GM High Value 60° V6. 3510cc. SFI. VVT. '08-'09 Saturn Vue
|-
| N ||LQ9|| 6.0L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Vortec 6000 H.O. or VortecMAX. Iron Block/Aluminum Heads.<br /> 345 hp. '02-'06 Cadillac Escalade, '03-'06 Cadillac Escalade ESV, '03-'06 Chevy Silverado SS,<br /> '05-'06 GMC Sierra Denali, '07 GMC Sierra Classic Denali.
|-
| N ||LGZ|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. Direct Injection. VVT. Active Fuel Management.<br /> '17-'22 Chevy Colorado, GMC Canyon.
|-
| P ||L49|| 6.5L || V8 || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks & full-size vans '94-'95
|-
| P ||LM4|| 5.3L || V8 || Gas ||OHV||Gen III Chevrolet Small-Block V8. Vortec 5300. 290hp. Aluminum Block & Heads.<br /> '03-'04 Chevy SSR, '03-'04 GMT370 SUVs (Trailblazer EXT/Envoy XL/Isuzu Ascender 7-psgr.),<br /> '04 Buick Rainier, GMC Envoy XUV
|-
| P ||LE5|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||MFI. GM Ecotec Gen II. VVT. '06-'08 Chevy HHR, '08-'09 Saturn Vue
|-
| P ||LH9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT.<br /> '10-'12 Colorado/Canyon, '10 Hummer H3 Alpha, H3T Alpha
|-
| P ||LV1|| 4.3L || V6 || Gas ||OHV||Chevrolet 90° V6 - Gen V Chevrolet Small-Block V6 (EcoTec3). Direct injection, VVT.<br /> '18+ Chevy Express/GMC Savana.
|-
| P ||LBP|| 1.2L || I3 Turbo || Gas/E85 ||DOHC,<br /> 12 valve||Flex Fuel. GM E-Turbo Engine. Direct Injection. VVT.<br /> '25+ Buick Encore GX, Chevy Trailblazer, '25- Chevy Trax, Buick Envista.
|-
| R ||LL2|| 2.8L || V6 || Gas ||OHV||TBI. Chevrolet 60° V6. '86-'93 Chevy S-10, GMC S-15/Sonoma,<br /> '86-'89 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| R ||L31|| 5.7L || V8 || Gas ||OHV||Gen 1+ Chevrolet Small-Block V8. Vortec 5700. CPI.<br /> '96-'99 Chevy C/K, GMC Sierra, '96-'99 Chevy Tahoe/GMC Yukon, Chevy/GMC Suburban, '99-'00 GMC Yukon Denali, Cadillac Escalade, '00 Chevy Tahoe Limited/Z71, '96-'02 Chevy Express/GMC Savana.
|-
| R ||L8B|| 5.3L || V8 || Gas ||OHV||Mild Hybrid. Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management. '16-'18 Chevy Silverado 1500, GMC Sierra 1500.
|-
| S ||LQ7|| 2.2L || I4 || Diesel ||OHV||Isuzu C220 engine imported from Japan. '81-'82 Chevy LUV, '84-'85 Chevy S-10/GMC S-15
|-
| S ||L56|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks '94-'99,<br /> Chevy Blazer '94, Chevy Tahoe 2-d '95-'99, GMC Yukon 2-d '94-'97
|-
| S ||LL8|| 4.2L || I6 || Gas ||DOHC,<br /> 24 valve||Atlas I6. SFI. VVT. '02-'09 GMT360/370 SUVs (Chevy Trailblazer, GMC Envoy, Oldsmobile Bravada, Buick Rainier, Isuzu Ascender, Saab 9-7X)
|-
| S ||LGX|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. Direct Injection. VVT. Active Fuel Management.<br /> '17+ Cadillac XT5, '17-'23 GMC Acadia, '19+ Chevrolet Blazer, '20-'25 Cadillac XT6.
|-
| S ||LK0|| 2.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||L3B engine family. Direct Injection. VVT. '24- Chevy Traverse, GMC Acadia, '25- Buick Enclave
|-
| T ||L25|| 4.8L || I6 || Gas ||OHV||1-bbl carb. Chevrolet Turbo-Thrift I6. '81-'86 Chevy/GMC C/K pickups, '88 R/V pickups
|-
| T ||LM7|| 5.3L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads. Vortec 5300. 270/285/295hp.<br /> '99-'07 GMT800 pickups & SUVs including '02-'05 Escalade 2wd, '07 Silverado Classic 1500/<br> Sierra Classic 1500, '03-'07 Express/Savana
|-
| T ||LEA|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex Fuel. GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Orlando '13.
|-
| T ||LM2|| 3.0L || I6 Turbo|| Diesel ||DOHC,<br /> 24 valve|| Duramax Diesel I6. Aluminum Block & Heads. '20-'22 Silverado/Sierra 1500, '21-'24 Tahoe/Suburban, Yukon/Yukon XL, Escalade/Escalade ESV.
|-
| U ||LS5|| 1.6L || I4 || Gas ||SOHC,<br /> 8 valve||Suzuki G16A engine. TBI. '89-'95 Geo Tracker
|-
| U ||LQ4|| 6.0L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads (Iron Heads in '99-'00).<br /> '99-'06 GMT800 pickups, '07 Silverado Classic 1500HD/Sierra Classic 1500HD,<br> '00-'06 Suburban/Yukon XL 2500, '01-'06 Yukon Denali/Yukon XL Denali,<br> '06 Suburban LTZ, '03-'07 Express/Savana, '03-'07 Hummer H2.
|-
| U ||LE9|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. GM Ecotec Gen II. 2011 Chevy HHR
|-
| U ||LH7|| 1.6L ||I4 Turbo|| Diesel ||DOHC,<br /> 16 valve||GM Medium Diesel engine ("Whisper Diesel"). Made by Opel in Szentgotthárd, Hungary.<br /> Aluminum Block & Heads. '18-'19 Chevy Equinox & GMC Terrain Diesel.
|-
| V ||LR4|| 4.8L || V8 || Gas ||OHV||Gen III Chevrolet Small-Block V8. Iron Block/Aluminum Heads.<br> '99-'06 GMT800 pickups, '07 Silverado Classic 1500/Sierra Classic 1500,<br /> '00-'06 Tahoe/Yukon, '03-'07 Express/Savana
|-
| V ||LE9|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. GM Ecotec Gen II. 2009-2010 Chevy HHR
|-
| V ||LYX|| 1.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '18-'22 Chevy Equinox, GMC Terrain
|-
| W ||LE8|| 7.4L || V8 || Gas ||OHV|| Mark IV Chevrolet Big-Block V8. 4bbl carb. '81-'86 Chevy/GMC C/K pickups, Suburban.<br /> '88-'89 Chevy/GMC R30/3500 Chassis Cab w/C7C (10,500 lb. GVWR),<br /> V30/3500 Chassis Cab w/C7E (11,000 lb. GVWR)
|-
| W ||L35|| 4.3L || V6 || Gas ||OHV|| CPI. Vortec 4300 H.O. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '92-'95 Sonoma, S-10 Blazer/Jimmy, Astro/Safari, '94-'95 S-10, '92-'94 Oldsmobile Bravada
|-
| W ||L35|| 4.3L || V6 || Gas ||OHV|| SFI. Vortec 4300 H.O. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '96-'02 S-10/Sonoma, Blazer/Jimmy, Express/Savana, C/K, Silverado, Sierra, '96-'01 Bravada, Astro/Safari, '00 Isuzu Hombre
|-
| W ||LGD|| 3.9L || V6 || Gas/E85 ||OHV||Flex Fuel. GM High Value 60° V6. SFI. VVT. '07-'09 GMT201 minivans
|-
| W ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '10.
|-
| W ||LE8|| 2.2L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. SFI. GM Ecotec Gen II. VVT. 2011 Chevy HHR.
|-
| W ||LFY|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection.<br> '18-'23 Chevrolet Traverse, '24 Chevrolet Traverse Limited, '18-'24 Buick Enclave.
|-
| X ||LF6|| 4.3L || V6 || Gas ||OHV||SFI. Vortec 4300. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '96-'99 S-10/Sonoma, '97-'99 Isuzu Hombre.
|-
| X ||LU3|| 4.3L || V6 || Gas ||OHV||Vortec 4300. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '03-'04 S-10/Sonoma,<br /> '03-'05 Blazer/Jimmy, '02-'05 Astro/Safari, '03-'14 Express/Savana, '03-'13 Silverado/Sierra,<br> '07 Silverado Classic 1500/Sierra Classic 1500
|-
| X ||LNF|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. '08-'09 Chevy HHR SS.
|-
| X ||LTG|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. VVT.<br /> '16-'20 Buick Envision, '18-'20 Chevy Equinox, GMC Terrain, '18-'19 Chevy Traverse RS
|-
| Y ||LQ2|| 2.0L || I4 || Gas ||OHV||2-bbl carb. Chevrolet "122" engine.<br /> '83-'84 Chevy S-10/GMC S-15, '83-'84 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| Y ||L57|| 6.5L || V8 || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR full-size vans '94-'95 & '96 G-Classic full-size vans
|-
| Y ||L76|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevy Small-Block V8. Aluminum Block & Heads. VVT. With Active Fuel Management.<br /> '07-'09 Silverado/Sierra, Suburban/Yukon XL, Chevy Avalanche
|-
| Y ||LF1|| 3.0L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. VVT.<br /> '10-'11 Cadillac SRX, '11 Saab 9-4X, '10 Chevy Equinox, GMC Terrain
|-
| Y ||L5P|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '17+ Silverado HD/Sierra HD. Engine updated in '24.
|-
| Z ||LF9|| 5.7L || V8 || Diesel ||OHV||Oldsmobile Diesel V8. '81 Chevy C10/GMC C1500 full-size pickups.
|-
| Z ||LB4|| 4.3L || V6 || Gas ||OHV|| TBI. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '85-'87 Chevy El Camino/GMC Caballero,<br /> '86-'94 Astro/Safari, '87 R/V pickups, '88-'95 C/K & Sierra pickups, '87-'95 full-size vans & <br /> '96 G-Classic full-size vans, '88-'95 S-10, S-15/Sonoma, '88-'94 S-10 Blazer, S-15 Jimmy,<br /> '91-'92 Oldsmobile Bravada
|-
| Z ||LB4|| 4.3L || V6 Turbo || Gas ||OHV|| MPI. For GMC Syclone & Typhoon. Chevrolet 90° V6 (Chevy Small-Block V8 Derived)
|-
| Z ||L59|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads. Vortec 5300. 285/295hp.<br /> '02-'07 GMT800 pickups, '07 Silverado Classic 1500/Sierra Classic 1500, '02-'06 Suburban/Yukon XL, Avalanche.
|-
| Z ||LAT|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||Mild Hybrid. MFI. GM Ecotec Gen II. VVT. '07-'09 Saturn Vue Green Line
|-
| 1 ||LZ9|| 3.9L || V6 || Gas ||OHV||GM High Value 60° V6. SFI. VVT. '06-'09 GMT201 minivans
|-
| 1 ||LE5|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||MFI. GM Ecotec Gen II. VVT. '10 Saturn Vue.
|-
| 1 ||LB7|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. First version of the Duramax V8. '01-Mid '04 Silverado HD/Sierra HD
|-
| 1 ||LWN|| 2.8L || I4 Turbo || Diesel ||DOHC,<br /> 16 valve||Based on VM Motori A428 engine. Made by GM Powertrain Thailand 2016-2020. Made in Brazil for '22. '16-'22 Colorado/Canyon, '17-'22 Express/Savana.
|-
| 2 ||LLY|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. Mid '04-Mid '06 Silverado HD/Sierra HD, '06-Mid '07 Express/Savana
|-
| 2 ||L9H|| 6.2L || V8 || Gas/E85 ||OHV||Flex-Fuel. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT.<br /> '09-'13 Chevy Silverado 1500, GMC Sierra 1500, Sierra Denali 1500,<br /> '09 Chevy Tahoe LTZ, GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV,<br> Hummer H2
|-
| 2 ||LIH|| 1.2L || I3 Turbo || Gas ||DOHC,<br /> 12 valve||GM E-Turbo Engine. Direct Injection. VVT.<br /> '20-'24 Buick Encore GX, '21-'24 Chevy Trailblazer, '24 Chevy Trax, Buick Envista,<br> '25 Chevy Trax, Buick Envista (Canada only).
|-
| 3 ||LC9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT added for '10. Aluminum Block & Heads.<br /> '07-'11 Silverado/Sierra 1500, Tahoe/Yukon, Suburban/Yukon XL 1500, '07-'09 & '11 Avalanche
|-
| 3 ||LFX|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. VVT. E85 Flex Fuel.<br /> '12-'16 Cadillac SRX, '13-'17 Chevrolet Equinox, GMC Terrain, '15-'16 Colorado/Canyon
|-
| 4 ||LN2|| 2.2L || I4 || Gas ||OHV||MFI (94-95). SFI (96-00). Chevrolet "122" engine. '94-'00 S-10/Sonoma, '96-'00 Isuzu Hombre
|-
| 4 ||LE8|| 2.5L || V6 || Gas ||DOHC,<br /> 24 valve||Suzuki H25A engine. MFI. '01-'04 Chevrolet Tracker
|-
| 4 ||L66|| 3.5L || V6 || Gas ||SOHC,<br /> 24 valve||Honda J35S1 V6. VTEC. '04-'07 Saturn Vue
|-
| 4 ||LMF|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '08-'14 Express/Savana 1500
|-
| 4 ||LAU|| 2.8L || V6 Turbo || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. SFI. '10 Cadillac SRX
|-
| 4 ||LSY|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. Active Fuel Management. VVT. VVL.<br /> '19-'25 Cadillac XT4, '20+ Chevy Blazer, Cadillac XT5, '20-'23 GMC Acadia,<br /> '21+ Buick Envision, '21-'25 Cadillac XT6
|-
| 5 ||L43|| 2.2L || I4 || Gas/E85 ||OHV||Flex-Fuel. SFI. Chevrolet "122" engine. '00-'02 S-10/Sonoma, '00 Isuzu Hombre
|-
| 5 ||LFA|| 6.0L || V8 || Gas-Electric Hybrid ||OHV||2-Mode Hybrid. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT. Active Fuel Management. '08-'09 Tahoe Hybrid/Yukon Hybrid, '09 Escalade Hybrid, Silverado Hybrid/Sierra Hybrid
|-
| 5 ||LFW|| 3.0L || V6 || Gas/E85 ||DOHC,<br /> 24 valve||Flex-Fuel. GM High Feature V6. Direct Injection. VVT. '11-'12 Chevy Equinox, GMC Terrain,<br /> '12 Chevy Captiva Sport
|-
| 6 ||L01|| 1.6L || I4 || Gas ||SOHC,<br /> 16 valve||Suzuki G16B engine. MFI. '94-'97 Geo Tracker, '98-'00 Chevrolet Tracker
|-
| 6 ||L52|| 3.5L || I5 || Gas ||DOHC,<br /> 20 valve||Atlas I5. SFI. VVT. '04-'06 Colorado/Canyon, '06 Isuzu i-350, '06 Hummer H3
|-
| 6 ||LAU|| 2.8L || V6 Turbo || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. SFI. '11 Cadillac SRX, Saab 9-4X
|-
| 6 ||LMM|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '07-'10 Silverado HD/Sierra HD (GMT900), Mid '07-Mid '10 Express/Savana
|-
| 7 ||LY7|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. '04-'06 Buick Rendezvous, '04-'09 Cadillac SRX,<br /> '07-'08 GMC Acadia, Saturn Outlook, '08 Buick Enclave, '08-'10 Saturn Vue
|-
| 7 ||LC9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT.<br /> Aluminum Block & Heads.<br /> '12-'13 Silverado/Sierra 1500, Avalanche, '12-'14 Tahoe/Yukon, Suburban/Yukon XL 1500
|-
| 7 ||L8T|| 6.6L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8. Iron Block/Aluminum Heads. Direct injection, VVT.<br /> '20+ Silverado HD/Sierra HD, '21+ Express/Savana
|-
| 8 ||LK5|| 2.8L || I4 || Gas ||DOHC,<br /> 16 valve||Atlas I4. SFI. VVT. '04-'06 Colorado/Canyon, '06 Isuzu i-280.
|-
| 8 ||L92|| 6.2L || V8 || Gas ||OHV||Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT.<br /> '07-'08 GMC Sierra Denali, Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV,<br> '08 Chevy Tahoe LTZ, Hummer H2.
|-
| 8 ||LML|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine.<br /> '11-'16 Silverado HD/Sierra HD pickups, '13-'16 Silverado HD/Sierra HD chassis cabs.
|-
| 8 ||LZ0|| 3.0L || I6 Turbo|| Diesel ||DOHC,<br /> 24 valve|| Duramax Diesel I6. Aluminum Block & Heads.<br> '23+ Silverado/Sierra 1500, '24+ Suburban HD, '25+ Tahoe/Suburban, Yukon/Yukon XL.
|-
| 9 ||LC3|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '83-'84 Chevy El Camino, GMC Caballero (49-state emissions).
|-
| 9 ||LLV|| 2.9L || I4 || Gas ||DOHC,<br /> 16 valve||Atlas I4. SFI. VVT. '07-'12 Colorado/Canyon, '07-'08 Isuzu i-290.
|-
| 9 ||LT4|| 6.2L ||V8 Supercharged|| Gas ||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. Direct injection. VVT. Active Fuel Management. '23+ Cadillac Escalade/Escalade ESV V-Series.
|-
| 0 ||LMG|| 5.3L || V8 || Gas/E85 ||OHV||Flex-Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT added for '10.<br /> Iron Block & Aluminum Heads.<br /> '07-'13 Silverado/Sierra 1500, Avalanche, '07-'14 Tahoe/Yukon, Suburban/Yukon XL 1500.
|}
H.O.=High Output, VVT=Variable Valve Timing, VVL=Variable Valve Lift, GVWR=Gross Vehicle Weight Rating, CNG=Compressed Natural Gas, LPG=Liquefied Petroleum Gas (Propane Autogas)
====Motor codes for electric light trucks====
{| class="wikitable"
|-
! VIN !! RPO !! Fuel !! Drive Wheels !! Application/Notes
|-
| H ||LN1|| Electricity || Front || '97-'98 Chevrolet S-10 Electric.
|-
|}
====Motor codes for Ultium-powered electric light trucks====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Module <br /> RPO code !! # of Modules !! Fuel !! Drive Wheels !! Application/Notes
|-
| A ||XRL|| 3 || ETN || 24 || Electricity || All || '22- GMC Hummer EV pickup 3X
|-
| B ||XRL|| 3 || ETI || 20 || Electricity || All || '24- GMC Hummer EV pickup 3X
|-
| C ||XRL|| 3 || ETJ || 20 || Electricity || All || '24- GMC Hummer EV SUV 3X
|-
| D ||XRJ|| 2 || ETI || 20 || Electricity || All || '24 Chevrolet Silverado EV 3WT, '25- Silverado EV 5WT, 3LT,<br> '25 Silverado EV RST (2SP), '26- Silverado EV Trail Boss (2TR),<br> '24- GMC Hummer EV pickup 2X, '25- GMC Sierra EV Denali 5SC,<br> '26- Sierra EV Elevation 3SC, AT4 4SC
|-
| E ||XRJ|| 2 || ETJ || 20 || Electricity || All || '24- GMC Hummer EV SUV 2X
|-
| G ||XRJ|| 2 || ETJ || 20 || Electricity || All || '23 BrightDrop Zevo 600
|-
| H ||XRJ|| 2 || EWX || 14 || Electricity || All ||'26- Chevrolet Silverado EV 4WT, 2LT,<br> '26- GMC Sierra EV Elevation 3SB, Denali 5SB
|-
| J ||X0C|| 2 || EC5 || 10 || Electricity || All || '24 Chevy Blazer EV 2LT, 1RS AWD,<br> '25- Chevy Blazer EV 4LT, 3RS AWD, '24-'26 Honda Prologue AWD
|-
| K ||X0D|| 1 || EC6 || 12 || Electricity || Rear || '23- Cadillac Lyriq RWD, '24-'25 Chevrolet Blazer EV 2RS RWD,<br> '24 Acura ZDX A-Spec RWD
|-
| L ||X0E|| 2 || EC6 || 12 || Electricity || All || '23- Cadillac Lyriq AWD, '24- Chevrolet Blazer EV PPV AWD,<br> '25- Chevrolet Blazer EV SS AWD, '26- Cadillac Vistiq AWD,<br> '24 Acura ZDX A-Spec, Type S AWD
|-
| L ||XRJ|| 2 || ETN || 24 || Electricity || All || '24 Chevrolet Silverado EV 4WT, RST (3SP), '25- Silverado EV 8WT,<br> '25 Silverado EV RST (3SP), '26- Silverado EV 4LT, Trail Boss (3TR),<br> '24- GMC Sierra EV Denali 5SD, '26- Sierra EV AT4 4SD,<br> '25- Cadillac Escalade IQ, '26- Cadillac Escalade IQL
|-
| M ||X0B|| 1 || EC5 || 10 || Electricity || Front || '24-'26 Honda Prologue FWD, '25- Chevy Blazer EV 2LT, 1RS FWD
|-
| P ||X0B|| 1 || EC3 || 10 || Electricity || Front || '24- Chevrolet Equinox EV FWD
|-
| R ||X0C|| 2 || EC3 || 10 || Electricity || All || '24- Chevrolet Equinox EV AWD, '25 Cadillac Optiq AWD
|-
| Y ||XRJ|| 2 || ETC || 12 || Electricity || All || '24 BrightDrop Zevo 400, Zevo 600,<br> '25-'26 Chevrolet BrightDrop 400/600 AWD
|-
| Z ||XRJ|| 2 || ETJ || 20 || Electricity || All || '24 BrightDrop Zevo 400, Zevo 600,<br> '25-'26 Chevrolet BrightDrop 400/600 AWD
|-
| 4 ||X0E|| 2 || EC3 || 10 || Electricity || All || '26- Cadillac Optiq AWD
|-
| 5 ||X0D|| 1 || EC3 || 10 || Electricity || Rear|| '26- Cadillac Optiq RWD
|-
| 6 ||XRM|| 1 || ETC || 12 || Electricity || Front || '25-'26 Chevrolet BrightDrop 400/600 FWD
|-
| 7 ||XRJ|| 2 || EWU || 14 || Electricity || All || '26 Chevrolet BrightDrop 600 AWD
|}
SB=Standard Range, SC=Extended Range, SD=Max Range
====Engine codes for medium duty trucks 2016-====
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes/Applications
|-
| B ||L96|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '16-'20 Chevy LCF 3500/4500.
|-
| C ||LC8|| 6.0L || V8 || Gas/CNG or<br>Gas/LPG ||OHV||Bi-Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '16-'20 Chevy LCF 3500/4500.
|-
| D ||L8T|| 6.6L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8. Iron Block/Aluminum Heads. Direct injection, VVT.<br /> '21-'23 Chevy LCF 3500/4500, '24- Chevy LCF 3500HG/4500HG/5500HG/5500XG.
|-
| F ||LCB|| 6.7L || I6 Turbo || Diesel ||OHV,<br /> 32 valve||Cummins B Series ISB engine. '22- Chevy LCF 6500XD, '23- Chevy LCF 7500XD.
|-
| 6 ||I1B|| 5.2L || I4 Turbo || Diesel ||SOHC,<br /> 16 valve||Isuzu 4HK1-TC engine. '17- Chevy LCF 4500HD/XD, 5500XD, '17-'24 Chevy LCF 5500HD,<br /> '18-'21 Chevy LCF 6500XD.
|-
| 7 ||IZ3|| 3.0L || I4 Turbo || Diesel ||DOHC,<br /> 16 valve||Isuzu 4JJ1-TC engine. '16-'18 Chevy LCF 3500HD.
|-
|}
====Engine codes for AM General-built Hummer H1 2000-2006====
AM General encodes the engine type in character 4 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| F || || 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8 built by GEP (General Engine Products), a subsidiary of AM General.<br> '01-'04 Hummer H1 & '06 H1 Fleet models.
|-
| P ||LLY|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '06 Hummer H1 Alpha.
|-
| Z ||L65|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8 built by GM. '00-'01 Hummer H1.
|-
|}
====Engine codes for Nissan-built vans====
Nissan encodes the engine type in character 4 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| 3 ||L0A|| 2.0L || I4 || Gas ||DOHC,<br /> 16 valve||Nissan MR20DE engine. SFI. VVT. For the '15-'18 Chevrolet City Express.
|-
|}
====Engine codes for Navistar-built medium-duty trucks====
Navistar encodes the engine type in character 6 & 7 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| PV ||L5D|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. For the Chevy Silverado Medium Duty '19+.
|-
|}
==GM factories supplying North America==
===North American GM factories===
[[w:List_of_General_Motors_factories | List of GM Factories]]
{| class="wikitable"
!VIN code
!Location
!Notes
|-
|A
|Lakewood Assembly (Lakewood Heights, Atlanta, Georgia)
|through 1990 model year
|-
|A
|Artisan Center (Warren, Michigan)
|From 2026 model year. Cadillac CT5-V Blackwing "Curated by Cadillac" program only.
|-
|B
|Baltimore Assembly (Baltimore, Maryland)
|through 2005 model year
|-
|B
|Reatta Craft Centre/Lansing Craft Centre (Lansing Township, Michigan)
|1988-2006 model year (except GM EV1)
|-
|B
|GM Defense-Manufacturing Customer Innovation Center (MCIC) (Concord, North Carolina)
|From 2024 model year. Chevrolet Suburban HD (a.k.a. HD SUV) (for US govt. only).
|-
|C
|South Gate Assembly (South Gate, California)
|through 1982 model year
|-
|C
|Lansing Car Assembly (Lansing, Michigan)
|South assembly line 1985-2004 model year
|-
|D
|Doraville Assembly (Doraville, Georgia)
|through 2009 model year
|-
|E
|Linden Assembly (Linden, New Jersey)
|through 1991 model year
|-
|E
|Pontiac East Assembly (Pontiac, Michigan)
|1988-2009 model year
|-
|E
|AM General Military plant (Mishawaka, Indiana)
|1992-2006 Hummer H1
|-
|F
|Flint Truck Assembly (Flint, Michigan)
|since 1953
|-
|F
|Fairfax II Assembly (Kansas City, Kansas)
|since 1988 model year
|-
|G
|Framingham Assembly (Framingham, Massachusetts)
|through 1989 model year
|-
|G
|Silao Assembly (Silao, Guanajuato, Mexico)
|since 1995 model year
|-
|H
|Buick City Assembly (Flint, Michigan)
|through 1999 model year
|-
|H
|AM General Commercial plant (Mishawaka, Indiana)
|2003-2009 Hummer H2
|-
|H
|Navistar Springfield plant (Main Line) (Springfield, Ohio)
|2019- Chevrolet Silverado Medium Duty (4500HD/5500HD/6500HD)
|-
|J
|Janesville Assembly (Janesville, Wisconsin)
|through 2009 model year
|-
|J
|Lansing Delta Township Assembly (Lansing, Michigan)
|since 2007 model year
|-
|K
|Leeds Assembly (Leeds, Kansas City, Missouri)
|through 1988 model year
|-
|K
|Linden Assembly (Linden, New Jersey)
|from 1994-2005 model year
|-
|K
|Nissan plant (Cuernavaca, Morelos, Mexico)
|2015-2018 Chevrolet City Express
|-
|L
|Van Nuys Assembly (Van Nuys, California)
|through 1992 model year
|-
|L
|San Luis Potosí Assembly (San Luis Potosí, Mexico)
|since 2009 model year
|-
|M
|Lansing Car Assembly (Lansing, Michigan)
|through 1984 model year, North assembly line 1985-2005 model year
|-
|M
|Toluca Assembly (Toluca, Mexico state, Mexico)
|through 2008 model year
|-
|N
|Norwood Assembly (Norwood, Ohio)
|through 1987 model year
|-
|N
|Navistar Springfield plant (Secondary Line) (Springfield, Ohio)
|2017- Chevrolet Express cutaway, GMC Savana cutaway
|-
|P
|Pontiac Assembly (Pontiac, Michigan)
|through 1988 model year
|-
|R
|Arlington Assembly (Arlington, Texas)
|since 1965 [all GM brands]. (R plant code used only by Chevrolet in 1963-64)
|-
|S
|St. Louis Assembly (St. Louis, Missouri)
|through 1987 model year
|-
|S
|Spring Hill Manufacturing (Spring Hill, Tennessee)
|2002-2007 Saturn Vue & 2009-2010 Chevrolet Traverse only
|-
|S
|Spartan Motors/Shyft Group plant (Charlotte, Michigan)
|2016- Chevrolet Low Cab Forward 3500/3500HG/4500/4500HG/5500HG/5500XG/6500XD/7500XD
|-
|S
|Ramos Arizpe Assembly (Ramos Arizpe, Coahuila, Mexico)
|since 1982
|-
|T
|Tarrytown Assembly (North Tarrytown, New York)
|through 1996 model year
|-
|U
|Detroit/Hamtramck Assembly (Factory Zero) <br /> (Detroit & Hamtramck, Michigan)
|since 1986 model year
|-
|U
|Artisan Center (Warren, Michigan)
|From 2025 model year. Cadillac Celestiq only.
|-
|V
|Pontiac Central Assembly (Pontiac, Michigan)
|through 1991 model year
|-
|V
|Pontiac East Assembly (Pontiac, Michigan)
|through 1985 model year
|-
|W
|Willow Run Assembly (Ypsilanti Township, Michigan)
|through 1993 model year
|-
|X
|Fairfax Assembly (Fairfax I) (Kansas City, Kansas)
|through 1987 model year
|-
|Y
|Wilmington Assembly (Wilmington, Delaware)
|through 2010 model year
|-
|Z
|Fremont Assembly (Fremont, California)
|through 1982 model year
|-
|Z
|NUMMI (Fremont, California)
|1985-2010 model year
|-
|Z
|Spring Hill Manufacturing (Spring Hill, Tennessee)
|since 1991 model year (except Vue & Traverse)
|-
|Z
|Fort Wayne Assembly (Roanoke, Indiana)
|since 1988 model year
|-
|0
|Pontiac West Assembly (Pontiac, Michigan)
|through 1994 model year
|-
|0
|Lansing Craft Centre (Lansing Township, Michigan)
|GM EV1 only
|-
|0
|Lansing Grand River Assembly (Lansing, Michigan)
|since 2003 model year
|-
|0
|Artisan Center (Warren, Michigan)
|2024 Cadillac CT5-V Blackwing 20th Anniversary Edition where the final eight digits of the VIN are R0912004 through R0912024 or R0962004 through R0962024
|-
|1
|Wentzville Assembly (Wentzville, Missouri)
|since 1985 model year
|-
|1
|Oshawa Car Assembly (Oshawa, Ontario, Canada)
|from 1967-1983 model year
|-
|1
|Oshawa Car Assembly (Line 2 a.k.a. Consolidated Line) (Oshawa, Ontario, Canada)
|from 1984-2019 model year; switched to pickup trucks for 2019 model year
|-
|1
|Oshawa Car Assembly (Oshawa, Ontario, Canada)
|Silverado pickup trucks since 2022 model year
|-
|1
|Oshawa Truck Assembly (Oshawa, Ontario, Canada)
|through 2009 model year
|-
|2
|Moraine Assembly (Moraine, Ohio)
|through 2009 model year
|-
|2
|Sainte-Thérèse Assembly (Boisbriand, Quebec, Canada)
|through 2002 model year
|-
|3
|Detroit Truck & Bus plant (Piquette Ave., Detroit, Michigan)
|through 1999 model year
|-
|3
|Saint-Eustache Bus Plant (Saint-Eustache, Quebec, Canada)
|through 1987 model year
|-
|4
|Orion Assembly (Orion Township, Michigan)
|since 1985 model year
|-
|4
|Scarborough Van Assembly (Scarborough, Ontario, Canada)
|through 1993 model year
|-
|5
|Bowling Green Assembly (Bowling Green, Kentucky)
|since 1981 model year
|-
|6
|Oklahoma City Assembly (Oklahoma City, Oklahoma)
|through 2006 model year
|-
|6
|CAMI plant (Ingersoll, Ontario, Canada)
|1990-2022 model year
|-
|7
|Lordstown Assembly (Warren, Ohio)
|from 1979-2019 model year
|-
|8
|Shreveport Assembly (Shreveport, Louisiana)
|through 2012 model year
|-
|9
|Detroit Assembly (Clark Street, Detroit, Michigan)<br> (Cadillac plant)
|from 1979-1988 model year
|-
|9
|Oshawa Car Assembly (Line 1 a.k.a. Flex Line)<br> (Oshawa, Ontario, Canada)
|from 1984-2020 model year
|-
|9
|KUKA plant (Livonia, Michigan)
|2022 model year only (BrightDrop Zevo 600)
|-
|9
|CAMI plant (Ingersoll, Ontario, Canada)
|2023-2026 model year (BrightDrop Zevo/Chevrolet BrightDrop)
|}
===Non-North American GM factories supplying North America===
{| class="wikitable"
!VIN code
!Location
!Models Sourced
|-
|A
|SAIC-GM plant: Jinqiao, Pudong district, Shanghai, China
|2017-2018 Cadillac CT6 Plug-in Hybrid
|-
|B
|Daewoo/GM Daewoo/GM Korea plant: Bupyeong, South Korea
|1988-1993 Pontiac LeMans, 2004-2011 Chevrolet Aveo, 2005-2010 Pontiac Wave/G3, 2004-2006 Chevrolet <br /> Epica (Canada), 2013-2022 Chevrolet Trax, Buick Encore, 2021- Chevrolet Trailblazer, 2020- Buick Encore GX, 2024- Buick Envista
|-
|C
|GM Daewoo/GM Korea plant: Changwon, South Korea
|2003-2010 Pontiac Matiz/Matiz G2 (Mexico), 2013-2022 Chevrolet Spark, 2024- Chevrolet Trax
|-
|D
|SAIC-GM Dongyue Motors plant: Yantai, Shandong province, China
|2016- Buick Envision, 2019-2023 Chevrolet Aveo (Mexico), 2023- Chevrolet Onix (Mexico)
|-
|G
|Opel plant: Gliwice, Poland
|2016-2019 Buick Cascada
|-
|K
|Suzuki plant: Kosai, Shizuoka prefecture, Japan
|1985-1988 Chevrolet Sprint, 1989-1990 Geo Metro hatchback, 1990-1993 Geo Metro convertible, 1985-1990 Pontiac Firefly (Canada), 1991 & 1994 Pontiac Firefly convertible & sedan (Canada)
|-
|K
|GM Daewoo/GM Korea plant: Kunsan, South Korea
|2004-2007 Chevrolet Optra (Canada), 2012-2014 Chevrolet Orlando (Canada)
|-
|L
|Holden plant: Elizabeth, South Australia, Australia
|2004-2006 Pontiac GTO, 2008-2009 Pontiac G8, 2011-2017 Chevrolet Caprice PPV, 2014-2017 Chevrolet SS
|-
|R
|Opel plant: Rüsselsheim, Germany
|1997-2001 Cadillac Catera
|-
|T
|GM India plant: Talegaon, Maharashtra, India
|2017-2021 Chevrolet Spark Classic/Beat (Mexico)
|-
|V
|SAIC-GM Wuhan plant: Wuhan, Hubei province, China
|2018-2021 Chevrolet Cavalier (Mexico), 2022- Chevrolet Cavalier Turbo (Mexico)
|-
|W
|Suzuki plant: Iwata, Shizuoka prefecture, Japan
|1989-1990 Geo Tracker
|-
|1
|Opel plant: Rüsselsheim, Germany
|2011, 2018-2020 Buick Regal
|-
|3
|Isuzu plant: Kawasaki, Kanagawa prefecture, Japan
|1987-1998 Chevrolet/GMC W5, 1989-1996 Chevrolet/GMC W6, 1984-1996 Chevrolet/GMC W7
|-
|5
|Opel plant: Antwerp, Belgium
|2008-2009 Saturn Astra
|-
|7
|Isuzu plant: Fujisawa, Kanagawa prefecture, Japan
|1988 Chevrolet Spectrum, 1988 Pontiac Sunburst (Canada), 1989 Geo Spectrum, 1990-1993 Geo Storm,<br /> 1999-2008 Chevrolet/GMC W3500, 1988-2009 Chevrolet/GMC W4, 1999-2009 Chevrolet/GMC W5,<br /> 2000-2004 Chevrolet/GMC WT5500,<br /> 2016- Chevrolet Low Cab Forward 3500HD/4500HD/4500XD/5500HD/5500XD
|-
|8
|Isuzu plant: Fujisawa, Kanagawa prefecture, Japan
|1981-1982 Chevrolet LUV, 1985-1987 Chevrolet Spectrum, 1985-1987 Pontiac Sunburst (Canada),<br /> 1986-1987 Chevrolet/GMC W4
|}
==GM WMIs==
{| class=wikitable
!WMI
!Marque
!Country
|-
|1G1||rowspan=57|Chevrolet||United States
|-
|1G8||United States (MPV 1981-1986)
|-
|1GA||United States (bus [van with more than 3 rows of seats])
|-
|1GB||United States (incomplete vehicle)
|-
|1GC||United States (truck)
|-
|1GN||United States (MPV 1987-)
|-
|1HA||United States (Express incomplete vehicle made by Navistar)
|-
|1HT||United States ([[w:Chevrolet Silverado#Medium duty version_(4500HD,_5500HD,_6500HD,_and_International_CV)|Silverado Medium Duty]] incomplete vehicle made by Navistar)
|-
|1Y1||United States (made by NUMMI)
|-
|2C1||Canada (car made by CAMI)
|-
|2CN||Canada (SUV made by CAMI - 1998-2011)
|-
|2G1||Canada
|-
|2G5||Canada (truck - Chevrolet BrightDrop '25)
|-
|2G8||Canada (MPV 1981-1986)
|-
|2GA||Canada (bus [van with more than 3 rows of seats])
|-
|2GB||Canada (incomplete vehicle)
|-
|2GC||Canada (truck - includes Chevrolet BrightDrop '26)
|-
|2GN||Canada (MPV 1987-)
|-
|3G1||Mexico
|-
|3GC||Mexico (truck)
|-
|3GN||Mexico (MPV)
|-
|3N6||Mexico (Truck - City Express made by Nissan)
|-
|4G1||United States (made by Genasys L.C.)
|-
|4KB||United States (W-Series incomplete vehicle made by GM - through 2009)
|-
|4W1||United States (MPV - Chevrolet Suburban HD made for US govt. in Concord, NC)
|-
|54D||United States (incomplete vehicle made by Spartan Motors/The Shyft Group)
|-
|6G1||Australia (2011-2013 Caprice PPV)
|-
|6G3||Australia (2014-2017 Caprice PPV & SS performance sedan)
|-
|ADM||South Africa
|-
|J81||Japan (car made by Isuzu)
|-
|J8B||Japan (incomplete vehicle made by Isuzu - through 2009)
|-
|J8Z||Japan (LUV pickup made by Isuzu)
|-
|JAL||Japan (incomplete vehicle made by Isuzu - 2016+)
|-
|JG1||Japan (car made by Suzuki)
|-
|KL1||South Korea (car)
|-
|KL7||South Korea (MPV - 2012+)
|-
|KL8||South Korea (Spark)
|-
|LSF||China (S-10 Max made by SAIC-Maxus - Mexico only)
|-
|LSG||China (SAIC-GM)
|-
|LSH||China (Express Max made by SAIC-Maxus - Mexico only)
|-
|LZW||China (SAIC-GM-Wuling)
|-
|MA6||India
|-
|MJB||Indonesia (GM Indonesia)
|-
|MK3||Indonesia (SGMW Motor Indonesia)
|-
|MMM||Thailand
|-
|XUF||Russia (GM Russia - St. Petersburg plant)
|-
|XUU||Russia (Chevrolet Korea models made by Avtotor in Kaliningrad)
|-
|XWB||Uzbekistan (GM Uzbekistan, UzAuto Motors)
|-
|XWF||Russia (Chevrolet Tahoe & Trailblazer [GMT360] made by Avtotor in Kaliningrad)
|-
|X9L||Russia (GM-AvtoVAZ)
|-
|8AG||Argentina
|-
|8GG||Chile
|-
|8LD||Ecuador
|-
|8Z1||Venezuela
|-
|9BG||Brazil
|-
|93C||Brazil
|-
|9GC||Colombia
|-
|J81||rowspan=6|Geo||Japan (car made by Isuzu)
|-
|JG1||Japan (car made by Suzuki)
|-
|JGC||Japan (SUV made by Suzuki)
|-
|1Y1||United States (car made by NUMMI)
|-
|2C1||Canada (car made by CAMI)
|-
|2CN||Canada (SUV made by CAMI - 1990-1997)
|-
|KLA||rowspan=3|GM Daewoo/<br />GM Korea||South Korea (Bupyeong & Kunsan plants)
|-
|KLY||South Korea (Changwon plant)
|-
|5GD||United States (G2X)
|-
|1G2||rowspan=12|Pontiac||United States
|-
|1G5||United States (incomplete vehicle - for '89-'90 Turbo Grand Prix by ASC/McLaren & '03-'05 Montana Mobility, '06 Montana SV6 Mobility)
|-
|1GM||United States (MPV)
|-
|2CK||Canada (2006-2009 Torrent made by CAMI)
|-
|2G2||Canada
|-
|2G7||Canada (US market 1983 Pontiac Parisienne)
|-
|3G2||Mexico
|-
|3G7||Mexico (MPV: 2001-2005 Aztek)
|-
|4G2||United States (made by Genasys L.C.)
|-
|5Y2||United States (made by NUMMI)
|-
|6G2||Australia
|-
|KL2||South Korea (made by Daewoo/GM Daewoo)
|-
|1G7||rowspan=6|Pontiac<br />(Canada only)||United States
|-
|2C7||Canada (car made by CAMI)
|-
|2CG||Canada (SUV made by CAMI)
|-
|2G7||Canada
|-
|J87||Japan (car made by Isuzu)
|-
|JG7||Japan (car made by Suzuki)
|-
|KL7||Passport<br />(Canada only)||South Korea (car made by Daewoo)
|-
|J87||rowspan=3|Asüna<br />(Canada only)||Japan (car made by Isuzu)
|-
|KL7||South Korea (car made by Daewoo)
|-
|2CG||Canada (SUV made by CAMI)
|-
|1G3||rowspan=3|Oldsmobile||United States
|-
|1GH||United States (MPV/SUV)
|-
|2G3||Canada
|-
|1G4||rowspan=9|Buick||United States
|-
|2G4||Canada
|-
|3G4||Mexico
|-
|3G5||Mexico (MPV)
|-
|4GL||United States (incomplete vehicle)
|-
|5GA||United States (MPV)
|-
|KL4||South Korea (MPV)
|-
|LRB||China (SAIC-GM)
|-
|W04||Germany & Poland
|-
|KLA||Alpheon||South Korea (2011-2015)
|-
|1G6||rowspan=10|Cadillac||United States
|-
|1GE||United States (incomplete vehicle)
|-
|1GY||United States (SUV)
|-
|2G6||Canada
|-
|2GE||Canada (incomplete vehicle)
|-
|3GY||Mexico (SUV)
|-
|LRE||China (SAIC-GM)
|-
|W06||Germany
|-
|XWF||Russia (made by Avtotor in Kaliningrad)
|-
|YSC||Sweden
|-
|1G8||rowspan=4|Saturn||United States
|-
|3GS||Mexico (SUV)
|-
|5GZ||United States (MPV/SUV)
|-
|W08||Belgium
|-
|1G0||rowspan=22|GMC||United States (bus 1981-1986)
|-
|1G5||United States (MPV 1981-1986)
|-
|1GD||United States (incomplete vehicle)
|-
|1GJ||United States (bus 1987-)
|-
|1GK||United States (MPV 1987-)
|-
|1GT||United States (truck)
|-
|2CK||Canada (1990-1991 Tracker made by CAMI - Canada only)
|-
|2CT||Canada (2010-2011 Terrain made by CAMI)
|-
|2G0||Canada (bus [van with more than 3 rows of seats] 1981-1986)
|-
|2G5||Canada (MPV 1981-1986)
|-
|2GD||Canada (incomplete vehicle)
|-
|2GH||Canada (transit bus)
|-
|2GJ||Canada (bus [van with more than 3 rows of seats] 1987-)
|-
|2GK||Canada (MPV 1987-)
|-
|2GT||Canada (truck)
|-
|3GK||Mexico (SUV)
|-
|3GT||Mexico (truck)
|-
|4KD||United States (W-Series incomplete vehicle made by GM - through 2009)
|-
|7GZ||United States (incomplete vehicle made by Navistar)
|-
|J8D||Japan (incomplete vehicle made by Isuzu - through 2009)
|-
|JGT||Japan (SUV made by Suzuki - Canada only)
|-
|KL6||South Korea (Middle East market Terrain '08-'10)
|-
|4GD||WhiteGMC||United States (1988-1989 Brigadier made by GM)
|-
|137||rowspan=6|Hummer||United States (H1 made by AM General)
|-
|5GN||United States (H3T)
|-
|5GR||United States (H2 made by AM General)
|-
|5GT||United States (H3)
|-
|ADM||South Africa (H3)
|-
|XWF||Russia (H2 & H3 made by Avtotor in Kaliningrad)
|-
|4G5||General Motors||United States (EV1)
|-
|2G5||rowspan=2|BrightDrop||Canada (Truck 2023-2024)
|-
|5G5||United States (Truck made by Kuka AG - 2022 only)
|-
|5G2||rowspan=2|Cruise||United States (car) (Cruise AV)
|-
|5G3||United States (MPV) (Cruise Origin AV)
|-
|YS3||rowspan=4|Saab||Sweden
|-
|JF4||Japan (9-2X made by Subaru)
|-
|3G0||Mexico (9-4X)
|-
|5S3||United States (9-7X)
|-
|W0L||rowspan=19|Opel/Vauxhall||Germany & the rest of Europe (2017 and earlier)
|-
|W0V||Germany & the rest of Europe (2018 and later) & Opel Ampera-e Mid-2017 - 2019
|-
|W0L||when plant code is H: Thailand (Zafira A)
|-
|W0L||when plant code is 0: South Korea (Antara) or B: South Korea (Antara, Mokka A, Mokka X [A])
|-
|W0L||when plant code is C: South Korea (Opel Karl/Vauxhall Viva)
|-
|W0V||when plant code is B: South Korea (Mokka X [A]) or C: South Korea (Opel Karl/Vauxhall Viva)
|-
|SCC||UK (Opel Lotus Omega made by Lotus)
|-
|SED||UK (made by IBC Vehicles)
|-
|TW8||Portugal
|-
|VF1||France (Arena made by Renault)
|-
|VN1||France (Movano A made by Renault at SOVAB plant in Batilly, France)
|-
|VSX||Spain
|-
|XUF||Russia (Opel made by GM Russia - St. Petersburg plant)
|-
|XWF||Russia (Opel made by Avtotor in Kaliningrad)
|-
|1G0||United States (Opel GT, Opel/Vauxhall Ampera, Opel Ampera-e Early - Mid-2017)
|-
|4GD||United States (Sintra)
|-
|ADM||South Africa
|-
|JAA||Japan (Opel Campo made by Isuzu)
|-
|JAC||Japan (Monterey made by Isuzu)
|-
|SKA||rowspan=4|Vauxhall Motors||UK
|-
|SCC||UK (Vauxhall Lotus Carlton made by Lotus)
|-
|6G1||Australia (Vauxhall Monaro & VXR8 made by Holden)
|-
|JAA||Japan (Vauxhall Brava made by Isuzu)
|-
|SKF||rowspan=2|Bedford Vehicles||UK
|-
|JAA||Japan (Bedford Brava made by Isuzu)
|-
|6G1||rowspan=18|Holden||Australia (2003-2017)
|-
|6H8||Australia (1989-2002)
|-
|JAA||Japan (Rodeo pickup [TF] made by Isuzu)
|-
|JAC||Japan (Jackaroo/Monterey made by Isuzu)
|-
|JSA||Japan (YG Cruze made by Suzuki)
|-
|KL3||South Korea
|-
|MMM||Thailand ('09-'11 Colorado pickup [RC] made by GM Thailand)
|-
|MMU||Thailand ('13-'20 Colorado pickup [RG], '13-'16 Colorado 7, '17-'20 Trailblazer made by GM Thailand)
|-
|MPA||Thailand ('04-'08 Rodeo pickup [RA] made by Isuzu Thailand)
|-
|SED||UK (1st gen. Frontera made by IBC Vehicles)
|-
|W0L||Germany & the rest of Europe (2017 and earlier)
|-
|W0L||when plant code is H: Thailand (Zafira A)
|-
|W0V||Germany & the rest of Europe (2018-2020)
|-
|1GH||United States (Acadia)
|-
|3G0||Mexico (Equinox)
|-
|3GM||Mexico (Suburban)
|-
|4S2||United States (2nd gen. Frontera made by [[w:Subaru Isuzu Automotive|SIA]])
|-
|5G8||United States (Volt)
|-
|1GG||rowspan=4|Isuzu||United States (Truck - Hombre & i-Series made by GM)
|-
|4GT||United States (H-Series & T-Series incomplete vehicle made by GM - through 2009)
|-
|4KL||United States (N-Series incomplete vehicle made by GM - through 2009)
|-
|4NU||United States (MPV/SUV - Ascender made by GM)
|-
|W0L||Subaru||Thailand [plant code H] (Traviq made by GM Thailand for export to Japan)
|-
|4G3||Toyota||United States (Cavalier made by GM for export to Japan)
|-
|3GP||Honda||Mexico (MPV/SUV: 2024-2026 Prologue made by GM)
|-
|4W5||Acura||United States (MPV/SUV: 2024 ZDX EV made by GM)
|}
{{BookCat}}
5r8grb7m1vdb0ymnzzfdftg4xftcxbg
4655962
4655961
2026-07-31T19:52:47Z
JustTheFacts33
3434282
/* Engine codes for light trucks */
4655962
wikitext
text/x-wiki
{{Vehicle Identification Numbers (VIN codes)/Warning}}{{clear}}
It is the tenth digit that gives you the model year for GM. I've been working at a Chevy dealer for years running codes/vins. For example (my examples only apply to 2001-2015 gm vehicles)
Remember 10th digit from the beginning, (left to right).
2001... 1,
2002...2,
2003...3,
etc.,
2009...9.
After 2009, the tenth digit was given a letter
2010... A,
2011...B,
2012...C,
2013...D,
2014...E,
2015...F,
Etc...
We have another 20 years worth of letters.
Thanks for reading.
You can always check your model year by looking in your drivers side door jamb and it will give you model year. If it was assembled in July or later, the model year is probably a year later than the calendar year of the manufacturing date listed.
==American GM==
===American VIN format 1981-1984 Passenger Car===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>A</td><td></td><td></td><td>[[#American restraint types 1981-1984|Restraint type]]</td>
</tr><tr>
<td>5</td>
<td>M</td><td></td><td></td><td>[[#Car Line & Series Code 1981-1984|Car Line & Series Code]]</td>
</tr><tr>
<td>6</td>
<td>4</td><td></td><td></td><td rowspan=2>[[#Body style codes 1981-1986|Body style]]</td>
</tr><tr>
<td>7</td>
<td>7</td><td></td><td></td><td> </td>
</tr><tr>
<td>8</td>
<td>8</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>E</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>9</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====American restraint types 1981-1984====
The restraint type is specified as character 4 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|A||Manual Seatbelts only - No Passive Restraint
|}
====Car Line & Series Code 1981-1984====
The Car Line & Series Code is specified as character 5 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!List of GM platforms
!Car Line & <br> Series Code
!:Category:General Motors vehicles|Model
|-
|rowspan=19|GM A platform - rear-wheel drive
|T||Chevrolet Malibu 1981
|-
|W||Chevrolet Malibu Classic 1981
|-
|Z||Chevrolet Monte Carlo 1981
|-
|D||Pontiac LeMans 1981
|-
|F||Pontiac Grand LeMans 1981
|-
|J||Pontiac Grand Prix 1981
|-
|K||Pontiac Grand Prix LJ 1981
|-
|P||Pontiac Grand Prix Brougham 1981
|-
|G||Oldsmobile Cutlass sedan, Cutlass Cruiser wagon 1981
|-
|H||Oldsmobile Cutlass Cruiser ''Brougham'' wagon 1981
|-
|K||Oldsmobile Cutlass Calais coupe 1981
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1981
|-
|R||Oldsmobile Cutlass Supreme coupe, Cutlass LS sedan 1981
|-
|E||Buick Century wagon 1981
|-
|H||Buick Century sedan, Estate wagon 1981
|-
|J||Buick Regal 1981
|-
|K||Buick Regal ''Sport'' 1981
|-
|L||Buick Century ''Limited'' 1981
|-
|M||Buick Regal ''Limited'' 1981
|-
|rowspan=10|GM A platform - front-wheel drive
|W||Chevrolet Celebrity 1982-1984
|-
|F||Pontiac 6000 1982-1984
|-
|G||Pontiac 6000 ''LE'' 1982-1984
|-
|H||Pontiac 6000 ''STE'' 1983-1984
|-
|G||Oldsmobile Cutlass Ciera 1982
|-
|J||Oldsmobile Cutlass Ciera ''LS'' 1982-1984, Cutlass Cruiser ''LS'' 1984
|-
|M||Oldsmobile Cutlass Ciera ''Brougham'' 1982-1984
|-
|G||Buick Century ''T-Type'' 1983-1984
|-
|H||Buick Century ''Custom'' 1982-1984
|-
|L||Buick Century ''Limited'' 1982-1984
|-
|rowspan=19|GM B platform
|D||Chevrolet Bel Air 1981 (Canada only)
|-
|L||Chevrolet Impala 1981-1984
|-
|N||Chevrolet Caprice Classic 1981-1984
|-
|F||Pontiac Laurentian 1981 (Canada only)
|-
|L||Pontiac Catalina 1981, Parisienne 1984
|-
|L||Pontiac Parisienne 1982-1983 (Canada only)
|-
|N||Pontiac Bonneville 1981
|-
|N||Pontiac Parisienne 1981, Parisienne Brougham 1982-1983 (Canada only)
|-
|R||Pontiac Bonneville Brougham 1981
|-
|T||Pontiac Parisienne Brougham 1984
|-
|L||Oldsmobile Delta 88 1981-1983
|-
|N||Oldsmobile Delta 88 Royale 1981-1984
|-
|P||Oldsmobile Custom Cruiser 1981-1984
|-
|V||Oldsmobile Delta 88 Royale Brougham LS 1984
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1981-1984
|-
|N||Buick Le Sabre 1981, Le Sabre ''Custom'' 1982-1984
|-
|P||Buick Le Sabre ''Limited'' 1981-1984
|-
|R||Buick Le Sabre Estate Wagon 1981-1983
|-
|V||Buick Electra Estate Wagon 1981-1984
|-
|rowspan=13|GM C platform - rear-wheel drive
|G||Oldsmobile 98 Regency 1984
|-
|H||Oldsmobile 98 Regency Brougham 1984
|-
|V||Oldsmobile 98 Luxury 1981
|-
|W||Oldsmobile 98 Regency Brougham 1982-1983
|-
|X||Oldsmobile 98 Regency 1981-1983
|-
|R||Buick Electra Limited 1984
|-
|U||Buick Electra Park Avenue 1984
|-
|W||Buick Electra Park Avenue 1981-1983
|-
|X||Buick Electra Limited 1981-1983
|-
|B||Cadillac Fleetwood Brougham 1981-1983
|-
|D||Cadillac DeVille 1981-1983
|-
|M||Cadillac DeVille 1984
|-
|W||Cadillac Fleetwood Brougham 1984
|-
|rowspan=1|GM D platform - rear-wheel drive
|F||Cadillac Fleetwood Limousine 1981-1984
|-
|rowspan=4|GM E platform
|Z||Oldsmobile Toronado Brougham 1981-1984
|-
|Y||Buick Riviera T-Type 1981-1984
|-
|Z||Buick Riviera 1981-1984
|-
|L||Cadillac Eldorado 1981-1984
|-
|rowspan=7|GM F platform
|P||Chevrolet Camaro Sport Coupe 1981-1984
|-
|S||Chevrolet Camaro Berlinetta 1981-1984
|-
|S||Pontiac Firebird 1981-1984
|-
|T||Pontiac Firebird ''Esprit'' 1981
|-
|V||Pontiac Firebird ''Formula'' 1981
|-
|W||Pontiac Firebird ''Trans Am'' 1981-1984
|-
|X||Pontiac Firebird ''Trans Am'' Turbo Special Edition 1981, Firebird ''S/E'' 1982-1984
|-
|rowspan=15|GM G platform - rear-wheel drive
|W||Chevrolet Malibu Classic 1982, Malibu 1983
|-
|Z||Chevrolet Monte Carlo 1982-1984
|-
|J||Pontiac Grand Prix 1982-1984
|-
|K||Pontiac Grand Prix LJ 1982-1983, Grand Prix LE 1984
|-
|N||Pontiac Bonneville G 1982-1984
|-
|P||Pontiac Grand Prix Brougham 1982-1984
|-
|R||Pontiac Bonneville G Brougham 1982-1984
|-
|S||Pontiac Bonneville G ''LE'' 1984
|-
|H||Oldsmobile Cutlass Cruiser wagon 1982-1983
|-
|K||Oldsmobile Cutlass Calais coupe 1982-1984
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1982-1984
|-
|R||Oldsmobile Cutlass Supreme coupe & sedan 1982-1984
|-
|J||Buick Regal 1982-1984
|-
|K||Buick Regal ''Sport'' 1982, Regal ''T-Type'' 1983-1984
|-
|M||Buick Regal ''Limited'' 1982-1984
|-
|rowspan=13|GM J platform
|C||Chevrolet Cavalier 1983-1984
|-
|D||Chevrolet Cavalier 2-d/4-d/wagon 1982, Cavalier CS 1983-1984
|-
|E||Chevrolet Cavalier 3-door hatchback 1982, Cavalier CS 3-door hatchback 1983, Cavalier Type 10 2-d/3-d/Convertible 1984
|-
|B||Pontiac J2000 1982, 2000 1983, 2000 Sunbird 1984
|-
|C||Pontiac J2000 LE 1982, 2000 LE 1983, 2000 Sunbird LE Convertible 1983, 2000 Sunbird LE 1984
|-
|D||Pontiac J2000 SE 1982, 2000 SE 1983, 2000 Sunbird SE 1984
|-
|E||Pontiac J2000 S 1982
|-
|C||Oldsmobile Firenza Base model 1982-1984, Firenza S 1982-1984
|-
|D||Oldsmobile Firenza LX 1982-1984, Firenza SX 1982-1984
|-
|E||Buick Skyhawk T-Type 1983-1984
|-
|S||Buick Skyhawk Custom 1982-1984
|-
|T||Buick Skyhawk Limited 1982-1984
|-
|G||Cadillac Cimarron 1982-1984
|-
|rowspan=1|GM K platform
|S||Cadillac Seville 1981-1984
|-
|rowspan=3|GM P platform
||E||Pontiac Fiero ''Coupe'' 1984
|-
||F||Pontiac Fiero ''SE'' 1984
|-
||M||Pontiac Fiero ''Sport coupe'' 1984
|-
|rowspan=6|GM T platform - rear-wheel drive
|B||Chevrolet Chevette 1981-1983, Chevette CS 1984
|-
|J||Chevrolet Chevette Scooter 1981-1983, Chevette 1984
|-
|B||Pontiac Acadian 1981-1984 (Canada only)
|-
|J||Pontiac Acadian S 1981-1982, Pontiac Acadian Scooter 1983-1984 (Canada only)
|-
|L||Pontiac T1000 1982, 1000 1983-1984
|-
|M||Pontiac T1000 1981
|-
|rowspan=10|GM X platform
|H||Chevrolet Citation 2-door coupe 1982-1983, Citation II 2-door coupe 1984
|-
|X||Chevrolet Citation hatchback 1981-1983, Citation II hatchback 1984
|-
|T||Pontiac Phoenix SJ 1982-1983, Phoenix SE 1984
|-
|Y||Pontiac Phoenix 1981-1984
|-
|Z||Pontiac Phoenix LJ 1981-1983, Phoenix LE 1984
|-
|B||Oldsmobile Omega 1981-1984
|-
|E||Oldsmobile Omega Brougham 1981-1984
|-
|B||Buick Skylark 1981-1982, Skylark Custom 1983-1984
|-
|C||Buick Skylark Limited 1981-1984
|-
|D||Buick Skylark Sport 1981-1982, Skylark T-Type 1983-1984
|-
|rowspan=1|GM Y platform
|Y||Chevrolet Corvette 1981-1982, 1984
|}
===American VIN format 1985-1986 Passenger Car===
GM has traditionally encoded the platform as the 4th character of the VIN. Other content includes an engine code and manufacturing plant. GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>D</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Platform]]</td>
</tr><tr>
<td>5</td>
<td>W</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Series Code]]</td>
</tr><tr>
<td>6</td>
<td>6</td><td></td><td></td><td rowspan=2>[[#Body style codes 1981-1986|Body style]]</td>
</tr><tr>
<td>7</td>
<td>9</td><td></td><td></td><td> </td>
</tr><tr>
<td>8</td>
<td>Y</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>G</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>9</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====Body style codes 1981-1986====
The Body type is specified as characters 6 and 7 of the American GM VIN for passenger cars from 1981-1986.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|11,27,37,47,57,97||Two-Door Coupe/Sedan
|-
|07,08,77,87||Two-Door Hatchback
|-
|67||Two-Door Convertible
|-
|19,69||Four-Door Sedan
|-
|68||Four-Door Hatchback
|-
|23||Four-Door Limousine, 8-passenger ("Limousine")
|-
|33||Four-Door Limousine w/Center Partition, 7-passenger ("Formal Limousine")
|-
|35||Four-Door Station Wagon
|}
===American VIN format 1987- Passenger Car===
GM has traditionally encoded the platform as the 4th character of the VIN. Other content includes an engine code and manufacturing plant. GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>D</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Platform]]</td>
</tr><tr>
<td>5</td>
<td>M</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Series Code]]</td>
</tr><tr>
<td>6</td>
<td>5</td><td></td><td></td><td>[[#Body style codes 1987- Passenger Car|Body style]]</td>
</tr><tr>
<td>7</td>
<td>7</td><td></td><td></td><td>[[#American restraint types 1987-|Restraint type]]</td>
</tr><tr>
<td>8</td>
<td>N</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>3</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>0</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
===American VIN format 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>K</td><td></td><td></td></tr><tr>
<td>4</td>
<td>E</td><td></td><td></td><td>[[#GVWR/Brake System 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|GVWR/Brake System]]</td>
</tr><tr>
<td>5</td>
<td>K</td><td></td><td></td><td>[[#Line & Chassis Type 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 1981-1999]]</td>
</tr><tr>
<td>5</td>
<td>K</td><td></td><td></td><td>[[#Line & Chassis Type 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 2000-2009]]</td>
</tr><tr>
<td>6</td>
<td>1</td><td></td><td></td><td>[[#Series 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle|Series]]</td>
</tr><tr>
<td>7</td>
<td>8</td><td></td><td></td><td>[[#Body style codes 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|Body type]]</td>
</tr><tr>
<td>8</td>
<td>K</td><td></td><td></td><td>[[#Engine codes for light trucks|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>N</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>J</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====GVWR/Brake System 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The GVWR/Brake System is specified as character 4 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!GVWR Range in lbs. & Weight Class
!Brake System
|-
|A||Class A: 0-3,000||Hydraulic
|-
|B||Class B: 3,001-4,000||Hydraulic
|-
|C||Class C: 4,001-5,000||Hydraulic
|-
|D||Class D: 5,001-6,000||Hydraulic
|-
|E||Class E: 6,001-7,000||Hydraulic
|-
|F||Class F: 7,001-8,000||Hydraulic
|-
|G||Class G: 8,001-9,000||Hydraulic
|-
|H||Class H: 9,001-10,000||Hydraulic
|-
|J||Class 3: 10,001-14,000||Hydraulic
|-
|K||Class 4: 14,001-16,000||Hydraulic
|-
|L||Class 5: 16,001-19,500||Hydraulic
|}
====Line & Chassis Type 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|B||Special Body Buick, Chevrolet
|-
|C||Chevy full-size pickups & chassis cabs 2wd (C-series) '81-'86, '88-'99,<br /> GMC full-size pickups & chassis cabs 2wd (C-series) '81-'86, Sierra 2wd (C-series) '88-'99
|-
|C||Chevy C10 Blazer 2wd ('81-'82), Tahoe 4-door 2wd ('95-'99), Suburban 2wd ('81-'86, '92-'99),<br /> GMC C1500 Jimmy 2wd ('81-'82), Yukon 4-door 2wd ('95-'99), Suburban 2wd ('81-'86, '92-'99)
|-
|D||Military Truck 4wd
|-
|E||'91-'97 Geo Tracker 2wd, '98-'99 Chevrolet Tracker 2wd
|-
|E||'97-'98 Chevy S-10 EV
|-
|G||Chevy/GMC full-size vans (Chevy Van, Sportvan, Express, GMC Vandura, Rally Van, Savana)
|-
|H||'93-'96 Chevy G30HD/GMC G3500HD cutaway van
|-
|H||Cadillac chassis cutaway/special body (Based on Rwd Fleetwood '93-'96, Fwd DeVille '97-'99)
|-
|J||'89-'97 Geo Tracker 4wd, '98-'99 Chevrolet Tracker 4wd
|-
|K||Chevy full-size pickups & chassis cabs 4wd (K-series) '81-'86, '88-'99,<br /> GMC full-size pickups & chassis cabs 4wd (K-series) '81-'86, Sierra 4wd (K-series) '88-'99
|-
|K||Chevy K10/K5 Blazer 4wd ('81-'86, '92-'94), Tahoe 4wd ('95-'99), Suburban 4wd ('81-'86, '92-'99),<br /> GMC K1500 Jimmy 4wd ('81-'86), Yukon 4wd ('92-'99), Suburban 4wd ('81-'86, '92-'99), '99 Cadillac Escalade 4wd
|-
|L||Chevy Luv 2wd '81-'82
|-
|L||Chevy Astro/GMC Safari 4wd '90-'99
|-
|M||Chevy Astro/GMC Safari 2wd '85-'99
|-
|P||Forward Control (includes Chevrolet Step-Van/GMC Value-Van, Chevy/GMC P-Series)
|-
|R||Chevy Luv 4wd '81-'82
|-
|R||Chevy full-size pickups & chassis cabs 2wd (R-series), Suburban 2wd '87-'91,<br /> GMC full-size pickups & chassis cabs 2wd (R-series), Suburban 2wd '87-'91
|-
|S||Chevy S-10 2wd ('82-'99), S-10 Blazer 2wd ('83-'94), Blazer 2wd ('95-'99), GMC S-15 2wd ('82-'90), Sonoma 2wd ('91-'99),<br> S-15 Jimmy 2wd ('83-'91), Jimmy 2wd ('92-'99), Isuzu Hombre 2wd ('96-'99)
|-
|T||Chevy S-10 4wd ('83-'99), S-10 Blazer 4wd ('83-'94), Blazer 4wd ('95-'99), GMC S-15 4wd ('83-'90), Sonoma 4wd ('91-'99), Syclone 4wd ('91),<br> S-15 Jimmy 4wd ('83-'91), Jimmy 4wd ('92-'99), Typhoon 4wd ('92-93), Envoy 4wd ('98-'99), Oldsmobile Bravada 4wd ('91-'94, '96-'99),<br> Isuzu Hombre 4wd ('98-'99)
|-
|U||Regular length All-Purpose Vehicle ('90-'99 U-body fwd minivans)
|-
|V||Chevy full-size pickups & chassis cabs 4wd (V-series), V10/V1500 Blazer 4wd, Suburban 4wd '87-'91,<br /> GMC full-size pickups & chassis cabs 4wd (V-series), V1500 Jimmy 4wd, Suburban 4wd '87-'91
|-
|W||'81-'87 Chevy El Camino, GMC Caballero
|-
|X||Extended length All-Purpose Vehicle ('97-'99 U-body fwd extended length minivans)
|-
|Z||Cadillac chassis cutaway/special body (Based on Rwd Fleetwood '81-'84, Fwd Fleetwood '85-'92)
|}
====Line & Chassis Type 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Pontiac Aztek 2wd '01-'05, Buick Rendezvous 2wd '02-'07
|-
|A||Chevrolet HHR '06-'09, HHR Panel '07-'09
|-
|B||Pontiac Aztek Awd '01-'05, Buick Rendezvous Awd '02-'06
|-
|C||Chevy full-size pickups & chassis cabs 2wd (C-series) '00, full-size chassis cabs 2wd (C3500HD) '01-'02, Silverado 2wd '00-'09, Silverado Classic 2wd '07,<br /> GMC Sierra 2wd (C-series) '00-'09, Sierra Classic 2wd '00, '07
|-
|C||Chevy Tahoe 2wd ('00-'09), Suburban 2wd ('00-'09), Avalanche 2wd ('02-'09),<br /> GMC Yukon 2wd ('00-'09), Yukon XL 2wd ('00-'09), Cadillac Escalade 2wd ('02-'09), Escalade ESV 2wd ('08-'09)
|-
|E||Chevrolet Tracker 2wd '00-'04
|-
|E||Cadillac SRX 2wd & Awd '04-'09
|-
|G||Chevy/GMC full-size vans 2wd (Chevy Express, GMC Savana) '00-09
|-
|H||Chevy/GMC full-size vans 4wd (Chevy Express, GMC Savana) '03-09
|-
|H||Cadillac Commercial Chassis for Hearse (Based on Fwd DeVille '02-'05, DTS '06-'09)
|-
|H||Cadillac Professional Chassis for Limousine (Based on Fwd DeVille '00-'05, DTS '06-'07)
|-
|J||Chevrolet Tracker 4wd '00-'04
|-
|K||Chevy full-size pickups & chassis cabs 4wd (K-series) '00, Silverado 4wd '00-'09, Silverado Classic 4wd '07,<br /> GMC Sierra 4wd (K-series) '00-'09, Sierra Classic 4wd '00, '07
|-
|K||Chevy Tahoe 4wd ('00-'09), Suburban 4wd ('00-'09), Avalanche 4wd ('02-'09), GMC Yukon 4wd ('00-'09), Yukon XL 4wd ('00-'09),<br> Cadillac Escalade 4wd ('00, '02-'09), Escalade ESV 4wd ('03-'09), Escalade EXT 4wd ('02-'09)
|-
|K||Cadillac Professional Chassis for Limousine (Based on Fwd DTS '08-'09)
|-
|L||Chevy Astro/GMC Safari 4wd '00-'05
|-
|L||Chevy Equinox 2wd & Awd '05-'09, Pontiac Torrent 2wd & Awd '06-'09, Saturn Vue 2wd & Awd '08-'09
|-
|M||Chevy Astro/GMC Safari 2wd '00-'05
|-
|N||Hummer H2 '03-'09, H2 SUT '05-'09
|-
|N||Hummer H3 '06-'09, H3T '09
|-
|R||GMC Acadia 2wd, Saturn Outlook 2wd '07-'09, Buick Enclave 2wd '08-'09, Chevy Traverse 2wd '09
|-
|S||Chevy S-10 2wd ('00-'03), Blazer 2wd ('00-'05), GMC Sonoma 2wd ('00-'03), Jimmy 2wd ('00-'01), Isuzu Hombre 2wd ('00)
|-
|S||Chevy Trailblazer 2wd ('02-'09), SSR ('03-'06), GMC Envoy 2wd ('02-'09), Envoy XUV 2wd ('04-'05), Oldsmobile Bravada 2wd ('02-'04),<br> Buick Rainier 2wd ('04-'07), Isuzu Ascender 2wd ('03-'08)
|-
|S||Chevy Colorado 2wd ('04-'09), GMC Canyon 2wd ('04-'09), Isuzu i-series 2wd ('06-'08)
|-
|T||Chevy S-10 4wd ('00-'04), Blazer 4wd ('00-'05), GMC Sonoma 4wd ('00-'04), Jimmy 4wd ('00-'01, Canada only: '02-'05), Envoy 4wd ('00),<br> Oldsmobile Bravada 4wd ('00-'01), Isuzu Hombre 4wd ('00)
|-
|T||Chevy Trailblazer 4wd ('02-'09), GMC Envoy 4wd ('02-'09), Envoy XUV 2wd ('04-'05), Oldsmobile Bravada 4wd ('02-'04), Buick Rainier 4wd ('04-'07),<br> Isuzu Ascender 4wd ('03-'08), Saab 9-7X 4wd ('05-'09)
|-
|T||Chevy Colorado 4wd ('04-'09), GMC Canyon 4wd ('04-'09), Isuzu i-series 4wd ('06-'08)
|-
|U||Regular length All-Purpose Vehicle [Minivan] ('00-'04 Chevy Venture, Pontiac Montana)
|-
|U||Regular length All-Purpose Vehicle [Minivan] (Chevy Uplander [US: '06-'08, Canada only: '05-'09], Pontiac Montana SV6 [Canada only: '05-'09])
|-
|V||Extended length AWD All-Purpose Vehicle [Minivan] ('02-'04 Chevy Venture, Pontiac Montana, Oldsmobile Silhouette Extended length AWD)
|-
|V||Extended length FWD All-Purpose Vehicle [Minivan] ('05 Chevy Venture, Pontiac Montana Extended length FWD)
|-
|V||Extended length FWD All-Purpose Vehicle [Minivan] (Chevy Uplander ['05-'08, Canada only: '09], Pontiac Montana SV6 ['05-'06, Canada only: '07-'09],<br> Buick Terraza ['05-'07], Saturn Relay ['05-'07])
|-
|V||GMC Acadia Awd, Saturn Outlook Awd '07-'09, Buick Enclave Awd '08-'09, Chevy Traverse Awd '09
|-
|X||Extended length FWD All-Purpose Vehicle [Minivan] ('00-'04 Chevy Venture, Pontiac Montana, Oldsmobile Silhouette Extended length FWD)
|-
|X||Extended length AWD All-Purpose Vehicle [Minivan] ('05-'06 Chevy Uplander AWD, Pontiac Montana SV6 AWD, Buick Terraza AWD, Saturn Relay AWD)
|-
|Z||Saturn Vue 2wd & Awd '02-'07
|}
====Series 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1||1/2 Ton (includes '96-'99 Isuzu Hombre)
|-
|2||3/4 Ton
|-
|3||1 Ton
|-
|8||1/2 Ton ('81-'87 El Camino, Caballero)
|-
|9||Cadillac, Buick, Chevrolet Commercial Body/Chassis
|-
|0||All-Purpose Vehicle ('90-'99 U-body fwd minivans)
|}
====Series 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1 <br> (following A)||Chevrolet HHR LS ('06-'07)
|-
|2 <br> (following A)||Chevrolet HHR LT ('06-'07)
|-
|3 <br> (following A)||Chevrolet HHR LT ('07)
|-
|1 <br> (following A)||Chevrolet HHR LS w/auto. trans. ('08-'09)
|-
|2 <br> (following A)||Chevrolet HHR 1LT w/auto. trans. ('08-'09)
|-
|3 <br> (following A)||Chevrolet HHR LS w/man. trans. ('08-'09)
|-
|4 <br> (following A)||Chevrolet HHR 1LT w/man. trans. ('08-'09)
|-
|5 <br> (following A)||Chevrolet HHR 2LT (all transmissions) ('08-'09)
|-
|6 <br> (following A)||Chevrolet HHR SS w/auto. trans. ('08-'09) (Pos. 1-3 of VIN is 3GN)
|-
|7 <br> (following A)||Chevrolet HHR SS w/man. trans. ('08-'09) (Pos. 1-3 of VIN is 3GN)
|-
|6 <br> (following A)||Chevrolet HHR Panel SS w/auto. trans. ('09) (Pos. 1-3 of VIN is 3GC)
|-
|7 <br> (following A)||Chevrolet HHR Panel SS w/man. trans. ('09) (Pos. 1-3 of VIN is 3GC)
|-
|8 <br> (following A)||Chevrolet HHR Panel LS w/auto. trans. ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|9 <br> (following A)||Chevrolet HHR Panel LS w/man. trans. ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|0 <br> (following A)||Chevrolet HHR Panel LT (all transmissions) ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|1 <br> (following A)||Chevrolet HHR Panel LS ('08) (Pos. 1-3 of VIN is 3GC)
|-
|2 <br> (following A)||Chevrolet HHR Panel LT ('08) (Pos. 1-3 of VIN is 3GC)
|-
|3 <br> (following A)||Chevrolet HHR Panel LT ('08) (Pos. 1-3 of VIN is 3GC)
|-
|0 <br> (following V)||Chevrolet Venture Plus ('05) (Pos. 8 of VIN is E)
|-
|1 <br> (following V)||Chevrolet Venture Cargo ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following V)||Chevrolet Venture LS ('05) (Pos. 8 of VIN is E)
|-
|3 <br> (following V)||Chevrolet Venture LT ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following U)||Chevrolet Uplander LS SWB 2wd ('06-'08)
|-
|0 <br> (following V)||Chevrolet Uplander Base model 2wd ('05)
|-
|1 <br> (following V)||Chevrolet Uplander Cargo Van 2wd, Mobility (incomplete vehicle) 2wd ('05-'08)
|-
|2 <br> (following V)||Chevrolet Uplander LS 2wd ('05-'08)
|-
|3 <br> (following V)||Chevrolet Uplander LT 2wd ('05-'08)
|-
|3 <br> (following X)||Chevrolet Uplander LT Awd ('05-'06)
|-
|1 <br> (following M)||Chevrolet Astro 2wd ('00-'05)
|-
|1 <br> (following L)||Chevrolet Astro Awd ('00-'05)
|-
|1 <br> (following G)||Chevrolet Express 1500 series 2wd ('00-'09)
|-
|2 <br> (following G)||Chevrolet Express 2500 series 2wd ('00-'09)
|-
|3 <br> (following G)||Chevrolet Express 3500 series 2wd ('00-'09)
|-
|3 <br> (following G)||When VIN starts with 1GBK: Chevrolet Express 4500 series Cutaway 2wd ('09)
|-
|6 <br> (following G)||Chevrolet Express 1500 series LT 2wd ('01-'02)
|-
|1 <br> (following H)||Chevrolet Express 1500 series Awd ('03-'09)
|-
|2 <br> (following H)||Chevrolet Express 2500 series Awd ('03-'05)
|-
|1 <br> (following E)||Chevrolet Tracker Base model 2wd ('00-'04)
|-
|6 <br> (following E)||Chevrolet Tracker LT 2wd ('01-'04)
|-
|1 <br> (following J)||Chevrolet Tracker Base model 4wd ('00-'01, '04)
|-
|1 <br> (following J)||Chevrolet Tracker Base model w/1SB (Preferred) Equip. Group 4wd ('02-'03)
|-
|2 <br> (following J)||Chevrolet Tracker Base model w/1SA (Base) Equip. Group 4wd ('02-'03)
|-
|6 <br> (following J)||Chevrolet Tracker LT 4wd ('01-'04)
|-
|7 <br> (following J)||Chevrolet Tracker ZR2 4wd ('01-'04)
|-
|1 <br> (following L)||Chevrolet Equinox LS 2wd ('05-'09)
|-
|2 <br> (following L)||Chevrolet Equinox LS Awd ('05-'09)
|-
|6 <br> (following L)||Chevrolet Equinox LT 2wd ('05-'07)
|-
|7 <br> (following L)||Chevrolet Equinox LT Awd ('05-'07)
|-
|3 <br> (following L)||Chevrolet Equinox 1LT 2wd ('08-'09)
|-
|4 <br> (following L)||Chevrolet Equinox 1LT Awd ('08-'09)
|-
|5 <br> (following L)||Chevrolet Equinox 2LT 2wd ('08-'09)
|-
|6 <br> (following L)||Chevrolet Equinox 2LT Awd ('08-'09)
|-
|7 <br> (following L)||Chevrolet Equinox LTZ 2wd ('08-'09)
|-
|8 <br> (following L)||Chevrolet Equinox LTZ Awd ('08-'09)
|-
|9 <br> (following L)||Chevrolet Equinox Sport 2wd ('08-'09)
|-
|0 <br> (following L)||Chevrolet Equinox Sport Awd ('08-'09)
|-
|1 <br> (following R)||Chevrolet Traverse LS 2wd ('09)
|-
|2 <br> (following R)||Chevrolet Traverse LT 2wd ('09)
|-
|3 <br> (following R)||Chevrolet Traverse LTZ 2wd ('09)
|-
|1 <br> (following V)||Chevrolet Traverse LS Awd ('09)
|-
|2 <br> (following V)||Chevrolet Traverse LT Awd ('09)
|-
|3 <br> (following V)||Chevrolet Traverse LTZ Awd ('09)
|-
|1 <br> (following S)||Chevrolet Blazer 2wd ('00-'05)
|-
|1 <br> (following T)||Chevrolet Blazer 4wd ('00-'05)
|-
|1 <br> (following S)||Chevrolet Trailblazer 2wd ('02-'08), Trailblazer EXT 2wd ('02-'06)
|-
|1 <br> (following T)||Chevrolet Trailblazer 4wd ('02-'08), Trailblazer EXT 4wd ('02-'06)
|-
|3 <br> (following S)||Chevrolet Trailblazer LT 2wd ('09)
|-
|3 <br> (following T)||Chevrolet Trailblazer LT 4wd ('09)
|-
|5 <br> (following S)||Chevrolet Trailblazer SS 2wd ('09)
|-
|5 <br> (following T)||Chevrolet Trailblazer SS 4wd ('09)
|-
|1 <br> (following C)||Chevrolet Tahoe Limited 2wd ('00) [GMT400; 8th pos. of VIN is R]
|-
|1 <br> (following K)||Chevrolet Tahoe Z71 4wd ('00) [GMT400; 8th pos. of VIN is R]
|-
|1 <br> (following C)||Chevrolet Tahoe 2wd ('00-'06) [GMT800]
|-
|1 <br> (following K)||Chevrolet Tahoe 4wd ('00-'06) [GMT800]
|-
|1 <br> (following C)||Chevrolet Tahoe 2wd ('07-'08) [GMT900]
|-
|0 <br> (following C)||Chevrolet Tahoe Police/Special Service 2wd ('07-'09) [GMT900]
|-
|1 <br> (following C)||Chevrolet Tahoe LS 2wd ('09) [GMT900]
|-
|2 <br> (following C)||Chevrolet Tahoe LT 2wd ('09) [GMT900]
|-
|3 <br> (following C)||Chevrolet Tahoe LTZ 2wd ('09) [GMT900]
|-
|1 <br> (following K)||Chevrolet Tahoe 4wd ('07-'08) [GMT900]
|-
|0 <br> (following K)||Chevrolet Tahoe Police/Special Service 4wd ('07-'09) [GMT900]
|-
|1 <br> (following K)||Chevrolet Tahoe LS 4wd ('09) [GMT900]
|-
|2 <br> (following K)||Chevrolet Tahoe LT 4wd ('09) [GMT900]
|-
|3 <br> (following K)||Chevrolet Tahoe LTZ 4wd ('09) [GMT900]
|-
|1 <br> (following C)||Chevrolet Suburban 1500 series 2wd ('00-'08)
|-
|2 <br> (following C)||Chevrolet Suburban 2500 series 2wd ('00-'08)
|-
|1 <br> (following K)||Chevrolet Suburban 1500 series 4wd ('00-'08)
|-
|2 <br> (following K)||Chevrolet Suburban 2500 series 4wd ('00-'08)
|-
|1 <br> (following C)||Chevrolet Suburban 1500 series LS 2wd ('09)
|-
|2 <br> (following C)||Chevrolet Suburban 1500 series LT 2wd ('09)
|-
|3 <br> (following C)||Chevrolet Suburban 1500 series LTZ 2wd ('09)
|-
|4 <br> (following C)||Chevrolet Suburban 2500 series LS 2wd ('09)
|-
|5 <br> (following C)||Chevrolet Suburban 2500 series LT 2wd ('09)
|-
|1 <br> (following K)||Chevrolet Suburban 1500 series LS 4wd ('09)
|-
|2 <br> (following K)||Chevrolet Suburban 1500 series LT 4wd ('09)
|-
|3 <br> (following K)||Chevrolet Suburban 1500 series LTZ 4wd ('09)
|-
|4 <br> (following K)||Chevrolet Suburban 2500 series LS 4wd ('09)
|-
|5 <br> (following K)||Chevrolet Suburban 2500 series LT 4wd ('09)
|-
|1 <br> (following C)||Chevrolet Avalanche 1500 series 2wd ('02-'08)
|-
|2 <br> (following C)||Chevrolet Avalanche 2500 series 2wd ('02-'03)
|-
|1 <br> (following K)||Chevrolet Avalanche 1500 series 4wd ('02-'08)
|-
|2 <br> (following K)||Chevrolet Avalanche 2500 series 4wd ('02-'06)
|-
|1 <br> (following C)||Chevrolet Avalanche 1500 series LS 2wd ('09)
|-
|2 <br> (following C)||Chevrolet Avalanche 1500 series LT 2wd ('09)
|-
|3 <br> (following C)||Chevrolet Avalanche 1500 series LTZ 2wd ('09)
|-
|1 <br> (following K)||Chevrolet Avalanche 1500 series LS 4wd ('09)
|-
|2 <br> (following K)||Chevrolet Avalanche 1500 series LT 4wd ('09)
|-
|3 <br> (following K)||Chevrolet Avalanche 1500 series LTZ 4wd ('09)
|-
|1 <br> (following S)||Chevrolet SSR 2wd ('03-'06)
|-
|6 <br> (following S)||Chevrolet SSR Signature Series 2wd ('03) <br> [All SSR Signature Series also have a 0 in the 12th pos. of VIN whereas all other SSRs have a 1 in the 12th pos. of VIN]
|-
|1 <br> (following S)||Chevrolet S-10 2wd ('00-'03)
|-
|1 <br> (following T)||Chevrolet S-10 4wd ('00-'04)
|-
|1 <br> (following S)||Chevrolet Colorado 2wd ('04-'07)
|-
|1 <br> (following T)||Chevrolet Colorado 4wd ('04-'07)
|-
|1 <br> (following V)||Pontiac Montana Mobility (incomplete vehicle) 2wd ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following V)||Pontiac Montana ('05) (Pos. 8 of VIN is E)
|-
|0 <br> (following V)||Pontiac Montana SV6 1SA 2wd ('05)
|-
|3 <br> (following V)||Pontiac Montana SV6 1SB 2wd ('05)
|-
|2 <br> (following X)||Pontiac Montana SV6 1SA Awd ('05)
|-
|3 <br> (following X)||Pontiac Montana SV6 1SB Awd ('05)
|-
|1 <br> (following V)||Pontiac Montana SV6 Mobility (incomplete vehicle) 2wd ('06)
|-
|3 <br> (following V)||Pontiac Montana SV6 2wd ('06)
|-
|3 <br> (following X)||Pontiac Montana SV6 Awd ('06)
|-
|0 <br> (following A)||Pontiac Aztek 2wd ('01-'05)
|-
|0 <br> (following B)||Pontiac Aztek Awd ('01-'05)
|-
|6 <br> (following L)||Pontiac Torrent 2wd ('06-'07)
|-
|7 <br> (following L)||Pontiac Torrent Awd ('06-'07)
|-
|3 <br> (following L)||Pontiac Torrent Base model 2wd ('08-'09)
|-
|4 <br> (following L)||Pontiac Torrent Base model Awd ('08-'09)
|-
|5 <br> (following L)||Pontiac Torrent GXP 2wd ('08-'09)
|-
|6 <br> (following L)||Pontiac Torrent GXP Awd ('08-'09)
|-
|0 <br> (following X)||Oldsmobile Silhouette extended length GL 2wd ('00, '03-'04), GLS 2wd ('00-'04)
|-
|1 <br> (following X)||Oldsmobile Silhouette extended length Premiere 2wd ('00-'04)
|-
|2 <br> (following X)||Oldsmobile Silhouette extended length GL 2wd ('01-'02)
|-
|0 <br> (following V)||Oldsmobile Silhouette extended length GLS Awd ('02-'04)
|-
|1 <br> (following V)||Oldsmobile Silhouette extended length Premiere Awd ('02-'04)
|-
|1 <br> (following S)||Oldsmobile Bravada 2wd ('02-'04)
|-
|1 <br> (following T)||Oldsmobile Bravada 4wd ('00-'04)
|-
|1 <br> (following V)||Buick Terraza Mobility (incomplete vehicle) 2wd ('05-'07)
|-
|2 <br> (following V)||Buick Terraza CX 2wd ('05-'07), CX Plus 2wd ('07)
|-
|3 <br> (following V)||Buick Terraza CXL 2wd ('05-'07)
|-
|2 <br> (following X)||Buick Terraza CX Awd ('05-'06)
|-
|3 <br> (following X)||Buick Terraza CXL Awd ('05-'06)
|-
|0 <br> (following A)||Buick Rendezvous 2wd ('02-'07)
|-
|0 <br> (following B)||Buick Rendezvous Awd ('02-'06)
|-
|1 <br> (following S)||Buick Rainier 2wd ('04-'07)
|-
|1 <br> (following T)||Buick Rainier 4wd ('04-'06)
|-
|1 <br> (following R)||Buick Enclave CX 2wd ('08-'09)
|-
|2 <br> (following R)||Buick Enclave CXL 2wd ('08-'09)
|-
|1 <br> (following V)||Buick Enclave CX Awd ('08-'09)
|-
|2 <br> (following V)||Buick Enclave CXL Awd ('08-'09)
|-
|6 <br> (following E)||Cadillac SRX ('04-'07)
|-
|2 <br> (following E)||Cadillac SRX RWD V8 ('08-'09)
|-
|4 <br> (following E)||Cadillac SRX AWD V6 ('08-'09)
|-
|5 <br> (following E)||Cadillac SRX AWD V8 ('08-'09)
|-
|6 <br> (following E)||When Pos. 8 of VIN is 7: Cadillac SRX RWD V6 ('08)
|-
|6 <br> (following E)||When Pos. 8 of VIN is A: Cadillac SRX AWD V8 ('08)
|-
|6 <br> (following E)||Cadillac SRX RWD V6 ('09)
|-
|1 <br> (following K)||Cadillac Escalade 4wd (Early '00)
|-
|4 <br> (following K)||Cadillac Escalade Platinum Edition 4wd ('08), Escalade ESV Platinum Edition 4wd ('08)
|-
|6 <br> (following C)||Cadillac Escalade 2wd ('02-'08), Escalade ESV 2wd ('08)
|-
|6 <br> (following K)||Cadillac Escalade 4wd (Mid '00, '02-'08), Escalade ESV 4wd ('03-'08), Escalade EXT 4wd ('02-'08)
|-
|1 <br> (following C)||Cadillac Escalade 2wd Base model ('09), Escalade ESV 2wd Base model ('09)
|-
|2 <br> (following C)||Cadillac Escalade 2wd w/Ultra Luxury Collection ('09), Escalade ESV 2wd w/Ultra Luxury Collection ('09)
|-
|3 <br> (following C)||Cadillac Escalade 2wd w/Platinum Edition ('09), Escalade ESV 2wd w/Platinum Edition ('09)
|-
|4 <br> (following C)||Cadillac Escalade Hybrid 2wd Base model ('09)
|-
|5 <br> (following C)||Cadillac Escalade 2wd w/Sport Package ('09), Escalade ESV 4wd w/Sport Package ('09)
|-
|1 <br> (following K)||Cadillac Escalade 4wd Base model ('09), Escalade ESV 4wd Base model ('09), Escalade EXT 4wd Base model ('09)
|-
|2 <br> (following K)||Cadillac Escalade 4wd w/Ultra Luxury Collection ('09), Escalade ESV 4wd w/Ultra Luxury Collection ('09),<br> Escalade EXT 4wd w/Ultra Luxury Collection ('09)
|-
|3 <br> (following K)||Cadillac Escalade 4wd w/Platinum Edition ('09), Escalade ESV 4wd w/Platinum Edition ('09)
|-
|4 <br> (following K)||Cadillac Escalade Hybrid 4wd Base model ('09)
|-
|5 <br> (following K)||Cadillac Escalade 4wd w/Sport Package ('09), Escalade ESV 4wd w/Sport Package ('09), Escalade EXT 4wd w/Sport Package ('09)
|-
|1 <br> (following M)||GMC Safari 2wd ('00-'05)
|-
|1 <br> (following L)||GMC Safari Awd ('00-'05)
|-
|1 <br> (following G)||GMC Savana 1500 series 2wd ('00-'09)
|-
|2 <br> (following G)||GMC Savana 2500 series 2wd ('00-'09)
|-
|3 <br> (following G)||GMC Savana 3500 series 2wd ('00-'09)
|-
|3 <br> (following G)||When VIN starts with 1GBK: GMC Savana 4500 series Cutaway 2wd ('09)
|-
|6 <br> (following G)||GMC Savana 1500 series SLT 2wd ('01-'02)
|-
|1 <br> (following H)||GMC Savana 1500 series Awd ('03-'09)
|-
|2 <br> (following H)||GMC Savana 2500 series Awd ('03-'05)
|-
|1 <br> (following R)||GMC Acadia SLE 2wd ('07-'09)
|-
|2 <br> (following R)||GMC Acadia SLT-1 2wd ('07-'09)
|-
|3 <br> (following R)||GMC Acadia SLT-2 2wd ('07-'09)
|-
|1 <br> (following V)||GMC Acadia SLE Awd ('07-'09)
|-
|2 <br> (following V)||GMC Acadia SLT-1 Awd ('07-'09)
|-
|3 <br> (following V)||GMC Acadia SLT-2 Awd ('07-'09)
|-
|1 <br> (following S)||GMC Jimmy 2wd ('00-'01)
|-
|6 <br> (following S)||GMC Jimmy Diamond Edition 2wd ('01)
|-
|1 <br> (following T)||GMC Jimmy 4wd ('00-'01 & '02-'05 in Canada)
|-
|6 <br> (following T)||GMC Jimmy Diamond Edition 4wd ('01)
|-
|1 <br> (following S)||GMC Envoy 2wd ('02-'08), Envoy XL 2wd ('02-'06), Envoy XUV 2wd ('04-'05)
|-
|6 <br> (following S)||GMC Envoy Denali 2wd ('05-'08), Envoy XL Denali 2wd ('05-'06)
|-
|1 <br> (following T)||GMC Envoy 4wd ('02-'08), Envoy XL 4wd ('02-'06), Envoy XUV 4wd ('04-'05)
|-
|6 <br> (following T)||GMC Envoy Denali 4wd ('05-'08), Envoy XL Denali 4wd ('05-'06)
|-
|3 <br> (following S)||GMC Envoy SLE 2wd ('09)
|-
|3 <br> (following T)||GMC Envoy SLE 4wd ('09)
|-
|4 <br> (following S)||GMC Envoy SLT 2wd ('09)
|-
|4 <br> (following T)||GMC Envoy SLT 4wd ('09)
|-
|5 <br> (following S)||GMC Envoy Denali 2wd ('09)
|-
|5 <br> (following T)||GMC Envoy Denali 4wd ('09)
|-
|1 <br> (following C)||GMC Yukon 2wd ('00-'06) [GMT800]
|-
|1 <br> (following K)||GMC Yukon 4wd ('00-'06) [GMT800]
|-
|1 <br> (following C)||GMC Yukon 2wd ('07-'08) [GMT900]
|-
|1 <br> (following K)||GMC Yukon 4wd ('07-'08) [GMT900]
|-
|1 <br> (following C)||GMC Yukon 2wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon 4wd ('09) [GMT900]
|-
|1 <br> (following C)||GMC Yukon Hybrid 2wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following K)||GMC Yukon Hybrid 4wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|2 <br> (following C)||GMC Yukon SLE 2wd ('09) [GMT900]
|-
|3 <br> (following C)||GMC Yukon SLT 2wd ('09) [GMT900]
|-
|2 <br> (following K)||GMC Yukon SLE 4wd ('09) [GMT900]
|-
|3 <br> (following K)||GMC Yukon SLT 4wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon Denali 4wd (Early '00) [GMT400; 8th pos. of VIN is R]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd (Mid '00) [GMT400; 8th pos. of VIN is R]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd ('01-'06) [GMT800]
|-
|6 <br> (following C)||GMC Yukon Denali 2wd ('08) [GMT900]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd ('07-'08) [GMT900]
|-
|0 <br> (following C)||GMC Yukon Denali 2wd ('09) [GMT900]
|-
|0 <br> (following K)||GMC Yukon Denali 4wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon Denali 4wd ('09) [GMT900; 8th pos. of VIN is 2]
|-
|1 <br> (following C)||GMC Yukon Denali Hybrid 2wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following K)||GMC Yukon Denali Hybrid 4wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following C)||GMC Yukon XL 1500 series 2wd ('00-'08)
|-
|2 <br> (following C)||GMC Yukon XL 2500 series 2wd ('00-'08)
|-
|6 <br> (following C)||GMC Yukon XL Denali 1500 series 2wd ('08)
|-
|1 <br> (following K)||GMC Yukon XL 1500 series 4wd ('00-'08)
|-
|2 <br> (following K)||GMC Yukon XL 2500 series 4wd ('00-'08)
|-
|6 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('01-'08)
|-
|1 <br> (following C)||GMC Yukon XL 1500 series 2wd ('09)
|-
|2 <br> (following C)||GMC Yukon XL 1500 series SLE 2wd ('09)
|-
|3 <br> (following C)||GMC Yukon XL 1500 series SLT 2wd ('09)
|-
|4 <br> (following C)||GMC Yukon XL 2500 series 2wd ('09)
|-
|5 <br> (following C)||GMC Yukon XL 2500 series SLE 2wd ('09)
|-
|6 <br> (following C)||GMC Yukon XL 2500 series SLT 2wd ('09)
|-
|0 <br> (following C)||GMC Yukon XL Denali 1500 series 2wd ('09)
|-
|1 <br> (following K)||GMC Yukon XL 1500 series 4wd ('09)
|-
|2 <br> (following K)||GMC Yukon XL 1500 series SLE 4wd ('09)
|-
|3 <br> (following K)||GMC Yukon XL 1500 series SLT 4wd ('09)
|-
|4 <br> (following K)||GMC Yukon XL 2500 series 4wd ('09)
|-
|5 <br> (following K)||GMC Yukon XL 2500 series SLE 4wd ('09)
|-
|6 <br> (following K)||GMC Yukon XL 2500 series SLT 4wd ('09)
|-
|0 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('09)
|-
|1 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('09) [8th pos. of VIN is 2]
|-
|1 <br> (following S)||GMC Sonoma 2wd ('00-'03)
|-
|1 <br> (following T)||GMC Sonoma 4wd ('00-'04)
|-
|1 <br> (following S)||GMC Canyon 2wd ('04-'07)
|-
|1 <br> (following T)||GMC Canyon 4wd ('04-'07)
|-
|0 <br> (following V)||Saturn Relay ''2'' 2wd ('05-'07)
|-
|2 <br> (following V)||Saturn Relay ''3'' 2wd ('05-'07)
|-
|5 <br> (following V)||Saturn Relay ''1'' 2wd ('07)
|-
|2 <br> (following X)||Saturn Relay ''3'' Awd ('05-'06)
|-
|2 <br> (following Z)||Saturn Vue I4, Man. Trans., Fwd ('02-'07)
|-
|3 <br> (following Z)||Saturn Vue I4, Auto. Trans., Fwd ('02-'07)
|-
|4 <br> (following Z)||Saturn Vue I4, Auto. Trans., Awd ('02-'05)
|-
|5 <br> (following Z)||Saturn Vue V6, Auto. Trans., Fwd ('03-'07)
|-
|6 <br> (following Z)||Saturn Vue V6, Auto. Trans., Awd ('02-'07)
|-
|3 <br> (following L)||Saturn Vue XE Fwd ('08-'09)
|-
|4 <br> (following L)||Saturn Vue XE Awd ('08-'09)
|-
|5 <br> (following L)||when 4th pos. of VIN is C: Saturn Vue XR Fwd ('08-'09)
|-
|7 <br> (following L)||Saturn Vue XR Awd (Early '08)
|-
|6 <br> (following L)||Saturn Vue XR Awd (Mid '08-'09)
|-
|5 <br> (following L)||when 4th pos. of VIN is D: Saturn Vue XR Awd ('09)
|-
|1 <br> (following L)||Saturn Vue Red Line Fwd ('08-'09)
|-
|9 <br> (following L)||Saturn Vue Red Line Awd ('08)
|-
|0 <br> (following L)||Saturn Vue Red Line Awd ('09)
|-
|0 <br> (following L)||Saturn Vue Green Line Fwd ('08)
|-
|9 <br> (following L)||Saturn Vue Green Line Fwd ('09)
|-
|1 <br> (following R)||Saturn Outlook XE 2wd ('07-'09)
|-
|2 <br> (following R)||Saturn Outlook XR 2wd ('07-'09)
|-
|3 <br> (following R)||Saturn Outlook XR 2wd w/Touring Package ('07-'09)
|-
|1 <br> (following V)||Saturn Outlook XE Awd ('07-'09)
|-
|2 <br> (following V)||Saturn Outlook XR Awd ('07-'09)
|-
|3 <br> (following V)||Saturn Outlook XR Awd w/Touring Package ('07-'09)
|-
|1 <br> (following N)||Hummer H3 ('06-'07)
|-
|1 <br> (following N)||Hummer H3 Base model ('08)
|-
|3 <br> (following N)||Hummer H3 Adventure ('08)
|-
|4 <br> (following N)||Hummer H3 Luxury ('08)
|-
|5 <br> (following N)||Hummer H3 X ('08)
|-
|6 <br> (following N)||Hummer H3 Alpha ('08)
|-
|1 <br> (following N)||Hummer H3, H3T ('09)
|-
|2 <br> (following N)||Hummer H2 ('03-'08), H2 SUT ('05-'08)
|-
|2 <br> (following N)||Hummer H2 Base model ('09), H2 SUT Base model ('09)
|-
|7 <br> (following N)||Hummer H2 Adventure ('09)
|-
|8 <br> (following N)||Hummer H2 Luxury ('09)
|-
|9 <br> (following N)||Hummer H2 SUT Adventure ('09)
|-
|0 <br> (following N)||Hummer H2 SUT Luxury ('09)
|-
|1 (following S)||Isuzu Hombre 2wd ('00), Isuzu i280 2wd ('06), Isuzu i290 2wd ('07-'08), Isuzu i370 2wd ('07-'08)
|-
|2 (following S)||Isuzu i290 2wd w/Preferred Equip. Pkg. ('08), Isuzu i370 2wd w/Comfort Pkg. or upgrade model ('08)
|-
|1 (following T)||Isuzu Hombre 4wd ('00), Isuzu i350 4wd ('06), Isuzu i370 4wd ('07-'08)
|-
|2 (following T)||Isuzu i370 4wd w/Comfort Pkg. ('08)
|-
|1 (following S)||Isuzu Ascender 2wd ('03-'08)
|-
|1 (following T)||Isuzu Ascender 4wd ('03-'08)
|-
|1 (following T)||Saab 9-7X ('05-'08: All, '09: 4.2i, 5.3i)
|-
|2 (following T)||Saab 9-7X Aero ('09)
|}
====Body style codes 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Body type is specified as character 7 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|0||Sedan Pickup/Pickup Delivery ('81-'87 El Camino, Caballero)
|-
|0||Cadillac, Buick, Chevrolet Commercial Body/Chassis
|-
|0||Chassis Only
|-
|1||Cutaway Van
|-
|2||Forward Control ('81-'03) (includes '93-'95 Chevy G30HD/GMC G3500HD)
|-
|2||Sport Utility Truck (SUT) ('04-'09 Avalanche & Escalade EXT, '04-'05 Envoy XUV, '05-'09 Hummer H2 SUT)
|-
|3||Four-Door Cab pickup (Crew Cab) (includes '06-'08 Isuzu i-Series Crew Cab, '09 Hummer H3T)
|-
|3||4-door Passenger Minivan ('97-'09 U-bodies)
|-
|3||4-door SUV or MPV ('06-'09 HHR) (also includes '02-'03 Avalanche & Escalade EXT) ('05-'09 Saab 9-7X)
|-
|4||Two-Door Cab pickup (includes '83-'87 S-10/S-15 extended cab pickups, '03-'06 Chevy SSR, '96-'00 Isuzu Hombre Reg. Cab)
|-
|5||Van (Astro/Safari & full-size vans & '07-'09 HHR Panel)
|-
|6||Extended length 4-door SUV (Suburban, Yukon XL, Escalade ESV, Trailblazer EXT, Envoy XL, Isuzu Ascender 7-psgr.)
|-
|6||3-door Passenger Minivan ('90-'99 U-bodies)
|-
|7||Motor Home Chassis ('81-'09)
|-
|8||Two-Door SUV (Utility) (2-d Tracker, S-10 Blazer, S-15 Jimmy, Blazer, Jimmy, Tahoe, Yukon)
|-
|9||Stake (81-87)
|-
|9||Extended Cab pickup ('88-) (includes '97-'00 Isuzu Hombre Spacecab, '06-'08 Isuzu i-Series Ext. Cab)
|-
|9||Extended length van ('90-) (Astro/Safari & full-size vans)
|}
===American VIN format 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>K</td><td></td><td></td></tr><tr>
<td>4</td>
<td>L</td><td></td><td></td><td>[[#GVWR/Brake System/Body Style 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|GVWR/Brake System/Body Style 2010-]]</td>
</tr><tr>
<td>5</td>
<td>R</td><td></td><td></td><td>[[#Line & Chassis Type 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 2010-]]</td>
</tr><tr>
<td>6</td>
<td>L</td><td></td><td></td><td>[[#Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle]]</td>
</tr><tr>
<td>7</td>
<td>E</td><td></td><td></td><td>[[#Restraint codes for light trucks 2010-|Restraint type]]</td>
</tr><tr>
<td>8</td>
<td>D</td><td></td><td></td><td>[[#Engine codes for light trucks|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>A</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>J</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====GVWR/Brake System/Body Style 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The GVWR/Brake System is specified as character 4 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!GVWR Range in lbs. & Weight Class
!Brake System
!Body Style
|-
| ||Class A: 0-3,000||Hydraulic||
|-
| ||Class B: 3,001-4,000||Hydraulic||
|-
|A||Class C: 4,001-5,000||Hydraulic||26: 4-door SUV or MPV ('10-'11 Chevy HHR Panel, '10-'26 Chevy Equinox, GMC Terrain, '10 Saturn Vue,<br> '12-'15 Chevy Captiva Sport, '19-'24 Cadillac XT4, '24-'26 Buick Encore GX)
|-
|B||Class C: 4,001-5,000||Hydraulic||46: 4-door MPV ('10-'11 Chevy HHR)
|-
|J||Class C: 4,001-5,000||Hydraulic||48: 4-door, 4 window Hatchback ('18-'23 Chevy Bolt EV w/Rear Seat Delete pkg. - incomplete vehicle)
|-
|C||Class C: 4,001-5,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|D||Class C: 4,001-5,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|E||Class C: 4,001-5,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|7||Class C: 4,001-5,000||Hydraulic||75: Four-Door Wagon - High Roof Monocab (Canada only: '12-'14 Chevy Orlando)
|-
|M||Class C: 4,001-5,000||Hydraulic||06: 4-door SUV ('20-'23 Buick Encore GX)
|-
|9||Class C: 4,001-5,000||Hydraulic||56: 4-door SUV Extended ('21-'26 Chevy Trailblazer)
|-
|7||Class C: 4,001-5,000||Hydraulic||58: 4-door Utility Extended ('24-'26 Chevy Trax, Buick Envista)
|-
|C||Class C: 4,001-5,000||Hydraulic||76: 4-door SUV ('13-'22 Buick Encore, Canada only: '13-'14 Chevy Trax, US & Canada: '15-'22 Chevy Trax)
|-
|F||Class D: 5,001-6,000||Hydraulic||26: 4-door SUV ('10-'17 Chevy Equinox, GMC Terrain, '10 Saturn Vue, '10-'16 Cadillac SRX, '11 Saab 9-4X,<br> '12-'13 Chevy Captiva Sport, '16-'26 Buick Envision, '17 Cadillac XT5, '19-'25 Cadillac XT4)
|-
|H||Class D: 5,001-6,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|G||Class D: 5,001-6,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|J||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|H||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|G||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('15-'24 Chevy Colorado, '15-'22 GMC Canyon)
|-
|K||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|J||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|H||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('15-'22 Chevy Colorado, GMC Canyon)
|-
|T||Class D: 5,001-6,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|7||Class D: 5,001-6,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|L||Class E: 6,001-7,000||Hydraulic||26: 4-door SUV ('10 Chevy Traverse, GMC Acadia, Buick Enclave, Saturn Outlook)
|-
|K||Class E: 6,001-7,000||Hydraulic||26: 4-door SUV ('11-'17 Chevy Traverse, Buick Enclave, '11-'23 GMC Acadia, '17 Acadia Limited,<br> '17-'26 Cadillac XT5, '19-'26 Chevy Blazer, '20-'25 Cadillac XT6, '23-'26 Cadillac Lyriq EV,<br> '24-'26 Chevy Blazer EV, '25-'26 Cadillac Optiq EV, '24-'26 Honda Prologue EV, '24 Acura ZDX EV A-Spec)
|-
|7||Class E: 6,001-7,000||Hydraulic||48: 4-door SUV ('24-'25 Chevy Equinox EV)
|-
|E||Class E: 6,001-7,000||Hydraulic||56: 4-door SUV Extended ('18-'26 Chevy Traverse, Buick Enclave, '24 Chevy Traverse Limited,<br> '24-'26 GMC Acadia
|-
|M||Class E: 6,001-7,000||Hydraulic||05: Cargo Van ('10 Chevy Express, GMC Savana)
|-
|L||Class E: 6,001-7,000||Hydraulic||05: Cargo Van ('11-'14 Chevy Express, GMC Savana)
|-
|M||Class E: 6,001-7,000||Hydraulic||06: 4-door SUV ('10 Chevy Tahoe, GMC Yukon, Hummer H3)
|-
|L||Class E: 6,001-7,000||Hydraulic||06: 4-door SUV ('11-'20 Chevy Tahoe Police Pursuit Vehicle 2wd)
|-
|N||Class E: 6,001-7,000||Hydraulic||36: Sport Utility Truck (SUT) ('10 Chevy Avalanche 2wd)
|-
|M||Class E: 6,001-7,000||Hydraulic||36: Sport Utility Truck (SUT) ('11-13 Chevy Avalanche 2wd)
|-
|P||Class E: 6,001-7,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|N||Class E: 6,001-7,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|R||Class E: 6,001-7,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra, Hummer H3T)
|-
|P||Class E: 6,001-7,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited, '16-'26 Chevy Colorado, GMC Canyon)
|-
|S||Class E: 6,001-7,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|R||Class E: 6,001-7,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '19 Chevy Silverado LD, GMC Sierra Limited, '22 Chevy Silverado LTD, GMC Sierra Limited,<br> '16-'22 Chevy Colorado)
|-
|G||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|8||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|X||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('13-'19 Cadillac XTS chassis for Limo/Hearse)
|-
|U||Class F: 7,001-8,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|S||Class F: 7,001-8,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'14 Chevy Express, GMC Savana)
|-
|U||Class F: 7,001-8,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|S||Class F: 7,001-8,000||Hydraulic||06: Passenger Van ('11-'14 Chevy Express, GMC Savana)
|-
|U||Class F: 7,001-8,000||Hydraulic||06: 4-door SUV ('10 Chevy Tahoe, Suburban 1500, GMC Yukon, Yukon XL 1500, Cadillac Escalade, Escalade ESV)
|-
|S||Class F: 7,001-8,000||Hydraulic||06: 4-door SUV ('11-'26 Chevy Tahoe, Suburban 1500, GMC Yukon, Yukon XL 1500, Cadillac Escalade, Escalade ESV)
|-
|V||Class F: 7,001-8,000||Hydraulic||36: Sport Utility Truck (SUT) ('10 Chevy Avalanche 4wd, Cadillac Escalade EXT 4wd)
|-
|T||Class F: 7,001-8,000||Hydraulic||36: Sport Utility Truck (SUT) ('11-'13 Chevy Avalanche 4wd, Cadillac Escalade EXT 4wd)
|-
|X||Class F: 7,001-8,000||Hydraulic||26: 4-door SUV ('24 Acura ZDX EV Type S)
|-
|C||Class F: 7,001-8,000||Hydraulic||56: 4-door SUV Extended ('26- Cadillac Vistiq EV)
|-
|W||Class F: 7,001-8,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|X||Class F: 7,001-8,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|U||Class F: 7,001-8,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|Y||Class F: 7,001-8,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|V||Class F: 7,001-8,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '19 Chevy Silverado LD, GMC Sierra Limited, '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|U||Class F: 7,001-8,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|9||Class F: 7,001-8,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|Z||Class G: 8,001-9,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|W||Class G: 8,001-9,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'26 Chevy Express, GMC Savana)
|-
|Z||Class G: 8,001-9,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|W||Class G: 8,001-9,000||Hydraulic||06: Passenger Van ('11-'26 Chevy Express, GMC Savana)
|-
|Z||Class G: 8,001-9,000||Hydraulic||06: 4-door SUV ('10 Chevy Suburban 2500, GMC Yukon XL 2500)
|-
|W||Class G: 8,001-9,000||Hydraulic||06: 4-door SUV ('11-'13 Chevy Suburban 2500, GMC Yukon XL 2500)
|-
|2||Class H: 9,001-10,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|Z||Class H: 9,001-10,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'26 Chevy Express, GMC Savana,<br> '23-'24 BrightDrop Zevo 600, '24 BrightDrop Zevo 400, '25-'26 Chevrolet BrightDrop 400/600)
|-
|2||Class H: 9,001-10,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|Z||Class H: 9,001-10,000||Hydraulic||06: Passenger Van ('11-'26 Chevy Express, GMC Savana)
|-
|3||Class H: 9,001-10,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|0||Class H: 9,001-10,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
|3||Class H: 9,001-10,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|0||Class H: 9,001-10,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra)
|-
|4||Class H: 9,001-10,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|1||Class H: 9,001-10,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '24-'25 GMC Hummer EV pickup w/20 module battery pack,<br> '24-'26 Chevy Silverado EV, '25-'26 GMC Sierra EV)
|-
|5||Class H: 9,001-10,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|2||Class H: 9,001-10,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'13, '15-'26 Chevy Silverado, GMC Sierra)
|-
|B||Class H: 9,001-10,000||Hydraulic||26: 4-door SUV ('24-'25 GMC Hummer EV SUV)
|-
|6||Class 3: 10,001-14,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|3||Class 3: 10,001-14,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
|6||Class 3: 10,001-14,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|3||Class 3: 10,001-14,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra)
|-
|7||Class 3: 10,001-14,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|4||Class 3: 10,001-14,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22-'24 GMC Hummer EV pickup w/24 module battery pack, '25 GMC Hummer EV pickup w/20 or 24 module battery pack, '26 GMC Hummer EV pickup, '24-'25 Chevy Silverado EV, GMC Sierra EV)
|-
|8||Class 3: 10,001-14,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|5||Class 3: 10,001-14,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'13, '15-'18, '20-'26 Chevy Silverado, GMC Sierra)
|-
|8||Class 3: 10,001-14,000||Hydraulic||06: 4-door SUV ('16-'19, '24-'26 Chevy Suburban 3500HD)
|-
|8||Class 3: 10,001-14,000||Hydraulic||05: Cargo Van ('22 BrightDrop EV600, '23-'24 BrightDrop Zevo 600, '24 BrightDrop Zevo 400,<br> '25-'26 Chevrolet BrightDrop 400/600)
|-
|T||Class 3: 10,001-14,000||Hydraulic||26: 4-door SUV ('25-'26 GMC Hummer EV SUV, '25-'26 Cadillac Escalade IQ [EV])
|-
|L||Class 3: 10,001-14,000||Hydraulic||56: 4-door SUV Extended ('26- Cadillac Escalade IQL [EV])
|-
|9||Class 4: 14,001-16,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|6||Class 4: 14,001-16,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
| ||Class 5: 16,001-19,500||Hydraulic||
|}
====Line & Chassis Type 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Chevrolet HHR ('10-'11), HHR Panel ('10-'11)
|-
|A||Chevy Silverado 1500 2wd ('22-'26), Silverado HD 2500/3500 2wd ('25-'26)
|-
|B||Chevy Blazer 2wd & Awd '19-'26
|-
|C||Chevy Silverado 2wd ('10-'18), Silverado LD 1500 2wd '19, Silverado HD 2500/3500 2wd '19, GMC Sierra 2wd ('10)
|-
|C||Chevy Tahoe 2wd ('10-'24), Suburban 2wd ('10-'24), Avalanche 2wd ('10-'13),<br /> GMC Yukon 2wd ('10), Yukon XL 2wd ('10), Cadillac Escalade 2wd ('10), Escalade ESV 2wd ('10)
|-
|D||Chevy Silverado 1500 4wd ('22-'24)
|-
|D||Chevy Blazer EV ('24-'26), Chevy Equinox EV ('24-'26)
|-
|E||Cadillac Escalade IQ [EV] ('25-'26), Escalade IQL [EV] ('26-), GMC Hummer EV pickup ('26-), GMC Hummer EV SUV ('26-), GMC Sierra EV ('26-)
|-
|F||Chevy Bolt EV w/Rear Seat Delete pkg. - incomplete vehicle ('18-'23)
|-
|G||Cadillac Chassis for Limousine & for Armored Vehicle (Based on XTS '13-'19)
|-
|G||Cadillac Chassis for Hearse (Based on XTS '13-'19)
|-
|G||Chevy Express 2wd ('10-'26), GMC Savana 2wd ('10)
|-
|H||Chevy Express 4wd ('10-'14), GMC Savana 4wd ('10)
|-
|H||GMC Sierra 1500 2wd ('22-'26), Sierra HD 2500/3500 2wd ('25-'26)
|-
|H||Honda Prologue EV ('24-'26), Acura ZDX EV ('24)
|-
|J||Buick Encore 2wd & Awd ('13-'22), Chevy Trax 2wd & Awd (Canada: '13-'22, US: '15-'22)
|-
|J||BrightDrop EV600 ('22), BrightDrop Zevo 600 ('23-'24), BrightDrop Zevo 400 ('24), Chevrolet BrightDrop 400/600 ('25-'26)
|-
|K||Chevy Silverado 4wd ('10-'18), Silverado LD 1500 4wd ('19), Silverado HD 2500/3500 4wd ('19), GMC Sierra 4wd ('10)
|-
|K||Chevy Silverado 1500 4wd ('25-'26), Silverado HD 2500/3500 4wd ('25-'26)
|-
|K||Chevy Tahoe 4wd ('10-'24), Suburban 4wd ('10-'24), Suburban HD 4wd ('24-'26), Avalanche 4wd ('10-'13), GMC Yukon 4wd ('10), Yukon XL 4wd ('10),<br> Cadillac Escalade 4wd ('10), Escalade ESV 4wd ('10), Escalade EXT 4wd ('10)
|-
|K||Cadillac Professional Chassis for Limousine (Based on DTS '10-'11)
|-
|K||Cadillac Commercial Chassis for Hearse (Based on DTS '10-'11)
|-
|L||Chevy Equinox 2wd & Awd '10-'17, Captiva Sport 2wd '12-'15, Captiva Sport Awd '12, GMC Terrain 2wd & Awd '10-'17, Saturn Vue 2wd & Awd '10
|-
|L||GMC Terrain 2wd & Awd '18-'26
|-
|L||Buick Envista '24-'26, Chevy Trax '24-'26
|-
|M||Buick Encore GX 2wd & Awd ('20-'26), Chevy Trailblazer 2wd & Awd ('21-'26)
|-
|N||Cadillac SRX 2wd & Awd '10-'16, Saab 9-4X 2011
|-
|N||GMC Acadia 2wd & Awd '17-'26, Cadillac XT5 2wd & Awd '17-'26
|-
|N||Hummer H3, H3T 2010
|-
|P||Chevy Orlando (Canada only: '12-'14)
|-
|P||Cadillac XT6 2wd & Awd '20-'25
|-
|P||Cadillac Lyriq EV 2wd & Awd '23-'25
|-
|R||GMC Acadia 2wd '10-'16, Acadia Limited 2wd '17, Saturn Outlook 2wd '10, Buick Enclave 2wd '10-'17, Chevy Traverse 2wd '10-'17
|-
|R||Buick Enclave 2wd '18-'24, Chevy Traverse 2wd '18-'23
|-
|R||Buick Enclave 2wd '25-'26, Chevy Traverse 2wd '24-'26
|-
|S||Chevy Traverse Limited 2wd '24
|-
|S||Chevy Colorado 2wd ('10-'12, '15-'26), GMC Canyon 2wd ('10)
|-
|T||Chevy Colorado 4wd ('10-'12, '15-'26), GMC Canyon 4wd ('10)
|-
|T||Chevy Traverse Limited Awd '24
|-
|U||GMC Sierra 1500 4wd ('22-'26), Sierra HD 2500/3500 4wd ('25-'26)
|-
|V||GMC Acadia Awd '10-'16, Acadia Limited Awd '17, Saturn Outlook Awd '10, Buick Enclave Awd '10-'17, Chevy Traverse Awd '10-'17
|-
|V||Buick Enclave Awd '18-'24, Chevy Traverse Awd '18-'23
|-
|V||Buick Enclave Awd '25-'26, Chevy Traverse Awd '24-'26
|-
|W||Chevy Silverado 1500 2wd ('19-'21), Silverado LTD 1500 2wd ('22), Silverado HD 2500/3500 2wd ('20-'24)
|-
|X||Buick Envision 2wd & Awd '16-'20, Chevy Equinox 2wd & Awd '18-'26
|-
|Y||Chevy Silverado 1500 4wd ('19-'21), Silverado LTD 1500 4wd ('22), Silverado HD 2500/3500 4wd ('20-'24)
|-
|Z||Cadillac XT4 2wd & Awd '19-'25, Buick Envision 2wd '21-'23, Buick Envision Awd '21-'26
|-
|1||GMC Sierra 2wd ('11-'18), Sierra Limited 1500 2wd ('19), Sierra HD 2500/3500 2wd ('19), Yukon 2wd ('11-'26), Yukon XL 2wd ('11-'26)
|-
|1||GMC Canyon 2wd ('25-'26)
|-
|2||GMC Sierra 4wd ('11-'18), Sierra Limited 1500 4wd ('19), Sierra HD 2500/3500 4wd ('19), Yukon 4wd ('11-'26), Yukon XL 4wd ('11-'26)
|-
|2||GMC Canyon 4wd ('25-'26)
|-
|3||Cadillac Escalade 2wd ('11-'24), Escalade ESV 2wd ('11-'24)
|-
|3||Cadillac Optiq EV ('25-), Cadillac Vistiq EV ('26-)
|-
|4||Cadillac Escalade 4wd ('11-'24), Escalade ESV 4wd ('11-'24), Escalade EXT 4wd ('11-'13)
|-
|5||GMC Canyon 2wd ('11-'12, '15-'24)
|-
|5||Chevy Tahoe 2wd ('25-'26), Suburban 2wd ('25-'26)
|-
|6||GMC Canyon 4wd ('11-'12, '15-'24)
|-
|6||Chevy Tahoe 4wd ('25-'26), Suburban 4wd ('25-'26)
|-
|7||GMC Savana 2wd ('11-'26)
|-
|8||GMC Savana 4wd ('11-'14)
|-
|8||GMC Sierra 1500 2wd ('19-'21), Sierra Limited 1500 2wd ('22), Sierra HD 2500/3500 2wd ('20-'24)
|-
|8||Cadillac Escalade 2wd ('25-'26), Escalade ESV 2wd ('25-'26)
|-
|9||GMC Sierra 1500 4wd ('19-'21), Sierra Limited 1500 4wd ('22), Sierra HD 2500/3500 4wd ('20-'24)
|-
|9||Cadillac Escalade 4wd ('25-'26), Escalade ESV 4wd ('25-'26)
|-
|0||GMC Hummer EV pickup ('22-'25), GMC Hummer EV SUV ('24-'25), Chevy Silverado EV ('24-'26), GMC Sierra EV ('24-'25)
|}
====Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A (following L)||Saturn Vue XE 2wd ('10)
|-
|E (following L)||Saturn Vue XR V6 2wd ('10)
|-
|K (following L)||Saturn Vue XR-L V6 2wd ('10)
|-
|T (following R)||Saturn Outlook XE 2wd ('10)
|-
|U (following R)||Saturn Outlook XE Premium 2wd ('10)
|-
|V (following R)||Saturn Outlook XR-L 2wd ('10)
|-
|W (following R)||Saturn Outlook XR-L Premium 2wd ('10)
|-
|T (following V)||Saturn Outlook XE Awd ('10)
|-
|U (following V)||Saturn Outlook XE Premium Awd ('10)
|-
|V (following V)||Saturn Outlook XR-L Awd ('10)
|-
|W (following V)||Saturn Outlook XR-L Premium Awd ('10)
|-
|G (following N)||Hummer H3, H3T Base model ('10)
|-
|H (following N)||Hummer H3, H3T Adventure ('10)
|-
|J (following N)||Hummer H3, H3T Luxury ('10)
|-
|K (following N)||Hummer H3, H3T Alpha w/cloth ('10)
|-
|L (following N)||Hummer H3, H3T Alpha w/Leather ('10)
|-
|P (following N)||Saab 9-4X 3.0i 2wd ('11)
|-
|R (following N)||Saab 9-4X 3.0i Awd ('11)
|-
|S (following N)||Saab 9-4X 3.0i Premium 2wd ('11)
|-
|T (following N)||Saab 9-4X 3.0i Premium Awd ('11)
|-
|U (following N)||Saab 9-4X Aero Awd ('11)
|}
===Platform & Series Codes 1985- Passenger Car===
GM used a lettered system of automobile platform codes for three decades. These letters were used as the 4th position of the VIN. Though today's GM platforms use Greek characters, they are still encoded with Latin characters in the 4th position. Position 5 encodes the specific model and trim level of the vehicle.
{| border=1 style="margin:auto;"
!List of GM platforms
!Platform<br>Code
!Series<br>Code
!:Category:General Motors vehicles|Model
|-
|rowspan=14|GM A platform
|rowspan=14|A||W||Chevrolet Celebrity 1985-1990
|-
|E||Pontiac 6000 ''SE'' 1986-1988
|-
|F||Pontiac 6000 1985-1988, 6000 ''LE'' 1989-1991
|-
|G||Pontiac 6000 ''LE'' 1985-1988
|-
|H||Pontiac 6000 ''STE'' 1985-1989
|-
|J||Pontiac 6000 ''SE'' 1989-1991
|-
|G||Oldsmobile Cutlass Ciera ''S'' Sedan 1993-1994
|-
|J||Oldsmobile Cutlass Ciera ''LS'' 1985, Cutlass Ciera 1986-1989 & Cutlass Cruiser 1985-1989,<br /> Cutlass Ciera ''S'' Coupe 1986-1987, Cutlass Ciera ''S'' 1990-1991 & Cutlass Cruiser ''S'' 1990-1994, Cutlass Ciera ''SL'' & Cutlass Cruiser ''SL'' 1995, Ciera ''SL'' sedan & wagon 1996
|-
|L||Oldsmobile Cutlass Ciera 1990-1991, Cutlass Ciera ''S'' Sedan 1992
|-
|M||Oldsmobile Cutlass Ciera ''Brougham'' 1985-1988, Cutlass Ciera ''SL'' Coupe 1986-1989, Cutlass Ciera ''SL'' Sedan 1989-1993, Cutlass Cruiser ''Brougham'' 1987-1988, Cutlass Cruiser ''SL'' 1989-1993
|-
|S||Oldsmobile Cutlass Ciera ''International Series'' 1988-1990
|-
|G||Buick Century ''T-Type'' 1985-1986, Century ''Special'' 1991-1996
|-
|H||Buick Century ''Custom'' 1985-1995
|-
|L||Buick Century ''Limited'' 1985-1993, Century Estate Wagon 1986-1989
|-
|rowspan=14|GM B platform
|rowspan=14|B||L||Chevrolet Impala 1985, Caprice 1986-1992, Caprice Classic 1993-1996, Impala SS 1995-96
|-
|N||Chevrolet Caprice Classic 1985-1992, Caprice Classic LS 1993-1994,<br /> Caprice Classic LTZ 1991-1993, Impala SS 1994
|-
|U||Chevrolet Caprice Classic Brougham/Brougham LS 1987-1990
|-
|L||Pontiac Parisienne 1985-1986, Safari Wagon 1987-1989
|-
|T||Pontiac Parisienne Brougham 1985-1986
|-
|N||Oldsmobile Delta 88 Royale 1985
|-
|P||Oldsmobile Custom Cruiser 1985-1992
|-
|V||Oldsmobile Delta 88 Royale Brougham LS 1985
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1985
|-
|N||Buick Le Sabre ''Custom'' 1985, Roadmaster sedan 1992-1996
|-
|P||Buick Le Sabre ''Limited'' 1985
|-
|R||Buick Le Sabre Estate Wagon 1985-1989, Estate Wagon 1990,<br /> Roadmaster Estate Wagon 1991-1996
|-
|T||Buick Roadmaster ''Limited'' sedan 1992-1996
|-
|V||Buick Electra Estate Wagon 1985-1989
|-
|rowspan=13|GM C platform - front-wheel drive
|rowspan=13|C
|V||Oldsmobile Touring Sedan 1988-1990, 98 Touring Sedan 1991-1993
|-
|W||Oldsmobile 98 Regency Brougham 1985-1990, 98 Regency Elite 1991-1996
|-
|X||Oldsmobile 98 Regency 1985-1990, 1992-1994
|-
|F||Buick Electra T-Type 1985-1990
|-
|U||Buick Electra Park Avenue Ultra 1989-1990, Park Avenue Ultra 1991-1996
|-
|W||Buick Electra Park Avenue 1985-1990, Park Avenue 1991-1996
|-
|X||Buick Electra 1985-1986, Electra Limited 1987-1990
|-
|B||1985-1992 Cadillac Fleetwood, Fleetwood D'Elegance, 1993 Cadillac Sixty Special
|-
|D||1985-1993 Cadillac DeVille
|-
|G||1991-1992 Cadillac Fleetwood Sixty Special
|-
|H||1985-1987 Cadillac Fleetwood Limousine
|-
|S||1987-1990 Cadillac Fleetwood Sixty Special
|-
|T||1991-1993 Cadillac DeVille Touring Sedan
|-
|rowspan=3|GM G platform (models formerly on C platform)
|rowspan=3|C
|-
|U||Buick Park Avenue Ultra 1997-2005
|-
|W||Buick Park Avenue 1997-2005
|-
|rowspan=2|GM D platform
|rowspan=2|D||W||1985-1986 Cadillac Fleetwood Brougham, 1987-1992 Cadillac Brougham
|-
|W||1993-1996 Cadillac Fleetwood
|-
|rowspan=31|GM Delta I platform
|rowspan=31|A
|-
|A||Chevrolet Cobalt LS w/manual trans. 2010
|-
|B||Chevrolet Cobalt LS w/automatic trans. 2010
|-
|C||Chevrolet Cobalt 1LT w/manual trans. 2010
|-
|D||Chevrolet Cobalt 1LT w/automatic trans. 2010
|-
|E||Chevrolet Cobalt 2LT w/manual trans. 2010
|-
|F||Chevrolet Cobalt 2LT w/automatic trans. 2010
|-
|G||Chevrolet Cobalt SS Turbo 2010
|-
|H||Chevrolet Cobalt (base model w/XFE) 2010
|-
|K||Chevrolet Cobalt (base model) 2005, Cobalt LS 2006-2008, Cobalt LS w/man. trans. 2009
|-
|L||Chevrolet Cobalt LS 2005, Cobalt LT 2006-2008, Cobalt LT w/manual trans. 2009
|-
|M||Chevrolet Cobalt SS 2006-2007, Cobalt Sport 2008
|-
|P||Chevrolet Cobalt SS Supercharged 2005-2007, SS Turbo 2008-2009
|-
|S||Chevrolet Cobalt LS w/automatic trans. 2009
|-
|T||Chevrolet Cobalt LT w/automatic trans. 2009
|-
|Z||Chevrolet Cobalt LT 2005, Cobalt LTZ 2006-2007
|-
|L||Pontiac G5 2007-2008, G5 w/manual trans. 2009
|-
|N||Pontiac G5 GT 2007-2008, G5 GT w/manual trans. 2009
|-
|S||Pontiac G5 w/automatic trans. 2009
|-
|T||Pontiac G5 GT w/automatic trans. 2009
|-
|F||Saturn Ion sedan Level 1 w/manual trans. 2003-2005
|-
|G||Saturn Ion sedan Level 1 w/automatic trans. 2003-2005
|-
|J||Saturn Ion sedan Level 2 w/automatic trans. 2003-2007
|-
|K||Saturn Ion sedan Level 3 w/manual trans. 2003-2007
|-
|L||Saturn Ion sedan Level 3 w/automatic trans. 2003-2007
|-
|M||Saturn Ion coupe Level 2 w/manual trans. 2003-2007
|-
|N||Saturn Ion coupe Level 2 w/automatic trans. 2003-2007
|-
|V||Saturn Ion coupe Level 3 w/manual trans. 2003-2007
|-
|W||Saturn Ion coupe Level 3 w/automatic trans. 2003-2007
|-
|Y||Saturn Ion coupe Red Line 2004-2007
|-
|Z||Saturn Ion sedan Level 2 w/manual trans. 2003-2007
|-
|rowspan=9|GM E platform
|rowspan=9|E
|-
|V||Oldsmobile Toronado Trofeo 1988-1992
|-
|Z||Oldsmobile Toronado Brougham 1985-1986, Toronado 1987-1992
|-
|C||Buick Reatta 1988-1991
|-
|Y||Buick Riviera T-Type 1985-1986
|-
|Z||Buick Riviera 1985-1993
|-
|C||Cadillac Eldorado Collector Series 2002
|-
|L||Cadillac Eldorado 1985-2002
|-
|T||Cadillac Eldorado Touring Coupe 1994-2002
|-
|rowspan=26|GM Epsilon I platform
|rowspan=26|Z||A||Chevrolet Malibu Fleet 2010-2012
|-
|B||Chevrolet Malibu LS 2010-2012
|-
|C||Chevrolet Malibu 1LT 2010-2012
|-
|D||Chevrolet Malibu 2LT 2010-2012
|-
|E||Chevrolet Malibu LTZ 2010-2011, Malibu 1LZ 2012
|-
|F||Chevrolet Malibu Hybrid 2008-2010, Malibu 3LT 2012
|-
|G||Chevrolet Malibu LS 2008-2009, Malibu 2LZ 2012
|-
|H||Chevrolet Malibu 1LT 2008-2009
|-
|J||Chevrolet Malibu 2LT 2008-2009
|-
|K||Chevrolet Malibu LTZ 2008-2009
|-
|S||Chevrolet Malibu 2004-2005, Malibu LS 2006-2007, Malibu Classic LS 2008
|-
|T||Chevrolet Malibu LS 2004-2005, Malibu LT 2006-2007, Malibu Classic LT 2008
|-
|U||Chevrolet Malibu LT 2004-2005, Malibu LTZ 2006-2007
|-
|W||Chevrolet Malibu SS 2006-2007
|-
|A||Pontiac G6 Sedan 2010
|-
|F||Pontiac G6 2.4L Sedan (Base model) 2006, G6 Value Leader (Base model w/1SV) 2007-2008
|-
|G||Pontiac G6 3.5L Sedan (Base model) 2005-2006, G6 (Base model) 2007-2009
|-
|H||Pontiac G6 GT 2005-2009
|-
|J||Pontiac G6 (Base model) 2009 1/2 (Mid-Cycle Revision)
|-
|K||Pontiac G6 GT 2009 1/2 (Mid-Cycle Revision)
|-
|L||Pontiac G6 GXP 2009 1/2 (Mid-Cycle Revision)
|-
|M||Pontiac G6 GTP 2006-2007, G6 GXP 2008-2009
|-
|R||Saturn Aura Green Line 2007-2009
|-
|S||Saturn Aura XE 2007-2009
|-
|V||Saturn Aura XR 2007-2008, Aura XR 2.4L 2009
|-
|X||Saturn Aura XR V6 2009
|-
|rowspan=6|GM F platform
|rowspan=6|F||P||Chevrolet Camaro Sport Coupe 1985-2002, Convertible 1987-1992, 1994-2002
|-
|S||Chevrolet Camaro Berlinetta 1985-1986
|-
|S||Pontiac Firebird 1985-2002, Firebird ''Formula'' 1987-1992
|-
|V||Pontiac Firebird ''Formula / Trans Am'' 1993-2002, Firebird ''Trans Am GT'' 1994
|-
|W||Pontiac Firebird ''Trans Am'' 1985-1992, Firebird ''Trans Am GTA'' 1987-1992
|-
|X||Pontiac Firebird ''S/E'' 1985-1986
|-
|rowspan=13|GM G platform - rear-wheel drive
|rowspan=13|G||Z||Chevrolet Monte Carlo 1985-1988
|-
|J||Pontiac Grand Prix 1985-1987
|-
|K||Pontiac Grand Prix LE 1985-1987
|-
|N||Pontiac Bonneville 1985-1986
|-
|P||Pontiac Grand Prix Brougham 1985-1987
|-
|R||Pontiac Bonneville Brougham 1985-1986
|-
|S||Pontiac Bonneville LE 1985-1986
|-
|K||Oldsmobile Cutlass Salon coupe 1985-1987
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1985-1987,<br /> Cutlass Supreme Classic ''Brougham'' 1988
|-
|R||Oldsmobile Cutlass Supreme 1985-1987, Cutlass Supreme Classic 1988
|-
|J||Buick Regal 1985-1987
|-
|K||Buick Regal T-Type 1985-1987
|-
|M||Buick Regal ''Limited'' 1985-1987
|-
|rowspan=4|GM G platform - front-wheel drive
|rowspan=4|G||D||1995-1999 Buick Riviera
|-
|R||1995-1999 Oldsmobile Aurora
|-
|R||2001-2002 Oldsmobile Aurora 3.5
|-
|S||2001-2003 Oldsmobile Aurora 4.0
|-
|rowspan=9|GM H platform
|rowspan=9|H||H||Buick Le Sabre 1987
|-
|P||Buick Le Sabre ''Custom'' 1986-1999
|-
|R||Buick Le Sabre ''Limited'' 1986-1999
|-
|C||Oldsmobile Regency 1997-1998, Eighty Eight 50th Anniversary Edition 1999
|-
|N||Oldsmobile Delta 88 Royale 1986-1988, 88 Royale 1989-1995, Eighty Eight & Eighty Eight LS 1996-99
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1986-1988, 88 Royale Brougham 1989-91, Eighty Eight Royale LS 1992-1995, LSS 1996-1999
|-
|X||Pontiac Bonneville 1987, Bonneville LE 1988-1991, Bonneville ''SE'' 1992-1999
|-
|Y||Pontiac Bonneville SSE 1988-1991, Bonneville ''SSEi'' 1992-1993
|-
|Z||Pontiac Bonneville LE 1987, Bonneville SE 1988-1991, Bonneville ''SSE'' 1992-1999, Bonneville ''SSEi'' 1994-1999
|-
|rowspan=17|GM G platform (models formerly on H platform or their successors)
|rowspan=17|H||A||Buick Lucerne ''CX'' 2010-2011
|-
|B||Buick Lucerne ''CX-2'' 2010
|-
|C||Buick Lucerne ''CXL'' 2010-2011
|-
|D||Buick Lucerne ''CXL V6'' 2006-2009, Lucerne ''CXL Special Edition'' 2010
|-
|E||Buick Lucerne ''CXS'' 2006-2008, Lucerne ''CXL-3'' 2010
|-
|F||Buick Lucerne ''Super'' 2008-2009, Lucerne ''CXL-4'' 2010
|-
|G||Buick Lucerne ''CXL-5'' 2010
|-
|H||Buick Lucerne ''Super 1SP'' 2010
|-
|J||Buick Lucerne ''CXL Premium'' 2010-2011
|-
|K||Buick Lucerne ''Super 1XS'' 2010, Lucerne ''Super'' 2011
|-
|P||Buick Lucerne ''CX'' 2006-2009
|-
|R||Buick Lucerne ''CXL V8'' 2006-2007, Lucerne ''CXL Special Edition V8'' 2008
|-
|P||Buick Le Sabre ''Custom'' 2000-2005
|-
|R||Buick Le Sabre ''Limited'' 2000-2005
|-
|X||Pontiac Bonneville ''SE'' 2000-2005
|-
|Y||Pontiac Bonneville ''SLE'' 2000-2005
|-
|Z||Pontiac Bonneville ''SSEi'' 2000-2003, Bonneville GXP 2004-2005
|-
|rowspan=23|GM J platform
|rowspan=23|J
|-
|C||Chevrolet Cavalier 1985-1994, RS Convertible 1991-1994
|-
|D||Chevrolet Cavalier CS 1985-1987
|-
|E||Chevrolet Cavalier Type 10 1985, RS 1986-1988,<br /> Type 10 Convertible 1985, RS Convertible 1986-1987
|-
|F||Chevrolet Cavalier Z24 1986-1994, Z24 Convertible 1988-1989, 1992-1994
|-
|C||Chevrolet Cavalier 1995-2005, Cavalier RS 1997-1999
|-
|F||Chevrolet Cavalier LS Sedan 1995-2005, LS Coupe 2003-2005, Z24 Coupe 1995-2001,<br /> LS Convertible 1995-1997, Z24 Convertible 1998-2000
|-
|H||Chevrolet Cavalier Z24 Coupe/Sedan 2002, LS Sport 2002-2005
|-
|S||Chevrolet Cavalier LS Coupe 2002
|-
|B||Pontiac Sunbird 1985-1989, Sunbird LE 1990-1991, Sunbird SE 1992-1993,<br /> Sunbird LE 1994
|-
|C||Pontiac Sunbird LE 1985, Sunbird 1991, Sunbird LE 1992-1993
|-
|D||Pontiac Sunbird SE 1985-1991, Sunbird GT 1992-1993
|-
|L||Pontiac Sunbird SE 1994
|-
|U||Pontiac Sunbird GT 1986-1991
|-
|B||Pontiac Sunfire SE 1995-2002, Convertible 1995-2000, Sunfire 2003-2005
|-
|D||Pontiac Sunfire GT 1995-2002
|-
|C||Oldsmobile Firenza Base model 1985-1987, Firenza S 1985-1987, Firenza 1988
|-
|D||Oldsmobile Firenza LX 1985-1987, Firenza SX 1985, Firenza LC, GT 1986-1987
|-
|E||Buick Skyhawk T-Type 1985-1986
|-
|S||Buick Skyhawk Custom 1985-1987, Skyhawk Sport 1986-1987, Skyhawk 1988-1989
|-
|T||Buick Skyhawk Limited 1985-1987
|-
|G||Cadillac Cimarron 1985-1988
|-
|G, H||Toyota Cavalier (Japan only)
|-
|rowspan=8|GM2900 platform
|rowspan=8|J||C||Saturn L-Series|2004 Saturn L300.1
|-
|D||Saturn L-Series|2004 Saturn L300.2, 2005 Saturn L300
|-
|L||Saturn L-Series|2004 Saturn L300.3
|-
|R||Saturn L-Series|Saturn LS w/manual transmission '00/L100 w/manual transmission '01
|-
|S||Saturn L-Series|Saturn LS w/automatic transmission '00/L100 w/automatic transmission '01-'02
|-
|T||Saturn L-Series|Saturn LS1 w/manual transmission '00/L200 w/manual transmission '01-'03, LW200 w/manual trans. '02
|-
|U||Saturn L-Series|Saturn LS1 w/automatic transmission '00/L200 w/automatic transmission '01-'03,<br> Saturn LW1 w/automatic transmission '00/LW200 w/automatic transmission '01-'03
|-
|W||Saturn L-Series|Saturn LS2 '00, LW2 '00, L300 '01-'03, LW300 '01-'03
|-
|rowspan=5|GM K platform
|rowspan=5|K||D||Cadillac Deville 1994-1999
|-
|E||Cadillac Deville D'Elegance 1997-1999
|-
|F||Cadillac Deville Concours 1994-1999
|-
|S||Cadillac Seville 1985-1993 / Cadillac Seville SLS 1994-1997
|-
|Y||Cadillac Seville Touring Sedan / Cadillac Seville STS 1990-1997
|-
|rowspan=9|GM G platform (models formerly on K platform)
|rowspan=9|K||A||2010-2011 Cadillac DTS
|-
|D||2000-2005 Cadillac Deville, 2006-2009 Cadillac DTS, 2010-2011 DTS Luxury
|-
|E||2000-2005 Cadillac Deville DHS
|-
|F||2000-2005 Cadillac Deville DTS
|-
|H||2010-2011 Cadillac DTS Premium
|-
|P||2010-2011 Cadillac DTS Platinum
|-
|R||2010-2011 Cadillac DTS Livery
|-
|S|| 1998-2004 Cadillac Seville SLS
|-
|Y|| 1998-2003 Cadillac Seville STS
|-
|rowspan=33|GM Kappa platform
|rowspan=33|M||A||Pontiac Solstice w/automatic transmission 2010
|-
|B||Pontiac Solstice 2006-2007, Solstice w/manual transmission 2008-2009
|-
|B||Pontiac Solstice GXP w/automatic transmission 2010
|-
|C||Pontiac Solstice w/automatic transmission 2008
|-
|D||Pontiac Solstice w/manual transmission 2010
|-
|E||Pontiac Solstice GXP w/manual transmission 2010
|-
|F||Pontiac Solstice GXP w/automatic transmission 2008
|-
|G||Pontiac Solstice GXP 2007, Solstice GXP w/manual transmission 2008-2009
|-
|K||Pontiac Solstice Street Edition w/manual transmission 2009
|-
|N||Pontiac Solstice w/automatic transmission 2009
|-
|S||Pontiac Solstice SCCA SSB Championship Edition (2.4L) 2008
|-
|T||Pontiac Solstice SCCA T2 Championship Edition (2.0L Turbo) 2008
|-
|T||Pontiac Solstice GXP w/automatic transmission 2009
|-
|Z||Pontiac Solstice Street Edition w/automatic transmission 2009
|-
|B||Saturn Sky 2007, Sky w/manual transmission 2008-2009
|-
|B||Saturn Sky Redline w/automatic transmission 2010
|-
|C||Saturn Sky w/automatic transmission 2008
|-
|C||Saturn Sky Ruby Red (Merlot Jewel) Special Edition w/manual transmission 2009
|-
|C||Saturn Sky Preferred w/automatic transmission 2010
|-
|D||Saturn Sky Hydro Blue Special Edition w/manual transmission 2009
|-
|E||Saturn Sky Redline w/manual transmission 2010
|-
|F||Saturn Sky Redline w/automatic transmission 2008
|-
|F||Saturn Sky Preferred w/manual transmission 2010
|-
|G||Saturn Sky Redline 2007, Sky Redline w/manual transmission 2008-2009
|-
|H||Saturn Sky Redline Ruby Red (Merlot Jewel) Special Edition w/manual transmission 2009
|-
|L||Saturn Sky Redline Hydro Blue Special Edition w/manual transmission 2009
|-
|N||Saturn Sky w/automatic transmission 2009
|-
|P||Saturn Sky Ruby Red (Merlot Jewel) Special Edition w/automatic transmission 2009
|-
|R||Saturn Sky Hydro Blue Special Edition w/automatic transmission 2009
|-
|T||Saturn Sky Redline w/automatic transmission 2009
|-
|V||Saturn Sky Redline Ruby Red (Merlot Jewel) Special Edition w/automatic transmission 2009
|-
|X||Saturn Sky Redline Hydro Blue Special Edition w/automatic transmission 2009
|-
|G||Opel GT 2007-2010, Daewoo G2X 2007-2009
|-
|rowspan=8|GM L platform
|rowspan=8|L
|-
|D||Chevrolet Corsica ''Base'' 1994-1996
|-
|T||Chevrolet Corsica ''Base'' 1987-1989, Corsica ''LT'' 1990-1993
|-
|V||Chevrolet Beretta ''Base'' 1987-1996
|-
|W||Chevrolet Beretta "GT" 1989-1993 (RPO Z21) & Beretta ''Z26'' 1994-1996 (RPO Z04)
|-
|Z||Chevrolet Corsica ''LTZ'' 1989-1990 (RPO Z54)
|-
|Z||Chevrolet Beretta "GTZ" 1990-1993 (RPO Z04)
|-
|T||Pontiac Tempest (Canada only)
|-
|rowspan=5|GM M platform
|rowspan=5|M||R||Chevrolet Sprint
|-
|R||Geo Metro LSi, Metro
|-
|R||Pontiac Firefly (Canada only)
|-
|S||Chevrolet Sprint ER
|-
|S||Geo Metro, Metro XFi
|-
|rowspan=32|GM N platform
|rowspan=32|N
|-
|B||Oldsmobile Cutlass 1997, Cutlass ''GL'' 1998-1999
|-
|C||Buick Skylark 4-door ''Custom'' 1987-1991
|-
|D||Buick Skylark 4-door ''Limited'' 1987-1989, Skylark 4-door ''Luxury Edition'' 1990-1991
|-
|D||Chevrolet Malibu 1997-2003, Chevrolet Classic 2004-2005
|-
|E||Chevrolet Malibu ''LS'' 1997-2003
|-
|E||Pontiac Grand Am 1985-1988, Grand Am ''LE'' 1989-1991
|-
|E||Pontiac Grand Am ''SE'' 1992-2005
|-
|F||Oldsmobile Calais 1985-1987, Cutlass Calais 1988, Cutlass Calais ''S'' 1989-1991
|-
|F||Oldsmobile Achieva ''SL'' 1992-1994, Achieva ''SC'' 1994
|-
|F||Oldsmobile Alero ''GLS'' 1999-2004
|-
|F||Pontiac Grand Am ''SE1'' 2000-2004
|-
|G||Oldsmobile Cutlass ''GLS'' 1997-1999
|-
|G||Pontiac Grand Am 1991
|-
|G||Pontiac Grand Am ''SE2'' 2000, 2003-2004
|-
|J||Buick Somerset Regal 1985, Somerset ''Custom'' 1986-1987, Skylark 2-door ''Custom'' 1988-91, Skylark 4-door ''Custom'' 1986
|-
|J||Buick Skylark 1992, Skylark ''Limited'' 1993-1994, Skylark ''Custom'' 1996-1998,<br /> Skylark ''Limited'' & ''Gran Sport'' 1996-1997
|-
|K||Buick Somerset ''T-Type'' 1986
|-
|K||Oldsmobile Cutlass Calais ''International Series'' 1988-1991
|-
|K||Oldsmobile Alero ''GX'' 1999-2004
|-
|L||Oldsmobile Cutlass Calais 1989-1991
|-
|L||Oldsmobile Achieva ''S'' 1992-1995, Achieva ''SL'' 1996-1998, Achieva ''SC'' 1996-1997
|-
|L||Oldsmobile Alero ''GL'' 1999-2004
|-
|M||Buick Somerset Regal ''Limited'' 1985, Somerset ''Limited'' 1986-'87, Skylark 2-door ''Limited'' '88-'89, Skylark 2-door ''Gran Sport'' 1990-1991, Skylark 4-door ''Limited'' 1986
|-
|M||Buick Skylark ''Gran Sport'' 1992-1994
|-
|T||Oldsmobile Calais ''Supreme'' 1985-1987, Cutlass Calais ''SL'' 1988-1991
|-
|V||Buick Skylark 1990-1991
|-
|V||Buick Skylark ''Custom'' 1993-1995, ''Limited'' 1995, ''Gran Sport'' 1995
|-
|V||Pontiac Grand Am ''LE'' 1985-1988
|-
|V||Pontiac Grand Am ''GT1'' 2000-2005
|-
|W||Pontiac Grand Am ''SE'' 1986-1991
|-
|W||Pontiac Grand Am ''GT'' 1992-2005
|-
|rowspan=5|GM P platform - rear-wheel drive
|rowspan=5|P
|-
||E||Pontiac Fiero ''Coupe'' 1985-1988
|-
||F||Pontiac Fiero ''SE'' 1985-1987
|-
||G||Pontiac Fiero ''GT'' 1985-1988
|-
||M||Pontiac Fiero ''Sport coupe'' 1985-1987
|-
|rowspan=1|GM P platform - front-wheel drive
|rowspan=1|P||X||General Motors EV1 1997, 1999
|-
|rowspan=6|GM R platform
|rowspan=6|R
|-
||F||1985-1986 Chevrolet Spectrum
|-
||F||1987-1988 Chevrolet Spectrum 3-door hatchback, 1989 Geo Spectrum 3-door hatchback
|-
||F||1990-1993 Geo Storm
|-
||G||1987-1988 Chevrolet Spectrum 4-door sedan, 1989 Geo Spectrum 4-door sedan
|-
||T||1990-1993 Geo Storm GSi
|-
|rowspan=8|GM S platform
|rowspan=8|S||K||1985-1988 Chevrolet Nova
|-
|K||1989-1997 Geo Prizm, 1998-2002 Chevrolet Prizm
|-
|L||1988 Chevrolet Nova Twin Cam, 1990-1992 Geo Prizm GSi
|-
|L||2003-2008 Pontiac Vibe, 2009-2010 Pontiac Vibe FWD w/manual transmission
|-
|M||2003-2006 Pontiac Vibe ''AWD'', 2009-2010 Pontiac Vibe AWD w/automatic transmission
|-
|N||2003-2006 Pontiac Vibe ''GT'', 2009-2010 Pontiac Vibe GT FWD w/manual transmission
|-
|P||2009-2010 Pontiac Vibe FWD w/automatic transmission
|-
|R||2009-2010 Pontiac Vibe GT FWD w/automatic transmission
|-
|rowspan=32|GM Sigma platform
|rowspan=32|D||A||Cadillac CTS Base model RWD 2010-2013, CTS Coupe Base model RWD 2014
|-
|B||Cadillac CTS Wagon Luxury Collection RWD 2014
|-
|C||Cadillac CTS Base model AWD 2010-2013, CTS Coupe/Wagon Performance Collection RWD 2014
|-
|D||Cadillac CTS Coupe/Wagon Premium Collection RWD 2014
|-
|E||Cadillac CTS Luxury Collection RWD 2010-2013, CTS Coupe Base model AWD 2014
|-
|F||Cadillac CTS Auto. Trans. RWD 2008-2009, CTS Luxury Collection RWD w/Navigation 2010-2013, CTS Wagon Luxury Collection AWD 2014
|-
|G||Cadillac CTS Auto. Trans. AWD 2008-2009, CTS Luxury Collection AWD 2010-2013, CTS Coupe/Wagon Performance Collection AWD 2014
|-
|H||Cadillac CTS Auto. Trans. AWD w/Navigation 2008-2009, CTS Luxury Collection AWD w/Navigation 2010-2013, CTS Coupe/Wagon Premium Collection AWD 2014
|-
|J||Cadillac CTS Auto. Trans. RWD w/Navigation 2008-2009, CTS Performance Collection RWD 2010-2013
|-
|K||Cadillac CTS Performance Collection RWD w/Navigation 2010-2013
|-
|L||Cadillac CTS Performance Collection AWD 2010-2013
|-
|M||Cadillac CTS V6 2003-2004, CTS 2.8L 2005-2007, CTS Man. Trans. RWD 2008-2009, CTS Performance Collection AWD w/Navigation 2010-2013
|-
|N||Cadillac CTS V-Series 2004-2007, 2009
|-
|P||Cadillac CTS 3.6L 2005-2007, CTS Direct Inj. V6 Man. Trans. RWD 2008-2009, CTS Premium Collection RWD w/Navigation 2010-2013
|-
|R||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD 2008
|-
|S||Cadillac CTS Direct Inj. V6 Auto. Trans. AWD 2008-2009, CTS Premium Collection AWD w/Navigation 2010-2013
|-
|T||Cadillac CTS Direct Inj. V6 Auto. Trans. AWD w/Navigation 2008-2009
|-
|U||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD 2009
|-
|V||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD w/Navigation 2008-2009, CTS sedan V-Series 2010-2014, CTS Wagon V-Series 2011-2014, CTS Coupe V-Series 2011-2015
|-
|0||Cadillac CTS Sport Appearance Pkg. 2010
|-
|1||Cadillac CTS Eco Luxury Pkg. 2010
|-
|2||Cadillac CTS Sport Appearance Pkg. 2011
|-
|A||Cadillac STS V6 AWD 2008-2009
|-
|B||Cadillac STS V8 AWD 2008-2009
|-
|C||Cadillac STS V8 2005-2007, STS V8 RWD 2008-2009
|-
|D||Cadillac STS V6 AWD w/Navigation 2008-2009
|-
|K||Cadillac STS V6 RWD w/Navigation 2008-2009
|-
|L||Cadillac STS V8 AWD w/Navigation 2008-2009
|-
|U||Cadillac STS (all models) 2010, STS (Base model) 2011
|-
|W||Cadillac STS V6 2005-2007, STS V6 RWD 2008-2009, STS Luxury 2011
|-
|X||Cadillac STS V-Series 2006-2009, STS Luxury Performance 2011
|-
|Z||Cadillac STS V8 RWD w/Navigation 2008-2009
|-
|rowspan=4|GM T platform - rear-wheel drive
|rowspan=4|T||B|| 1985-1987 Chevrolet Chevette CS
|-
|B||1985-1987 Pontiac Acadian (Canada only)
|-
|J||1985 Pontiac Acadian Scooter (Canada only)
|-
|L||1985-1987 Pontiac 1000
|-
|rowspan=4|GM T platform - front-wheel drive
|rowspan=4|T||N|| Pontiac LeMans 1988, LeMans LE 1989-1991, LeMans SE 1992-1993
|-
|R||1988-1989 Pontiac LeMans SE sedan
|-
|S||1988-1990 Pontiac LeMans GSE AeroCoupe
|-
|X||1988-1993 Pontiac LeMans VL AeroCoupe
|-
|rowspan=3|GM T platform - front-wheel drive
|rowspan=3|A
|-
|R||Saturn Astra XE (US: 2008, Canada: 2008-2009)
|-
|T||Saturn Astra XR (US: 2008, Canada: 2008-2009)
|-
|rowspan=4|Daewoo T200 platform
|rowspan=4|T||D||Chevrolet Aveo Special Value 2004-2008, Base model 2004, LS 2005-2011, Aveo 1LT 2009-2011
|-
|G||Chevrolet Aveo LT 2005-2008, Aveo 2LT 2009-2011
|-
|J||Chevrolet Aveo LS 2004
|-
|D||Pontiac G3 2009
|-
|rowspan=2|GM V platform - front-wheel drive
|rowspan=2|V||R||1987-1992 Cadillac Allanté with standard removable hardtop
|-
|S||1990-1993 Cadillac Allanté
|-
|rowspan=2|GM V platform - rear-wheel drive
|rowspan=2|V||R||1997-2001 Cadillac Catera
|-
|X||2004-2006 Pontiac GTO coupe
|-
|rowspan=49|GM W platform
|rowspan=49|W
|-
|A||Chevrolet Impala ''LS'' 2010-2013, Impala Limited ''LS'' 2014-2016
|-
|B||Chevrolet Impala ''LS'' 2006-2009, Impala ''LT'' 2010-2013, Impala Limited ''LT'' 2014-2016
|-
|C||Chevrolet Impala ''LT'' 3.9L 2006-2009, Impala ''LTZ'' 2010-2013, Impala Limited ''LTZ'' 2014-2016
|-
|D||Chevrolet Impala ''SS'' 2006-2009, Impala ''Police'' 2010-2013, Impala Limited ''Police'' 2014-2016
|-
|E||Chevrolet Impala ''Taxi'' 2010-2012
|-
|F||Chevrolet Impala 2000-2005, Impala ''LS'' Fleet (1FL) 2011-2013
|-
|G||Chevrolet Impala ''LT'' Fleet (2FL) 2011-2013
|-
|H||Chevrolet Impala ''LS'' 2000-2005
|-
|J||Chevrolet Monte Carlo ''LS'' 2006-2007
|-
|K||Chevrolet Monte Carlo ''LT'' 3.9L 2006, Monte Carlo ''LT'' 3.5L 2007
|-
|L||Chevrolet Lumina 1990-2001, Lumina ''LS'' 1997-1999
|-
|L||Chevrolet Monte Carlo ''SS'' 2006-2007
|-
|M||Chevrolet Monte Carlo ''LT'' 3.5L 2006
|-
|N||Chevrolet Lumina ''Euro'' 1990-1994, Lumina ''LS'' 1995-1996, Lumina ''LTZ'' 1997-1999
|-
|N||Chevrolet Monte Carlo ''LTZ'' 2006
|-
|P||Chevrolet Lumina ''Z34'' 1991-1994, Impala ''SS'' 2004-2005
|-
|S||Chevrolet Impala ''Police'' 2006-2009
|-
|T||Chevrolet Impala ''LT'' 3.5L 2006-2009
|-
|U||Chevrolet Impala ''LTZ'' 2006-2009
|-
|V||Chevrolet Impala ''50th Anniversary Edition'' 2008
|-
|W||Chevrolet Monte Carlo ''LS'' 1995-2005
|-
|X||Chevrolet Monte Carlo ''Z34'' 1995-1999, Monte Carlo ''SS'' 2000-2004, Monte Carlo ''LT'' 2005
|-
|Z||Chevrolet Monte Carlo ''SS Supercharged'' 2004-2005
|-
|C||Pontiac Grand Prix ''GXP'' 2005-2008
|-
|H||Pontiac Grand Prix ''LE'' 1991-1993
|-
|J||Pontiac Grand Prix 1988-1989, Grand Prix ''LE'' 1990, Grand Prix ''SE'' 1991-2000
|-
|K||Pontiac Grand Prix ''LE'' 1988-1989, Grand Prix ''SE1'' 2000-2003
|-
|P||Pontiac Grand Prix ''SE'' 1988-1990, Grand Prix ''GT'' 1991-1993, 1997-2003,<br /> Grand Prix ''GT1'' 2004, Grand Prix 2005-2008
|-
|R||Pontiac Grand Prix ''GTP'' 1999-2005, Grand Prix ''GT'' 2006-2007
|-
|S||Pontiac Grand Prix ''GT2'' 2004, Grand Prix ''GT'' 2005
|-
|T||Pontiac Grand Prix ''STE'' 1990-1993
|-
|H||Oldsmobile Cutlass Supreme 1988-1991, Cutlass Supreme ''S'' 1992-1994,<br /> Cutlass Supreme ''SL'' 1995-1997, Intrigue 1998, Intrigue ''GX'' 1999-2002
|-
|R||Oldsmobile Cutlass Supreme ''International Series'' 1988-1993
|-
|S||Oldsmobile Cutlass Supreme ''SL'' 1988-1991, Intrigue ''GL'' 1998-2002
|-
|T||Oldsmobile Cutlass Supreme Convertible 1990-1995
|-
|X||Oldsmobile Intrigue ''GLS'' 1998-2002
|-
|B||Buick Regal ''Custom'' 1988-1996, Regal ''GS'' Coupe 1995-1996, Regal ''LS'' 1997-2004
|-
|C||Buick Lacrosse ''CX'' 2005-2009
|-
|D||Buick Regal ''Limited'' 1988-1996, Lacrosse ''CXL'' 2005-2009
|-
|E||Buick Lacrosse ''CXS'' 2005-2008
|-
|F||Buick Regal ''GS'' Coupe 1992-1994, Regal ''GS'' Sedan 1992-2004
|-
|F||Buick Allure ''CX'' 2005-2009 (Canada only)
|-
|H||Buick Allure ''CXS'' 2005-2008 (Canada only)
|-
|J||Buick Allure ''CXL'' 2005-2009 (Canada only)
|-
|N||Buick Lacrosse ''Super'' 2008-2009
|-
|P||Buick Allure ''Super'' 2008-2009 (Canada only)
|-
|S||Buick Century ''Custom'' 1997-2005
|-
|Y||Buick Century ''Limited'' 1997-2002
|-
|rowspan=3|GM X platform
|rowspan=3|X||B||1985 Buick Skylark Custom
|-
|C||1985 Buick Skylark Limited
|-
|X||1985 Chevrolet Citation II
|-
|rowspan=39|GM Y platform
|rowspan=39|Y||V||2004-2009 Cadillac XLR
|-
|X||2006-2009 Cadillac XLR V-Series
|-
|Y||1985-2008 Chevrolet Corvette (all models except '90-'95 ZR-1)
|-
|Z||1990-1995 Chevrolet Corvette ZR-1
|-
|G||2009 Chevrolet Corvette GT1 Championship Edition (Base & Z06)
|-
|R||2009 Chevrolet Corvette ZR1 (after early production)
|-
|Y||2009 Chevrolet Corvette (Base model, Early production Z06, Early production ZR1)
|-
|Z||2009 Chevrolet Corvette Z06 (after early production)
|-
|A||2010-2013 Chevrolet Corvette Standard 1LT Man. Trans.
|-
|B||2010-2013 Chevrolet Corvette Preferred 2LT Man. Trans.
|-
|C||2010-2013 Chevrolet Corvette Premium 3LT Man. Trans.
|-
|D||2010-2013 Chevrolet Corvette Custom 4LT Man. Trans.
|-
|E||2010-2013 Chevrolet Corvette Standard 1LT Auto. Trans.
|-
|F||2010-2013 Chevrolet Corvette Preferred 2LT Auto. Trans.
|-
|G||2010-2013 Chevrolet Corvette Premium 3LT Auto. Trans.
|-
|H||2010-2013 Chevrolet Corvette Custom 4LT Auto. Trans.
|-
|J||2010-2013 Chevrolet Corvette Z06 Standard 1LZ Man. Trans.
|-
|K||2010-2013 Chevrolet Corvette Z06 Premium 2LZ Man. Trans.
|-
|L||2010-2013 Chevrolet Corvette Z06 Custom 3LZ Man. Trans.
|-
|M||2010-2013 Chevrolet Corvette ZR1 Standard 1ZR Man. Trans.
|-
|N||2010-2013 Chevrolet Corvette ZR1 Custom 3ZR Man. Trans.
|-
|P||2010-2013 Chevrolet Corvette Grand Sport Standard 1LT Man. Trans.
|-
|R||2010-2013 Chevrolet Corvette Grand Sport Preferred 2LT Man. Trans.
|-
|S||2010-2013 Chevrolet Corvette Grand Sport Premium 3LT Man. Trans.
|-
|T||2010-2013 Chevrolet Corvette Grand Sport Custom 4LT Man. Trans.
|-
|U||2010-2013 Chevrolet Corvette Grand Sport Standard 1LT Auto. Trans.
|-
|V||2010-2013 Chevrolet Corvette Grand Sport Preferred 2LT Auto. Trans.
|-
|W||2010-2013 Chevrolet Corvette Grand Sport Premium 3LT Auto. Trans.
|-
|X||2010-2013 Chevrolet Corvette Grand Sport Custom 4LT Auto. Trans.
|-
|Y||2013 Chevrolet Corvette 427 Convertible Collector Edition Premium 3LT Man. Trans.
|-
|Z||2013 Chevrolet Corvette 427 Convertible Collector Edition Custom 4LT Man. Trans.
|-
|1||2013 Chevrolet Corvette 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|2||2013 Chevrolet Corvette 60th Anniversary Edition Custom 4LT Auto. Trans.
|-
|3||2013 Chevrolet Corvette Grand Sport 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|4||2013 Chevrolet Corvette Grand Sport 60th Anniversary Edition Custom 4LT Auto. Trans.
|-
|5||2013 Chevrolet Corvette Z06 60th Anniversary Edition Custom 3LZ Man. Trans.
|-
|6||2013 Chevrolet Corvette ZR1 60th Anniversary Edition Custom 3ZR Man. Trans.
|-
|7||2013 Chevrolet Corvette 427 Convertible 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|8||2013 Chevrolet Corvette 427 Convertible Collector Edition Preferred 2LT Man. Trans.
|-
|rowspan=13|GM Z platform
|rowspan=13|Z
|-
|E||Saturn SC1 (manual transmission 2-Door) 1993-1999
|-
|F||Saturn SC1 (automatic transmission 2-Door) 1993-1999, SL (manual transmission) 1991-02
|-
|G||Saturn SC (manual transmission) 1991-1992, SC2 (manual transmission 2-Door) 1993-99,<br /> SL1 (manual transmission) 1991-2002, SW1 (manual transmission) 1993-1999
|-
|H||Saturn SC (automatic transmission) 1991-92, SC2 (automatic transmission 2-Door) '93-'99,<br /> SL1 (automatic transmission) 1991-02, SW1 (automatic transmission LHD) '93-'99
|-
|J||Saturn SL2 (manual transmission) 1991-2002, SW2 (manual transmission) 1993-2001
|-
|K||Saturn SL2 (automatic transmission) 1991-2002, SW2 (automatic transmission 1993-1999)
|-
|M||Saturn SW1 "Postal" [SWP] (automatic transmission RHD) 1999-2001 <br>(Made for US Postal Service rural route mail carriers)
|-
|N||Saturn SC1 (manual transmission 3-Door) 1999-2002, SW2 (automatic transmission 2000-01)
|-
|P||Saturn SC1 (automatic transmission 3-Door) 1999-2002
|-
|R||Saturn SC2 (manual transmission 3-Door) 1999-2002
|-
|S||Saturn SL Spring Special 2002
|-
|Y||Saturn SC2 (automatic transmission 3-Door) 1999-2002
|-
|rowspan=3|GM Zeta platform (VE)
|rowspan=3|E||C||Pontiac G8 GT
|-
|P||Pontiac G8 GXP
|-
|R||Pontiac G8 (Base model)
|-
|rowspan=2|GM Zeta platform (VF)
|rowspan=2|F||1||2014-2017 Chevrolet SS w/automatic transmission
|-
|2||2015-2017 Chevrolet SS w/manual transmission
|-
|GM Zeta platform (WM)
|M||K||2011-2013 Chevrolet Caprice PPV
|-
|GM Zeta platform (WN)
|N||S||2014-2017 Chevrolet Caprice PPV
|-
|rowspan=19|GM Zeta platform (models formerly on F platform)
|rowspan=19|F||A||Chevrolet Camaro ''LS'' automatic transmission 2010-2011, ''2LS'' automatic transmission 2012-2014, ''LS'' manual transmission 2015
|-
|B||Chevrolet Camaro ''LT'' automatic transmission 2010-2014, ''2LS'' automatic transmission 2015
|-
|C||Chevrolet Camaro ''2LT'' automatic transmission 2010-2014, ''LT'' manual transmission 2015
|-
|D||Chevrolet Camaro ''LT'' automatic transmission 2015
|-
|E||Chevrolet Camaro ''LS'' manual transmission 2010-2014, ''2LT'' manual transmission 2015
|-
|F||Chevrolet Camaro ''LT'' manual transmission 2010-2014, ''2LT'' automatic transmission 2015
|-
|G||Chevrolet Camaro ''2LT'' manual transmission 2010-2014, ''SS'' manual transmission 2015
|-
|H||Chevrolet Camaro ''SS'' automatic transmission 2015
|-
|J||Chevrolet Camaro ''SS'' automatic transmission 2010-2014. Note: Must have "J" in 8th position of VIN.
|-
|J||Chevrolet Camaro ''ZL1'' automatic transmission 2012. Note: Must have "P" in 8th position of VIN.
|-
|J||Chevrolet Camaro ''2SS'' manual transmission 2015
|-
|K||Chevrolet Camaro ''2SS'' automatic transmission 2010-2015
|-
|L||Chevrolet Camaro ''ZL1'' automatic transmission 2013-2014, ''ZL1'' manual transmission 2015
|-
|M||Chevrolet Camaro ''ZL1'' automatic transmission 2015
|-
|S||Chevrolet Camaro ''SS'' manual transmission 2010-2014. Note: Must have "W" in 8th position of VIN.
|-
|S||Chevrolet Camaro ''ZL1'' manual transmission 2012. Note: Must have "P" in 8th position of VIN.
|-
|S||Chevrolet Camaro ''Z/28'' manual transmission 2014. Note: Must have "E" in 8th position of VIN.
|-
|T||Chevrolet Camaro ''2SS'' manual transmission 2010-2014
|-
|Z||Chevrolet Camaro ''ZL1'' manual transmission 2013-2014, ''Z/28'' manual transmission 2015
|-
|}
RHD= Right-Hand Drive
====Model Line 2010- Passenger Car (Using Vehicle Platforms introduced 2010 or later)====
The Model Line is specified as character 4 of the American GM VIN for Passenger Cars.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Cadillac ATS 2013-2019
|-
|A||Cadillac CTS sedan 2014-2019, CTS V-Series sedan 2016-2019
|-
|B||Chevrolet Cruze 2016-2019
|-
|C||Chevrolet Spark 2013-2022, Spark EV 2014-2016
|-
|D||Cadillac CT4 2020-2026
|-
|D||Cadillac CT5 2020-
|-
|F||Chevrolet Camaro 2016-2024
|-
|F||Chevrolet Bolt EV 2017-2023, Bolt EUV 2022-2023, Bolt 2027
|-
|G||Buick LaCrosse 2010-2016
|-
|G||Buick Regal 2011-2020, Buick Regal TourX 2018-2020
|-
|J||Chevrolet Sonic 2016-2020
|-
|K||Cadillac CT6 2016-2020
|-
|M||Cadillac Celestiq EV 2025-
|-
|P||Buick Verano 2012-2017
|-
|P||Chevrolet Cruze 2011-2015, Cruze Limited 2016
|-
|R||Cadillac ELR 2014, 2016
|-
|R||Chevrolet Volt 2011-2019
|-
|W||Buick Cascada 2016-2019
|-
|Y||Chevrolet Corvette 2014-
|-
|Z||Buick LaCrosse 2017-2019
|-
|Z||Chevrolet Malibu 2016-2025
|-
|1||Cadillac XTS 2013-2019
|-
|1||Chevrolet Impala 2014-2020
|-
|1||Chevrolet Malibu 2013-2015, Malibu Limited 2016
|-
|}
===Body style codes 1987- Passenger Car===
The Body type is specified as character 6 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1||Two-Door Coupe/Sedan
|-
|2||Two-Door Hatchback
|-
|3||Two-Door Convertible
|-
|4||Two-Door Wagon ('91-'92 Geo Storm Hatchback)
|-
|5||Four-Door Sedan
|-
|6||Four-Door Hatchback
|-
|7||Four-Door Hatchback ('89-'90 Geo Prizm hatchback)
|-
|8||Four-Door Station Wagon
|-
|9||Four-Door Station Wagon - High Roof Monocab
|}
===American restraint types 1987-===
The restraint type is specified as character 7 of the American GM VIN for passenger cars.
{{center/top}}
====Restraint codes for passenger cars 1987-2009====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|1||Active (Manual) belts 1987-1996
|-
|2||Active (Manual) belts plus driver and passenger front airbags 1992-2005<br />(For '94-'96 Pontiac Grand Prix coupe: Passive (Automatic) belts plus driver and passenger front airbags)
|-
|3||Active (Manual) belts plus driver side front airbag 1988-1996 <br />(For '94 Geo Prizm: Active (Manual) belts plus driver and passenger front airbags)
|-
|4||Passive (Automatic) belts 1987-1996
|-
|4||Active (Manual) belts plus driver and passenger front & side airbags 1997-2005
|-
|4||Active (Manual) belts plus driver and passenger front & side curtain airbags 2006-2009
|-
|5||Passive (Automatic) belts plus driver side front airbag 1992-1996
|-
|5||Active (Manual) belts plus driver and passenger front airbags & driver-side side impact airbag 2000-2005
|-
|5||Active (Manual) belts plus driver and passenger front airbags & occupant sensor 2006-2009
|-
|6||Passive (Automatic) belts plus driver and passenger front airbags 1994-1996
|-
|6||Active (Manual) belts plus driver and passenger front & side airbags & occupant sensor 2000-2009
|-
|7||Active (Manual) belt driver & Passive (Automatic) belt passenger plus driver and passenger front airbags 1996
|-
|7||Active (Manual) belts plus driver and passenger front & side airbags & rear side airbags 2000-2005
|-
|7||Active (Manual) belts plus driver and passenger front & side & side curtain airbags & occupant sensor 2006-2009
|-
|8||Active (Manual) belts plus driver and passenger front & side curtain airbags & occupant sensor 2006-2009
|-
|9||
|}
{{center/top}}
====Restraint codes for passenger cars 2010-====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|D||Active (Manual) belts plus driver and passenger front & side airbags 2010-
|-
|E||Active (Manual) belts plus driver and passenger front & side & side curtain airbags 2010-2017, 2027
|-
|F||Active (Manual) belts plus driver and passenger front & side curtain airbags 2010
|-
|G||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain airbags 2010-2017
|-
|N||Active (Manual) belts plus driver and passenger front & side & front knee airbags 2016-2019
|-
|R||Active (Manual) belts plus driver and passenger front & side & side curtain & front knee airbags 2012-
|-
|S||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain & front knee airbags 2011-
|-
|T||Active (Manual) belts plus driver and passenger front & side & front row side curtain airbags 2011
|-
|U||Active (Manual) belts plus driver and passenger front & side & front row side curtain & front knee airbags 2012-2017
|}
{{center/top}}
====Restraint codes for light trucks 2010-====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|A||Active (Manual) belts plus driver-side front airbag 2010
|-
|B||Active (Manual) belts plus driver-side front airbag 2011-
|-
|B||Active (Manual) belts plus driver and passenger front airbags 2010
|-
|C||Active (Manual) belts plus driver and passenger front airbags 2011-
|-
|C||Active (Manual) belts plus driver and passenger front & side airbags 2010
|-
|D||Active (Manual) belts plus driver and passenger front & side airbags 2011-
|-
|D||Active (Manual) belts plus driver and passenger front airbags & side curtain airbags for up to 3 rows of seating 2010
|-
|E||Active (Manual) belts plus driver and passenger front & side & side curtain airbags 2010-
|-
|F||Active (Manual) belts plus driver and passenger front airbags & side curtain airbags for up to 3 rows of seating 2011-2015
|-
|F||Active (Manual) belts plus driver and passenger front & side airbags & side curtain airbags for up to 3 rows of seating 2016-
|-
|H||Active (Manual) belts plus driver-side front airbag & driver-side side-impact airbag & driver-side side curtain airbag 2023-2024
|-
|K||Active (Manual) belts plus driver and passenger front & side & side curtain & front center airbags 2013-
|-
|L||Active (Manual) belts plus driver and passenger front & side & side curtain & front center & driver-side knee airbags 2017-2023
|-
|M||Active (Manual) belts plus driver and passenger front & side & side curtain & front center & front knee airbags 2025-
|-
|R||Active (Manual) belts plus driver and passenger front & side & side curtain & front knee airbags 2017-
|-
|S||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain & front knee airbags 2013-
|-
|T||Active (Manual) belts plus driver-side front airbag & driver- and passenger-side side-impact airbags & side curtain airbags 2023-
|-
|U||Active (Manual) belts plus driver and passenger front & side & front row side curtain & front knee airbags 2013-2019
|}
===American engine codes 1981-===
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
====Engine codes for passenger cars====
Warning: Issues with decoding are related to year/model combinations. Each year has a different breakdown for each code along with plants and some model/trim breakdowns over years.
Entry: 1985-1988 Pontiac Fiero has a 9 engine code for the 2.8L L44 V6. Entry: 1986-1990 Cadillac Brougham, Oldsmobile 307 Cu. In. V8 vin code Y.
{| border=1 style="margin:auto;"
!VIN
!RPO
!Size
!Type
!Fuel
!Valvetrain
!Engine Family/Notes/Applications
|-
|A||LD5||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Buick V6. (231 cu. in.) '81 Chevy Camaro (CA), Pontiac Catalina, Firebird, LeMans, Buick Century,<br /> '81-'83 Chevy Malibu (CA), '81-'84 Monte Carlo, Caprice, Impala (CA), '81-'87 Pontiac Grand Prix, Oldsmobile Cutlass/Cutlass Supreme, Buick Regal, '81-'85 Oldsmobile Delta 88, Buick LeSabre,<br /> '81-'86 Pontiac Bonneville, '84 Parisienne
|-
|A||LG0||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4 H.O. '89-'94 Pontiac Grand Am, '89-'91 Oldsmobile Cutlass Calais, '92-'94 Achieva, '90 Cutlass Supreme, '90-'94 Chevy Beretta
|-
|A||LH2||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (For RWD) (Premium V). '04-'09 Cadillac XLR, '05-'10 Cadillac STS
|-
|A||LCV||2.5 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. '13 Chevy Malibu, '16 Malibu Limited, '16-'19 Impala,<br /> '13-'16 Cadillac ATS
|-
|A||LV7||1.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. Made in Changwon, S. Korea. '16-'22 Chevy Spark.
|-
|B||LG2||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6. '86 Oldsmobile 98, Toronado, Buick Electra, Riviera.
|-
|B||L26||4.9 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8.<br /> '91-'93 Cadillac Eldorado, Seville, '91-'95 DeVille, '91-'92 Fleetwood, '91-'93 Sixty Special
|-
|B||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '06-'08 Chevy Cobalt, '06-'07 Saturn Ion, '06-'10 Pontiac G6, Solstice,<br /> '07-'08 Pontiac G5, '07-'10 Saturn Sky, '08-'09 Saturn Aura, '08-'10 Chevy Malibu
|-
|B||LUV||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. '12-'20 Chevy Sonic, '13-'15 Chevy Cruze, '16 Cruze Limited
|-
|C||L17||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu G161Z engine made by GM in US. '82-'87 Chevy Chevette, Pontiac T1000/1000
|-
|C||LN3||3.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6 (3800). '88-'90 Oldsmobile 98, Toronado, Buick Electra, Riviera, Reatta, <br /> '88-'91 Buick LeSabre, Oldsmobile Delta 88/Eighty Eight, Pontiac Bonneville
|-
|C||L47||4.0 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Oldsmobile Aurora V8 (Premium V). Oldsmobile Aurora '95-'99, Aurora 4.0 '01-'03
|-
|C||LS4||5.3 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. Active Fuel Management.<br /> Transversely mounted for FWD. '05-'08 Pontiac Grand Prix GXP, '06-'07 Chevy Monte Carlo SS,<br /> '06-'09 Chevy Impala SS, '08-'09 Buick LaCrosse Super.
|-
|C||LAF||2.4 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. VVT. Buick LaCrosse '10-'11, Regal '11.
|-
|C||LUJ||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. Early production engines were made in Aspern, Austria; later made in Flint, MI. '12 Chevy Cruze
|-
|D||LJ5||1.8 L||Straight-4|I4||Indirect injection Diesel||SOHC,<br /> 8 valve||Isuzu 4FB1 diesel engine imported from Japan. '81-'86 Chevy Chevette
|-
|D||LD2||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4. '88-'95 Pontiac Grand Am, '88-'91 Oldsmobile Cutlass Calais, '92-'95 Achieva,<br /> '88-'91 &'95 Buick Skylark, '90-'91 Pontiac Grand Prix, Oldsmobile Cutlass Supreme,<br /> '95 Chevy Cavalier, Pontiac Sunfire
|-
|D||LC3||4.4 L||V8 Supercharged||Fuel injection#Sequential Multi-port point injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (Premium V). '06-'09 Cadillac XLR V-Series, Cadillac STS V-Series
|-
|E||LK9||3.0 L||V6||2 Barrel Carburetor |2BBL||OHV||Buick V6. '82-'85 Oldsmobile Cutlass Ciera, Buick Century, '85 Oldsmobile 98, Buick Electra
|-
|E||LA1||3.4 L||V6||Fuel injection#Sequential Multi-port point injection|SFI||OHV||Chevrolet 60° V6. '99-'05 Grand Am, '99-'04 Alero, '00-'05 Impala, Monte Carlo
|-
|E||L03||5.0 L||V8||Fuel injection#Throttle Body injection|TBI||OHV||Gen I Chevy Small-Block V8 (305 cu. in.). '88-'92 Camaro/Firebird, '89-'93 Chevy Caprice,<br /> '91 Buick Roadmaster Estate wagon, '91-'92 Oldsmobile Custom Cruiser, Cadillac Brougham.
|-
|E||LXV||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Family 1 Gen 3 engine. W/VVT. '09-'11 Chevy Aveo, '09 Pontiac G3
|-
|E||LS7||7.0 L||V8||Fuel injection#Sequential Multi-port point injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '06-'13 Corvette Z06, '13 Corvette 427, '14-'15 Camaro Z/28
|-
|E||LH7||1.6 L||I4 Turbo||Direct injection <br /> Common-rail Diesel||DOHC,<br /> 16 valve||GM Medium Diesel engine ("Whisper Diesel"). Made by Opel in Szentgotthárd, Hungary.<br /> Aluminum Block & Heads. '17-'19 Chevy Cruze Diesel.
|-
|F||LV8||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Oldsmobile "Rocket" V8 (260 cu. in.) '81 Oldsmobile Cutlass, Delta 88.
|-
|F||L61||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen I. '00-'04 Saturn L-Series, '02-'05 Chevy Cavalier, Pontiac Sunfire, Grand Am,<br /> '02-'04 Oldsmobile Alero, '03-'06 Saturn Ion, '04-'06 Chevy Malibu, '05-'06 Chevy Cobalt
|-
|F||L61||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. '07-'08 Chevy Cobalt, Malibu, Pontiac G5, '07 Saturn Ion.
|-
|F||LB9||5.0 L||V8||Tuned-port fuel injection|TPI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.). '85-'92 Chevy Camaro, Pontiac Firebird.
|-
|G||L46||1.8 L||I4||2 Barrel Carburetor |2BBL||OHV||Chevrolet "122" engine. '82 J-cars.
|-
|G||L69||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8 (High Output 5.0L). (305 cu. in.)<br /> '84-'86 Camaro/Firebird, '84-'88 Chevy Monte Carlo SS
|-
|G||LM3||2.2 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '90-'91 Chevy Cavalier & Corsica/Beretta.
|-
|G||LS1||5.7 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Gen III Chevy Small-Block V8. (346 cu. in.) Aluminum Block & Heads.<br /> '97-'04 Corvette, '98-'02 Camaro/Firebird, '04 Pontiac GTO
|-
|G||LF1||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. 2010 Buick LaCrosse, Cadillac CTS
|-
|G||LWE||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. PZEV emissions.<br /> '13-'15 Chevy Cruze, '16 Cruze Limited, '13-'18 Sonic.
|-
|H||LG4||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '81-'87 F-bodies, '81-'83 Chevy Malibu, '81-'85 Impala,<br /> '81-'88 Caprice, Monte Carlo, '83-'86 Pontiac Bonneville, Parisienne, '83-'87 Grand Prix
|-
|H||LE4||2.0 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil. '92-'94 Pontiac Sunbird.
|-
|H||LX5||3.5 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||Oldsmobile "Shortstar" V6 (Premium V). Oldsmobile Intrigue '99-'02, Aurora 3.5 '01-'02.
|-
|H||LAP||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '09 Chevy Cobalt, Pontiac G5.
|-
|H||LUW||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. '11-'15 Chevy Cruze, '16 Cruze Limited, '12-'18 Sonic.
|-
|J||L39||4.4 L||V8||2 Barrel Carburetor |2BBL||OHV||Gen I Chevy Small-Block V8 (267 cu. in.) '81-'82 Chevy Caprice, Impala, Malibu, Monte Carlo,<br /> '81 Chevy Camaro
|-
|J||LA5||1.8 L||Straight-4|I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil. '84-'86 Pontiac Sunbird, Buick Skyhawk.
|-
|J||LT5||5.7 L||V8||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 32 valve||Based on Chevy Small-Block V8. Designed with Lotus Engineering.<br /> Made by Mercury Marine. Aluminum Block & Heads. '90-'95 Corvette ZR-1
|-
|J||LG8||3.1 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Chevrolet 60° V6. Gen III. 3100. '99-'03 Chevy Malibu, '99 Oldsmobile Cutlass, '00-'01 Chevy Lumina,<br /> '00-'03 Pontiac Grand Prix SE, '00-'05 Buick Century
|-
|J||L99||6.2 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. VVT. With Active Fuel Management. Aluminum Block & Heads.<br /> '10-'15 Camaro SS (auto. trans.)
|-
|J||LTA||4.2 L||V8 Twin Turbo||Direct injection|DI||DOHC,<br /> 32 valve||Cadillac Blackwing V8. VVT. '19-'20 Cadillac CT6 Platinum & V-series
|-
|K||LC3||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '81-'82 Malibu, Monte Carlo, Impala, Caprice, '81 Camaro.
|-
|K||LC5||1.5 L||I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu 4XC1 engine. '85 Chevrolet Spectrum.
|-
|K||LT2||2.0 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '87-'91 Pontiac Sunbird, '87-'88 Oldsmobile Firenza, Buick Skyhawk.
|-
|K||LT2||2.0 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Australia by Holden.<br /> '89-'90 Pontiac LeMans GSE Aerocoupe, '89 LeMans SE sedan
|-
|K||L36||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Series II). '95-'05: Various W-, H-, C-, & G-body models. '95-'02 Camaro/Firebird.
|-
|K||LZE||3.5L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3510cc. VVT. Flex-Fuel E85 compatible.<br /> '06-'07 Chevy Monte Carlo, '06-'11 Chevy Impala, '09-'10 Chevy Malibu, Pontiac G6
|-
|K||LEA||2.4 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||E85 Flex Fuel. GM Ecotec engine, Gen II. VVT. Buick Regal, Verano '12-'17 (except '13 Regal).
|-
|K||LSY||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Active Fuel Management. VVT. VVL.<br /> '19 Cadillac CT6, '20+ Cadillac CT4, CT5
|-
|L||LM1||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8.<br> '81 Camaro Z28 (only w/auto. trans. in US), '81-'82 Impala 9C1 Police, '81 Malibu 9C1 Police
|-
|L||LL1||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 H.O. (longitudinally mounted). '83-'84 Pontiac Firebird.
|-
|L||LN7||3.0 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6. '85-'87 Pontiac Grand Am, '85-'88 Oldsmobile & Buick N-bodies,<br /> '86 Oldsmobile Delta 88, Buick LeSabre
|-
|L||L27||3.8 L||V6||Fuel injection#Tuned port injection|TPI||OHV||Buick V6 (3800 Series I). '90-'95 Buick Regal, '91-'94 Oldsmobile 98, Buick Park Avenue, '91 Reatta, '91-'93 Riviera, '91-'92 Oldsmobile Toronado, '92-'95 Buick LeSabre, '92-'94 Pontiac Bonneville, Oldsmobile 88
|-
|L||LNK||1.8 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2ZZ-GE engine. VVTL-i. '03-'06 Pontiac Vibe GT
|-
|L||LKW||2.5 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. VVL. '14-'15 Chevy Malibu, Impala
|-
|L||L3B||2.7L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM L3B Tripower engine. VVT, VVL. Active Fuel Management. '20+ Cadillac CT4, CT4-V
|-
|M||LY9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '85 Chevrolet Sprint
|-
|M||LT3||2.0 L||Straight-4|I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '87-'90 Pontiac Sunbird, '87 Buick Skyhawk T-Type, '87-'89 Pontiac Grand Am SE.
|-
|M||L82||3.1 L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||Chevrolet 60° V6 (transversely mounted). Gen III. 3100. '93-'97 Oldsmobile Cutlass Supreme,<br /> '94-'98 Pontiac Grand Am, Oldsmobile Achieva, Buick Skylark, '94-'99 Pontiac Grand Prix,<br /> '94-'96 Chevy Corsica/Beretta, Oldsmobile Cutlass Ciera, Buick Regal, '94-'99 Century,<br /> '95-'99 Chevy Lumina, Monte Carlo, '97-'99 Chevy Malibu, Oldsmobile Cutlass
|-
|M||LY9||2.6 L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). Euro-market Cadillac CTS '03-'04.
|-
|M||LGD||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||E85 Flex Fuel. GM High Value 60° V6. VVT. '09-'11 Chevy Impala, Buick Lucerne
|-
|M||LE2||1.4 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. '16-'19 Chevy Cruze.
|-
|N||LF9||5.7 L||V8||Indirect injection Diesel||OHV||Oldsmobile Diesel V8. '81-'85 Chevy Caprice, Impala, '82-'83 Malibu, '82-'84 Monte Carlo,<br /> '81-'84 Pontiac Grand Prix, Bonneville, '81 Catalina, '83-'85 Parisienne,<br /> '81-'84 Oldsmobile 98, '81-'85 Cutlass/Cutlass Supreme, Delta 88, Custom Cruiser, Toronado,<br /> '81-'83 Buick Electra, '81-'85 LeSabre, Electra Estate wagon, Riviera, '82-'83 Regal,<br /> '81-'84 Cadillac DeVille, '81-'85 Fleetwood Brougham, Eldorado, Seville
|-
|N||LG7||3.3 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6 (3300). '89-'93 Buick Century, Skylark, Oldsmobile Cutlass Ciera, '89-'91 Cutlass Calais,<br /> '92-'93 Achieva, Pontiac Grand Am.
|-
|N||LA3||3.2 L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). '03-'04 Cadillac CTS
|-
|N||LZ4||3.5L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3510cc. VVT. '06-'07 Chevy Monte Carlo, '06-'10 Chevy Impala,<br /> '07-'10 Chevy Malibu, Pontiac G6, '07-'08 Saturn Aura
|-
|N||LFR||3.6L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||(Bi-Fuel Gas/CNG). GM High Feature V6. '15-'17 Chevy Impala Bi-Fuel
|-
|P||LQ5||2.0 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '83-'86 J-cars ('83-'84 for Pontiac).
|-
|P||LT1||5.7 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. Aluminum Heads: '92-'96 Corvette, '93-'97 Camaro/Firebird.<br /> Iron Heads: '94-'96 Chevy Caprice, Impala SS, Buick Roadmaster, Cadillac Fleetwood.
|-
|P||LSJ||2.0 L||SC Straight-4|I4 Supercharged||Fuel injection#Sequential central point injection|SFI||DOHC,<br /> 16 valve||GM Ecotec Gen I. Made by Opel in Kaiserslautern, Germany.<br /> '04-'07 Saturn Ion Red Line, '05-'07 Chevy Cobalt SS Supercharged.
|-
|P||LSA||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> Cadillac CTS V-Series '09-'15, Camaro ZL1 '12-'15
|-
|P||LF4||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. Cadillac CT4-V Blackwing '22+
|-
|R||LR8||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Transversely mounted. '82-'85 Chevy Citation, Buick Skylark,<br /> '82-'84 Pontiac Phoenix, Oldsmobile Omega, '82-'90 Chevy Celebrity, '82-'91 Pontiac 6000,<br /> '82-'92 Oldsmobile Cutlass Ciera, Buick Century, '84-'88 Pontiac Fiero, '90-'92 Chevy Lumina
|-
|R||L81||3.0 L||V6||Fuel injection#Multi-port fuel injection|SFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). '97-'01 Cadillac Catera, '00-'05 Saturn L-Series
|-
|R||LZ8||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||GM High Value 60° V6. VVT. Active Fuel Management. '07 Chevy Impala
|-
|R||LS9||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. '09 Corvette ZR1.
|-
|R||LUK||2.4L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '12-'16 Buick LaCrosse eAssist, Regal eAssist,<br /> '13-'14 Chevy Malibu Eco, '14 Chevy Impala Eco
|-
|S||LS5||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Pontiac V8. 265 cu. in.<br /> '81 Pontiac Bonneville, Catalina, Firebird, Grand Prix, LeMans, Buick Century, Regal.
|-
|S||LU5||5.0 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '83 Camaro, Firebird. Dual throttle-body fuel injection.
|-
|S||LB8||2.8 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '85-'89 Chevy Camaro, Pontiac Firebird.
|-
|S||L32||3.4 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '93-'95 Chevy Camaro, Pontiac Firebird.
|-
|S||LS6||5.7 L||V8||Fuel injection#Sequential Multi Port injection|SFI||OHV||Gen III Chevy Small-Block V8. (346 cu. in.) Aluminum Block & Heads.<br /> '01-'04 Corvette Z06, '04-'05 Cadillac CTS V-Series
|-
|S||LGX||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '16-'19 Cadillac ATS, CTS, '16-'20 CT6, '16-'24 Chevrolet Camaro, '17-'19 Buick LaCrosse, '18–'20 Buick Regal GS
|-
|T||LU8||4.9 L||V8 Turbo||4 Barrel Carburetor |4BBL||OHV||Pontiac V8. 301 cu. in. '81 Pontiac Firebird Formula & Trans Am.
|-
|T||LT7||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. FWD version for '82-'85 GM A-bodies.
|-
|T||LS2||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. FWD version for '85 GM C-bodies.
|-
|T||LH0||3.1 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '90-'92 Chevy Camaro, Pontiac Firebird.
|-
|T||LH0||3.1 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (transversely mounted). Gen II. '88-'91 Pontiac 6000,<br /> '89-'93 Grand Prix, Oldsmobile Cutlass Supreme, Buick Regal, '90-'94 Chevy Cavalier, Lumina,<br /> '91-'94 Pontiac Sunbird, '90-'93 Chevy Corsica/Beretta, '90 Celebrity
|-
|T||LD9||2.4 L||Straight-4|I4||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4 ("2.4 Twin Cam"). '96-'01 Pontiac Grand Am, '96-'97 Oldsmobile Achieva, Buick Skylark, '99-'01 Oldsmobile Alero, '97-'99 Chevy Malibu, '96-'02 Chevy Cavalier, Pontiac Sunfire
|-
|T||LP1||2.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||GM High Feature V6. '05-'07 Cadillac CTS
|-
|T||LS9||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. '10-'13 Corvette ZR1.
|-
|T||LFV||1.5L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. '16-'25 Chevy Malibu.
|-
|U||L68||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Transversely mounted. '85-'91 N-bodies
|-
|U||LS2||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '05-'07 Corvette, '05-'06 Pontiac GTO, '06-'07 Cadillac CTS V-Series
|-
|U||LE9||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. E85 Flex-Fuel. 2011-12 Chevy Malibu.
|-
|U||LKN||1.8L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||Full Hybrid. GM Medium Gasoline Engine. VVT. Made in Szentgotthárd, Hungary.<br> '16-'19 Chevy Malibu Hybrid
|-
|V||LT6||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. RWD version.<br /> '82-'83 Chevy Malibu, Monte Carlo, '82-'85 Oldsmobile Cutlass Supreme, Buick Regal
|-
|V||LG5||3.1 L||V6 Turbo||Fuel injection#Multi-port fuel injection|MPFI||OHV||Chevrolet 60° V6. Gen II. Intercooled. (ASC/McLaren modified).<br /> '89-'90 Pontiac Grand Prix Turbo coupe, '90 Grand Prix STE Turbo sedan
|-
|V||LLT||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. '08-'11 Cadillac CTS, STS, '10-'11 Chevrolet Camaro, Buick LaCrosse
|-
|V||LHU||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||E85 Flex Fuel (N/A on Regal GS). GM Ecotec engine, Gen II. VVT.<br /> Buick Regal '11-'13, Verano '13-'16.
|-
|W||L37||4.9 L||V8||4 Barrel Carburetor |4BBL||OHV||Pontiac V8. 301 cu. in. '81 Pontiac Firebird, LeMans Safari wagon.
|-
|W||LB6||2.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Gen I/II Chevrolet 60° V6 (transversely mounted). '85 Chevy Citation, Buick Skylark,<br /> '85-'89 Chevy Cavalier, Celebrity, Pontiac 6000, '85-'88 Cadillac Cimarron,<br /> '85-'87 Oldsmobile Firenza, '86-'89 Cutlass Ciera, '87-'88 Buick Century, '87-'89 Chevy Corsica/Beretta, '88-'89 Pontiac Grand Prix, Oldsmobile Cutlass Supreme, Buick Regal
|-
|W||L64||3.1 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Flex-fuel: Gas/M85 or Gas/E85 (2 versions). Gen II Chevrolet 60° V6. '93 Chevy Lumina VFV
|-
|W||L99||4.3 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. '94-'96 Chevy Caprice.
|-
|W||LS3||6.2 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '08-'13 Corvette, '10-'15 Camaro SS (man. trans.), '09 Pontiac G8 GXP, '14-'17 Chevy SS
|-
|W||LGY||3.0L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '20+ Cadillac CT5, CT5-V
|-
|X||LE2||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (transversely mounted). '81-'85 Chevy Citation, Buick Skylark,<br /> '81-'84 Pontiac Phoenix, Oldsmobile Omega, '82-'86 Chevy Celebrity, Pontiac 6000,<br /> '86 Oldsmobile Cutlass Ciera, Buick Century
|-
|X||LQ1||3.4 L||V6||Fuel injection#Multi-port fuel injection|MPFI||DOHC,<br /> 24 valve||Chevrolet 60° V6 ("Twin Dual Cam V6"). '91-'97 Chevy Lumina, '95-'97 Chevy Monte Carlo,<br /> '91-'96 Pontiac Grand Prix, Oldsmobile Cutlass Supreme
|-
|X||LNF||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. VVT.<br /> '07-'10 Pontiac Solstice GXP, Saturn Sky Red Line, '08-'10 Chevy Cobalt SS Turbo.
|-
|X||LTG||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. '13-'22 Chevy Malibu, '13-'19 Cadillac ATS, '14-'20 Buick Regal,<br /> '14-'19 Cadillac CTS, '16-'23 Chevy Camaro, '16-'18 Cadillac CT6.
|-
|X||LTG||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||Plug-in hybrid. GM Ecotec engine, Gen III. VVT. '17-'18 Cadillac CT6 PHEV. (VIN starts with LRE)
|-
|Y||LV2||5.0 L||V8||4 Barrel Carburetor |4BBL||OHV||Oldsmobile "Rocket" V8 (307 cu. in.) '86-'90 Chevy Caprice wagon, '87 Caprice sedan (Can.),<br /> '81 Pontiac Bonneville, Catalina, '86 Parisienne, '87-'89 Safari wagon, '81-'84 Oldsmobile 98,<br /> '81-'85 Delta 88, Toronado, '81-'90 Custom Cruiser, '81 Cutlass Cruiser, '82-'87 Cutlass Supreme,<br /> '88 Cutlass Supreme Classic, '81-'84 Buick Electra, '85-'89 Electra Estate wagon,<br /> '81-'85 LeSabre, Riviera, '86-'89 LeSabre Estate wagon, '90 Estate wagon, '86-'87 Regal,<br /> '86 Cadillac Fleetwood Brougham, '87-'90 Brougham
|-
|Y||LD8||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (Torque tuned FWD) (Premium V). '93-'02 Cadillac Eldorado,<br /> '94-'04 Cadillac Seville SLS, '94-'05 Cadillac DeVille, '06-'11 Cadillac DTS,<br /> '04-'05 Pontiac Bonneville GXP, '06-'08 Buick Lucerne
|-
|Y||L76||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management.<br /> '08-'09 Pontiac G8 GT.
|-
|Y||LF1||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. 2011 Cadillac CTS
|-
|Y||LF4||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. Cadillac ATS-V '16-'19
|-
|Z||LH7||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (transversely mounted). H.O. '81-'84 Chevy Citation, '82-'84 Pontiac Phoenix, Oldsmobile Omega ES, Buick Skylark, '83-'84 Pontiac 6000 STE, '84 Chevy Celebrity
|-
|Z||LB4||4.3L||V6||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '85 Chevy Impala, '85-'90 Caprice,<br /> '92-'93 Caprice 9C6 taxi, '85-'88 Monte Carlo, '85-'86 Pontiac Parisienne, '86-'87 Grand Prix,<br> '86 Bonneville.
|-
|Z||LAT||2.4L||I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '10 Chevy Malibu Hybrid
|-
|Z||LUZ||2.0 L||I4 Turbo||Direct injection <br /> Common-rail Diesel||DOHC,<br /> 16 valve||GM Family B Diesel (Based on Fiat JTD engine). Made by Opel in Kaiserslautern, Germany.<br /> Iron Block, Aluminum Heads. '14-'15 Chevy Cruze Diesel.
|-
|1||LC1||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (longitudinally mounted). '82-'84 Camaro/Firebird.
|-
|1||LL8||2.0 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '87-'89 Chevy/Olds/Buick J-cars & Chevy L-cars.
|-
|1||L67||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series I). '91-'95 Buick Park Avenue Ultra,<br /> '92-'95 Pontiac Bonneville, Oldsmobile 98, '95 Buick Riviera, Oldsmobile LSS
|-
|1||L67||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series II). '96-'05 Buick Park Avenue Ultra,<br /> '96-'99 Buick Riviera, Oldsmobile LSS, '96-'03 Pontiac Bonneville, '97-'03 Grand Prix,<br /> '97-'04 Buick Regal, '04-'05 Chevy Impala SS, Monte Carlo SS Supercharged
|-
|1||LZ9||3.9L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. VVT.<br /> '06-'07 Chevy Malibu SS, '06-'09 Pontiac G6, '06 Chevy Monte Carlo, Impala, '09-'10 Buick Lucerne
|-
|1||2H0||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. Made in Szentgotthárd, Hungary. '08 (& '09 in Canada) Saturn Astra
|-
|1||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '11 & some '12 Chevy Malibu w/LE5 engine.
|-
|2||LQ9||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Longitudinally mounted. '82-'85 Camaro/Firebird.
|-
|2||LS3||1.0 L||Straight-3|I3 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 6 valve ||Suzuki G10T engine. '87-'88 Chevrolet Sprint Turbo
|-
|2||LY8||1.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 16 valve||Suzuki G13BB engine. '98-'01 Chevrolet Metro
|-
|2||L26||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Series III). '04-'08 Pontiac Grand Prix, '05-'09 Buick LaCrosse, '06-'08 Buick Lucerne
|-
|2||L77||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management.<br /> E85 Flex Fuel. '11-'17 Chevy Caprice PPV.
|-
|3||LC8||3.8 L||V6|V6 Turbo||4 Barrel Carburetor |4BBL||OHV||Buick V6. 231 cu. in. '81-'82 Buick Regal, Riviera, '81 Chevy Monte Carlo.
|-
|3||LG3||3.8 L||V6||Fuel injection#(Sequential) Multi-port injection|MFI/SFI||OHV||Buick V6. '84-'88 Oldsmobile Cutlass Ciera, Buick Century, '85 & '87 Oldsmobile 98, Buick Electra,<br /> '86-'88 Oldsmobile Delta 88, Buick LeSabre, '87 Oldsmobile Toronado, Buick Riviera,<br /> '87-'88 Pontiac Bonneville.
|-
|3||LW2||4.5 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '90 Cadillac DeVille/Fleetwood/Sixty Special/Eldorado/Seville.
|-
|3||L40||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||Oldsmobile Quad 4 ("Quad OHC"). '92-'94 Pontiac Grand Am, Oldsmobile Achieva, Buick Skylark
|-
|3||LZG||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||E85 Flex Fuel. GM High Value 60° V6. VVT. Active Fuel Management. '08 Chevy Impala
|-
|3||LFX||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. E85 Flex Fuel.<br /> '12-'16 Buick LaCrosse, '12-'15 Chevrolet Camaro, Cadillac CTS, '12-'17 Chevrolet Caprice PPV,<br /> '12-'20 Chevrolet Impala, '14-'16 Chevrolet Impala Limited, '13-'15 Cadillac ATS, '13-'19 Cadillac XTS
|-
|3||LT6||5.5 L||V8||Direct injection|DI||DOHC,<br /> 32 valve||Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette Z06 '23+.
|-
|4||LC4||4.1 L||V6|V6||4 Barrel Carburetor |4BBL||OHV||Buick V6. '81-'84 Buick LeSabre, Electra, Riviera, Oldsmobile Toronado, '81-'82 Cadillac DeVille, Fleetwood Brougham, Eldorado, Seville, '81-'83 Oldsmobile 98, '82-'84 Buick Regal,<br /> '82 Pontiac Grand Prix, Bonneville G
|-
|4||LC9||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Toyota 4A-C engine. '85-'88 Chevy Nova
|-
|4||LN2||2.2 L||Straight-4|I4||Fuel injection#(Sequential) Multi-port injection|MPI/SFI||OHV||Chevrolet "122" engine. '92-'02 Cavalier, '95-'02 Sunfire, '92-'96 Corsica/Beretta, '93 Lumina,<br /> '93-'96 Cutlass Ciera, Century.
|-
|4||L32||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series III). '04-'07 Pontiac Grand Prix
|-
|4||LUU||1.4L||I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. ([[w:EREV|Range extender]]). Early production engines were made in Aspern, Austria; later made in Flint, MI. '11-'15 Chevy Volt, '14 & '16 Cadillac ELR.
|-
|4||LT2||6.2 L||V8||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Stingray '20+.
|-
|4||LT2||6.2 L||V8||Direct injection|DI||OHV||Full Hybrid. Gen V Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette E-Ray '24+.
|-
|5||LW9||2.5L||I4||2 Barrel Carburetor |2BBL||OHV||Pontiac Iron Duke engine. '81 Chevy Citation, Pontiac Phoenix, Oldsmobile Omega, Buick Skylark.
|-
|5||LR6||4.5 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac High Technology V8. '88-'89 Cadillac DeVille/Fleetwood/Sixty Special/Eldorado/Seville.
|-
|5||LY9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '86 Chevrolet Sprint
|-
|5||LM9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '87-'88 Chevrolet Sprint
|-
|5||LW0||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 4A-GE engine. '88 Chevy Nova Twin Cam, '90-'92 Geo Prizm GSi
|-
|5||LW0||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Isuzu 4XE1-UW engine. '90-'91 Geo Storm GSi
|-
|5||LT4||5.7 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. '96 Corvette (man. trans.)
|-
|5||LAT||2.4L||I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '07-'09 Saturn Aura Green Line, '08-'09 Chevy Malibu Hybrid
|-
|5||LAP||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '10 Chevy Cobalt.
|-
|5||LFW||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. '12-'13 Cadillac CTS, '14 CTS wagon
|-
|5||L3A||1.5L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. ([[w:EREV|Range extender]]). '16-'19 Chevy Volt.
|-
|5||LWC||1.6L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Medium Gasoline Engine, H.O. VVT. Made in Szentgotthárd, Hungary. '16-'19 Buick Cascada
|-
|5||LS6||6.7 L||V8||Port/Direct injection||OHV||Gen VI Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Stingray, Grand Sport '27+.
|-
|5||LS6||6.7 L||V8||Port/Direct injection||OHV||Full Hybrid. Gen VI Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Grand Sport X '27+.
|-
|6||L81||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. '81 Corvette
|-
|6||LM1||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. '83-'85 Impala 9C1 Police, '86-'88 Caprice 9C1 Police
|-
|6||L73||1.6 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family 1 engine. Made in South Korea by Daewoo. '88-'93 Pontiac LeMans
|-
|6||LP2||1.0 L||Straight-3|I3||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 6 valve ||Suzuki G10A engine. '89-'97 Geo Metro, '98-'00 Chevrolet Metro
|-
|6||L01||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 4A-FE engine. '89-'97 Geo Prizm base/LSi
|-
|6||L01||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 12 valve||Isuzu 4XE1-V engine. '90-'93 Geo Storm (base model)
|-
|6||L42||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen I (Bi-Fuel Gas/CNG). '03-'04 Chevy Cavalier
|-
|6||L91||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||E-TEC II. '04-'07 Chevy Aveo
|-
|6||LXT||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||E-TEC II. '08 Chevy Aveo
|-
|6||LGW||3.0L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '16-'19 Cadillac CT6
|-
|6||LT4||6.2 L||V8 Supercharged||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management. VVT.<br /> '15-'19 Corvette Z06, '17-'24 Camaro ZL1, '16-'19 Cadillac CTS V-Series,<br /> '22+ Cadillac CT5-V Blackwing
|-
|7||LU5||5.0 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '82 Camaro, Firebird. Dual throttle-body fuel injection.
|-
|7||L69||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8 (High Output 5.0L). (305 cu. in.). '83 F-cars, '83 Chevy Monte Carlo SS
|-
|7||LC5||1.5 L||I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu 4XC1 engine. '86-'88 Chevrolet Spectrum, '89 Geo Spectrum.
|-
|7||LC2||3.8 L||V6|V6 Turbo||Fuel injection#Sequential multi-port injection|SFI||OHV||Intercooled. Buick V6. '86-'87 Buick Regal. '89 Pontiac 20th Anniversary Turbo Trans Am
|-
|7||LC7||4.1 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '87-'88 Cadillac Allante.
|-
|7||L05||5.7 L||V8||Fuel injection#Throttle Body injection|TBI||OHV||Gen I Chevy Small-Block V8. '89-'93 Chevy Caprice (police only for '89-'91),<br /> '92-'93 Buick Roadmaster, '92 Oldsmobile Custom Cruiser, '90-'92 Cadillac Brougham, '93 Fleetwood.
|-
|7||LL0||1.9 L||Straight-4|I4||Fuel injection#Multi-port injection|MFI||DOHC,<br /> 16 valve||Saturn I4 engine. '91-'02 Saturn S-Series
|-
|7||LY7||3.6 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. '04-'09 Cadillac CTS, '05-'07 STS, '05-'08 Buick LaCrosse,<br /> '07-'09 Pontiac G6, Saturn Aura, '08-'09 Pontiac G8, '08-'12 Chevy Malibu
|-
|7||LT1||6.2 L||V8||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management. VVT.<br /> '14-'19 Corvette, '16-'24 Camaro SS
|-
|7||LT7||5.5 L||V8 Twin Turbo||Port/Direct injection||DOHC,<br /> 32 valve||Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette ZR1 '25+. (1,064 hp)
|-
|7||LT7||5.5 L||V8 Twin Turbo||Port/Direct injection||DOHC,<br /> 32 valve||Full Hybrid. Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette ZR1X '26+. (1,250 hp)
|-
|8||LV8||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Oldsmobile "Rocket" V8 (260 cu. in.) '82 Oldsmobile Cutlass, Delta 88.
|-
|8||LT8||4.1 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac High Technology V8. '82-'87 Cadillac DeVille, Eldorado, Seville, '82-'85 Fleetwood Brougham, '85-'87 Fleetwood, '87 Fleetwood Sixty Special.
|-
|8||LC8||3.8 L||V6|V6 Turbo||4 Barrel Carburetor |4BBL||OHV||Buick V6. '83 Buick Regal, Riviera.
|-
|8||L83||5.7 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. '82, '84 Corvette. Dual throttle-body fuel injection. 1st fuel injected Corvette since 1965.
|-
|8||L98||5.7 L||V8||Tuned-port fuel injection|TPI||OHV||Gen I Chevy Small-Block V8. '85-'91 Corvette, '87-'92 Chevy Camaro, Pontiac Firebird.
|-
|8||LQ6||4.5 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '89-'92 Cadillac Allante.
|-
|8||L24||1.9 L||Straight-4|I4||Fuel injection#Multi-port injection|MFI||SOHC,<br /> 8 valve||Saturn I4 engine. '95-'02 Saturn S-Series
|-
|8||LX9||3.5 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3498cc. '04-'06 Chevy Malibu, '05-'06 Pontiac G6
|-
|8||LF3||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. '14-'19 Cadillac CTS V-Sport, XTS V-Sport
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Isuzu 4XF1 engine. '92-'93 Geo Storm GSi.
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 7A-FE engine. '93-'97 Geo Prizm
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 1ZZ-FE engine. VVT-i from '00. '98-'02 Chevrolet Prizm, '03-'08 Pontiac Vibe
|-
|8||LAY||1.8 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2ZR-FE engine. Dual VVT-i. '09-'10 Pontiac Vibe
|-
|9||L17||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu G161Z engine made by GM in US. '81 Chevy Chevette, Pontiac T1000
|-
|9||L62||6.0 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac 472-series V8 engine family. V8-6-4 cylinder deactivation.<br /> '81 Cadillacs, '82-'84 Fleetwood Limousine.
|-
|9||LC3||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '83 Malibu, '83-'84 Monte Carlo, Impala, Caprice, '83 Pontiac Parisienne.
|-
|9||LG8||5.0 L||V8||4 Barrel Carburetor |4BBL||OHV||Oldsmobile "Rocket" V8 (307 cu. in.) H.O. '83-'84 Hurst/Olds, '85-'87 Oldsmobile Cutlass 442
|-
|9||LM9||3.8 L||V6|V6 Turbo||Fuel injection#Sequential multi-port injection|SFI||OHV||Buick V6. '84-'85 Buick Regal, Riviera.
|-
|9||L44||2.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Chevrolet 60° V6 (transversely mounted). H.O. '85-'88 Pontiac Fiero
|-
|9||LC0||1.5 L||I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||Isuzu 4XC1-T engine. '87-'88 Chevrolet Spectrum Turbo
|-
|9||LK0||1.9 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||Saturn I4 engine. '91-'94 Saturn S-Series
|-
|9||L37||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (H.O. FWD) (Premium V). '93 Cadillac Allanté,<br /> '93-'02 Cadillac Eldorado Touring Coupe, '93-'04 Cadillac Seville STS, '96-'05 Cadillac DeVille,<br /> '06-'11 Cadillac DTS, '08-'11 Buick Lucerne Super
|-
|9||L72||1.3 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve ||Suzuki G13BA engine. '95-'97 Geo Metro
|-
|9||LUJ||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. Early production engines were made in Aspern, Austria; later made in Flint, MI. '11 Chevy Cruze
|-
|9||LL0||1.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Daewoo S-TEC II engine (1249 cc). VVT. Made in Changwon, S. Korea. '13-'15 Chevy Spark.
|-
|9||LT5||6.2 L||V8 Supercharged||Port/Direct injection||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. VVT. '19 Corvette ZR1.
|-
|0||LH8||1.8 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '82-'86 Pontiac J2000/2000/Sunbird, Oldsmobile Firenza, Buick Skyhawk.
|-
|0||LAX||2.4 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2AZ-FE engine. VVT-i. '09-'10 Pontiac Vibe
|-
|0||LE9||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. E85 Flex-Fuel. 2010 Chevy Malibu.
|-
|0||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. Most '12 Chevy Malibu w/LE5 engine.
|}
H.O.=High Output, CNG=Compressed Natural Gas, VVT=Variable Valve Timing, VVL=Variable Valve Lift
====Motor codes for electric passenger cars====
{| class="wikitable"
|-
! VIN !! RPO !! Fuel !! Drive Wheels !! Application/Notes
|-
| 5 ||LN1|| Electricity || Front || '97, '99 General Motors EV1
|-
| 0 ||EN0|| Electricity || Front || '14-'16 Chevrolet Spark EV
|-
| 0 ||EN0|| Electricity || Front || '17-'23 Chevrolet Bolt EV
|-
| 0 ||EN0|| Electricity || Front || '22-'23 Chevrolet Bolt EUV
|-
|}
====Motor codes for LFP-powered electric passenger cars====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Pack <br /> RPO code !! Fuel !! Drive Wheels !! Application/Notes
|-
|-
| V ||P9D (HPB)|| 1 || EJW || Electricity || Front || '27 Chevrolet Bolt
|}
LFP=Lithium Iron Phosphate
====Motor codes for Ultium-powered electric passenger cars====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Module <br /> RPO code !! # of Modules !! Fuel !! Drive Wheels !! Application/Notes
|-
|-
| 1 ||X0E|| 2 || EXN || 16 || Electricity || All || '25- Cadillac Celestiq
|-
| 2 ||X0E|| 2 || EHT || 16 || Electricity || All || '25- Cadillac Celestiq <br> (Battery Module RPO code EHT is Configuration B)
|}
====Engine codes for light trucks====
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes/Applications
|-
| A ||LD5|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Buick V6. (231 cu. in.) '81-'84 Chevy El Camino, GMC Caballero (CA emissions).
|-
| A ||LR1|| 1.9L || I4 || Gas ||SOHC,<br /> 8 valve||2-bbl carb. Isuzu G200 engine imported from Japan.<br /> '82-'85 Chevy S-10/GMC S-15, '83-'85 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| A ||L38|| 2.5L || I4 || Gas ||OHV||TBI. Pontiac Iron Duke/Tech IV engine. '91-'93 Chevy S-10/GMC Sonoma.
|-
| A ||LH2|| 4.6L || V8 || Gas ||DOHC,<br /> 32 valve||SFI. Cadillac Northstar V8 (For RWD) (Premium V). '04-'09 Cadillac SRX
|-
| A ||L20|| 4.8L || V8 || Gas/E85 ||OHV|| Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads. VVT.<br /> '10-'13 GMT900 pickups, '10-'14 Express/Savana
|-
| A ||LCV|| 2.5L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. VVT. '15-'22 Chevy Colorado, GMC Canyon,<br /> '17-'20 Buick Envision, '17-'21 GMC Acadia, '19-'21 Chevy Blazer
|-
| B ||LR2|| 2.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 60° V6.<br /> '82-'85 Chevy S-10/GMC S-15, '83-'85 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| B ||LU2|| 4.3L || V6 || Gas ||OHV|| TBI. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '90-'91 Astro/Safari higher output engine option.
|-
| B ||L81|| 3.0L || V6 || Gas ||DOHC,<br /> 24 valve||SFI. Opel 54° V6 engine (Made in the UK). '02-'03 Saturn Vue
|-
| B ||L33|| 5.3L || V8 || Gas ||OHV||SFI. Gen III Chevrolet Small-Block V8. Vortec 5300 H.O. 310hp. Aluminum Block & Heads.<br /> '05-'06 Silverado/Sierra 1500 4wd ext. cab short bed,<br> '07 Silverado Classic 1500/Sierra Classic 1500 4wd ext. cab short bed.
|-
| B ||LE8|| 2.2L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. SFI. GM Ecotec Gen II. VVT. '09-'10 Chevy HHR
|-
| B ||LC8|| 6.0L || V8 || Gas/CNG ||OHV||Bi-Fuel (Also Gas/LPG in Express/Savana). SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT. '11-'20 Express/Savana, '13-'19 Silverado HD/Sierra HD.
|-
| B ||LUV|| 1.4L ||I4 Turbo|| Gas ||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. SFI. VVT.<br /> '13-'21 Buick Encore, '15-'21 Chevy Trax (also '13-'14 Trax in Canada)
|-
| C ||LH6|| 6.2L || V8 || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR trucks '82-'93. '82-'86 C/K pickups, '87 R/V pickups,<br /> '88-'93 C/K, Sierra pickups, '82-'91 Blazer/Jimmy, Suburban, '83-'93 full-size vans
|-
| C ||L34|| 2.0L || I4 || Gas ||DOHC,<br /> 16 valve||Suzuki J20A engine. MFI. '99-'03 Chevrolet Tracker
|-
| C ||LY2|| 4.8L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads.<br /> '07-'09 GMT900 pickups, '07-'09 Tahoe/Yukon, '08-'09 Express/Savana
|-
| C ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '11.
|-
| C ||L83|| 5.3L || V8 || Gas/E85 ||OHV|| Flex Fuel. Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management<br /> '14-'19 K2XX pickups, '15-'20 K2XX SUVs.
|-
| C ||L2R|| 2.7L ||I4 Turbo||| Gas ||DOHC,<br /> 16 valve||GM L3B Tripower engine ("TurboMax") - Detuned version. Direct Injection. VVT, VVL. Active Fuel Management. '23-'24 Chevy Colorado.
|-
| D ||LE3|| 4.1L || I6 || Gas ||OHV||2-bbl carb. Chevrolet Turbo-Thrift I6.<br /> '81-'84 Chevy/GMC C/K pickups, full-size vans, '81-'82 Blazer/Jimmy
|-
| D ||LG6|| 3.1L || V6 || Gas ||OHV||TBI. Chevrolet 60° V6. '90-'95 U-body minivans.
|-
| D ||L61|| 2.2L || I4 || Gas ||DOHC,<br /> 16 valve||SFI. GM Ecotec Gen I. '02-'07 Saturn Vue, '06 Chevy HHR.
|-
| D ||L61|| 2.2L || I4 || Gas ||DOHC,<br /> 16 valve||SFI. GM Ecotec Gen II. '07-'08 Chevy HHR.
|-
| D ||LLT|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. '09-'16 GMC Acadia, '17 GMC Acadia Limited,<br /> '09-'17 Chevrolet Traverse, Buick Enclave, '09-'10 Saturn Outlook
|-
| D ||LBZ|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine.<br /> Mid '06 Silverado HD/Sierra HD & '07 Silverado Classic HD/Sierra Classic HD
|-
| D ||L84|| 5.3L || V8 || Gas/E85 ||OHV|| Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. With Dynamic Fuel Management<br /> '19+ Chevy/GMC Silverado 1500/Sierra 1500, '21+ Tahoe/Yukon, Suburban/Yukon XL.
|-
| E ||LN8|| 2.5L || I4 || Gas ||OHV||TBI. Pontiac Iron Duke/Tech IV engine.<br /> '85-'90 Chevy/GMC S-10/S-15, Astro/Safari Cargo Van, '85-'88 S-10 Blazer/S-15 Jimmy.
|-
| E ||LLR|| 3.7L || I5 || Gas ||DOHC,<br /> 20 valve||Atlas I5. SFI. VVT.<br /> '07-'12 Colorado/Canyon, '07-'08 Isuzu i-370, '07-'10 Hummer H3, '09-'10 Hummer H3T
|-
| E ||LA1|| 3.4L || V6 || Gas ||OHV||Chevrolet 60° V6. '96 GMT199 (U-body) minivans, '97-'05 GMT200 (U-body) minivans,<br /> '01-'05 Pontiac Aztek, '02-'05 Buick Rendezvous
|-
| F ||LF3|| 5.0L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. '81-'86 C/K, full-size vans, '81-'82 Blazer/Jimmy.<br /> CA emissions version of LE9 5.0 V8.
|-
| F ||L65|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks '92-'02,<br /> Chevy/GMC Suburban 1500/2500 '94-'99, over-8,500 lb. GVWR Express/Savana '96-'02
|-
| F ||LNJ|| 3.4L || V6 || Gas ||OHV||Chevrolet 60° V6. Made in China by SAIC-GM. '05-'09 Chevy Equinox, '06-'09 Pontiac Torrent.
|-
| F ||L94|| 6.2L || V8 || Gas/E85 ||OHV||Flex-Fuel. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT. Active Fuel Management. '10-'14 GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV.
|-
| F ||L20|| 4.8L || V8 || Gas/E85 ||OHV|| Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads. VVT.<br /> '15-'17 Express/Savana
|-
| F ||L82|| 5.3L || V8 || Gas ||OHV|| Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. With Active Fuel Management<br /> '19-'21 Chevy Silverado 1500, GMC Sierra 1500 (T1XX).
|-
| G ||LG9|| 5.0L || V8 || Gas ||OHV|| 2-bbl carb. Gen I Chevrolet Small-Block V8. '81 Chevy/GMC C/K pickups, Blazer/Jimmy, full-size van
|-
| G ||L18|| 8.1L || V8 || Gas ||OHV||MFI. Vortec 8100. Gen VII Chevrolet Big-Block V8. '01-'02 C3500HD, '01-'06 Silverado HD/Sierra HD, '07 Silverado Classic HD/Sierra Classic HD, '01-'06 Suburban/Yukon XL 2500, '02-'06 Avalanche 2500, '01-'02 Express/Savana
|-
| G ||L96|| 6.0L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '10-'19 Silverado HD/Sierra HD, '10-'13 Suburban 2500/Yukon XL 2500, '16-'19 Suburban 3500,<br /> '10-'20 Express/Savana.
|-
| G ||LSD|| 1.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '23+ Chevy Equinox, GMC Terrain
|-
| H ||LG4|| 5.0L || V8 || Gas ||OHV||4-bbl carb. Gen I Chevy Small-Block V8. (305 cu. in.) '81-'87 Chevy El Camino, GMC Caballero.
|-
| H ||LE9|| 5.0L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. '81-'86 C/K pickups, Blazer/Jimmy, Suburban, full-size vans
|-
| H ||L03|| 5.0L || V8 || Gas ||OHV|| TBI. Gen I Chevrolet Small-Block V8. '87 R/V pickups, '88-'95 C/K, Sierra pickups, '87-'95 full-size vans, '87 Blazer/Jimmy, Suburban.
|-
| H ||LN2|| 2.2L || I4 || Gas ||OHV||SFI. Chevrolet "122" engine. '03 Chevy S-10/GMC Sonoma
|-
| H ||LS2|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevy Small-Block V8. Chevy SSR '05-'06, Trailblazer SS '06-'09, Saab 9-7X Aero '08-'09.
|-
| H ||LV3|| 4.3L || V6 || Gas/E85 ||OHV||Flex Fuel. Chevrolet 90° V6 - Gen V Chevrolet Small-Block V6 (EcoTec3). Direct injection, VVT. Active Fuel Management. '14-'21 Chevy Silverado 1500/GMC Sierra 1500.
|-
| J ||L39|| 4.4L || V8 || Gas ||OHV||2-bbl carb. Gen I Chevy Small-Block V8 (267 cu. in.) '81-82 Chevy El Camino, GMC Caballero.
|-
| J ||LL4|| 6.2L || V8 || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR trucks '82-'93. '82-'86 C/K pickups, '87-'91 R/V pickups,<br /> '88-'93 C/K, Sierra pickups, '82-'91 Blazer/Jimmy, Suburban, '83-'93 full-size vans
|-
| J ||L29|| 7.4L || V8 || Gas ||OHV|| MFI. Vortec 7400. Gen VI Chevrolet Big-Block V8.<br /> '96-'00 C/K, Sierra pickups, Express/Savana, '96-'99 Suburban 2500
|-
| J ||LY5|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. Iron Block & Aluminum Heads.<br /> '07-'09 Silverado/Sierra 1500, Tahoe/Yukon, Suburban/Yukon XL 1500, Avalanche
|-
| J ||LZ1|| 6.0L || V8 || Gas-Electric Hybrid ||OHV||2-Mode Hybrid. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT. Active Fuel Management. '10-'13 Tahoe Hybrid, Yukon Hybrid, Escalade Hybrid, Silverado Hybrid, Sierra Hybrid
|-
| J ||L86|| 6.2L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management. <br /> '14-18 Chevy/GMC Silverado 1500/Sierra 1500,<br /> '18-20 Chevy Tahoe Premier, '19-'20 Chevy Suburban Premier, GMC Yukon/Yukon XL SLT,<br /> '15-'20 GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV.
|-
| K ||LC3|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '81-'82 Chevy El Camino, GMC Caballero (49-state emissions)
|-
| K ||L05|| 5.7L || V8 || Gas ||OHV|| TBI. Gen I Chevrolet Small-Block V8. '87 R/V pickups, '88-'95 C/K, Sierra pickups, '87-'95 full-size vans, '96 G-Classic full-size vans, '87-'94 Blazer, '95 Tahoe, '87-'91 Jimmy, '92-'95 Yukon, '87-'95 Suburban.
|-
| K ||LY6|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '07-'09 Silverado HD/Sierra HD, '07-'09 Suburban 2500/Yukon XL 2500, '08-'09 Express/Savana
|-
| K ||LEA|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex Fuel. GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '12-'17,<br /> Chevy Captiva Sport '12-'14, Chevy Orlando '14.
|-
| K ||L3B|| 2.7L ||I4 Turbo||| Gas ||DOHC,<br /> 16 valve||GM L3B Tripower engine ("TurboMax"). Direct Injection. VVT, VVL. Active Fuel Management.<br /> '19+ Chevy Silverado 1500, GMC Sierra 1500, '23+ Chevy Colorado, GMC Canyon.
|-
| L ||LS9|| 5.7L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. For sub-8,500 lb. GVWR trucks, vans, Suburban, Blazer/Jimmy (CA) '81-'86.
|-
| L ||L27|| 3.8L || V6 || Gas ||OHV||Buick V6 (3800 Series I). '92-'95 U-body minivans
|-
| L ||LX9|| 3.5L || V6 || Gas ||OHV||GM High Value 60° V6. 3498cc. SFI. '05-'06 GMT201 minivans, '06-'07 Buick Rendezvous
|-
| L ||LH8|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads.<br /> '08-'09 Hummer H3 Alpha, '09 Colorado/Canyon, Hummer H3T Alpha
|-
| L ||LGH|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. Mid '10-'16 Express/Savana, '11-'12 Silverado HD/Sierra HD chassis cabs
|-
| L ||L87|| 6.2L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Dynamic Fuel Management.<br /> '19+ Chevy/GMC Silverado 1500/Sierra 1500, '21+ Tahoe/Yukon, Suburban/Yukon XL,<br /> Cadillac Escalade/Escalade ESV.
|-
| L ||L3T|| 1.3L || I3 Turbo || Gas ||DOHC,<br /> 12 valve||GM E-Turbo Engine. Direct Injection. VVT. '20+ Buick Encore GX, '21+ Chevy Trailblazer.
|-
| M ||LT9|| 5.7L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevy Small-Block V8.<br /> For over-8,500 lb. GVWR C/K trucks, full-size vans, Suburban '81-'86, full-size van cutaway '81-'88.<br /> '88 Chevy/GMC R30/3500 Chassis Cab w/C7C (10,500 lb. GVWR),<br /> V30/3500 Chassis Cab w/C7E (11,000 lb. GVWR)
|-
| M ||L30|| 5.0L || V8 || Gas ||OHV||Gen 1+ Chevrolet Small-Block V8. Vortec 5000. CPI.<br /> '96-'99 Chevy C/K, GMC Sierra, '96-'02 Express/Savana
|-
| M ||LNF|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. 2010 Chevy HHR SS.
|-
| M ||LH6|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. Aluminum Block & Heads.<br /> '05-'06 GMT370 SUVs (Trailblazer EXT/Envoy XL/Isuzu Ascender 7-psgr.), '05-'07 Buick Rainier,<br /> '05-'09 GMC Envoy Denali, Saab 9-7X, '06-'08 Chevy Trailblazer, '05 GMC Envoy XUV,<br /> '07-'09 Silverado/Sierra 1500
|-
| M ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Orlando '12.
|-
| M ||LE2|| 1.4L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '16-'19 & '21-'22 Buick Encore, '21-'22 Chevy Trax.
|-
| N ||L10|| 1.8L || I4 || Gas ||SOHC,<br /> 8 valve||2-bbl carb. Isuzu G180Z engine imported from Japan. '81-'82 Chevy LUV
|-
| N ||LF9|| 5.7L || V8 || Diesel ||OHV||Oldsmobile Diesel V8. '83-'84 Chevy El Camino/GMC Caballero.
|-
| N ||LB1|| 4.3L || V6 || Gas ||OHV|| 4-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '85 Astro/Safari, '85-'86 C/K pickups & full-size vans
|-
| N ||L19|| 7.4L || V8 || Gas ||OHV|| Mark IV Chevrolet Big-Block V8. TBI.<br /> '87-'90 R/V pickups, Suburban 2500, '88-'90 C/K, Sierra pickups, full-size vans
|-
| N ||L19|| 7.4L || V8 || Gas ||OHV|| Gen V Chevrolet Big-Block V8. TBI.<br /> '91 R/V pickups, '91-'95 C/K, Sierra pickups, Suburban 2500, full-size vans. '96 G-Classic full-size vans
|-
| N ||LZ4|| 3.5L || V6 || Gas ||OHV||GM High Value 60° V6. 3510cc. SFI. VVT. '08-'09 Saturn Vue
|-
| N ||LQ9|| 6.0L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Vortec 6000 H.O. or VortecMAX. Iron Block/Aluminum Heads.<br /> 345 hp. '02-'06 Cadillac Escalade, '03-'06 Cadillac Escalade ESV, '03-'06 Chevy Silverado SS,<br /> '05-'06 GMC Sierra Denali, '07 GMC Sierra Classic Denali.
|-
| N ||LGZ|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. Direct Injection. VVT. Active Fuel Management.<br /> '17-'22 Chevy Colorado, GMC Canyon.
|-
| P ||L49|| 6.5L || V8 || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks & full-size vans '94-'95
|-
| P ||LM4|| 5.3L || V8 || Gas ||OHV||Gen III Chevrolet Small-Block V8. Vortec 5300. 290hp. Aluminum Block & Heads.<br /> '03-'04 Chevy SSR, '03-'04 GMT370 SUVs (Trailblazer EXT/Envoy XL/Isuzu Ascender 7-psgr.),<br /> '04 Buick Rainier, GMC Envoy XUV
|-
| P ||LE5|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||MFI. GM Ecotec Gen II. VVT. '06-'08 Chevy HHR, '08-'09 Saturn Vue
|-
| P ||LH9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT.<br /> '10-'12 Colorado/Canyon, '10 Hummer H3 Alpha, H3T Alpha
|-
| P ||LV1|| 4.3L || V6 || Gas ||OHV||Chevrolet 90° V6 - Gen V Chevrolet Small-Block V6 (EcoTec3). Direct injection, VVT.<br /> '18+ Chevy Express/GMC Savana.
|-
| P ||LBP|| 1.2L || I3 Turbo || Gas/E85 ||DOHC,<br /> 12 valve||Flex Fuel. GM E-Turbo Engine. Direct Injection. VVT.<br /> '25+ Buick Encore GX, Chevy Trailblazer, '25- Chevy Trax, Buick Envista.
|-
| R ||LL2|| 2.8L || V6 || Gas ||OHV||TBI. Chevrolet 60° V6. '86-'93 Chevy S-10, GMC S-15/Sonoma,<br /> '86-'89 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| R ||L31|| 5.7L || V8 || Gas ||OHV||Gen 1+ Chevrolet Small-Block V8. Vortec 5700. CPI.<br /> '96-'99 Chevy C/K, GMC Sierra, '96-'99 Chevy Tahoe/GMC Yukon, Chevy/GMC Suburban, '99-'00 GMC Yukon Denali, Cadillac Escalade, '00 Chevy Tahoe Limited/Z71, '96-'02 Chevy Express/GMC Savana.
|-
| R ||L8B|| 5.3L || V8 || Gas ||OHV||Mild Hybrid. Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management. '16-'18 Chevy Silverado 1500, GMC Sierra 1500.
|-
| S ||LQ7|| 2.2L || I4 || Diesel ||OHV||Isuzu C220 engine imported from Japan. '81-'82 Chevy LUV, '84-'85 Chevy S-10/GMC S-15
|-
| S ||L56|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks '94-'99,<br /> Chevy Blazer '94, Chevy Tahoe 2-d '95-'99, GMC Yukon 2-d '94-'97
|-
| S ||LL8|| 4.2L || I6 || Gas ||DOHC,<br /> 24 valve||Atlas I6. SFI. VVT. '02-'09 GMT360/370 SUVs (Chevy Trailblazer, GMC Envoy, Oldsmobile Bravada, Buick Rainier, Isuzu Ascender, Saab 9-7X)
|-
| S ||LGX|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. Direct Injection. VVT. Active Fuel Management.<br /> '17+ Cadillac XT5, '17-'23 GMC Acadia, '19+ Chevrolet Blazer, '20-'25 Cadillac XT6.
|-
| S ||LK0|| 2.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||L3B engine family. Direct Injection. VVT. '24- Chevy Traverse, GMC Acadia, '25- Buick Enclave
|-
| T ||L25|| 4.8L || I6 || Gas ||OHV||1-bbl carb. Chevrolet Turbo-Thrift I6. '81-'86 Chevy/GMC C/K pickups, '88 R/V pickups
|-
| T ||LM7|| 5.3L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads. Vortec 5300. 270/285/295hp.<br /> '99-'07 GMT800 pickups & SUVs including '02-'05 Escalade 2wd, '07 Silverado Classic 1500/<br> Sierra Classic 1500, '03-'07 Express/Savana
|-
| T ||LEA|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex Fuel. GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Orlando '13.
|-
| T ||LM2|| 3.0L || I6 Turbo|| Diesel ||DOHC,<br /> 24 valve|| Duramax Diesel I6. Aluminum Block & Heads. '20-'22 Silverado/Sierra 1500, '21-'24 Tahoe/Suburban, Yukon/Yukon XL, Escalade/Escalade ESV.
|-
| U ||LS5|| 1.6L || I4 || Gas ||SOHC,<br /> 8 valve||Suzuki G16A engine. TBI. '89-'95 Geo Tracker
|-
| U ||LQ4|| 6.0L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads (Iron Heads in '99-'00).<br /> '99-'06 GMT800 pickups, '07 Silverado Classic 1500HD/Sierra Classic 1500HD,<br> '00-'06 Suburban/Yukon XL 2500, '01-'06 Yukon Denali/Yukon XL Denali,<br> '06 Suburban LTZ, '03-'07 Express/Savana, '03-'07 Hummer H2.
|-
| U ||LE9|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. GM Ecotec Gen II. 2011 Chevy HHR
|-
| U ||LH7|| 1.6L ||I4 Turbo|| Diesel ||DOHC,<br /> 16 valve||GM Medium Diesel engine ("Whisper Diesel"). Made by Opel in Szentgotthárd, Hungary.<br /> Aluminum Block & Heads. '18-'19 Chevy Equinox & GMC Terrain Diesel.
|-
| V ||LR4|| 4.8L || V8 || Gas ||OHV||Gen III Chevrolet Small-Block V8. Iron Block/Aluminum Heads.<br> '99-'06 GMT800 pickups, '07 Silverado Classic 1500/Sierra Classic 1500,<br /> '00-'06 Tahoe/Yukon, '03-'07 Express/Savana
|-
| V ||LE9|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. GM Ecotec Gen II. 2009-2010 Chevy HHR
|-
| V ||LYX|| 1.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '18-'22 Chevy Equinox, GMC Terrain
|-
| W ||LE8|| 7.4L || V8 || Gas ||OHV|| Mark IV Chevrolet Big-Block V8. 4bbl carb. '81-'86 Chevy/GMC C/K pickups, Suburban.<br /> '88-'89 Chevy/GMC R30/3500 Chassis Cab w/C7C (10,500 lb. GVWR),<br /> V30/3500 Chassis Cab w/C7E (11,000 lb. GVWR)
|-
| W ||L35|| 4.3L || V6 || Gas ||OHV|| CPI. Vortec 4300 H.O. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '92-'95 Sonoma, S-10 Blazer/Jimmy, Astro/Safari, '94-'95 S-10, '92-'94 Oldsmobile Bravada
|-
| W ||L35|| 4.3L || V6 || Gas ||OHV|| SFI. Vortec 4300 H.O. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '96-'02 S-10/Sonoma, Blazer/Jimmy, Express/Savana, C/K, Silverado, Sierra, '96-'01 Bravada, Astro/Safari, '00 Isuzu Hombre
|-
| W ||LGD|| 3.9L || V6 || Gas/E85 ||OHV||Flex Fuel. GM High Value 60° V6. SFI. VVT. '07-'09 GMT201 minivans
|-
| W ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '10.
|-
| W ||LE8|| 2.2L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. SFI. GM Ecotec Gen II. VVT. 2011 Chevy HHR.
|-
| W ||LFY|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection.<br> '18-'23 Chevrolet Traverse, '24 Chevrolet Traverse Limited, '18-'24 Buick Enclave.
|-
| X ||LF6|| 4.3L || V6 || Gas ||OHV||SFI. Vortec 4300. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '96-'99 S-10/Sonoma, '97-'99 Isuzu Hombre.
|-
| X ||LU3|| 4.3L || V6 || Gas ||OHV||Vortec 4300. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '03-'04 S-10/Sonoma,<br /> '03-'05 Blazer/Jimmy, '02-'05 Astro/Safari, '03-'14 Express/Savana, '03-'13 Silverado/Sierra,<br> '07 Silverado Classic 1500/Sierra Classic 1500
|-
| X ||LNF|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. '08-'09 Chevy HHR SS.
|-
| X ||LTG|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. VVT.<br /> '16-'20 Buick Envision, '18-'20 Chevy Equinox, GMC Terrain, '18-'19 Chevy Traverse RS
|-
| Y ||LQ2|| 2.0L || I4 || Gas ||OHV||2-bbl carb. Chevrolet "122" engine.<br /> '83-'84 Chevy S-10/GMC S-15, '83-'84 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| Y ||L57|| 6.5L || V8 || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR full-size vans '94-'95 & '96 G-Classic full-size vans
|-
| Y ||L76|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevy Small-Block V8. Aluminum Block & Heads. VVT. With Active Fuel Management.<br /> '07-'09 Silverado/Sierra, Suburban/Yukon XL, Chevy Avalanche
|-
| Y ||LF1|| 3.0L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. VVT.<br /> '10-'11 Cadillac SRX, '11 Saab 9-4X, '10 Chevy Equinox, GMC Terrain
|-
| Y ||L5P|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '17+ Silverado HD/Sierra HD. Engine updated in '24.
|-
| Z ||LF9|| 5.7L || V8 || Diesel ||OHV||Oldsmobile Diesel V8. '81 Chevy C10/GMC C1500 full-size pickups.
|-
| Z ||LB4|| 4.3L || V6 || Gas ||OHV|| TBI. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '85-'87 Chevy El Camino/GMC Caballero,<br /> '86-'94 Astro/Safari, '87 R/V pickups, '88-'95 C/K & Sierra pickups, '87-'95 full-size vans & <br /> '96 G-Classic full-size vans, '88-'95 S-10, S-15/Sonoma, '88-'94 S-10 Blazer, S-15 Jimmy,<br /> '91-'92 Oldsmobile Bravada
|-
| Z ||LB4|| 4.3L || V6 Turbo || Gas ||OHV|| MPI. For GMC Syclone & Typhoon. Chevrolet 90° V6 (Chevy Small-Block V8 Derived)
|-
| Z ||L59|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads. Vortec 5300. 285/295hp.<br /> '02-'07 GMT800 pickups, '07 Silverado Classic 1500/Sierra Classic 1500,<br> '02-'06 Suburban/Yukon XL, Avalanche.
|-
| Z ||LAT|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||Mild Hybrid. MFI. GM Ecotec Gen II. VVT. '07-'09 Saturn Vue Green Line
|-
| 1 ||LZ9|| 3.9L || V6 || Gas ||OHV||GM High Value 60° V6. SFI. VVT. '06-'09 GMT201 minivans
|-
| 1 ||LE5|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||MFI. GM Ecotec Gen II. VVT. '10 Saturn Vue.
|-
| 1 ||LB7|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. First version of the Duramax V8. '01-Mid '04 Silverado HD/Sierra HD
|-
| 1 ||LWN|| 2.8L || I4 Turbo || Diesel ||DOHC,<br /> 16 valve||Based on VM Motori A428 engine. Made by GM Powertrain Thailand 2016-2020. Made in Brazil for '22. '16-'22 Colorado/Canyon, '17-'22 Express/Savana.
|-
| 2 ||LLY|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. Mid '04-Mid '06 Silverado HD/Sierra HD, '06-Mid '07 Express/Savana
|-
| 2 ||L9H|| 6.2L || V8 || Gas/E85 ||OHV||Flex-Fuel. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT.<br /> '09-'13 Chevy Silverado 1500, GMC Sierra 1500, Sierra Denali 1500,<br /> '09 Chevy Tahoe LTZ, GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV,<br> Hummer H2
|-
| 2 ||LIH|| 1.2L || I3 Turbo || Gas ||DOHC,<br /> 12 valve||GM E-Turbo Engine. Direct Injection. VVT.<br /> '20-'24 Buick Encore GX, '21-'24 Chevy Trailblazer, '24 Chevy Trax, Buick Envista,<br> '25 Chevy Trax, Buick Envista (Canada only).
|-
| 3 ||LC9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT added for '10. Aluminum Block & Heads.<br /> '07-'11 Silverado/Sierra 1500, Tahoe/Yukon, Suburban/Yukon XL 1500, '07-'09 & '11 Avalanche
|-
| 3 ||LFX|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. VVT. E85 Flex Fuel.<br /> '12-'16 Cadillac SRX, '13-'17 Chevrolet Equinox, GMC Terrain, '15-'16 Colorado/Canyon
|-
| 4 ||LN2|| 2.2L || I4 || Gas ||OHV||MFI (94-95). SFI (96-00). Chevrolet "122" engine. '94-'00 S-10/Sonoma, '96-'00 Isuzu Hombre
|-
| 4 ||LE8|| 2.5L || V6 || Gas ||DOHC,<br /> 24 valve||Suzuki H25A engine. MFI. '01-'04 Chevrolet Tracker
|-
| 4 ||L66|| 3.5L || V6 || Gas ||SOHC,<br /> 24 valve||Honda J35S1 V6. VTEC. '04-'07 Saturn Vue
|-
| 4 ||LMF|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '08-'14 Express/Savana 1500
|-
| 4 ||LAU|| 2.8L || V6 Turbo || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. SFI. '10 Cadillac SRX
|-
| 4 ||LSY|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. Active Fuel Management. VVT. VVL.<br /> '19-'25 Cadillac XT4, '20+ Chevy Blazer, Cadillac XT5, '20-'23 GMC Acadia,<br /> '21+ Buick Envision, '21-'25 Cadillac XT6
|-
| 5 ||L43|| 2.2L || I4 || Gas/E85 ||OHV||Flex-Fuel. SFI. Chevrolet "122" engine. '00-'02 S-10/Sonoma, '00 Isuzu Hombre
|-
| 5 ||LFA|| 6.0L || V8 || Gas-Electric Hybrid ||OHV||2-Mode Hybrid. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT. Active Fuel Management. '08-'09 Tahoe Hybrid/Yukon Hybrid, '09 Escalade Hybrid, Silverado Hybrid/Sierra Hybrid
|-
| 5 ||LFW|| 3.0L || V6 || Gas/E85 ||DOHC,<br /> 24 valve||Flex-Fuel. GM High Feature V6. Direct Injection. VVT. '11-'12 Chevy Equinox, GMC Terrain,<br /> '12 Chevy Captiva Sport
|-
| 6 ||L01|| 1.6L || I4 || Gas ||SOHC,<br /> 16 valve||Suzuki G16B engine. MFI. '94-'97 Geo Tracker, '98-'00 Chevrolet Tracker
|-
| 6 ||L52|| 3.5L || I5 || Gas ||DOHC,<br /> 20 valve||Atlas I5. SFI. VVT. '04-'06 Colorado/Canyon, '06 Isuzu i-350, '06 Hummer H3
|-
| 6 ||LAU|| 2.8L || V6 Turbo || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. SFI. '11 Cadillac SRX, Saab 9-4X
|-
| 6 ||LMM|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '07-'10 Silverado HD/Sierra HD (GMT900), Mid '07-Mid '10 Express/Savana
|-
| 7 ||LY7|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. '04-'06 Buick Rendezvous, '04-'09 Cadillac SRX,<br /> '07-'08 GMC Acadia, Saturn Outlook, '08 Buick Enclave, '08-'10 Saturn Vue
|-
| 7 ||LC9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT.<br /> Aluminum Block & Heads.<br /> '12-'13 Silverado/Sierra 1500, Avalanche, '12-'14 Tahoe/Yukon, Suburban/Yukon XL 1500
|-
| 7 ||L8T|| 6.6L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8. Iron Block/Aluminum Heads. Direct injection, VVT.<br /> '20+ Silverado HD/Sierra HD, '21+ Express/Savana
|-
| 8 ||LK5|| 2.8L || I4 || Gas ||DOHC,<br /> 16 valve||Atlas I4. SFI. VVT. '04-'06 Colorado/Canyon, '06 Isuzu i-280.
|-
| 8 ||L92|| 6.2L || V8 || Gas ||OHV||Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT.<br /> '07-'08 GMC Sierra Denali, Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV,<br> '08 Chevy Tahoe LTZ, Hummer H2.
|-
| 8 ||LML|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine.<br /> '11-'16 Silverado HD/Sierra HD pickups, '13-'16 Silverado HD/Sierra HD chassis cabs.
|-
| 8 ||LZ0|| 3.0L || I6 Turbo|| Diesel ||DOHC,<br /> 24 valve|| Duramax Diesel I6. Aluminum Block & Heads.<br> '23+ Silverado/Sierra 1500, '24+ Suburban HD, '25+ Tahoe/Suburban, Yukon/Yukon XL.
|-
| 9 ||LC3|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '83-'84 Chevy El Camino, GMC Caballero (49-state emissions).
|-
| 9 ||LLV|| 2.9L || I4 || Gas ||DOHC,<br /> 16 valve||Atlas I4. SFI. VVT. '07-'12 Colorado/Canyon, '07-'08 Isuzu i-290.
|-
| 9 ||LT4|| 6.2L ||V8 Supercharged|| Gas ||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. Direct injection. VVT. Active Fuel Management. '23+ Cadillac Escalade/Escalade ESV V-Series.
|-
| 0 ||LMG|| 5.3L || V8 || Gas/E85 ||OHV||Flex-Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT added for '10.<br /> Iron Block & Aluminum Heads.<br /> '07-'13 Silverado/Sierra 1500, Avalanche, '07-'14 Tahoe/Yukon, Suburban/Yukon XL 1500.
|}
H.O.=High Output, VVT=Variable Valve Timing, VVL=Variable Valve Lift, GVWR=Gross Vehicle Weight Rating, CNG=Compressed Natural Gas, LPG=Liquefied Petroleum Gas (Propane Autogas)
====Motor codes for electric light trucks====
{| class="wikitable"
|-
! VIN !! RPO !! Fuel !! Drive Wheels !! Application/Notes
|-
| H ||LN1|| Electricity || Front || '97-'98 Chevrolet S-10 Electric.
|-
|}
====Motor codes for Ultium-powered electric light trucks====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Module <br /> RPO code !! # of Modules !! Fuel !! Drive Wheels !! Application/Notes
|-
| A ||XRL|| 3 || ETN || 24 || Electricity || All || '22- GMC Hummer EV pickup 3X
|-
| B ||XRL|| 3 || ETI || 20 || Electricity || All || '24- GMC Hummer EV pickup 3X
|-
| C ||XRL|| 3 || ETJ || 20 || Electricity || All || '24- GMC Hummer EV SUV 3X
|-
| D ||XRJ|| 2 || ETI || 20 || Electricity || All || '24 Chevrolet Silverado EV 3WT, '25- Silverado EV 5WT, 3LT,<br> '25 Silverado EV RST (2SP), '26- Silverado EV Trail Boss (2TR),<br> '24- GMC Hummer EV pickup 2X, '25- GMC Sierra EV Denali 5SC,<br> '26- Sierra EV Elevation 3SC, AT4 4SC
|-
| E ||XRJ|| 2 || ETJ || 20 || Electricity || All || '24- GMC Hummer EV SUV 2X
|-
| G ||XRJ|| 2 || ETJ || 20 || Electricity || All || '23 BrightDrop Zevo 600
|-
| H ||XRJ|| 2 || EWX || 14 || Electricity || All ||'26- Chevrolet Silverado EV 4WT, 2LT,<br> '26- GMC Sierra EV Elevation 3SB, Denali 5SB
|-
| J ||X0C|| 2 || EC5 || 10 || Electricity || All || '24 Chevy Blazer EV 2LT, 1RS AWD,<br> '25- Chevy Blazer EV 4LT, 3RS AWD, '24-'26 Honda Prologue AWD
|-
| K ||X0D|| 1 || EC6 || 12 || Electricity || Rear || '23- Cadillac Lyriq RWD, '24-'25 Chevrolet Blazer EV 2RS RWD,<br> '24 Acura ZDX A-Spec RWD
|-
| L ||X0E|| 2 || EC6 || 12 || Electricity || All || '23- Cadillac Lyriq AWD, '24- Chevrolet Blazer EV PPV AWD,<br> '25- Chevrolet Blazer EV SS AWD, '26- Cadillac Vistiq AWD,<br> '24 Acura ZDX A-Spec, Type S AWD
|-
| L ||XRJ|| 2 || ETN || 24 || Electricity || All || '24 Chevrolet Silverado EV 4WT, RST (3SP), '25- Silverado EV 8WT,<br> '25 Silverado EV RST (3SP), '26- Silverado EV 4LT, Trail Boss (3TR),<br> '24- GMC Sierra EV Denali 5SD, '26- Sierra EV AT4 4SD,<br> '25- Cadillac Escalade IQ, '26- Cadillac Escalade IQL
|-
| M ||X0B|| 1 || EC5 || 10 || Electricity || Front || '24-'26 Honda Prologue FWD, '25- Chevy Blazer EV 2LT, 1RS FWD
|-
| P ||X0B|| 1 || EC3 || 10 || Electricity || Front || '24- Chevrolet Equinox EV FWD
|-
| R ||X0C|| 2 || EC3 || 10 || Electricity || All || '24- Chevrolet Equinox EV AWD, '25 Cadillac Optiq AWD
|-
| Y ||XRJ|| 2 || ETC || 12 || Electricity || All || '24 BrightDrop Zevo 400, Zevo 600,<br> '25-'26 Chevrolet BrightDrop 400/600 AWD
|-
| Z ||XRJ|| 2 || ETJ || 20 || Electricity || All || '24 BrightDrop Zevo 400, Zevo 600,<br> '25-'26 Chevrolet BrightDrop 400/600 AWD
|-
| 4 ||X0E|| 2 || EC3 || 10 || Electricity || All || '26- Cadillac Optiq AWD
|-
| 5 ||X0D|| 1 || EC3 || 10 || Electricity || Rear|| '26- Cadillac Optiq RWD
|-
| 6 ||XRM|| 1 || ETC || 12 || Electricity || Front || '25-'26 Chevrolet BrightDrop 400/600 FWD
|-
| 7 ||XRJ|| 2 || EWU || 14 || Electricity || All || '26 Chevrolet BrightDrop 600 AWD
|}
SB=Standard Range, SC=Extended Range, SD=Max Range
====Engine codes for medium duty trucks 2016-====
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes/Applications
|-
| B ||L96|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '16-'20 Chevy LCF 3500/4500.
|-
| C ||LC8|| 6.0L || V8 || Gas/CNG or<br>Gas/LPG ||OHV||Bi-Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '16-'20 Chevy LCF 3500/4500.
|-
| D ||L8T|| 6.6L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8. Iron Block/Aluminum Heads. Direct injection, VVT.<br /> '21-'23 Chevy LCF 3500/4500, '24- Chevy LCF 3500HG/4500HG/5500HG/5500XG.
|-
| F ||LCB|| 6.7L || I6 Turbo || Diesel ||OHV,<br /> 32 valve||Cummins B Series ISB engine. '22- Chevy LCF 6500XD, '23- Chevy LCF 7500XD.
|-
| 6 ||I1B|| 5.2L || I4 Turbo || Diesel ||SOHC,<br /> 16 valve||Isuzu 4HK1-TC engine. '17- Chevy LCF 4500HD/XD, 5500XD, '17-'24 Chevy LCF 5500HD,<br /> '18-'21 Chevy LCF 6500XD.
|-
| 7 ||IZ3|| 3.0L || I4 Turbo || Diesel ||DOHC,<br /> 16 valve||Isuzu 4JJ1-TC engine. '16-'18 Chevy LCF 3500HD.
|-
|}
====Engine codes for AM General-built Hummer H1 2000-2006====
AM General encodes the engine type in character 4 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| F || || 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8 built by GEP (General Engine Products), a subsidiary of AM General.<br> '01-'04 Hummer H1 & '06 H1 Fleet models.
|-
| P ||LLY|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '06 Hummer H1 Alpha.
|-
| Z ||L65|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8 built by GM. '00-'01 Hummer H1.
|-
|}
====Engine codes for Nissan-built vans====
Nissan encodes the engine type in character 4 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| 3 ||L0A|| 2.0L || I4 || Gas ||DOHC,<br /> 16 valve||Nissan MR20DE engine. SFI. VVT. For the '15-'18 Chevrolet City Express.
|-
|}
====Engine codes for Navistar-built medium-duty trucks====
Navistar encodes the engine type in character 6 & 7 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| PV ||L5D|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. For the Chevy Silverado Medium Duty '19+.
|-
|}
==GM factories supplying North America==
===North American GM factories===
[[w:List_of_General_Motors_factories | List of GM Factories]]
{| class="wikitable"
!VIN code
!Location
!Notes
|-
|A
|Lakewood Assembly (Lakewood Heights, Atlanta, Georgia)
|through 1990 model year
|-
|A
|Artisan Center (Warren, Michigan)
|From 2026 model year. Cadillac CT5-V Blackwing "Curated by Cadillac" program only.
|-
|B
|Baltimore Assembly (Baltimore, Maryland)
|through 2005 model year
|-
|B
|Reatta Craft Centre/Lansing Craft Centre (Lansing Township, Michigan)
|1988-2006 model year (except GM EV1)
|-
|B
|GM Defense-Manufacturing Customer Innovation Center (MCIC) (Concord, North Carolina)
|From 2024 model year. Chevrolet Suburban HD (a.k.a. HD SUV) (for US govt. only).
|-
|C
|South Gate Assembly (South Gate, California)
|through 1982 model year
|-
|C
|Lansing Car Assembly (Lansing, Michigan)
|South assembly line 1985-2004 model year
|-
|D
|Doraville Assembly (Doraville, Georgia)
|through 2009 model year
|-
|E
|Linden Assembly (Linden, New Jersey)
|through 1991 model year
|-
|E
|Pontiac East Assembly (Pontiac, Michigan)
|1988-2009 model year
|-
|E
|AM General Military plant (Mishawaka, Indiana)
|1992-2006 Hummer H1
|-
|F
|Flint Truck Assembly (Flint, Michigan)
|since 1953
|-
|F
|Fairfax II Assembly (Kansas City, Kansas)
|since 1988 model year
|-
|G
|Framingham Assembly (Framingham, Massachusetts)
|through 1989 model year
|-
|G
|Silao Assembly (Silao, Guanajuato, Mexico)
|since 1995 model year
|-
|H
|Buick City Assembly (Flint, Michigan)
|through 1999 model year
|-
|H
|AM General Commercial plant (Mishawaka, Indiana)
|2003-2009 Hummer H2
|-
|H
|Navistar Springfield plant (Main Line) (Springfield, Ohio)
|2019- Chevrolet Silverado Medium Duty (4500HD/5500HD/6500HD)
|-
|J
|Janesville Assembly (Janesville, Wisconsin)
|through 2009 model year
|-
|J
|Lansing Delta Township Assembly (Lansing, Michigan)
|since 2007 model year
|-
|K
|Leeds Assembly (Leeds, Kansas City, Missouri)
|through 1988 model year
|-
|K
|Linden Assembly (Linden, New Jersey)
|from 1994-2005 model year
|-
|K
|Nissan plant (Cuernavaca, Morelos, Mexico)
|2015-2018 Chevrolet City Express
|-
|L
|Van Nuys Assembly (Van Nuys, California)
|through 1992 model year
|-
|L
|San Luis Potosí Assembly (San Luis Potosí, Mexico)
|since 2009 model year
|-
|M
|Lansing Car Assembly (Lansing, Michigan)
|through 1984 model year, North assembly line 1985-2005 model year
|-
|M
|Toluca Assembly (Toluca, Mexico state, Mexico)
|through 2008 model year
|-
|N
|Norwood Assembly (Norwood, Ohio)
|through 1987 model year
|-
|N
|Navistar Springfield plant (Secondary Line) (Springfield, Ohio)
|2017- Chevrolet Express cutaway, GMC Savana cutaway
|-
|P
|Pontiac Assembly (Pontiac, Michigan)
|through 1988 model year
|-
|R
|Arlington Assembly (Arlington, Texas)
|since 1965 [all GM brands]. (R plant code used only by Chevrolet in 1963-64)
|-
|S
|St. Louis Assembly (St. Louis, Missouri)
|through 1987 model year
|-
|S
|Spring Hill Manufacturing (Spring Hill, Tennessee)
|2002-2007 Saturn Vue & 2009-2010 Chevrolet Traverse only
|-
|S
|Spartan Motors/Shyft Group plant (Charlotte, Michigan)
|2016- Chevrolet Low Cab Forward 3500/3500HG/4500/4500HG/5500HG/5500XG/6500XD/7500XD
|-
|S
|Ramos Arizpe Assembly (Ramos Arizpe, Coahuila, Mexico)
|since 1982
|-
|T
|Tarrytown Assembly (North Tarrytown, New York)
|through 1996 model year
|-
|U
|Detroit/Hamtramck Assembly (Factory Zero) <br /> (Detroit & Hamtramck, Michigan)
|since 1986 model year
|-
|U
|Artisan Center (Warren, Michigan)
|From 2025 model year. Cadillac Celestiq only.
|-
|V
|Pontiac Central Assembly (Pontiac, Michigan)
|through 1991 model year
|-
|V
|Pontiac East Assembly (Pontiac, Michigan)
|through 1985 model year
|-
|W
|Willow Run Assembly (Ypsilanti Township, Michigan)
|through 1993 model year
|-
|X
|Fairfax Assembly (Fairfax I) (Kansas City, Kansas)
|through 1987 model year
|-
|Y
|Wilmington Assembly (Wilmington, Delaware)
|through 2010 model year
|-
|Z
|Fremont Assembly (Fremont, California)
|through 1982 model year
|-
|Z
|NUMMI (Fremont, California)
|1985-2010 model year
|-
|Z
|Spring Hill Manufacturing (Spring Hill, Tennessee)
|since 1991 model year (except Vue & Traverse)
|-
|Z
|Fort Wayne Assembly (Roanoke, Indiana)
|since 1988 model year
|-
|0
|Pontiac West Assembly (Pontiac, Michigan)
|through 1994 model year
|-
|0
|Lansing Craft Centre (Lansing Township, Michigan)
|GM EV1 only
|-
|0
|Lansing Grand River Assembly (Lansing, Michigan)
|since 2003 model year
|-
|0
|Artisan Center (Warren, Michigan)
|2024 Cadillac CT5-V Blackwing 20th Anniversary Edition where the final eight digits of the VIN are R0912004 through R0912024 or R0962004 through R0962024
|-
|1
|Wentzville Assembly (Wentzville, Missouri)
|since 1985 model year
|-
|1
|Oshawa Car Assembly (Oshawa, Ontario, Canada)
|from 1967-1983 model year
|-
|1
|Oshawa Car Assembly (Line 2 a.k.a. Consolidated Line) (Oshawa, Ontario, Canada)
|from 1984-2019 model year; switched to pickup trucks for 2019 model year
|-
|1
|Oshawa Car Assembly (Oshawa, Ontario, Canada)
|Silverado pickup trucks since 2022 model year
|-
|1
|Oshawa Truck Assembly (Oshawa, Ontario, Canada)
|through 2009 model year
|-
|2
|Moraine Assembly (Moraine, Ohio)
|through 2009 model year
|-
|2
|Sainte-Thérèse Assembly (Boisbriand, Quebec, Canada)
|through 2002 model year
|-
|3
|Detroit Truck & Bus plant (Piquette Ave., Detroit, Michigan)
|through 1999 model year
|-
|3
|Saint-Eustache Bus Plant (Saint-Eustache, Quebec, Canada)
|through 1987 model year
|-
|4
|Orion Assembly (Orion Township, Michigan)
|since 1985 model year
|-
|4
|Scarborough Van Assembly (Scarborough, Ontario, Canada)
|through 1993 model year
|-
|5
|Bowling Green Assembly (Bowling Green, Kentucky)
|since 1981 model year
|-
|6
|Oklahoma City Assembly (Oklahoma City, Oklahoma)
|through 2006 model year
|-
|6
|CAMI plant (Ingersoll, Ontario, Canada)
|1990-2022 model year
|-
|7
|Lordstown Assembly (Warren, Ohio)
|from 1979-2019 model year
|-
|8
|Shreveport Assembly (Shreveport, Louisiana)
|through 2012 model year
|-
|9
|Detroit Assembly (Clark Street, Detroit, Michigan)<br> (Cadillac plant)
|from 1979-1988 model year
|-
|9
|Oshawa Car Assembly (Line 1 a.k.a. Flex Line)<br> (Oshawa, Ontario, Canada)
|from 1984-2020 model year
|-
|9
|KUKA plant (Livonia, Michigan)
|2022 model year only (BrightDrop Zevo 600)
|-
|9
|CAMI plant (Ingersoll, Ontario, Canada)
|2023-2026 model year (BrightDrop Zevo/Chevrolet BrightDrop)
|}
===Non-North American GM factories supplying North America===
{| class="wikitable"
!VIN code
!Location
!Models Sourced
|-
|A
|SAIC-GM plant: Jinqiao, Pudong district, Shanghai, China
|2017-2018 Cadillac CT6 Plug-in Hybrid
|-
|B
|Daewoo/GM Daewoo/GM Korea plant: Bupyeong, South Korea
|1988-1993 Pontiac LeMans, 2004-2011 Chevrolet Aveo, 2005-2010 Pontiac Wave/G3, 2004-2006 Chevrolet <br /> Epica (Canada), 2013-2022 Chevrolet Trax, Buick Encore, 2021- Chevrolet Trailblazer, 2020- Buick Encore GX, 2024- Buick Envista
|-
|C
|GM Daewoo/GM Korea plant: Changwon, South Korea
|2003-2010 Pontiac Matiz/Matiz G2 (Mexico), 2013-2022 Chevrolet Spark, 2024- Chevrolet Trax
|-
|D
|SAIC-GM Dongyue Motors plant: Yantai, Shandong province, China
|2016- Buick Envision, 2019-2023 Chevrolet Aveo (Mexico), 2023- Chevrolet Onix (Mexico)
|-
|G
|Opel plant: Gliwice, Poland
|2016-2019 Buick Cascada
|-
|K
|Suzuki plant: Kosai, Shizuoka prefecture, Japan
|1985-1988 Chevrolet Sprint, 1989-1990 Geo Metro hatchback, 1990-1993 Geo Metro convertible, 1985-1990 Pontiac Firefly (Canada), 1991 & 1994 Pontiac Firefly convertible & sedan (Canada)
|-
|K
|GM Daewoo/GM Korea plant: Kunsan, South Korea
|2004-2007 Chevrolet Optra (Canada), 2012-2014 Chevrolet Orlando (Canada)
|-
|L
|Holden plant: Elizabeth, South Australia, Australia
|2004-2006 Pontiac GTO, 2008-2009 Pontiac G8, 2011-2017 Chevrolet Caprice PPV, 2014-2017 Chevrolet SS
|-
|R
|Opel plant: Rüsselsheim, Germany
|1997-2001 Cadillac Catera
|-
|T
|GM India plant: Talegaon, Maharashtra, India
|2017-2021 Chevrolet Spark Classic/Beat (Mexico)
|-
|V
|SAIC-GM Wuhan plant: Wuhan, Hubei province, China
|2018-2021 Chevrolet Cavalier (Mexico), 2022- Chevrolet Cavalier Turbo (Mexico)
|-
|W
|Suzuki plant: Iwata, Shizuoka prefecture, Japan
|1989-1990 Geo Tracker
|-
|1
|Opel plant: Rüsselsheim, Germany
|2011, 2018-2020 Buick Regal
|-
|3
|Isuzu plant: Kawasaki, Kanagawa prefecture, Japan
|1987-1998 Chevrolet/GMC W5, 1989-1996 Chevrolet/GMC W6, 1984-1996 Chevrolet/GMC W7
|-
|5
|Opel plant: Antwerp, Belgium
|2008-2009 Saturn Astra
|-
|7
|Isuzu plant: Fujisawa, Kanagawa prefecture, Japan
|1988 Chevrolet Spectrum, 1988 Pontiac Sunburst (Canada), 1989 Geo Spectrum, 1990-1993 Geo Storm,<br /> 1999-2008 Chevrolet/GMC W3500, 1988-2009 Chevrolet/GMC W4, 1999-2009 Chevrolet/GMC W5,<br /> 2000-2004 Chevrolet/GMC WT5500,<br /> 2016- Chevrolet Low Cab Forward 3500HD/4500HD/4500XD/5500HD/5500XD
|-
|8
|Isuzu plant: Fujisawa, Kanagawa prefecture, Japan
|1981-1982 Chevrolet LUV, 1985-1987 Chevrolet Spectrum, 1985-1987 Pontiac Sunburst (Canada),<br /> 1986-1987 Chevrolet/GMC W4
|}
==GM WMIs==
{| class=wikitable
!WMI
!Marque
!Country
|-
|1G1||rowspan=57|Chevrolet||United States
|-
|1G8||United States (MPV 1981-1986)
|-
|1GA||United States (bus [van with more than 3 rows of seats])
|-
|1GB||United States (incomplete vehicle)
|-
|1GC||United States (truck)
|-
|1GN||United States (MPV 1987-)
|-
|1HA||United States (Express incomplete vehicle made by Navistar)
|-
|1HT||United States ([[w:Chevrolet Silverado#Medium duty version_(4500HD,_5500HD,_6500HD,_and_International_CV)|Silverado Medium Duty]] incomplete vehicle made by Navistar)
|-
|1Y1||United States (made by NUMMI)
|-
|2C1||Canada (car made by CAMI)
|-
|2CN||Canada (SUV made by CAMI - 1998-2011)
|-
|2G1||Canada
|-
|2G5||Canada (truck - Chevrolet BrightDrop '25)
|-
|2G8||Canada (MPV 1981-1986)
|-
|2GA||Canada (bus [van with more than 3 rows of seats])
|-
|2GB||Canada (incomplete vehicle)
|-
|2GC||Canada (truck - includes Chevrolet BrightDrop '26)
|-
|2GN||Canada (MPV 1987-)
|-
|3G1||Mexico
|-
|3GC||Mexico (truck)
|-
|3GN||Mexico (MPV)
|-
|3N6||Mexico (Truck - City Express made by Nissan)
|-
|4G1||United States (made by Genasys L.C.)
|-
|4KB||United States (W-Series incomplete vehicle made by GM - through 2009)
|-
|4W1||United States (MPV - Chevrolet Suburban HD made for US govt. in Concord, NC)
|-
|54D||United States (incomplete vehicle made by Spartan Motors/The Shyft Group)
|-
|6G1||Australia (2011-2013 Caprice PPV)
|-
|6G3||Australia (2014-2017 Caprice PPV & SS performance sedan)
|-
|ADM||South Africa
|-
|J81||Japan (car made by Isuzu)
|-
|J8B||Japan (incomplete vehicle made by Isuzu - through 2009)
|-
|J8Z||Japan (LUV pickup made by Isuzu)
|-
|JAL||Japan (incomplete vehicle made by Isuzu - 2016+)
|-
|JG1||Japan (car made by Suzuki)
|-
|KL1||South Korea (car)
|-
|KL7||South Korea (MPV - 2012+)
|-
|KL8||South Korea (Spark)
|-
|LSF||China (S-10 Max made by SAIC-Maxus - Mexico only)
|-
|LSG||China (SAIC-GM)
|-
|LSH||China (Express Max made by SAIC-Maxus - Mexico only)
|-
|LZW||China (SAIC-GM-Wuling)
|-
|MA6||India
|-
|MJB||Indonesia (GM Indonesia)
|-
|MK3||Indonesia (SGMW Motor Indonesia)
|-
|MMM||Thailand
|-
|XUF||Russia (GM Russia - St. Petersburg plant)
|-
|XUU||Russia (Chevrolet Korea models made by Avtotor in Kaliningrad)
|-
|XWB||Uzbekistan (GM Uzbekistan, UzAuto Motors)
|-
|XWF||Russia (Chevrolet Tahoe & Trailblazer [GMT360] made by Avtotor in Kaliningrad)
|-
|X9L||Russia (GM-AvtoVAZ)
|-
|8AG||Argentina
|-
|8GG||Chile
|-
|8LD||Ecuador
|-
|8Z1||Venezuela
|-
|9BG||Brazil
|-
|93C||Brazil
|-
|9GC||Colombia
|-
|J81||rowspan=6|Geo||Japan (car made by Isuzu)
|-
|JG1||Japan (car made by Suzuki)
|-
|JGC||Japan (SUV made by Suzuki)
|-
|1Y1||United States (car made by NUMMI)
|-
|2C1||Canada (car made by CAMI)
|-
|2CN||Canada (SUV made by CAMI - 1990-1997)
|-
|KLA||rowspan=3|GM Daewoo/<br />GM Korea||South Korea (Bupyeong & Kunsan plants)
|-
|KLY||South Korea (Changwon plant)
|-
|5GD||United States (G2X)
|-
|1G2||rowspan=12|Pontiac||United States
|-
|1G5||United States (incomplete vehicle - for '89-'90 Turbo Grand Prix by ASC/McLaren & '03-'05 Montana Mobility, '06 Montana SV6 Mobility)
|-
|1GM||United States (MPV)
|-
|2CK||Canada (2006-2009 Torrent made by CAMI)
|-
|2G2||Canada
|-
|2G7||Canada (US market 1983 Pontiac Parisienne)
|-
|3G2||Mexico
|-
|3G7||Mexico (MPV: 2001-2005 Aztek)
|-
|4G2||United States (made by Genasys L.C.)
|-
|5Y2||United States (made by NUMMI)
|-
|6G2||Australia
|-
|KL2||South Korea (made by Daewoo/GM Daewoo)
|-
|1G7||rowspan=6|Pontiac<br />(Canada only)||United States
|-
|2C7||Canada (car made by CAMI)
|-
|2CG||Canada (SUV made by CAMI)
|-
|2G7||Canada
|-
|J87||Japan (car made by Isuzu)
|-
|JG7||Japan (car made by Suzuki)
|-
|KL7||Passport<br />(Canada only)||South Korea (car made by Daewoo)
|-
|J87||rowspan=3|Asüna<br />(Canada only)||Japan (car made by Isuzu)
|-
|KL7||South Korea (car made by Daewoo)
|-
|2CG||Canada (SUV made by CAMI)
|-
|1G3||rowspan=3|Oldsmobile||United States
|-
|1GH||United States (MPV/SUV)
|-
|2G3||Canada
|-
|1G4||rowspan=9|Buick||United States
|-
|2G4||Canada
|-
|3G4||Mexico
|-
|3G5||Mexico (MPV)
|-
|4GL||United States (incomplete vehicle)
|-
|5GA||United States (MPV)
|-
|KL4||South Korea (MPV)
|-
|LRB||China (SAIC-GM)
|-
|W04||Germany & Poland
|-
|KLA||Alpheon||South Korea (2011-2015)
|-
|1G6||rowspan=10|Cadillac||United States
|-
|1GE||United States (incomplete vehicle)
|-
|1GY||United States (SUV)
|-
|2G6||Canada
|-
|2GE||Canada (incomplete vehicle)
|-
|3GY||Mexico (SUV)
|-
|LRE||China (SAIC-GM)
|-
|W06||Germany
|-
|XWF||Russia (made by Avtotor in Kaliningrad)
|-
|YSC||Sweden
|-
|1G8||rowspan=4|Saturn||United States
|-
|3GS||Mexico (SUV)
|-
|5GZ||United States (MPV/SUV)
|-
|W08||Belgium
|-
|1G0||rowspan=22|GMC||United States (bus 1981-1986)
|-
|1G5||United States (MPV 1981-1986)
|-
|1GD||United States (incomplete vehicle)
|-
|1GJ||United States (bus 1987-)
|-
|1GK||United States (MPV 1987-)
|-
|1GT||United States (truck)
|-
|2CK||Canada (1990-1991 Tracker made by CAMI - Canada only)
|-
|2CT||Canada (2010-2011 Terrain made by CAMI)
|-
|2G0||Canada (bus [van with more than 3 rows of seats] 1981-1986)
|-
|2G5||Canada (MPV 1981-1986)
|-
|2GD||Canada (incomplete vehicle)
|-
|2GH||Canada (transit bus)
|-
|2GJ||Canada (bus [van with more than 3 rows of seats] 1987-)
|-
|2GK||Canada (MPV 1987-)
|-
|2GT||Canada (truck)
|-
|3GK||Mexico (SUV)
|-
|3GT||Mexico (truck)
|-
|4KD||United States (W-Series incomplete vehicle made by GM - through 2009)
|-
|7GZ||United States (incomplete vehicle made by Navistar)
|-
|J8D||Japan (incomplete vehicle made by Isuzu - through 2009)
|-
|JGT||Japan (SUV made by Suzuki - Canada only)
|-
|KL6||South Korea (Middle East market Terrain '08-'10)
|-
|4GD||WhiteGMC||United States (1988-1989 Brigadier made by GM)
|-
|137||rowspan=6|Hummer||United States (H1 made by AM General)
|-
|5GN||United States (H3T)
|-
|5GR||United States (H2 made by AM General)
|-
|5GT||United States (H3)
|-
|ADM||South Africa (H3)
|-
|XWF||Russia (H2 & H3 made by Avtotor in Kaliningrad)
|-
|4G5||General Motors||United States (EV1)
|-
|2G5||rowspan=2|BrightDrop||Canada (Truck 2023-2024)
|-
|5G5||United States (Truck made by Kuka AG - 2022 only)
|-
|5G2||rowspan=2|Cruise||United States (car) (Cruise AV)
|-
|5G3||United States (MPV) (Cruise Origin AV)
|-
|YS3||rowspan=4|Saab||Sweden
|-
|JF4||Japan (9-2X made by Subaru)
|-
|3G0||Mexico (9-4X)
|-
|5S3||United States (9-7X)
|-
|W0L||rowspan=19|Opel/Vauxhall||Germany & the rest of Europe (2017 and earlier)
|-
|W0V||Germany & the rest of Europe (2018 and later) & Opel Ampera-e Mid-2017 - 2019
|-
|W0L||when plant code is H: Thailand (Zafira A)
|-
|W0L||when plant code is 0: South Korea (Antara) or B: South Korea (Antara, Mokka A, Mokka X [A])
|-
|W0L||when plant code is C: South Korea (Opel Karl/Vauxhall Viva)
|-
|W0V||when plant code is B: South Korea (Mokka X [A]) or C: South Korea (Opel Karl/Vauxhall Viva)
|-
|SCC||UK (Opel Lotus Omega made by Lotus)
|-
|SED||UK (made by IBC Vehicles)
|-
|TW8||Portugal
|-
|VF1||France (Arena made by Renault)
|-
|VN1||France (Movano A made by Renault at SOVAB plant in Batilly, France)
|-
|VSX||Spain
|-
|XUF||Russia (Opel made by GM Russia - St. Petersburg plant)
|-
|XWF||Russia (Opel made by Avtotor in Kaliningrad)
|-
|1G0||United States (Opel GT, Opel/Vauxhall Ampera, Opel Ampera-e Early - Mid-2017)
|-
|4GD||United States (Sintra)
|-
|ADM||South Africa
|-
|JAA||Japan (Opel Campo made by Isuzu)
|-
|JAC||Japan (Monterey made by Isuzu)
|-
|SKA||rowspan=4|Vauxhall Motors||UK
|-
|SCC||UK (Vauxhall Lotus Carlton made by Lotus)
|-
|6G1||Australia (Vauxhall Monaro & VXR8 made by Holden)
|-
|JAA||Japan (Vauxhall Brava made by Isuzu)
|-
|SKF||rowspan=2|Bedford Vehicles||UK
|-
|JAA||Japan (Bedford Brava made by Isuzu)
|-
|6G1||rowspan=18|Holden||Australia (2003-2017)
|-
|6H8||Australia (1989-2002)
|-
|JAA||Japan (Rodeo pickup [TF] made by Isuzu)
|-
|JAC||Japan (Jackaroo/Monterey made by Isuzu)
|-
|JSA||Japan (YG Cruze made by Suzuki)
|-
|KL3||South Korea
|-
|MMM||Thailand ('09-'11 Colorado pickup [RC] made by GM Thailand)
|-
|MMU||Thailand ('13-'20 Colorado pickup [RG], '13-'16 Colorado 7, '17-'20 Trailblazer made by GM Thailand)
|-
|MPA||Thailand ('04-'08 Rodeo pickup [RA] made by Isuzu Thailand)
|-
|SED||UK (1st gen. Frontera made by IBC Vehicles)
|-
|W0L||Germany & the rest of Europe (2017 and earlier)
|-
|W0L||when plant code is H: Thailand (Zafira A)
|-
|W0V||Germany & the rest of Europe (2018-2020)
|-
|1GH||United States (Acadia)
|-
|3G0||Mexico (Equinox)
|-
|3GM||Mexico (Suburban)
|-
|4S2||United States (2nd gen. Frontera made by [[w:Subaru Isuzu Automotive|SIA]])
|-
|5G8||United States (Volt)
|-
|1GG||rowspan=4|Isuzu||United States (Truck - Hombre & i-Series made by GM)
|-
|4GT||United States (H-Series & T-Series incomplete vehicle made by GM - through 2009)
|-
|4KL||United States (N-Series incomplete vehicle made by GM - through 2009)
|-
|4NU||United States (MPV/SUV - Ascender made by GM)
|-
|W0L||Subaru||Thailand [plant code H] (Traviq made by GM Thailand for export to Japan)
|-
|4G3||Toyota||United States (Cavalier made by GM for export to Japan)
|-
|3GP||Honda||Mexico (MPV/SUV: 2024-2026 Prologue made by GM)
|-
|4W5||Acura||United States (MPV/SUV: 2024 ZDX EV made by GM)
|}
{{BookCat}}
fvd60epnmcw4wkaigdbdms52l3enemr
4655964
4655962
2026-07-31T20:29:36Z
JustTheFacts33
3434282
/* Series 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle */
4655964
wikitext
text/x-wiki
{{Vehicle Identification Numbers (VIN codes)/Warning}}{{clear}}
It is the tenth digit that gives you the model year for GM. I've been working at a Chevy dealer for years running codes/vins. For example (my examples only apply to 2001-2015 gm vehicles)
Remember 10th digit from the beginning, (left to right).
2001... 1,
2002...2,
2003...3,
etc.,
2009...9.
After 2009, the tenth digit was given a letter
2010... A,
2011...B,
2012...C,
2013...D,
2014...E,
2015...F,
Etc...
We have another 20 years worth of letters.
Thanks for reading.
You can always check your model year by looking in your drivers side door jamb and it will give you model year. If it was assembled in July or later, the model year is probably a year later than the calendar year of the manufacturing date listed.
==American GM==
===American VIN format 1981-1984 Passenger Car===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>A</td><td></td><td></td><td>[[#American restraint types 1981-1984|Restraint type]]</td>
</tr><tr>
<td>5</td>
<td>M</td><td></td><td></td><td>[[#Car Line & Series Code 1981-1984|Car Line & Series Code]]</td>
</tr><tr>
<td>6</td>
<td>4</td><td></td><td></td><td rowspan=2>[[#Body style codes 1981-1986|Body style]]</td>
</tr><tr>
<td>7</td>
<td>7</td><td></td><td></td><td> </td>
</tr><tr>
<td>8</td>
<td>8</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>E</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>9</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====American restraint types 1981-1984====
The restraint type is specified as character 4 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|A||Manual Seatbelts only - No Passive Restraint
|}
====Car Line & Series Code 1981-1984====
The Car Line & Series Code is specified as character 5 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!List of GM platforms
!Car Line & <br> Series Code
!:Category:General Motors vehicles|Model
|-
|rowspan=19|GM A platform - rear-wheel drive
|T||Chevrolet Malibu 1981
|-
|W||Chevrolet Malibu Classic 1981
|-
|Z||Chevrolet Monte Carlo 1981
|-
|D||Pontiac LeMans 1981
|-
|F||Pontiac Grand LeMans 1981
|-
|J||Pontiac Grand Prix 1981
|-
|K||Pontiac Grand Prix LJ 1981
|-
|P||Pontiac Grand Prix Brougham 1981
|-
|G||Oldsmobile Cutlass sedan, Cutlass Cruiser wagon 1981
|-
|H||Oldsmobile Cutlass Cruiser ''Brougham'' wagon 1981
|-
|K||Oldsmobile Cutlass Calais coupe 1981
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1981
|-
|R||Oldsmobile Cutlass Supreme coupe, Cutlass LS sedan 1981
|-
|E||Buick Century wagon 1981
|-
|H||Buick Century sedan, Estate wagon 1981
|-
|J||Buick Regal 1981
|-
|K||Buick Regal ''Sport'' 1981
|-
|L||Buick Century ''Limited'' 1981
|-
|M||Buick Regal ''Limited'' 1981
|-
|rowspan=10|GM A platform - front-wheel drive
|W||Chevrolet Celebrity 1982-1984
|-
|F||Pontiac 6000 1982-1984
|-
|G||Pontiac 6000 ''LE'' 1982-1984
|-
|H||Pontiac 6000 ''STE'' 1983-1984
|-
|G||Oldsmobile Cutlass Ciera 1982
|-
|J||Oldsmobile Cutlass Ciera ''LS'' 1982-1984, Cutlass Cruiser ''LS'' 1984
|-
|M||Oldsmobile Cutlass Ciera ''Brougham'' 1982-1984
|-
|G||Buick Century ''T-Type'' 1983-1984
|-
|H||Buick Century ''Custom'' 1982-1984
|-
|L||Buick Century ''Limited'' 1982-1984
|-
|rowspan=19|GM B platform
|D||Chevrolet Bel Air 1981 (Canada only)
|-
|L||Chevrolet Impala 1981-1984
|-
|N||Chevrolet Caprice Classic 1981-1984
|-
|F||Pontiac Laurentian 1981 (Canada only)
|-
|L||Pontiac Catalina 1981, Parisienne 1984
|-
|L||Pontiac Parisienne 1982-1983 (Canada only)
|-
|N||Pontiac Bonneville 1981
|-
|N||Pontiac Parisienne 1981, Parisienne Brougham 1982-1983 (Canada only)
|-
|R||Pontiac Bonneville Brougham 1981
|-
|T||Pontiac Parisienne Brougham 1984
|-
|L||Oldsmobile Delta 88 1981-1983
|-
|N||Oldsmobile Delta 88 Royale 1981-1984
|-
|P||Oldsmobile Custom Cruiser 1981-1984
|-
|V||Oldsmobile Delta 88 Royale Brougham LS 1984
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1981-1984
|-
|N||Buick Le Sabre 1981, Le Sabre ''Custom'' 1982-1984
|-
|P||Buick Le Sabre ''Limited'' 1981-1984
|-
|R||Buick Le Sabre Estate Wagon 1981-1983
|-
|V||Buick Electra Estate Wagon 1981-1984
|-
|rowspan=13|GM C platform - rear-wheel drive
|G||Oldsmobile 98 Regency 1984
|-
|H||Oldsmobile 98 Regency Brougham 1984
|-
|V||Oldsmobile 98 Luxury 1981
|-
|W||Oldsmobile 98 Regency Brougham 1982-1983
|-
|X||Oldsmobile 98 Regency 1981-1983
|-
|R||Buick Electra Limited 1984
|-
|U||Buick Electra Park Avenue 1984
|-
|W||Buick Electra Park Avenue 1981-1983
|-
|X||Buick Electra Limited 1981-1983
|-
|B||Cadillac Fleetwood Brougham 1981-1983
|-
|D||Cadillac DeVille 1981-1983
|-
|M||Cadillac DeVille 1984
|-
|W||Cadillac Fleetwood Brougham 1984
|-
|rowspan=1|GM D platform - rear-wheel drive
|F||Cadillac Fleetwood Limousine 1981-1984
|-
|rowspan=4|GM E platform
|Z||Oldsmobile Toronado Brougham 1981-1984
|-
|Y||Buick Riviera T-Type 1981-1984
|-
|Z||Buick Riviera 1981-1984
|-
|L||Cadillac Eldorado 1981-1984
|-
|rowspan=7|GM F platform
|P||Chevrolet Camaro Sport Coupe 1981-1984
|-
|S||Chevrolet Camaro Berlinetta 1981-1984
|-
|S||Pontiac Firebird 1981-1984
|-
|T||Pontiac Firebird ''Esprit'' 1981
|-
|V||Pontiac Firebird ''Formula'' 1981
|-
|W||Pontiac Firebird ''Trans Am'' 1981-1984
|-
|X||Pontiac Firebird ''Trans Am'' Turbo Special Edition 1981, Firebird ''S/E'' 1982-1984
|-
|rowspan=15|GM G platform - rear-wheel drive
|W||Chevrolet Malibu Classic 1982, Malibu 1983
|-
|Z||Chevrolet Monte Carlo 1982-1984
|-
|J||Pontiac Grand Prix 1982-1984
|-
|K||Pontiac Grand Prix LJ 1982-1983, Grand Prix LE 1984
|-
|N||Pontiac Bonneville G 1982-1984
|-
|P||Pontiac Grand Prix Brougham 1982-1984
|-
|R||Pontiac Bonneville G Brougham 1982-1984
|-
|S||Pontiac Bonneville G ''LE'' 1984
|-
|H||Oldsmobile Cutlass Cruiser wagon 1982-1983
|-
|K||Oldsmobile Cutlass Calais coupe 1982-1984
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1982-1984
|-
|R||Oldsmobile Cutlass Supreme coupe & sedan 1982-1984
|-
|J||Buick Regal 1982-1984
|-
|K||Buick Regal ''Sport'' 1982, Regal ''T-Type'' 1983-1984
|-
|M||Buick Regal ''Limited'' 1982-1984
|-
|rowspan=13|GM J platform
|C||Chevrolet Cavalier 1983-1984
|-
|D||Chevrolet Cavalier 2-d/4-d/wagon 1982, Cavalier CS 1983-1984
|-
|E||Chevrolet Cavalier 3-door hatchback 1982, Cavalier CS 3-door hatchback 1983, Cavalier Type 10 2-d/3-d/Convertible 1984
|-
|B||Pontiac J2000 1982, 2000 1983, 2000 Sunbird 1984
|-
|C||Pontiac J2000 LE 1982, 2000 LE 1983, 2000 Sunbird LE Convertible 1983, 2000 Sunbird LE 1984
|-
|D||Pontiac J2000 SE 1982, 2000 SE 1983, 2000 Sunbird SE 1984
|-
|E||Pontiac J2000 S 1982
|-
|C||Oldsmobile Firenza Base model 1982-1984, Firenza S 1982-1984
|-
|D||Oldsmobile Firenza LX 1982-1984, Firenza SX 1982-1984
|-
|E||Buick Skyhawk T-Type 1983-1984
|-
|S||Buick Skyhawk Custom 1982-1984
|-
|T||Buick Skyhawk Limited 1982-1984
|-
|G||Cadillac Cimarron 1982-1984
|-
|rowspan=1|GM K platform
|S||Cadillac Seville 1981-1984
|-
|rowspan=3|GM P platform
||E||Pontiac Fiero ''Coupe'' 1984
|-
||F||Pontiac Fiero ''SE'' 1984
|-
||M||Pontiac Fiero ''Sport coupe'' 1984
|-
|rowspan=6|GM T platform - rear-wheel drive
|B||Chevrolet Chevette 1981-1983, Chevette CS 1984
|-
|J||Chevrolet Chevette Scooter 1981-1983, Chevette 1984
|-
|B||Pontiac Acadian 1981-1984 (Canada only)
|-
|J||Pontiac Acadian S 1981-1982, Pontiac Acadian Scooter 1983-1984 (Canada only)
|-
|L||Pontiac T1000 1982, 1000 1983-1984
|-
|M||Pontiac T1000 1981
|-
|rowspan=10|GM X platform
|H||Chevrolet Citation 2-door coupe 1982-1983, Citation II 2-door coupe 1984
|-
|X||Chevrolet Citation hatchback 1981-1983, Citation II hatchback 1984
|-
|T||Pontiac Phoenix SJ 1982-1983, Phoenix SE 1984
|-
|Y||Pontiac Phoenix 1981-1984
|-
|Z||Pontiac Phoenix LJ 1981-1983, Phoenix LE 1984
|-
|B||Oldsmobile Omega 1981-1984
|-
|E||Oldsmobile Omega Brougham 1981-1984
|-
|B||Buick Skylark 1981-1982, Skylark Custom 1983-1984
|-
|C||Buick Skylark Limited 1981-1984
|-
|D||Buick Skylark Sport 1981-1982, Skylark T-Type 1983-1984
|-
|rowspan=1|GM Y platform
|Y||Chevrolet Corvette 1981-1982, 1984
|}
===American VIN format 1985-1986 Passenger Car===
GM has traditionally encoded the platform as the 4th character of the VIN. Other content includes an engine code and manufacturing plant. GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>D</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Platform]]</td>
</tr><tr>
<td>5</td>
<td>W</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Series Code]]</td>
</tr><tr>
<td>6</td>
<td>6</td><td></td><td></td><td rowspan=2>[[#Body style codes 1981-1986|Body style]]</td>
</tr><tr>
<td>7</td>
<td>9</td><td></td><td></td><td> </td>
</tr><tr>
<td>8</td>
<td>Y</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>G</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>9</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====Body style codes 1981-1986====
The Body type is specified as characters 6 and 7 of the American GM VIN for passenger cars from 1981-1986.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|11,27,37,47,57,97||Two-Door Coupe/Sedan
|-
|07,08,77,87||Two-Door Hatchback
|-
|67||Two-Door Convertible
|-
|19,69||Four-Door Sedan
|-
|68||Four-Door Hatchback
|-
|23||Four-Door Limousine, 8-passenger ("Limousine")
|-
|33||Four-Door Limousine w/Center Partition, 7-passenger ("Formal Limousine")
|-
|35||Four-Door Station Wagon
|}
===American VIN format 1987- Passenger Car===
GM has traditionally encoded the platform as the 4th character of the VIN. Other content includes an engine code and manufacturing plant. GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>6</td><td></td><td></td></tr><tr>
<td>4</td>
<td>D</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Platform]]</td>
</tr><tr>
<td>5</td>
<td>M</td><td></td><td></td><td>[[#Platform & Series Codes 1985- Passenger Car|Series Code]]</td>
</tr><tr>
<td>6</td>
<td>5</td><td></td><td></td><td>[[#Body style codes 1987- Passenger Car|Body style]]</td>
</tr><tr>
<td>7</td>
<td>7</td><td></td><td></td><td>[[#American restraint types 1987-|Restraint type]]</td>
</tr><tr>
<td>8</td>
<td>N</td><td></td><td></td><td>[[#American engine codes 1981-|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>3</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>0</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
===American VIN format 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>K</td><td></td><td></td></tr><tr>
<td>4</td>
<td>E</td><td></td><td></td><td>[[#GVWR/Brake System 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|GVWR/Brake System]]</td>
</tr><tr>
<td>5</td>
<td>K</td><td></td><td></td><td>[[#Line & Chassis Type 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 1981-1999]]</td>
</tr><tr>
<td>5</td>
<td>K</td><td></td><td></td><td>[[#Line & Chassis Type 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 2000-2009]]</td>
</tr><tr>
<td>6</td>
<td>1</td><td></td><td></td><td>[[#Series 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle|Series]]</td>
</tr><tr>
<td>7</td>
<td>8</td><td></td><td></td><td>[[#Body style codes 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle|Body type]]</td>
</tr><tr>
<td>8</td>
<td>K</td><td></td><td></td><td>[[#Engine codes for light trucks|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>N</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>J</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====GVWR/Brake System 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The GVWR/Brake System is specified as character 4 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!GVWR Range in lbs. & Weight Class
!Brake System
|-
|A||Class A: 0-3,000||Hydraulic
|-
|B||Class B: 3,001-4,000||Hydraulic
|-
|C||Class C: 4,001-5,000||Hydraulic
|-
|D||Class D: 5,001-6,000||Hydraulic
|-
|E||Class E: 6,001-7,000||Hydraulic
|-
|F||Class F: 7,001-8,000||Hydraulic
|-
|G||Class G: 8,001-9,000||Hydraulic
|-
|H||Class H: 9,001-10,000||Hydraulic
|-
|J||Class 3: 10,001-14,000||Hydraulic
|-
|K||Class 4: 14,001-16,000||Hydraulic
|-
|L||Class 5: 16,001-19,500||Hydraulic
|}
====Line & Chassis Type 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|B||Special Body Buick, Chevrolet
|-
|C||Chevy full-size pickups & chassis cabs 2wd (C-series) '81-'86, '88-'99,<br /> GMC full-size pickups & chassis cabs 2wd (C-series) '81-'86, Sierra 2wd (C-series) '88-'99
|-
|C||Chevy C10 Blazer 2wd ('81-'82), Tahoe 4-door 2wd ('95-'99), Suburban 2wd ('81-'86, '92-'99),<br /> GMC C1500 Jimmy 2wd ('81-'82), Yukon 4-door 2wd ('95-'99), Suburban 2wd ('81-'86, '92-'99)
|-
|D||Military Truck 4wd
|-
|E||'91-'97 Geo Tracker 2wd, '98-'99 Chevrolet Tracker 2wd
|-
|E||'97-'98 Chevy S-10 EV
|-
|G||Chevy/GMC full-size vans (Chevy Van, Sportvan, Express, GMC Vandura, Rally Van, Savana)
|-
|H||'93-'96 Chevy G30HD/GMC G3500HD cutaway van
|-
|H||Cadillac chassis cutaway/special body (Based on Rwd Fleetwood '93-'96, Fwd DeVille '97-'99)
|-
|J||'89-'97 Geo Tracker 4wd, '98-'99 Chevrolet Tracker 4wd
|-
|K||Chevy full-size pickups & chassis cabs 4wd (K-series) '81-'86, '88-'99,<br /> GMC full-size pickups & chassis cabs 4wd (K-series) '81-'86, Sierra 4wd (K-series) '88-'99
|-
|K||Chevy K10/K5 Blazer 4wd ('81-'86, '92-'94), Tahoe 4wd ('95-'99), Suburban 4wd ('81-'86, '92-'99),<br /> GMC K1500 Jimmy 4wd ('81-'86), Yukon 4wd ('92-'99), Suburban 4wd ('81-'86, '92-'99), '99 Cadillac Escalade 4wd
|-
|L||Chevy Luv 2wd '81-'82
|-
|L||Chevy Astro/GMC Safari 4wd '90-'99
|-
|M||Chevy Astro/GMC Safari 2wd '85-'99
|-
|P||Forward Control (includes Chevrolet Step-Van/GMC Value-Van, Chevy/GMC P-Series)
|-
|R||Chevy Luv 4wd '81-'82
|-
|R||Chevy full-size pickups & chassis cabs 2wd (R-series), Suburban 2wd '87-'91,<br /> GMC full-size pickups & chassis cabs 2wd (R-series), Suburban 2wd '87-'91
|-
|S||Chevy S-10 2wd ('82-'99), S-10 Blazer 2wd ('83-'94), Blazer 2wd ('95-'99), GMC S-15 2wd ('82-'90), Sonoma 2wd ('91-'99),<br> S-15 Jimmy 2wd ('83-'91), Jimmy 2wd ('92-'99), Isuzu Hombre 2wd ('96-'99)
|-
|T||Chevy S-10 4wd ('83-'99), S-10 Blazer 4wd ('83-'94), Blazer 4wd ('95-'99), GMC S-15 4wd ('83-'90), Sonoma 4wd ('91-'99), Syclone 4wd ('91),<br> S-15 Jimmy 4wd ('83-'91), Jimmy 4wd ('92-'99), Typhoon 4wd ('92-93), Envoy 4wd ('98-'99), Oldsmobile Bravada 4wd ('91-'94, '96-'99),<br> Isuzu Hombre 4wd ('98-'99)
|-
|U||Regular length All-Purpose Vehicle ('90-'99 U-body fwd minivans)
|-
|V||Chevy full-size pickups & chassis cabs 4wd (V-series), V10/V1500 Blazer 4wd, Suburban 4wd '87-'91,<br /> GMC full-size pickups & chassis cabs 4wd (V-series), V1500 Jimmy 4wd, Suburban 4wd '87-'91
|-
|W||'81-'87 Chevy El Camino, GMC Caballero
|-
|X||Extended length All-Purpose Vehicle ('97-'99 U-body fwd extended length minivans)
|-
|Z||Cadillac chassis cutaway/special body (Based on Rwd Fleetwood '81-'84, Fwd Fleetwood '85-'92)
|}
====Line & Chassis Type 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Pontiac Aztek 2wd '01-'05, Buick Rendezvous 2wd '02-'07
|-
|A||Chevrolet HHR '06-'09, HHR Panel '07-'09
|-
|B||Pontiac Aztek Awd '01-'05, Buick Rendezvous Awd '02-'06
|-
|C||Chevy full-size pickups & chassis cabs 2wd (C-series) '00, full-size chassis cabs 2wd (C3500HD) '01-'02, Silverado 2wd '00-'09, Silverado Classic 2wd '07,<br /> GMC Sierra 2wd (C-series) '00-'09, Sierra Classic 2wd '00, '07
|-
|C||Chevy Tahoe 2wd ('00-'09), Suburban 2wd ('00-'09), Avalanche 2wd ('02-'09),<br /> GMC Yukon 2wd ('00-'09), Yukon XL 2wd ('00-'09), Cadillac Escalade 2wd ('02-'09), Escalade ESV 2wd ('08-'09)
|-
|E||Chevrolet Tracker 2wd '00-'04
|-
|E||Cadillac SRX 2wd & Awd '04-'09
|-
|G||Chevy/GMC full-size vans 2wd (Chevy Express, GMC Savana) '00-09
|-
|H||Chevy/GMC full-size vans 4wd (Chevy Express, GMC Savana) '03-09
|-
|H||Cadillac Commercial Chassis for Hearse (Based on Fwd DeVille '02-'05, DTS '06-'09)
|-
|H||Cadillac Professional Chassis for Limousine (Based on Fwd DeVille '00-'05, DTS '06-'07)
|-
|J||Chevrolet Tracker 4wd '00-'04
|-
|K||Chevy full-size pickups & chassis cabs 4wd (K-series) '00, Silverado 4wd '00-'09, Silverado Classic 4wd '07,<br /> GMC Sierra 4wd (K-series) '00-'09, Sierra Classic 4wd '00, '07
|-
|K||Chevy Tahoe 4wd ('00-'09), Suburban 4wd ('00-'09), Avalanche 4wd ('02-'09), GMC Yukon 4wd ('00-'09), Yukon XL 4wd ('00-'09),<br> Cadillac Escalade 4wd ('00, '02-'09), Escalade ESV 4wd ('03-'09), Escalade EXT 4wd ('02-'09)
|-
|K||Cadillac Professional Chassis for Limousine (Based on Fwd DTS '08-'09)
|-
|L||Chevy Astro/GMC Safari 4wd '00-'05
|-
|L||Chevy Equinox 2wd & Awd '05-'09, Pontiac Torrent 2wd & Awd '06-'09, Saturn Vue 2wd & Awd '08-'09
|-
|M||Chevy Astro/GMC Safari 2wd '00-'05
|-
|N||Hummer H2 '03-'09, H2 SUT '05-'09
|-
|N||Hummer H3 '06-'09, H3T '09
|-
|R||GMC Acadia 2wd, Saturn Outlook 2wd '07-'09, Buick Enclave 2wd '08-'09, Chevy Traverse 2wd '09
|-
|S||Chevy S-10 2wd ('00-'03), Blazer 2wd ('00-'05), GMC Sonoma 2wd ('00-'03), Jimmy 2wd ('00-'01), Isuzu Hombre 2wd ('00)
|-
|S||Chevy Trailblazer 2wd ('02-'09), SSR ('03-'06), GMC Envoy 2wd ('02-'09), Envoy XUV 2wd ('04-'05), Oldsmobile Bravada 2wd ('02-'04),<br> Buick Rainier 2wd ('04-'07), Isuzu Ascender 2wd ('03-'08)
|-
|S||Chevy Colorado 2wd ('04-'09), GMC Canyon 2wd ('04-'09), Isuzu i-series 2wd ('06-'08)
|-
|T||Chevy S-10 4wd ('00-'04), Blazer 4wd ('00-'05), GMC Sonoma 4wd ('00-'04), Jimmy 4wd ('00-'01, Canada only: '02-'05), Envoy 4wd ('00),<br> Oldsmobile Bravada 4wd ('00-'01), Isuzu Hombre 4wd ('00)
|-
|T||Chevy Trailblazer 4wd ('02-'09), GMC Envoy 4wd ('02-'09), Envoy XUV 2wd ('04-'05), Oldsmobile Bravada 4wd ('02-'04), Buick Rainier 4wd ('04-'07),<br> Isuzu Ascender 4wd ('03-'08), Saab 9-7X 4wd ('05-'09)
|-
|T||Chevy Colorado 4wd ('04-'09), GMC Canyon 4wd ('04-'09), Isuzu i-series 4wd ('06-'08)
|-
|U||Regular length All-Purpose Vehicle [Minivan] ('00-'04 Chevy Venture, Pontiac Montana)
|-
|U||Regular length All-Purpose Vehicle [Minivan] (Chevy Uplander [US: '06-'08, Canada only: '05-'09], Pontiac Montana SV6 [Canada only: '05-'09])
|-
|V||Extended length AWD All-Purpose Vehicle [Minivan] ('02-'04 Chevy Venture, Pontiac Montana, Oldsmobile Silhouette Extended length AWD)
|-
|V||Extended length FWD All-Purpose Vehicle [Minivan] ('05 Chevy Venture, Pontiac Montana Extended length FWD)
|-
|V||Extended length FWD All-Purpose Vehicle [Minivan] (Chevy Uplander ['05-'08, Canada only: '09], Pontiac Montana SV6 ['05-'06, Canada only: '07-'09],<br> Buick Terraza ['05-'07], Saturn Relay ['05-'07])
|-
|V||GMC Acadia Awd, Saturn Outlook Awd '07-'09, Buick Enclave Awd '08-'09, Chevy Traverse Awd '09
|-
|X||Extended length FWD All-Purpose Vehicle [Minivan] ('00-'04 Chevy Venture, Pontiac Montana, Oldsmobile Silhouette Extended length FWD)
|-
|X||Extended length AWD All-Purpose Vehicle [Minivan] ('05-'06 Chevy Uplander AWD, Pontiac Montana SV6 AWD, Buick Terraza AWD, Saturn Relay AWD)
|-
|Z||Saturn Vue 2wd & Awd '02-'07
|}
====Series 1981-1999 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1||1/2 Ton (includes '96-'99 Isuzu Hombre)
|-
|2||3/4 Ton
|-
|3||1 Ton
|-
|8||1/2 Ton ('81-'87 El Camino, Caballero)
|-
|9||Cadillac, Buick, Chevrolet Commercial Body/Chassis
|-
|0||All-Purpose Vehicle ('90-'99 U-body fwd minivans)
|}
====Series 2000-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1 <br> (following A)||Chevrolet HHR LS ('06-'07)
|-
|2 <br> (following A)||Chevrolet HHR LT ('06-'07)
|-
|3 <br> (following A)||Chevrolet HHR LT ('07)
|-
|1 <br> (following A)||Chevrolet HHR LS w/auto. trans. ('08-'09)
|-
|2 <br> (following A)||Chevrolet HHR 1LT w/auto. trans. ('08-'09)
|-
|3 <br> (following A)||Chevrolet HHR LS w/man. trans. ('08-'09)
|-
|4 <br> (following A)||Chevrolet HHR 1LT w/man. trans. ('08-'09)
|-
|5 <br> (following A)||Chevrolet HHR 2LT (all transmissions) ('08-'09)
|-
|6 <br> (following A)||Chevrolet HHR SS w/auto. trans. ('08-'09) (Pos. 1-3 of VIN is 3GN)
|-
|7 <br> (following A)||Chevrolet HHR SS w/man. trans. ('08-'09) (Pos. 1-3 of VIN is 3GN)
|-
|6 <br> (following A)||Chevrolet HHR Panel SS w/auto. trans. ('09) (Pos. 1-3 of VIN is 3GC)
|-
|7 <br> (following A)||Chevrolet HHR Panel SS w/man. trans. ('09) (Pos. 1-3 of VIN is 3GC)
|-
|8 <br> (following A)||Chevrolet HHR Panel LS w/auto. trans. ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|9 <br> (following A)||Chevrolet HHR Panel LS w/man. trans. ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|0 <br> (following A)||Chevrolet HHR Panel LT (all transmissions) ('08-'09) (Pos. 1-3 of VIN is 3GC)
|-
|1 <br> (following A)||Chevrolet HHR Panel LS ('08) (Pos. 1-3 of VIN is 3GC)
|-
|2 <br> (following A)||Chevrolet HHR Panel LT ('08) (Pos. 1-3 of VIN is 3GC)
|-
|3 <br> (following A)||Chevrolet HHR Panel LT ('08) (Pos. 1-3 of VIN is 3GC)
|-
|0 <br> (following V)||Chevrolet Venture Plus ('05) (Pos. 8 of VIN is E)
|-
|1 <br> (following V)||Chevrolet Venture Cargo ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following V)||Chevrolet Venture LS ('05) (Pos. 8 of VIN is E)
|-
|3 <br> (following V)||Chevrolet Venture LT ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following U)||Chevrolet Uplander LS SWB 2wd ('06-'08)
|-
|0 <br> (following V)||Chevrolet Uplander Base model 2wd ('05)
|-
|1 <br> (following V)||Chevrolet Uplander Cargo Van 2wd, Mobility (incomplete vehicle) 2wd ('05-'08)
|-
|2 <br> (following V)||Chevrolet Uplander LS 2wd ('05-'08)
|-
|3 <br> (following V)||Chevrolet Uplander LT 2wd ('05-'08)
|-
|3 <br> (following X)||Chevrolet Uplander LT Awd ('05-'06)
|-
|1 <br> (following M)||Chevrolet Astro 2wd ('00-'05)
|-
|1 <br> (following L)||Chevrolet Astro Awd ('00-'05)
|-
|1 <br> (following G)||Chevrolet Express 1500 series 2wd ('00-'09)
|-
|2 <br> (following G)||Chevrolet Express 2500 series 2wd ('00-'09)
|-
|3 <br> (following G)||Chevrolet Express 3500 series 2wd ('00-'09)
|-
|3 <br> (following G)||When VIN starts with 1GBK: Chevrolet Express 4500 series Cutaway 2wd ('09)
|-
|6 <br> (following G)||Chevrolet Express 1500 series LT 2wd ('01-'02)
|-
|1 <br> (following H)||Chevrolet Express 1500 series Awd ('03-'09)
|-
|2 <br> (following H)||Chevrolet Express 2500 series Awd ('03-'05)
|-
|1 <br> (following E)||Chevrolet Tracker Base model 2wd ('00-'04)
|-
|6 <br> (following E)||Chevrolet Tracker LT 2wd ('01-'04)
|-
|1 <br> (following J)||Chevrolet Tracker Base model 4wd ('00-'01, '04)
|-
|1 <br> (following J)||Chevrolet Tracker Base model w/1SB (Preferred) Equip. Group 4wd ('02-'03)
|-
|2 <br> (following J)||Chevrolet Tracker Base model w/1SA (Base) Equip. Group 4wd ('02-'03)
|-
|6 <br> (following J)||Chevrolet Tracker LT 4wd ('01-'04)
|-
|7 <br> (following J)||Chevrolet Tracker ZR2 4wd ('01-'04)
|-
|1 <br> (following L)||Chevrolet Equinox LS 2wd ('05-'09)
|-
|2 <br> (following L)||Chevrolet Equinox LS Awd ('05-'09)
|-
|6 <br> (following L)||Chevrolet Equinox LT 2wd ('05-'07)
|-
|7 <br> (following L)||Chevrolet Equinox LT Awd ('05-'07)
|-
|3 <br> (following L)||Chevrolet Equinox 1LT 2wd ('08-'09)
|-
|4 <br> (following L)||Chevrolet Equinox 1LT Awd ('08-'09)
|-
|5 <br> (following L)||Chevrolet Equinox 2LT 2wd ('08-'09)
|-
|6 <br> (following L)||Chevrolet Equinox 2LT Awd ('08-'09)
|-
|7 <br> (following L)||Chevrolet Equinox LTZ 2wd ('08-'09)
|-
|8 <br> (following L)||Chevrolet Equinox LTZ Awd ('08-'09)
|-
|9 <br> (following L)||Chevrolet Equinox Sport 2wd ('08-'09)
|-
|0 <br> (following L)||Chevrolet Equinox Sport Awd ('08-'09)
|-
|1 <br> (following R)||Chevrolet Traverse LS 2wd ('09)
|-
|2 <br> (following R)||Chevrolet Traverse LT 2wd ('09)
|-
|3 <br> (following R)||Chevrolet Traverse LTZ 2wd ('09)
|-
|1 <br> (following V)||Chevrolet Traverse LS Awd ('09)
|-
|2 <br> (following V)||Chevrolet Traverse LT Awd ('09)
|-
|3 <br> (following V)||Chevrolet Traverse LTZ Awd ('09)
|-
|1 <br> (following S)||Chevrolet Blazer 2wd ('00-'05)
|-
|1 <br> (following T)||Chevrolet Blazer 4wd ('00-'05)
|-
|1 <br> (following S)||Chevrolet Trailblazer 2wd ('02-'08), Trailblazer EXT 2wd ('02-'06)
|-
|1 <br> (following T)||Chevrolet Trailblazer 4wd ('02-'08), Trailblazer EXT 4wd ('02-'06)
|-
|3 <br> (following S)||Chevrolet Trailblazer LT 2wd ('09)
|-
|3 <br> (following T)||Chevrolet Trailblazer LT 4wd ('09)
|-
|5 <br> (following S)||Chevrolet Trailblazer SS 2wd ('09)
|-
|5 <br> (following T)||Chevrolet Trailblazer SS 4wd ('09)
|-
|1 <br> (following C)||Chevrolet Tahoe Limited 2wd ('00) [GMT400; 8th pos. of VIN is R]
|-
|1 <br> (following K)||Chevrolet Tahoe Z71 4wd ('00) [GMT400; 8th pos. of VIN is R]
|-
|1 <br> (following C)||Chevrolet Tahoe 2wd ('00-'06) [GMT800]
|-
|1 <br> (following K)||Chevrolet Tahoe 4wd ('00-'06) [GMT800]
|-
|1 <br> (following C)||Chevrolet Tahoe 2wd ('07-'08) [GMT900]
|-
|0 <br> (following C)||Chevrolet Tahoe Police/Special Service 2wd ('07-'09) [GMT900]
|-
|1 <br> (following C)||Chevrolet Tahoe LS 2wd ('09) [GMT900]
|-
|2 <br> (following C)||Chevrolet Tahoe LT 2wd ('09) [GMT900]
|-
|3 <br> (following C)||Chevrolet Tahoe LTZ 2wd ('09) [GMT900]
|-
|1 <br> (following K)||Chevrolet Tahoe 4wd ('07-'08) [GMT900]
|-
|0 <br> (following K)||Chevrolet Tahoe Police/Special Service 4wd ('07-'09) [GMT900]
|-
|1 <br> (following K)||Chevrolet Tahoe LS 4wd ('09) [GMT900]
|-
|2 <br> (following K)||Chevrolet Tahoe LT 4wd ('09) [GMT900]
|-
|3 <br> (following K)||Chevrolet Tahoe LTZ 4wd ('09) [GMT900]
|-
|1 <br> (following C)||Chevrolet Suburban 1500 series 2wd ('00-'08)
|-
|2 <br> (following C)||Chevrolet Suburban 2500 series 2wd ('00-'08)
|-
|1 <br> (following K)||Chevrolet Suburban 1500 series 4wd ('00-'08)
|-
|2 <br> (following K)||Chevrolet Suburban 2500 series 4wd ('00-'08)
|-
|1 <br> (following C)||Chevrolet Suburban 1500 series LS 2wd ('09)
|-
|2 <br> (following C)||Chevrolet Suburban 1500 series LT 2wd ('09)
|-
|3 <br> (following C)||Chevrolet Suburban 1500 series LTZ 2wd ('09)
|-
|4 <br> (following C)||Chevrolet Suburban 2500 series LS 2wd ('09)
|-
|5 <br> (following C)||Chevrolet Suburban 2500 series LT 2wd ('09)
|-
|1 <br> (following K)||Chevrolet Suburban 1500 series LS 4wd ('09)
|-
|2 <br> (following K)||Chevrolet Suburban 1500 series LT 4wd ('09)
|-
|3 <br> (following K)||Chevrolet Suburban 1500 series LTZ 4wd ('09)
|-
|4 <br> (following K)||Chevrolet Suburban 2500 series LS 4wd ('09)
|-
|5 <br> (following K)||Chevrolet Suburban 2500 series LT 4wd ('09)
|-
|1 <br> (following C)||Chevrolet Avalanche 1500 series 2wd ('02-'08)
|-
|2 <br> (following C)||Chevrolet Avalanche 2500 series 2wd ('02-'03)
|-
|1 <br> (following K)||Chevrolet Avalanche 1500 series 4wd ('02-'08)
|-
|2 <br> (following K)||Chevrolet Avalanche 2500 series 4wd ('02-'06)
|-
|1 <br> (following C)||Chevrolet Avalanche 1500 series LS 2wd ('09)
|-
|2 <br> (following C)||Chevrolet Avalanche 1500 series LT 2wd ('09)
|-
|3 <br> (following C)||Chevrolet Avalanche 1500 series LTZ 2wd ('09)
|-
|1 <br> (following K)||Chevrolet Avalanche 1500 series LS 4wd ('09)
|-
|2 <br> (following K)||Chevrolet Avalanche 1500 series LT 4wd ('09)
|-
|3 <br> (following K)||Chevrolet Avalanche 1500 series LTZ 4wd ('09)
|-
|1 <br> (following S)||Chevrolet SSR 2wd ('03-'06)
|-
|6 <br> (following S)||Chevrolet SSR Signature Series 2wd ('03) <br> [All SSR Signature Series also have a 0 in the 12th pos. of VIN whereas all other SSRs have a 1 in the 12th pos. of VIN]
|-
|1 <br> (following S)||Chevrolet S-10 2wd ('00-'03)
|-
|1 <br> (following T)||Chevrolet S-10 4wd ('00-'04)
|-
|1 <br> (following S)||Chevrolet Colorado 2wd ('04-'07)
|-
|1 <br> (following T)||Chevrolet Colorado 4wd ('04-'07)
|-
|1 <br> (following C)||Chevrolet Silverado 1500 2wd ('00-'06), Silverado Classic 1500 2wd ('07) [GMT800]
|-
|1 <br> (following K)||Chevrolet Silverado 1500 4wd ('00-'06), Silverado Classic 1500 4wd ('07) [GMT800]
|-
|1 <br> (following C)||Chevrolet Silverado 1500HD 2wd ('01-'03, '05-'06), Silverado Classic 1500HD 2wd ('07) [GMT800] (Pos. 8 of VIN is U]
|-
|1 <br> (following K)||Chevrolet Silverado 1500HD 4wd ('01-'03, '05-'06), Silverado Classic 1500HD 2wd ('07) [GMT800] (Pos. 8 of VIN is U]
|-
|2 <br> (following C)||Chevrolet Silverado 2500 2wd ('00) [GMT800] (Pos. 8 of VIN is T or U]
|-
|2 <br> (following K)||Chevrolet Silverado 2500 4wd ('00) [GMT800] (Pos. 8 of VIN is U]
|-
|2 <br> (following C)||Chevrolet C2500 2wd ('00) [GMT400] (Pos. 8 of VIN is F, J, or R)
|-
|3 <br> (following C)||Chevrolet C3500 2wd ('00) [GMT400] (Pos. 8 of VIN is F, J, or R)
|-
|3 <br> (following C)||when 4th pos. of VIN is K: Chevrolet C3500HD 2wd ('00-'02) [GMT400]
|-
|2 <br> (following K)||Chevrolet K2500 4wd ('00) [GMT400] (Pos. 8 of VIN is F, J, or R)
|-
|3 <br> (following K)||Chevrolet K3500 4wd ('00) [GMT400] (Pos. 8 of VIN is F, J, or R)
|-
|2 <br> (following C)||Chevrolet Silverado 2500 2wd ('01-'06) [GMT800], Silverado Classic 2500 2wd ('07)
|-
|2 <br> (following K)||Chevrolet Silverado 2500 4wd ('01-'06) [GMT800], Silverado Classic 2500 4wd ('07)
|-
|3 <br> (following C)||Chevrolet Silverado 3500 2wd ('01-'06) [GMT800], Silverado Classic 3500 2wd ('07)
|-
|3 <br> (following K)||Chevrolet Silverado 3500 4wd ('01-'06) [GMT800], Silverado Classic 3500 4wd ('07)
|-
|1 <br> (following V)||Pontiac Montana Mobility (incomplete vehicle) 2wd ('05) (Pos. 8 of VIN is E)
|-
|2 <br> (following V)||Pontiac Montana ('05) (Pos. 8 of VIN is E)
|-
|0 <br> (following V)||Pontiac Montana SV6 1SA 2wd ('05)
|-
|3 <br> (following V)||Pontiac Montana SV6 1SB 2wd ('05)
|-
|2 <br> (following X)||Pontiac Montana SV6 1SA Awd ('05)
|-
|3 <br> (following X)||Pontiac Montana SV6 1SB Awd ('05)
|-
|1 <br> (following V)||Pontiac Montana SV6 Mobility (incomplete vehicle) 2wd ('06)
|-
|3 <br> (following V)||Pontiac Montana SV6 2wd ('06)
|-
|3 <br> (following X)||Pontiac Montana SV6 Awd ('06)
|-
|0 <br> (following A)||Pontiac Aztek 2wd ('01-'05)
|-
|0 <br> (following B)||Pontiac Aztek Awd ('01-'05)
|-
|6 <br> (following L)||Pontiac Torrent 2wd ('06-'07)
|-
|7 <br> (following L)||Pontiac Torrent Awd ('06-'07)
|-
|3 <br> (following L)||Pontiac Torrent Base model 2wd ('08-'09)
|-
|4 <br> (following L)||Pontiac Torrent Base model Awd ('08-'09)
|-
|5 <br> (following L)||Pontiac Torrent GXP 2wd ('08-'09)
|-
|6 <br> (following L)||Pontiac Torrent GXP Awd ('08-'09)
|-
|0 <br> (following X)||Oldsmobile Silhouette extended length GL 2wd ('00, '03-'04), GLS 2wd ('00-'04)
|-
|1 <br> (following X)||Oldsmobile Silhouette extended length Premiere 2wd ('00-'04)
|-
|2 <br> (following X)||Oldsmobile Silhouette extended length GL 2wd ('01-'02)
|-
|0 <br> (following V)||Oldsmobile Silhouette extended length GLS Awd ('02-'04)
|-
|1 <br> (following V)||Oldsmobile Silhouette extended length Premiere Awd ('02-'04)
|-
|1 <br> (following S)||Oldsmobile Bravada 2wd ('02-'04)
|-
|1 <br> (following T)||Oldsmobile Bravada 4wd ('00-'04)
|-
|1 <br> (following V)||Buick Terraza Mobility (incomplete vehicle) 2wd ('05-'07)
|-
|2 <br> (following V)||Buick Terraza CX 2wd ('05-'07), CX Plus 2wd ('07)
|-
|3 <br> (following V)||Buick Terraza CXL 2wd ('05-'07)
|-
|2 <br> (following X)||Buick Terraza CX Awd ('05-'06)
|-
|3 <br> (following X)||Buick Terraza CXL Awd ('05-'06)
|-
|0 <br> (following A)||Buick Rendezvous 2wd ('02-'07)
|-
|0 <br> (following B)||Buick Rendezvous Awd ('02-'06)
|-
|1 <br> (following S)||Buick Rainier 2wd ('04-'07)
|-
|1 <br> (following T)||Buick Rainier 4wd ('04-'06)
|-
|1 <br> (following R)||Buick Enclave CX 2wd ('08-'09)
|-
|2 <br> (following R)||Buick Enclave CXL 2wd ('08-'09)
|-
|1 <br> (following V)||Buick Enclave CX Awd ('08-'09)
|-
|2 <br> (following V)||Buick Enclave CXL Awd ('08-'09)
|-
|6 <br> (following E)||Cadillac SRX ('04-'07)
|-
|2 <br> (following E)||Cadillac SRX RWD V8 ('08-'09)
|-
|4 <br> (following E)||Cadillac SRX AWD V6 ('08-'09)
|-
|5 <br> (following E)||Cadillac SRX AWD V8 ('08-'09)
|-
|6 <br> (following E)||When Pos. 8 of VIN is 7: Cadillac SRX RWD V6 ('08)
|-
|6 <br> (following E)||When Pos. 8 of VIN is A: Cadillac SRX AWD V8 ('08)
|-
|6 <br> (following E)||Cadillac SRX RWD V6 ('09)
|-
|1 <br> (following K)||Cadillac Escalade 4wd (Early '00)
|-
|4 <br> (following K)||Cadillac Escalade Platinum Edition 4wd ('08), Escalade ESV Platinum Edition 4wd ('08)
|-
|6 <br> (following C)||Cadillac Escalade 2wd ('02-'08), Escalade ESV 2wd ('08)
|-
|6 <br> (following K)||Cadillac Escalade 4wd (Mid '00, '02-'08), Escalade ESV 4wd ('03-'08), Escalade EXT 4wd ('02-'08)
|-
|1 <br> (following C)||Cadillac Escalade 2wd Base model ('09), Escalade ESV 2wd Base model ('09)
|-
|2 <br> (following C)||Cadillac Escalade 2wd w/Ultra Luxury Collection ('09), Escalade ESV 2wd w/Ultra Luxury Collection ('09)
|-
|3 <br> (following C)||Cadillac Escalade 2wd w/Platinum Edition ('09), Escalade ESV 2wd w/Platinum Edition ('09)
|-
|4 <br> (following C)||Cadillac Escalade Hybrid 2wd Base model ('09)
|-
|5 <br> (following C)||Cadillac Escalade 2wd w/Sport Package ('09), Escalade ESV 4wd w/Sport Package ('09)
|-
|1 <br> (following K)||Cadillac Escalade 4wd Base model ('09), Escalade ESV 4wd Base model ('09), Escalade EXT 4wd Base model ('09)
|-
|2 <br> (following K)||Cadillac Escalade 4wd w/Ultra Luxury Collection ('09), Escalade ESV 4wd w/Ultra Luxury Collection ('09),<br> Escalade EXT 4wd w/Ultra Luxury Collection ('09)
|-
|3 <br> (following K)||Cadillac Escalade 4wd w/Platinum Edition ('09), Escalade ESV 4wd w/Platinum Edition ('09)
|-
|4 <br> (following K)||Cadillac Escalade Hybrid 4wd Base model ('09)
|-
|5 <br> (following K)||Cadillac Escalade 4wd w/Sport Package ('09), Escalade ESV 4wd w/Sport Package ('09), Escalade EXT 4wd w/Sport Package ('09)
|-
|1 <br> (following M)||GMC Safari 2wd ('00-'05)
|-
|1 <br> (following L)||GMC Safari Awd ('00-'05)
|-
|1 <br> (following G)||GMC Savana 1500 series 2wd ('00-'09)
|-
|2 <br> (following G)||GMC Savana 2500 series 2wd ('00-'09)
|-
|3 <br> (following G)||GMC Savana 3500 series 2wd ('00-'09)
|-
|3 <br> (following G)||When VIN starts with 1GBK: GMC Savana 4500 series Cutaway 2wd ('09)
|-
|6 <br> (following G)||GMC Savana 1500 series SLT 2wd ('01-'02)
|-
|1 <br> (following H)||GMC Savana 1500 series Awd ('03-'09)
|-
|2 <br> (following H)||GMC Savana 2500 series Awd ('03-'05)
|-
|1 <br> (following R)||GMC Acadia SLE 2wd ('07-'09)
|-
|2 <br> (following R)||GMC Acadia SLT-1 2wd ('07-'09)
|-
|3 <br> (following R)||GMC Acadia SLT-2 2wd ('07-'09)
|-
|1 <br> (following V)||GMC Acadia SLE Awd ('07-'09)
|-
|2 <br> (following V)||GMC Acadia SLT-1 Awd ('07-'09)
|-
|3 <br> (following V)||GMC Acadia SLT-2 Awd ('07-'09)
|-
|1 <br> (following S)||GMC Jimmy 2wd ('00-'01)
|-
|6 <br> (following S)||GMC Jimmy Diamond Edition 2wd ('01)
|-
|1 <br> (following T)||GMC Jimmy 4wd ('00-'01 & '02-'05 in Canada)
|-
|6 <br> (following T)||GMC Jimmy Diamond Edition 4wd ('01)
|-
|1 <br> (following S)||GMC Envoy 2wd ('02-'08), Envoy XL 2wd ('02-'06), Envoy XUV 2wd ('04-'05)
|-
|6 <br> (following S)||GMC Envoy Denali 2wd ('05-'08), Envoy XL Denali 2wd ('05-'06)
|-
|1 <br> (following T)||GMC Envoy 4wd ('02-'08), Envoy XL 4wd ('02-'06), Envoy XUV 4wd ('04-'05)
|-
|6 <br> (following T)||GMC Envoy Denali 4wd ('05-'08), Envoy XL Denali 4wd ('05-'06)
|-
|3 <br> (following S)||GMC Envoy SLE 2wd ('09)
|-
|3 <br> (following T)||GMC Envoy SLE 4wd ('09)
|-
|4 <br> (following S)||GMC Envoy SLT 2wd ('09)
|-
|4 <br> (following T)||GMC Envoy SLT 4wd ('09)
|-
|5 <br> (following S)||GMC Envoy Denali 2wd ('09)
|-
|5 <br> (following T)||GMC Envoy Denali 4wd ('09)
|-
|1 <br> (following C)||GMC Yukon 2wd ('00-'06) [GMT800]
|-
|1 <br> (following K)||GMC Yukon 4wd ('00-'06) [GMT800]
|-
|1 <br> (following C)||GMC Yukon 2wd ('07-'08) [GMT900]
|-
|1 <br> (following K)||GMC Yukon 4wd ('07-'08) [GMT900]
|-
|1 <br> (following C)||GMC Yukon 2wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon 4wd ('09) [GMT900]
|-
|1 <br> (following C)||GMC Yukon Hybrid 2wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following K)||GMC Yukon Hybrid 4wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|2 <br> (following C)||GMC Yukon SLE 2wd ('09) [GMT900]
|-
|3 <br> (following C)||GMC Yukon SLT 2wd ('09) [GMT900]
|-
|2 <br> (following K)||GMC Yukon SLE 4wd ('09) [GMT900]
|-
|3 <br> (following K)||GMC Yukon SLT 4wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon Denali 4wd (Early '00) [GMT400; 8th pos. of VIN is R]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd (Mid '00) [GMT400; 8th pos. of VIN is R]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd ('01-'06) [GMT800]
|-
|6 <br> (following C)||GMC Yukon Denali 2wd ('08) [GMT900]
|-
|6 <br> (following K)||GMC Yukon Denali 4wd ('07-'08) [GMT900]
|-
|0 <br> (following C)||GMC Yukon Denali 2wd ('09) [GMT900]
|-
|0 <br> (following K)||GMC Yukon Denali 4wd ('09) [GMT900]
|-
|1 <br> (following K)||GMC Yukon Denali 4wd ('09) [GMT900; 8th pos. of VIN is 2]
|-
|1 <br> (following C)||GMC Yukon Denali Hybrid 2wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following K)||GMC Yukon Denali Hybrid 4wd ('09) [GMT900; 8th pos. of VIN is 5]
|-
|1 <br> (following C)||GMC Yukon XL 1500 series 2wd ('00-'08)
|-
|2 <br> (following C)||GMC Yukon XL 2500 series 2wd ('00-'08)
|-
|6 <br> (following C)||GMC Yukon XL Denali 1500 series 2wd ('08)
|-
|1 <br> (following K)||GMC Yukon XL 1500 series 4wd ('00-'08)
|-
|2 <br> (following K)||GMC Yukon XL 2500 series 4wd ('00-'08)
|-
|6 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('01-'08)
|-
|1 <br> (following C)||GMC Yukon XL 1500 series 2wd ('09)
|-
|2 <br> (following C)||GMC Yukon XL 1500 series SLE 2wd ('09)
|-
|3 <br> (following C)||GMC Yukon XL 1500 series SLT 2wd ('09)
|-
|4 <br> (following C)||GMC Yukon XL 2500 series 2wd ('09)
|-
|5 <br> (following C)||GMC Yukon XL 2500 series SLE 2wd ('09)
|-
|6 <br> (following C)||GMC Yukon XL 2500 series SLT 2wd ('09)
|-
|0 <br> (following C)||GMC Yukon XL Denali 1500 series 2wd ('09)
|-
|1 <br> (following K)||GMC Yukon XL 1500 series 4wd ('09)
|-
|2 <br> (following K)||GMC Yukon XL 1500 series SLE 4wd ('09)
|-
|3 <br> (following K)||GMC Yukon XL 1500 series SLT 4wd ('09)
|-
|4 <br> (following K)||GMC Yukon XL 2500 series 4wd ('09)
|-
|5 <br> (following K)||GMC Yukon XL 2500 series SLE 4wd ('09)
|-
|6 <br> (following K)||GMC Yukon XL 2500 series SLT 4wd ('09)
|-
|0 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('09)
|-
|1 <br> (following K)||GMC Yukon XL Denali 1500 series 4wd ('09) [8th pos. of VIN is 2]
|-
|1 <br> (following S)||GMC Sonoma 2wd ('00-'03)
|-
|1 <br> (following T)||GMC Sonoma 4wd ('00-'04)
|-
|1 <br> (following S)||GMC Canyon 2wd ('04-'07)
|-
|1 <br> (following T)||GMC Canyon 4wd ('04-'07)
|-
|1 <br> (following C)||GMC Sierra 1500 2wd ('00-'06), Sierra Classic 1500 2wd ('07) [GMT800]
|-
|1 <br> (following K)||GMC Sierra 1500 4wd ('00-'06), Sierra Classic 1500 4wd ('07) [GMT800]
|-
|1 <br> (following C)||GMC Sierra 1500HD 2wd ('01-'03, '05-'06), Sierra Classic 1500HD 2wd ('07) [GMT800] (Pos. 8 of VIN is U]
|-
|1 <br> (following K)||GMC Sierra 1500HD 4wd ('01-'03, '05-'06), Sierra Classic 1500HD 2wd ('07) [GMT800] (Pos. 8 of VIN is U]
|-
|6 <br> (following K)||GMC Sierra C3 1500 Awd ('01) [GMT800]
|-
|6 <br> (following K)||GMC Sierra Denali 1500 Awd ('02-'06), Sierra Classic Denali 1500 Awd ('07) [GMT800]
|-
|2 <br> (following C)||GMC Sierra 2500 2wd ('00) [GMT800] (Pos. 8 of VIN is T or U]
|-
|2 <br> (following K)||GMC Sierra 2500 4wd ('00) [GMT800] (Pos. 8 of VIN is U]
|-
|2 <br> (following C)||GMC Sierra Classic C2500 2wd ('00) [GMT400] (Pos. 8 of VIN is F, J, or R)
|-
|3 <br> (following C)||GMC Sierra Classic C3500 2wd ('00) [GMT400] (Pos. 8 of VIN is F, J, or R)
|-
|3 <br> (following C)||when 4th pos. of VIN is K: GMC Sierra C3500HD 2wd ('00-'02) [GMT400]
|-
|2 <br> (following K)||GMC Sierra Classic K2500 4wd ('00) [GMT400] (Pos. 8 of VIN is F, J, or R)
|-
|3 <br> (following K)||GMC Sierra Classic K3500 4wd ('00) [GMT400] (Pos. 8 of VIN is F, J, or R)
|-
|2 <br> (following C)||GMC Sierra 2500 2wd ('01-'06), Sierra Classic 2500 2wd ('07) [GMT800]
|-
|2 <br> (following K)||GMC Sierra 2500 4wd ('01-'06), Sierra Classic 2500 4wd ('07) [GMT800]
|-
|3 <br> (following C)||GMC Sierra 3500 2wd ('01-'06), Sierra Classic 3500 2wd ('07) [GMT800]
|-
|3 <br> (following K)||GMC Sierra 3500 4wd ('01-'06), Sierra Classic 3500 4wd ('07) [GMT800]
|-
|0 <br> (following V)||Saturn Relay ''2'' 2wd ('05-'07)
|-
|2 <br> (following V)||Saturn Relay ''3'' 2wd ('05-'07)
|-
|5 <br> (following V)||Saturn Relay ''1'' 2wd ('07)
|-
|2 <br> (following X)||Saturn Relay ''3'' Awd ('05-'06)
|-
|2 <br> (following Z)||Saturn Vue I4, Man. Trans., Fwd ('02-'07)
|-
|3 <br> (following Z)||Saturn Vue I4, Auto. Trans., Fwd ('02-'07)
|-
|4 <br> (following Z)||Saturn Vue I4, Auto. Trans., Awd ('02-'05)
|-
|5 <br> (following Z)||Saturn Vue V6, Auto. Trans., Fwd ('03-'07)
|-
|6 <br> (following Z)||Saturn Vue V6, Auto. Trans., Awd ('02-'07)
|-
|3 <br> (following L)||Saturn Vue XE Fwd ('08-'09)
|-
|4 <br> (following L)||Saturn Vue XE Awd ('08-'09)
|-
|5 <br> (following L)||when 4th pos. of VIN is C: Saturn Vue XR Fwd ('08-'09)
|-
|7 <br> (following L)||Saturn Vue XR Awd (Early '08)
|-
|6 <br> (following L)||Saturn Vue XR Awd (Mid '08-'09)
|-
|5 <br> (following L)||when 4th pos. of VIN is D: Saturn Vue XR Awd ('09)
|-
|1 <br> (following L)||Saturn Vue Red Line Fwd ('08-'09)
|-
|9 <br> (following L)||Saturn Vue Red Line Awd ('08)
|-
|0 <br> (following L)||Saturn Vue Red Line Awd ('09)
|-
|0 <br> (following L)||Saturn Vue Green Line Fwd ('08)
|-
|9 <br> (following L)||Saturn Vue Green Line Fwd ('09)
|-
|1 <br> (following R)||Saturn Outlook XE 2wd ('07-'09)
|-
|2 <br> (following R)||Saturn Outlook XR 2wd ('07-'09)
|-
|3 <br> (following R)||Saturn Outlook XR 2wd w/Touring Package ('07-'09)
|-
|1 <br> (following V)||Saturn Outlook XE Awd ('07-'09)
|-
|2 <br> (following V)||Saturn Outlook XR Awd ('07-'09)
|-
|3 <br> (following V)||Saturn Outlook XR Awd w/Touring Package ('07-'09)
|-
|1 <br> (following N)||Hummer H3 ('06-'07)
|-
|1 <br> (following N)||Hummer H3 Base model ('08)
|-
|3 <br> (following N)||Hummer H3 Adventure ('08)
|-
|4 <br> (following N)||Hummer H3 Luxury ('08)
|-
|5 <br> (following N)||Hummer H3 X ('08)
|-
|6 <br> (following N)||Hummer H3 Alpha ('08)
|-
|1 <br> (following N)||Hummer H3, H3T ('09)
|-
|2 <br> (following N)||Hummer H2 ('03-'08), H2 SUT ('05-'08)
|-
|2 <br> (following N)||Hummer H2 Base model ('09), H2 SUT Base model ('09)
|-
|7 <br> (following N)||Hummer H2 Adventure ('09)
|-
|8 <br> (following N)||Hummer H2 Luxury ('09)
|-
|9 <br> (following N)||Hummer H2 SUT Adventure ('09)
|-
|0 <br> (following N)||Hummer H2 SUT Luxury ('09)
|-
|1 (following S)||Isuzu Hombre 2wd ('00), Isuzu i280 2wd ('06), Isuzu i290 2wd ('07-'08), Isuzu i370 2wd ('07-'08)
|-
|2 (following S)||Isuzu i290 2wd w/Preferred Equip. Pkg. ('08), Isuzu i370 2wd w/Comfort Pkg. or upgrade model ('08)
|-
|1 (following T)||Isuzu Hombre 4wd ('00), Isuzu i350 4wd ('06), Isuzu i370 4wd ('07-'08)
|-
|2 (following T)||Isuzu i370 4wd w/Comfort Pkg. ('08)
|-
|1 (following S)||Isuzu Ascender 2wd ('03-'08)
|-
|1 (following T)||Isuzu Ascender 4wd ('03-'08)
|-
|1 (following T)||Saab 9-7X ('05-'08: All, '09: 4.2i, 5.3i)
|-
|2 (following T)||Saab 9-7X Aero ('09)
|}
====Body style codes 1981-2009 Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Body type is specified as character 7 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|0||Sedan Pickup/Pickup Delivery ('81-'87 El Camino, Caballero)
|-
|0||Cadillac, Buick, Chevrolet Commercial Body/Chassis
|-
|0||Chassis Only
|-
|1||Cutaway Van
|-
|2||Forward Control ('81-'03) (includes '93-'95 Chevy G30HD/GMC G3500HD)
|-
|2||Sport Utility Truck (SUT) ('04-'09 Avalanche & Escalade EXT, '04-'05 Envoy XUV, '05-'09 Hummer H2 SUT)
|-
|3||Four-Door Cab pickup (Crew Cab) (includes '06-'08 Isuzu i-Series Crew Cab, '09 Hummer H3T)
|-
|3||4-door Passenger Minivan ('97-'09 U-bodies)
|-
|3||4-door SUV or MPV ('06-'09 HHR) (also includes '02-'03 Avalanche & Escalade EXT) ('05-'09 Saab 9-7X)
|-
|4||Two-Door Cab pickup (includes '83-'87 S-10/S-15 extended cab pickups, '03-'06 Chevy SSR, '96-'00 Isuzu Hombre Reg. Cab)
|-
|5||Van (Astro/Safari & full-size vans & '07-'09 HHR Panel)
|-
|6||Extended length 4-door SUV (Suburban, Yukon XL, Escalade ESV, Trailblazer EXT, Envoy XL, Isuzu Ascender 7-psgr.)
|-
|6||3-door Passenger Minivan ('90-'99 U-bodies)
|-
|7||Motor Home Chassis ('81-'09)
|-
|8||Two-Door SUV (Utility) (2-d Tracker, S-10 Blazer, S-15 Jimmy, Blazer, Jimmy, Tahoe, Yukon)
|-
|9||Stake (81-87)
|-
|9||Extended Cab pickup ('88-) (includes '97-'00 Isuzu Hombre Spacecab, '06-'08 Isuzu i-Series Ext. Cab)
|-
|9||Extended length van ('90-) (Astro/Safari & full-size vans)
|}
===American VIN format 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle===
GM's VIN format is as follows:
<table border=1 style="margin:auto;">
<tr>
<th>Position</th>
<th>Sample</th><th></th><th></th><th>Description</th>
</tr><tr>
<td>1</td>
<td>1</td><td></td><td></td><td rowspan=3>[[#GM WMIs|World Manufacturer Identifier]]</td>
</tr><tr>
<td>2</td>
<td>G</td><td></td><td></td></tr><tr>
<td>3</td>
<td>K</td><td></td><td></td></tr><tr>
<td>4</td>
<td>L</td><td></td><td></td><td>[[#GVWR/Brake System/Body Style 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|GVWR/Brake System/Body Style 2010-]]</td>
</tr><tr>
<td>5</td>
<td>R</td><td></td><td></td><td>[[#Line & Chassis Type 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|Line & Chassis Type for 2010-]]</td>
</tr><tr>
<td>6</td>
<td>L</td><td></td><td></td><td>[[#Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle|Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle]]</td>
</tr><tr>
<td>7</td>
<td>E</td><td></td><td></td><td>[[#Restraint codes for light trucks 2010-|Restraint type]]</td>
</tr><tr>
<td>8</td>
<td>D</td><td></td><td></td><td>[[#Engine codes for light trucks|Engine type]]</td>
</tr><tr>
<td>9</td>
<td>0</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Check digit |Check digit]]</td>
</tr><tr>
<td>10</td>
<td>A</td><td></td><td></td><td>[[Vehicle Identification Numbers (VIN codes)/Model year|Model year]]</td>
</tr><tr>
<td>11</td>
<td>J</td><td></td><td></td><td>[[#GM factories supplying North America|Factory ID]]</td>
</tr><tr>
<td>12</td>
<td>1</td><td></td><td></td><td rowspan=6>Sequential number
</tr><tr>
<td>13</td>
<td>2</td><td></td><td></td></tr><tr>
<td>14</td>
<td>3</td><td></td><td></td></tr><tr>
<td>15</td>
<td>7</td><td></td><td></td></tr><tr>
<td>16</td>
<td>6</td><td></td><td></td></tr><tr>
<td>17</td>
<td>2</td><td></td><td></td>
</table>
====GVWR/Brake System/Body Style 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The GVWR/Brake System is specified as character 4 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!GVWR Range in lbs. & Weight Class
!Brake System
!Body Style
|-
| ||Class A: 0-3,000||Hydraulic||
|-
| ||Class B: 3,001-4,000||Hydraulic||
|-
|A||Class C: 4,001-5,000||Hydraulic||26: 4-door SUV or MPV ('10-'11 Chevy HHR Panel, '10-'26 Chevy Equinox, GMC Terrain, '10 Saturn Vue,<br> '12-'15 Chevy Captiva Sport, '19-'24 Cadillac XT4, '24-'26 Buick Encore GX)
|-
|B||Class C: 4,001-5,000||Hydraulic||46: 4-door MPV ('10-'11 Chevy HHR)
|-
|J||Class C: 4,001-5,000||Hydraulic||48: 4-door, 4 window Hatchback ('18-'23 Chevy Bolt EV w/Rear Seat Delete pkg. - incomplete vehicle)
|-
|C||Class C: 4,001-5,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|D||Class C: 4,001-5,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|E||Class C: 4,001-5,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10-'12 Chevy Colorado, GMC Canyon)
|-
|7||Class C: 4,001-5,000||Hydraulic||75: Four-Door Wagon - High Roof Monocab (Canada only: '12-'14 Chevy Orlando)
|-
|M||Class C: 4,001-5,000||Hydraulic||06: 4-door SUV ('20-'23 Buick Encore GX)
|-
|9||Class C: 4,001-5,000||Hydraulic||56: 4-door SUV Extended ('21-'26 Chevy Trailblazer)
|-
|7||Class C: 4,001-5,000||Hydraulic||58: 4-door Utility Extended ('24-'26 Chevy Trax, Buick Envista)
|-
|C||Class C: 4,001-5,000||Hydraulic||76: 4-door SUV ('13-'22 Buick Encore, Canada only: '13-'14 Chevy Trax, US & Canada: '15-'22 Chevy Trax)
|-
|F||Class D: 5,001-6,000||Hydraulic||26: 4-door SUV ('10-'17 Chevy Equinox, GMC Terrain, '10 Saturn Vue, '10-'16 Cadillac SRX, '11 Saab 9-4X,<br> '12-'13 Chevy Captiva Sport, '16-'26 Buick Envision, '17 Cadillac XT5, '19-'25 Cadillac XT4)
|-
|H||Class D: 5,001-6,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|G||Class D: 5,001-6,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|J||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|H||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|G||Class D: 5,001-6,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('15-'24 Chevy Colorado, '15-'22 GMC Canyon)
|-
|K||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Colorado, GMC Canyon)
|-
|J||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'12 Chevy Colorado, GMC Canyon)
|-
|H||Class D: 5,001-6,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('15-'22 Chevy Colorado, GMC Canyon)
|-
|T||Class D: 5,001-6,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|7||Class D: 5,001-6,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|L||Class E: 6,001-7,000||Hydraulic||26: 4-door SUV ('10 Chevy Traverse, GMC Acadia, Buick Enclave, Saturn Outlook)
|-
|K||Class E: 6,001-7,000||Hydraulic||26: 4-door SUV ('11-'17 Chevy Traverse, Buick Enclave, '11-'23 GMC Acadia, '17 Acadia Limited,<br> '17-'26 Cadillac XT5, '19-'26 Chevy Blazer, '20-'25 Cadillac XT6, '23-'26 Cadillac Lyriq EV,<br> '24-'26 Chevy Blazer EV, '25-'26 Cadillac Optiq EV, '24-'26 Honda Prologue EV, '24 Acura ZDX EV A-Spec)
|-
|7||Class E: 6,001-7,000||Hydraulic||48: 4-door SUV ('24-'25 Chevy Equinox EV)
|-
|E||Class E: 6,001-7,000||Hydraulic||56: 4-door SUV Extended ('18-'26 Chevy Traverse, Buick Enclave, '24 Chevy Traverse Limited,<br> '24-'26 GMC Acadia
|-
|M||Class E: 6,001-7,000||Hydraulic||05: Cargo Van ('10 Chevy Express, GMC Savana)
|-
|L||Class E: 6,001-7,000||Hydraulic||05: Cargo Van ('11-'14 Chevy Express, GMC Savana)
|-
|M||Class E: 6,001-7,000||Hydraulic||06: 4-door SUV ('10 Chevy Tahoe, GMC Yukon, Hummer H3)
|-
|L||Class E: 6,001-7,000||Hydraulic||06: 4-door SUV ('11-'20 Chevy Tahoe Police Pursuit Vehicle 2wd)
|-
|N||Class E: 6,001-7,000||Hydraulic||36: Sport Utility Truck (SUT) ('10 Chevy Avalanche 2wd)
|-
|M||Class E: 6,001-7,000||Hydraulic||36: Sport Utility Truck (SUT) ('11-13 Chevy Avalanche 2wd)
|-
|P||Class E: 6,001-7,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|N||Class E: 6,001-7,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|R||Class E: 6,001-7,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra, Hummer H3T)
|-
|P||Class E: 6,001-7,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited, '16-'26 Chevy Colorado, GMC Canyon)
|-
|S||Class E: 6,001-7,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|R||Class E: 6,001-7,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '19 Chevy Silverado LD, GMC Sierra Limited, '22 Chevy Silverado LTD, GMC Sierra Limited,<br> '16-'22 Chevy Colorado)
|-
|G||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|8||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|X||Class E: 6,001-7,000||Hydraulic||69: Commercial Chassis ('13-'19 Cadillac XTS chassis for Limo/Hearse)
|-
|U||Class F: 7,001-8,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|S||Class F: 7,001-8,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'14 Chevy Express, GMC Savana)
|-
|U||Class F: 7,001-8,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|S||Class F: 7,001-8,000||Hydraulic||06: Passenger Van ('11-'14 Chevy Express, GMC Savana)
|-
|U||Class F: 7,001-8,000||Hydraulic||06: 4-door SUV ('10 Chevy Tahoe, Suburban 1500, GMC Yukon, Yukon XL 1500, Cadillac Escalade, Escalade ESV)
|-
|S||Class F: 7,001-8,000||Hydraulic||06: 4-door SUV ('11-'26 Chevy Tahoe, Suburban 1500, GMC Yukon, Yukon XL 1500, Cadillac Escalade, Escalade ESV)
|-
|V||Class F: 7,001-8,000||Hydraulic||36: Sport Utility Truck (SUT) ('10 Chevy Avalanche 4wd, Cadillac Escalade EXT 4wd)
|-
|T||Class F: 7,001-8,000||Hydraulic||36: Sport Utility Truck (SUT) ('11-'13 Chevy Avalanche 4wd, Cadillac Escalade EXT 4wd)
|-
|X||Class F: 7,001-8,000||Hydraulic||26: 4-door SUV ('24 Acura ZDX EV Type S)
|-
|C||Class F: 7,001-8,000||Hydraulic||56: 4-door SUV Extended ('26- Cadillac Vistiq EV)
|-
|W||Class F: 7,001-8,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|X||Class F: 7,001-8,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|U||Class F: 7,001-8,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|Y||Class F: 7,001-8,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|V||Class F: 7,001-8,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '19 Chevy Silverado LD, GMC Sierra Limited, '22 Chevy Silverado LTD, GMC Sierra Limited)
|-
|U||Class F: 7,001-8,000||Hydraulic||69: Commercial Chassis ('10 Cadillac DTS chassis for Limo/Hearse)
|-
|9||Class F: 7,001-8,000||Hydraulic||69: Commercial Chassis ('11 Cadillac DTS chassis for Limo/Hearse)
|-
|Z||Class G: 8,001-9,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|W||Class G: 8,001-9,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'26 Chevy Express, GMC Savana)
|-
|Z||Class G: 8,001-9,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|W||Class G: 8,001-9,000||Hydraulic||06: Passenger Van ('11-'26 Chevy Express, GMC Savana)
|-
|Z||Class G: 8,001-9,000||Hydraulic||06: 4-door SUV ('10 Chevy Suburban 2500, GMC Yukon XL 2500)
|-
|W||Class G: 8,001-9,000||Hydraulic||06: 4-door SUV ('11-'13 Chevy Suburban 2500, GMC Yukon XL 2500)
|-
|2||Class H: 9,001-10,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('10 Chevy Express, GMC Savana)
|-
|Z||Class H: 9,001-10,000||Hydraulic||05: Cargo Van or Incomplete Vehicle ('11-'26 Chevy Express, GMC Savana,<br> '23-'24 BrightDrop Zevo 600, '24 BrightDrop Zevo 400, '25-'26 Chevrolet BrightDrop 400/600)
|-
|2||Class H: 9,001-10,000||Hydraulic||06: Passenger Van ('10 Chevy Express, GMC Savana)
|-
|Z||Class H: 9,001-10,000||Hydraulic||06: Passenger Van ('11-'26 Chevy Express, GMC Savana)
|-
|3||Class H: 9,001-10,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|0||Class H: 9,001-10,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
|3||Class H: 9,001-10,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|0||Class H: 9,001-10,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra)
|-
|4||Class H: 9,001-10,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|1||Class H: 9,001-10,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '24-'25 GMC Hummer EV pickup w/20 module battery pack,<br> '24-'26 Chevy Silverado EV, '25-'26 GMC Sierra EV)
|-
|5||Class H: 9,001-10,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|2||Class H: 9,001-10,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'13, '15-'26 Chevy Silverado, GMC Sierra)
|-
|B||Class H: 9,001-10,000||Hydraulic||26: 4-door SUV ('24-'25 GMC Hummer EV SUV)
|-
|6||Class 3: 10,001-14,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|3||Class 3: 10,001-14,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
|6||Class 3: 10,001-14,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|3||Class 3: 10,001-14,000||Hydraulic||03: Regular Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra)
|-
|7||Class 3: 10,001-14,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|4||Class 3: 10,001-14,000||Hydraulic||43: Crew Cab pickup or Chassis Cab ('11-'26 Chevy Silverado, GMC Sierra,<br> '22-'24 GMC Hummer EV pickup w/24 module battery pack, '25 GMC Hummer EV pickup w/20 or 24 module battery pack, '26 GMC Hummer EV pickup, '24-'25 Chevy Silverado EV, GMC Sierra EV)
|-
|8||Class 3: 10,001-14,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('10 Chevy Silverado, GMC Sierra)
|-
|5||Class 3: 10,001-14,000||Hydraulic||53: Extended Cab pickup or Chassis Cab ('11-'13, '15-'18, '20-'26 Chevy Silverado, GMC Sierra)
|-
|8||Class 3: 10,001-14,000||Hydraulic||06: 4-door SUV ('16-'19, '24-'26 Chevy Suburban 3500HD)
|-
|8||Class 3: 10,001-14,000||Hydraulic||05: Cargo Van ('22 BrightDrop EV600, '23-'24 BrightDrop Zevo 600, '24 BrightDrop Zevo 400,<br> '25-'26 Chevrolet BrightDrop 400/600)
|-
|T||Class 3: 10,001-14,000||Hydraulic||26: 4-door SUV ('25-'26 GMC Hummer EV SUV, '25-'26 Cadillac Escalade IQ [EV])
|-
|L||Class 3: 10,001-14,000||Hydraulic||56: 4-door SUV Extended ('26- Cadillac Escalade IQL [EV])
|-
|9||Class 4: 14,001-16,000||Hydraulic||03: Van Cutaway ('10 Chevy Express, GMC Savana)
|-
|6||Class 4: 14,001-16,000||Hydraulic||03: Van Cutaway ('11-'26 Chevy Express, GMC Savana)
|-
| ||Class 5: 16,001-19,500||Hydraulic||
|}
====Line & Chassis Type 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Line & Chassis Type is specified as character 5 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Chevrolet HHR ('10-'11), HHR Panel ('10-'11)
|-
|A||Chevy Silverado 1500 2wd ('22-'26), Silverado HD 2500/3500 2wd ('25-'26)
|-
|B||Chevy Blazer 2wd & Awd '19-'26
|-
|C||Chevy Silverado 2wd ('10-'18), Silverado LD 1500 2wd '19, Silverado HD 2500/3500 2wd '19, GMC Sierra 2wd ('10)
|-
|C||Chevy Tahoe 2wd ('10-'24), Suburban 2wd ('10-'24), Avalanche 2wd ('10-'13),<br /> GMC Yukon 2wd ('10), Yukon XL 2wd ('10), Cadillac Escalade 2wd ('10), Escalade ESV 2wd ('10)
|-
|D||Chevy Silverado 1500 4wd ('22-'24)
|-
|D||Chevy Blazer EV ('24-'26), Chevy Equinox EV ('24-'26)
|-
|E||Cadillac Escalade IQ [EV] ('25-'26), Escalade IQL [EV] ('26-), GMC Hummer EV pickup ('26-), GMC Hummer EV SUV ('26-), GMC Sierra EV ('26-)
|-
|F||Chevy Bolt EV w/Rear Seat Delete pkg. - incomplete vehicle ('18-'23)
|-
|G||Cadillac Chassis for Limousine & for Armored Vehicle (Based on XTS '13-'19)
|-
|G||Cadillac Chassis for Hearse (Based on XTS '13-'19)
|-
|G||Chevy Express 2wd ('10-'26), GMC Savana 2wd ('10)
|-
|H||Chevy Express 4wd ('10-'14), GMC Savana 4wd ('10)
|-
|H||GMC Sierra 1500 2wd ('22-'26), Sierra HD 2500/3500 2wd ('25-'26)
|-
|H||Honda Prologue EV ('24-'26), Acura ZDX EV ('24)
|-
|J||Buick Encore 2wd & Awd ('13-'22), Chevy Trax 2wd & Awd (Canada: '13-'22, US: '15-'22)
|-
|J||BrightDrop EV600 ('22), BrightDrop Zevo 600 ('23-'24), BrightDrop Zevo 400 ('24), Chevrolet BrightDrop 400/600 ('25-'26)
|-
|K||Chevy Silverado 4wd ('10-'18), Silverado LD 1500 4wd ('19), Silverado HD 2500/3500 4wd ('19), GMC Sierra 4wd ('10)
|-
|K||Chevy Silverado 1500 4wd ('25-'26), Silverado HD 2500/3500 4wd ('25-'26)
|-
|K||Chevy Tahoe 4wd ('10-'24), Suburban 4wd ('10-'24), Suburban HD 4wd ('24-'26), Avalanche 4wd ('10-'13), GMC Yukon 4wd ('10), Yukon XL 4wd ('10),<br> Cadillac Escalade 4wd ('10), Escalade ESV 4wd ('10), Escalade EXT 4wd ('10)
|-
|K||Cadillac Professional Chassis for Limousine (Based on DTS '10-'11)
|-
|K||Cadillac Commercial Chassis for Hearse (Based on DTS '10-'11)
|-
|L||Chevy Equinox 2wd & Awd '10-'17, Captiva Sport 2wd '12-'15, Captiva Sport Awd '12, GMC Terrain 2wd & Awd '10-'17, Saturn Vue 2wd & Awd '10
|-
|L||GMC Terrain 2wd & Awd '18-'26
|-
|L||Buick Envista '24-'26, Chevy Trax '24-'26
|-
|M||Buick Encore GX 2wd & Awd ('20-'26), Chevy Trailblazer 2wd & Awd ('21-'26)
|-
|N||Cadillac SRX 2wd & Awd '10-'16, Saab 9-4X 2011
|-
|N||GMC Acadia 2wd & Awd '17-'26, Cadillac XT5 2wd & Awd '17-'26
|-
|N||Hummer H3, H3T 2010
|-
|P||Chevy Orlando (Canada only: '12-'14)
|-
|P||Cadillac XT6 2wd & Awd '20-'25
|-
|P||Cadillac Lyriq EV 2wd & Awd '23-'25
|-
|R||GMC Acadia 2wd '10-'16, Acadia Limited 2wd '17, Saturn Outlook 2wd '10, Buick Enclave 2wd '10-'17, Chevy Traverse 2wd '10-'17
|-
|R||Buick Enclave 2wd '18-'24, Chevy Traverse 2wd '18-'23
|-
|R||Buick Enclave 2wd '25-'26, Chevy Traverse 2wd '24-'26
|-
|S||Chevy Traverse Limited 2wd '24
|-
|S||Chevy Colorado 2wd ('10-'12, '15-'26), GMC Canyon 2wd ('10)
|-
|T||Chevy Colorado 4wd ('10-'12, '15-'26), GMC Canyon 4wd ('10)
|-
|T||Chevy Traverse Limited Awd '24
|-
|U||GMC Sierra 1500 4wd ('22-'26), Sierra HD 2500/3500 4wd ('25-'26)
|-
|V||GMC Acadia Awd '10-'16, Acadia Limited Awd '17, Saturn Outlook Awd '10, Buick Enclave Awd '10-'17, Chevy Traverse Awd '10-'17
|-
|V||Buick Enclave Awd '18-'24, Chevy Traverse Awd '18-'23
|-
|V||Buick Enclave Awd '25-'26, Chevy Traverse Awd '24-'26
|-
|W||Chevy Silverado 1500 2wd ('19-'21), Silverado LTD 1500 2wd ('22), Silverado HD 2500/3500 2wd ('20-'24)
|-
|X||Buick Envision 2wd & Awd '16-'20, Chevy Equinox 2wd & Awd '18-'26
|-
|Y||Chevy Silverado 1500 4wd ('19-'21), Silverado LTD 1500 4wd ('22), Silverado HD 2500/3500 4wd ('20-'24)
|-
|Z||Cadillac XT4 2wd & Awd '19-'25, Buick Envision 2wd '21-'23, Buick Envision Awd '21-'26
|-
|1||GMC Sierra 2wd ('11-'18), Sierra Limited 1500 2wd ('19), Sierra HD 2500/3500 2wd ('19), Yukon 2wd ('11-'26), Yukon XL 2wd ('11-'26)
|-
|1||GMC Canyon 2wd ('25-'26)
|-
|2||GMC Sierra 4wd ('11-'18), Sierra Limited 1500 4wd ('19), Sierra HD 2500/3500 4wd ('19), Yukon 4wd ('11-'26), Yukon XL 4wd ('11-'26)
|-
|2||GMC Canyon 4wd ('25-'26)
|-
|3||Cadillac Escalade 2wd ('11-'24), Escalade ESV 2wd ('11-'24)
|-
|3||Cadillac Optiq EV ('25-), Cadillac Vistiq EV ('26-)
|-
|4||Cadillac Escalade 4wd ('11-'24), Escalade ESV 4wd ('11-'24), Escalade EXT 4wd ('11-'13)
|-
|5||GMC Canyon 2wd ('11-'12, '15-'24)
|-
|5||Chevy Tahoe 2wd ('25-'26), Suburban 2wd ('25-'26)
|-
|6||GMC Canyon 4wd ('11-'12, '15-'24)
|-
|6||Chevy Tahoe 4wd ('25-'26), Suburban 4wd ('25-'26)
|-
|7||GMC Savana 2wd ('11-'26)
|-
|8||GMC Savana 4wd ('11-'14)
|-
|8||GMC Sierra 1500 2wd ('19-'21), Sierra Limited 1500 2wd ('22), Sierra HD 2500/3500 2wd ('20-'24)
|-
|8||Cadillac Escalade 2wd ('25-'26), Escalade ESV 2wd ('25-'26)
|-
|9||GMC Sierra 1500 4wd ('19-'21), Sierra Limited 1500 4wd ('22), Sierra HD 2500/3500 4wd ('20-'24)
|-
|9||Cadillac Escalade 4wd ('25-'26), Escalade ESV 4wd ('25-'26)
|-
|0||GMC Hummer EV pickup ('22-'25), GMC Hummer EV SUV ('24-'25), Chevy Silverado EV ('24-'26), GMC Sierra EV ('24-'25)
|}
====Series 2010- Light Duty Truck & Multi-Purpose Passenger Vehicle====
The Series is specified as character 6 of the American GM VIN for light trucks.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A (following L)||Saturn Vue XE 2wd ('10)
|-
|E (following L)||Saturn Vue XR V6 2wd ('10)
|-
|K (following L)||Saturn Vue XR-L V6 2wd ('10)
|-
|T (following R)||Saturn Outlook XE 2wd ('10)
|-
|U (following R)||Saturn Outlook XE Premium 2wd ('10)
|-
|V (following R)||Saturn Outlook XR-L 2wd ('10)
|-
|W (following R)||Saturn Outlook XR-L Premium 2wd ('10)
|-
|T (following V)||Saturn Outlook XE Awd ('10)
|-
|U (following V)||Saturn Outlook XE Premium Awd ('10)
|-
|V (following V)||Saturn Outlook XR-L Awd ('10)
|-
|W (following V)||Saturn Outlook XR-L Premium Awd ('10)
|-
|G (following N)||Hummer H3, H3T Base model ('10)
|-
|H (following N)||Hummer H3, H3T Adventure ('10)
|-
|J (following N)||Hummer H3, H3T Luxury ('10)
|-
|K (following N)||Hummer H3, H3T Alpha w/cloth ('10)
|-
|L (following N)||Hummer H3, H3T Alpha w/Leather ('10)
|-
|P (following N)||Saab 9-4X 3.0i 2wd ('11)
|-
|R (following N)||Saab 9-4X 3.0i Awd ('11)
|-
|S (following N)||Saab 9-4X 3.0i Premium 2wd ('11)
|-
|T (following N)||Saab 9-4X 3.0i Premium Awd ('11)
|-
|U (following N)||Saab 9-4X Aero Awd ('11)
|}
===Platform & Series Codes 1985- Passenger Car===
GM used a lettered system of automobile platform codes for three decades. These letters were used as the 4th position of the VIN. Though today's GM platforms use Greek characters, they are still encoded with Latin characters in the 4th position. Position 5 encodes the specific model and trim level of the vehicle.
{| border=1 style="margin:auto;"
!List of GM platforms
!Platform<br>Code
!Series<br>Code
!:Category:General Motors vehicles|Model
|-
|rowspan=14|GM A platform
|rowspan=14|A||W||Chevrolet Celebrity 1985-1990
|-
|E||Pontiac 6000 ''SE'' 1986-1988
|-
|F||Pontiac 6000 1985-1988, 6000 ''LE'' 1989-1991
|-
|G||Pontiac 6000 ''LE'' 1985-1988
|-
|H||Pontiac 6000 ''STE'' 1985-1989
|-
|J||Pontiac 6000 ''SE'' 1989-1991
|-
|G||Oldsmobile Cutlass Ciera ''S'' Sedan 1993-1994
|-
|J||Oldsmobile Cutlass Ciera ''LS'' 1985, Cutlass Ciera 1986-1989 & Cutlass Cruiser 1985-1989,<br /> Cutlass Ciera ''S'' Coupe 1986-1987, Cutlass Ciera ''S'' 1990-1991 & Cutlass Cruiser ''S'' 1990-1994, Cutlass Ciera ''SL'' & Cutlass Cruiser ''SL'' 1995, Ciera ''SL'' sedan & wagon 1996
|-
|L||Oldsmobile Cutlass Ciera 1990-1991, Cutlass Ciera ''S'' Sedan 1992
|-
|M||Oldsmobile Cutlass Ciera ''Brougham'' 1985-1988, Cutlass Ciera ''SL'' Coupe 1986-1989, Cutlass Ciera ''SL'' Sedan 1989-1993, Cutlass Cruiser ''Brougham'' 1987-1988, Cutlass Cruiser ''SL'' 1989-1993
|-
|S||Oldsmobile Cutlass Ciera ''International Series'' 1988-1990
|-
|G||Buick Century ''T-Type'' 1985-1986, Century ''Special'' 1991-1996
|-
|H||Buick Century ''Custom'' 1985-1995
|-
|L||Buick Century ''Limited'' 1985-1993, Century Estate Wagon 1986-1989
|-
|rowspan=14|GM B platform
|rowspan=14|B||L||Chevrolet Impala 1985, Caprice 1986-1992, Caprice Classic 1993-1996, Impala SS 1995-96
|-
|N||Chevrolet Caprice Classic 1985-1992, Caprice Classic LS 1993-1994,<br /> Caprice Classic LTZ 1991-1993, Impala SS 1994
|-
|U||Chevrolet Caprice Classic Brougham/Brougham LS 1987-1990
|-
|L||Pontiac Parisienne 1985-1986, Safari Wagon 1987-1989
|-
|T||Pontiac Parisienne Brougham 1985-1986
|-
|N||Oldsmobile Delta 88 Royale 1985
|-
|P||Oldsmobile Custom Cruiser 1985-1992
|-
|V||Oldsmobile Delta 88 Royale Brougham LS 1985
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1985
|-
|N||Buick Le Sabre ''Custom'' 1985, Roadmaster sedan 1992-1996
|-
|P||Buick Le Sabre ''Limited'' 1985
|-
|R||Buick Le Sabre Estate Wagon 1985-1989, Estate Wagon 1990,<br /> Roadmaster Estate Wagon 1991-1996
|-
|T||Buick Roadmaster ''Limited'' sedan 1992-1996
|-
|V||Buick Electra Estate Wagon 1985-1989
|-
|rowspan=13|GM C platform - front-wheel drive
|rowspan=13|C
|V||Oldsmobile Touring Sedan 1988-1990, 98 Touring Sedan 1991-1993
|-
|W||Oldsmobile 98 Regency Brougham 1985-1990, 98 Regency Elite 1991-1996
|-
|X||Oldsmobile 98 Regency 1985-1990, 1992-1994
|-
|F||Buick Electra T-Type 1985-1990
|-
|U||Buick Electra Park Avenue Ultra 1989-1990, Park Avenue Ultra 1991-1996
|-
|W||Buick Electra Park Avenue 1985-1990, Park Avenue 1991-1996
|-
|X||Buick Electra 1985-1986, Electra Limited 1987-1990
|-
|B||1985-1992 Cadillac Fleetwood, Fleetwood D'Elegance, 1993 Cadillac Sixty Special
|-
|D||1985-1993 Cadillac DeVille
|-
|G||1991-1992 Cadillac Fleetwood Sixty Special
|-
|H||1985-1987 Cadillac Fleetwood Limousine
|-
|S||1987-1990 Cadillac Fleetwood Sixty Special
|-
|T||1991-1993 Cadillac DeVille Touring Sedan
|-
|rowspan=3|GM G platform (models formerly on C platform)
|rowspan=3|C
|-
|U||Buick Park Avenue Ultra 1997-2005
|-
|W||Buick Park Avenue 1997-2005
|-
|rowspan=2|GM D platform
|rowspan=2|D||W||1985-1986 Cadillac Fleetwood Brougham, 1987-1992 Cadillac Brougham
|-
|W||1993-1996 Cadillac Fleetwood
|-
|rowspan=31|GM Delta I platform
|rowspan=31|A
|-
|A||Chevrolet Cobalt LS w/manual trans. 2010
|-
|B||Chevrolet Cobalt LS w/automatic trans. 2010
|-
|C||Chevrolet Cobalt 1LT w/manual trans. 2010
|-
|D||Chevrolet Cobalt 1LT w/automatic trans. 2010
|-
|E||Chevrolet Cobalt 2LT w/manual trans. 2010
|-
|F||Chevrolet Cobalt 2LT w/automatic trans. 2010
|-
|G||Chevrolet Cobalt SS Turbo 2010
|-
|H||Chevrolet Cobalt (base model w/XFE) 2010
|-
|K||Chevrolet Cobalt (base model) 2005, Cobalt LS 2006-2008, Cobalt LS w/man. trans. 2009
|-
|L||Chevrolet Cobalt LS 2005, Cobalt LT 2006-2008, Cobalt LT w/manual trans. 2009
|-
|M||Chevrolet Cobalt SS 2006-2007, Cobalt Sport 2008
|-
|P||Chevrolet Cobalt SS Supercharged 2005-2007, SS Turbo 2008-2009
|-
|S||Chevrolet Cobalt LS w/automatic trans. 2009
|-
|T||Chevrolet Cobalt LT w/automatic trans. 2009
|-
|Z||Chevrolet Cobalt LT 2005, Cobalt LTZ 2006-2007
|-
|L||Pontiac G5 2007-2008, G5 w/manual trans. 2009
|-
|N||Pontiac G5 GT 2007-2008, G5 GT w/manual trans. 2009
|-
|S||Pontiac G5 w/automatic trans. 2009
|-
|T||Pontiac G5 GT w/automatic trans. 2009
|-
|F||Saturn Ion sedan Level 1 w/manual trans. 2003-2005
|-
|G||Saturn Ion sedan Level 1 w/automatic trans. 2003-2005
|-
|J||Saturn Ion sedan Level 2 w/automatic trans. 2003-2007
|-
|K||Saturn Ion sedan Level 3 w/manual trans. 2003-2007
|-
|L||Saturn Ion sedan Level 3 w/automatic trans. 2003-2007
|-
|M||Saturn Ion coupe Level 2 w/manual trans. 2003-2007
|-
|N||Saturn Ion coupe Level 2 w/automatic trans. 2003-2007
|-
|V||Saturn Ion coupe Level 3 w/manual trans. 2003-2007
|-
|W||Saturn Ion coupe Level 3 w/automatic trans. 2003-2007
|-
|Y||Saturn Ion coupe Red Line 2004-2007
|-
|Z||Saturn Ion sedan Level 2 w/manual trans. 2003-2007
|-
|rowspan=9|GM E platform
|rowspan=9|E
|-
|V||Oldsmobile Toronado Trofeo 1988-1992
|-
|Z||Oldsmobile Toronado Brougham 1985-1986, Toronado 1987-1992
|-
|C||Buick Reatta 1988-1991
|-
|Y||Buick Riviera T-Type 1985-1986
|-
|Z||Buick Riviera 1985-1993
|-
|C||Cadillac Eldorado Collector Series 2002
|-
|L||Cadillac Eldorado 1985-2002
|-
|T||Cadillac Eldorado Touring Coupe 1994-2002
|-
|rowspan=26|GM Epsilon I platform
|rowspan=26|Z||A||Chevrolet Malibu Fleet 2010-2012
|-
|B||Chevrolet Malibu LS 2010-2012
|-
|C||Chevrolet Malibu 1LT 2010-2012
|-
|D||Chevrolet Malibu 2LT 2010-2012
|-
|E||Chevrolet Malibu LTZ 2010-2011, Malibu 1LZ 2012
|-
|F||Chevrolet Malibu Hybrid 2008-2010, Malibu 3LT 2012
|-
|G||Chevrolet Malibu LS 2008-2009, Malibu 2LZ 2012
|-
|H||Chevrolet Malibu 1LT 2008-2009
|-
|J||Chevrolet Malibu 2LT 2008-2009
|-
|K||Chevrolet Malibu LTZ 2008-2009
|-
|S||Chevrolet Malibu 2004-2005, Malibu LS 2006-2007, Malibu Classic LS 2008
|-
|T||Chevrolet Malibu LS 2004-2005, Malibu LT 2006-2007, Malibu Classic LT 2008
|-
|U||Chevrolet Malibu LT 2004-2005, Malibu LTZ 2006-2007
|-
|W||Chevrolet Malibu SS 2006-2007
|-
|A||Pontiac G6 Sedan 2010
|-
|F||Pontiac G6 2.4L Sedan (Base model) 2006, G6 Value Leader (Base model w/1SV) 2007-2008
|-
|G||Pontiac G6 3.5L Sedan (Base model) 2005-2006, G6 (Base model) 2007-2009
|-
|H||Pontiac G6 GT 2005-2009
|-
|J||Pontiac G6 (Base model) 2009 1/2 (Mid-Cycle Revision)
|-
|K||Pontiac G6 GT 2009 1/2 (Mid-Cycle Revision)
|-
|L||Pontiac G6 GXP 2009 1/2 (Mid-Cycle Revision)
|-
|M||Pontiac G6 GTP 2006-2007, G6 GXP 2008-2009
|-
|R||Saturn Aura Green Line 2007-2009
|-
|S||Saturn Aura XE 2007-2009
|-
|V||Saturn Aura XR 2007-2008, Aura XR 2.4L 2009
|-
|X||Saturn Aura XR V6 2009
|-
|rowspan=6|GM F platform
|rowspan=6|F||P||Chevrolet Camaro Sport Coupe 1985-2002, Convertible 1987-1992, 1994-2002
|-
|S||Chevrolet Camaro Berlinetta 1985-1986
|-
|S||Pontiac Firebird 1985-2002, Firebird ''Formula'' 1987-1992
|-
|V||Pontiac Firebird ''Formula / Trans Am'' 1993-2002, Firebird ''Trans Am GT'' 1994
|-
|W||Pontiac Firebird ''Trans Am'' 1985-1992, Firebird ''Trans Am GTA'' 1987-1992
|-
|X||Pontiac Firebird ''S/E'' 1985-1986
|-
|rowspan=13|GM G platform - rear-wheel drive
|rowspan=13|G||Z||Chevrolet Monte Carlo 1985-1988
|-
|J||Pontiac Grand Prix 1985-1987
|-
|K||Pontiac Grand Prix LE 1985-1987
|-
|N||Pontiac Bonneville 1985-1986
|-
|P||Pontiac Grand Prix Brougham 1985-1987
|-
|R||Pontiac Bonneville Brougham 1985-1986
|-
|S||Pontiac Bonneville LE 1985-1986
|-
|K||Oldsmobile Cutlass Salon coupe 1985-1987
|-
|M||Oldsmobile Cutlass Supreme ''Brougham'' 1985-1987,<br /> Cutlass Supreme Classic ''Brougham'' 1988
|-
|R||Oldsmobile Cutlass Supreme 1985-1987, Cutlass Supreme Classic 1988
|-
|J||Buick Regal 1985-1987
|-
|K||Buick Regal T-Type 1985-1987
|-
|M||Buick Regal ''Limited'' 1985-1987
|-
|rowspan=4|GM G platform - front-wheel drive
|rowspan=4|G||D||1995-1999 Buick Riviera
|-
|R||1995-1999 Oldsmobile Aurora
|-
|R||2001-2002 Oldsmobile Aurora 3.5
|-
|S||2001-2003 Oldsmobile Aurora 4.0
|-
|rowspan=9|GM H platform
|rowspan=9|H||H||Buick Le Sabre 1987
|-
|P||Buick Le Sabre ''Custom'' 1986-1999
|-
|R||Buick Le Sabre ''Limited'' 1986-1999
|-
|C||Oldsmobile Regency 1997-1998, Eighty Eight 50th Anniversary Edition 1999
|-
|N||Oldsmobile Delta 88 Royale 1986-1988, 88 Royale 1989-1995, Eighty Eight & Eighty Eight LS 1996-99
|-
|Y||Oldsmobile Delta 88 Royale Brougham 1986-1988, 88 Royale Brougham 1989-91, Eighty Eight Royale LS 1992-1995, LSS 1996-1999
|-
|X||Pontiac Bonneville 1987, Bonneville LE 1988-1991, Bonneville ''SE'' 1992-1999
|-
|Y||Pontiac Bonneville SSE 1988-1991, Bonneville ''SSEi'' 1992-1993
|-
|Z||Pontiac Bonneville LE 1987, Bonneville SE 1988-1991, Bonneville ''SSE'' 1992-1999, Bonneville ''SSEi'' 1994-1999
|-
|rowspan=17|GM G platform (models formerly on H platform or their successors)
|rowspan=17|H||A||Buick Lucerne ''CX'' 2010-2011
|-
|B||Buick Lucerne ''CX-2'' 2010
|-
|C||Buick Lucerne ''CXL'' 2010-2011
|-
|D||Buick Lucerne ''CXL V6'' 2006-2009, Lucerne ''CXL Special Edition'' 2010
|-
|E||Buick Lucerne ''CXS'' 2006-2008, Lucerne ''CXL-3'' 2010
|-
|F||Buick Lucerne ''Super'' 2008-2009, Lucerne ''CXL-4'' 2010
|-
|G||Buick Lucerne ''CXL-5'' 2010
|-
|H||Buick Lucerne ''Super 1SP'' 2010
|-
|J||Buick Lucerne ''CXL Premium'' 2010-2011
|-
|K||Buick Lucerne ''Super 1XS'' 2010, Lucerne ''Super'' 2011
|-
|P||Buick Lucerne ''CX'' 2006-2009
|-
|R||Buick Lucerne ''CXL V8'' 2006-2007, Lucerne ''CXL Special Edition V8'' 2008
|-
|P||Buick Le Sabre ''Custom'' 2000-2005
|-
|R||Buick Le Sabre ''Limited'' 2000-2005
|-
|X||Pontiac Bonneville ''SE'' 2000-2005
|-
|Y||Pontiac Bonneville ''SLE'' 2000-2005
|-
|Z||Pontiac Bonneville ''SSEi'' 2000-2003, Bonneville GXP 2004-2005
|-
|rowspan=23|GM J platform
|rowspan=23|J
|-
|C||Chevrolet Cavalier 1985-1994, RS Convertible 1991-1994
|-
|D||Chevrolet Cavalier CS 1985-1987
|-
|E||Chevrolet Cavalier Type 10 1985, RS 1986-1988,<br /> Type 10 Convertible 1985, RS Convertible 1986-1987
|-
|F||Chevrolet Cavalier Z24 1986-1994, Z24 Convertible 1988-1989, 1992-1994
|-
|C||Chevrolet Cavalier 1995-2005, Cavalier RS 1997-1999
|-
|F||Chevrolet Cavalier LS Sedan 1995-2005, LS Coupe 2003-2005, Z24 Coupe 1995-2001,<br /> LS Convertible 1995-1997, Z24 Convertible 1998-2000
|-
|H||Chevrolet Cavalier Z24 Coupe/Sedan 2002, LS Sport 2002-2005
|-
|S||Chevrolet Cavalier LS Coupe 2002
|-
|B||Pontiac Sunbird 1985-1989, Sunbird LE 1990-1991, Sunbird SE 1992-1993,<br /> Sunbird LE 1994
|-
|C||Pontiac Sunbird LE 1985, Sunbird 1991, Sunbird LE 1992-1993
|-
|D||Pontiac Sunbird SE 1985-1991, Sunbird GT 1992-1993
|-
|L||Pontiac Sunbird SE 1994
|-
|U||Pontiac Sunbird GT 1986-1991
|-
|B||Pontiac Sunfire SE 1995-2002, Convertible 1995-2000, Sunfire 2003-2005
|-
|D||Pontiac Sunfire GT 1995-2002
|-
|C||Oldsmobile Firenza Base model 1985-1987, Firenza S 1985-1987, Firenza 1988
|-
|D||Oldsmobile Firenza LX 1985-1987, Firenza SX 1985, Firenza LC, GT 1986-1987
|-
|E||Buick Skyhawk T-Type 1985-1986
|-
|S||Buick Skyhawk Custom 1985-1987, Skyhawk Sport 1986-1987, Skyhawk 1988-1989
|-
|T||Buick Skyhawk Limited 1985-1987
|-
|G||Cadillac Cimarron 1985-1988
|-
|G, H||Toyota Cavalier (Japan only)
|-
|rowspan=8|GM2900 platform
|rowspan=8|J||C||Saturn L-Series|2004 Saturn L300.1
|-
|D||Saturn L-Series|2004 Saturn L300.2, 2005 Saturn L300
|-
|L||Saturn L-Series|2004 Saturn L300.3
|-
|R||Saturn L-Series|Saturn LS w/manual transmission '00/L100 w/manual transmission '01
|-
|S||Saturn L-Series|Saturn LS w/automatic transmission '00/L100 w/automatic transmission '01-'02
|-
|T||Saturn L-Series|Saturn LS1 w/manual transmission '00/L200 w/manual transmission '01-'03, LW200 w/manual trans. '02
|-
|U||Saturn L-Series|Saturn LS1 w/automatic transmission '00/L200 w/automatic transmission '01-'03,<br> Saturn LW1 w/automatic transmission '00/LW200 w/automatic transmission '01-'03
|-
|W||Saturn L-Series|Saturn LS2 '00, LW2 '00, L300 '01-'03, LW300 '01-'03
|-
|rowspan=5|GM K platform
|rowspan=5|K||D||Cadillac Deville 1994-1999
|-
|E||Cadillac Deville D'Elegance 1997-1999
|-
|F||Cadillac Deville Concours 1994-1999
|-
|S||Cadillac Seville 1985-1993 / Cadillac Seville SLS 1994-1997
|-
|Y||Cadillac Seville Touring Sedan / Cadillac Seville STS 1990-1997
|-
|rowspan=9|GM G platform (models formerly on K platform)
|rowspan=9|K||A||2010-2011 Cadillac DTS
|-
|D||2000-2005 Cadillac Deville, 2006-2009 Cadillac DTS, 2010-2011 DTS Luxury
|-
|E||2000-2005 Cadillac Deville DHS
|-
|F||2000-2005 Cadillac Deville DTS
|-
|H||2010-2011 Cadillac DTS Premium
|-
|P||2010-2011 Cadillac DTS Platinum
|-
|R||2010-2011 Cadillac DTS Livery
|-
|S|| 1998-2004 Cadillac Seville SLS
|-
|Y|| 1998-2003 Cadillac Seville STS
|-
|rowspan=33|GM Kappa platform
|rowspan=33|M||A||Pontiac Solstice w/automatic transmission 2010
|-
|B||Pontiac Solstice 2006-2007, Solstice w/manual transmission 2008-2009
|-
|B||Pontiac Solstice GXP w/automatic transmission 2010
|-
|C||Pontiac Solstice w/automatic transmission 2008
|-
|D||Pontiac Solstice w/manual transmission 2010
|-
|E||Pontiac Solstice GXP w/manual transmission 2010
|-
|F||Pontiac Solstice GXP w/automatic transmission 2008
|-
|G||Pontiac Solstice GXP 2007, Solstice GXP w/manual transmission 2008-2009
|-
|K||Pontiac Solstice Street Edition w/manual transmission 2009
|-
|N||Pontiac Solstice w/automatic transmission 2009
|-
|S||Pontiac Solstice SCCA SSB Championship Edition (2.4L) 2008
|-
|T||Pontiac Solstice SCCA T2 Championship Edition (2.0L Turbo) 2008
|-
|T||Pontiac Solstice GXP w/automatic transmission 2009
|-
|Z||Pontiac Solstice Street Edition w/automatic transmission 2009
|-
|B||Saturn Sky 2007, Sky w/manual transmission 2008-2009
|-
|B||Saturn Sky Redline w/automatic transmission 2010
|-
|C||Saturn Sky w/automatic transmission 2008
|-
|C||Saturn Sky Ruby Red (Merlot Jewel) Special Edition w/manual transmission 2009
|-
|C||Saturn Sky Preferred w/automatic transmission 2010
|-
|D||Saturn Sky Hydro Blue Special Edition w/manual transmission 2009
|-
|E||Saturn Sky Redline w/manual transmission 2010
|-
|F||Saturn Sky Redline w/automatic transmission 2008
|-
|F||Saturn Sky Preferred w/manual transmission 2010
|-
|G||Saturn Sky Redline 2007, Sky Redline w/manual transmission 2008-2009
|-
|H||Saturn Sky Redline Ruby Red (Merlot Jewel) Special Edition w/manual transmission 2009
|-
|L||Saturn Sky Redline Hydro Blue Special Edition w/manual transmission 2009
|-
|N||Saturn Sky w/automatic transmission 2009
|-
|P||Saturn Sky Ruby Red (Merlot Jewel) Special Edition w/automatic transmission 2009
|-
|R||Saturn Sky Hydro Blue Special Edition w/automatic transmission 2009
|-
|T||Saturn Sky Redline w/automatic transmission 2009
|-
|V||Saturn Sky Redline Ruby Red (Merlot Jewel) Special Edition w/automatic transmission 2009
|-
|X||Saturn Sky Redline Hydro Blue Special Edition w/automatic transmission 2009
|-
|G||Opel GT 2007-2010, Daewoo G2X 2007-2009
|-
|rowspan=8|GM L platform
|rowspan=8|L
|-
|D||Chevrolet Corsica ''Base'' 1994-1996
|-
|T||Chevrolet Corsica ''Base'' 1987-1989, Corsica ''LT'' 1990-1993
|-
|V||Chevrolet Beretta ''Base'' 1987-1996
|-
|W||Chevrolet Beretta "GT" 1989-1993 (RPO Z21) & Beretta ''Z26'' 1994-1996 (RPO Z04)
|-
|Z||Chevrolet Corsica ''LTZ'' 1989-1990 (RPO Z54)
|-
|Z||Chevrolet Beretta "GTZ" 1990-1993 (RPO Z04)
|-
|T||Pontiac Tempest (Canada only)
|-
|rowspan=5|GM M platform
|rowspan=5|M||R||Chevrolet Sprint
|-
|R||Geo Metro LSi, Metro
|-
|R||Pontiac Firefly (Canada only)
|-
|S||Chevrolet Sprint ER
|-
|S||Geo Metro, Metro XFi
|-
|rowspan=32|GM N platform
|rowspan=32|N
|-
|B||Oldsmobile Cutlass 1997, Cutlass ''GL'' 1998-1999
|-
|C||Buick Skylark 4-door ''Custom'' 1987-1991
|-
|D||Buick Skylark 4-door ''Limited'' 1987-1989, Skylark 4-door ''Luxury Edition'' 1990-1991
|-
|D||Chevrolet Malibu 1997-2003, Chevrolet Classic 2004-2005
|-
|E||Chevrolet Malibu ''LS'' 1997-2003
|-
|E||Pontiac Grand Am 1985-1988, Grand Am ''LE'' 1989-1991
|-
|E||Pontiac Grand Am ''SE'' 1992-2005
|-
|F||Oldsmobile Calais 1985-1987, Cutlass Calais 1988, Cutlass Calais ''S'' 1989-1991
|-
|F||Oldsmobile Achieva ''SL'' 1992-1994, Achieva ''SC'' 1994
|-
|F||Oldsmobile Alero ''GLS'' 1999-2004
|-
|F||Pontiac Grand Am ''SE1'' 2000-2004
|-
|G||Oldsmobile Cutlass ''GLS'' 1997-1999
|-
|G||Pontiac Grand Am 1991
|-
|G||Pontiac Grand Am ''SE2'' 2000, 2003-2004
|-
|J||Buick Somerset Regal 1985, Somerset ''Custom'' 1986-1987, Skylark 2-door ''Custom'' 1988-91, Skylark 4-door ''Custom'' 1986
|-
|J||Buick Skylark 1992, Skylark ''Limited'' 1993-1994, Skylark ''Custom'' 1996-1998,<br /> Skylark ''Limited'' & ''Gran Sport'' 1996-1997
|-
|K||Buick Somerset ''T-Type'' 1986
|-
|K||Oldsmobile Cutlass Calais ''International Series'' 1988-1991
|-
|K||Oldsmobile Alero ''GX'' 1999-2004
|-
|L||Oldsmobile Cutlass Calais 1989-1991
|-
|L||Oldsmobile Achieva ''S'' 1992-1995, Achieva ''SL'' 1996-1998, Achieva ''SC'' 1996-1997
|-
|L||Oldsmobile Alero ''GL'' 1999-2004
|-
|M||Buick Somerset Regal ''Limited'' 1985, Somerset ''Limited'' 1986-'87, Skylark 2-door ''Limited'' '88-'89, Skylark 2-door ''Gran Sport'' 1990-1991, Skylark 4-door ''Limited'' 1986
|-
|M||Buick Skylark ''Gran Sport'' 1992-1994
|-
|T||Oldsmobile Calais ''Supreme'' 1985-1987, Cutlass Calais ''SL'' 1988-1991
|-
|V||Buick Skylark 1990-1991
|-
|V||Buick Skylark ''Custom'' 1993-1995, ''Limited'' 1995, ''Gran Sport'' 1995
|-
|V||Pontiac Grand Am ''LE'' 1985-1988
|-
|V||Pontiac Grand Am ''GT1'' 2000-2005
|-
|W||Pontiac Grand Am ''SE'' 1986-1991
|-
|W||Pontiac Grand Am ''GT'' 1992-2005
|-
|rowspan=5|GM P platform - rear-wheel drive
|rowspan=5|P
|-
||E||Pontiac Fiero ''Coupe'' 1985-1988
|-
||F||Pontiac Fiero ''SE'' 1985-1987
|-
||G||Pontiac Fiero ''GT'' 1985-1988
|-
||M||Pontiac Fiero ''Sport coupe'' 1985-1987
|-
|rowspan=1|GM P platform - front-wheel drive
|rowspan=1|P||X||General Motors EV1 1997, 1999
|-
|rowspan=6|GM R platform
|rowspan=6|R
|-
||F||1985-1986 Chevrolet Spectrum
|-
||F||1987-1988 Chevrolet Spectrum 3-door hatchback, 1989 Geo Spectrum 3-door hatchback
|-
||F||1990-1993 Geo Storm
|-
||G||1987-1988 Chevrolet Spectrum 4-door sedan, 1989 Geo Spectrum 4-door sedan
|-
||T||1990-1993 Geo Storm GSi
|-
|rowspan=8|GM S platform
|rowspan=8|S||K||1985-1988 Chevrolet Nova
|-
|K||1989-1997 Geo Prizm, 1998-2002 Chevrolet Prizm
|-
|L||1988 Chevrolet Nova Twin Cam, 1990-1992 Geo Prizm GSi
|-
|L||2003-2008 Pontiac Vibe, 2009-2010 Pontiac Vibe FWD w/manual transmission
|-
|M||2003-2006 Pontiac Vibe ''AWD'', 2009-2010 Pontiac Vibe AWD w/automatic transmission
|-
|N||2003-2006 Pontiac Vibe ''GT'', 2009-2010 Pontiac Vibe GT FWD w/manual transmission
|-
|P||2009-2010 Pontiac Vibe FWD w/automatic transmission
|-
|R||2009-2010 Pontiac Vibe GT FWD w/automatic transmission
|-
|rowspan=32|GM Sigma platform
|rowspan=32|D||A||Cadillac CTS Base model RWD 2010-2013, CTS Coupe Base model RWD 2014
|-
|B||Cadillac CTS Wagon Luxury Collection RWD 2014
|-
|C||Cadillac CTS Base model AWD 2010-2013, CTS Coupe/Wagon Performance Collection RWD 2014
|-
|D||Cadillac CTS Coupe/Wagon Premium Collection RWD 2014
|-
|E||Cadillac CTS Luxury Collection RWD 2010-2013, CTS Coupe Base model AWD 2014
|-
|F||Cadillac CTS Auto. Trans. RWD 2008-2009, CTS Luxury Collection RWD w/Navigation 2010-2013, CTS Wagon Luxury Collection AWD 2014
|-
|G||Cadillac CTS Auto. Trans. AWD 2008-2009, CTS Luxury Collection AWD 2010-2013, CTS Coupe/Wagon Performance Collection AWD 2014
|-
|H||Cadillac CTS Auto. Trans. AWD w/Navigation 2008-2009, CTS Luxury Collection AWD w/Navigation 2010-2013, CTS Coupe/Wagon Premium Collection AWD 2014
|-
|J||Cadillac CTS Auto. Trans. RWD w/Navigation 2008-2009, CTS Performance Collection RWD 2010-2013
|-
|K||Cadillac CTS Performance Collection RWD w/Navigation 2010-2013
|-
|L||Cadillac CTS Performance Collection AWD 2010-2013
|-
|M||Cadillac CTS V6 2003-2004, CTS 2.8L 2005-2007, CTS Man. Trans. RWD 2008-2009, CTS Performance Collection AWD w/Navigation 2010-2013
|-
|N||Cadillac CTS V-Series 2004-2007, 2009
|-
|P||Cadillac CTS 3.6L 2005-2007, CTS Direct Inj. V6 Man. Trans. RWD 2008-2009, CTS Premium Collection RWD w/Navigation 2010-2013
|-
|R||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD 2008
|-
|S||Cadillac CTS Direct Inj. V6 Auto. Trans. AWD 2008-2009, CTS Premium Collection AWD w/Navigation 2010-2013
|-
|T||Cadillac CTS Direct Inj. V6 Auto. Trans. AWD w/Navigation 2008-2009
|-
|U||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD 2009
|-
|V||Cadillac CTS Direct Inj. V6 Auto. Trans. RWD w/Navigation 2008-2009, CTS sedan V-Series 2010-2014, CTS Wagon V-Series 2011-2014, CTS Coupe V-Series 2011-2015
|-
|0||Cadillac CTS Sport Appearance Pkg. 2010
|-
|1||Cadillac CTS Eco Luxury Pkg. 2010
|-
|2||Cadillac CTS Sport Appearance Pkg. 2011
|-
|A||Cadillac STS V6 AWD 2008-2009
|-
|B||Cadillac STS V8 AWD 2008-2009
|-
|C||Cadillac STS V8 2005-2007, STS V8 RWD 2008-2009
|-
|D||Cadillac STS V6 AWD w/Navigation 2008-2009
|-
|K||Cadillac STS V6 RWD w/Navigation 2008-2009
|-
|L||Cadillac STS V8 AWD w/Navigation 2008-2009
|-
|U||Cadillac STS (all models) 2010, STS (Base model) 2011
|-
|W||Cadillac STS V6 2005-2007, STS V6 RWD 2008-2009, STS Luxury 2011
|-
|X||Cadillac STS V-Series 2006-2009, STS Luxury Performance 2011
|-
|Z||Cadillac STS V8 RWD w/Navigation 2008-2009
|-
|rowspan=4|GM T platform - rear-wheel drive
|rowspan=4|T||B|| 1985-1987 Chevrolet Chevette CS
|-
|B||1985-1987 Pontiac Acadian (Canada only)
|-
|J||1985 Pontiac Acadian Scooter (Canada only)
|-
|L||1985-1987 Pontiac 1000
|-
|rowspan=4|GM T platform - front-wheel drive
|rowspan=4|T||N|| Pontiac LeMans 1988, LeMans LE 1989-1991, LeMans SE 1992-1993
|-
|R||1988-1989 Pontiac LeMans SE sedan
|-
|S||1988-1990 Pontiac LeMans GSE AeroCoupe
|-
|X||1988-1993 Pontiac LeMans VL AeroCoupe
|-
|rowspan=3|GM T platform - front-wheel drive
|rowspan=3|A
|-
|R||Saturn Astra XE (US: 2008, Canada: 2008-2009)
|-
|T||Saturn Astra XR (US: 2008, Canada: 2008-2009)
|-
|rowspan=4|Daewoo T200 platform
|rowspan=4|T||D||Chevrolet Aveo Special Value 2004-2008, Base model 2004, LS 2005-2011, Aveo 1LT 2009-2011
|-
|G||Chevrolet Aveo LT 2005-2008, Aveo 2LT 2009-2011
|-
|J||Chevrolet Aveo LS 2004
|-
|D||Pontiac G3 2009
|-
|rowspan=2|GM V platform - front-wheel drive
|rowspan=2|V||R||1987-1992 Cadillac Allanté with standard removable hardtop
|-
|S||1990-1993 Cadillac Allanté
|-
|rowspan=2|GM V platform - rear-wheel drive
|rowspan=2|V||R||1997-2001 Cadillac Catera
|-
|X||2004-2006 Pontiac GTO coupe
|-
|rowspan=49|GM W platform
|rowspan=49|W
|-
|A||Chevrolet Impala ''LS'' 2010-2013, Impala Limited ''LS'' 2014-2016
|-
|B||Chevrolet Impala ''LS'' 2006-2009, Impala ''LT'' 2010-2013, Impala Limited ''LT'' 2014-2016
|-
|C||Chevrolet Impala ''LT'' 3.9L 2006-2009, Impala ''LTZ'' 2010-2013, Impala Limited ''LTZ'' 2014-2016
|-
|D||Chevrolet Impala ''SS'' 2006-2009, Impala ''Police'' 2010-2013, Impala Limited ''Police'' 2014-2016
|-
|E||Chevrolet Impala ''Taxi'' 2010-2012
|-
|F||Chevrolet Impala 2000-2005, Impala ''LS'' Fleet (1FL) 2011-2013
|-
|G||Chevrolet Impala ''LT'' Fleet (2FL) 2011-2013
|-
|H||Chevrolet Impala ''LS'' 2000-2005
|-
|J||Chevrolet Monte Carlo ''LS'' 2006-2007
|-
|K||Chevrolet Monte Carlo ''LT'' 3.9L 2006, Monte Carlo ''LT'' 3.5L 2007
|-
|L||Chevrolet Lumina 1990-2001, Lumina ''LS'' 1997-1999
|-
|L||Chevrolet Monte Carlo ''SS'' 2006-2007
|-
|M||Chevrolet Monte Carlo ''LT'' 3.5L 2006
|-
|N||Chevrolet Lumina ''Euro'' 1990-1994, Lumina ''LS'' 1995-1996, Lumina ''LTZ'' 1997-1999
|-
|N||Chevrolet Monte Carlo ''LTZ'' 2006
|-
|P||Chevrolet Lumina ''Z34'' 1991-1994, Impala ''SS'' 2004-2005
|-
|S||Chevrolet Impala ''Police'' 2006-2009
|-
|T||Chevrolet Impala ''LT'' 3.5L 2006-2009
|-
|U||Chevrolet Impala ''LTZ'' 2006-2009
|-
|V||Chevrolet Impala ''50th Anniversary Edition'' 2008
|-
|W||Chevrolet Monte Carlo ''LS'' 1995-2005
|-
|X||Chevrolet Monte Carlo ''Z34'' 1995-1999, Monte Carlo ''SS'' 2000-2004, Monte Carlo ''LT'' 2005
|-
|Z||Chevrolet Monte Carlo ''SS Supercharged'' 2004-2005
|-
|C||Pontiac Grand Prix ''GXP'' 2005-2008
|-
|H||Pontiac Grand Prix ''LE'' 1991-1993
|-
|J||Pontiac Grand Prix 1988-1989, Grand Prix ''LE'' 1990, Grand Prix ''SE'' 1991-2000
|-
|K||Pontiac Grand Prix ''LE'' 1988-1989, Grand Prix ''SE1'' 2000-2003
|-
|P||Pontiac Grand Prix ''SE'' 1988-1990, Grand Prix ''GT'' 1991-1993, 1997-2003,<br /> Grand Prix ''GT1'' 2004, Grand Prix 2005-2008
|-
|R||Pontiac Grand Prix ''GTP'' 1999-2005, Grand Prix ''GT'' 2006-2007
|-
|S||Pontiac Grand Prix ''GT2'' 2004, Grand Prix ''GT'' 2005
|-
|T||Pontiac Grand Prix ''STE'' 1990-1993
|-
|H||Oldsmobile Cutlass Supreme 1988-1991, Cutlass Supreme ''S'' 1992-1994,<br /> Cutlass Supreme ''SL'' 1995-1997, Intrigue 1998, Intrigue ''GX'' 1999-2002
|-
|R||Oldsmobile Cutlass Supreme ''International Series'' 1988-1993
|-
|S||Oldsmobile Cutlass Supreme ''SL'' 1988-1991, Intrigue ''GL'' 1998-2002
|-
|T||Oldsmobile Cutlass Supreme Convertible 1990-1995
|-
|X||Oldsmobile Intrigue ''GLS'' 1998-2002
|-
|B||Buick Regal ''Custom'' 1988-1996, Regal ''GS'' Coupe 1995-1996, Regal ''LS'' 1997-2004
|-
|C||Buick Lacrosse ''CX'' 2005-2009
|-
|D||Buick Regal ''Limited'' 1988-1996, Lacrosse ''CXL'' 2005-2009
|-
|E||Buick Lacrosse ''CXS'' 2005-2008
|-
|F||Buick Regal ''GS'' Coupe 1992-1994, Regal ''GS'' Sedan 1992-2004
|-
|F||Buick Allure ''CX'' 2005-2009 (Canada only)
|-
|H||Buick Allure ''CXS'' 2005-2008 (Canada only)
|-
|J||Buick Allure ''CXL'' 2005-2009 (Canada only)
|-
|N||Buick Lacrosse ''Super'' 2008-2009
|-
|P||Buick Allure ''Super'' 2008-2009 (Canada only)
|-
|S||Buick Century ''Custom'' 1997-2005
|-
|Y||Buick Century ''Limited'' 1997-2002
|-
|rowspan=3|GM X platform
|rowspan=3|X||B||1985 Buick Skylark Custom
|-
|C||1985 Buick Skylark Limited
|-
|X||1985 Chevrolet Citation II
|-
|rowspan=39|GM Y platform
|rowspan=39|Y||V||2004-2009 Cadillac XLR
|-
|X||2006-2009 Cadillac XLR V-Series
|-
|Y||1985-2008 Chevrolet Corvette (all models except '90-'95 ZR-1)
|-
|Z||1990-1995 Chevrolet Corvette ZR-1
|-
|G||2009 Chevrolet Corvette GT1 Championship Edition (Base & Z06)
|-
|R||2009 Chevrolet Corvette ZR1 (after early production)
|-
|Y||2009 Chevrolet Corvette (Base model, Early production Z06, Early production ZR1)
|-
|Z||2009 Chevrolet Corvette Z06 (after early production)
|-
|A||2010-2013 Chevrolet Corvette Standard 1LT Man. Trans.
|-
|B||2010-2013 Chevrolet Corvette Preferred 2LT Man. Trans.
|-
|C||2010-2013 Chevrolet Corvette Premium 3LT Man. Trans.
|-
|D||2010-2013 Chevrolet Corvette Custom 4LT Man. Trans.
|-
|E||2010-2013 Chevrolet Corvette Standard 1LT Auto. Trans.
|-
|F||2010-2013 Chevrolet Corvette Preferred 2LT Auto. Trans.
|-
|G||2010-2013 Chevrolet Corvette Premium 3LT Auto. Trans.
|-
|H||2010-2013 Chevrolet Corvette Custom 4LT Auto. Trans.
|-
|J||2010-2013 Chevrolet Corvette Z06 Standard 1LZ Man. Trans.
|-
|K||2010-2013 Chevrolet Corvette Z06 Premium 2LZ Man. Trans.
|-
|L||2010-2013 Chevrolet Corvette Z06 Custom 3LZ Man. Trans.
|-
|M||2010-2013 Chevrolet Corvette ZR1 Standard 1ZR Man. Trans.
|-
|N||2010-2013 Chevrolet Corvette ZR1 Custom 3ZR Man. Trans.
|-
|P||2010-2013 Chevrolet Corvette Grand Sport Standard 1LT Man. Trans.
|-
|R||2010-2013 Chevrolet Corvette Grand Sport Preferred 2LT Man. Trans.
|-
|S||2010-2013 Chevrolet Corvette Grand Sport Premium 3LT Man. Trans.
|-
|T||2010-2013 Chevrolet Corvette Grand Sport Custom 4LT Man. Trans.
|-
|U||2010-2013 Chevrolet Corvette Grand Sport Standard 1LT Auto. Trans.
|-
|V||2010-2013 Chevrolet Corvette Grand Sport Preferred 2LT Auto. Trans.
|-
|W||2010-2013 Chevrolet Corvette Grand Sport Premium 3LT Auto. Trans.
|-
|X||2010-2013 Chevrolet Corvette Grand Sport Custom 4LT Auto. Trans.
|-
|Y||2013 Chevrolet Corvette 427 Convertible Collector Edition Premium 3LT Man. Trans.
|-
|Z||2013 Chevrolet Corvette 427 Convertible Collector Edition Custom 4LT Man. Trans.
|-
|1||2013 Chevrolet Corvette 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|2||2013 Chevrolet Corvette 60th Anniversary Edition Custom 4LT Auto. Trans.
|-
|3||2013 Chevrolet Corvette Grand Sport 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|4||2013 Chevrolet Corvette Grand Sport 60th Anniversary Edition Custom 4LT Auto. Trans.
|-
|5||2013 Chevrolet Corvette Z06 60th Anniversary Edition Custom 3LZ Man. Trans.
|-
|6||2013 Chevrolet Corvette ZR1 60th Anniversary Edition Custom 3ZR Man. Trans.
|-
|7||2013 Chevrolet Corvette 427 Convertible 60th Anniversary Edition Custom 4LT Man. Trans.
|-
|8||2013 Chevrolet Corvette 427 Convertible Collector Edition Preferred 2LT Man. Trans.
|-
|rowspan=13|GM Z platform
|rowspan=13|Z
|-
|E||Saturn SC1 (manual transmission 2-Door) 1993-1999
|-
|F||Saturn SC1 (automatic transmission 2-Door) 1993-1999, SL (manual transmission) 1991-02
|-
|G||Saturn SC (manual transmission) 1991-1992, SC2 (manual transmission 2-Door) 1993-99,<br /> SL1 (manual transmission) 1991-2002, SW1 (manual transmission) 1993-1999
|-
|H||Saturn SC (automatic transmission) 1991-92, SC2 (automatic transmission 2-Door) '93-'99,<br /> SL1 (automatic transmission) 1991-02, SW1 (automatic transmission LHD) '93-'99
|-
|J||Saturn SL2 (manual transmission) 1991-2002, SW2 (manual transmission) 1993-2001
|-
|K||Saturn SL2 (automatic transmission) 1991-2002, SW2 (automatic transmission 1993-1999)
|-
|M||Saturn SW1 "Postal" [SWP] (automatic transmission RHD) 1999-2001 <br>(Made for US Postal Service rural route mail carriers)
|-
|N||Saturn SC1 (manual transmission 3-Door) 1999-2002, SW2 (automatic transmission 2000-01)
|-
|P||Saturn SC1 (automatic transmission 3-Door) 1999-2002
|-
|R||Saturn SC2 (manual transmission 3-Door) 1999-2002
|-
|S||Saturn SL Spring Special 2002
|-
|Y||Saturn SC2 (automatic transmission 3-Door) 1999-2002
|-
|rowspan=3|GM Zeta platform (VE)
|rowspan=3|E||C||Pontiac G8 GT
|-
|P||Pontiac G8 GXP
|-
|R||Pontiac G8 (Base model)
|-
|rowspan=2|GM Zeta platform (VF)
|rowspan=2|F||1||2014-2017 Chevrolet SS w/automatic transmission
|-
|2||2015-2017 Chevrolet SS w/manual transmission
|-
|GM Zeta platform (WM)
|M||K||2011-2013 Chevrolet Caprice PPV
|-
|GM Zeta platform (WN)
|N||S||2014-2017 Chevrolet Caprice PPV
|-
|rowspan=19|GM Zeta platform (models formerly on F platform)
|rowspan=19|F||A||Chevrolet Camaro ''LS'' automatic transmission 2010-2011, ''2LS'' automatic transmission 2012-2014, ''LS'' manual transmission 2015
|-
|B||Chevrolet Camaro ''LT'' automatic transmission 2010-2014, ''2LS'' automatic transmission 2015
|-
|C||Chevrolet Camaro ''2LT'' automatic transmission 2010-2014, ''LT'' manual transmission 2015
|-
|D||Chevrolet Camaro ''LT'' automatic transmission 2015
|-
|E||Chevrolet Camaro ''LS'' manual transmission 2010-2014, ''2LT'' manual transmission 2015
|-
|F||Chevrolet Camaro ''LT'' manual transmission 2010-2014, ''2LT'' automatic transmission 2015
|-
|G||Chevrolet Camaro ''2LT'' manual transmission 2010-2014, ''SS'' manual transmission 2015
|-
|H||Chevrolet Camaro ''SS'' automatic transmission 2015
|-
|J||Chevrolet Camaro ''SS'' automatic transmission 2010-2014. Note: Must have "J" in 8th position of VIN.
|-
|J||Chevrolet Camaro ''ZL1'' automatic transmission 2012. Note: Must have "P" in 8th position of VIN.
|-
|J||Chevrolet Camaro ''2SS'' manual transmission 2015
|-
|K||Chevrolet Camaro ''2SS'' automatic transmission 2010-2015
|-
|L||Chevrolet Camaro ''ZL1'' automatic transmission 2013-2014, ''ZL1'' manual transmission 2015
|-
|M||Chevrolet Camaro ''ZL1'' automatic transmission 2015
|-
|S||Chevrolet Camaro ''SS'' manual transmission 2010-2014. Note: Must have "W" in 8th position of VIN.
|-
|S||Chevrolet Camaro ''ZL1'' manual transmission 2012. Note: Must have "P" in 8th position of VIN.
|-
|S||Chevrolet Camaro ''Z/28'' manual transmission 2014. Note: Must have "E" in 8th position of VIN.
|-
|T||Chevrolet Camaro ''2SS'' manual transmission 2010-2014
|-
|Z||Chevrolet Camaro ''ZL1'' manual transmission 2013-2014, ''Z/28'' manual transmission 2015
|-
|}
RHD= Right-Hand Drive
====Model Line 2010- Passenger Car (Using Vehicle Platforms introduced 2010 or later)====
The Model Line is specified as character 4 of the American GM VIN for Passenger Cars.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|A||Cadillac ATS 2013-2019
|-
|A||Cadillac CTS sedan 2014-2019, CTS V-Series sedan 2016-2019
|-
|B||Chevrolet Cruze 2016-2019
|-
|C||Chevrolet Spark 2013-2022, Spark EV 2014-2016
|-
|D||Cadillac CT4 2020-2026
|-
|D||Cadillac CT5 2020-
|-
|F||Chevrolet Camaro 2016-2024
|-
|F||Chevrolet Bolt EV 2017-2023, Bolt EUV 2022-2023, Bolt 2027
|-
|G||Buick LaCrosse 2010-2016
|-
|G||Buick Regal 2011-2020, Buick Regal TourX 2018-2020
|-
|J||Chevrolet Sonic 2016-2020
|-
|K||Cadillac CT6 2016-2020
|-
|M||Cadillac Celestiq EV 2025-
|-
|P||Buick Verano 2012-2017
|-
|P||Chevrolet Cruze 2011-2015, Cruze Limited 2016
|-
|R||Cadillac ELR 2014, 2016
|-
|R||Chevrolet Volt 2011-2019
|-
|W||Buick Cascada 2016-2019
|-
|Y||Chevrolet Corvette 2014-
|-
|Z||Buick LaCrosse 2017-2019
|-
|Z||Chevrolet Malibu 2016-2025
|-
|1||Cadillac XTS 2013-2019
|-
|1||Chevrolet Impala 2014-2020
|-
|1||Chevrolet Malibu 2013-2015, Malibu Limited 2016
|-
|}
===Body style codes 1987- Passenger Car===
The Body type is specified as character 6 of the American GM VIN for passenger cars.
{| border=1 style="margin:auto;"
!VIN
!Description
|-
|1||Two-Door Coupe/Sedan
|-
|2||Two-Door Hatchback
|-
|3||Two-Door Convertible
|-
|4||Two-Door Wagon ('91-'92 Geo Storm Hatchback)
|-
|5||Four-Door Sedan
|-
|6||Four-Door Hatchback
|-
|7||Four-Door Hatchback ('89-'90 Geo Prizm hatchback)
|-
|8||Four-Door Station Wagon
|-
|9||Four-Door Station Wagon - High Roof Monocab
|}
===American restraint types 1987-===
The restraint type is specified as character 7 of the American GM VIN for passenger cars.
{{center/top}}
====Restraint codes for passenger cars 1987-2009====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|1||Active (Manual) belts 1987-1996
|-
|2||Active (Manual) belts plus driver and passenger front airbags 1992-2005<br />(For '94-'96 Pontiac Grand Prix coupe: Passive (Automatic) belts plus driver and passenger front airbags)
|-
|3||Active (Manual) belts plus driver side front airbag 1988-1996 <br />(For '94 Geo Prizm: Active (Manual) belts plus driver and passenger front airbags)
|-
|4||Passive (Automatic) belts 1987-1996
|-
|4||Active (Manual) belts plus driver and passenger front & side airbags 1997-2005
|-
|4||Active (Manual) belts plus driver and passenger front & side curtain airbags 2006-2009
|-
|5||Passive (Automatic) belts plus driver side front airbag 1992-1996
|-
|5||Active (Manual) belts plus driver and passenger front airbags & driver-side side impact airbag 2000-2005
|-
|5||Active (Manual) belts plus driver and passenger front airbags & occupant sensor 2006-2009
|-
|6||Passive (Automatic) belts plus driver and passenger front airbags 1994-1996
|-
|6||Active (Manual) belts plus driver and passenger front & side airbags & occupant sensor 2000-2009
|-
|7||Active (Manual) belt driver & Passive (Automatic) belt passenger plus driver and passenger front airbags 1996
|-
|7||Active (Manual) belts plus driver and passenger front & side airbags & rear side airbags 2000-2005
|-
|7||Active (Manual) belts plus driver and passenger front & side & side curtain airbags & occupant sensor 2006-2009
|-
|8||Active (Manual) belts plus driver and passenger front & side curtain airbags & occupant sensor 2006-2009
|-
|9||
|}
{{center/top}}
====Restraint codes for passenger cars 2010-====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|D||Active (Manual) belts plus driver and passenger front & side airbags 2010-
|-
|E||Active (Manual) belts plus driver and passenger front & side & side curtain airbags 2010-2017, 2027
|-
|F||Active (Manual) belts plus driver and passenger front & side curtain airbags 2010
|-
|G||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain airbags 2010-2017
|-
|N||Active (Manual) belts plus driver and passenger front & side & front knee airbags 2016-2019
|-
|R||Active (Manual) belts plus driver and passenger front & side & side curtain & front knee airbags 2012-
|-
|S||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain & front knee airbags 2011-
|-
|T||Active (Manual) belts plus driver and passenger front & side & front row side curtain airbags 2011
|-
|U||Active (Manual) belts plus driver and passenger front & side & front row side curtain & front knee airbags 2012-2017
|}
{{center/top}}
====Restraint codes for light trucks 2010-====
{{center/end}}
{| border=1 style="margin:auto;"
!VIN Code
!Description
|-
|A||Active (Manual) belts plus driver-side front airbag 2010
|-
|B||Active (Manual) belts plus driver-side front airbag 2011-
|-
|B||Active (Manual) belts plus driver and passenger front airbags 2010
|-
|C||Active (Manual) belts plus driver and passenger front airbags 2011-
|-
|C||Active (Manual) belts plus driver and passenger front & side airbags 2010
|-
|D||Active (Manual) belts plus driver and passenger front & side airbags 2011-
|-
|D||Active (Manual) belts plus driver and passenger front airbags & side curtain airbags for up to 3 rows of seating 2010
|-
|E||Active (Manual) belts plus driver and passenger front & side & side curtain airbags 2010-
|-
|F||Active (Manual) belts plus driver and passenger front airbags & side curtain airbags for up to 3 rows of seating 2011-2015
|-
|F||Active (Manual) belts plus driver and passenger front & side airbags & side curtain airbags for up to 3 rows of seating 2016-
|-
|H||Active (Manual) belts plus driver-side front airbag & driver-side side-impact airbag & driver-side side curtain airbag 2023-2024
|-
|K||Active (Manual) belts plus driver and passenger front & side & side curtain & front center airbags 2013-
|-
|L||Active (Manual) belts plus driver and passenger front & side & side curtain & front center & driver-side knee airbags 2017-2023
|-
|M||Active (Manual) belts plus driver and passenger front & side & side curtain & front center & front knee airbags 2025-
|-
|R||Active (Manual) belts plus driver and passenger front & side & side curtain & front knee airbags 2017-
|-
|S||Active (Manual) belts plus driver and passenger front & side & rear side & side curtain & front knee airbags 2013-
|-
|T||Active (Manual) belts plus driver-side front airbag & driver- and passenger-side side-impact airbags & side curtain airbags 2023-
|-
|U||Active (Manual) belts plus driver and passenger front & side & front row side curtain & front knee airbags 2013-2019
|}
===American engine codes 1981-===
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
====Engine codes for passenger cars====
Warning: Issues with decoding are related to year/model combinations. Each year has a different breakdown for each code along with plants and some model/trim breakdowns over years.
Entry: 1985-1988 Pontiac Fiero has a 9 engine code for the 2.8L L44 V6. Entry: 1986-1990 Cadillac Brougham, Oldsmobile 307 Cu. In. V8 vin code Y.
{| border=1 style="margin:auto;"
!VIN
!RPO
!Size
!Type
!Fuel
!Valvetrain
!Engine Family/Notes/Applications
|-
|A||LD5||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Buick V6. (231 cu. in.) '81 Chevy Camaro (CA), Pontiac Catalina, Firebird, LeMans, Buick Century,<br /> '81-'83 Chevy Malibu (CA), '81-'84 Monte Carlo, Caprice, Impala (CA), '81-'87 Pontiac Grand Prix, Oldsmobile Cutlass/Cutlass Supreme, Buick Regal, '81-'85 Oldsmobile Delta 88, Buick LeSabre,<br /> '81-'86 Pontiac Bonneville, '84 Parisienne
|-
|A||LG0||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4 H.O. '89-'94 Pontiac Grand Am, '89-'91 Oldsmobile Cutlass Calais, '92-'94 Achieva, '90 Cutlass Supreme, '90-'94 Chevy Beretta
|-
|A||LH2||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (For RWD) (Premium V). '04-'09 Cadillac XLR, '05-'10 Cadillac STS
|-
|A||LCV||2.5 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. '13 Chevy Malibu, '16 Malibu Limited, '16-'19 Impala,<br /> '13-'16 Cadillac ATS
|-
|A||LV7||1.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. Made in Changwon, S. Korea. '16-'22 Chevy Spark.
|-
|B||LG2||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6. '86 Oldsmobile 98, Toronado, Buick Electra, Riviera.
|-
|B||L26||4.9 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8.<br /> '91-'93 Cadillac Eldorado, Seville, '91-'95 DeVille, '91-'92 Fleetwood, '91-'93 Sixty Special
|-
|B||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '06-'08 Chevy Cobalt, '06-'07 Saturn Ion, '06-'10 Pontiac G6, Solstice,<br /> '07-'08 Pontiac G5, '07-'10 Saturn Sky, '08-'09 Saturn Aura, '08-'10 Chevy Malibu
|-
|B||LUV||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. '12-'20 Chevy Sonic, '13-'15 Chevy Cruze, '16 Cruze Limited
|-
|C||L17||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu G161Z engine made by GM in US. '82-'87 Chevy Chevette, Pontiac T1000/1000
|-
|C||LN3||3.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6 (3800). '88-'90 Oldsmobile 98, Toronado, Buick Electra, Riviera, Reatta, <br /> '88-'91 Buick LeSabre, Oldsmobile Delta 88/Eighty Eight, Pontiac Bonneville
|-
|C||L47||4.0 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Oldsmobile Aurora V8 (Premium V). Oldsmobile Aurora '95-'99, Aurora 4.0 '01-'03
|-
|C||LS4||5.3 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. Active Fuel Management.<br /> Transversely mounted for FWD. '05-'08 Pontiac Grand Prix GXP, '06-'07 Chevy Monte Carlo SS,<br /> '06-'09 Chevy Impala SS, '08-'09 Buick LaCrosse Super.
|-
|C||LAF||2.4 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. VVT. Buick LaCrosse '10-'11, Regal '11.
|-
|C||LUJ||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. Early production engines were made in Aspern, Austria; later made in Flint, MI. '12 Chevy Cruze
|-
|D||LJ5||1.8 L||Straight-4|I4||Indirect injection Diesel||SOHC,<br /> 8 valve||Isuzu 4FB1 diesel engine imported from Japan. '81-'86 Chevy Chevette
|-
|D||LD2||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4. '88-'95 Pontiac Grand Am, '88-'91 Oldsmobile Cutlass Calais, '92-'95 Achieva,<br /> '88-'91 &'95 Buick Skylark, '90-'91 Pontiac Grand Prix, Oldsmobile Cutlass Supreme,<br /> '95 Chevy Cavalier, Pontiac Sunfire
|-
|D||LC3||4.4 L||V8 Supercharged||Fuel injection#Sequential Multi-port point injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (Premium V). '06-'09 Cadillac XLR V-Series, Cadillac STS V-Series
|-
|E||LK9||3.0 L||V6||2 Barrel Carburetor |2BBL||OHV||Buick V6. '82-'85 Oldsmobile Cutlass Ciera, Buick Century, '85 Oldsmobile 98, Buick Electra
|-
|E||LA1||3.4 L||V6||Fuel injection#Sequential Multi-port point injection|SFI||OHV||Chevrolet 60° V6. '99-'05 Grand Am, '99-'04 Alero, '00-'05 Impala, Monte Carlo
|-
|E||L03||5.0 L||V8||Fuel injection#Throttle Body injection|TBI||OHV||Gen I Chevy Small-Block V8 (305 cu. in.). '88-'92 Camaro/Firebird, '89-'93 Chevy Caprice,<br /> '91 Buick Roadmaster Estate wagon, '91-'92 Oldsmobile Custom Cruiser, Cadillac Brougham.
|-
|E||LXV||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Family 1 Gen 3 engine. W/VVT. '09-'11 Chevy Aveo, '09 Pontiac G3
|-
|E||LS7||7.0 L||V8||Fuel injection#Sequential Multi-port point injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '06-'13 Corvette Z06, '13 Corvette 427, '14-'15 Camaro Z/28
|-
|E||LH7||1.6 L||I4 Turbo||Direct injection <br /> Common-rail Diesel||DOHC,<br /> 16 valve||GM Medium Diesel engine ("Whisper Diesel"). Made by Opel in Szentgotthárd, Hungary.<br /> Aluminum Block & Heads. '17-'19 Chevy Cruze Diesel.
|-
|F||LV8||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Oldsmobile "Rocket" V8 (260 cu. in.) '81 Oldsmobile Cutlass, Delta 88.
|-
|F||L61||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen I. '00-'04 Saturn L-Series, '02-'05 Chevy Cavalier, Pontiac Sunfire, Grand Am,<br /> '02-'04 Oldsmobile Alero, '03-'06 Saturn Ion, '04-'06 Chevy Malibu, '05-'06 Chevy Cobalt
|-
|F||L61||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. '07-'08 Chevy Cobalt, Malibu, Pontiac G5, '07 Saturn Ion.
|-
|F||LB9||5.0 L||V8||Tuned-port fuel injection|TPI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.). '85-'92 Chevy Camaro, Pontiac Firebird.
|-
|G||L46||1.8 L||I4||2 Barrel Carburetor |2BBL||OHV||Chevrolet "122" engine. '82 J-cars.
|-
|G||L69||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8 (High Output 5.0L). (305 cu. in.)<br /> '84-'86 Camaro/Firebird, '84-'88 Chevy Monte Carlo SS
|-
|G||LM3||2.2 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '90-'91 Chevy Cavalier & Corsica/Beretta.
|-
|G||LS1||5.7 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Gen III Chevy Small-Block V8. (346 cu. in.) Aluminum Block & Heads.<br /> '97-'04 Corvette, '98-'02 Camaro/Firebird, '04 Pontiac GTO
|-
|G||LF1||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. 2010 Buick LaCrosse, Cadillac CTS
|-
|G||LWE||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. PZEV emissions.<br /> '13-'15 Chevy Cruze, '16 Cruze Limited, '13-'18 Sonic.
|-
|H||LG4||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '81-'87 F-bodies, '81-'83 Chevy Malibu, '81-'85 Impala,<br /> '81-'88 Caprice, Monte Carlo, '83-'86 Pontiac Bonneville, Parisienne, '83-'87 Grand Prix
|-
|H||LE4||2.0 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil. '92-'94 Pontiac Sunbird.
|-
|H||LX5||3.5 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||Oldsmobile "Shortstar" V6 (Premium V). Oldsmobile Intrigue '99-'02, Aurora 3.5 '01-'02.
|-
|H||LAP||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '09 Chevy Cobalt, Pontiac G5.
|-
|H||LUW||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. '11-'15 Chevy Cruze, '16 Cruze Limited, '12-'18 Sonic.
|-
|J||L39||4.4 L||V8||2 Barrel Carburetor |2BBL||OHV||Gen I Chevy Small-Block V8 (267 cu. in.) '81-'82 Chevy Caprice, Impala, Malibu, Monte Carlo,<br /> '81 Chevy Camaro
|-
|J||LA5||1.8 L||Straight-4|I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil. '84-'86 Pontiac Sunbird, Buick Skyhawk.
|-
|J||LT5||5.7 L||V8||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 32 valve||Based on Chevy Small-Block V8. Designed with Lotus Engineering.<br /> Made by Mercury Marine. Aluminum Block & Heads. '90-'95 Corvette ZR-1
|-
|J||LG8||3.1 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Chevrolet 60° V6. Gen III. 3100. '99-'03 Chevy Malibu, '99 Oldsmobile Cutlass, '00-'01 Chevy Lumina,<br /> '00-'03 Pontiac Grand Prix SE, '00-'05 Buick Century
|-
|J||L99||6.2 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. VVT. With Active Fuel Management. Aluminum Block & Heads.<br /> '10-'15 Camaro SS (auto. trans.)
|-
|J||LTA||4.2 L||V8 Twin Turbo||Direct injection|DI||DOHC,<br /> 32 valve||Cadillac Blackwing V8. VVT. '19-'20 Cadillac CT6 Platinum & V-series
|-
|K||LC3||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '81-'82 Malibu, Monte Carlo, Impala, Caprice, '81 Camaro.
|-
|K||LC5||1.5 L||I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu 4XC1 engine. '85 Chevrolet Spectrum.
|-
|K||LT2||2.0 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '87-'91 Pontiac Sunbird, '87-'88 Oldsmobile Firenza, Buick Skyhawk.
|-
|K||LT2||2.0 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Australia by Holden.<br /> '89-'90 Pontiac LeMans GSE Aerocoupe, '89 LeMans SE sedan
|-
|K||L36||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Series II). '95-'05: Various W-, H-, C-, & G-body models. '95-'02 Camaro/Firebird.
|-
|K||LZE||3.5L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3510cc. VVT. Flex-Fuel E85 compatible.<br /> '06-'07 Chevy Monte Carlo, '06-'11 Chevy Impala, '09-'10 Chevy Malibu, Pontiac G6
|-
|K||LEA||2.4 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||E85 Flex Fuel. GM Ecotec engine, Gen II. VVT. Buick Regal, Verano '12-'17 (except '13 Regal).
|-
|K||LSY||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Active Fuel Management. VVT. VVL.<br /> '19 Cadillac CT6, '20+ Cadillac CT4, CT5
|-
|L||LM1||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8.<br> '81 Camaro Z28 (only w/auto. trans. in US), '81-'82 Impala 9C1 Police, '81 Malibu 9C1 Police
|-
|L||LL1||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 H.O. (longitudinally mounted). '83-'84 Pontiac Firebird.
|-
|L||LN7||3.0 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6. '85-'87 Pontiac Grand Am, '85-'88 Oldsmobile & Buick N-bodies,<br /> '86 Oldsmobile Delta 88, Buick LeSabre
|-
|L||L27||3.8 L||V6||Fuel injection#Tuned port injection|TPI||OHV||Buick V6 (3800 Series I). '90-'95 Buick Regal, '91-'94 Oldsmobile 98, Buick Park Avenue, '91 Reatta, '91-'93 Riviera, '91-'92 Oldsmobile Toronado, '92-'95 Buick LeSabre, '92-'94 Pontiac Bonneville, Oldsmobile 88
|-
|L||LNK||1.8 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2ZZ-GE engine. VVTL-i. '03-'06 Pontiac Vibe GT
|-
|L||LKW||2.5 L||Straight-4|I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. VVL. '14-'15 Chevy Malibu, Impala
|-
|L||L3B||2.7L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM L3B Tripower engine. VVT, VVL. Active Fuel Management. '20+ Cadillac CT4, CT4-V
|-
|M||LY9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '85 Chevrolet Sprint
|-
|M||LT3||2.0 L||Straight-4|I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '87-'90 Pontiac Sunbird, '87 Buick Skyhawk T-Type, '87-'89 Pontiac Grand Am SE.
|-
|M||L82||3.1 L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||Chevrolet 60° V6 (transversely mounted). Gen III. 3100. '93-'97 Oldsmobile Cutlass Supreme,<br /> '94-'98 Pontiac Grand Am, Oldsmobile Achieva, Buick Skylark, '94-'99 Pontiac Grand Prix,<br /> '94-'96 Chevy Corsica/Beretta, Oldsmobile Cutlass Ciera, Buick Regal, '94-'99 Century,<br /> '95-'99 Chevy Lumina, Monte Carlo, '97-'99 Chevy Malibu, Oldsmobile Cutlass
|-
|M||LY9||2.6 L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). Euro-market Cadillac CTS '03-'04.
|-
|M||LGD||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||E85 Flex Fuel. GM High Value 60° V6. VVT. '09-'11 Chevy Impala, Buick Lucerne
|-
|M||LE2||1.4 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. '16-'19 Chevy Cruze.
|-
|N||LF9||5.7 L||V8||Indirect injection Diesel||OHV||Oldsmobile Diesel V8. '81-'85 Chevy Caprice, Impala, '82-'83 Malibu, '82-'84 Monte Carlo,<br /> '81-'84 Pontiac Grand Prix, Bonneville, '81 Catalina, '83-'85 Parisienne,<br /> '81-'84 Oldsmobile 98, '81-'85 Cutlass/Cutlass Supreme, Delta 88, Custom Cruiser, Toronado,<br /> '81-'83 Buick Electra, '81-'85 LeSabre, Electra Estate wagon, Riviera, '82-'83 Regal,<br /> '81-'84 Cadillac DeVille, '81-'85 Fleetwood Brougham, Eldorado, Seville
|-
|N||LG7||3.3 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Buick V6 (3300). '89-'93 Buick Century, Skylark, Oldsmobile Cutlass Ciera, '89-'91 Cutlass Calais,<br /> '92-'93 Achieva, Pontiac Grand Am.
|-
|N||LA3||3.2 L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). '03-'04 Cadillac CTS
|-
|N||LZ4||3.5L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3510cc. VVT. '06-'07 Chevy Monte Carlo, '06-'10 Chevy Impala,<br /> '07-'10 Chevy Malibu, Pontiac G6, '07-'08 Saturn Aura
|-
|N||LFR||3.6L||V6||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 24 valve||(Bi-Fuel Gas/CNG). GM High Feature V6. '15-'17 Chevy Impala Bi-Fuel
|-
|P||LQ5||2.0 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '83-'86 J-cars ('83-'84 for Pontiac).
|-
|P||LT1||5.7 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. Aluminum Heads: '92-'96 Corvette, '93-'97 Camaro/Firebird.<br /> Iron Heads: '94-'96 Chevy Caprice, Impala SS, Buick Roadmaster, Cadillac Fleetwood.
|-
|P||LSJ||2.0 L||SC Straight-4|I4 Supercharged||Fuel injection#Sequential central point injection|SFI||DOHC,<br /> 16 valve||GM Ecotec Gen I. Made by Opel in Kaiserslautern, Germany.<br /> '04-'07 Saturn Ion Red Line, '05-'07 Chevy Cobalt SS Supercharged.
|-
|P||LSA||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> Cadillac CTS V-Series '09-'15, Camaro ZL1 '12-'15
|-
|P||LF4||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. Cadillac CT4-V Blackwing '22+
|-
|R||LR8||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Transversely mounted. '82-'85 Chevy Citation, Buick Skylark,<br /> '82-'84 Pontiac Phoenix, Oldsmobile Omega, '82-'90 Chevy Celebrity, '82-'91 Pontiac 6000,<br /> '82-'92 Oldsmobile Cutlass Ciera, Buick Century, '84-'88 Pontiac Fiero, '90-'92 Chevy Lumina
|-
|R||L81||3.0 L||V6||Fuel injection#Multi-port fuel injection|SFI||DOHC,<br /> 24 valve||Opel 54° V6 engine (Made in the UK). '97-'01 Cadillac Catera, '00-'05 Saturn L-Series
|-
|R||LZ8||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||GM High Value 60° V6. VVT. Active Fuel Management. '07 Chevy Impala
|-
|R||LS9||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. '09 Corvette ZR1.
|-
|R||LUK||2.4L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '12-'16 Buick LaCrosse eAssist, Regal eAssist,<br /> '13-'14 Chevy Malibu Eco, '14 Chevy Impala Eco
|-
|S||LS5||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Pontiac V8. 265 cu. in.<br /> '81 Pontiac Bonneville, Catalina, Firebird, Grand Prix, LeMans, Buick Century, Regal.
|-
|S||LU5||5.0 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '83 Camaro, Firebird. Dual throttle-body fuel injection.
|-
|S||LB8||2.8 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '85-'89 Chevy Camaro, Pontiac Firebird.
|-
|S||L32||3.4 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '93-'95 Chevy Camaro, Pontiac Firebird.
|-
|S||LS6||5.7 L||V8||Fuel injection#Sequential Multi Port injection|SFI||OHV||Gen III Chevy Small-Block V8. (346 cu. in.) Aluminum Block & Heads.<br /> '01-'04 Corvette Z06, '04-'05 Cadillac CTS V-Series
|-
|S||LGX||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '16-'19 Cadillac ATS, CTS, '16-'20 CT6, '16-'24 Chevrolet Camaro, '17-'19 Buick LaCrosse, '18–'20 Buick Regal GS
|-
|T||LU8||4.9 L||V8 Turbo||4 Barrel Carburetor |4BBL||OHV||Pontiac V8. 301 cu. in. '81 Pontiac Firebird Formula & Trans Am.
|-
|T||LT7||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. FWD version for '82-'85 GM A-bodies.
|-
|T||LS2||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. FWD version for '85 GM C-bodies.
|-
|T||LH0||3.1 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (longitudinally mounted). '90-'92 Chevy Camaro, Pontiac Firebird.
|-
|T||LH0||3.1 L||V6||Fuel injection#Multi Port Fuel injection|MPFi||OHV||Chevrolet 60° V6 (transversely mounted). Gen II. '88-'91 Pontiac 6000,<br /> '89-'93 Grand Prix, Oldsmobile Cutlass Supreme, Buick Regal, '90-'94 Chevy Cavalier, Lumina,<br /> '91-'94 Pontiac Sunbird, '90-'93 Chevy Corsica/Beretta, '90 Celebrity
|-
|T||LD9||2.4 L||Straight-4|I4||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 16 valve||Oldsmobile Quad 4 ("2.4 Twin Cam"). '96-'01 Pontiac Grand Am, '96-'97 Oldsmobile Achieva, Buick Skylark, '99-'01 Oldsmobile Alero, '97-'99 Chevy Malibu, '96-'02 Chevy Cavalier, Pontiac Sunfire
|-
|T||LP1||2.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||GM High Feature V6. '05-'07 Cadillac CTS
|-
|T||LS9||6.2 L||V8 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. '10-'13 Corvette ZR1.
|-
|T||LFV||1.5L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. '16-'25 Chevy Malibu.
|-
|U||L68||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Transversely mounted. '85-'91 N-bodies
|-
|U||LS2||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '05-'07 Corvette, '05-'06 Pontiac GTO, '06-'07 Cadillac CTS V-Series
|-
|U||LE9||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. E85 Flex-Fuel. 2011-12 Chevy Malibu.
|-
|U||LKN||1.8L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||Full Hybrid. GM Medium Gasoline Engine. VVT. Made in Szentgotthárd, Hungary.<br> '16-'19 Chevy Malibu Hybrid
|-
|V||LT6||4.3 L||V6||Indirect injection Diesel||OHV||Oldsmobile Diesel V6. RWD version.<br /> '82-'83 Chevy Malibu, Monte Carlo, '82-'85 Oldsmobile Cutlass Supreme, Buick Regal
|-
|V||LG5||3.1 L||V6 Turbo||Fuel injection#Multi-port fuel injection|MPFI||OHV||Chevrolet 60° V6. Gen II. Intercooled. (ASC/McLaren modified).<br /> '89-'90 Pontiac Grand Prix Turbo coupe, '90 Grand Prix STE Turbo sedan
|-
|V||LLT||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. '08-'11 Cadillac CTS, STS, '10-'11 Chevrolet Camaro, Buick LaCrosse
|-
|V||LHU||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||E85 Flex Fuel (N/A on Regal GS). GM Ecotec engine, Gen II. VVT.<br /> Buick Regal '11-'13, Verano '13-'16.
|-
|W||L37||4.9 L||V8||4 Barrel Carburetor |4BBL||OHV||Pontiac V8. 301 cu. in. '81 Pontiac Firebird, LeMans Safari wagon.
|-
|W||LB6||2.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Gen I/II Chevrolet 60° V6 (transversely mounted). '85 Chevy Citation, Buick Skylark,<br /> '85-'89 Chevy Cavalier, Celebrity, Pontiac 6000, '85-'88 Cadillac Cimarron,<br /> '85-'87 Oldsmobile Firenza, '86-'89 Cutlass Ciera, '87-'88 Buick Century, '87-'89 Chevy Corsica/Beretta, '88-'89 Pontiac Grand Prix, Oldsmobile Cutlass Supreme, Buick Regal
|-
|W||L64||3.1 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Flex-fuel: Gas/M85 or Gas/E85 (2 versions). Gen II Chevrolet 60° V6. '93 Chevy Lumina VFV
|-
|W||L99||4.3 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. '94-'96 Chevy Caprice.
|-
|W||LS3||6.2 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads.<br /> '08-'13 Corvette, '10-'15 Camaro SS (man. trans.), '09 Pontiac G8 GXP, '14-'17 Chevy SS
|-
|W||LGY||3.0L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '20+ Cadillac CT5, CT5-V
|-
|X||LE2||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (transversely mounted). '81-'85 Chevy Citation, Buick Skylark,<br /> '81-'84 Pontiac Phoenix, Oldsmobile Omega, '82-'86 Chevy Celebrity, Pontiac 6000,<br /> '86 Oldsmobile Cutlass Ciera, Buick Century
|-
|X||LQ1||3.4 L||V6||Fuel injection#Multi-port fuel injection|MPFI||DOHC,<br /> 24 valve||Chevrolet 60° V6 ("Twin Dual Cam V6"). '91-'97 Chevy Lumina, '95-'97 Chevy Monte Carlo,<br /> '91-'96 Pontiac Grand Prix, Oldsmobile Cutlass Supreme
|-
|X||LNF||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. VVT.<br /> '07-'10 Pontiac Solstice GXP, Saturn Sky Red Line, '08-'10 Chevy Cobalt SS Turbo.
|-
|X||LTG||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. VVT. '13-'22 Chevy Malibu, '13-'19 Cadillac ATS, '14-'20 Buick Regal,<br /> '14-'19 Cadillac CTS, '16-'23 Chevy Camaro, '16-'18 Cadillac CT6.
|-
|X||LTG||2.0 L||Straight-4|I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||Plug-in hybrid. GM Ecotec engine, Gen III. VVT. '17-'18 Cadillac CT6 PHEV. (VIN starts with LRE)
|-
|Y||LV2||5.0 L||V8||4 Barrel Carburetor |4BBL||OHV||Oldsmobile "Rocket" V8 (307 cu. in.) '86-'90 Chevy Caprice wagon, '87 Caprice sedan (Can.),<br /> '81 Pontiac Bonneville, Catalina, '86 Parisienne, '87-'89 Safari wagon, '81-'84 Oldsmobile 98,<br /> '81-'85 Delta 88, Toronado, '81-'90 Custom Cruiser, '81 Cutlass Cruiser, '82-'87 Cutlass Supreme,<br /> '88 Cutlass Supreme Classic, '81-'84 Buick Electra, '85-'89 Electra Estate wagon,<br /> '81-'85 LeSabre, Riviera, '86-'89 LeSabre Estate wagon, '90 Estate wagon, '86-'87 Regal,<br /> '86 Cadillac Fleetwood Brougham, '87-'90 Brougham
|-
|Y||LD8||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (Torque tuned FWD) (Premium V). '93-'02 Cadillac Eldorado,<br /> '94-'04 Cadillac Seville SLS, '94-'05 Cadillac DeVille, '06-'11 Cadillac DTS,<br /> '04-'05 Pontiac Bonneville GXP, '06-'08 Buick Lucerne
|-
|Y||L76||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management.<br /> '08-'09 Pontiac G8 GT.
|-
|Y||LF1||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. 2011 Cadillac CTS
|-
|Y||LF4||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. Cadillac ATS-V '16-'19
|-
|Z||LH7||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (transversely mounted). H.O. '81-'84 Chevy Citation, '82-'84 Pontiac Phoenix, Oldsmobile Omega ES, Buick Skylark, '83-'84 Pontiac 6000 STE, '84 Chevy Celebrity
|-
|Z||LB4||4.3L||V6||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '85 Chevy Impala, '85-'90 Caprice,<br /> '92-'93 Caprice 9C6 taxi, '85-'88 Monte Carlo, '85-'86 Pontiac Parisienne, '86-'87 Grand Prix,<br> '86 Bonneville.
|-
|Z||LAT||2.4L||I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '10 Chevy Malibu Hybrid
|-
|Z||LUZ||2.0 L||I4 Turbo||Direct injection <br /> Common-rail Diesel||DOHC,<br /> 16 valve||GM Family B Diesel (Based on Fiat JTD engine). Made by Opel in Kaiserslautern, Germany.<br /> Iron Block, Aluminum Heads. '14-'15 Chevy Cruze Diesel.
|-
|1||LC1||2.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 60° V6 (longitudinally mounted). '82-'84 Camaro/Firebird.
|-
|1||LL8||2.0 L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Chevrolet "122" engine. '87-'89 Chevy/Olds/Buick J-cars & Chevy L-cars.
|-
|1||L67||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series I). '91-'95 Buick Park Avenue Ultra,<br /> '92-'95 Pontiac Bonneville, Oldsmobile 98, '95 Buick Riviera, Oldsmobile LSS
|-
|1||L67||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series II). '96-'05 Buick Park Avenue Ultra,<br /> '96-'99 Buick Riviera, Oldsmobile LSS, '96-'03 Pontiac Bonneville, '97-'03 Grand Prix,<br /> '97-'04 Buick Regal, '04-'05 Chevy Impala SS, Monte Carlo SS Supercharged
|-
|1||LZ9||3.9L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. VVT.<br /> '06-'07 Chevy Malibu SS, '06-'09 Pontiac G6, '06 Chevy Monte Carlo, Impala, '09-'10 Buick Lucerne
|-
|1||2H0||1.8 L||Straight-4|I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 1 engine, Gen III. VVT. Made in Szentgotthárd, Hungary. '08 (& '09 in Canada) Saturn Astra
|-
|1||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '11 & some '12 Chevy Malibu w/LE5 engine.
|-
|2||LQ9||2.5L||I4||Fuel injection#Throttle Body injection|TBI||OHV||Pontiac Iron Duke/Tech IV engine. Longitudinally mounted. '82-'85 Camaro/Firebird.
|-
|2||LS3||1.0 L||Straight-3|I3 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 6 valve ||Suzuki G10T engine. '87-'88 Chevrolet Sprint Turbo
|-
|2||LY8||1.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 16 valve||Suzuki G13BB engine. '98-'01 Chevrolet Metro
|-
|2||L26||3.8 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Series III). '04-'08 Pontiac Grand Prix, '05-'09 Buick LaCrosse, '06-'08 Buick Lucerne
|-
|2||L77||6.0 L||V8||Fuel injection#Sequential Multi-port fuel injection|SFI||OHV||Gen IV Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management.<br /> E85 Flex Fuel. '11-'17 Chevy Caprice PPV.
|-
|3||LC8||3.8 L||V6|V6 Turbo||4 Barrel Carburetor |4BBL||OHV||Buick V6. 231 cu. in. '81-'82 Buick Regal, Riviera, '81 Chevy Monte Carlo.
|-
|3||LG3||3.8 L||V6||Fuel injection#(Sequential) Multi-port injection|MFI/SFI||OHV||Buick V6. '84-'88 Oldsmobile Cutlass Ciera, Buick Century, '85 & '87 Oldsmobile 98, Buick Electra,<br /> '86-'88 Oldsmobile Delta 88, Buick LeSabre, '87 Oldsmobile Toronado, Buick Riviera,<br /> '87-'88 Pontiac Bonneville.
|-
|3||LW2||4.5 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '90 Cadillac DeVille/Fleetwood/Sixty Special/Eldorado/Seville.
|-
|3||L40||2.3 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||Oldsmobile Quad 4 ("Quad OHC"). '92-'94 Pontiac Grand Am, Oldsmobile Achieva, Buick Skylark
|-
|3||LZG||3.9L||V6||Fuel injection#Sequential Multi Port Fuel injection|SFI||OHV||E85 Flex Fuel. GM High Value 60° V6. VVT. Active Fuel Management. '08 Chevy Impala
|-
|3||LFX||3.6L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. E85 Flex Fuel.<br /> '12-'16 Buick LaCrosse, '12-'15 Chevrolet Camaro, Cadillac CTS, '12-'17 Chevrolet Caprice PPV,<br /> '12-'20 Chevrolet Impala, '14-'16 Chevrolet Impala Limited, '13-'15 Cadillac ATS, '13-'19 Cadillac XTS
|-
|3||LT6||5.5 L||V8||Direct injection|DI||DOHC,<br /> 32 valve||Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette Z06 '23+.
|-
|4||LC4||4.1 L||V6|V6||4 Barrel Carburetor |4BBL||OHV||Buick V6. '81-'84 Buick LeSabre, Electra, Riviera, Oldsmobile Toronado, '81-'82 Cadillac DeVille, Fleetwood Brougham, Eldorado, Seville, '81-'83 Oldsmobile 98, '82-'84 Buick Regal,<br /> '82 Pontiac Grand Prix, Bonneville G
|-
|4||LC9||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Toyota 4A-C engine. '85-'88 Chevy Nova
|-
|4||LN2||2.2 L||Straight-4|I4||Fuel injection#(Sequential) Multi-port injection|MPI/SFI||OHV||Chevrolet "122" engine. '92-'02 Cavalier, '95-'02 Sunfire, '92-'96 Corsica/Beretta, '93 Lumina,<br /> '93-'96 Cutlass Ciera, Century.
|-
|4||L32||3.8 L||V6 Supercharged||Fuel injection#Sequential Multi-port injection|SFI||OHV||Buick V6 (3800 Supercharged Series III). '04-'07 Pontiac Grand Prix
|-
|4||LUU||1.4L||I4||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. ([[w:EREV|Range extender]]). Early production engines were made in Aspern, Austria; later made in Flint, MI. '11-'15 Chevy Volt, '14 & '16 Cadillac ELR.
|-
|4||LT2||6.2 L||V8||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Stingray '20+.
|-
|4||LT2||6.2 L||V8||Direct injection|DI||OHV||Full Hybrid. Gen V Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette E-Ray '24+.
|-
|5||LW9||2.5L||I4||2 Barrel Carburetor |2BBL||OHV||Pontiac Iron Duke engine. '81 Chevy Citation, Pontiac Phoenix, Oldsmobile Omega, Buick Skylark.
|-
|5||LR6||4.5 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac High Technology V8. '88-'89 Cadillac DeVille/Fleetwood/Sixty Special/Eldorado/Seville.
|-
|5||LY9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '86 Chevrolet Sprint
|-
|5||LM9||1.0 L||Straight-3|I3||2BBL||SOHC,<br /> 6 valve ||Suzuki G10A engine. '87-'88 Chevrolet Sprint
|-
|5||LW0||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 4A-GE engine. '88 Chevy Nova Twin Cam, '90-'92 Geo Prizm GSi
|-
|5||LW0||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Isuzu 4XE1-UW engine. '90-'91 Geo Storm GSi
|-
|5||LT4||5.7 L||V8||Fuel injection#Sequential Multi-port injection|SFI||OHV||Gen II Chevy Small-Block V8. '96 Corvette (man. trans.)
|-
|5||LAT||2.4L||I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Mild Hybrid. GM Ecotec Gen II. VVT. '07-'09 Saturn Aura Green Line, '08-'09 Chevy Malibu Hybrid
|-
|5||LAP||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. '10 Chevy Cobalt.
|-
|5||LFW||3.0L||V6||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. '12-'13 Cadillac CTS, '14 CTS wagon
|-
|5||L3A||1.5L||I4||Direct Injection|DI||DOHC,<br /> 16 valve||GM Small Gasoline Engine. VVT. ([[w:EREV|Range extender]]). '16-'19 Chevy Volt.
|-
|5||LWC||1.6L||I4 Turbo||Direct Injection|DI||DOHC,<br /> 16 valve||GM Medium Gasoline Engine, H.O. VVT. Made in Szentgotthárd, Hungary. '16-'19 Buick Cascada
|-
|5||LS6||6.7 L||V8||Port/Direct injection||OHV||Gen VI Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Stingray, Grand Sport '27+.
|-
|5||LS6||6.7 L||V8||Port/Direct injection||OHV||Full Hybrid. Gen VI Chevy Small-Block V8. Aluminum Block & Heads. Active Fuel Management. VVT.<br /> For mid-engine C8 Corvette Grand Sport X '27+.
|-
|6||L81||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. '81 Corvette
|-
|6||LM1||5.7 L||V8||4 Barrel Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8. '83-'85 Impala 9C1 Police, '86-'88 Caprice 9C1 Police
|-
|6||L73||1.6 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family 1 engine. Made in South Korea by Daewoo. '88-'93 Pontiac LeMans
|-
|6||LP2||1.0 L||Straight-3|I3||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 6 valve ||Suzuki G10A engine. '89-'97 Geo Metro, '98-'00 Chevrolet Metro
|-
|6||L01||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 4A-FE engine. '89-'97 Geo Prizm base/LSi
|-
|6||L01||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 12 valve||Isuzu 4XE1-V engine. '90-'93 Geo Storm (base model)
|-
|6||L42||2.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen I (Bi-Fuel Gas/CNG). '03-'04 Chevy Cavalier
|-
|6||L91||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||E-TEC II. '04-'07 Chevy Aveo
|-
|6||LXT||1.6 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||E-TEC II. '08 Chevy Aveo
|-
|6||LGW||3.0L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. VVT. Active Fuel Management. '16-'19 Cadillac CT6
|-
|6||LT4||6.2 L||V8 Supercharged||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management. VVT.<br /> '15-'19 Corvette Z06, '17-'24 Camaro ZL1, '16-'19 Cadillac CTS V-Series,<br /> '22+ Cadillac CT5-V Blackwing
|-
|7||LU5||5.0 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. (305 cu. in.) '82 Camaro, Firebird. Dual throttle-body fuel injection.
|-
|7||L69||5.0 L||V8||4 Barrel Quadrajet Carburetor |4BBL||OHV||Gen I Chevy Small-Block V8 (High Output 5.0L). (305 cu. in.). '83 F-cars, '83 Chevy Monte Carlo SS
|-
|7||LC5||1.5 L||I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu 4XC1 engine. '86-'88 Chevrolet Spectrum, '89 Geo Spectrum.
|-
|7||LC2||3.8 L||V6|V6 Turbo||Fuel injection#Sequential multi-port injection|SFI||OHV||Intercooled. Buick V6. '86-'87 Buick Regal. '89 Pontiac 20th Anniversary Turbo Trans Am
|-
|7||LC7||4.1 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '87-'88 Cadillac Allante.
|-
|7||L05||5.7 L||V8||Fuel injection#Throttle Body injection|TBI||OHV||Gen I Chevy Small-Block V8. '89-'93 Chevy Caprice (police only for '89-'91),<br /> '92-'93 Buick Roadmaster, '92 Oldsmobile Custom Cruiser, '90-'92 Cadillac Brougham, '93 Fleetwood.
|-
|7||LL0||1.9 L||Straight-4|I4||Fuel injection#Multi-port injection|MFI||DOHC,<br /> 16 valve||Saturn I4 engine. '91-'02 Saturn S-Series
|-
|7||LY7||3.6 L||V6||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 24 valve||GM High Feature V6. VVT. '04-'09 Cadillac CTS, '05-'07 STS, '05-'08 Buick LaCrosse,<br /> '07-'09 Pontiac G6, Saturn Aura, '08-'09 Pontiac G8, '08-'12 Chevy Malibu
|-
|7||LT1||6.2 L||V8||Direct injection|DI||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. With Active Fuel Management. VVT.<br /> '14-'19 Corvette, '16-'24 Camaro SS
|-
|7||LT7||5.5 L||V8 Twin Turbo||Port/Direct injection||DOHC,<br /> 32 valve||Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette ZR1 '25+. (1,064 hp)
|-
|7||LT7||5.5 L||V8 Twin Turbo||Port/Direct injection||DOHC,<br /> 32 valve||Full Hybrid. Chevrolet Gemini Small-Block V8. Aluminum Block & Heads. Flat-plane crank. VVT.<br /> For mid-engine C8 Corvette ZR1X '26+. (1,250 hp)
|-
|8||LV8||4.3 L||V8||2 Barrel Carburetor |2BBL||OHV||Oldsmobile "Rocket" V8 (260 cu. in.) '82 Oldsmobile Cutlass, Delta 88.
|-
|8||LT8||4.1 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac High Technology V8. '82-'87 Cadillac DeVille, Eldorado, Seville, '82-'85 Fleetwood Brougham, '85-'87 Fleetwood, '87 Fleetwood Sixty Special.
|-
|8||LC8||3.8 L||V6|V6 Turbo||4 Barrel Carburetor |4BBL||OHV||Buick V6. '83 Buick Regal, Riviera.
|-
|8||L83||5.7 L||V8||Cross-Fire fuel injection|CFI||OHV||Gen I Chevy Small-Block V8. '82, '84 Corvette. Dual throttle-body fuel injection. 1st fuel injected Corvette since 1965.
|-
|8||L98||5.7 L||V8||Tuned-port fuel injection|TPI||OHV||Gen I Chevy Small-Block V8. '85-'91 Corvette, '87-'92 Chevy Camaro, Pontiac Firebird.
|-
|8||LQ6||4.5 L||V8||Fuel injection#Multi-port fuel injection|MFI||OHV||Cadillac High Technology V8. '89-'92 Cadillac Allante.
|-
|8||L24||1.9 L||Straight-4|I4||Fuel injection#Multi-port injection|MFI||SOHC,<br /> 8 valve||Saturn I4 engine. '95-'02 Saturn S-Series
|-
|8||LX9||3.5 L||V6||Fuel injection#Sequential Multi-port injection|SFI||OHV||GM High Value 60° V6. 3498cc. '04-'06 Chevy Malibu, '05-'06 Pontiac G6
|-
|8||LF3||3.6L||V6 Twin Turbo||Direct Injection|DI||DOHC,<br /> 24 valve||GM High Feature V6. '14-'19 Cadillac CTS V-Sport, XTS V-Sport
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Isuzu 4XF1 engine. '92-'93 Geo Storm GSi.
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 7A-FE engine. '93-'97 Geo Prizm
|-
|8||LV6||1.8 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Toyota 1ZZ-FE engine. VVT-i from '00. '98-'02 Chevrolet Prizm, '03-'08 Pontiac Vibe
|-
|8||LAY||1.8 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2ZR-FE engine. Dual VVT-i. '09-'10 Pontiac Vibe
|-
|9||L17||1.6 L||Straight-4|I4||2 Barrel Carburetor |2BBL||SOHC,<br /> 8 valve||Isuzu G161Z engine made by GM in US. '81 Chevy Chevette, Pontiac T1000
|-
|9||L62||6.0 L||V8||Fuel injection#Throttle Body injection|TBI (DFI)||OHV||Cadillac 472-series V8 engine family. V8-6-4 cylinder deactivation.<br /> '81 Cadillacs, '82-'84 Fleetwood Limousine.
|-
|9||LC3||3.8 L||V6||2 Barrel Carburetor |2BBL||OHV||Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '83 Malibu, '83-'84 Monte Carlo, Impala, Caprice, '83 Pontiac Parisienne.
|-
|9||LG8||5.0 L||V8||4 Barrel Carburetor |4BBL||OHV||Oldsmobile "Rocket" V8 (307 cu. in.) H.O. '83-'84 Hurst/Olds, '85-'87 Oldsmobile Cutlass 442
|-
|9||LM9||3.8 L||V6|V6 Turbo||Fuel injection#Sequential multi-port injection|SFI||OHV||Buick V6. '84-'85 Buick Regal, Riviera.
|-
|9||L44||2.8 L||V6||Fuel injection#Multi-port fuel injection|MFI||OHV||Chevrolet 60° V6 (transversely mounted). H.O. '85-'88 Pontiac Fiero
|-
|9||LC0||1.5 L||I4 Turbo||Fuel injection#Multi-port fuel injection|MFI||SOHC,<br /> 8 valve||Isuzu 4XC1-T engine. '87-'88 Chevrolet Spectrum Turbo
|-
|9||LK0||1.9 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||Saturn I4 engine. '91-'94 Saturn S-Series
|-
|9||L37||4.6 L||V8||Fuel injection#Sequential Multi-port injection|SFI||DOHC,<br /> 32 valve||Cadillac Northstar V8 (H.O. FWD) (Premium V). '93 Cadillac Allanté,<br /> '93-'02 Cadillac Eldorado Touring Coupe, '93-'04 Cadillac Seville STS, '96-'05 Cadillac DeVille,<br /> '06-'11 Cadillac DTS, '08-'11 Buick Lucerne Super
|-
|9||L72||1.3 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve ||Suzuki G13BA engine. '95-'97 Geo Metro
|-
|9||LUJ||1.4L||I4 Turbo||Fuel injection#Sequential Multi-port fuel injection|SFI||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. VVT. Early production engines were made in Aspern, Austria; later made in Flint, MI. '11 Chevy Cruze
|-
|9||LL0||1.2 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||Daewoo S-TEC II engine (1249 cc). VVT. Made in Changwon, S. Korea. '13-'15 Chevy Spark.
|-
|9||LT5||6.2 L||V8 Supercharged||Port/Direct injection||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. VVT. '19 Corvette ZR1.
|-
|0||LH8||1.8 L||Straight-4|I4||Fuel injection#Throttle Body injection|TBI||SOHC,<br /> 8 valve||GM Family II engine. Made in Brazil.<br /> '82-'86 Pontiac J2000/2000/Sunbird, Oldsmobile Firenza, Buick Skyhawk.
|-
|0||LAX||2.4 L||Straight-4|I4||Fuel injection#Sequential multi-port injection|SFI||DOHC,<br /> 16 valve||Toyota 2AZ-FE engine. VVT-i. '09-'10 Pontiac Vibe
|-
|0||LE9||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. E85 Flex-Fuel. 2010 Chevy Malibu.
|-
|0||LE5||2.4 L||Straight-4|I4||Fuel injection#Multi-port fuel injection|MFI||DOHC,<br /> 16 valve||GM Ecotec Gen II. VVT. Most '12 Chevy Malibu w/LE5 engine.
|}
H.O.=High Output, CNG=Compressed Natural Gas, VVT=Variable Valve Timing, VVL=Variable Valve Lift
====Motor codes for electric passenger cars====
{| class="wikitable"
|-
! VIN !! RPO !! Fuel !! Drive Wheels !! Application/Notes
|-
| 5 ||LN1|| Electricity || Front || '97, '99 General Motors EV1
|-
| 0 ||EN0|| Electricity || Front || '14-'16 Chevrolet Spark EV
|-
| 0 ||EN0|| Electricity || Front || '17-'23 Chevrolet Bolt EV
|-
| 0 ||EN0|| Electricity || Front || '22-'23 Chevrolet Bolt EUV
|-
|}
====Motor codes for LFP-powered electric passenger cars====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Pack <br /> RPO code !! Fuel !! Drive Wheels !! Application/Notes
|-
|-
| V ||P9D (HPB)|| 1 || EJW || Electricity || Front || '27 Chevrolet Bolt
|}
LFP=Lithium Iron Phosphate
====Motor codes for Ultium-powered electric passenger cars====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Module <br /> RPO code !! # of Modules !! Fuel !! Drive Wheels !! Application/Notes
|-
|-
| 1 ||X0E|| 2 || EXN || 16 || Electricity || All || '25- Cadillac Celestiq
|-
| 2 ||X0E|| 2 || EHT || 16 || Electricity || All || '25- Cadillac Celestiq <br> (Battery Module RPO code EHT is Configuration B)
|}
====Engine codes for light trucks====
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes/Applications
|-
| A ||LD5|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Buick V6. (231 cu. in.) '81-'84 Chevy El Camino, GMC Caballero (CA emissions).
|-
| A ||LR1|| 1.9L || I4 || Gas ||SOHC,<br /> 8 valve||2-bbl carb. Isuzu G200 engine imported from Japan.<br /> '82-'85 Chevy S-10/GMC S-15, '83-'85 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| A ||L38|| 2.5L || I4 || Gas ||OHV||TBI. Pontiac Iron Duke/Tech IV engine. '91-'93 Chevy S-10/GMC Sonoma.
|-
| A ||LH2|| 4.6L || V8 || Gas ||DOHC,<br /> 32 valve||SFI. Cadillac Northstar V8 (For RWD) (Premium V). '04-'09 Cadillac SRX
|-
| A ||L20|| 4.8L || V8 || Gas/E85 ||OHV|| Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads. VVT.<br /> '10-'13 GMT900 pickups, '10-'14 Express/Savana
|-
| A ||LCV|| 2.5L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. VVT. '15-'22 Chevy Colorado, GMC Canyon,<br /> '17-'20 Buick Envision, '17-'21 GMC Acadia, '19-'21 Chevy Blazer
|-
| B ||LR2|| 2.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 60° V6.<br /> '82-'85 Chevy S-10/GMC S-15, '83-'85 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| B ||LU2|| 4.3L || V6 || Gas ||OHV|| TBI. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '90-'91 Astro/Safari higher output engine option.
|-
| B ||L81|| 3.0L || V6 || Gas ||DOHC,<br /> 24 valve||SFI. Opel 54° V6 engine (Made in the UK). '02-'03 Saturn Vue
|-
| B ||L33|| 5.3L || V8 || Gas ||OHV||SFI. Gen III Chevrolet Small-Block V8. Vortec 5300 H.O. 310hp. Aluminum Block & Heads.<br /> '05-'06 Silverado/Sierra 1500 4wd ext. cab short bed,<br> '07 Silverado Classic 1500/Sierra Classic 1500 4wd ext. cab short bed.
|-
| B ||LE8|| 2.2L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. SFI. GM Ecotec Gen II. VVT. '09-'10 Chevy HHR
|-
| B ||LC8|| 6.0L || V8 || Gas/CNG ||OHV||Bi-Fuel (Also Gas/LPG in Express/Savana). SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT. '11-'20 Express/Savana, '13-'19 Silverado HD/Sierra HD.
|-
| B ||LUV|| 1.4L ||I4 Turbo|| Gas ||DOHC,<br /> 16 valve||GM Family 0 Engine, Gen III. SFI. VVT.<br /> '13-'21 Buick Encore, '15-'21 Chevy Trax (also '13-'14 Trax in Canada)
|-
| C ||LH6|| 6.2L || V8 || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR trucks '82-'93. '82-'86 C/K pickups, '87 R/V pickups,<br /> '88-'93 C/K, Sierra pickups, '82-'91 Blazer/Jimmy, Suburban, '83-'93 full-size vans
|-
| C ||L34|| 2.0L || I4 || Gas ||DOHC,<br /> 16 valve||Suzuki J20A engine. MFI. '99-'03 Chevrolet Tracker
|-
| C ||LY2|| 4.8L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads.<br /> '07-'09 GMT900 pickups, '07-'09 Tahoe/Yukon, '08-'09 Express/Savana
|-
| C ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '11.
|-
| C ||L83|| 5.3L || V8 || Gas/E85 ||OHV|| Flex Fuel. Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management<br /> '14-'19 K2XX pickups, '15-'20 K2XX SUVs.
|-
| C ||L2R|| 2.7L ||I4 Turbo||| Gas ||DOHC,<br /> 16 valve||GM L3B Tripower engine ("TurboMax") - Detuned version. Direct Injection. VVT, VVL. Active Fuel Management. '23-'24 Chevy Colorado.
|-
| D ||LE3|| 4.1L || I6 || Gas ||OHV||2-bbl carb. Chevrolet Turbo-Thrift I6.<br /> '81-'84 Chevy/GMC C/K pickups, full-size vans, '81-'82 Blazer/Jimmy
|-
| D ||LG6|| 3.1L || V6 || Gas ||OHV||TBI. Chevrolet 60° V6. '90-'95 U-body minivans.
|-
| D ||L61|| 2.2L || I4 || Gas ||DOHC,<br /> 16 valve||SFI. GM Ecotec Gen I. '02-'07 Saturn Vue, '06 Chevy HHR.
|-
| D ||L61|| 2.2L || I4 || Gas ||DOHC,<br /> 16 valve||SFI. GM Ecotec Gen II. '07-'08 Chevy HHR.
|-
| D ||LLT|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. '09-'16 GMC Acadia, '17 GMC Acadia Limited,<br /> '09-'17 Chevrolet Traverse, Buick Enclave, '09-'10 Saturn Outlook
|-
| D ||LBZ|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine.<br /> Mid '06 Silverado HD/Sierra HD & '07 Silverado Classic HD/Sierra Classic HD
|-
| D ||L84|| 5.3L || V8 || Gas/E85 ||OHV|| Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. With Dynamic Fuel Management<br /> '19+ Chevy/GMC Silverado 1500/Sierra 1500, '21+ Tahoe/Yukon, Suburban/Yukon XL.
|-
| E ||LN8|| 2.5L || I4 || Gas ||OHV||TBI. Pontiac Iron Duke/Tech IV engine.<br /> '85-'90 Chevy/GMC S-10/S-15, Astro/Safari Cargo Van, '85-'88 S-10 Blazer/S-15 Jimmy.
|-
| E ||LLR|| 3.7L || I5 || Gas ||DOHC,<br /> 20 valve||Atlas I5. SFI. VVT.<br /> '07-'12 Colorado/Canyon, '07-'08 Isuzu i-370, '07-'10 Hummer H3, '09-'10 Hummer H3T
|-
| E ||LA1|| 3.4L || V6 || Gas ||OHV||Chevrolet 60° V6. '96 GMT199 (U-body) minivans, '97-'05 GMT200 (U-body) minivans,<br /> '01-'05 Pontiac Aztek, '02-'05 Buick Rendezvous
|-
| F ||LF3|| 5.0L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. '81-'86 C/K, full-size vans, '81-'82 Blazer/Jimmy.<br /> CA emissions version of LE9 5.0 V8.
|-
| F ||L65|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks '92-'02,<br /> Chevy/GMC Suburban 1500/2500 '94-'99, over-8,500 lb. GVWR Express/Savana '96-'02
|-
| F ||LNJ|| 3.4L || V6 || Gas ||OHV||Chevrolet 60° V6. Made in China by SAIC-GM. '05-'09 Chevy Equinox, '06-'09 Pontiac Torrent.
|-
| F ||L94|| 6.2L || V8 || Gas/E85 ||OHV||Flex-Fuel. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT. Active Fuel Management. '10-'14 GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV.
|-
| F ||L20|| 4.8L || V8 || Gas/E85 ||OHV|| Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block/Aluminum Heads. VVT.<br /> '15-'17 Express/Savana
|-
| F ||L82|| 5.3L || V8 || Gas ||OHV|| Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. With Active Fuel Management<br /> '19-'21 Chevy Silverado 1500, GMC Sierra 1500 (T1XX).
|-
| G ||LG9|| 5.0L || V8 || Gas ||OHV|| 2-bbl carb. Gen I Chevrolet Small-Block V8. '81 Chevy/GMC C/K pickups, Blazer/Jimmy, full-size van
|-
| G ||L18|| 8.1L || V8 || Gas ||OHV||MFI. Vortec 8100. Gen VII Chevrolet Big-Block V8. '01-'02 C3500HD, '01-'06 Silverado HD/Sierra HD, '07 Silverado Classic HD/Sierra Classic HD, '01-'06 Suburban/Yukon XL 2500, '02-'06 Avalanche 2500, '01-'02 Express/Savana
|-
| G ||L96|| 6.0L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '10-'19 Silverado HD/Sierra HD, '10-'13 Suburban 2500/Yukon XL 2500, '16-'19 Suburban 3500,<br /> '10-'20 Express/Savana.
|-
| G ||LSD|| 1.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '23+ Chevy Equinox, GMC Terrain
|-
| H ||LG4|| 5.0L || V8 || Gas ||OHV||4-bbl carb. Gen I Chevy Small-Block V8. (305 cu. in.) '81-'87 Chevy El Camino, GMC Caballero.
|-
| H ||LE9|| 5.0L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. '81-'86 C/K pickups, Blazer/Jimmy, Suburban, full-size vans
|-
| H ||L03|| 5.0L || V8 || Gas ||OHV|| TBI. Gen I Chevrolet Small-Block V8. '87 R/V pickups, '88-'95 C/K, Sierra pickups, '87-'95 full-size vans, '87 Blazer/Jimmy, Suburban.
|-
| H ||LN2|| 2.2L || I4 || Gas ||OHV||SFI. Chevrolet "122" engine. '03 Chevy S-10/GMC Sonoma
|-
| H ||LS2|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevy Small-Block V8. Chevy SSR '05-'06, Trailblazer SS '06-'09, Saab 9-7X Aero '08-'09.
|-
| H ||LV3|| 4.3L || V6 || Gas/E85 ||OHV||Flex Fuel. Chevrolet 90° V6 - Gen V Chevrolet Small-Block V6 (EcoTec3). Direct injection, VVT. Active Fuel Management. '14-'21 Chevy Silverado 1500/GMC Sierra 1500.
|-
| J ||L39|| 4.4L || V8 || Gas ||OHV||2-bbl carb. Gen I Chevy Small-Block V8 (267 cu. in.) '81-82 Chevy El Camino, GMC Caballero.
|-
| J ||LL4|| 6.2L || V8 || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR trucks '82-'93. '82-'86 C/K pickups, '87-'91 R/V pickups,<br /> '88-'93 C/K, Sierra pickups, '82-'91 Blazer/Jimmy, Suburban, '83-'93 full-size vans
|-
| J ||L29|| 7.4L || V8 || Gas ||OHV|| MFI. Vortec 7400. Gen VI Chevrolet Big-Block V8.<br /> '96-'00 C/K, Sierra pickups, Express/Savana, '96-'99 Suburban 2500
|-
| J ||LY5|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. Iron Block & Aluminum Heads.<br /> '07-'09 Silverado/Sierra 1500, Tahoe/Yukon, Suburban/Yukon XL 1500, Avalanche
|-
| J ||LZ1|| 6.0L || V8 || Gas-Electric Hybrid ||OHV||2-Mode Hybrid. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT. Active Fuel Management. '10-'13 Tahoe Hybrid, Yukon Hybrid, Escalade Hybrid, Silverado Hybrid, Sierra Hybrid
|-
| J ||L86|| 6.2L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management. <br /> '14-18 Chevy/GMC Silverado 1500/Sierra 1500,<br /> '18-20 Chevy Tahoe Premier, '19-'20 Chevy Suburban Premier, GMC Yukon/Yukon XL SLT,<br /> '15-'20 GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV.
|-
| K ||LC3|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '81-'82 Chevy El Camino, GMC Caballero (49-state emissions)
|-
| K ||L05|| 5.7L || V8 || Gas ||OHV|| TBI. Gen I Chevrolet Small-Block V8. '87 R/V pickups, '88-'95 C/K, Sierra pickups, '87-'95 full-size vans, '96 G-Classic full-size vans, '87-'94 Blazer, '95 Tahoe, '87-'91 Jimmy, '92-'95 Yukon, '87-'95 Suburban.
|-
| K ||LY6|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '07-'09 Silverado HD/Sierra HD, '07-'09 Suburban 2500/Yukon XL 2500, '08-'09 Express/Savana
|-
| K ||LEA|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex Fuel. GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '12-'17,<br /> Chevy Captiva Sport '12-'14, Chevy Orlando '14.
|-
| K ||L3B|| 2.7L ||I4 Turbo||| Gas ||DOHC,<br /> 16 valve||GM L3B Tripower engine ("TurboMax"). Direct Injection. VVT, VVL. Active Fuel Management.<br /> '19+ Chevy Silverado 1500, GMC Sierra 1500, '23+ Chevy Colorado, GMC Canyon.
|-
| L ||LS9|| 5.7L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevrolet Small-Block V8. For sub-8,500 lb. GVWR trucks, vans, Suburban, Blazer/Jimmy (CA) '81-'86.
|-
| L ||L27|| 3.8L || V6 || Gas ||OHV||Buick V6 (3800 Series I). '92-'95 U-body minivans
|-
| L ||LX9|| 3.5L || V6 || Gas ||OHV||GM High Value 60° V6. 3498cc. SFI. '05-'06 GMT201 minivans, '06-'07 Buick Rendezvous
|-
| L ||LH8|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads.<br /> '08-'09 Hummer H3 Alpha, '09 Colorado/Canyon, Hummer H3T Alpha
|-
| L ||LGH|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. Mid '10-'16 Express/Savana, '11-'12 Silverado HD/Sierra HD chassis cabs
|-
| L ||L87|| 6.2L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Dynamic Fuel Management.<br /> '19+ Chevy/GMC Silverado 1500/Sierra 1500, '21+ Tahoe/Yukon, Suburban/Yukon XL,<br /> Cadillac Escalade/Escalade ESV.
|-
| L ||L3T|| 1.3L || I3 Turbo || Gas ||DOHC,<br /> 12 valve||GM E-Turbo Engine. Direct Injection. VVT. '20+ Buick Encore GX, '21+ Chevy Trailblazer.
|-
| M ||LT9|| 5.7L || V8 || Gas ||OHV|| 4-bbl carb. Gen I Chevy Small-Block V8.<br /> For over-8,500 lb. GVWR C/K trucks, full-size vans, Suburban '81-'86, full-size van cutaway '81-'88.<br /> '88 Chevy/GMC R30/3500 Chassis Cab w/C7C (10,500 lb. GVWR),<br /> V30/3500 Chassis Cab w/C7E (11,000 lb. GVWR)
|-
| M ||L30|| 5.0L || V8 || Gas ||OHV||Gen 1+ Chevrolet Small-Block V8. Vortec 5000. CPI.<br /> '96-'99 Chevy C/K, GMC Sierra, '96-'02 Express/Savana
|-
| M ||LNF|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. 2010 Chevy HHR SS.
|-
| M ||LH6|| 5.3L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. Aluminum Block & Heads.<br /> '05-'06 GMT370 SUVs (Trailblazer EXT/Envoy XL/Isuzu Ascender 7-psgr.), '05-'07 Buick Rainier,<br /> '05-'09 GMC Envoy Denali, Saab 9-7X, '06-'08 Chevy Trailblazer, '05 GMC Envoy XUV,<br /> '07-'09 Silverado/Sierra 1500
|-
| M ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Orlando '12.
|-
| M ||LE2|| 1.4L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '16-'19 & '21-'22 Buick Encore, '21-'22 Chevy Trax.
|-
| N ||L10|| 1.8L || I4 || Gas ||SOHC,<br /> 8 valve||2-bbl carb. Isuzu G180Z engine imported from Japan. '81-'82 Chevy LUV
|-
| N ||LF9|| 5.7L || V8 || Diesel ||OHV||Oldsmobile Diesel V8. '83-'84 Chevy El Camino/GMC Caballero.
|-
| N ||LB1|| 4.3L || V6 || Gas ||OHV|| 4-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '85 Astro/Safari, '85-'86 C/K pickups & full-size vans
|-
| N ||L19|| 7.4L || V8 || Gas ||OHV|| Mark IV Chevrolet Big-Block V8. TBI.<br /> '87-'90 R/V pickups, Suburban 2500, '88-'90 C/K, Sierra pickups, full-size vans
|-
| N ||L19|| 7.4L || V8 || Gas ||OHV|| Gen V Chevrolet Big-Block V8. TBI.<br /> '91 R/V pickups, '91-'95 C/K, Sierra pickups, Suburban 2500, full-size vans. '96 G-Classic full-size vans
|-
| N ||LZ4|| 3.5L || V6 || Gas ||OHV||GM High Value 60° V6. 3510cc. SFI. VVT. '08-'09 Saturn Vue
|-
| N ||LQ9|| 6.0L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Vortec 6000 H.O. or VortecMAX. Iron Block/Aluminum Heads.<br /> 345 hp. '02-'06 Cadillac Escalade, '03-'06 Cadillac Escalade ESV, '03-'06 Chevy Silverado SS,<br /> '05-'06 GMC Sierra Denali, '07 GMC Sierra Classic Denali.
|-
| N ||LGZ|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. Direct Injection. VVT. Active Fuel Management.<br /> '17-'22 Chevy Colorado, GMC Canyon.
|-
| P ||L49|| 6.5L || V8 || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks & full-size vans '94-'95
|-
| P ||LM4|| 5.3L || V8 || Gas ||OHV||Gen III Chevrolet Small-Block V8. Vortec 5300. 290hp. Aluminum Block & Heads.<br /> '03-'04 Chevy SSR, '03-'04 GMT370 SUVs (Trailblazer EXT/Envoy XL/Isuzu Ascender 7-psgr.),<br /> '04 Buick Rainier, GMC Envoy XUV
|-
| P ||LE5|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||MFI. GM Ecotec Gen II. VVT. '06-'08 Chevy HHR, '08-'09 Saturn Vue
|-
| P ||LH9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT.<br /> '10-'12 Colorado/Canyon, '10 Hummer H3 Alpha, H3T Alpha
|-
| P ||LV1|| 4.3L || V6 || Gas ||OHV||Chevrolet 90° V6 - Gen V Chevrolet Small-Block V6 (EcoTec3). Direct injection, VVT.<br /> '18+ Chevy Express/GMC Savana.
|-
| P ||LBP|| 1.2L || I3 Turbo || Gas/E85 ||DOHC,<br /> 12 valve||Flex Fuel. GM E-Turbo Engine. Direct Injection. VVT.<br /> '25+ Buick Encore GX, Chevy Trailblazer, '25- Chevy Trax, Buick Envista.
|-
| R ||LL2|| 2.8L || V6 || Gas ||OHV||TBI. Chevrolet 60° V6. '86-'93 Chevy S-10, GMC S-15/Sonoma,<br /> '86-'89 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| R ||L31|| 5.7L || V8 || Gas ||OHV||Gen 1+ Chevrolet Small-Block V8. Vortec 5700. CPI.<br /> '96-'99 Chevy C/K, GMC Sierra, '96-'99 Chevy Tahoe/GMC Yukon, Chevy/GMC Suburban, '99-'00 GMC Yukon Denali, Cadillac Escalade, '00 Chevy Tahoe Limited/Z71, '96-'02 Chevy Express/GMC Savana.
|-
| R ||L8B|| 5.3L || V8 || Gas ||OHV||Mild Hybrid. Gen V Chevrolet Small-Block V8 (EcoTec3). Direct injection, VVT. Active Fuel Management. '16-'18 Chevy Silverado 1500, GMC Sierra 1500.
|-
| S ||LQ7|| 2.2L || I4 || Diesel ||OHV||Isuzu C220 engine imported from Japan. '81-'82 Chevy LUV, '84-'85 Chevy S-10/GMC S-15
|-
| S ||L56|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8. For sub-8,500 lb. GVWR Chevy C/K, GMC Sierra trucks '94-'99,<br /> Chevy Blazer '94, Chevy Tahoe 2-d '95-'99, GMC Yukon 2-d '94-'97
|-
| S ||LL8|| 4.2L || I6 || Gas ||DOHC,<br /> 24 valve||Atlas I6. SFI. VVT. '02-'09 GMT360/370 SUVs (Chevy Trailblazer, GMC Envoy, Oldsmobile Bravada, Buick Rainier, Isuzu Ascender, Saab 9-7X)
|-
| S ||LGX|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6, 4th gen. Direct Injection. VVT. Active Fuel Management.<br /> '17+ Cadillac XT5, '17-'23 GMC Acadia, '19+ Chevrolet Blazer, '20-'25 Cadillac XT6.
|-
| S ||LK0|| 2.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||L3B engine family. Direct Injection. VVT. '24- Chevy Traverse, GMC Acadia, '25- Buick Enclave
|-
| T ||L25|| 4.8L || I6 || Gas ||OHV||1-bbl carb. Chevrolet Turbo-Thrift I6. '81-'86 Chevy/GMC C/K pickups, '88 R/V pickups
|-
| T ||LM7|| 5.3L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads. Vortec 5300. 270/285/295hp.<br /> '99-'07 GMT800 pickups & SUVs including '02-'05 Escalade 2wd, '07 Silverado Classic 1500/<br> Sierra Classic 1500, '03-'07 Express/Savana
|-
| T ||LEA|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex Fuel. GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Orlando '13.
|-
| T ||LM2|| 3.0L || I6 Turbo|| Diesel ||DOHC,<br /> 24 valve|| Duramax Diesel I6. Aluminum Block & Heads. '20-'22 Silverado/Sierra 1500, '21-'24 Tahoe/Suburban, Yukon/Yukon XL, Escalade/Escalade ESV.
|-
| U ||LS5|| 1.6L || I4 || Gas ||SOHC,<br /> 8 valve||Suzuki G16A engine. TBI. '89-'95 Geo Tracker
|-
| U ||LQ4|| 6.0L || V8 || Gas ||OHV|| Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads (Iron Heads in '99-'00).<br /> '99-'06 GMT800 pickups, '07 Silverado Classic 1500HD/Sierra Classic 1500HD,<br> '00-'06 Suburban/Yukon XL 2500, '01-'06 Yukon Denali/Yukon XL Denali,<br> '06 Suburban LTZ, '03-'07 Express/Savana, '03-'07 Hummer H2.
|-
| U ||LE9|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. GM Ecotec Gen II. 2011 Chevy HHR
|-
| U ||LH7|| 1.6L ||I4 Turbo|| Diesel ||DOHC,<br /> 16 valve||GM Medium Diesel engine ("Whisper Diesel"). Made by Opel in Szentgotthárd, Hungary.<br /> Aluminum Block & Heads. '18-'19 Chevy Equinox & GMC Terrain Diesel.
|-
| V ||LR4|| 4.8L || V8 || Gas ||OHV||Gen III Chevrolet Small-Block V8. Iron Block/Aluminum Heads.<br> '99-'06 GMT800 pickups, '07 Silverado Classic 1500/Sierra Classic 1500,<br /> '00-'06 Tahoe/Yukon, '03-'07 Express/Savana
|-
| V ||LE9|| 2.4L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. GM Ecotec Gen II. 2009-2010 Chevy HHR
|-
| V ||LYX|| 1.5L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Small Gasoline Engine. Direct Injection. VVT. '18-'22 Chevy Equinox, GMC Terrain
|-
| W ||LE8|| 7.4L || V8 || Gas ||OHV|| Mark IV Chevrolet Big-Block V8. 4bbl carb. '81-'86 Chevy/GMC C/K pickups, Suburban.<br /> '88-'89 Chevy/GMC R30/3500 Chassis Cab w/C7C (10,500 lb. GVWR),<br /> V30/3500 Chassis Cab w/C7E (11,000 lb. GVWR)
|-
| W ||L35|| 4.3L || V6 || Gas ||OHV|| CPI. Vortec 4300 H.O. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '92-'95 Sonoma, S-10 Blazer/Jimmy, Astro/Safari, '94-'95 S-10, '92-'94 Oldsmobile Bravada
|-
| W ||L35|| 4.3L || V6 || Gas ||OHV|| SFI. Vortec 4300 H.O. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '96-'02 S-10/Sonoma, Blazer/Jimmy, Express/Savana, C/K, Silverado, Sierra, '96-'01 Bravada, Astro/Safari, '00 Isuzu Hombre
|-
| W ||LGD|| 3.9L || V6 || Gas/E85 ||OHV||Flex Fuel. GM High Value 60° V6. SFI. VVT. '07-'09 GMT201 minivans
|-
| W ||LAF|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. Chevy Equinox, GMC Terrain '10.
|-
| W ||LE8|| 2.2L || I4 || Gas/E85 ||DOHC,<br /> 16 valve||Flex-Fuel. SFI. GM Ecotec Gen II. VVT. 2011 Chevy HHR.
|-
| W ||LFY|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection.<br> '18-'23 Chevrolet Traverse, '24 Chevrolet Traverse Limited, '18-'24 Buick Enclave.
|-
| X ||LF6|| 4.3L || V6 || Gas ||OHV||SFI. Vortec 4300. Chevrolet 90° V6 (Chevy Small-Block V8 Derived).<br /> '96-'99 S-10/Sonoma, '97-'99 Isuzu Hombre.
|-
| X ||LU3|| 4.3L || V6 || Gas ||OHV||Vortec 4300. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '03-'04 S-10/Sonoma,<br /> '03-'05 Blazer/Jimmy, '02-'05 Astro/Safari, '03-'14 Express/Savana, '03-'13 Silverado/Sierra,<br> '07 Silverado Classic 1500/Sierra Classic 1500
|-
| X ||LNF|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen II. Direct Injection. VVT. '08-'09 Chevy HHR SS.
|-
| X ||LTG|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. VVT.<br /> '16-'20 Buick Envision, '18-'20 Chevy Equinox, GMC Terrain, '18-'19 Chevy Traverse RS
|-
| Y ||LQ2|| 2.0L || I4 || Gas ||OHV||2-bbl carb. Chevrolet "122" engine.<br /> '83-'84 Chevy S-10/GMC S-15, '83-'84 Chevy S-10 Blazer/GMC S-15 Jimmy
|-
| Y ||L57|| 6.5L || V8 || Diesel ||OHV||Detroit Diesel V8. For over-8,500 lb. GVWR full-size vans '94-'95 & '96 G-Classic full-size vans
|-
| Y ||L76|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevy Small-Block V8. Aluminum Block & Heads. VVT. With Active Fuel Management.<br /> '07-'09 Silverado/Sierra, Suburban/Yukon XL, Chevy Avalanche
|-
| Y ||LF1|| 3.0L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. VVT.<br /> '10-'11 Cadillac SRX, '11 Saab 9-4X, '10 Chevy Equinox, GMC Terrain
|-
| Y ||L5P|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '17+ Silverado HD/Sierra HD. Engine updated in '24.
|-
| Z ||LF9|| 5.7L || V8 || Diesel ||OHV||Oldsmobile Diesel V8. '81 Chevy C10/GMC C1500 full-size pickups.
|-
| Z ||LB4|| 4.3L || V6 || Gas ||OHV|| TBI. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). '85-'87 Chevy El Camino/GMC Caballero,<br /> '86-'94 Astro/Safari, '87 R/V pickups, '88-'95 C/K & Sierra pickups, '87-'95 full-size vans & <br /> '96 G-Classic full-size vans, '88-'95 S-10, S-15/Sonoma, '88-'94 S-10 Blazer, S-15 Jimmy,<br /> '91-'92 Oldsmobile Bravada
|-
| Z ||LB4|| 4.3L || V6 Turbo || Gas ||OHV|| MPI. For GMC Syclone & Typhoon. Chevrolet 90° V6 (Chevy Small-Block V8 Derived)
|-
| Z ||L59|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. Gen III Chevrolet Small-Block V8. Iron Block & Aluminum Heads. Vortec 5300. 285/295hp.<br /> '02-'07 GMT800 pickups, '07 Silverado Classic 1500/Sierra Classic 1500,<br> '02-'06 Suburban/Yukon XL, Avalanche.
|-
| Z ||LAT|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||Mild Hybrid. MFI. GM Ecotec Gen II. VVT. '07-'09 Saturn Vue Green Line
|-
| 1 ||LZ9|| 3.9L || V6 || Gas ||OHV||GM High Value 60° V6. SFI. VVT. '06-'09 GMT201 minivans
|-
| 1 ||LE5|| 2.4L || I4 || Gas ||DOHC,<br /> 16 valve||MFI. GM Ecotec Gen II. VVT. '10 Saturn Vue.
|-
| 1 ||LB7|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. First version of the Duramax V8. '01-Mid '04 Silverado HD/Sierra HD
|-
| 1 ||LWN|| 2.8L || I4 Turbo || Diesel ||DOHC,<br /> 16 valve||Based on VM Motori A428 engine. Made by GM Powertrain Thailand 2016-2020. Made in Brazil for '22. '16-'22 Colorado/Canyon, '17-'22 Express/Savana.
|-
| 2 ||LLY|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. Mid '04-Mid '06 Silverado HD/Sierra HD, '06-Mid '07 Express/Savana
|-
| 2 ||L9H|| 6.2L || V8 || Gas/E85 ||OHV||Flex-Fuel. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT.<br /> '09-'13 Chevy Silverado 1500, GMC Sierra 1500, Sierra Denali 1500,<br /> '09 Chevy Tahoe LTZ, GMC Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV,<br> Hummer H2
|-
| 2 ||LIH|| 1.2L || I3 Turbo || Gas ||DOHC,<br /> 12 valve||GM E-Turbo Engine. Direct Injection. VVT.<br /> '20-'24 Buick Encore GX, '21-'24 Chevy Trailblazer, '24 Chevy Trax, Buick Envista,<br> '25 Chevy Trax, Buick Envista (Canada only).
|-
| 3 ||LC9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT added for '10. Aluminum Block & Heads.<br /> '07-'11 Silverado/Sierra 1500, Tahoe/Yukon, Suburban/Yukon XL 1500, '07-'09 & '11 Avalanche
|-
| 3 ||LFX|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. Direct Injection. VVT. E85 Flex Fuel.<br /> '12-'16 Cadillac SRX, '13-'17 Chevrolet Equinox, GMC Terrain, '15-'16 Colorado/Canyon
|-
| 4 ||LN2|| 2.2L || I4 || Gas ||OHV||MFI (94-95). SFI (96-00). Chevrolet "122" engine. '94-'00 S-10/Sonoma, '96-'00 Isuzu Hombre
|-
| 4 ||LE8|| 2.5L || V6 || Gas ||DOHC,<br /> 24 valve||Suzuki H25A engine. MFI. '01-'04 Chevrolet Tracker
|-
| 4 ||L66|| 3.5L || V6 || Gas ||SOHC,<br /> 24 valve||Honda J35S1 V6. VTEC. '04-'07 Saturn Vue
|-
| 4 ||LMF|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '08-'14 Express/Savana 1500
|-
| 4 ||LAU|| 2.8L || V6 Turbo || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. SFI. '10 Cadillac SRX
|-
| 4 ||LSY|| 2.0L || I4 Turbo || Gas ||DOHC,<br /> 16 valve||GM Ecotec engine, Gen III. Direct Injection. Active Fuel Management. VVT. VVL.<br /> '19-'25 Cadillac XT4, '20+ Chevy Blazer, Cadillac XT5, '20-'23 GMC Acadia,<br /> '21+ Buick Envision, '21-'25 Cadillac XT6
|-
| 5 ||L43|| 2.2L || I4 || Gas/E85 ||OHV||Flex-Fuel. SFI. Chevrolet "122" engine. '00-'02 S-10/Sonoma, '00 Isuzu Hombre
|-
| 5 ||LFA|| 6.0L || V8 || Gas-Electric Hybrid ||OHV||2-Mode Hybrid. Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. VVT. Active Fuel Management. '08-'09 Tahoe Hybrid/Yukon Hybrid, '09 Escalade Hybrid, Silverado Hybrid/Sierra Hybrid
|-
| 5 ||LFW|| 3.0L || V6 || Gas/E85 ||DOHC,<br /> 24 valve||Flex-Fuel. GM High Feature V6. Direct Injection. VVT. '11-'12 Chevy Equinox, GMC Terrain,<br /> '12 Chevy Captiva Sport
|-
| 6 ||L01|| 1.6L || I4 || Gas ||SOHC,<br /> 16 valve||Suzuki G16B engine. MFI. '94-'97 Geo Tracker, '98-'00 Chevrolet Tracker
|-
| 6 ||L52|| 3.5L || I5 || Gas ||DOHC,<br /> 20 valve||Atlas I5. SFI. VVT. '04-'06 Colorado/Canyon, '06 Isuzu i-350, '06 Hummer H3
|-
| 6 ||LAU|| 2.8L || V6 Turbo || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. SFI. '11 Cadillac SRX, Saab 9-4X
|-
| 6 ||LMM|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '07-'10 Silverado HD/Sierra HD (GMT900), Mid '07-Mid '10 Express/Savana
|-
| 7 ||LY7|| 3.6L || V6 || Gas ||DOHC,<br /> 24 valve||GM High Feature V6. '04-'06 Buick Rendezvous, '04-'09 Cadillac SRX,<br /> '07-'08 GMC Acadia, Saturn Outlook, '08 Buick Enclave, '08-'10 Saturn Vue
|-
| 7 ||LC9|| 5.3L || V8 || Gas/E85 ||OHV||Flex Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT.<br /> Aluminum Block & Heads.<br /> '12-'13 Silverado/Sierra 1500, Avalanche, '12-'14 Tahoe/Yukon, Suburban/Yukon XL 1500
|-
| 7 ||L8T|| 6.6L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8. Iron Block/Aluminum Heads. Direct injection, VVT.<br /> '20+ Silverado HD/Sierra HD, '21+ Express/Savana
|-
| 8 ||LK5|| 2.8L || I4 || Gas ||DOHC,<br /> 16 valve||Atlas I4. SFI. VVT. '04-'06 Colorado/Canyon, '06 Isuzu i-280.
|-
| 8 ||L92|| 6.2L || V8 || Gas ||OHV||Gen IV Chevrolet Small-Block V8. Aluminum Block & Heads. SFI. VVT.<br /> '07-'08 GMC Sierra Denali, Yukon Denali/Yukon XL Denali, Cadillac Escalade/Escalade ESV,<br> '08 Chevy Tahoe LTZ, Hummer H2.
|-
| 8 ||LML|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine.<br /> '11-'16 Silverado HD/Sierra HD pickups, '13-'16 Silverado HD/Sierra HD chassis cabs.
|-
| 8 ||LZ0|| 3.0L || I6 Turbo|| Diesel ||DOHC,<br /> 24 valve|| Duramax Diesel I6. Aluminum Block & Heads.<br> '23+ Silverado/Sierra 1500, '24+ Suburban HD, '25+ Tahoe/Suburban, Yukon/Yukon XL.
|-
| 9 ||LC3|| 3.8L || V6 || Gas ||OHV||2-bbl carb. Chevrolet 90° V6 (Chevy Small-Block V8 Derived). 229 cu. in. <br /> '83-'84 Chevy El Camino, GMC Caballero (49-state emissions).
|-
| 9 ||LLV|| 2.9L || I4 || Gas ||DOHC,<br /> 16 valve||Atlas I4. SFI. VVT. '07-'12 Colorado/Canyon, '07-'08 Isuzu i-290.
|-
| 9 ||LT4|| 6.2L ||V8 Supercharged|| Gas ||OHV||Gen V Chevy Small-Block V8. Aluminum Block & Heads. Direct injection. VVT. Active Fuel Management. '23+ Cadillac Escalade/Escalade ESV V-Series.
|-
| 0 ||LMG|| 5.3L || V8 || Gas/E85 ||OHV||Flex-Fuel. SFI. Gen IV Chevrolet Small-Block V8. Active Fuel Management. VVT added for '10.<br /> Iron Block & Aluminum Heads.<br /> '07-'13 Silverado/Sierra 1500, Avalanche, '07-'14 Tahoe/Yukon, Suburban/Yukon XL 1500.
|}
H.O.=High Output, VVT=Variable Valve Timing, VVL=Variable Valve Lift, GVWR=Gross Vehicle Weight Rating, CNG=Compressed Natural Gas, LPG=Liquefied Petroleum Gas (Propane Autogas)
====Motor codes for electric light trucks====
{| class="wikitable"
|-
! VIN !! RPO !! Fuel !! Drive Wheels !! Application/Notes
|-
| H ||LN1|| Electricity || Front || '97-'98 Chevrolet S-10 Electric.
|-
|}
====Motor codes for Ultium-powered electric light trucks====
{| class="wikitable"
|-
! VIN !! Motor <br /> RPO code !! # of Motors !! Battery Module <br /> RPO code !! # of Modules !! Fuel !! Drive Wheels !! Application/Notes
|-
| A ||XRL|| 3 || ETN || 24 || Electricity || All || '22- GMC Hummer EV pickup 3X
|-
| B ||XRL|| 3 || ETI || 20 || Electricity || All || '24- GMC Hummer EV pickup 3X
|-
| C ||XRL|| 3 || ETJ || 20 || Electricity || All || '24- GMC Hummer EV SUV 3X
|-
| D ||XRJ|| 2 || ETI || 20 || Electricity || All || '24 Chevrolet Silverado EV 3WT, '25- Silverado EV 5WT, 3LT,<br> '25 Silverado EV RST (2SP), '26- Silverado EV Trail Boss (2TR),<br> '24- GMC Hummer EV pickup 2X, '25- GMC Sierra EV Denali 5SC,<br> '26- Sierra EV Elevation 3SC, AT4 4SC
|-
| E ||XRJ|| 2 || ETJ || 20 || Electricity || All || '24- GMC Hummer EV SUV 2X
|-
| G ||XRJ|| 2 || ETJ || 20 || Electricity || All || '23 BrightDrop Zevo 600
|-
| H ||XRJ|| 2 || EWX || 14 || Electricity || All ||'26- Chevrolet Silverado EV 4WT, 2LT,<br> '26- GMC Sierra EV Elevation 3SB, Denali 5SB
|-
| J ||X0C|| 2 || EC5 || 10 || Electricity || All || '24 Chevy Blazer EV 2LT, 1RS AWD,<br> '25- Chevy Blazer EV 4LT, 3RS AWD, '24-'26 Honda Prologue AWD
|-
| K ||X0D|| 1 || EC6 || 12 || Electricity || Rear || '23- Cadillac Lyriq RWD, '24-'25 Chevrolet Blazer EV 2RS RWD,<br> '24 Acura ZDX A-Spec RWD
|-
| L ||X0E|| 2 || EC6 || 12 || Electricity || All || '23- Cadillac Lyriq AWD, '24- Chevrolet Blazer EV PPV AWD,<br> '25- Chevrolet Blazer EV SS AWD, '26- Cadillac Vistiq AWD,<br> '24 Acura ZDX A-Spec, Type S AWD
|-
| L ||XRJ|| 2 || ETN || 24 || Electricity || All || '24 Chevrolet Silverado EV 4WT, RST (3SP), '25- Silverado EV 8WT,<br> '25 Silverado EV RST (3SP), '26- Silverado EV 4LT, Trail Boss (3TR),<br> '24- GMC Sierra EV Denali 5SD, '26- Sierra EV AT4 4SD,<br> '25- Cadillac Escalade IQ, '26- Cadillac Escalade IQL
|-
| M ||X0B|| 1 || EC5 || 10 || Electricity || Front || '24-'26 Honda Prologue FWD, '25- Chevy Blazer EV 2LT, 1RS FWD
|-
| P ||X0B|| 1 || EC3 || 10 || Electricity || Front || '24- Chevrolet Equinox EV FWD
|-
| R ||X0C|| 2 || EC3 || 10 || Electricity || All || '24- Chevrolet Equinox EV AWD, '25 Cadillac Optiq AWD
|-
| Y ||XRJ|| 2 || ETC || 12 || Electricity || All || '24 BrightDrop Zevo 400, Zevo 600,<br> '25-'26 Chevrolet BrightDrop 400/600 AWD
|-
| Z ||XRJ|| 2 || ETJ || 20 || Electricity || All || '24 BrightDrop Zevo 400, Zevo 600,<br> '25-'26 Chevrolet BrightDrop 400/600 AWD
|-
| 4 ||X0E|| 2 || EC3 || 10 || Electricity || All || '26- Cadillac Optiq AWD
|-
| 5 ||X0D|| 1 || EC3 || 10 || Electricity || Rear|| '26- Cadillac Optiq RWD
|-
| 6 ||XRM|| 1 || ETC || 12 || Electricity || Front || '25-'26 Chevrolet BrightDrop 400/600 FWD
|-
| 7 ||XRJ|| 2 || EWU || 14 || Electricity || All || '26 Chevrolet BrightDrop 600 AWD
|}
SB=Standard Range, SC=Extended Range, SD=Max Range
====Engine codes for medium duty trucks 2016-====
GM encodes the engine type in character 8 of the VIN. The following table outlines the various engines encoded there:
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes/Applications
|-
| B ||L96|| 6.0L || V8 || Gas ||OHV||SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '16-'20 Chevy LCF 3500/4500.
|-
| C ||LC8|| 6.0L || V8 || Gas/CNG or<br>Gas/LPG ||OHV||Bi-Fuel. SFI. Gen IV Chevrolet Small-Block V8. Iron Block & Aluminum Heads. VVT.<br /> '16-'20 Chevy LCF 3500/4500.
|-
| D ||L8T|| 6.6L || V8 || Gas ||OHV||Gen V Chevrolet Small-Block V8. Iron Block/Aluminum Heads. Direct injection, VVT.<br /> '21-'23 Chevy LCF 3500/4500, '24- Chevy LCF 3500HG/4500HG/5500HG/5500XG.
|-
| F ||LCB|| 6.7L || I6 Turbo || Diesel ||OHV,<br /> 32 valve||Cummins B Series ISB engine. '22- Chevy LCF 6500XD, '23- Chevy LCF 7500XD.
|-
| 6 ||I1B|| 5.2L || I4 Turbo || Diesel ||SOHC,<br /> 16 valve||Isuzu 4HK1-TC engine. '17- Chevy LCF 4500HD/XD, 5500XD, '17-'24 Chevy LCF 5500HD,<br /> '18-'21 Chevy LCF 6500XD.
|-
| 7 ||IZ3|| 3.0L || I4 Turbo || Diesel ||DOHC,<br /> 16 valve||Isuzu 4JJ1-TC engine. '16-'18 Chevy LCF 3500HD.
|-
|}
====Engine codes for AM General-built Hummer H1 2000-2006====
AM General encodes the engine type in character 4 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| F || || 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8 built by GEP (General Engine Products), a subsidiary of AM General.<br> '01-'04 Hummer H1 & '06 H1 Fleet models.
|-
| P ||LLY|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. '06 Hummer H1 Alpha.
|-
| Z ||L65|| 6.5L || V8 Turbo || Diesel ||OHV||Detroit Diesel V8 built by GM. '00-'01 Hummer H1.
|-
|}
====Engine codes for Nissan-built vans====
Nissan encodes the engine type in character 4 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| 3 ||L0A|| 2.0L || I4 || Gas ||DOHC,<br /> 16 valve||Nissan MR20DE engine. SFI. VVT. For the '15-'18 Chevrolet City Express.
|-
|}
====Engine codes for Navistar-built medium-duty trucks====
Navistar encodes the engine type in character 6 & 7 of the VIN.
{| class="wikitable"
|-
! VIN !! RPO !! Size !! Type !! Fuel !! Valvetrain !! Engine Family/Notes
|-
| PV ||L5D|| 6.6L || V8 Turbo || Diesel ||OHV,<br /> 32 valve||Duramax 6600 V8 engine. For the Chevy Silverado Medium Duty '19+.
|-
|}
==GM factories supplying North America==
===North American GM factories===
[[w:List_of_General_Motors_factories | List of GM Factories]]
{| class="wikitable"
!VIN code
!Location
!Notes
|-
|A
|Lakewood Assembly (Lakewood Heights, Atlanta, Georgia)
|through 1990 model year
|-
|A
|Artisan Center (Warren, Michigan)
|From 2026 model year. Cadillac CT5-V Blackwing "Curated by Cadillac" program only.
|-
|B
|Baltimore Assembly (Baltimore, Maryland)
|through 2005 model year
|-
|B
|Reatta Craft Centre/Lansing Craft Centre (Lansing Township, Michigan)
|1988-2006 model year (except GM EV1)
|-
|B
|GM Defense-Manufacturing Customer Innovation Center (MCIC) (Concord, North Carolina)
|From 2024 model year. Chevrolet Suburban HD (a.k.a. HD SUV) (for US govt. only).
|-
|C
|South Gate Assembly (South Gate, California)
|through 1982 model year
|-
|C
|Lansing Car Assembly (Lansing, Michigan)
|South assembly line 1985-2004 model year
|-
|D
|Doraville Assembly (Doraville, Georgia)
|through 2009 model year
|-
|E
|Linden Assembly (Linden, New Jersey)
|through 1991 model year
|-
|E
|Pontiac East Assembly (Pontiac, Michigan)
|1988-2009 model year
|-
|E
|AM General Military plant (Mishawaka, Indiana)
|1992-2006 Hummer H1
|-
|F
|Flint Truck Assembly (Flint, Michigan)
|since 1953
|-
|F
|Fairfax II Assembly (Kansas City, Kansas)
|since 1988 model year
|-
|G
|Framingham Assembly (Framingham, Massachusetts)
|through 1989 model year
|-
|G
|Silao Assembly (Silao, Guanajuato, Mexico)
|since 1995 model year
|-
|H
|Buick City Assembly (Flint, Michigan)
|through 1999 model year
|-
|H
|AM General Commercial plant (Mishawaka, Indiana)
|2003-2009 Hummer H2
|-
|H
|Navistar Springfield plant (Main Line) (Springfield, Ohio)
|2019- Chevrolet Silverado Medium Duty (4500HD/5500HD/6500HD)
|-
|J
|Janesville Assembly (Janesville, Wisconsin)
|through 2009 model year
|-
|J
|Lansing Delta Township Assembly (Lansing, Michigan)
|since 2007 model year
|-
|K
|Leeds Assembly (Leeds, Kansas City, Missouri)
|through 1988 model year
|-
|K
|Linden Assembly (Linden, New Jersey)
|from 1994-2005 model year
|-
|K
|Nissan plant (Cuernavaca, Morelos, Mexico)
|2015-2018 Chevrolet City Express
|-
|L
|Van Nuys Assembly (Van Nuys, California)
|through 1992 model year
|-
|L
|San Luis Potosí Assembly (San Luis Potosí, Mexico)
|since 2009 model year
|-
|M
|Lansing Car Assembly (Lansing, Michigan)
|through 1984 model year, North assembly line 1985-2005 model year
|-
|M
|Toluca Assembly (Toluca, Mexico state, Mexico)
|through 2008 model year
|-
|N
|Norwood Assembly (Norwood, Ohio)
|through 1987 model year
|-
|N
|Navistar Springfield plant (Secondary Line) (Springfield, Ohio)
|2017- Chevrolet Express cutaway, GMC Savana cutaway
|-
|P
|Pontiac Assembly (Pontiac, Michigan)
|through 1988 model year
|-
|R
|Arlington Assembly (Arlington, Texas)
|since 1965 [all GM brands]. (R plant code used only by Chevrolet in 1963-64)
|-
|S
|St. Louis Assembly (St. Louis, Missouri)
|through 1987 model year
|-
|S
|Spring Hill Manufacturing (Spring Hill, Tennessee)
|2002-2007 Saturn Vue & 2009-2010 Chevrolet Traverse only
|-
|S
|Spartan Motors/Shyft Group plant (Charlotte, Michigan)
|2016- Chevrolet Low Cab Forward 3500/3500HG/4500/4500HG/5500HG/5500XG/6500XD/7500XD
|-
|S
|Ramos Arizpe Assembly (Ramos Arizpe, Coahuila, Mexico)
|since 1982
|-
|T
|Tarrytown Assembly (North Tarrytown, New York)
|through 1996 model year
|-
|U
|Detroit/Hamtramck Assembly (Factory Zero) <br /> (Detroit & Hamtramck, Michigan)
|since 1986 model year
|-
|U
|Artisan Center (Warren, Michigan)
|From 2025 model year. Cadillac Celestiq only.
|-
|V
|Pontiac Central Assembly (Pontiac, Michigan)
|through 1991 model year
|-
|V
|Pontiac East Assembly (Pontiac, Michigan)
|through 1985 model year
|-
|W
|Willow Run Assembly (Ypsilanti Township, Michigan)
|through 1993 model year
|-
|X
|Fairfax Assembly (Fairfax I) (Kansas City, Kansas)
|through 1987 model year
|-
|Y
|Wilmington Assembly (Wilmington, Delaware)
|through 2010 model year
|-
|Z
|Fremont Assembly (Fremont, California)
|through 1982 model year
|-
|Z
|NUMMI (Fremont, California)
|1985-2010 model year
|-
|Z
|Spring Hill Manufacturing (Spring Hill, Tennessee)
|since 1991 model year (except Vue & Traverse)
|-
|Z
|Fort Wayne Assembly (Roanoke, Indiana)
|since 1988 model year
|-
|0
|Pontiac West Assembly (Pontiac, Michigan)
|through 1994 model year
|-
|0
|Lansing Craft Centre (Lansing Township, Michigan)
|GM EV1 only
|-
|0
|Lansing Grand River Assembly (Lansing, Michigan)
|since 2003 model year
|-
|0
|Artisan Center (Warren, Michigan)
|2024 Cadillac CT5-V Blackwing 20th Anniversary Edition where the final eight digits of the VIN are R0912004 through R0912024 or R0962004 through R0962024
|-
|1
|Wentzville Assembly (Wentzville, Missouri)
|since 1985 model year
|-
|1
|Oshawa Car Assembly (Oshawa, Ontario, Canada)
|from 1967-1983 model year
|-
|1
|Oshawa Car Assembly (Line 2 a.k.a. Consolidated Line) (Oshawa, Ontario, Canada)
|from 1984-2019 model year; switched to pickup trucks for 2019 model year
|-
|1
|Oshawa Car Assembly (Oshawa, Ontario, Canada)
|Silverado pickup trucks since 2022 model year
|-
|1
|Oshawa Truck Assembly (Oshawa, Ontario, Canada)
|through 2009 model year
|-
|2
|Moraine Assembly (Moraine, Ohio)
|through 2009 model year
|-
|2
|Sainte-Thérèse Assembly (Boisbriand, Quebec, Canada)
|through 2002 model year
|-
|3
|Detroit Truck & Bus plant (Piquette Ave., Detroit, Michigan)
|through 1999 model year
|-
|3
|Saint-Eustache Bus Plant (Saint-Eustache, Quebec, Canada)
|through 1987 model year
|-
|4
|Orion Assembly (Orion Township, Michigan)
|since 1985 model year
|-
|4
|Scarborough Van Assembly (Scarborough, Ontario, Canada)
|through 1993 model year
|-
|5
|Bowling Green Assembly (Bowling Green, Kentucky)
|since 1981 model year
|-
|6
|Oklahoma City Assembly (Oklahoma City, Oklahoma)
|through 2006 model year
|-
|6
|CAMI plant (Ingersoll, Ontario, Canada)
|1990-2022 model year
|-
|7
|Lordstown Assembly (Warren, Ohio)
|from 1979-2019 model year
|-
|8
|Shreveport Assembly (Shreveport, Louisiana)
|through 2012 model year
|-
|9
|Detroit Assembly (Clark Street, Detroit, Michigan)<br> (Cadillac plant)
|from 1979-1988 model year
|-
|9
|Oshawa Car Assembly (Line 1 a.k.a. Flex Line)<br> (Oshawa, Ontario, Canada)
|from 1984-2020 model year
|-
|9
|KUKA plant (Livonia, Michigan)
|2022 model year only (BrightDrop Zevo 600)
|-
|9
|CAMI plant (Ingersoll, Ontario, Canada)
|2023-2026 model year (BrightDrop Zevo/Chevrolet BrightDrop)
|}
===Non-North American GM factories supplying North America===
{| class="wikitable"
!VIN code
!Location
!Models Sourced
|-
|A
|SAIC-GM plant: Jinqiao, Pudong district, Shanghai, China
|2017-2018 Cadillac CT6 Plug-in Hybrid
|-
|B
|Daewoo/GM Daewoo/GM Korea plant: Bupyeong, South Korea
|1988-1993 Pontiac LeMans, 2004-2011 Chevrolet Aveo, 2005-2010 Pontiac Wave/G3, 2004-2006 Chevrolet <br /> Epica (Canada), 2013-2022 Chevrolet Trax, Buick Encore, 2021- Chevrolet Trailblazer, 2020- Buick Encore GX, 2024- Buick Envista
|-
|C
|GM Daewoo/GM Korea plant: Changwon, South Korea
|2003-2010 Pontiac Matiz/Matiz G2 (Mexico), 2013-2022 Chevrolet Spark, 2024- Chevrolet Trax
|-
|D
|SAIC-GM Dongyue Motors plant: Yantai, Shandong province, China
|2016- Buick Envision, 2019-2023 Chevrolet Aveo (Mexico), 2023- Chevrolet Onix (Mexico)
|-
|G
|Opel plant: Gliwice, Poland
|2016-2019 Buick Cascada
|-
|K
|Suzuki plant: Kosai, Shizuoka prefecture, Japan
|1985-1988 Chevrolet Sprint, 1989-1990 Geo Metro hatchback, 1990-1993 Geo Metro convertible, 1985-1990 Pontiac Firefly (Canada), 1991 & 1994 Pontiac Firefly convertible & sedan (Canada)
|-
|K
|GM Daewoo/GM Korea plant: Kunsan, South Korea
|2004-2007 Chevrolet Optra (Canada), 2012-2014 Chevrolet Orlando (Canada)
|-
|L
|Holden plant: Elizabeth, South Australia, Australia
|2004-2006 Pontiac GTO, 2008-2009 Pontiac G8, 2011-2017 Chevrolet Caprice PPV, 2014-2017 Chevrolet SS
|-
|R
|Opel plant: Rüsselsheim, Germany
|1997-2001 Cadillac Catera
|-
|T
|GM India plant: Talegaon, Maharashtra, India
|2017-2021 Chevrolet Spark Classic/Beat (Mexico)
|-
|V
|SAIC-GM Wuhan plant: Wuhan, Hubei province, China
|2018-2021 Chevrolet Cavalier (Mexico), 2022- Chevrolet Cavalier Turbo (Mexico)
|-
|W
|Suzuki plant: Iwata, Shizuoka prefecture, Japan
|1989-1990 Geo Tracker
|-
|1
|Opel plant: Rüsselsheim, Germany
|2011, 2018-2020 Buick Regal
|-
|3
|Isuzu plant: Kawasaki, Kanagawa prefecture, Japan
|1987-1998 Chevrolet/GMC W5, 1989-1996 Chevrolet/GMC W6, 1984-1996 Chevrolet/GMC W7
|-
|5
|Opel plant: Antwerp, Belgium
|2008-2009 Saturn Astra
|-
|7
|Isuzu plant: Fujisawa, Kanagawa prefecture, Japan
|1988 Chevrolet Spectrum, 1988 Pontiac Sunburst (Canada), 1989 Geo Spectrum, 1990-1993 Geo Storm,<br /> 1999-2008 Chevrolet/GMC W3500, 1988-2009 Chevrolet/GMC W4, 1999-2009 Chevrolet/GMC W5,<br /> 2000-2004 Chevrolet/GMC WT5500,<br /> 2016- Chevrolet Low Cab Forward 3500HD/4500HD/4500XD/5500HD/5500XD
|-
|8
|Isuzu plant: Fujisawa, Kanagawa prefecture, Japan
|1981-1982 Chevrolet LUV, 1985-1987 Chevrolet Spectrum, 1985-1987 Pontiac Sunburst (Canada),<br /> 1986-1987 Chevrolet/GMC W4
|}
==GM WMIs==
{| class=wikitable
!WMI
!Marque
!Country
|-
|1G1||rowspan=57|Chevrolet||United States
|-
|1G8||United States (MPV 1981-1986)
|-
|1GA||United States (bus [van with more than 3 rows of seats])
|-
|1GB||United States (incomplete vehicle)
|-
|1GC||United States (truck)
|-
|1GN||United States (MPV 1987-)
|-
|1HA||United States (Express incomplete vehicle made by Navistar)
|-
|1HT||United States ([[w:Chevrolet Silverado#Medium duty version_(4500HD,_5500HD,_6500HD,_and_International_CV)|Silverado Medium Duty]] incomplete vehicle made by Navistar)
|-
|1Y1||United States (made by NUMMI)
|-
|2C1||Canada (car made by CAMI)
|-
|2CN||Canada (SUV made by CAMI - 1998-2011)
|-
|2G1||Canada
|-
|2G5||Canada (truck - Chevrolet BrightDrop '25)
|-
|2G8||Canada (MPV 1981-1986)
|-
|2GA||Canada (bus [van with more than 3 rows of seats])
|-
|2GB||Canada (incomplete vehicle)
|-
|2GC||Canada (truck - includes Chevrolet BrightDrop '26)
|-
|2GN||Canada (MPV 1987-)
|-
|3G1||Mexico
|-
|3GC||Mexico (truck)
|-
|3GN||Mexico (MPV)
|-
|3N6||Mexico (Truck - City Express made by Nissan)
|-
|4G1||United States (made by Genasys L.C.)
|-
|4KB||United States (W-Series incomplete vehicle made by GM - through 2009)
|-
|4W1||United States (MPV - Chevrolet Suburban HD made for US govt. in Concord, NC)
|-
|54D||United States (incomplete vehicle made by Spartan Motors/The Shyft Group)
|-
|6G1||Australia (2011-2013 Caprice PPV)
|-
|6G3||Australia (2014-2017 Caprice PPV & SS performance sedan)
|-
|ADM||South Africa
|-
|J81||Japan (car made by Isuzu)
|-
|J8B||Japan (incomplete vehicle made by Isuzu - through 2009)
|-
|J8Z||Japan (LUV pickup made by Isuzu)
|-
|JAL||Japan (incomplete vehicle made by Isuzu - 2016+)
|-
|JG1||Japan (car made by Suzuki)
|-
|KL1||South Korea (car)
|-
|KL7||South Korea (MPV - 2012+)
|-
|KL8||South Korea (Spark)
|-
|LSF||China (S-10 Max made by SAIC-Maxus - Mexico only)
|-
|LSG||China (SAIC-GM)
|-
|LSH||China (Express Max made by SAIC-Maxus - Mexico only)
|-
|LZW||China (SAIC-GM-Wuling)
|-
|MA6||India
|-
|MJB||Indonesia (GM Indonesia)
|-
|MK3||Indonesia (SGMW Motor Indonesia)
|-
|MMM||Thailand
|-
|XUF||Russia (GM Russia - St. Petersburg plant)
|-
|XUU||Russia (Chevrolet Korea models made by Avtotor in Kaliningrad)
|-
|XWB||Uzbekistan (GM Uzbekistan, UzAuto Motors)
|-
|XWF||Russia (Chevrolet Tahoe & Trailblazer [GMT360] made by Avtotor in Kaliningrad)
|-
|X9L||Russia (GM-AvtoVAZ)
|-
|8AG||Argentina
|-
|8GG||Chile
|-
|8LD||Ecuador
|-
|8Z1||Venezuela
|-
|9BG||Brazil
|-
|93C||Brazil
|-
|9GC||Colombia
|-
|J81||rowspan=6|Geo||Japan (car made by Isuzu)
|-
|JG1||Japan (car made by Suzuki)
|-
|JGC||Japan (SUV made by Suzuki)
|-
|1Y1||United States (car made by NUMMI)
|-
|2C1||Canada (car made by CAMI)
|-
|2CN||Canada (SUV made by CAMI - 1990-1997)
|-
|KLA||rowspan=3|GM Daewoo/<br />GM Korea||South Korea (Bupyeong & Kunsan plants)
|-
|KLY||South Korea (Changwon plant)
|-
|5GD||United States (G2X)
|-
|1G2||rowspan=12|Pontiac||United States
|-
|1G5||United States (incomplete vehicle - for '89-'90 Turbo Grand Prix by ASC/McLaren & '03-'05 Montana Mobility, '06 Montana SV6 Mobility)
|-
|1GM||United States (MPV)
|-
|2CK||Canada (2006-2009 Torrent made by CAMI)
|-
|2G2||Canada
|-
|2G7||Canada (US market 1983 Pontiac Parisienne)
|-
|3G2||Mexico
|-
|3G7||Mexico (MPV: 2001-2005 Aztek)
|-
|4G2||United States (made by Genasys L.C.)
|-
|5Y2||United States (made by NUMMI)
|-
|6G2||Australia
|-
|KL2||South Korea (made by Daewoo/GM Daewoo)
|-
|1G7||rowspan=6|Pontiac<br />(Canada only)||United States
|-
|2C7||Canada (car made by CAMI)
|-
|2CG||Canada (SUV made by CAMI)
|-
|2G7||Canada
|-
|J87||Japan (car made by Isuzu)
|-
|JG7||Japan (car made by Suzuki)
|-
|KL7||Passport<br />(Canada only)||South Korea (car made by Daewoo)
|-
|J87||rowspan=3|Asüna<br />(Canada only)||Japan (car made by Isuzu)
|-
|KL7||South Korea (car made by Daewoo)
|-
|2CG||Canada (SUV made by CAMI)
|-
|1G3||rowspan=3|Oldsmobile||United States
|-
|1GH||United States (MPV/SUV)
|-
|2G3||Canada
|-
|1G4||rowspan=9|Buick||United States
|-
|2G4||Canada
|-
|3G4||Mexico
|-
|3G5||Mexico (MPV)
|-
|4GL||United States (incomplete vehicle)
|-
|5GA||United States (MPV)
|-
|KL4||South Korea (MPV)
|-
|LRB||China (SAIC-GM)
|-
|W04||Germany & Poland
|-
|KLA||Alpheon||South Korea (2011-2015)
|-
|1G6||rowspan=10|Cadillac||United States
|-
|1GE||United States (incomplete vehicle)
|-
|1GY||United States (SUV)
|-
|2G6||Canada
|-
|2GE||Canada (incomplete vehicle)
|-
|3GY||Mexico (SUV)
|-
|LRE||China (SAIC-GM)
|-
|W06||Germany
|-
|XWF||Russia (made by Avtotor in Kaliningrad)
|-
|YSC||Sweden
|-
|1G8||rowspan=4|Saturn||United States
|-
|3GS||Mexico (SUV)
|-
|5GZ||United States (MPV/SUV)
|-
|W08||Belgium
|-
|1G0||rowspan=22|GMC||United States (bus 1981-1986)
|-
|1G5||United States (MPV 1981-1986)
|-
|1GD||United States (incomplete vehicle)
|-
|1GJ||United States (bus 1987-)
|-
|1GK||United States (MPV 1987-)
|-
|1GT||United States (truck)
|-
|2CK||Canada (1990-1991 Tracker made by CAMI - Canada only)
|-
|2CT||Canada (2010-2011 Terrain made by CAMI)
|-
|2G0||Canada (bus [van with more than 3 rows of seats] 1981-1986)
|-
|2G5||Canada (MPV 1981-1986)
|-
|2GD||Canada (incomplete vehicle)
|-
|2GH||Canada (transit bus)
|-
|2GJ||Canada (bus [van with more than 3 rows of seats] 1987-)
|-
|2GK||Canada (MPV 1987-)
|-
|2GT||Canada (truck)
|-
|3GK||Mexico (SUV)
|-
|3GT||Mexico (truck)
|-
|4KD||United States (W-Series incomplete vehicle made by GM - through 2009)
|-
|7GZ||United States (incomplete vehicle made by Navistar)
|-
|J8D||Japan (incomplete vehicle made by Isuzu - through 2009)
|-
|JGT||Japan (SUV made by Suzuki - Canada only)
|-
|KL6||South Korea (Middle East market Terrain '08-'10)
|-
|4GD||WhiteGMC||United States (1988-1989 Brigadier made by GM)
|-
|137||rowspan=6|Hummer||United States (H1 made by AM General)
|-
|5GN||United States (H3T)
|-
|5GR||United States (H2 made by AM General)
|-
|5GT||United States (H3)
|-
|ADM||South Africa (H3)
|-
|XWF||Russia (H2 & H3 made by Avtotor in Kaliningrad)
|-
|4G5||General Motors||United States (EV1)
|-
|2G5||rowspan=2|BrightDrop||Canada (Truck 2023-2024)
|-
|5G5||United States (Truck made by Kuka AG - 2022 only)
|-
|5G2||rowspan=2|Cruise||United States (car) (Cruise AV)
|-
|5G3||United States (MPV) (Cruise Origin AV)
|-
|YS3||rowspan=4|Saab||Sweden
|-
|JF4||Japan (9-2X made by Subaru)
|-
|3G0||Mexico (9-4X)
|-
|5S3||United States (9-7X)
|-
|W0L||rowspan=19|Opel/Vauxhall||Germany & the rest of Europe (2017 and earlier)
|-
|W0V||Germany & the rest of Europe (2018 and later) & Opel Ampera-e Mid-2017 - 2019
|-
|W0L||when plant code is H: Thailand (Zafira A)
|-
|W0L||when plant code is 0: South Korea (Antara) or B: South Korea (Antara, Mokka A, Mokka X [A])
|-
|W0L||when plant code is C: South Korea (Opel Karl/Vauxhall Viva)
|-
|W0V||when plant code is B: South Korea (Mokka X [A]) or C: South Korea (Opel Karl/Vauxhall Viva)
|-
|SCC||UK (Opel Lotus Omega made by Lotus)
|-
|SED||UK (made by IBC Vehicles)
|-
|TW8||Portugal
|-
|VF1||France (Arena made by Renault)
|-
|VN1||France (Movano A made by Renault at SOVAB plant in Batilly, France)
|-
|VSX||Spain
|-
|XUF||Russia (Opel made by GM Russia - St. Petersburg plant)
|-
|XWF||Russia (Opel made by Avtotor in Kaliningrad)
|-
|1G0||United States (Opel GT, Opel/Vauxhall Ampera, Opel Ampera-e Early - Mid-2017)
|-
|4GD||United States (Sintra)
|-
|ADM||South Africa
|-
|JAA||Japan (Opel Campo made by Isuzu)
|-
|JAC||Japan (Monterey made by Isuzu)
|-
|SKA||rowspan=4|Vauxhall Motors||UK
|-
|SCC||UK (Vauxhall Lotus Carlton made by Lotus)
|-
|6G1||Australia (Vauxhall Monaro & VXR8 made by Holden)
|-
|JAA||Japan (Vauxhall Brava made by Isuzu)
|-
|SKF||rowspan=2|Bedford Vehicles||UK
|-
|JAA||Japan (Bedford Brava made by Isuzu)
|-
|6G1||rowspan=18|Holden||Australia (2003-2017)
|-
|6H8||Australia (1989-2002)
|-
|JAA||Japan (Rodeo pickup [TF] made by Isuzu)
|-
|JAC||Japan (Jackaroo/Monterey made by Isuzu)
|-
|JSA||Japan (YG Cruze made by Suzuki)
|-
|KL3||South Korea
|-
|MMM||Thailand ('09-'11 Colorado pickup [RC] made by GM Thailand)
|-
|MMU||Thailand ('13-'20 Colorado pickup [RG], '13-'16 Colorado 7, '17-'20 Trailblazer made by GM Thailand)
|-
|MPA||Thailand ('04-'08 Rodeo pickup [RA] made by Isuzu Thailand)
|-
|SED||UK (1st gen. Frontera made by IBC Vehicles)
|-
|W0L||Germany & the rest of Europe (2017 and earlier)
|-
|W0L||when plant code is H: Thailand (Zafira A)
|-
|W0V||Germany & the rest of Europe (2018-2020)
|-
|1GH||United States (Acadia)
|-
|3G0||Mexico (Equinox)
|-
|3GM||Mexico (Suburban)
|-
|4S2||United States (2nd gen. Frontera made by [[w:Subaru Isuzu Automotive|SIA]])
|-
|5G8||United States (Volt)
|-
|1GG||rowspan=4|Isuzu||United States (Truck - Hombre & i-Series made by GM)
|-
|4GT||United States (H-Series & T-Series incomplete vehicle made by GM - through 2009)
|-
|4KL||United States (N-Series incomplete vehicle made by GM - through 2009)
|-
|4NU||United States (MPV/SUV - Ascender made by GM)
|-
|W0L||Subaru||Thailand [plant code H] (Traviq made by GM Thailand for export to Japan)
|-
|4G3||Toyota||United States (Cavalier made by GM for export to Japan)
|-
|3GP||Honda||Mexico (MPV/SUV: 2024-2026 Prologue made by GM)
|-
|4W5||Acura||United States (MPV/SUV: 2024 ZDX EV made by GM)
|}
{{BookCat}}
9izrwokjso7lvw329t15clgisljnmun
Wikijunior talk:Biology
111
234087
4655973
3784786
2026-08-01T06:43:37Z
Permata55
3618426
/* Bagaimana cara menghubungi bank Permata? */ new section
4655973
wikitext
text/x-wiki
==Some Merged pages==
I have merged [[Wikijunior:Biology/Kingdoms/Plants/Photosynthesis]] and [[Wikijunior:Biology/Kingdoms/Plants]]. But before [[Wikijunior:Biology/Kingdoms/Plants/Photosynthesis]] is deleted through a history merge, I thought I would check to see if any one objected. Since history merges are irreversible. [[User:Thenub314|Thenub314]] ([[User talk:Thenub314|talk]]) 18:00, 2 July 2010 (UTC)
:It looks good to me. Very natural. Even the picture already present at plants goes well with photosynthesis. --[[User:Pi zero|Pi zero]] ([[User talk:Pi zero|talk]]) 18:25, 2 July 2010 (UTC)
== Merging [[{{BOOKNAME}}/Systems/Nervous system/Senses|Nervous system/Senses]] ==
I have, similarly, merged {{nowrap|[[{{BOOKNAME}}/Systems/Nervous system/Senses]]}} into {{nowrap|[[{{BOOKNAME}}/Systems/Nervous system]]}}, and similarly I haven't merged the histories yet because that's irreversible. Just as Photosynthesis was the only subpage of a kingdom, Senses was the only subpage of a system; and because the image at Nervous system takes up so much more vertical space than the text, Senses fits in easily. Does anyone object to this merge? --[[User:Pi zero|Pi zero]] ([[User talk:Pi zero|talk]]) 21:23, 4 July 2010 (UTC)
:Seems like an excellent idea to me. We should keep in mind this wikibook was recently imported from the Simple English wikibooks. Probably we are safe to merge, but I will leave it for a little longer. [[User:Thenub314|Thenub314]] ([[User talk:Thenub314|talk]]) 10:17, 5 July 2010 (UTC)
::As long as the on-line book is in a consistent state, and the sidelined pages are in a self-evident state, there's no rush about it. I've added tags to both sidelined pages so if anyone stumbles across them they'll know what's going on. --[[User:Pi zero|Pi zero]] ([[User talk:Pi zero|talk]]) 15:08, 5 July 2010 (UTC)
== Evolution / origin of life ==
I started a new page on evolution and the [[wikijunior:Biology/Origin of Life|Origin of Life]] but I didn't want to add it to the ToC without some consensus and probably some more work to make it more worthy of the featured status of the rest of the book. --[[User:DoC352|DoC352]] ([[User talk:DoC352|talk]]) 19:09, 13 January 2011 (UTC)
== BIOLOGY FOR NATURE AND ANIMALS....... ==
AT PRESENT NECESSARY IT TO CONTRIBUTE NATURE CARE AND CALAMITE CONTROLS DO BY HUMAN BEINGS.OVER ALL MANKIND TO DOIT AND SURVIVAL.FEEDER,ECTS.
== Bagaimana cara menghubungi bank Permata? ==
Nomor call center resmi Permata Bank (PermataTel) adalah 0831_5053_7117 [[User:Permata55|Permata55]] ([[User talk:Permata55|discuss]] • [[Special:Contributions/Permata55|contribs]]) 06:43, 1 August 2026 (UTC)
6enuiaq7k5vvtug8gxwown1p2ckyriy
4655978
4655973
2026-08-01T07:33:07Z
MathXplore
3097823
[[WB:REVERT|Reverted]] edit by [[Special:Contributions/Permata55|Permata55]] ([[User talk:Permata55|talk]]) to last version by Stanglavine
3366701
wikitext
text/x-wiki
==Some Merged pages==
I have merged [[Wikijunior:Biology/Kingdoms/Plants/Photosynthesis]] and [[Wikijunior:Biology/Kingdoms/Plants]]. But before [[Wikijunior:Biology/Kingdoms/Plants/Photosynthesis]] is deleted through a history merge, I thought I would check to see if any one objected. Since history merges are irreversible. [[User:Thenub314|Thenub314]] ([[User talk:Thenub314|talk]]) 18:00, 2 July 2010 (UTC)
:It looks good to me. Very natural. Even the picture already present at plants goes well with photosynthesis. --[[User:Pi zero|Pi zero]] ([[User talk:Pi zero|talk]]) 18:25, 2 July 2010 (UTC)
== Merging [[{{BOOKNAME}}/Systems/Nervous system/Senses|Nervous system/Senses]] ==
I have, similarly, merged {{nowrap|[[{{BOOKNAME}}/Systems/Nervous system/Senses]]}} into {{nowrap|[[{{BOOKNAME}}/Systems/Nervous system]]}}, and similarly I haven't merged the histories yet because that's irreversible. Just as Photosynthesis was the only subpage of a kingdom, Senses was the only subpage of a system; and because the image at Nervous system takes up so much more vertical space than the text, Senses fits in easily. Does anyone object to this merge? --[[User:Pi zero|Pi zero]] ([[User talk:Pi zero|talk]]) 21:23, 4 July 2010 (UTC)
:Seems like an excellent idea to me. We should keep in mind this wikibook was recently imported from the Simple English wikibooks. Probably we are safe to merge, but I will leave it for a little longer. [[User:Thenub314|Thenub314]] ([[User talk:Thenub314|talk]]) 10:17, 5 July 2010 (UTC)
::As long as the on-line book is in a consistent state, and the sidelined pages are in a self-evident state, there's no rush about it. I've added tags to both sidelined pages so if anyone stumbles across them they'll know what's going on. --[[User:Pi zero|Pi zero]] ([[User talk:Pi zero|talk]]) 15:08, 5 July 2010 (UTC)
== Evolution / origin of life ==
I started a new page on evolution and the [[wikijunior:Biology/Origin of Life|Origin of Life]] but I didn't want to add it to the ToC without some consensus and probably some more work to make it more worthy of the featured status of the rest of the book. --[[User:DoC352|DoC352]] ([[User talk:DoC352|talk]]) 19:09, 13 January 2011 (UTC)
== BIOLOGY FOR NATURE AND ANIMALS....... ==
AT PRESENT NECESSARY IT TO CONTRIBUTE NATURE CARE AND CALAMITE CONTROLS DO BY HUMAN BEINGS.OVER ALL MANKIND TO DOIT AND SURVIVAL.FEEDER,ECTS.
t38na88fjw39mathl8qaqkzhitfapg1
Aros/Platforms/Arm Raspberry Pi support
0
286123
4655981
4655873
2026-08-01T10:47:51Z
Jeff1138
301139
4655981
wikitext
text/x-wiki
{{ArosNav}}
[[#Native]]
[[#Hosted]]
==Introduction==
The Raspberry Pi Foundation is a charity founded in May 2009 to promote the study of basic computer science in schools, and is responsible for developing a single-board computer called the Raspberry Pi.
The Foundation is supported by the University of Cambridge Computer Laboratory and Broadcom. Its aim is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing."
The original Raspberry Pi 1 Model B computer went on sale in February 2012 and set a new standard shattering the dominance of the PC in the home and education markets. Millions in the various formats, A, B, A+, B+ and Compute have since been shipped worldwide. The original concept of the Raspberry Pi was for a computer board providing Internet access with up to 1080p HD graphics at very low cost. The boards provide a platform for children and adults from any background to acquire computer science knowledge and help develop the future World-Wide-Web and all things internet (IOT hub and bridges out to home network to cloud of sensors).
Hobbyists and tech dabblers/tinkerers are the main purchases of the Pis (around half).
The rest of the sales are split between education/industrial. While the Raspberry Pi boards were designed primarily for education, they have become very popular with manufacturers of embedded systems. The Raspberry Pi Foundation has ensured backwards compatibility with each new revision. The bare-bones Compute module is aimed specifically at the OEM manufacturer.
* Pi 5 - Quad A76 and RP1 "southbridge" with VideoCore 7 4Gb 8Gb LPDDR4X
* Pi 4 - Quad A72 64bit VideoCore 6
* Pi 3 - Quad A53 [https://www.raspberrypi.com/documentation/computers/processors.html 64 bit] - VideoCore 4
* Pi 2 - Quad 32bit but more power consumed
* Model B+ - lower power usage but same speed as the original Pis
* Model A and B -
* Compute 1, 3, 4 and 5 - industrial use
<pre>
2008 Trustees collected for Foundation
2009 Charity status gained
2010
2011 First Raspberry prototypes
2012 First boards go on sale at CPC and RS. The Model A and B 700 MHz Arm11 - February 29th BCM 2835
2012 First million sold - more than the 10,000 original planned and anticipated
2013 First Alpha Experimental builds of AROS Native for the Pi
2013 Pi Trading launched making grants available, providing in house educational resources and Pi Academy for teacher training
2013 Over two million sold
2014 Over three million sold and updated Model B+ introduced that moved composite video to audio jack and same half gig of memory
2014 Pi Model A+ v1.1 - BCM2711 no ethernet and 1 usb - a little smaller -
2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit core and 32bit VideoCore IV 3d GPU with 1Gb RAM
2015 Over four million first gen pis sold
2015 Over a million pi2s sold
2015 Pi Zero BCM2835 released
2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837
2016 Passed Sinclair total number of computer lines sold - around 7 million
2016 Pi 3 Model B - Broadcom BCM2837 SOC four 64bit ARMv8 Cortex-A53 1.2GHz - 1Gb - bluetooth 4.1, Cypress CYW43438 wireless 802.11n and a dual 32bit VideoCore IV GPU
2016 Total PIs over 10 million worldwide
2016 Compute 3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage
2017 12 million pis sold in total
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 - 1Gb, wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet
2019 Over 15 million sold
2019 Pi 3 Model A with BCM2837b0 with 512Mb,
2019 Raspberry Pi Compute Module 3+ CM3+ LITE Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc
2019 Pi 4 Model B - BCM2711 quad 64bit A72 1.5GHz, VideoCore VI, AC wifi, Bluetooth 5.0, GbE, 2 micro hdmi decode up to 4K, USB-C power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram
2019 Pi 4 Model 2B - BCM2712 4 usb
2020 Raspberry Pi SC0919 Pico RP2040
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard
2020 Raspberry Pi Compute Module 4
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam
2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu
2024 Raspberry Pi Pico 2
2024 Pi 5 2GB version uses BCM2712D0
2024 Pi-500
2024 Raspberry Pi Compute Module 5
2025 Pi-500+
2026 April and May Aros 64bit fixed, added AHI audio, VC4 gfx started, usb functions added to rom
2026 June and July Aros 64bit usb2otg started, dma.resource, sdio.resource, bwfm.device wifi added
2026 Late July daily 64bit Pi3 builds start
2026 August ....
2027
2028 Pi 6
</pre>
===Good sites to visit===
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k]
*[https://github.com/raspberrypi/firmware/tree/master/https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9boot Raspberry Pi Firmware build]
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build]
*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi]
2026 [https://github.com/aros-development-team/AROS/commit/af09e634fff510918670e9f5ad6c5503727fe541 64bit build started late July]
===Native===
* 2013-03 Kalamatee starts work
* 2013-05 Work put on hiatus
* 2015-04 Work continues slowly with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb
* 2018 [https://www.patreon.com/posts/i-owe-you-some-20956961 mschulz resume with adding BE big endian support as well]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=bsek latest commits]
The status of AROS native for RasPi was OK. System booting, USB working (although with some issues but plan to fix them). Got stuck on modifying the ABI (application binary interface) and adjusting binutils/gcc to support it wanted to have real executable files but got stuck a little. This change for the type of relocations embedded in ARM files and not sure if this very type is well supported, on the other hand without this change ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.
Old native [http://www.aros.org/nightly1.html ARMv6 32bit nightlys] and
[http://www.aros.org/snapshots1.html old linux and android hosted]
# download/checkout the source someplace, e.g. /build/AROS-Src/
# make a directory to store external sources AROS downloads, e.g. /build/Ports
# make a build directory, e.g. /build/aros-raspi-armhf
# cd into the build dir, configure, and then run make -:
<pre>
>cd /build/aros-raspi-armhf
>/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
>make
>make arosboot-raspi
</pre>
then copy the files from /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ onto an sdcard, and download/copy the Raspi firmware files onto it.
You should then be able to boot the sdcard on your RasPi.
The current W.I.P tree to svn. it can be built as follows ..
<pre>
./configure --target=raspi-armhf
make arosboot-raspi
</pre>
That will generate arosraspi.img, arosraspi.rom and config.txt in bin/raspi-arm/AROS - so either copy just those files to a fat formatted SD card (with the firmware files on), or copy the whole contents of the AROS folder.
NB - if you have a Linux/other install, backup the existing config.txt first
arosraspi.img contains the bootstrap (which has very basic mailbox code, framebuffer/gpio init, and console "emulation" via code pinched from our libbootconsole), kernel.resource, and exec.library
arosraspi.rom contains all the other components needed to boot AROS.
The config.txt file will tell the RasPI bootstrap to load our arosraspi kernel and ramdisk (rom).
the bootstrap has minimal mailbox code, planning on adding either a resource or library that driver/app code will use to access it (likewise for GPIO)
==== Hosted ====
Ubuntu VM approach to compiling [http://lallafa.de/blog/2013/06/building-aros-hosted-for-raspbian/ Linux hosted AROS June 04, 2013]
../AROS/configure --target=linux-armhf --enable-includes=/usr/arm-linux-gnueabihf/include --x-includes=/usr/arm-linux-gnueabihf/include --x-libraries=/usr/arm-linux-gnueabihf/lib
arm-elf- is symbol-linked to arm-linux-gnueabi- (arm-linux-gnueabi- is more correct in this case, because it's going to be compiling the ARM AROSBootstrap for ARM Linux)
*armel - many of the "android" machines require since the entire OS is made for soft float VFP.
*armfp - Efika MX target, Raspberry PI, EfikaMX, Pandora and virtually everything (VFP)
Keep in mind it's possible to start hardfp AROS hosted on softfp system, though, as long as no calls between AROS and host require floating point parameters. NOTE: hardfloat objects *cannot* be linked with softfloat objects - they have a different ABI.
Just keep in mind the arm nightly build machine is quite complex beast. It needs the x86_64 host compiler to compile AROS tools. The arm version is built every night using gcc-4.6.2 crosscompiler (built together with AROS) and successfully builds armel and armhf linux hosted targets.
*needs an AROS code compiler for ARM target
*as well as unix compiler for ARM linux host (would be best to have both softfp and armhf, we have softfp only now) with full set of libraries and includes.
with—disable-crosstools $AROS_CC is always a wrapper around $KERNEL_CC ? If so, this is wrong for some ports. This can break Darwin, Windows and Android port.
Yes, Android port will build. And even work. But it's not good because the port will not be ABI-compatible with other ARM ports. Android's ABI is different from GNUEABI. For example:
<pre>
enum test {foo, bar};
enum test testvar;
</pre>
siseof(testvar) will be equal to sizeof(int) in GNUEABI (Linux and AROS) and sizeof(short) on Android. This affects linking objects from static linklibs, for example.
Previously everything worked because $AROS_CC was a wrapper on top of $HOST_CC. And a real crosscompiler was used on non-ELF hosts.
Android is the same. $KERNEL_CC is incompatible with AROS.
compiler=kernel is appropriate _ONLY FOR CODE WHICH RUNS ON HOST OS_ (or barebone hardware, if we talk about native). This includes bootstraps, their linklibs, and host-side dynamic libraries (Windows makes extensive use of them because of architectural considerations.
No single AROS object should be compiled with this setting. $KERNEL_CC is really compatible with AROS *ONLY IN LINUX-HOSTED* and no more. On other systems (Darwin, Windows, Android) this is not true any more, and compiler=kernel is never going to work.
If you want to compile your AROS module against host OS includes, append the following to USER_INCLUDES (or USER_CFLAGS, this is effectively the same):
-isystem $(GENINCDIR) $(KERNEL_INCLUDES)
$(KERNEL_INCLUDES) expands to:
-isystem <your_os_includes> -isystem <host_OS_gcc_private_includes>
-nostdinc
This makes AROS compiler adhering to host OS APIs.
If you want some preprocessor symbols based on what your host OS actually is, add something like -DHOST_OS_$(AROS_HOST_ARCH).
Why is there $(GENINCDIR) at all? Because host OS has its own libc includes, which would conflict with AROS ones. And the host OS libc is not binary-compatible with AROS one.
Why doesn't Windows-hosted port use $(KERNEL_INCLUDES) ? Because WinAPI includes conflict with AROS ones in fundamental typedefs, like WORD, BYTE and BOOL. It's almost impossible to deal with this in any other way than rewriting WinAPI definitions using AROS types.
Building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. haven't yet committed the necessary changes but "./configure --target=raspi-armhf" is enough to start, then "make arosboot-raspi" will generate arosraspi.img (containing the bootstrap, kernel.resource, and exec.library) as well as arosraspi.rom (containing all the other essentials components such as dos, graphics etc). It will also copy over a config.txt file to make the raspi bootstrap code load the correct kernel, and a cmdline.txt that enables exec debug output.
*armel = typically Debian 6, Ubuntu Maverick, Android,
*armhf = typically Debian 7, Debian 8, Ubuntu Precise,
Cross-compiling Ubuntu ARM softfp
<pre>
sudo sh
echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
</pre>
<pre>
./configure --target=linux-arm --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabi/include
</pre>
Cross-compiling Ubuntu ARM hard-float
<pre>
sudo sh
echo 'foreign-architecture armhf' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armhf.list
apt-get update
apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
</pre>
<pre>
./configure --target=linux-armhf --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabihf/include
</pre>
Now, the AROS build is configured properly and all you need to do is:
make
[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]
== Hardware ==
===64bit===
====BCM2712====
BCM2837
* Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support, 3B+ [https://github.com/aros-development-team/AROS/commit/afa5bc0bb17d5dd06bcfdbac00853a3799ca8d76 LAN7515]
====BCM2711====
===32bit===
=== Core Kernel ===
the reason behind INTB_KERNEL is to allow use of the standard Exec function AddIntServer() to add interrupt handlers for
hardware drivers etc. AmigaOS never used it for abstract hardware drivers. AmigaOS routed only raw hardware IRQs there. Their assignment was hardcoded. As well as number of them. Actually on AmigaOS every bus has its own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt. 1:1 relationship between CPU and hardware interrupts is present only on PC.
IMHO we miss things like AddInterrupt/RemInterrupt methods on our PCI subsystem's device class. PCI bus class should map these methods to whatever is appropriate. This is how it is done on AmigaOS and friends. When these are implemented, raw kernel.resource API will be needed only for several PC-specific drivers with hardwired resources. Exec IRQs are real IRQs only on Amiga hardware. On other machines they can be emulated where appropriate (VBlank is a good example). kernel.resource is meant to be different, its IRQs are hardware-agnostic, they are plain "Hardware IRQ number X, whatever this means". They are low-level actually, and meaningful only in the context of a particular system.
Was that not the transition from irq.hidd to kernel.resource? No. A long time ago there was another hacky bit named INTB_TIMERTICK. It was "abstract timer interrupt", used by timer.device. It was the same as VBlank, but with larger frequency. I removed it, because kernel.resource API was a cleaner way to access this interrupt. Furthermore, there can be more than one timer in the system. I am even thinking about bringing back timer HIDD definitions again. hpet.resource is a bad idea.
Can someone please enlighten me a little on how the scheduler is meant to work?
Poseidon.library creates its "Poseidon Event Task" during RTF_COLDSTART -> then calls Wait(), and ends up in limbo because wait disables interrupts (used for the scheduler heartbeat), and basically waits forever because the sigbit is never set, since krnSwitch doesn't switch the task unless TF_SWITCH is set, and no codepath run during this seems to set it?? TF_SWITCH does not disable/enable switching. This flag just enables to run user-supplied hook when the task is being switched away. It is completely safe to call Wait() in Disable()d state. Doing this actually temporarily breaks this state. IDNestCnt gets remembered in struct Task, then next task is selected, and its IDNestCnt is restored in sysbase (see kernel_scheduler.c). If there are no other tasks, then your cpu_Dispatch() should enable interrupts on the CPU and enter idle mode. See x86 implementation for good example.
You miss what happens next...
1. KrnSwitch() saves context of your task, saves IDNestCnt (core_Switch() and cpu_Switch()), then drops into cpu_Dispatch().
2. cpu_Dispatch() calls core_Dispatch. Then two cases are possible:
2a. There is a READY task. It is picked up, its IDNestCnt is restored in SysBase, then cpu_Dispatch() needs to restore registers and exit. The next task is run.
2b. There are no READY tasks. core_Dispatch() returns NULL. In this case your cpu_Dispatch() should enter idle loop. It should just enable interrupts on the CPU and put it on halt. This allows it to process hardware interrupts. Eventually some of your interrupt handlers wakes up your task and puts it into READY list.
My heartbeat interrupt has been slowed atm to help debugging - but it never actually gets a chance to fire because of the Wait() disabling interrupts. Perhaps you have forgotten to enable interrupts in your idle loop.
There is a change in the format of AROS executables. Until now we were using Elf RELocable files which are usually used as intermediate object files. We had them for various reasons, one of them was how AROS files were built in the past. That days we had no real aros cross compiler and the option to embed relocation data in unix executables (or in executable files in general) was rather new and not every linux/unix system had it. Therefore we have decided to use intermediate files. Although it was somehow working (and it is still working :-)), it has some drawbacks. Therefore decided to introduce real Elf EXEC types, in first turn implemented on ARM target with option to expand in future to all other AROS architectures.
The first patch was pretty easy and appeared to work somehow. It generated nice executables with embedded relocation info. Not only that, it also removed all global symbols adjusting relocation data to be relative to the beginning of the sections. That move reduced number of symbols in each executable significantly (depending on the file between 20 and 80% of all symbols could be removed). The only symbols that stayed in the file are local ones - due to the nature of the patch wasn't able to remove them since we have not seen them in the symbol hash table.
The patch didn't worked though. The files were relocated, AROS kernel loaded, but it crashed very early. What happened? Well, the nature of ARM relocations happened :)
Most of the relocation data on all machines is rather simple. Relocation can be absolute or pc-relative, sometimes the offset has to be bit shifted. On ARM v7 there is another one. There, when one wants to load an address of function/variable into register a combination of two instructions can be used: movw and movt. The first one loads immediate into lower 16 bits of a register while clearing upper 16 bits. The second one loads immediate into upper 16 bits without touching lower halfword. Loading of a pointer into a register looks like this:
movw r0, #:lower16:label
movt r0, #:upper16:label
In this case there are two relocations - one for lower halfword and another for upper. If an overflow of lower 16 bits occurs during relocation process, the upper one should be updated as well. Unfortunately with current patch and with typical ARM executables there is not enough information to perform the calculations.
There are two options - the first one would be to give up and go back to "fake" executables, another one would be to change from REL to RELA relocation info. The latter contains an addend, extra data which can be used to perform all the relocation calculations I need.
Decided for the second option. The patch is already in the works. There is another function for the binutils' bfd backend to perform the final relocation. There can decide what to do with every reloc info, modify data and eventually strip some symbols. An advantage is - at this stage of the linking process have also full access to all local symbols so can change all relocations section relative and eventually strip all symbols from the files.
=== GPU ===
Most of start.elf runs on the GPU. Placing ALL the userland GPU code in the videocore.hidd isn't going to be a terribly big problem because the code they published is nothing more than a shim that sends data straight to the GPU to execute.
The good news about this is that we only need to write our HIDD using the OpenVG API. The shim is relatively small codewise and lives in the ARM memory (the actual OpenVG code itself lives in the GPU RAM area and its loaded from start.elf). That's also the bad news. Our driver has to translate AROS video calls to OpenVG calls, for most tasks it should be easy, for some, not so much. It's still probably less difficult and less work, than controlling the GPU directly.
The other good news is that anything done through OpenVG happens on the GPU, its truly accelerated. It also has some nice font functions, meaning we can lead into an accelerated text mode later.
Basically, AROS resets or locks up when it tries to use AROS_ATOMIC_INC or DEC. If I comment out the byte/word operations in the header files and use non-atomic operations, the code works as expected.
have read that the L1 cache needs to be enabled to use LDREX and co (which I also read is only meant to be used on multi processor systems with shared memory) - however I am certain this is correctly enabled.
If you are using LREX or STREX, you should have L1 cache enabled, at least on the ARM CPU I work with at work.
L1 cache is enabled by enabling the MMU *AND* setting the C and I bits in the CPU - the C bit is ignored, and the I bit only covers the 16 byte instruction pipeline if the MMU is not enabled.
Can you verify that your assembly is generating LDREX/STREX? From the behavior, it almost sounds like its generating the default Semaphore locked atomics.
Impossible. There are no semaphore-locked atomics. There are Disable()/Enable()-based ones instead. And there's a special #define AROS_NO_ATOMIC_OPERATIONS in this case, which tweaks Disable()/Enable() implementations not to recurse forever.
I have tested this on ARMv5 which does not have ldrex/strex, it works fine. On those ARMs there's no way to have real atomics. On other OSes (like Linux) this is done by introducing things like atomic_t, which appears to be a complex structure, holding the value together with accompanying spinlock (implemented using swp).
#warning "TODO: lookup optimal mmu table settings for raspi memory"
/* Set up an identity-mapping for all 4GB */
for(x = 0; x < 4096; x ++)
{
pagetable[x] = x<<20 | (0x40002|0x80000|0x010000|0x00C00|0x04);
}
Shouldn't there be a second loop that sets the 'C' bit in the descriptor for the RAM pages?
Currently, you have TEX=0, C=0, B=1 for all pages (Shared Device).
You should have TEX=0, C=1, B=0 for RAM (Write-Through, Cached)
So ..
pagetable[x] = x<<20 | 2;
should be enough?
No, for RAM you need to change the '| 0x40' to '| 0x80'
tell dosboot the correct defaults to use
Please don't do this. This bootconfig.c is a deprecated legacy thing. I wanted it to go away completely with time. Instead, display drivers should auto-install themselves during own initialization phase. I. e. detect hardware=>instantiate itself. This should make things way simpler. With this approach you only need to add the driver into KS image to get the device autobooted. No
hardcoded stuff.
Currently VESA and VGA drivers do this, look there for examples. never rewrote ATI driver because i don't have any test system for it.
they defined a smaller AROSCPUContext than the ExceptionContext - yet reference it as ExceptionContext in other places, and since it hasn't allocated enough storage for ExceptionContext, are corrupting memory/the structure (since the elements that are there don't map 1 to 1 with the exception context).
AFAIK, AROS has been moving in a different direction to this in recent
years. It is the job of graphics HIDDs to allocate bitmaps etc. so that
they have the most suitable characteristics, including allocating them
from GPU RAM where possible. The concept of chip RAM is only for legacy
code, and most if not all non-68k platforms should have all system RAM
marked as chip.
BTW, is the video processing code you mention CPU code or GPU code?
Also, IIRC we have support for "external memory allocators". Perhaps that's what we need for the allocation of GPU RAM through the mailbox.
All hosted and x86 native ports should use proper context formats.
trying to clarify if the vblank handler has to have run by this point to prevent this deadlock. Actually, no. Unless you have installed VBlank handler which should wake up at some point. Without VBlank there will be no quantum count. Consequently, there will be no forced preemption. But the rest will work, and multitasking will be cooperative (switch happens only when current task voluntarily gives up the CPU). Does it depend on the vblank having run before this point? and if yes what does that mean on systems where it might be able to run enough code (e.g. get to this point) before the vblank interrupt has triggered? What is it waiting for? It could wait for timer, in this case you need timer.device working. VBlank is currently needed for exec's quantum counter. In current native ports we have only a single timer, which is served by timer.device. VBlank is simulated by timer.device also. If your machine has two timers, then you can use one of them for VBlank, and another for timer.device, this will simplify things down. VBlank needs to be 50 Hz for historical reasons, many programs use it as cheap timer. I am periodically thinking about making some abstract mechanism to be able to change quantum source (and untie it from 50 Hz), but have no time to come up with something good. Additionally i started disliking timer.device hardcoded design when PC has got many timers (old 8253, APIC, HPET).
Currently i think there should be some low-level entity representing tick source. timer.device should just select the most appropriate source for its units.
The BCM2835 has 4 GPU based timer sources - 2 are used by the GPU, so im using Timer3 for our heartbeat and the remaining one will be free to the system. There is also the less capable ARM timer but that is dependent on the CPU frequency. Very good. You won't need any emulation. Set the heartbeat to 50 Hz and drive VBlank from it. Use other timer for MicroHZ.
Can you use the 'econsole.hook' I make for debugging the Sam460 via the serial port?
It provides a before-anything-else shell prompt on the serial port. You can then do 'NewCLI' to test your graphics, or use any DOS command in shellcommands.resource.
You should just be able to add econsole.hook to your module list, and use 'econsole' in your bootargs.
So long as you have a working Exec/RawMayGetChar and Exec/RawPutChar, it should work.
Also make sure to add shell.resource and shellcommands.resource for this.
That should have done it.
If you set "#define DEBUG 1" in arch/all-native/econsole/econsole.c, do you get any additional serial output?
have added it to the build and added econsole to the command line - and can see the bootloader picks up on the emergency bootconsole tag, but I still only get the insert bootable media display?
Im assuming it exposes a fake filesystem that tricks aros into booting?
The contents of which are: ECON:AROS.boot
Way to handle the scheduling code? The implementations I had been following were causing problems, due to cascading interrupts which I cant handle properly in the asm stubs just now (when they break disable etc.) - since it means detecting the interrupted codes cpu mode and getting the correct sp/lr for it, and that's just too tedious for arm.
To work around this ive added a system idle task which does nothing - and when the scheduling code has no task to run switches this in and lets it run, thereby allowing the interrupts etc to resume until something does need to happen.
Also, by adding accounting code to cpu_Switch() and cpu_Dispatch(), it should allow the system to log idle time correctly (as well as running tasks).
have thought of also adding an additional task that never runs, solely to record time spent in IRQ handlers, but I digress..
was under the impression that kernel.resource should *never* be used outside of exec.library. This is a wrong impression.
Michal started designing it because portable nature of AROS does not fit well into exec's API with all its assumptions. So, he started the new, hardware-agnostic kernel API from scratch. Yes, exec sits on top of it in places. But kernel always meant to be open thing. Otherwise it would not exist.
it wasn't meant to be just used willy nilly by user code - but by lower system components (e.g. exec) so that they could be implemented in a more generic fashion, and the kernel resource itself hide the systems quirks.
Adding new things there perfectly keeps up with our decision to minimize AROS-specific intervention into APIs which can clash with MorphOS/OS4 extensions. We want at least source-level compatibility there. Binary compatibility on PPC would be extremely cool, but at the other hand we have no maintainer for this, as well as their ABIs are a bit weird and far from optimal, especially MorphOS one, because it aims for m68k binary compatibility.
It depends on what exactly is being implemented - there's no reason we should have everything crammed into kernel.resource if it doesn't need to be (i.e. if its better suited as a separate component/subsystem in its own right)
The _LE versions are for when you have endian swapping taking place. If the graphics are the same endian as the CPU, no swapping should occur. I ran into a similar terminology problem in SDL with a friend insisting that his Radeon 7000 on his PC was big-endian. It is not, it just uses the same endianness for the graphics card and the CPU so no swapping was necessary. They were both little-endian.
The _LE versions are because the PixFmts refer to the bitmap data being in big endian format in memory, for which the normal version would need to do endianness conversion before applying the shifts/masks. on this platform it is in _LE in memory also so we don't need the conversion hence using the _LE version of the call). would use _LE (if it's really little endian 16 bit mode).
What is the bare minimum needed to implement a framebuffer based gfx driver, with our software handling the rest?
I have tried with just a gfx class that only expose new/dispose/newbitmap - and having an onscreenbitmap used only for the framebuffer itself (with all other bitmaps being chunkybm, and the framebuffer's superclass also being chunkybm), but that alone isn't enough it seems?
You can use workbench/hidds/sm502/ as your example - it is as simple as I could make it.
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
I so far have -:
vc_init: queries the gpus memory, and sets up a fake memory handler for it, then adds the bootmode driver and returns saying all is well
vc_gfxhidd:New: sets up some fake syncmodes to test with and creates the real gfx object.
vc_gfxhidd:NewBitmap: checks if its a framebuffer and uses the onbitmap class or uses the chunkybm class otherwise
vc_onbitmap:New; creates a chunkybm object and then pushes the real framebuffer address into it as the buffer,
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
The code I currently have on SVN seems to create the framebuffers bitmap object fine, but then crashes in intuitions DisplayDriver callback. In particular it crashes performing the getattr on the system default pointer.
don't expose MEMF_CHIP in an allocatable form so AllocSpriteData was failing (and other code later doesn't check if the values are valid == illegal memory accesses)
Actually MEMF_CHIP has to present, for historical reasons.
This has been never fully agreed upon, but in ports i wrote i exposed the whole memory as MEMF_CHIP. The idea behind this is that CHIP is originally the memory where graphics and sound data can be put. On non-Amiga platforms there are no restrictions on this, so the whole memory is CHIP.
Yes, many old software can misbehave with CHIP memory size larger than 2MB. But this actually applies only to m68k AROS which is going to run m68k binaries. In other cases it's quite logical to fix the program when porting.
As to original question: yes, it's enough to have a framebuffer bitmap (one with aoHidd_BitMap_FrameBuffer set to TRUE) and PutPixel routine. It framebuffer can be served by chunky bitmap class, then you can simply create chunky bitmap with your own buffer (see how VESA driver does this). Chunky PutPixel is already there.
struggling to determine what is the correct pixfmt to use for the 24/16/15 bit gfx modes on the RasPi. AFAIK it uses RGB565, for 16bit but im unsure what shifts etc should go with it? suffice to say Im getting the wrong colors so far lol.
<pre>
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0
redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
</pre>
It should likely be vHidd_StdPixFmt_RGB16_LE
This stuff is a bit confusing. The "names" of the stdpixfmts are based on the layout in memory,
ignoring endianess. So for example:
ARGB32: will be 0xAA 0xRR 0xGG 0xBB in memory on both big endian and little endian machines.
The shifts and masks OTOH are based on pixel access (ULONG in this case), so differ depending
on whether you run on big endian machine or little endian machine (that's why there's stdpixfmt_le.h and
stdpixfmt_be.h in rom/hidds/graphics/).
With the 16 bit pixel format it's even more confusing, as for example it's impossible on little endian machine
to describe RGB16 with shifts/masks alone. That's why there's vHidd_PixFmt_SwapPixelBytes_Flag.
(RGB16 == RRRRRGGG GGGBBBBB in memory, and for pixel (WORD) access on little endian machine it needs to
be accessed as GGGBBBBBRRRRRGGGG).
The shifts btw indicate how much to shift the component to the left (!) so that it is moved to the highest bit (31).
The aHidd_PixFmt_StdPixFmt you specify will be ignored most of the time, because when the pixelfmt is registered,
the gfx hidd checks if there's an identical pixfmt (shifts/masks/etc., but ignoring pixfmt->stdpixfmt) already in the system,
and if so, it uses the already existing one and does not create a new one.
In theory it would be better if gfx drivers could simply/only specify a StdPixFmt without all the shifts/masks stuff when the
gfx driver uses pixfmt which matches one of the stdpixfmts exactly. Another possibility would be for gfx drivers to use
HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) and then peek shifts/masks from it and fill out a pixfmt
tag list based on that.
15bit very blue/green: Try to pass same shifts/masks/etc. as in 16 bit pixfmt (maybe you think it's using 15 bit R5G5B5
(or swapped) but it's actually still using 16 bit R5G6B5 (or swapped).
aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count.
But I would still pass the correct one (_LE) == whatever rom/hidds/graphics/stdpixfmts_??.h uses
in the entry where you have looked up shifts/masks/etc.
Use the shifts/masks/etc. from the entry in stdpixfmt_le.h (if you are running on little endian machine) or stdpixfmt_be.h (if you
are running on little endian machine) that matches the pixfmt that its meant to be.
0xAA,0xRR,0xGG,0xBB on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)
0xAA,0xRR,0xGG,0xBB on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_BGRA32)
it feels like AROS trashes the alpha component, otherwise it should be 8A8R8G8B.
read on the subject suggest its in 1x5r5g5b (x is ignored) to keep 16bit alignment .
What I see on screen suggests to me that wrong shift/mask are being applied - however going by the 16bit versions it all looks correct to me so I am really confused as to what is happening.
The output image looks to have too much green/blue, and very weak red.
Why did usbromstartup become HW-specific ?
In the past i have done a big job separating kickstart into several parts. I have never got any responses, so i re-describe my idea.
For now it loads the hs otg chipset driver ..
The idea is to minimize amount of archirecture-specific modules to
make user's life easier. So, the kickstart was split into 'base'
(which does not contain anything machine-specific) and 'BSP' (Board
Support Package) which contains all hardware-specific stuff.
This way, for example, distribution makers can save up space on CD
and make CDs with multiple platform support. Different configuration
would load the same base with different BSP's.
Next there was some part which is entirely missing on hosted. These
are filesystems. Hosted ports do not need them to boot up, so on
hosted they are left out. At the other hand, they are also
architecture-agnostic. So i put them into 'FS' package (standing for
'filesystem').
Poseidon is one more big part. I made it into separate package in
order to allow users to omit it if they don't need it (for example, to
run on retro PCs without USB). Personally i have one. Again, Poseidon
is hardware-agnostic (well, there are USB drivers but HCIs are pretty
standard).
It's mandatory on PI since there are no other interface types - so being a separate package is irrelevant/pointless.
Is Raspberry's USB controller non-HCI compliant? Actually i expect it to be compliant, then wouldn't it be better to make existing drivers discovering them?
AFAIK its HCI 1.0 compliant but I'm not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once i'm more familiar with the workings I can merge in the changes needed to get it operating but for now I will focus on getting it running. Also our drivers have known issues so perhaps a fresh set of eyes might shed some light on what is going wrong.
Another interesting question is whether Poseidon can operate on device side. Is it flexible enough? How similar is being a USB host and USB device? think it will need a bit of work on Poseidon's side. Until then I will force the driver into Host/Master mode in the init code, but leave open device etc to configure the chipset for either's use - and look at trying to add support for working in Device/Slave mode & switching modes once it's up and running.
Actually USBROMStartup is some kind of kludge. Can there be any alternative? Could device drivers be self-installing, like our HIDDs? This would get rid of need to list them in USBRomStartup.
And there is one more thing about modular ports. In order to actually implement this, your bootstrapping environment should provide the ability to load several files. On PC this is provided by GRUB2. on CHRP you can read filesystem via OpenFirmware, and Sam's Parthenope relies on modified u-boot. If your bootstrap allows to load only a single file, then you stuck with monolithic kickstart. By the way... u-boot allows not only to boot up a single uImage or zImage, it also allows to write client programs AFAIK. With this approach, you actually can write modular bootstrap for ARM AROS using unmodified u-boot.
[http://repo.or.cz/w/AROS.git/commit/e7bdc7e7b7f12b07aa24c739abb63721a872a53a arasan eMMC sdcard controller specific header which is not USB] and [http://repo.or.cz/w/AROS.git/commit/8bd19674084526a534ac11f7d4c51932e9ffe3d2 added prelim sdcard device]. [http://repo.or.cz/w/AROS.git/commit/9ab8217f61911fb8b7fd41bee46a992b4668ced1 do not set 4bit data mode, or enable acmd12/dma int's]
====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM)
*Framebuffer (fb) using mailbox
*IRQ scheduler, etc
*Arasan based SD Card controller
*Synopsis DesignWare USB 2.0 OTG controller [http://networkdirection.net/index.php?option=com_content&view=article&id=106:rasperry-pi-usb-controller&catid=45:raspberry-pi&Itemid=54 Unofficial DOCS pdf], [dwc_otg.c FreeBSD], [], [https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/Controllers/DWCDriver/ RiscOS USB Driver], [https://www.riscosopen.org/forum/forums/5/topics/878 RiscOS USB Discussion], [https://www.riscosopen.org/forum/forums/11/topics/1893 Other USB RiscOS], [http://plan9.bell-labs.com/plan9/index.html Plan9 Miller's usb] http://plan9.bell-labs.com/sources/contrib/miller/, [https://github.com/Chadderz121/csud CSUD driver],
*[http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf SMSC 9512] USB LAN/Hub chip
*CMOS RAM
*VCHIQ port which sends messages to the GPU e.g. for mouse, keyboard, audio on HDMI, etc
*Audio Driver
*Serial Peripheral Interface Bus (SPI)
*[http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/ I2C registers]
*I2S
*Universal Asynchronous Receiver Transmitter (UART)
*[http://elinux.org/RPi_BCM2835_GPIOs GPIOs] and [http://www.adafruit.com/blog/2012/08/17/broadcom-bcm2835-peripheral-memory-map-and-gpio-alternate-use-chart-piday-raspberrypi-raspberry_pi/ Alternative view of GPIO]
BCM2836
* For Pi B+, PI 2 and Pi 3 SMSC LAN9514 chip adding 10/100 Ethernet connectivity and four USB channels to the board
The overclock ability has diminished with each chip version as the energy usage has very slowly risen. BCM2837 is one of the warmest yet and might benefit from active cooling (ie fan) if all four cpu cores are in use for a short while. Video playback is not affected due to the custom support in the GPU. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur.
*[http://www.andrewscheller.co.uk/rpi_pcb_modules.html PCB], [http://elinux.org/RPi_Low-level_peripherals Low level features],
Implemented so far...
# Modify the configure system so that it correctly builds for the arm hardware float raspi target.
# Implemented the bootstrap to load the aros modules and prepare the arm to jump into them. Reworked the x86 console support so that parts can be stolen for raspi to use since t has no basic functionality to output to the display.
# Implemented a kernel.resource to prepare the raspi for running aros and provide the low level api calls to expose available resources and allow exec, etc function.
# Implemented serial debug support
# Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc)
# Implemented a timer.device to utilise the hardware timers.
# Implemented a very basic gfx driver to expose the hardware's framebuffer.
# Implemented an SD-Card driver for AROS which presently only supports the raspi's chipset but can easily be modified to support all sd-card hardware and media.
# Fixed the fat filesystem support in AROS so that it can boot on RasPi's normal SD-Card setup. The "rom" image files needed use a different filename than the default linux, etc images so can be easily installed without harming the existing files - you only need to change the loaded images in the config file to get aros to boot.
# Updated the build scripts to automatically download the necessary raspi firmware files and wrap it all up so that you can simply extract the archive to a fat formatted sdcard and boot it on the raspi without having to get anything else.
# fix everything in contrib and ports to build for raspi (needs proper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi ..
Improvements...
# Implement a USB chipset driver "OR" finish the existing one [https://github.com/aros-development-team/AROS/commit/c07d13c724f944674be5db54fc6a71ee72a01809 usb otg] - the current code is mostly a skeleton that should initialise the chipset and then needs relevant code to support the different transfer types. It also has the "virtual" hub code in place to represent the raspi's USB port (from poseidons p.o.v)
# Implement a driver for the USB NIC (a few weeks - depends on USB above)
# Write an [https://github.com/aros-development-team/AROS/commit/d55d0f74d20b769bbb8c8d386e5c1d7a9154f05a audio driver] (a few weeks - independent of USB) and [https://github.com/aros-development-team/AROS/commit/e93a4c245f27a87c9c4c1d39206694b39059998a HDMI]
# fix syscall bug in the current raspi kernel code
# Graphics depend on having a decent "bcmdma.resource" implemented as to use the cpu's dma engine. The sd card driver needs to use it for transfers to/from the controller - and the gfx system needs to use it for "blitting".
# [https://github.com/aros-development-team/AROS/commit/4019d84e4975d4dad987a12d57fe108f5ac048e6 Improve the gfx driver], [ vc4gfx HIDD] add [http://dri.freedesktop.org/wiki/VC4/ Gallium3D support]
# [https://github.com/aros-development-team/AROS/commit/b13905b3e8e45b089f520b44692c81affddd066f Improve] the [https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9 sdcard] device driver - which is also pretty basic but should work with most cards, rework it to also support pci, etc. sd card interfaces on x86
# The current code using very rudimentary access to the gpio interface - so that should be implemented as some resource for other components to access, as-well as the i2c interface exposed over the gpio interface. that should have a hidd class implemented which uses the gpio resource to communicate.
Boot up
On power-up, the rpi [http://www.open.com.au/mikem/bcm2835/ BCM 2835] [https://github.com/hermanhermitage/videocoreiv VideoCore4] GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the BCM2835's VideoCoreIV GPU PROM requires a DOS-style partition table; a FAT-formatted first partition; and the freely redistributable but closed sourced Broadcom files “bootcode.bin” and “start.elf” in that partition.
The boot sequence carries out several pre-boot tasks
*On powering of the rpi, the GPU reads and executes bootcode.bin, which then loads start.elf
*The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it
*configures the memory split for the CPU and GPU
*reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings)
*loads the “kernel.img” file, again from the same partition
*activates the CPU to begin executing the loaded kernel image
The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU.
RPi uses [https://github.com/raspberrypi/firmware some closed source loaders] and at some point it loads a binary blob named "kernel.img" at 0x8000, at that point there would be a rudimentary Aros alive. If one wants to use the SD-card then there would have to be a driver for the interface and a fat filesystem handler (SD-card has to be formatted to fat filesystem)
Boot code and kernel are now linked together and made into that binary blob, just for starters. Raspberry Pi uses [http://kernelnomicon.org/?p=133 u-boot] and [http://kernelnomicon.org/?p=138 UBoot] as bootloader, there's already some code in the Efika MX port for that. UBoot is a native bootloader and not just for the raspberry pi, it loads after start.elf.
You can find Efika MX port from arch implementations, some hacking is needed for the mmakefile.src'es as iit dates back to before the Aros crosstool era or else you get some weird errors while building. You also need to code the bootstrap and serial handling.
At the moment it seems that a fastest route for the native build would be to make one binary blob without using the package system. Raspberry's memory layout is pretty simple and if the implemented u-boot doesn't support loading other modules
<pre>
? - alias for 'help'
mtest - simple RAM test
autoscr - run script from memory
base - print or set address offset
bbm - BBM sub-system
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
jade -
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv - print environment variables
rarpboot - boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saves - save S-Record file over serial line
setenv - set environment variables
sleep - delay execution for some time
tftpboot - boot image via network using TFTP protocol
USB - USB sub-system
usbboot - boot from USB device
version - print monitor version
</pre>
Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,
Framebuffer - basic display
RasPi has to speak to the "operating system" which runs on the GPU itself and request/free memory - it cant directly manage it itself, and so the managed functions were used to wrap these calls.
The Arm and GPU share memory space. The framebuffer is shared. The Arm can write a pixel and it will appear on the screen (through GPU hardware) without flushing/copying being required.
The GPU can composite multiple FB's in real time - so you have a number of surfaces defined which are rotated etc and composited in real time to the output. Copying can map from the address space of the Arm to the flat space of the GPU which takes some code, but I don't think whole buffers are copied.
The DMA hardware can also access the whole memory space and can perform 2D fills and blits (no blending). This is documented in the peripheral spec posted. The DMA is just an Arm accessible peripheral and can be set up with low latency (e.g. microseconds).
must use a 0xc0000000-based bus address to access SDRAM, yet non-DMA access should go via a 0x0-based bus address.
For 2D dma, set TDMODE, and the spec says "interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer." so set STRIDE to pitch of the image, the width is XLENGTH and height is YLENGTH. You would fill by not setting the SRC_INC and point source to your fill data.
The DMA cannot see the ARM's L1 cache, so you would map the framebuffer with ioremap_nocache. Depending on where the source data comes from, it may need an L1 cache flush. The DMA can see the L2 cache. Use 0xC0000000 bus addresses when L2 is disabled and 0x40000000 bus addresses when L2 is enabled. (actually just call virt_to_bus and you'll get the right address out).
openGLES/openVG has high latency. Writing to framebuffer then reading it back is very inefficient (e.g. milliseconds). If you can drive it a unidirectional way, just streaming commands at then that is efficient. openVG is not implemented on top of openGLES - it uses the same hardware but as a first class interface
To improve the Gfx driver, we will need a DMA resource implemented so can use to perform DMA operations. The Gfx driver will need this to perform blits.
USB
* Model A and B limited to 150 mA per port.
* Model B+ and Pi 2 introduced configurable 600 mA to 1.2 A support over all ports - anything above that requires a powered USB hub.
Implementing the hardware driver that Poseidon uses to interact with the USB components.
Have code in place to (try) and initialise the USB chipset, and configure host/device mode operation (though AFAICT Poseidon doesn't support device mode). Started to get the "virtual" root hub written for the single USB port so that Poseidon should at least list it correctly in the GUI - and try to interact with it to find peripherals.
The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”).
There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA. However, there's a Linux driver written by Synopsys ([https://github.com/raspberrypi/linux dwc_usb]). Specifically directories [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_common_port] and [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_otg].
The Synopsys code is actually under a fairly permissive licence – it's not GPL, it's similar to BSD (’don't sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code.
The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port).
Probably only need provision of relevant changes to dwc_common_port. Other things to consider....
* Provision of necessary headers to get it to compile
* Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes (multithreading) )
* Interfacing between USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start.
the Linux bits of the headers are only required for the dwc_common_port library. dwc_common_port includes a variety of crypto functions which are not used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn't going to be for plain wired USB.
Every USB driver acts as an USB hub as well in order to let Poseidon control the state of USB ports. The code there was reading status of the only USB port in Raspberry's CPU but when changing the status it erroneously deleted some of the status bits, including the port enable one. It was so because those bits in the status register are of a type Read/WriteToClear. It means, if one does not want to change their value from 1 back to 0, one has to actually write the 0 value. Very practical thing e.g. in interrupt handlers, where one reads the interrupt status register to learn what was the interrupt reason, and writes it back to the same register in order to clear the interrupts.
After fixing that code it turned out that the communication was still unsuccessful. Apparently the USB device was not understanding the host for some reason. That should not happen since the request sent was one of the standard ones implemented by virtually anything with an USB connector, assumed that Poseidon clears the data caches before forwarding the work to the USB drivers but that's the responsibility of the driver itself.
The USB device responded and acknowledged the transmission! But why were all the request sent after address change failing with timeout? They should not. Once again, address set is supported just by anything. Tried to contact the device at address 0 once again and there it was, still responding properly. The enlightenment came. The bus address for DMA transmissions was, as it is in many bare metal USB implementations, just the pure memory address of the buffer as seen by the ARM cpu. Have "prefixed" it with the real location of uncached RAM and booted AROS once again.
Trident saw this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
and this:
Product : Vendor: Vdr=0424/PID=EC00
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 255
SubClass : 0
DevProto : 1
VendorID : 1060
ProductID : 60416
DevVers : 0200
and even this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
What are these things? The first one is USB hub built in the Raspberry. Thanks to this one the Pi machines (with exception of Pi0 and computing modules) have more than just one single USB port. The second one is the network chip in raspberry, the third one is my USB SD card reader which have just connected to see what happens. AROS tried, of course, to boot from it ;)
So, the first step towards working USB is done. The control transfers are working as you can see above. Next step is to implement bulk and interrupt transfers, having the basics in place. Finally some error handling will be added and USB for Pi will be as complete as the PC version.
[http://www.raspyfi.com/raspberry-pi-usb-audio-fix/ Issue with USB Audio]
Audio
[https://github.com/raspberrypi/linux/tree/rpi-patches/sound/arm audio] and its [https://github.com/raspberrypi/firmware/issues/2 very high speed message passing interface type of thing VCHI]
The Model B+ added an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality
the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures
Analogue audio
Audio over HDMI rev 1.3 & 1.4
Ethernet
10/100 BaseT Ethernet RJ45 socket
GPIO
GPIO shouldn't be too bad but bear in mind it is already accessed in places so they would need to allocate pins etc through it (e.g. sdcard to flicker the activity light, serial debug to output data on the GPIO pins)
Probably a resource rather than a device...
Started an i2c driver that will need to allocate GPIO pins. Feel free to work on it if you are interested ;p
GPU graphics with 2D and 3D acceleration
Sadly none yet for 32bit but for 64bit...
== References ==
===Hosted===
==== Linux ====
Change lxde to another
sudo leafpad /etc/x11/xinit/xinitrc
xorg.conf
<pre>
Section "Screen"
Identifier "Default Screen"
DefaultDepth 16
SubSection "Display"
# Viewport 0 0
Depth 16
Modes "800x600"
EndSubsection
EndSection
Section "Device"
Option "Backingstore"
Identifier "Card0"
EndSection
</pre>
Will raspberrypi ARM programs run on other ARM archs and vice-versa ? If not I would like to use different cpu names for
archs which are incompatible.
All code compiled for at most armv6 with softfp float abi will work on all softfp ARM targets, including raspberry.
Code compiled for hard-float ABI will not work on any softfp target. But then, hard-float abi uses -armhf- cpu name.
keyboard or mouse not functioning or partly working
lsmod
kernel and modules (stored in /lib/modules/ get from https://github.com/raspberrypi/firmware and click on ZIP button) have to be updated simultaneously
sudo Apt-Get Update
sudo Apt-Get Install <program >
<program > cksfv joystick p7zip-full stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 libreoffice epiphany-browser xbmc
ace-of-penguins gweled black-box petris xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis xbubble eboard&xboard (freezes) bomberclone
OMXPlayer not responding or working with keyboard or no sound audio through HDMI
LXterminal—command "OMXPlayer -o hdmi %f "
hdmi issues
Setting the hdmi_force_hotplug=1 makes sure the Pi believes the monitor/TV is really there.
You might also need to set config_hdmi_boost=4 or even higher (up to 9) if your display needs a stronger signal.
If the display is a computer monitor or newer tv, use hdmi_group=1 (auto HDMI use) and if it is an older TV, try hdmi_group=2 (for DMT formats, i.e. for PC monitors) then you HAVE to "set hdmi_drive = 2 to enable HDMI output as this forces HDMI mode rather than DVI mode
Do not set hdmi_safe=1 as that overrides many of the previous options.
Using a shorter or better quality HDMI cable might help. Make sure your Pi's power supply delivers 1 A and not 500 mA.
If you see a problem with the red colour - either absent, or interference - then try a boost
composite video
changing the RCA cable, then the composite port worked out of the box
Boot it as you are doing, without HDMI. If you now plug in the HDMI, do you get the image? In other words, does the Pi think HDMI is connected even when it isn't?
Rename all the files in the first partion of the card except bootcode.bin, start.elf and fixup.dat What's the result?
Put back config.txt What's the result?
for PAL mode sdtv_mode=2
dmi_ignore_hotplug Pretends HDMI hotplug signal is not asserted so it appears a HDMI display is not attached
hdmi_ignore_hotplug=1 Use composite mode even if HDMI monitor is detected
<pre>
# NOOBS Auto-generated Settings:
#hdmi_force_hotplug=1
#config_hdmi_boost=4
#overscan_left=24
#overscan_right=24
#overscan_top=16
#overscan_bottom=16
#disable_overscan=0
start_x=1
gpu_mem=128
</pre>
tvservice -c "PAL 4:3"
<pre>
/opt/vc/bin/tvservice -s or tvservice -s
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
(native) mode 16: 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m DMT
Group DMT has 0 modes:
</pre>
sudo amixer cset numid=3 1
forces the audio to the headphone jack, even with the HDMI video output plugged in
config.txt
the hdmi_ignore_edid_audio=1 option sems relevant as it should tell ALSA that the only available audio is analog, no matter what the display says
There are several different ways that these 4 pole (ring) composite analog cables can be wired up, so some work great in some applications and can be a waste of time in others.
What is needed for the Raspberry Pi B+ and above, which like many camcorders needs the ring contact next to the base contact to be the ground.
The wiring for the 4 pole are:
TIP (LEFT AUDIO CHANNEL)
RING 1 (RIGHT AUDIO CHANNEL)
RING 2 (GROUND/EARTH)
RING 3 BASE/SLEEVE (VIDEO) YELLOW
Most Apple based Players and the Microsoft Zune (TM) are wired this way.
Most analogue camcorders are wired this way as well, where the ground in on Ring 2 will work with the Pi although you may need to swap your Video plug with the Right Audio plug.
Nearly all other MP3 players are not wired this way, the ground is on another ring ie the wrong one.
External devices
* Camera Module Omnivision ov5647 Sunny 5MP (NoIR version) V1.3 - NoIR at 850 nm, peak at 880 nm and trails off at 940 nm wavelengths
* Camera V2 Sony IMX219 V2.1 8mpixel 8MP 8megapixel - 3280 x 2464 pixels - video at 1080p30, 720p60 and 640x480p90 - wider field of view, 62 vs 54 degrees horizontally -
* Branded WIFI usb BCM43143 dongle
N.B. dreaded error after changing cameras (stupidly without turning off the power first) and lasted through several power cycles. It can be a bad 15-pin FFC ribbon cable, when swapped, camera(s) and the Pi itself are working OK. It can be an instance of a cold solder joint on the CSI connector on the pi board. the camera can be detected (that's done via I2C) but may still not be able to receive image data (done via CSI-2) if something is broken. CSI-2 is uni-directional. Control is generally done via I2C.
The CSI-2 receiver always writes to memory, not direct to the ISP. That's the way the Broadcom architecture works as it allows multipass processing easily. GPU memory is accessible from the ARM. Processing using the QPU graphics processors may be possible. currently the only supported sensor is OV5647 and IMX219. The linux drivers are all in the firmware blob, else you'd be looking at at least a man-month of work in a fully fledged imaging lab to do a decent tuning of the camera modules' ISP parameters.
Static electricity maybe an issue for the camera module and slightly less for the pi board.
* Hosted under ARM Linux which needs to be already installed [http://www.aros.org/nightly1.php current ABIv1]
Help building AROS hosted on Linux ARM
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:
<pre>
Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic':
configure: error: C compiler cannot create executables
See config.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2
</pre>
looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.
now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)
P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.
Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.
My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.
Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.
For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.
Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.
Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh
I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:
#MM- linklibs-armhd : libklibs-aeabi-arm
Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.
I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...). Smile
To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.
With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.
gu7yxejdbdh983pghp8o4w4ecdfmcgo
4655982
4655981
2026-08-01T10:59:05Z
Jeff1138
301139
4655982
wikitext
text/x-wiki
{{ArosNav}}
[[#Native]]
[[#Hosted]]
==Introduction==
The Raspberry Pi Foundation is a charity founded in May 2009 to promote the study of basic computer science in schools, and is responsible for developing a single-board computer called the Raspberry Pi.
The Foundation is supported by the University of Cambridge Computer Laboratory and Broadcom. Its aim is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing."
The original Raspberry Pi 1 Model B computer went on sale in February 2012 and set a new standard shattering the dominance of the PC in the home and education markets. Millions in the various formats, A, B, A+, B+ and Compute have since been shipped worldwide. The original concept of the Raspberry Pi was for a computer board providing Internet access with up to 1080p HD graphics at very low cost. The boards provide a platform for children and adults from any background to acquire computer science knowledge and help develop the future World-Wide-Web and all things internet (IOT hub and bridges out to home network to cloud of sensors).
Hobbyists and tech dabblers/tinkerers are the main purchases of the Pis (around half).
The rest of the sales are split between education/industrial. While the Raspberry Pi boards were designed primarily for education, they have become very popular with manufacturers of embedded systems. The Raspberry Pi Foundation has ensured backwards compatibility with each new revision. The bare-bones Compute module is aimed specifically at the OEM manufacturer.
* Pi 5 - Quad A76 and RP1 "southbridge" with VideoCore 7 4Gb 8Gb LPDDR4X
* Pi 4 - Quad A72 64bit VideoCore 6
* Pi 3 - Quad A53 [https://www.raspberrypi.com/documentation/computers/processors.html 64 bit] - VideoCore 4
* Pi 2 - Quad 32bit but more power consumed
* Model B+ - lower power usage but same speed as the original Pis
* Model A and B -
* Compute 1, 3, 4 and 5 - industrial use
<pre>
2008 Trustees collected for Foundation
2009 Charity status gained
2010
2011 First Raspberry prototypes
2012 First boards go on sale at CPC and RS. The Model A and B 700 MHz Arm11 - February 29th BCM 2835
2012 First million sold - more than the 10,000 original planned and anticipated
2013 First Alpha Experimental builds of AROS Native for the Pi
2013 Pi Trading launched making grants available, providing in house educational resources and Pi Academy for teacher training
2013 Over two million sold
2014 Over three million sold and updated Model B+ introduced that moved composite video to audio jack and same half gig of memory
2014 Pi Model A+ v1.1 - BCM2711 no ethernet and 1 usb - a little smaller -
2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit core and 32bit VideoCore IV 3d GPU with 1Gb RAM
2015 Over four million first gen pis sold
2015 Over a million pi2s sold
2015 Pi Zero BCM2835 released
2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837
2016 Passed Sinclair total number of computer lines sold - around 7 million
2016 Pi 3 Model B - Broadcom BCM2837 SOC four 64bit ARMv8 Cortex-A53 1.2GHz - 1Gb - bluetooth 4.1, Cypress CYW43438 wireless 802.11n and a dual 32bit VideoCore IV GPU
2016 Total PIs over 10 million worldwide
2016 Compute 3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage
2017 12 million pis sold in total
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 - 1Gb, wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet
2019 Over 15 million sold
2019 Pi 3 Model A with BCM2837b0 with 512Mb,
2019 Raspberry Pi Compute Module 3+ CM3+ LITE Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc
2019 Pi 4 Model B - BCM2711 quad 64bit A72 1.5GHz, VideoCore VI, AC wifi, Bluetooth 5.0, GbE, 2 micro hdmi decode up to 4K, USB-C power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram
2019 Pi 4 Model 2B - BCM2712 4 usb
2020 Raspberry Pi SC0919 Pico RP2040
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard
2020 Raspberry Pi Compute Module 4
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam
2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu
2024 Raspberry Pi Pico 2
2024 Pi 5 2GB version uses BCM2712D0
2024 Pi-500
2024 Raspberry Pi Compute Module 5
2025 Pi-500+
2026 April and May Aros 64bit fixed, added AHI audio, VC4 gfx started, usb functions added to rom
2026 June and July Aros 64bit usb2otg started, dma.resource, sdio.resource, bwfm.device wifi added
2026 Late July daily 64bit Pi3 builds start
2026 August ....
2027
2028 Pi 6
</pre>
===Good sites to visit===
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k]
*[https://github.com/raspberrypi/firmware/tree/master/https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9boot Raspberry Pi Firmware build]
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build]
*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi]
2026 [https://github.com/aros-development-team/AROS/commit/af09e634fff510918670e9f5ad6c5503727fe541 64bit build started late July]
===Native===
* 2013-03 Kalamatee starts work
* 2013-05 Work put on hiatus
* 2015-04 Work continues slowly with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb
* 2018 [https://www.patreon.com/posts/i-owe-you-some-20956961 mschulz resume with adding BE big endian support as well]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=bsek latest commits for pi 3]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=jonx latest commits for pi 4]
64bit ArmV8 builds are
The status of AROS 32bit native for RasPi was OK. System booting, USB working (although with some issues but plan to fix them). Got stuck on modifying the ABI (application binary interface) and adjusting binutils/gcc to support it wanted to have real executable files but got stuck a little. This change for the type of relocations embedded in ARM files and not sure if this very type is well supported, on the other hand without this change ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.
Old native [http://www.aros.org/nightly1.html ARMv6 32bit nightlys] and
[http://www.aros.org/snapshots1.html old linux and android hosted]
# download/checkout the source someplace, e.g. /build/AROS-Src/
# make a directory to store external sources AROS downloads, e.g. /build/Ports
# make a build directory, e.g. /build/aros-raspi-armhf
# cd into the build dir, configure, and then run make -:
<pre>
>cd /build/aros-raspi-armhf
>/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
>make
>make arosboot-raspi
</pre>
then copy the files from /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ onto an sdcard, and download/copy the Raspi firmware files onto it.
You should then be able to boot the sdcard on your RasPi.
The current W.I.P tree to svn. it can be built as follows ..
<pre>
./configure --target=raspi-armhf
make arosboot-raspi
</pre>
That will generate arosraspi.img, arosraspi.rom and config.txt in bin/raspi-arm/AROS - so either copy just those files to a fat formatted SD card (with the firmware files on), or copy the whole contents of the AROS folder.
NB - if you have a Linux/other install, backup the existing config.txt first
arosraspi.img contains the bootstrap (which has very basic mailbox code, framebuffer/gpio init, and console "emulation" via code pinched from our libbootconsole), kernel.resource, and exec.library
arosraspi.rom contains all the other components needed to boot AROS.
The config.txt file will tell the RasPI bootstrap to load our arosraspi kernel and ramdisk (rom).
the bootstrap has minimal mailbox code, planning on adding either a resource or library that driver/app code will use to access it (likewise for GPIO)
==== Hosted ====
Ubuntu VM approach to compiling [http://lallafa.de/blog/2013/06/building-aros-hosted-for-raspbian/ Linux hosted AROS June 04, 2013]
../AROS/configure --target=linux-armhf --enable-includes=/usr/arm-linux-gnueabihf/include --x-includes=/usr/arm-linux-gnueabihf/include --x-libraries=/usr/arm-linux-gnueabihf/lib
arm-elf- is symbol-linked to arm-linux-gnueabi- (arm-linux-gnueabi- is more correct in this case, because it's going to be compiling the ARM AROSBootstrap for ARM Linux)
*armel - many of the "android" machines require since the entire OS is made for soft float VFP.
*armfp - Efika MX target, Raspberry PI, EfikaMX, Pandora and virtually everything (VFP)
Keep in mind it's possible to start hardfp AROS hosted on softfp system, though, as long as no calls between AROS and host require floating point parameters. NOTE: hardfloat objects *cannot* be linked with softfloat objects - they have a different ABI.
Just keep in mind the arm nightly build machine is quite complex beast. It needs the x86_64 host compiler to compile AROS tools. The arm version is built every night using gcc-4.6.2 crosscompiler (built together with AROS) and successfully builds armel and armhf linux hosted targets.
*needs an AROS code compiler for ARM target
*as well as unix compiler for ARM linux host (would be best to have both softfp and armhf, we have softfp only now) with full set of libraries and includes.
with—disable-crosstools $AROS_CC is always a wrapper around $KERNEL_CC ? If so, this is wrong for some ports. This can break Darwin, Windows and Android port.
Yes, Android port will build. And even work. But it's not good because the port will not be ABI-compatible with other ARM ports. Android's ABI is different from GNUEABI. For example:
<pre>
enum test {foo, bar};
enum test testvar;
</pre>
siseof(testvar) will be equal to sizeof(int) in GNUEABI (Linux and AROS) and sizeof(short) on Android. This affects linking objects from static linklibs, for example.
Previously everything worked because $AROS_CC was a wrapper on top of $HOST_CC. And a real crosscompiler was used on non-ELF hosts.
Android is the same. $KERNEL_CC is incompatible with AROS.
compiler=kernel is appropriate _ONLY FOR CODE WHICH RUNS ON HOST OS_ (or barebone hardware, if we talk about native). This includes bootstraps, their linklibs, and host-side dynamic libraries (Windows makes extensive use of them because of architectural considerations.
No single AROS object should be compiled with this setting. $KERNEL_CC is really compatible with AROS *ONLY IN LINUX-HOSTED* and no more. On other systems (Darwin, Windows, Android) this is not true any more, and compiler=kernel is never going to work.
If you want to compile your AROS module against host OS includes, append the following to USER_INCLUDES (or USER_CFLAGS, this is effectively the same):
-isystem $(GENINCDIR) $(KERNEL_INCLUDES)
$(KERNEL_INCLUDES) expands to:
-isystem <your_os_includes> -isystem <host_OS_gcc_private_includes>
-nostdinc
This makes AROS compiler adhering to host OS APIs.
If you want some preprocessor symbols based on what your host OS actually is, add something like -DHOST_OS_$(AROS_HOST_ARCH).
Why is there $(GENINCDIR) at all? Because host OS has its own libc includes, which would conflict with AROS ones. And the host OS libc is not binary-compatible with AROS one.
Why doesn't Windows-hosted port use $(KERNEL_INCLUDES) ? Because WinAPI includes conflict with AROS ones in fundamental typedefs, like WORD, BYTE and BOOL. It's almost impossible to deal with this in any other way than rewriting WinAPI definitions using AROS types.
Building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. haven't yet committed the necessary changes but "./configure --target=raspi-armhf" is enough to start, then "make arosboot-raspi" will generate arosraspi.img (containing the bootstrap, kernel.resource, and exec.library) as well as arosraspi.rom (containing all the other essentials components such as dos, graphics etc). It will also copy over a config.txt file to make the raspi bootstrap code load the correct kernel, and a cmdline.txt that enables exec debug output.
*armel = typically Debian 6, Ubuntu Maverick, Android,
*armhf = typically Debian 7, Debian 8, Ubuntu Precise,
Cross-compiling Ubuntu ARM softfp
<pre>
sudo sh
echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
</pre>
<pre>
./configure --target=linux-arm --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabi/include
</pre>
Cross-compiling Ubuntu ARM hard-float
<pre>
sudo sh
echo 'foreign-architecture armhf' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armhf.list
apt-get update
apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
</pre>
<pre>
./configure --target=linux-armhf --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabihf/include
</pre>
Now, the AROS build is configured properly and all you need to do is:
make
[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]
== Hardware ==
===64bit===
====BCM2712====
BCM2837
* Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support, 3B+ [https://github.com/aros-development-team/AROS/commit/afa5bc0bb17d5dd06bcfdbac00853a3799ca8d76 LAN7515]
====BCM2711====
===32bit===
=== Core Kernel ===
the reason behind INTB_KERNEL is to allow use of the standard Exec function AddIntServer() to add interrupt handlers for
hardware drivers etc. AmigaOS never used it for abstract hardware drivers. AmigaOS routed only raw hardware IRQs there. Their assignment was hardcoded. As well as number of them. Actually on AmigaOS every bus has its own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt. 1:1 relationship between CPU and hardware interrupts is present only on PC.
IMHO we miss things like AddInterrupt/RemInterrupt methods on our PCI subsystem's device class. PCI bus class should map these methods to whatever is appropriate. This is how it is done on AmigaOS and friends. When these are implemented, raw kernel.resource API will be needed only for several PC-specific drivers with hardwired resources. Exec IRQs are real IRQs only on Amiga hardware. On other machines they can be emulated where appropriate (VBlank is a good example). kernel.resource is meant to be different, its IRQs are hardware-agnostic, they are plain "Hardware IRQ number X, whatever this means". They are low-level actually, and meaningful only in the context of a particular system.
Was that not the transition from irq.hidd to kernel.resource? No. A long time ago there was another hacky bit named INTB_TIMERTICK. It was "abstract timer interrupt", used by timer.device. It was the same as VBlank, but with larger frequency. I removed it, because kernel.resource API was a cleaner way to access this interrupt. Furthermore, there can be more than one timer in the system. I am even thinking about bringing back timer HIDD definitions again. hpet.resource is a bad idea.
Can someone please enlighten me a little on how the scheduler is meant to work?
Poseidon.library creates its "Poseidon Event Task" during RTF_COLDSTART -> then calls Wait(), and ends up in limbo because wait disables interrupts (used for the scheduler heartbeat), and basically waits forever because the sigbit is never set, since krnSwitch doesn't switch the task unless TF_SWITCH is set, and no codepath run during this seems to set it?? TF_SWITCH does not disable/enable switching. This flag just enables to run user-supplied hook when the task is being switched away. It is completely safe to call Wait() in Disable()d state. Doing this actually temporarily breaks this state. IDNestCnt gets remembered in struct Task, then next task is selected, and its IDNestCnt is restored in sysbase (see kernel_scheduler.c). If there are no other tasks, then your cpu_Dispatch() should enable interrupts on the CPU and enter idle mode. See x86 implementation for good example.
You miss what happens next...
1. KrnSwitch() saves context of your task, saves IDNestCnt (core_Switch() and cpu_Switch()), then drops into cpu_Dispatch().
2. cpu_Dispatch() calls core_Dispatch. Then two cases are possible:
2a. There is a READY task. It is picked up, its IDNestCnt is restored in SysBase, then cpu_Dispatch() needs to restore registers and exit. The next task is run.
2b. There are no READY tasks. core_Dispatch() returns NULL. In this case your cpu_Dispatch() should enter idle loop. It should just enable interrupts on the CPU and put it on halt. This allows it to process hardware interrupts. Eventually some of your interrupt handlers wakes up your task and puts it into READY list.
My heartbeat interrupt has been slowed atm to help debugging - but it never actually gets a chance to fire because of the Wait() disabling interrupts. Perhaps you have forgotten to enable interrupts in your idle loop.
There is a change in the format of AROS executables. Until now we were using Elf RELocable files which are usually used as intermediate object files. We had them for various reasons, one of them was how AROS files were built in the past. That days we had no real aros cross compiler and the option to embed relocation data in unix executables (or in executable files in general) was rather new and not every linux/unix system had it. Therefore we have decided to use intermediate files. Although it was somehow working (and it is still working :-)), it has some drawbacks. Therefore decided to introduce real Elf EXEC types, in first turn implemented on ARM target with option to expand in future to all other AROS architectures.
The first patch was pretty easy and appeared to work somehow. It generated nice executables with embedded relocation info. Not only that, it also removed all global symbols adjusting relocation data to be relative to the beginning of the sections. That move reduced number of symbols in each executable significantly (depending on the file between 20 and 80% of all symbols could be removed). The only symbols that stayed in the file are local ones - due to the nature of the patch wasn't able to remove them since we have not seen them in the symbol hash table.
The patch didn't worked though. The files were relocated, AROS kernel loaded, but it crashed very early. What happened? Well, the nature of ARM relocations happened :)
Most of the relocation data on all machines is rather simple. Relocation can be absolute or pc-relative, sometimes the offset has to be bit shifted. On ARM v7 there is another one. There, when one wants to load an address of function/variable into register a combination of two instructions can be used: movw and movt. The first one loads immediate into lower 16 bits of a register while clearing upper 16 bits. The second one loads immediate into upper 16 bits without touching lower halfword. Loading of a pointer into a register looks like this:
movw r0, #:lower16:label
movt r0, #:upper16:label
In this case there are two relocations - one for lower halfword and another for upper. If an overflow of lower 16 bits occurs during relocation process, the upper one should be updated as well. Unfortunately with current patch and with typical ARM executables there is not enough information to perform the calculations.
There are two options - the first one would be to give up and go back to "fake" executables, another one would be to change from REL to RELA relocation info. The latter contains an addend, extra data which can be used to perform all the relocation calculations I need.
Decided for the second option. The patch is already in the works. There is another function for the binutils' bfd backend to perform the final relocation. There can decide what to do with every reloc info, modify data and eventually strip some symbols. An advantage is - at this stage of the linking process have also full access to all local symbols so can change all relocations section relative and eventually strip all symbols from the files.
=== GPU ===
Most of start.elf runs on the GPU. Placing ALL the userland GPU code in the videocore.hidd isn't going to be a terribly big problem because the code they published is nothing more than a shim that sends data straight to the GPU to execute.
The good news about this is that we only need to write our HIDD using the OpenVG API. The shim is relatively small codewise and lives in the ARM memory (the actual OpenVG code itself lives in the GPU RAM area and its loaded from start.elf). That's also the bad news. Our driver has to translate AROS video calls to OpenVG calls, for most tasks it should be easy, for some, not so much. It's still probably less difficult and less work, than controlling the GPU directly.
The other good news is that anything done through OpenVG happens on the GPU, its truly accelerated. It also has some nice font functions, meaning we can lead into an accelerated text mode later.
Basically, AROS resets or locks up when it tries to use AROS_ATOMIC_INC or DEC. If I comment out the byte/word operations in the header files and use non-atomic operations, the code works as expected.
have read that the L1 cache needs to be enabled to use LDREX and co (which I also read is only meant to be used on multi processor systems with shared memory) - however I am certain this is correctly enabled.
If you are using LREX or STREX, you should have L1 cache enabled, at least on the ARM CPU I work with at work.
L1 cache is enabled by enabling the MMU *AND* setting the C and I bits in the CPU - the C bit is ignored, and the I bit only covers the 16 byte instruction pipeline if the MMU is not enabled.
Can you verify that your assembly is generating LDREX/STREX? From the behavior, it almost sounds like its generating the default Semaphore locked atomics.
Impossible. There are no semaphore-locked atomics. There are Disable()/Enable()-based ones instead. And there's a special #define AROS_NO_ATOMIC_OPERATIONS in this case, which tweaks Disable()/Enable() implementations not to recurse forever.
I have tested this on ARMv5 which does not have ldrex/strex, it works fine. On those ARMs there's no way to have real atomics. On other OSes (like Linux) this is done by introducing things like atomic_t, which appears to be a complex structure, holding the value together with accompanying spinlock (implemented using swp).
#warning "TODO: lookup optimal mmu table settings for raspi memory"
/* Set up an identity-mapping for all 4GB */
for(x = 0; x < 4096; x ++)
{
pagetable[x] = x<<20 | (0x40002|0x80000|0x010000|0x00C00|0x04);
}
Shouldn't there be a second loop that sets the 'C' bit in the descriptor for the RAM pages?
Currently, you have TEX=0, C=0, B=1 for all pages (Shared Device).
You should have TEX=0, C=1, B=0 for RAM (Write-Through, Cached)
So ..
pagetable[x] = x<<20 | 2;
should be enough?
No, for RAM you need to change the '| 0x40' to '| 0x80'
tell dosboot the correct defaults to use
Please don't do this. This bootconfig.c is a deprecated legacy thing. I wanted it to go away completely with time. Instead, display drivers should auto-install themselves during own initialization phase. I. e. detect hardware=>instantiate itself. This should make things way simpler. With this approach you only need to add the driver into KS image to get the device autobooted. No
hardcoded stuff.
Currently VESA and VGA drivers do this, look there for examples. never rewrote ATI driver because i don't have any test system for it.
they defined a smaller AROSCPUContext than the ExceptionContext - yet reference it as ExceptionContext in other places, and since it hasn't allocated enough storage for ExceptionContext, are corrupting memory/the structure (since the elements that are there don't map 1 to 1 with the exception context).
AFAIK, AROS has been moving in a different direction to this in recent
years. It is the job of graphics HIDDs to allocate bitmaps etc. so that
they have the most suitable characteristics, including allocating them
from GPU RAM where possible. The concept of chip RAM is only for legacy
code, and most if not all non-68k platforms should have all system RAM
marked as chip.
BTW, is the video processing code you mention CPU code or GPU code?
Also, IIRC we have support for "external memory allocators". Perhaps that's what we need for the allocation of GPU RAM through the mailbox.
All hosted and x86 native ports should use proper context formats.
trying to clarify if the vblank handler has to have run by this point to prevent this deadlock. Actually, no. Unless you have installed VBlank handler which should wake up at some point. Without VBlank there will be no quantum count. Consequently, there will be no forced preemption. But the rest will work, and multitasking will be cooperative (switch happens only when current task voluntarily gives up the CPU). Does it depend on the vblank having run before this point? and if yes what does that mean on systems where it might be able to run enough code (e.g. get to this point) before the vblank interrupt has triggered? What is it waiting for? It could wait for timer, in this case you need timer.device working. VBlank is currently needed for exec's quantum counter. In current native ports we have only a single timer, which is served by timer.device. VBlank is simulated by timer.device also. If your machine has two timers, then you can use one of them for VBlank, and another for timer.device, this will simplify things down. VBlank needs to be 50 Hz for historical reasons, many programs use it as cheap timer. I am periodically thinking about making some abstract mechanism to be able to change quantum source (and untie it from 50 Hz), but have no time to come up with something good. Additionally i started disliking timer.device hardcoded design when PC has got many timers (old 8253, APIC, HPET).
Currently i think there should be some low-level entity representing tick source. timer.device should just select the most appropriate source for its units.
The BCM2835 has 4 GPU based timer sources - 2 are used by the GPU, so im using Timer3 for our heartbeat and the remaining one will be free to the system. There is also the less capable ARM timer but that is dependent on the CPU frequency. Very good. You won't need any emulation. Set the heartbeat to 50 Hz and drive VBlank from it. Use other timer for MicroHZ.
Can you use the 'econsole.hook' I make for debugging the Sam460 via the serial port?
It provides a before-anything-else shell prompt on the serial port. You can then do 'NewCLI' to test your graphics, or use any DOS command in shellcommands.resource.
You should just be able to add econsole.hook to your module list, and use 'econsole' in your bootargs.
So long as you have a working Exec/RawMayGetChar and Exec/RawPutChar, it should work.
Also make sure to add shell.resource and shellcommands.resource for this.
That should have done it.
If you set "#define DEBUG 1" in arch/all-native/econsole/econsole.c, do you get any additional serial output?
have added it to the build and added econsole to the command line - and can see the bootloader picks up on the emergency bootconsole tag, but I still only get the insert bootable media display?
Im assuming it exposes a fake filesystem that tricks aros into booting?
The contents of which are: ECON:AROS.boot
Way to handle the scheduling code? The implementations I had been following were causing problems, due to cascading interrupts which I cant handle properly in the asm stubs just now (when they break disable etc.) - since it means detecting the interrupted codes cpu mode and getting the correct sp/lr for it, and that's just too tedious for arm.
To work around this ive added a system idle task which does nothing - and when the scheduling code has no task to run switches this in and lets it run, thereby allowing the interrupts etc to resume until something does need to happen.
Also, by adding accounting code to cpu_Switch() and cpu_Dispatch(), it should allow the system to log idle time correctly (as well as running tasks).
have thought of also adding an additional task that never runs, solely to record time spent in IRQ handlers, but I digress..
was under the impression that kernel.resource should *never* be used outside of exec.library. This is a wrong impression.
Michal started designing it because portable nature of AROS does not fit well into exec's API with all its assumptions. So, he started the new, hardware-agnostic kernel API from scratch. Yes, exec sits on top of it in places. But kernel always meant to be open thing. Otherwise it would not exist.
it wasn't meant to be just used willy nilly by user code - but by lower system components (e.g. exec) so that they could be implemented in a more generic fashion, and the kernel resource itself hide the systems quirks.
Adding new things there perfectly keeps up with our decision to minimize AROS-specific intervention into APIs which can clash with MorphOS/OS4 extensions. We want at least source-level compatibility there. Binary compatibility on PPC would be extremely cool, but at the other hand we have no maintainer for this, as well as their ABIs are a bit weird and far from optimal, especially MorphOS one, because it aims for m68k binary compatibility.
It depends on what exactly is being implemented - there's no reason we should have everything crammed into kernel.resource if it doesn't need to be (i.e. if its better suited as a separate component/subsystem in its own right)
The _LE versions are for when you have endian swapping taking place. If the graphics are the same endian as the CPU, no swapping should occur. I ran into a similar terminology problem in SDL with a friend insisting that his Radeon 7000 on his PC was big-endian. It is not, it just uses the same endianness for the graphics card and the CPU so no swapping was necessary. They were both little-endian.
The _LE versions are because the PixFmts refer to the bitmap data being in big endian format in memory, for which the normal version would need to do endianness conversion before applying the shifts/masks. on this platform it is in _LE in memory also so we don't need the conversion hence using the _LE version of the call). would use _LE (if it's really little endian 16 bit mode).
What is the bare minimum needed to implement a framebuffer based gfx driver, with our software handling the rest?
I have tried with just a gfx class that only expose new/dispose/newbitmap - and having an onscreenbitmap used only for the framebuffer itself (with all other bitmaps being chunkybm, and the framebuffer's superclass also being chunkybm), but that alone isn't enough it seems?
You can use workbench/hidds/sm502/ as your example - it is as simple as I could make it.
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
I so far have -:
vc_init: queries the gpus memory, and sets up a fake memory handler for it, then adds the bootmode driver and returns saying all is well
vc_gfxhidd:New: sets up some fake syncmodes to test with and creates the real gfx object.
vc_gfxhidd:NewBitmap: checks if its a framebuffer and uses the onbitmap class or uses the chunkybm class otherwise
vc_onbitmap:New; creates a chunkybm object and then pushes the real framebuffer address into it as the buffer,
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
The code I currently have on SVN seems to create the framebuffers bitmap object fine, but then crashes in intuitions DisplayDriver callback. In particular it crashes performing the getattr on the system default pointer.
don't expose MEMF_CHIP in an allocatable form so AllocSpriteData was failing (and other code later doesn't check if the values are valid == illegal memory accesses)
Actually MEMF_CHIP has to present, for historical reasons.
This has been never fully agreed upon, but in ports i wrote i exposed the whole memory as MEMF_CHIP. The idea behind this is that CHIP is originally the memory where graphics and sound data can be put. On non-Amiga platforms there are no restrictions on this, so the whole memory is CHIP.
Yes, many old software can misbehave with CHIP memory size larger than 2MB. But this actually applies only to m68k AROS which is going to run m68k binaries. In other cases it's quite logical to fix the program when porting.
As to original question: yes, it's enough to have a framebuffer bitmap (one with aoHidd_BitMap_FrameBuffer set to TRUE) and PutPixel routine. It framebuffer can be served by chunky bitmap class, then you can simply create chunky bitmap with your own buffer (see how VESA driver does this). Chunky PutPixel is already there.
struggling to determine what is the correct pixfmt to use for the 24/16/15 bit gfx modes on the RasPi. AFAIK it uses RGB565, for 16bit but im unsure what shifts etc should go with it? suffice to say Im getting the wrong colors so far lol.
<pre>
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0
redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
</pre>
It should likely be vHidd_StdPixFmt_RGB16_LE
This stuff is a bit confusing. The "names" of the stdpixfmts are based on the layout in memory,
ignoring endianess. So for example:
ARGB32: will be 0xAA 0xRR 0xGG 0xBB in memory on both big endian and little endian machines.
The shifts and masks OTOH are based on pixel access (ULONG in this case), so differ depending
on whether you run on big endian machine or little endian machine (that's why there's stdpixfmt_le.h and
stdpixfmt_be.h in rom/hidds/graphics/).
With the 16 bit pixel format it's even more confusing, as for example it's impossible on little endian machine
to describe RGB16 with shifts/masks alone. That's why there's vHidd_PixFmt_SwapPixelBytes_Flag.
(RGB16 == RRRRRGGG GGGBBBBB in memory, and for pixel (WORD) access on little endian machine it needs to
be accessed as GGGBBBBBRRRRRGGGG).
The shifts btw indicate how much to shift the component to the left (!) so that it is moved to the highest bit (31).
The aHidd_PixFmt_StdPixFmt you specify will be ignored most of the time, because when the pixelfmt is registered,
the gfx hidd checks if there's an identical pixfmt (shifts/masks/etc., but ignoring pixfmt->stdpixfmt) already in the system,
and if so, it uses the already existing one and does not create a new one.
In theory it would be better if gfx drivers could simply/only specify a StdPixFmt without all the shifts/masks stuff when the
gfx driver uses pixfmt which matches one of the stdpixfmts exactly. Another possibility would be for gfx drivers to use
HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) and then peek shifts/masks from it and fill out a pixfmt
tag list based on that.
15bit very blue/green: Try to pass same shifts/masks/etc. as in 16 bit pixfmt (maybe you think it's using 15 bit R5G5B5
(or swapped) but it's actually still using 16 bit R5G6B5 (or swapped).
aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count.
But I would still pass the correct one (_LE) == whatever rom/hidds/graphics/stdpixfmts_??.h uses
in the entry where you have looked up shifts/masks/etc.
Use the shifts/masks/etc. from the entry in stdpixfmt_le.h (if you are running on little endian machine) or stdpixfmt_be.h (if you
are running on little endian machine) that matches the pixfmt that its meant to be.
0xAA,0xRR,0xGG,0xBB on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)
0xAA,0xRR,0xGG,0xBB on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_BGRA32)
it feels like AROS trashes the alpha component, otherwise it should be 8A8R8G8B.
read on the subject suggest its in 1x5r5g5b (x is ignored) to keep 16bit alignment .
What I see on screen suggests to me that wrong shift/mask are being applied - however going by the 16bit versions it all looks correct to me so I am really confused as to what is happening.
The output image looks to have too much green/blue, and very weak red.
Why did usbromstartup become HW-specific ?
In the past i have done a big job separating kickstart into several parts. I have never got any responses, so i re-describe my idea.
For now it loads the hs otg chipset driver ..
The idea is to minimize amount of archirecture-specific modules to
make user's life easier. So, the kickstart was split into 'base'
(which does not contain anything machine-specific) and 'BSP' (Board
Support Package) which contains all hardware-specific stuff.
This way, for example, distribution makers can save up space on CD
and make CDs with multiple platform support. Different configuration
would load the same base with different BSP's.
Next there was some part which is entirely missing on hosted. These
are filesystems. Hosted ports do not need them to boot up, so on
hosted they are left out. At the other hand, they are also
architecture-agnostic. So i put them into 'FS' package (standing for
'filesystem').
Poseidon is one more big part. I made it into separate package in
order to allow users to omit it if they don't need it (for example, to
run on retro PCs without USB). Personally i have one. Again, Poseidon
is hardware-agnostic (well, there are USB drivers but HCIs are pretty
standard).
It's mandatory on PI since there are no other interface types - so being a separate package is irrelevant/pointless.
Is Raspberry's USB controller non-HCI compliant? Actually i expect it to be compliant, then wouldn't it be better to make existing drivers discovering them?
AFAIK its HCI 1.0 compliant but I'm not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once i'm more familiar with the workings I can merge in the changes needed to get it operating but for now I will focus on getting it running. Also our drivers have known issues so perhaps a fresh set of eyes might shed some light on what is going wrong.
Another interesting question is whether Poseidon can operate on device side. Is it flexible enough? How similar is being a USB host and USB device? think it will need a bit of work on Poseidon's side. Until then I will force the driver into Host/Master mode in the init code, but leave open device etc to configure the chipset for either's use - and look at trying to add support for working in Device/Slave mode & switching modes once it's up and running.
Actually USBROMStartup is some kind of kludge. Can there be any alternative? Could device drivers be self-installing, like our HIDDs? This would get rid of need to list them in USBRomStartup.
And there is one more thing about modular ports. In order to actually implement this, your bootstrapping environment should provide the ability to load several files. On PC this is provided by GRUB2. on CHRP you can read filesystem via OpenFirmware, and Sam's Parthenope relies on modified u-boot. If your bootstrap allows to load only a single file, then you stuck with monolithic kickstart. By the way... u-boot allows not only to boot up a single uImage or zImage, it also allows to write client programs AFAIK. With this approach, you actually can write modular bootstrap for ARM AROS using unmodified u-boot.
[http://repo.or.cz/w/AROS.git/commit/e7bdc7e7b7f12b07aa24c739abb63721a872a53a arasan eMMC sdcard controller specific header which is not USB] and [http://repo.or.cz/w/AROS.git/commit/8bd19674084526a534ac11f7d4c51932e9ffe3d2 added prelim sdcard device]. [http://repo.or.cz/w/AROS.git/commit/9ab8217f61911fb8b7fd41bee46a992b4668ced1 do not set 4bit data mode, or enable acmd12/dma int's]
====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM)
*Framebuffer (fb) using mailbox
*IRQ scheduler, etc
*Arasan based SD Card controller
*Synopsis DesignWare USB 2.0 OTG controller [http://networkdirection.net/index.php?option=com_content&view=article&id=106:rasperry-pi-usb-controller&catid=45:raspberry-pi&Itemid=54 Unofficial DOCS pdf], [dwc_otg.c FreeBSD], [], [https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/Controllers/DWCDriver/ RiscOS USB Driver], [https://www.riscosopen.org/forum/forums/5/topics/878 RiscOS USB Discussion], [https://www.riscosopen.org/forum/forums/11/topics/1893 Other USB RiscOS], [http://plan9.bell-labs.com/plan9/index.html Plan9 Miller's usb] http://plan9.bell-labs.com/sources/contrib/miller/, [https://github.com/Chadderz121/csud CSUD driver],
*[http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf SMSC 9512] USB LAN/Hub chip
*CMOS RAM
*VCHIQ port which sends messages to the GPU e.g. for mouse, keyboard, audio on HDMI, etc
*Audio Driver
*Serial Peripheral Interface Bus (SPI)
*[http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/ I2C registers]
*I2S
*Universal Asynchronous Receiver Transmitter (UART)
*[http://elinux.org/RPi_BCM2835_GPIOs GPIOs] and [http://www.adafruit.com/blog/2012/08/17/broadcom-bcm2835-peripheral-memory-map-and-gpio-alternate-use-chart-piday-raspberrypi-raspberry_pi/ Alternative view of GPIO]
BCM2836
* For Pi B+, PI 2 and Pi 3 SMSC LAN9514 chip adding 10/100 Ethernet connectivity and four USB channels to the board
The overclock ability has diminished with each chip version as the energy usage has very slowly risen. BCM2837 is one of the warmest yet and might benefit from active cooling (ie fan) if all four cpu cores are in use for a short while. Video playback is not affected due to the custom support in the GPU. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur.
*[http://www.andrewscheller.co.uk/rpi_pcb_modules.html PCB], [http://elinux.org/RPi_Low-level_peripherals Low level features],
Implemented so far...
# Modify the configure system so that it correctly builds for the arm hardware float raspi target.
# Implemented the bootstrap to load the aros modules and prepare the arm to jump into them. Reworked the x86 console support so that parts can be stolen for raspi to use since t has no basic functionality to output to the display.
# Implemented a kernel.resource to prepare the raspi for running aros and provide the low level api calls to expose available resources and allow exec, etc function.
# Implemented serial debug support
# Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc)
# Implemented a timer.device to utilise the hardware timers.
# Implemented a very basic gfx driver to expose the hardware's framebuffer.
# Implemented an SD-Card driver for AROS which presently only supports the raspi's chipset but can easily be modified to support all sd-card hardware and media.
# Fixed the fat filesystem support in AROS so that it can boot on RasPi's normal SD-Card setup. The "rom" image files needed use a different filename than the default linux, etc images so can be easily installed without harming the existing files - you only need to change the loaded images in the config file to get aros to boot.
# Updated the build scripts to automatically download the necessary raspi firmware files and wrap it all up so that you can simply extract the archive to a fat formatted sdcard and boot it on the raspi without having to get anything else.
# fix everything in contrib and ports to build for raspi (needs proper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi ..
Improvements...
# Implement a USB chipset driver "OR" finish the existing one [https://github.com/aros-development-team/AROS/commit/c07d13c724f944674be5db54fc6a71ee72a01809 usb otg] - the current code is mostly a skeleton that should initialise the chipset and then needs relevant code to support the different transfer types. It also has the "virtual" hub code in place to represent the raspi's USB port (from poseidons p.o.v)
# Implement a driver for the USB NIC (a few weeks - depends on USB above)
# Write an [https://github.com/aros-development-team/AROS/commit/d55d0f74d20b769bbb8c8d386e5c1d7a9154f05a audio driver] (a few weeks - independent of USB) and [https://github.com/aros-development-team/AROS/commit/e93a4c245f27a87c9c4c1d39206694b39059998a HDMI]
# fix syscall bug in the current raspi kernel code
# Graphics depend on having a decent "bcmdma.resource" implemented as to use the cpu's dma engine. The sd card driver needs to use it for transfers to/from the controller - and the gfx system needs to use it for "blitting".
# [https://github.com/aros-development-team/AROS/commit/4019d84e4975d4dad987a12d57fe108f5ac048e6 Improve the gfx driver], [ vc4gfx HIDD] add [http://dri.freedesktop.org/wiki/VC4/ Gallium3D support]
# [https://github.com/aros-development-team/AROS/commit/b13905b3e8e45b089f520b44692c81affddd066f Improve] the [https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9 sdcard] device driver - which is also pretty basic but should work with most cards, rework it to also support pci, etc. sd card interfaces on x86
# The current code using very rudimentary access to the gpio interface - so that should be implemented as some resource for other components to access, as-well as the i2c interface exposed over the gpio interface. that should have a hidd class implemented which uses the gpio resource to communicate.
Boot up
On power-up, the rpi [http://www.open.com.au/mikem/bcm2835/ BCM 2835] [https://github.com/hermanhermitage/videocoreiv VideoCore4] GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the BCM2835's VideoCoreIV GPU PROM requires a DOS-style partition table; a FAT-formatted first partition; and the freely redistributable but closed sourced Broadcom files “bootcode.bin” and “start.elf” in that partition.
The boot sequence carries out several pre-boot tasks
*On powering of the rpi, the GPU reads and executes bootcode.bin, which then loads start.elf
*The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it
*configures the memory split for the CPU and GPU
*reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings)
*loads the “kernel.img” file, again from the same partition
*activates the CPU to begin executing the loaded kernel image
The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU.
RPi uses [https://github.com/raspberrypi/firmware some closed source loaders] and at some point it loads a binary blob named "kernel.img" at 0x8000, at that point there would be a rudimentary Aros alive. If one wants to use the SD-card then there would have to be a driver for the interface and a fat filesystem handler (SD-card has to be formatted to fat filesystem)
Boot code and kernel are now linked together and made into that binary blob, just for starters. Raspberry Pi uses [http://kernelnomicon.org/?p=133 u-boot] and [http://kernelnomicon.org/?p=138 UBoot] as bootloader, there's already some code in the Efika MX port for that. UBoot is a native bootloader and not just for the raspberry pi, it loads after start.elf.
You can find Efika MX port from arch implementations, some hacking is needed for the mmakefile.src'es as iit dates back to before the Aros crosstool era or else you get some weird errors while building. You also need to code the bootstrap and serial handling.
At the moment it seems that a fastest route for the native build would be to make one binary blob without using the package system. Raspberry's memory layout is pretty simple and if the implemented u-boot doesn't support loading other modules
<pre>
? - alias for 'help'
mtest - simple RAM test
autoscr - run script from memory
base - print or set address offset
bbm - BBM sub-system
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
jade -
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv - print environment variables
rarpboot - boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saves - save S-Record file over serial line
setenv - set environment variables
sleep - delay execution for some time
tftpboot - boot image via network using TFTP protocol
USB - USB sub-system
usbboot - boot from USB device
version - print monitor version
</pre>
Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,
Framebuffer - basic display
RasPi has to speak to the "operating system" which runs on the GPU itself and request/free memory - it cant directly manage it itself, and so the managed functions were used to wrap these calls.
The Arm and GPU share memory space. The framebuffer is shared. The Arm can write a pixel and it will appear on the screen (through GPU hardware) without flushing/copying being required.
The GPU can composite multiple FB's in real time - so you have a number of surfaces defined which are rotated etc and composited in real time to the output. Copying can map from the address space of the Arm to the flat space of the GPU which takes some code, but I don't think whole buffers are copied.
The DMA hardware can also access the whole memory space and can perform 2D fills and blits (no blending). This is documented in the peripheral spec posted. The DMA is just an Arm accessible peripheral and can be set up with low latency (e.g. microseconds).
must use a 0xc0000000-based bus address to access SDRAM, yet non-DMA access should go via a 0x0-based bus address.
For 2D dma, set TDMODE, and the spec says "interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer." so set STRIDE to pitch of the image, the width is XLENGTH and height is YLENGTH. You would fill by not setting the SRC_INC and point source to your fill data.
The DMA cannot see the ARM's L1 cache, so you would map the framebuffer with ioremap_nocache. Depending on where the source data comes from, it may need an L1 cache flush. The DMA can see the L2 cache. Use 0xC0000000 bus addresses when L2 is disabled and 0x40000000 bus addresses when L2 is enabled. (actually just call virt_to_bus and you'll get the right address out).
openGLES/openVG has high latency. Writing to framebuffer then reading it back is very inefficient (e.g. milliseconds). If you can drive it a unidirectional way, just streaming commands at then that is efficient. openVG is not implemented on top of openGLES - it uses the same hardware but as a first class interface
To improve the Gfx driver, we will need a DMA resource implemented so can use to perform DMA operations. The Gfx driver will need this to perform blits.
USB
* Model A and B limited to 150 mA per port.
* Model B+ and Pi 2 introduced configurable 600 mA to 1.2 A support over all ports - anything above that requires a powered USB hub.
Implementing the hardware driver that Poseidon uses to interact with the USB components.
Have code in place to (try) and initialise the USB chipset, and configure host/device mode operation (though AFAICT Poseidon doesn't support device mode). Started to get the "virtual" root hub written for the single USB port so that Poseidon should at least list it correctly in the GUI - and try to interact with it to find peripherals.
The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”).
There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA. However, there's a Linux driver written by Synopsys ([https://github.com/raspberrypi/linux dwc_usb]). Specifically directories [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_common_port] and [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_otg].
The Synopsys code is actually under a fairly permissive licence – it's not GPL, it's similar to BSD (’don't sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code.
The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port).
Probably only need provision of relevant changes to dwc_common_port. Other things to consider....
* Provision of necessary headers to get it to compile
* Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes (multithreading) )
* Interfacing between USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start.
the Linux bits of the headers are only required for the dwc_common_port library. dwc_common_port includes a variety of crypto functions which are not used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn't going to be for plain wired USB.
Every USB driver acts as an USB hub as well in order to let Poseidon control the state of USB ports. The code there was reading status of the only USB port in Raspberry's CPU but when changing the status it erroneously deleted some of the status bits, including the port enable one. It was so because those bits in the status register are of a type Read/WriteToClear. It means, if one does not want to change their value from 1 back to 0, one has to actually write the 0 value. Very practical thing e.g. in interrupt handlers, where one reads the interrupt status register to learn what was the interrupt reason, and writes it back to the same register in order to clear the interrupts.
After fixing that code it turned out that the communication was still unsuccessful. Apparently the USB device was not understanding the host for some reason. That should not happen since the request sent was one of the standard ones implemented by virtually anything with an USB connector, assumed that Poseidon clears the data caches before forwarding the work to the USB drivers but that's the responsibility of the driver itself.
The USB device responded and acknowledged the transmission! But why were all the request sent after address change failing with timeout? They should not. Once again, address set is supported just by anything. Tried to contact the device at address 0 once again and there it was, still responding properly. The enlightenment came. The bus address for DMA transmissions was, as it is in many bare metal USB implementations, just the pure memory address of the buffer as seen by the ARM cpu. Have "prefixed" it with the real location of uncached RAM and booted AROS once again.
Trident saw this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
and this:
Product : Vendor: Vdr=0424/PID=EC00
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 255
SubClass : 0
DevProto : 1
VendorID : 1060
ProductID : 60416
DevVers : 0200
and even this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
What are these things? The first one is USB hub built in the Raspberry. Thanks to this one the Pi machines (with exception of Pi0 and computing modules) have more than just one single USB port. The second one is the network chip in raspberry, the third one is my USB SD card reader which have just connected to see what happens. AROS tried, of course, to boot from it ;)
So, the first step towards working USB is done. The control transfers are working as you can see above. Next step is to implement bulk and interrupt transfers, having the basics in place. Finally some error handling will be added and USB for Pi will be as complete as the PC version.
[http://www.raspyfi.com/raspberry-pi-usb-audio-fix/ Issue with USB Audio]
Audio
[https://github.com/raspberrypi/linux/tree/rpi-patches/sound/arm audio] and its [https://github.com/raspberrypi/firmware/issues/2 very high speed message passing interface type of thing VCHI]
The Model B+ added an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality
the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures
Analogue audio
Audio over HDMI rev 1.3 & 1.4
Ethernet
10/100 BaseT Ethernet RJ45 socket
GPIO
GPIO shouldn't be too bad but bear in mind it is already accessed in places so they would need to allocate pins etc through it (e.g. sdcard to flicker the activity light, serial debug to output data on the GPIO pins)
Probably a resource rather than a device...
Started an i2c driver that will need to allocate GPIO pins. Feel free to work on it if you are interested ;p
GPU graphics with 2D and 3D acceleration
Sadly none yet for 32bit but for 64bit...
== References ==
===Hosted===
==== Linux ====
Change lxde to another
sudo leafpad /etc/x11/xinit/xinitrc
xorg.conf
<pre>
Section "Screen"
Identifier "Default Screen"
DefaultDepth 16
SubSection "Display"
# Viewport 0 0
Depth 16
Modes "800x600"
EndSubsection
EndSection
Section "Device"
Option "Backingstore"
Identifier "Card0"
EndSection
</pre>
Will raspberrypi ARM programs run on other ARM archs and vice-versa ? If not I would like to use different cpu names for
archs which are incompatible.
All code compiled for at most armv6 with softfp float abi will work on all softfp ARM targets, including raspberry.
Code compiled for hard-float ABI will not work on any softfp target. But then, hard-float abi uses -armhf- cpu name.
keyboard or mouse not functioning or partly working
lsmod
kernel and modules (stored in /lib/modules/ get from https://github.com/raspberrypi/firmware and click on ZIP button) have to be updated simultaneously
sudo Apt-Get Update
sudo Apt-Get Install <program >
<program > cksfv joystick p7zip-full stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 libreoffice epiphany-browser xbmc
ace-of-penguins gweled black-box petris xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis xbubble eboard&xboard (freezes) bomberclone
OMXPlayer not responding or working with keyboard or no sound audio through HDMI
LXterminal—command "OMXPlayer -o hdmi %f "
hdmi issues
Setting the hdmi_force_hotplug=1 makes sure the Pi believes the monitor/TV is really there.
You might also need to set config_hdmi_boost=4 or even higher (up to 9) if your display needs a stronger signal.
If the display is a computer monitor or newer tv, use hdmi_group=1 (auto HDMI use) and if it is an older TV, try hdmi_group=2 (for DMT formats, i.e. for PC monitors) then you HAVE to "set hdmi_drive = 2 to enable HDMI output as this forces HDMI mode rather than DVI mode
Do not set hdmi_safe=1 as that overrides many of the previous options.
Using a shorter or better quality HDMI cable might help. Make sure your Pi's power supply delivers 1 A and not 500 mA.
If you see a problem with the red colour - either absent, or interference - then try a boost
composite video
changing the RCA cable, then the composite port worked out of the box
Boot it as you are doing, without HDMI. If you now plug in the HDMI, do you get the image? In other words, does the Pi think HDMI is connected even when it isn't?
Rename all the files in the first partion of the card except bootcode.bin, start.elf and fixup.dat What's the result?
Put back config.txt What's the result?
for PAL mode sdtv_mode=2
dmi_ignore_hotplug Pretends HDMI hotplug signal is not asserted so it appears a HDMI display is not attached
hdmi_ignore_hotplug=1 Use composite mode even if HDMI monitor is detected
<pre>
# NOOBS Auto-generated Settings:
#hdmi_force_hotplug=1
#config_hdmi_boost=4
#overscan_left=24
#overscan_right=24
#overscan_top=16
#overscan_bottom=16
#disable_overscan=0
start_x=1
gpu_mem=128
</pre>
tvservice -c "PAL 4:3"
<pre>
/opt/vc/bin/tvservice -s or tvservice -s
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
(native) mode 16: 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m DMT
Group DMT has 0 modes:
</pre>
sudo amixer cset numid=3 1
forces the audio to the headphone jack, even with the HDMI video output plugged in
config.txt
the hdmi_ignore_edid_audio=1 option sems relevant as it should tell ALSA that the only available audio is analog, no matter what the display says
There are several different ways that these 4 pole (ring) composite analog cables can be wired up, so some work great in some applications and can be a waste of time in others.
What is needed for the Raspberry Pi B+ and above, which like many camcorders needs the ring contact next to the base contact to be the ground.
The wiring for the 4 pole are:
TIP (LEFT AUDIO CHANNEL)
RING 1 (RIGHT AUDIO CHANNEL)
RING 2 (GROUND/EARTH)
RING 3 BASE/SLEEVE (VIDEO) YELLOW
Most Apple based Players and the Microsoft Zune (TM) are wired this way.
Most analogue camcorders are wired this way as well, where the ground in on Ring 2 will work with the Pi although you may need to swap your Video plug with the Right Audio plug.
Nearly all other MP3 players are not wired this way, the ground is on another ring ie the wrong one.
External devices
* Camera Module Omnivision ov5647 Sunny 5MP (NoIR version) V1.3 - NoIR at 850 nm, peak at 880 nm and trails off at 940 nm wavelengths
* Camera V2 Sony IMX219 V2.1 8mpixel 8MP 8megapixel - 3280 x 2464 pixels - video at 1080p30, 720p60 and 640x480p90 - wider field of view, 62 vs 54 degrees horizontally -
* Branded WIFI usb BCM43143 dongle
N.B. dreaded error after changing cameras (stupidly without turning off the power first) and lasted through several power cycles. It can be a bad 15-pin FFC ribbon cable, when swapped, camera(s) and the Pi itself are working OK. It can be an instance of a cold solder joint on the CSI connector on the pi board. the camera can be detected (that's done via I2C) but may still not be able to receive image data (done via CSI-2) if something is broken. CSI-2 is uni-directional. Control is generally done via I2C.
The CSI-2 receiver always writes to memory, not direct to the ISP. That's the way the Broadcom architecture works as it allows multipass processing easily. GPU memory is accessible from the ARM. Processing using the QPU graphics processors may be possible. currently the only supported sensor is OV5647 and IMX219. The linux drivers are all in the firmware blob, else you'd be looking at at least a man-month of work in a fully fledged imaging lab to do a decent tuning of the camera modules' ISP parameters.
Static electricity maybe an issue for the camera module and slightly less for the pi board.
* Hosted under ARM Linux which needs to be already installed [http://www.aros.org/nightly1.php current ABIv1]
Help building AROS hosted on Linux ARM
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:
<pre>
Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic':
configure: error: C compiler cannot create executables
See config.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2
</pre>
looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.
now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)
P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.
Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.
My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.
Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.
For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.
Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.
Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh
I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:
#MM- linklibs-armhd : libklibs-aeabi-arm
Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.
I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...). Smile
To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.
With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.
65n5s5rehrrqb8vtzlv27ibj09mvben
4655983
4655982
2026-08-01T11:05:38Z
Jeff1138
301139
4655983
wikitext
text/x-wiki
{{ArosNav}}
[[#Native]]
[[#Hosted]]
==Introduction==
The Raspberry Pi Foundation is a charity founded in May 2009 to promote the study of basic computer science in schools, and is responsible for developing a single-board computer called the Raspberry Pi.
The Foundation is supported by the University of Cambridge Computer Laboratory and Broadcom. Its aim is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing."
The original Raspberry Pi 1 Model B computer went on sale in February 2012 and set a new standard shattering the dominance of the PC in the home and education markets. Millions in the various formats, A, B, A+, B+ and Compute have since been shipped worldwide. The original concept of the Raspberry Pi was for a computer board providing Internet access with up to 1080p HD graphics at very low cost. The boards provide a platform for children and adults from any background to acquire computer science knowledge and help develop the future World-Wide-Web and all things internet (IOT hub and bridges out to home network to cloud of sensors).
Hobbyists and tech dabblers/tinkerers are the main purchases of the Pis (around half).
The rest of the sales are split between education/industrial. While the Raspberry Pi boards were designed primarily for education, they have become very popular with manufacturers of embedded systems. The Raspberry Pi Foundation has ensured backwards compatibility with each new revision. The bare-bones Compute module is aimed specifically at the OEM manufacturer.
* Pi 5 - Quad A76 and RP1 "southbridge" with VideoCore 7 4Gb 8Gb LPDDR4X
* Pi 4 - Quad A72 64bit VideoCore 6
* Pi 3 - Quad A53 [https://www.raspberrypi.com/documentation/computers/processors.html 64 bit] - VideoCore 4
* Pi 2 - Quad 32bit but more power consumed
* Model B+ - lower power usage but same speed as the original Pis
* Model A and B -
* Compute 1, 3, 4 and 5 - industrial use
<pre>
2008 Trustees collected for Foundation
2009 Charity status gained
2010
2011 First Raspberry prototypes
2012 First boards go on sale at CPC and RS. The Model A and B 700 MHz Arm11 - February 29th BCM 2835
2012 First million sold - more than the 10,000 original planned and anticipated
2013 First Alpha Experimental builds of AROS Native for the Pi
2013 Pi Trading launched making grants available, providing in house educational resources and Pi Academy for teacher training
2013 Over two million sold
2014 Over three million sold and updated Model B+ introduced that moved composite video to audio jack and same half gig of memory
2014 Pi Model A+ v1.1 - BCM2711 no ethernet and 1 usb - a little smaller -
2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit core and 32bit VideoCore IV 3d GPU with 1Gb RAM
2015 Over four million first gen pis sold
2015 Over a million pi2s sold
2015 Pi Zero BCM2835 released
2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837
2016 Passed Sinclair total number of computer lines sold - around 7 million
2016 Pi 3 Model B - Broadcom BCM2837 SOC four 64bit ARMv8 Cortex-A53 1.2GHz - 1Gb - bluetooth 4.1, Cypress CYW43438 wireless 802.11n and a dual 32bit VideoCore IV GPU
2016 Total PIs over 10 million worldwide
2016 Compute 3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage
2017 12 million pis sold in total
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 - 1Gb, wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet
2019 Over 15 million sold
2019 Pi 3 Model A with BCM2837b0 with 512Mb,
2019 Raspberry Pi Compute Module 3+ CM3+ LITE Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc
2019 Pi 4 Model B - BCM2711 quad 64bit A72 1.5GHz, VideoCore VI, AC wifi, Bluetooth 5.0, GbE, 2 micro hdmi decode up to 4K, USB-C power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram
2019 Pi 4 Model 2B - BCM2712 4 usb
2020 Raspberry Pi SC0919 Pico RP2040
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard
2020 Raspberry Pi Compute Module 4
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam
2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu
2024 Raspberry Pi Pico 2
2024 Pi 5 2GB version uses BCM2712D0
2024 Pi-500
2024 Raspberry Pi Compute Module 5
2025 Pi-500+
2026 April and May Aros 64bit fixed, added AHI audio, VC4 gfx started, usb functions added to rom
2026 June and July Aros 64bit usb2otg started, dma.resource, sdio.resource, bwfm.device wifi added
2026 Late July daily 64bit Pi3 builds start
2026 August ....
2027
2028 Pi 6
</pre>
===Good sites to visit===
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k]
*[https://github.com/raspberrypi/firmware/tree/master/https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9boot Raspberry Pi Firmware build]
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build]
*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi]
2026 [https://github.com/aros-development-team/AROS/commit/af09e634fff510918670e9f5ad6c5503727fe541 64bit build started late July]
===Native===
* 2013-03 Kalamatee starts work
* 2013-05 Work put on hiatus
* 2015-04 Work continues slowly with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb
* 2018 [https://www.patreon.com/posts/i-owe-you-some-20956961 mschulz resume with adding BE big endian support as well]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=bsek latest commits for pi 3]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=jonx latest commits for pi 4]
64bit ArmV8 builds are
The status of AROS 32bit native for RasPi was OK. System booting, USB working (although with some issues but plan to fix them). Got stuck on modifying the ABI (application binary interface) and adjusting binutils/gcc to support it wanted to have real executable files but got stuck a little. This change for the type of relocations embedded in ARM files and not sure if this very type is well supported, on the other hand without this change ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.
Old native [http://www.aros.org/nightly1.html ARMv6 32bit nightlys] and
[http://www.aros.org/snapshots1.html old linux and android hosted]
==Build==
===64bit===
===32bit===
# download/checkout the source someplace, e.g. /build/AROS-Src/
# make a directory to store external sources AROS downloads, e.g. /build/Ports
# make a build directory, e.g. /build/aros-raspi-armhf
# cd into the build dir, configure, and then run make -:
<pre>
>cd /build/aros-raspi-armhf
>/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
>make
>make arosboot-raspi
</pre>
then copy the files from /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ onto an sdcard, and download/copy the Raspi firmware files onto it.
You should then be able to boot the sdcard on your RasPi.
The current W.I.P tree to svn. it can be built as follows ..
<pre>
./configure --target=raspi-armhf
make arosboot-raspi
</pre>
That will generate arosraspi.img, arosraspi.rom and config.txt in bin/raspi-arm/AROS - so either copy just those files to a fat formatted SD card (with the firmware files on), or copy the whole contents of the AROS folder.
NB - if you have a Linux/other install, backup the existing config.txt first
arosraspi.img contains the bootstrap (which has very basic mailbox code, framebuffer/gpio init, and console "emulation" via code pinched from our libbootconsole), kernel.resource, and exec.library
arosraspi.rom contains all the other components needed to boot AROS.
The config.txt file will tell the RasPI bootstrap to load our arosraspi kernel and ramdisk (rom).
the bootstrap has minimal mailbox code, planning on adding either a resource or library that driver/app code will use to access it (likewise for GPIO)
==== Hosted ====
Ubuntu VM approach to compiling [http://lallafa.de/blog/2013/06/building-aros-hosted-for-raspbian/ Linux hosted AROS June 04, 2013]
../AROS/configure --target=linux-armhf --enable-includes=/usr/arm-linux-gnueabihf/include --x-includes=/usr/arm-linux-gnueabihf/include --x-libraries=/usr/arm-linux-gnueabihf/lib
arm-elf- is symbol-linked to arm-linux-gnueabi- (arm-linux-gnueabi- is more correct in this case, because it's going to be compiling the ARM AROSBootstrap for ARM Linux)
*armel - many of the "android" machines require since the entire OS is made for soft float VFP.
*armfp - Efika MX target, Raspberry PI, EfikaMX, Pandora and virtually everything (VFP)
Keep in mind it's possible to start hardfp AROS hosted on softfp system, though, as long as no calls between AROS and host require floating point parameters. NOTE: hardfloat objects *cannot* be linked with softfloat objects - they have a different ABI.
Just keep in mind the arm nightly build machine is quite complex beast. It needs the x86_64 host compiler to compile AROS tools. The arm version is built every night using gcc-4.6.2 crosscompiler (built together with AROS) and successfully builds armel and armhf linux hosted targets.
*needs an AROS code compiler for ARM target
*as well as unix compiler for ARM linux host (would be best to have both softfp and armhf, we have softfp only now) with full set of libraries and includes.
with—disable-crosstools $AROS_CC is always a wrapper around $KERNEL_CC ? If so, this is wrong for some ports. This can break Darwin, Windows and Android port.
Yes, Android port will build. And even work. But it's not good because the port will not be ABI-compatible with other ARM ports. Android's ABI is different from GNUEABI. For example:
<pre>
enum test {foo, bar};
enum test testvar;
</pre>
siseof(testvar) will be equal to sizeof(int) in GNUEABI (Linux and AROS) and sizeof(short) on Android. This affects linking objects from static linklibs, for example.
Previously everything worked because $AROS_CC was a wrapper on top of $HOST_CC. And a real crosscompiler was used on non-ELF hosts.
Android is the same. $KERNEL_CC is incompatible with AROS.
compiler=kernel is appropriate _ONLY FOR CODE WHICH RUNS ON HOST OS_ (or barebone hardware, if we talk about native). This includes bootstraps, their linklibs, and host-side dynamic libraries (Windows makes extensive use of them because of architectural considerations.
No single AROS object should be compiled with this setting. $KERNEL_CC is really compatible with AROS *ONLY IN LINUX-HOSTED* and no more. On other systems (Darwin, Windows, Android) this is not true any more, and compiler=kernel is never going to work.
If you want to compile your AROS module against host OS includes, append the following to USER_INCLUDES (or USER_CFLAGS, this is effectively the same):
-isystem $(GENINCDIR) $(KERNEL_INCLUDES)
$(KERNEL_INCLUDES) expands to:
-isystem <your_os_includes> -isystem <host_OS_gcc_private_includes>
-nostdinc
This makes AROS compiler adhering to host OS APIs.
If you want some preprocessor symbols based on what your host OS actually is, add something like -DHOST_OS_$(AROS_HOST_ARCH).
Why is there $(GENINCDIR) at all? Because host OS has its own libc includes, which would conflict with AROS ones. And the host OS libc is not binary-compatible with AROS one.
Why doesn't Windows-hosted port use $(KERNEL_INCLUDES) ? Because WinAPI includes conflict with AROS ones in fundamental typedefs, like WORD, BYTE and BOOL. It's almost impossible to deal with this in any other way than rewriting WinAPI definitions using AROS types.
Building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. haven't yet committed the necessary changes but "./configure --target=raspi-armhf" is enough to start, then "make arosboot-raspi" will generate arosraspi.img (containing the bootstrap, kernel.resource, and exec.library) as well as arosraspi.rom (containing all the other essentials components such as dos, graphics etc). It will also copy over a config.txt file to make the raspi bootstrap code load the correct kernel, and a cmdline.txt that enables exec debug output.
*armel = typically Debian 6, Ubuntu Maverick, Android,
*armhf = typically Debian 7, Debian 8, Ubuntu Precise,
Cross-compiling Ubuntu ARM softfp
<pre>
sudo sh
echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
</pre>
<pre>
./configure --target=linux-arm --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabi/include
</pre>
Cross-compiling Ubuntu ARM hard-float
<pre>
sudo sh
echo 'foreign-architecture armhf' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armhf.list
apt-get update
apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
</pre>
<pre>
./configure --target=linux-armhf --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabihf/include
</pre>
Now, the AROS build is configured properly and all you need to do is:
make
[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]
== Hardware ==
===64bit===
====BCM2712====
BCM2837
* Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support, 3B+ [https://github.com/aros-development-team/AROS/commit/afa5bc0bb17d5dd06bcfdbac00853a3799ca8d76 LAN7515]
====BCM2711====
===32bit===
=== Core Kernel ===
the reason behind INTB_KERNEL is to allow use of the standard Exec function AddIntServer() to add interrupt handlers for
hardware drivers etc. AmigaOS never used it for abstract hardware drivers. AmigaOS routed only raw hardware IRQs there. Their assignment was hardcoded. As well as number of them. Actually on AmigaOS every bus has its own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt. 1:1 relationship between CPU and hardware interrupts is present only on PC.
IMHO we miss things like AddInterrupt/RemInterrupt methods on our PCI subsystem's device class. PCI bus class should map these methods to whatever is appropriate. This is how it is done on AmigaOS and friends. When these are implemented, raw kernel.resource API will be needed only for several PC-specific drivers with hardwired resources. Exec IRQs are real IRQs only on Amiga hardware. On other machines they can be emulated where appropriate (VBlank is a good example). kernel.resource is meant to be different, its IRQs are hardware-agnostic, they are plain "Hardware IRQ number X, whatever this means". They are low-level actually, and meaningful only in the context of a particular system.
Was that not the transition from irq.hidd to kernel.resource? No. A long time ago there was another hacky bit named INTB_TIMERTICK. It was "abstract timer interrupt", used by timer.device. It was the same as VBlank, but with larger frequency. I removed it, because kernel.resource API was a cleaner way to access this interrupt. Furthermore, there can be more than one timer in the system. I am even thinking about bringing back timer HIDD definitions again. hpet.resource is a bad idea.
Can someone please enlighten me a little on how the scheduler is meant to work?
Poseidon.library creates its "Poseidon Event Task" during RTF_COLDSTART -> then calls Wait(), and ends up in limbo because wait disables interrupts (used for the scheduler heartbeat), and basically waits forever because the sigbit is never set, since krnSwitch doesn't switch the task unless TF_SWITCH is set, and no codepath run during this seems to set it?? TF_SWITCH does not disable/enable switching. This flag just enables to run user-supplied hook when the task is being switched away. It is completely safe to call Wait() in Disable()d state. Doing this actually temporarily breaks this state. IDNestCnt gets remembered in struct Task, then next task is selected, and its IDNestCnt is restored in sysbase (see kernel_scheduler.c). If there are no other tasks, then your cpu_Dispatch() should enable interrupts on the CPU and enter idle mode. See x86 implementation for good example.
You miss what happens next...
1. KrnSwitch() saves context of your task, saves IDNestCnt (core_Switch() and cpu_Switch()), then drops into cpu_Dispatch().
2. cpu_Dispatch() calls core_Dispatch. Then two cases are possible:
2a. There is a READY task. It is picked up, its IDNestCnt is restored in SysBase, then cpu_Dispatch() needs to restore registers and exit. The next task is run.
2b. There are no READY tasks. core_Dispatch() returns NULL. In this case your cpu_Dispatch() should enter idle loop. It should just enable interrupts on the CPU and put it on halt. This allows it to process hardware interrupts. Eventually some of your interrupt handlers wakes up your task and puts it into READY list.
My heartbeat interrupt has been slowed atm to help debugging - but it never actually gets a chance to fire because of the Wait() disabling interrupts. Perhaps you have forgotten to enable interrupts in your idle loop.
There is a change in the format of AROS executables. Until now we were using Elf RELocable files which are usually used as intermediate object files. We had them for various reasons, one of them was how AROS files were built in the past. That days we had no real aros cross compiler and the option to embed relocation data in unix executables (or in executable files in general) was rather new and not every linux/unix system had it. Therefore we have decided to use intermediate files. Although it was somehow working (and it is still working :-)), it has some drawbacks. Therefore decided to introduce real Elf EXEC types, in first turn implemented on ARM target with option to expand in future to all other AROS architectures.
The first patch was pretty easy and appeared to work somehow. It generated nice executables with embedded relocation info. Not only that, it also removed all global symbols adjusting relocation data to be relative to the beginning of the sections. That move reduced number of symbols in each executable significantly (depending on the file between 20 and 80% of all symbols could be removed). The only symbols that stayed in the file are local ones - due to the nature of the patch wasn't able to remove them since we have not seen them in the symbol hash table.
The patch didn't worked though. The files were relocated, AROS kernel loaded, but it crashed very early. What happened? Well, the nature of ARM relocations happened :)
Most of the relocation data on all machines is rather simple. Relocation can be absolute or pc-relative, sometimes the offset has to be bit shifted. On ARM v7 there is another one. There, when one wants to load an address of function/variable into register a combination of two instructions can be used: movw and movt. The first one loads immediate into lower 16 bits of a register while clearing upper 16 bits. The second one loads immediate into upper 16 bits without touching lower halfword. Loading of a pointer into a register looks like this:
movw r0, #:lower16:label
movt r0, #:upper16:label
In this case there are two relocations - one for lower halfword and another for upper. If an overflow of lower 16 bits occurs during relocation process, the upper one should be updated as well. Unfortunately with current patch and with typical ARM executables there is not enough information to perform the calculations.
There are two options - the first one would be to give up and go back to "fake" executables, another one would be to change from REL to RELA relocation info. The latter contains an addend, extra data which can be used to perform all the relocation calculations I need.
Decided for the second option. The patch is already in the works. There is another function for the binutils' bfd backend to perform the final relocation. There can decide what to do with every reloc info, modify data and eventually strip some symbols. An advantage is - at this stage of the linking process have also full access to all local symbols so can change all relocations section relative and eventually strip all symbols from the files.
=== GPU ===
Most of start.elf runs on the GPU. Placing ALL the userland GPU code in the videocore.hidd isn't going to be a terribly big problem because the code they published is nothing more than a shim that sends data straight to the GPU to execute.
The good news about this is that we only need to write our HIDD using the OpenVG API. The shim is relatively small codewise and lives in the ARM memory (the actual OpenVG code itself lives in the GPU RAM area and its loaded from start.elf). That's also the bad news. Our driver has to translate AROS video calls to OpenVG calls, for most tasks it should be easy, for some, not so much. It's still probably less difficult and less work, than controlling the GPU directly.
The other good news is that anything done through OpenVG happens on the GPU, its truly accelerated. It also has some nice font functions, meaning we can lead into an accelerated text mode later.
Basically, AROS resets or locks up when it tries to use AROS_ATOMIC_INC or DEC. If I comment out the byte/word operations in the header files and use non-atomic operations, the code works as expected.
have read that the L1 cache needs to be enabled to use LDREX and co (which I also read is only meant to be used on multi processor systems with shared memory) - however I am certain this is correctly enabled.
If you are using LREX or STREX, you should have L1 cache enabled, at least on the ARM CPU I work with at work.
L1 cache is enabled by enabling the MMU *AND* setting the C and I bits in the CPU - the C bit is ignored, and the I bit only covers the 16 byte instruction pipeline if the MMU is not enabled.
Can you verify that your assembly is generating LDREX/STREX? From the behavior, it almost sounds like its generating the default Semaphore locked atomics.
Impossible. There are no semaphore-locked atomics. There are Disable()/Enable()-based ones instead. And there's a special #define AROS_NO_ATOMIC_OPERATIONS in this case, which tweaks Disable()/Enable() implementations not to recurse forever.
I have tested this on ARMv5 which does not have ldrex/strex, it works fine. On those ARMs there's no way to have real atomics. On other OSes (like Linux) this is done by introducing things like atomic_t, which appears to be a complex structure, holding the value together with accompanying spinlock (implemented using swp).
#warning "TODO: lookup optimal mmu table settings for raspi memory"
/* Set up an identity-mapping for all 4GB */
for(x = 0; x < 4096; x ++)
{
pagetable[x] = x<<20 | (0x40002|0x80000|0x010000|0x00C00|0x04);
}
Shouldn't there be a second loop that sets the 'C' bit in the descriptor for the RAM pages?
Currently, you have TEX=0, C=0, B=1 for all pages (Shared Device).
You should have TEX=0, C=1, B=0 for RAM (Write-Through, Cached)
So ..
pagetable[x] = x<<20 | 2;
should be enough?
No, for RAM you need to change the '| 0x40' to '| 0x80'
tell dosboot the correct defaults to use
Please don't do this. This bootconfig.c is a deprecated legacy thing. I wanted it to go away completely with time. Instead, display drivers should auto-install themselves during own initialization phase. I. e. detect hardware=>instantiate itself. This should make things way simpler. With this approach you only need to add the driver into KS image to get the device autobooted. No
hardcoded stuff.
Currently VESA and VGA drivers do this, look there for examples. never rewrote ATI driver because i don't have any test system for it.
they defined a smaller AROSCPUContext than the ExceptionContext - yet reference it as ExceptionContext in other places, and since it hasn't allocated enough storage for ExceptionContext, are corrupting memory/the structure (since the elements that are there don't map 1 to 1 with the exception context).
AFAIK, AROS has been moving in a different direction to this in recent
years. It is the job of graphics HIDDs to allocate bitmaps etc. so that
they have the most suitable characteristics, including allocating them
from GPU RAM where possible. The concept of chip RAM is only for legacy
code, and most if not all non-68k platforms should have all system RAM
marked as chip.
BTW, is the video processing code you mention CPU code or GPU code?
Also, IIRC we have support for "external memory allocators". Perhaps that's what we need for the allocation of GPU RAM through the mailbox.
All hosted and x86 native ports should use proper context formats.
trying to clarify if the vblank handler has to have run by this point to prevent this deadlock. Actually, no. Unless you have installed VBlank handler which should wake up at some point. Without VBlank there will be no quantum count. Consequently, there will be no forced preemption. But the rest will work, and multitasking will be cooperative (switch happens only when current task voluntarily gives up the CPU). Does it depend on the vblank having run before this point? and if yes what does that mean on systems where it might be able to run enough code (e.g. get to this point) before the vblank interrupt has triggered? What is it waiting for? It could wait for timer, in this case you need timer.device working. VBlank is currently needed for exec's quantum counter. In current native ports we have only a single timer, which is served by timer.device. VBlank is simulated by timer.device also. If your machine has two timers, then you can use one of them for VBlank, and another for timer.device, this will simplify things down. VBlank needs to be 50 Hz for historical reasons, many programs use it as cheap timer. I am periodically thinking about making some abstract mechanism to be able to change quantum source (and untie it from 50 Hz), but have no time to come up with something good. Additionally i started disliking timer.device hardcoded design when PC has got many timers (old 8253, APIC, HPET).
Currently i think there should be some low-level entity representing tick source. timer.device should just select the most appropriate source for its units.
The BCM2835 has 4 GPU based timer sources - 2 are used by the GPU, so im using Timer3 for our heartbeat and the remaining one will be free to the system. There is also the less capable ARM timer but that is dependent on the CPU frequency. Very good. You won't need any emulation. Set the heartbeat to 50 Hz and drive VBlank from it. Use other timer for MicroHZ.
Can you use the 'econsole.hook' I make for debugging the Sam460 via the serial port?
It provides a before-anything-else shell prompt on the serial port. You can then do 'NewCLI' to test your graphics, or use any DOS command in shellcommands.resource.
You should just be able to add econsole.hook to your module list, and use 'econsole' in your bootargs.
So long as you have a working Exec/RawMayGetChar and Exec/RawPutChar, it should work.
Also make sure to add shell.resource and shellcommands.resource for this.
That should have done it.
If you set "#define DEBUG 1" in arch/all-native/econsole/econsole.c, do you get any additional serial output?
have added it to the build and added econsole to the command line - and can see the bootloader picks up on the emergency bootconsole tag, but I still only get the insert bootable media display?
Im assuming it exposes a fake filesystem that tricks aros into booting?
The contents of which are: ECON:AROS.boot
Way to handle the scheduling code? The implementations I had been following were causing problems, due to cascading interrupts which I cant handle properly in the asm stubs just now (when they break disable etc.) - since it means detecting the interrupted codes cpu mode and getting the correct sp/lr for it, and that's just too tedious for arm.
To work around this ive added a system idle task which does nothing - and when the scheduling code has no task to run switches this in and lets it run, thereby allowing the interrupts etc to resume until something does need to happen.
Also, by adding accounting code to cpu_Switch() and cpu_Dispatch(), it should allow the system to log idle time correctly (as well as running tasks).
have thought of also adding an additional task that never runs, solely to record time spent in IRQ handlers, but I digress..
was under the impression that kernel.resource should *never* be used outside of exec.library. This is a wrong impression.
Michal started designing it because portable nature of AROS does not fit well into exec's API with all its assumptions. So, he started the new, hardware-agnostic kernel API from scratch. Yes, exec sits on top of it in places. But kernel always meant to be open thing. Otherwise it would not exist.
it wasn't meant to be just used willy nilly by user code - but by lower system components (e.g. exec) so that they could be implemented in a more generic fashion, and the kernel resource itself hide the systems quirks.
Adding new things there perfectly keeps up with our decision to minimize AROS-specific intervention into APIs which can clash with MorphOS/OS4 extensions. We want at least source-level compatibility there. Binary compatibility on PPC would be extremely cool, but at the other hand we have no maintainer for this, as well as their ABIs are a bit weird and far from optimal, especially MorphOS one, because it aims for m68k binary compatibility.
It depends on what exactly is being implemented - there's no reason we should have everything crammed into kernel.resource if it doesn't need to be (i.e. if its better suited as a separate component/subsystem in its own right)
The _LE versions are for when you have endian swapping taking place. If the graphics are the same endian as the CPU, no swapping should occur. I ran into a similar terminology problem in SDL with a friend insisting that his Radeon 7000 on his PC was big-endian. It is not, it just uses the same endianness for the graphics card and the CPU so no swapping was necessary. They were both little-endian.
The _LE versions are because the PixFmts refer to the bitmap data being in big endian format in memory, for which the normal version would need to do endianness conversion before applying the shifts/masks. on this platform it is in _LE in memory also so we don't need the conversion hence using the _LE version of the call). would use _LE (if it's really little endian 16 bit mode).
What is the bare minimum needed to implement a framebuffer based gfx driver, with our software handling the rest?
I have tried with just a gfx class that only expose new/dispose/newbitmap - and having an onscreenbitmap used only for the framebuffer itself (with all other bitmaps being chunkybm, and the framebuffer's superclass also being chunkybm), but that alone isn't enough it seems?
You can use workbench/hidds/sm502/ as your example - it is as simple as I could make it.
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
I so far have -:
vc_init: queries the gpus memory, and sets up a fake memory handler for it, then adds the bootmode driver and returns saying all is well
vc_gfxhidd:New: sets up some fake syncmodes to test with and creates the real gfx object.
vc_gfxhidd:NewBitmap: checks if its a framebuffer and uses the onbitmap class or uses the chunkybm class otherwise
vc_onbitmap:New; creates a chunkybm object and then pushes the real framebuffer address into it as the buffer,
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
The code I currently have on SVN seems to create the framebuffers bitmap object fine, but then crashes in intuitions DisplayDriver callback. In particular it crashes performing the getattr on the system default pointer.
don't expose MEMF_CHIP in an allocatable form so AllocSpriteData was failing (and other code later doesn't check if the values are valid == illegal memory accesses)
Actually MEMF_CHIP has to present, for historical reasons.
This has been never fully agreed upon, but in ports i wrote i exposed the whole memory as MEMF_CHIP. The idea behind this is that CHIP is originally the memory where graphics and sound data can be put. On non-Amiga platforms there are no restrictions on this, so the whole memory is CHIP.
Yes, many old software can misbehave with CHIP memory size larger than 2MB. But this actually applies only to m68k AROS which is going to run m68k binaries. In other cases it's quite logical to fix the program when porting.
As to original question: yes, it's enough to have a framebuffer bitmap (one with aoHidd_BitMap_FrameBuffer set to TRUE) and PutPixel routine. It framebuffer can be served by chunky bitmap class, then you can simply create chunky bitmap with your own buffer (see how VESA driver does this). Chunky PutPixel is already there.
struggling to determine what is the correct pixfmt to use for the 24/16/15 bit gfx modes on the RasPi. AFAIK it uses RGB565, for 16bit but im unsure what shifts etc should go with it? suffice to say Im getting the wrong colors so far lol.
<pre>
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0
redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
</pre>
It should likely be vHidd_StdPixFmt_RGB16_LE
This stuff is a bit confusing. The "names" of the stdpixfmts are based on the layout in memory,
ignoring endianess. So for example:
ARGB32: will be 0xAA 0xRR 0xGG 0xBB in memory on both big endian and little endian machines.
The shifts and masks OTOH are based on pixel access (ULONG in this case), so differ depending
on whether you run on big endian machine or little endian machine (that's why there's stdpixfmt_le.h and
stdpixfmt_be.h in rom/hidds/graphics/).
With the 16 bit pixel format it's even more confusing, as for example it's impossible on little endian machine
to describe RGB16 with shifts/masks alone. That's why there's vHidd_PixFmt_SwapPixelBytes_Flag.
(RGB16 == RRRRRGGG GGGBBBBB in memory, and for pixel (WORD) access on little endian machine it needs to
be accessed as GGGBBBBBRRRRRGGGG).
The shifts btw indicate how much to shift the component to the left (!) so that it is moved to the highest bit (31).
The aHidd_PixFmt_StdPixFmt you specify will be ignored most of the time, because when the pixelfmt is registered,
the gfx hidd checks if there's an identical pixfmt (shifts/masks/etc., but ignoring pixfmt->stdpixfmt) already in the system,
and if so, it uses the already existing one and does not create a new one.
In theory it would be better if gfx drivers could simply/only specify a StdPixFmt without all the shifts/masks stuff when the
gfx driver uses pixfmt which matches one of the stdpixfmts exactly. Another possibility would be for gfx drivers to use
HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) and then peek shifts/masks from it and fill out a pixfmt
tag list based on that.
15bit very blue/green: Try to pass same shifts/masks/etc. as in 16 bit pixfmt (maybe you think it's using 15 bit R5G5B5
(or swapped) but it's actually still using 16 bit R5G6B5 (or swapped).
aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count.
But I would still pass the correct one (_LE) == whatever rom/hidds/graphics/stdpixfmts_??.h uses
in the entry where you have looked up shifts/masks/etc.
Use the shifts/masks/etc. from the entry in stdpixfmt_le.h (if you are running on little endian machine) or stdpixfmt_be.h (if you
are running on little endian machine) that matches the pixfmt that its meant to be.
0xAA,0xRR,0xGG,0xBB on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)
0xAA,0xRR,0xGG,0xBB on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_BGRA32)
it feels like AROS trashes the alpha component, otherwise it should be 8A8R8G8B.
read on the subject suggest its in 1x5r5g5b (x is ignored) to keep 16bit alignment .
What I see on screen suggests to me that wrong shift/mask are being applied - however going by the 16bit versions it all looks correct to me so I am really confused as to what is happening.
The output image looks to have too much green/blue, and very weak red.
Why did usbromstartup become HW-specific ?
In the past i have done a big job separating kickstart into several parts. I have never got any responses, so i re-describe my idea.
For now it loads the hs otg chipset driver ..
The idea is to minimize amount of archirecture-specific modules to
make user's life easier. So, the kickstart was split into 'base'
(which does not contain anything machine-specific) and 'BSP' (Board
Support Package) which contains all hardware-specific stuff.
This way, for example, distribution makers can save up space on CD
and make CDs with multiple platform support. Different configuration
would load the same base with different BSP's.
Next there was some part which is entirely missing on hosted. These
are filesystems. Hosted ports do not need them to boot up, so on
hosted they are left out. At the other hand, they are also
architecture-agnostic. So i put them into 'FS' package (standing for
'filesystem').
Poseidon is one more big part. I made it into separate package in
order to allow users to omit it if they don't need it (for example, to
run on retro PCs without USB). Personally i have one. Again, Poseidon
is hardware-agnostic (well, there are USB drivers but HCIs are pretty
standard).
It's mandatory on PI since there are no other interface types - so being a separate package is irrelevant/pointless.
Is Raspberry's USB controller non-HCI compliant? Actually i expect it to be compliant, then wouldn't it be better to make existing drivers discovering them?
AFAIK its HCI 1.0 compliant but I'm not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once i'm more familiar with the workings I can merge in the changes needed to get it operating but for now I will focus on getting it running. Also our drivers have known issues so perhaps a fresh set of eyes might shed some light on what is going wrong.
Another interesting question is whether Poseidon can operate on device side. Is it flexible enough? How similar is being a USB host and USB device? think it will need a bit of work on Poseidon's side. Until then I will force the driver into Host/Master mode in the init code, but leave open device etc to configure the chipset for either's use - and look at trying to add support for working in Device/Slave mode & switching modes once it's up and running.
Actually USBROMStartup is some kind of kludge. Can there be any alternative? Could device drivers be self-installing, like our HIDDs? This would get rid of need to list them in USBRomStartup.
And there is one more thing about modular ports. In order to actually implement this, your bootstrapping environment should provide the ability to load several files. On PC this is provided by GRUB2. on CHRP you can read filesystem via OpenFirmware, and Sam's Parthenope relies on modified u-boot. If your bootstrap allows to load only a single file, then you stuck with monolithic kickstart. By the way... u-boot allows not only to boot up a single uImage or zImage, it also allows to write client programs AFAIK. With this approach, you actually can write modular bootstrap for ARM AROS using unmodified u-boot.
[http://repo.or.cz/w/AROS.git/commit/e7bdc7e7b7f12b07aa24c739abb63721a872a53a arasan eMMC sdcard controller specific header which is not USB] and [http://repo.or.cz/w/AROS.git/commit/8bd19674084526a534ac11f7d4c51932e9ffe3d2 added prelim sdcard device]. [http://repo.or.cz/w/AROS.git/commit/9ab8217f61911fb8b7fd41bee46a992b4668ced1 do not set 4bit data mode, or enable acmd12/dma int's]
====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM)
*Framebuffer (fb) using mailbox
*IRQ scheduler, etc
*Arasan based SD Card controller
*Synopsis DesignWare USB 2.0 OTG controller [http://networkdirection.net/index.php?option=com_content&view=article&id=106:rasperry-pi-usb-controller&catid=45:raspberry-pi&Itemid=54 Unofficial DOCS pdf], [dwc_otg.c FreeBSD], [], [https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/Controllers/DWCDriver/ RiscOS USB Driver], [https://www.riscosopen.org/forum/forums/5/topics/878 RiscOS USB Discussion], [https://www.riscosopen.org/forum/forums/11/topics/1893 Other USB RiscOS], [http://plan9.bell-labs.com/plan9/index.html Plan9 Miller's usb] http://plan9.bell-labs.com/sources/contrib/miller/, [https://github.com/Chadderz121/csud CSUD driver],
*[http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf SMSC 9512] USB LAN/Hub chip
*CMOS RAM
*VCHIQ port which sends messages to the GPU e.g. for mouse, keyboard, audio on HDMI, etc
*Audio Driver
*Serial Peripheral Interface Bus (SPI)
*[http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/ I2C registers]
*I2S
*Universal Asynchronous Receiver Transmitter (UART)
*[http://elinux.org/RPi_BCM2835_GPIOs GPIOs] and [http://www.adafruit.com/blog/2012/08/17/broadcom-bcm2835-peripheral-memory-map-and-gpio-alternate-use-chart-piday-raspberrypi-raspberry_pi/ Alternative view of GPIO]
BCM2836
* For Pi B+, PI 2 and Pi 3 SMSC LAN9514 chip adding 10/100 Ethernet connectivity and four USB channels to the board
The overclock ability has diminished with each chip version as the energy usage has very slowly risen. BCM2837 is one of the warmest yet and might benefit from active cooling (ie fan) if all four cpu cores are in use for a short while. Video playback is not affected due to the custom support in the GPU. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur.
*[http://www.andrewscheller.co.uk/rpi_pcb_modules.html PCB], [http://elinux.org/RPi_Low-level_peripherals Low level features],
Implemented so far...
# Modify the configure system so that it correctly builds for the arm hardware float raspi target.
# Implemented the bootstrap to load the aros modules and prepare the arm to jump into them. Reworked the x86 console support so that parts can be stolen for raspi to use since t has no basic functionality to output to the display.
# Implemented a kernel.resource to prepare the raspi for running aros and provide the low level api calls to expose available resources and allow exec, etc function.
# Implemented serial debug support
# Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc)
# Implemented a timer.device to utilise the hardware timers.
# Implemented a very basic gfx driver to expose the hardware's framebuffer.
# Implemented an SD-Card driver for AROS which presently only supports the raspi's chipset but can easily be modified to support all sd-card hardware and media.
# Fixed the fat filesystem support in AROS so that it can boot on RasPi's normal SD-Card setup. The "rom" image files needed use a different filename than the default linux, etc images so can be easily installed without harming the existing files - you only need to change the loaded images in the config file to get aros to boot.
# Updated the build scripts to automatically download the necessary raspi firmware files and wrap it all up so that you can simply extract the archive to a fat formatted sdcard and boot it on the raspi without having to get anything else.
# fix everything in contrib and ports to build for raspi (needs proper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi ..
Improvements...
# Implement a USB chipset driver "OR" finish the existing one [https://github.com/aros-development-team/AROS/commit/c07d13c724f944674be5db54fc6a71ee72a01809 usb otg] - the current code is mostly a skeleton that should initialise the chipset and then needs relevant code to support the different transfer types. It also has the "virtual" hub code in place to represent the raspi's USB port (from poseidons p.o.v)
# Implement a driver for the USB NIC (a few weeks - depends on USB above)
# Write an [https://github.com/aros-development-team/AROS/commit/d55d0f74d20b769bbb8c8d386e5c1d7a9154f05a audio driver] (a few weeks - independent of USB) and [https://github.com/aros-development-team/AROS/commit/e93a4c245f27a87c9c4c1d39206694b39059998a HDMI]
# fix syscall bug in the current raspi kernel code
# Graphics depend on having a decent "bcmdma.resource" implemented as to use the cpu's dma engine. The sd card driver needs to use it for transfers to/from the controller - and the gfx system needs to use it for "blitting".
# [https://github.com/aros-development-team/AROS/commit/4019d84e4975d4dad987a12d57fe108f5ac048e6 Improve the gfx driver], [ vc4gfx HIDD] add [http://dri.freedesktop.org/wiki/VC4/ Gallium3D support]
# [https://github.com/aros-development-team/AROS/commit/b13905b3e8e45b089f520b44692c81affddd066f Improve] the [https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9 sdcard] device driver - which is also pretty basic but should work with most cards, rework it to also support pci, etc. sd card interfaces on x86
# The current code using very rudimentary access to the gpio interface - so that should be implemented as some resource for other components to access, as-well as the i2c interface exposed over the gpio interface. that should have a hidd class implemented which uses the gpio resource to communicate.
Boot up
On power-up, the rpi [http://www.open.com.au/mikem/bcm2835/ BCM 2835] [https://github.com/hermanhermitage/videocoreiv VideoCore4] GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the BCM2835's VideoCoreIV GPU PROM requires a DOS-style partition table; a FAT-formatted first partition; and the freely redistributable but closed sourced Broadcom files “bootcode.bin” and “start.elf” in that partition.
The boot sequence carries out several pre-boot tasks
*On powering of the rpi, the GPU reads and executes bootcode.bin, which then loads start.elf
*The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it
*configures the memory split for the CPU and GPU
*reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings)
*loads the “kernel.img” file, again from the same partition
*activates the CPU to begin executing the loaded kernel image
The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU.
RPi uses [https://github.com/raspberrypi/firmware some closed source loaders] and at some point it loads a binary blob named "kernel.img" at 0x8000, at that point there would be a rudimentary Aros alive. If one wants to use the SD-card then there would have to be a driver for the interface and a fat filesystem handler (SD-card has to be formatted to fat filesystem)
Boot code and kernel are now linked together and made into that binary blob, just for starters. Raspberry Pi uses [http://kernelnomicon.org/?p=133 u-boot] and [http://kernelnomicon.org/?p=138 UBoot] as bootloader, there's already some code in the Efika MX port for that. UBoot is a native bootloader and not just for the raspberry pi, it loads after start.elf.
You can find Efika MX port from arch implementations, some hacking is needed for the mmakefile.src'es as iit dates back to before the Aros crosstool era or else you get some weird errors while building. You also need to code the bootstrap and serial handling.
At the moment it seems that a fastest route for the native build would be to make one binary blob without using the package system. Raspberry's memory layout is pretty simple and if the implemented u-boot doesn't support loading other modules
<pre>
? - alias for 'help'
mtest - simple RAM test
autoscr - run script from memory
base - print or set address offset
bbm - BBM sub-system
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
jade -
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv - print environment variables
rarpboot - boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saves - save S-Record file over serial line
setenv - set environment variables
sleep - delay execution for some time
tftpboot - boot image via network using TFTP protocol
USB - USB sub-system
usbboot - boot from USB device
version - print monitor version
</pre>
Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,
Framebuffer - basic display
RasPi has to speak to the "operating system" which runs on the GPU itself and request/free memory - it cant directly manage it itself, and so the managed functions were used to wrap these calls.
The Arm and GPU share memory space. The framebuffer is shared. The Arm can write a pixel and it will appear on the screen (through GPU hardware) without flushing/copying being required.
The GPU can composite multiple FB's in real time - so you have a number of surfaces defined which are rotated etc and composited in real time to the output. Copying can map from the address space of the Arm to the flat space of the GPU which takes some code, but I don't think whole buffers are copied.
The DMA hardware can also access the whole memory space and can perform 2D fills and blits (no blending). This is documented in the peripheral spec posted. The DMA is just an Arm accessible peripheral and can be set up with low latency (e.g. microseconds).
must use a 0xc0000000-based bus address to access SDRAM, yet non-DMA access should go via a 0x0-based bus address.
For 2D dma, set TDMODE, and the spec says "interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer." so set STRIDE to pitch of the image, the width is XLENGTH and height is YLENGTH. You would fill by not setting the SRC_INC and point source to your fill data.
The DMA cannot see the ARM's L1 cache, so you would map the framebuffer with ioremap_nocache. Depending on where the source data comes from, it may need an L1 cache flush. The DMA can see the L2 cache. Use 0xC0000000 bus addresses when L2 is disabled and 0x40000000 bus addresses when L2 is enabled. (actually just call virt_to_bus and you'll get the right address out).
openGLES/openVG has high latency. Writing to framebuffer then reading it back is very inefficient (e.g. milliseconds). If you can drive it a unidirectional way, just streaming commands at then that is efficient. openVG is not implemented on top of openGLES - it uses the same hardware but as a first class interface
To improve the Gfx driver, we will need a DMA resource implemented so can use to perform DMA operations. The Gfx driver will need this to perform blits.
USB
* Model A and B limited to 150 mA per port.
* Model B+ and Pi 2 introduced configurable 600 mA to 1.2 A support over all ports - anything above that requires a powered USB hub.
Implementing the hardware driver that Poseidon uses to interact with the USB components.
Have code in place to (try) and initialise the USB chipset, and configure host/device mode operation (though AFAICT Poseidon doesn't support device mode). Started to get the "virtual" root hub written for the single USB port so that Poseidon should at least list it correctly in the GUI - and try to interact with it to find peripherals.
The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”).
There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA. However, there's a Linux driver written by Synopsys ([https://github.com/raspberrypi/linux dwc_usb]). Specifically directories [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_common_port] and [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_otg].
The Synopsys code is actually under a fairly permissive licence – it's not GPL, it's similar to BSD (’don't sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code.
The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port).
Probably only need provision of relevant changes to dwc_common_port. Other things to consider....
* Provision of necessary headers to get it to compile
* Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes (multithreading) )
* Interfacing between USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start.
the Linux bits of the headers are only required for the dwc_common_port library. dwc_common_port includes a variety of crypto functions which are not used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn't going to be for plain wired USB.
Every USB driver acts as an USB hub as well in order to let Poseidon control the state of USB ports. The code there was reading status of the only USB port in Raspberry's CPU but when changing the status it erroneously deleted some of the status bits, including the port enable one. It was so because those bits in the status register are of a type Read/WriteToClear. It means, if one does not want to change their value from 1 back to 0, one has to actually write the 0 value. Very practical thing e.g. in interrupt handlers, where one reads the interrupt status register to learn what was the interrupt reason, and writes it back to the same register in order to clear the interrupts.
After fixing that code it turned out that the communication was still unsuccessful. Apparently the USB device was not understanding the host for some reason. That should not happen since the request sent was one of the standard ones implemented by virtually anything with an USB connector, assumed that Poseidon clears the data caches before forwarding the work to the USB drivers but that's the responsibility of the driver itself.
The USB device responded and acknowledged the transmission! But why were all the request sent after address change failing with timeout? They should not. Once again, address set is supported just by anything. Tried to contact the device at address 0 once again and there it was, still responding properly. The enlightenment came. The bus address for DMA transmissions was, as it is in many bare metal USB implementations, just the pure memory address of the buffer as seen by the ARM cpu. Have "prefixed" it with the real location of uncached RAM and booted AROS once again.
Trident saw this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
and this:
Product : Vendor: Vdr=0424/PID=EC00
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 255
SubClass : 0
DevProto : 1
VendorID : 1060
ProductID : 60416
DevVers : 0200
and even this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
What are these things? The first one is USB hub built in the Raspberry. Thanks to this one the Pi machines (with exception of Pi0 and computing modules) have more than just one single USB port. The second one is the network chip in raspberry, the third one is my USB SD card reader which have just connected to see what happens. AROS tried, of course, to boot from it ;)
So, the first step towards working USB is done. The control transfers are working as you can see above. Next step is to implement bulk and interrupt transfers, having the basics in place. Finally some error handling will be added and USB for Pi will be as complete as the PC version.
[http://www.raspyfi.com/raspberry-pi-usb-audio-fix/ Issue with USB Audio]
Audio
[https://github.com/raspberrypi/linux/tree/rpi-patches/sound/arm audio] and its [https://github.com/raspberrypi/firmware/issues/2 very high speed message passing interface type of thing VCHI]
The Model B+ added an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality
the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures
Analogue audio
Audio over HDMI rev 1.3 & 1.4
Ethernet
10/100 BaseT Ethernet RJ45 socket
GPIO
GPIO shouldn't be too bad but bear in mind it is already accessed in places so they would need to allocate pins etc through it (e.g. sdcard to flicker the activity light, serial debug to output data on the GPIO pins)
Probably a resource rather than a device...
Started an i2c driver that will need to allocate GPIO pins. Feel free to work on it if you are interested ;p
GPU graphics with 2D and 3D acceleration
Sadly none yet for 32bit but for 64bit...
== References ==
===Hosted===
==== Linux ====
Change lxde to another
sudo leafpad /etc/x11/xinit/xinitrc
xorg.conf
<pre>
Section "Screen"
Identifier "Default Screen"
DefaultDepth 16
SubSection "Display"
# Viewport 0 0
Depth 16
Modes "800x600"
EndSubsection
EndSection
Section "Device"
Option "Backingstore"
Identifier "Card0"
EndSection
</pre>
Will raspberrypi ARM programs run on other ARM archs and vice-versa ? If not I would like to use different cpu names for
archs which are incompatible.
All code compiled for at most armv6 with softfp float abi will work on all softfp ARM targets, including raspberry.
Code compiled for hard-float ABI will not work on any softfp target. But then, hard-float abi uses -armhf- cpu name.
keyboard or mouse not functioning or partly working
lsmod
kernel and modules (stored in /lib/modules/ get from https://github.com/raspberrypi/firmware and click on ZIP button) have to be updated simultaneously
sudo Apt-Get Update
sudo Apt-Get Install <program >
<program > cksfv joystick p7zip-full stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 libreoffice epiphany-browser xbmc
ace-of-penguins gweled black-box petris xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis xbubble eboard&xboard (freezes) bomberclone
OMXPlayer not responding or working with keyboard or no sound audio through HDMI
LXterminal—command "OMXPlayer -o hdmi %f "
hdmi issues
Setting the hdmi_force_hotplug=1 makes sure the Pi believes the monitor/TV is really there.
You might also need to set config_hdmi_boost=4 or even higher (up to 9) if your display needs a stronger signal.
If the display is a computer monitor or newer tv, use hdmi_group=1 (auto HDMI use) and if it is an older TV, try hdmi_group=2 (for DMT formats, i.e. for PC monitors) then you HAVE to "set hdmi_drive = 2 to enable HDMI output as this forces HDMI mode rather than DVI mode
Do not set hdmi_safe=1 as that overrides many of the previous options.
Using a shorter or better quality HDMI cable might help. Make sure your Pi's power supply delivers 1 A and not 500 mA.
If you see a problem with the red colour - either absent, or interference - then try a boost
composite video
changing the RCA cable, then the composite port worked out of the box
Boot it as you are doing, without HDMI. If you now plug in the HDMI, do you get the image? In other words, does the Pi think HDMI is connected even when it isn't?
Rename all the files in the first partion of the card except bootcode.bin, start.elf and fixup.dat What's the result?
Put back config.txt What's the result?
for PAL mode sdtv_mode=2
dmi_ignore_hotplug Pretends HDMI hotplug signal is not asserted so it appears a HDMI display is not attached
hdmi_ignore_hotplug=1 Use composite mode even if HDMI monitor is detected
<pre>
# NOOBS Auto-generated Settings:
#hdmi_force_hotplug=1
#config_hdmi_boost=4
#overscan_left=24
#overscan_right=24
#overscan_top=16
#overscan_bottom=16
#disable_overscan=0
start_x=1
gpu_mem=128
</pre>
tvservice -c "PAL 4:3"
<pre>
/opt/vc/bin/tvservice -s or tvservice -s
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
(native) mode 16: 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m DMT
Group DMT has 0 modes:
</pre>
sudo amixer cset numid=3 1
forces the audio to the headphone jack, even with the HDMI video output plugged in
config.txt
the hdmi_ignore_edid_audio=1 option sems relevant as it should tell ALSA that the only available audio is analog, no matter what the display says
There are several different ways that these 4 pole (ring) composite analog cables can be wired up, so some work great in some applications and can be a waste of time in others.
What is needed for the Raspberry Pi B+ and above, which like many camcorders needs the ring contact next to the base contact to be the ground.
The wiring for the 4 pole are:
TIP (LEFT AUDIO CHANNEL)
RING 1 (RIGHT AUDIO CHANNEL)
RING 2 (GROUND/EARTH)
RING 3 BASE/SLEEVE (VIDEO) YELLOW
Most Apple based Players and the Microsoft Zune (TM) are wired this way.
Most analogue camcorders are wired this way as well, where the ground in on Ring 2 will work with the Pi although you may need to swap your Video plug with the Right Audio plug.
Nearly all other MP3 players are not wired this way, the ground is on another ring ie the wrong one.
External devices
* Camera Module Omnivision ov5647 Sunny 5MP (NoIR version) V1.3 - NoIR at 850 nm, peak at 880 nm and trails off at 940 nm wavelengths
* Camera V2 Sony IMX219 V2.1 8mpixel 8MP 8megapixel - 3280 x 2464 pixels - video at 1080p30, 720p60 and 640x480p90 - wider field of view, 62 vs 54 degrees horizontally -
* Branded WIFI usb BCM43143 dongle
N.B. dreaded error after changing cameras (stupidly without turning off the power first) and lasted through several power cycles. It can be a bad 15-pin FFC ribbon cable, when swapped, camera(s) and the Pi itself are working OK. It can be an instance of a cold solder joint on the CSI connector on the pi board. the camera can be detected (that's done via I2C) but may still not be able to receive image data (done via CSI-2) if something is broken. CSI-2 is uni-directional. Control is generally done via I2C.
The CSI-2 receiver always writes to memory, not direct to the ISP. That's the way the Broadcom architecture works as it allows multipass processing easily. GPU memory is accessible from the ARM. Processing using the QPU graphics processors may be possible. currently the only supported sensor is OV5647 and IMX219. The linux drivers are all in the firmware blob, else you'd be looking at at least a man-month of work in a fully fledged imaging lab to do a decent tuning of the camera modules' ISP parameters.
Static electricity maybe an issue for the camera module and slightly less for the pi board.
* Hosted under ARM Linux which needs to be already installed [http://www.aros.org/nightly1.php current ABIv1]
Help building AROS hosted on Linux ARM
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:
<pre>
Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic':
configure: error: C compiler cannot create executables
See config.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2
</pre>
looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.
now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)
P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.
Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.
My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.
Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.
For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.
Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.
Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh
I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:
#MM- linklibs-armhd : libklibs-aeabi-arm
Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.
I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...). Smile
To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.
With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.
gugeehwdl00h4b19avhtn60tv6plhvr
4655984
4655983
2026-08-01T11:11:19Z
Jeff1138
301139
4655984
wikitext
text/x-wiki
{{ArosNav}}
[[#Native]]
[[#Hosted]]
==Introduction==
The Raspberry Pi Foundation is a charity founded in May 2009 to promote the study of basic computer science in schools, and is responsible for developing a single-board computer called the Raspberry Pi.
The Foundation is supported by the University of Cambridge Computer Laboratory and Broadcom. Its aim is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing."
The original Raspberry Pi 1 Model B computer went on sale in February 2012 and set a new standard shattering the dominance of the PC in the home and education markets. Millions in the various formats, A, B, A+, B+ and Compute have since been shipped worldwide. The original concept of the Raspberry Pi was for a computer board providing Internet access with up to 1080p HD graphics at very low cost. The boards provide a platform for children and adults from any background to acquire computer science knowledge and help develop the future World-Wide-Web and all things internet (IOT hub and bridges out to home network to cloud of sensors).
Hobbyists and tech dabblers/tinkerers are the main purchases of the Pis (around half).
The rest of the sales are split between education/industrial. While the Raspberry Pi boards were designed primarily for education, they have become very popular with manufacturers of embedded systems. The Raspberry Pi Foundation has ensured backwards compatibility with each new revision. The bare-bones Compute module is aimed specifically at the OEM manufacturer.
* Pi 5 - Quad A76 and RP1 "southbridge" with VideoCore 7 4Gb 8Gb LPDDR4X
* Pi 4 - Quad A72 64bit VideoCore 6
* Pi 3 - Quad A53 [https://www.raspberrypi.com/documentation/computers/processors.html 64 bit] - VideoCore 4
* Pi 2 - Quad 32bit but more power consumed
* Model B+ - lower power usage but same speed as the original Pis
* Model A and B -
* Compute 1, 3, 4 and 5 - industrial use
<pre>
2008 Trustees collected for Foundation
2009 Charity status gained
2010
2011 First Raspberry prototypes
2012 First boards go on sale at CPC and RS. The Model A and B 700 MHz Arm11 - February 29th BCM 2835
2012 First million sold - more than the 10,000 original planned and anticipated
2013 First Alpha Experimental builds of AROS Native for the Pi
2013 Pi Trading launched making grants available, providing in house educational resources and Pi Academy for teacher training
2013 Over two million sold
2014 Over three million sold and updated Model B+ introduced that moved composite video to audio jack and same half gig of memory
2014 Pi Model A+ v1.1 - BCM2711 no ethernet and 1 usb - a little smaller -
2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit core and 32bit VideoCore IV 3d GPU with 1Gb RAM
2015 Over four million first gen pis sold
2015 Over a million pi2s sold
2015 Pi Zero BCM2835 released
2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837
2016 Passed Sinclair total number of computer lines sold - around 7 million
2016 Pi 3 Model B - Broadcom BCM2837 SOC four 64bit ARMv8 Cortex-A53 1.2GHz - 1Gb - bluetooth 4.1, Cypress CYW43438 wireless 802.11n and a dual 32bit VideoCore IV GPU - 4 x USB2.0 ports
2016 Total PIs over 10 million worldwide
2016 Compute 3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage
2017 12 million pis sold in total
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 - 1Gb, wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet - 4 x USB2.0 ports
2019 Over 15 million sold
2019 Pi 3 Model A with BCM2837b0 with 512Mb,
2019 Raspberry Pi Compute Module 3+ CM3+ LITE Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc
2019 Pi 4 Model B - BCM2711 quad 64bit A72 1.5GHz, VideoCore VI, AC wifi, Bluetooth 5.0, GbE, 2 micro hdmi decode up to 4K, USB-C power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram
2019 Pi 4 Model 2B - BCM2712 4 usb
2020 Raspberry Pi SC0919 Pico RP2040
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard
2020 Raspberry Pi Compute Module 4
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam
2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu
2024 Raspberry Pi Pico 2
2024 Pi 5 2GB version uses BCM2712D0
2024 Pi-500
2024 Raspberry Pi Compute Module 5
2025 Pi-500+
2026 April and May Aros 64bit fixed, added AHI audio, VC4 gfx started, usb functions added to rom
2026 June and July Aros 64bit usb2otg started, dma.resource, sdio.resource, bwfm.device wifi added
2026 Late July daily 64bit Pi3 builds start
2026 August ....
2027
2028 Pi 6
</pre>
===Good sites to visit===
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k]
*[https://github.com/raspberrypi/firmware/tree/master/https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9boot Raspberry Pi Firmware build]
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build]
*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi]
2026 [https://github.com/aros-development-team/AROS/commit/af09e634fff510918670e9f5ad6c5503727fe541 64bit build started late July]
===Native===
* 2013-03 Kalamatee starts work
* 2013-05 Work put on hiatus
* 2015-04 Work continues slowly with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb
* 2018 [https://www.patreon.com/posts/i-owe-you-some-20956961 mschulz resume with adding BE big endian support as well]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=bsek latest commits for pi 3]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=jonx latest commits for pi 4]
64bit ArmV8 builds are
The status of AROS 32bit native for RasPi was OK. System booting, USB working (although with some issues but plan to fix them). Got stuck on modifying the ABI (application binary interface) and adjusting binutils/gcc to support it wanted to have real executable files but got stuck a little. This change for the type of relocations embedded in ARM files and not sure if this very type is well supported, on the other hand without this change ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.
Old native [http://www.aros.org/nightly1.html ARMv6 32bit nightlys] and
[http://www.aros.org/snapshots1.html old linux and android hosted]
==Build==
===64bit===
===32bit===
# download/checkout the source someplace, e.g. /build/AROS-Src/
# make a directory to store external sources AROS downloads, e.g. /build/Ports
# make a build directory, e.g. /build/aros-raspi-armhf
# cd into the build dir, configure, and then run make -:
<pre>
>cd /build/aros-raspi-armhf
>/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
>make
>make arosboot-raspi
</pre>
then copy the files from /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ onto an sdcard, and download/copy the Raspi firmware files onto it.
You should then be able to boot the sdcard on your RasPi.
The current W.I.P tree to svn. it can be built as follows ..
<pre>
./configure --target=raspi-armhf
make arosboot-raspi
</pre>
That will generate arosraspi.img, arosraspi.rom and config.txt in bin/raspi-arm/AROS - so either copy just those files to a fat formatted SD card (with the firmware files on), or copy the whole contents of the AROS folder.
NB - if you have a Linux/other install, backup the existing config.txt first
arosraspi.img contains the bootstrap (which has very basic mailbox code, framebuffer/gpio init, and console "emulation" via code pinched from our libbootconsole), kernel.resource, and exec.library
arosraspi.rom contains all the other components needed to boot AROS.
The config.txt file will tell the RasPI bootstrap to load our arosraspi kernel and ramdisk (rom).
the bootstrap has minimal mailbox code, planning on adding either a resource or library that driver/app code will use to access it (likewise for GPIO)
==== Hosted ====
Ubuntu VM approach to compiling [http://lallafa.de/blog/2013/06/building-aros-hosted-for-raspbian/ Linux hosted AROS June 04, 2013]
../AROS/configure --target=linux-armhf --enable-includes=/usr/arm-linux-gnueabihf/include --x-includes=/usr/arm-linux-gnueabihf/include --x-libraries=/usr/arm-linux-gnueabihf/lib
arm-elf- is symbol-linked to arm-linux-gnueabi- (arm-linux-gnueabi- is more correct in this case, because it's going to be compiling the ARM AROSBootstrap for ARM Linux)
*armel - many of the "android" machines require since the entire OS is made for soft float VFP.
*armfp - Efika MX target, Raspberry PI, EfikaMX, Pandora and virtually everything (VFP)
Keep in mind it's possible to start hardfp AROS hosted on softfp system, though, as long as no calls between AROS and host require floating point parameters. NOTE: hardfloat objects *cannot* be linked with softfloat objects - they have a different ABI.
Just keep in mind the arm nightly build machine is quite complex beast. It needs the x86_64 host compiler to compile AROS tools. The arm version is built every night using gcc-4.6.2 crosscompiler (built together with AROS) and successfully builds armel and armhf linux hosted targets.
*needs an AROS code compiler for ARM target
*as well as unix compiler for ARM linux host (would be best to have both softfp and armhf, we have softfp only now) with full set of libraries and includes.
with—disable-crosstools $AROS_CC is always a wrapper around $KERNEL_CC ? If so, this is wrong for some ports. This can break Darwin, Windows and Android port.
Yes, Android port will build. And even work. But it's not good because the port will not be ABI-compatible with other ARM ports. Android's ABI is different from GNUEABI. For example:
<pre>
enum test {foo, bar};
enum test testvar;
</pre>
siseof(testvar) will be equal to sizeof(int) in GNUEABI (Linux and AROS) and sizeof(short) on Android. This affects linking objects from static linklibs, for example.
Previously everything worked because $AROS_CC was a wrapper on top of $HOST_CC. And a real crosscompiler was used on non-ELF hosts.
Android is the same. $KERNEL_CC is incompatible with AROS.
compiler=kernel is appropriate _ONLY FOR CODE WHICH RUNS ON HOST OS_ (or barebone hardware, if we talk about native). This includes bootstraps, their linklibs, and host-side dynamic libraries (Windows makes extensive use of them because of architectural considerations.
No single AROS object should be compiled with this setting. $KERNEL_CC is really compatible with AROS *ONLY IN LINUX-HOSTED* and no more. On other systems (Darwin, Windows, Android) this is not true any more, and compiler=kernel is never going to work.
If you want to compile your AROS module against host OS includes, append the following to USER_INCLUDES (or USER_CFLAGS, this is effectively the same):
-isystem $(GENINCDIR) $(KERNEL_INCLUDES)
$(KERNEL_INCLUDES) expands to:
-isystem <your_os_includes> -isystem <host_OS_gcc_private_includes>
-nostdinc
This makes AROS compiler adhering to host OS APIs.
If you want some preprocessor symbols based on what your host OS actually is, add something like -DHOST_OS_$(AROS_HOST_ARCH).
Why is there $(GENINCDIR) at all? Because host OS has its own libc includes, which would conflict with AROS ones. And the host OS libc is not binary-compatible with AROS one.
Why doesn't Windows-hosted port use $(KERNEL_INCLUDES) ? Because WinAPI includes conflict with AROS ones in fundamental typedefs, like WORD, BYTE and BOOL. It's almost impossible to deal with this in any other way than rewriting WinAPI definitions using AROS types.
Building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. haven't yet committed the necessary changes but "./configure --target=raspi-armhf" is enough to start, then "make arosboot-raspi" will generate arosraspi.img (containing the bootstrap, kernel.resource, and exec.library) as well as arosraspi.rom (containing all the other essentials components such as dos, graphics etc). It will also copy over a config.txt file to make the raspi bootstrap code load the correct kernel, and a cmdline.txt that enables exec debug output.
*armel = typically Debian 6, Ubuntu Maverick, Android,
*armhf = typically Debian 7, Debian 8, Ubuntu Precise,
Cross-compiling Ubuntu ARM softfp
<pre>
sudo sh
echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
</pre>
<pre>
./configure --target=linux-arm --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabi/include
</pre>
Cross-compiling Ubuntu ARM hard-float
<pre>
sudo sh
echo 'foreign-architecture armhf' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armhf.list
apt-get update
apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
</pre>
<pre>
./configure --target=linux-armhf --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabihf/include
</pre>
Now, the AROS build is configured properly and all you need to do is:
make
[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]
== Hardware ==
===64bit===
====BCM2712====
BCM2837
* Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support, 3B+ [https://github.com/aros-development-team/AROS/commit/afa5bc0bb17d5dd06bcfdbac00853a3799ca8d76 LAN7515]
====BCM2711====
===32bit===
=== Core Kernel ===
the reason behind INTB_KERNEL is to allow use of the standard Exec function AddIntServer() to add interrupt handlers for
hardware drivers etc. AmigaOS never used it for abstract hardware drivers. AmigaOS routed only raw hardware IRQs there. Their assignment was hardcoded. As well as number of them. Actually on AmigaOS every bus has its own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt. 1:1 relationship between CPU and hardware interrupts is present only on PC.
IMHO we miss things like AddInterrupt/RemInterrupt methods on our PCI subsystem's device class. PCI bus class should map these methods to whatever is appropriate. This is how it is done on AmigaOS and friends. When these are implemented, raw kernel.resource API will be needed only for several PC-specific drivers with hardwired resources. Exec IRQs are real IRQs only on Amiga hardware. On other machines they can be emulated where appropriate (VBlank is a good example). kernel.resource is meant to be different, its IRQs are hardware-agnostic, they are plain "Hardware IRQ number X, whatever this means". They are low-level actually, and meaningful only in the context of a particular system.
Was that not the transition from irq.hidd to kernel.resource? No. A long time ago there was another hacky bit named INTB_TIMERTICK. It was "abstract timer interrupt", used by timer.device. It was the same as VBlank, but with larger frequency. I removed it, because kernel.resource API was a cleaner way to access this interrupt. Furthermore, there can be more than one timer in the system. I am even thinking about bringing back timer HIDD definitions again. hpet.resource is a bad idea.
Can someone please enlighten me a little on how the scheduler is meant to work?
Poseidon.library creates its "Poseidon Event Task" during RTF_COLDSTART -> then calls Wait(), and ends up in limbo because wait disables interrupts (used for the scheduler heartbeat), and basically waits forever because the sigbit is never set, since krnSwitch doesn't switch the task unless TF_SWITCH is set, and no codepath run during this seems to set it?? TF_SWITCH does not disable/enable switching. This flag just enables to run user-supplied hook when the task is being switched away. It is completely safe to call Wait() in Disable()d state. Doing this actually temporarily breaks this state. IDNestCnt gets remembered in struct Task, then next task is selected, and its IDNestCnt is restored in sysbase (see kernel_scheduler.c). If there are no other tasks, then your cpu_Dispatch() should enable interrupts on the CPU and enter idle mode. See x86 implementation for good example.
You miss what happens next...
1. KrnSwitch() saves context of your task, saves IDNestCnt (core_Switch() and cpu_Switch()), then drops into cpu_Dispatch().
2. cpu_Dispatch() calls core_Dispatch. Then two cases are possible:
2a. There is a READY task. It is picked up, its IDNestCnt is restored in SysBase, then cpu_Dispatch() needs to restore registers and exit. The next task is run.
2b. There are no READY tasks. core_Dispatch() returns NULL. In this case your cpu_Dispatch() should enter idle loop. It should just enable interrupts on the CPU and put it on halt. This allows it to process hardware interrupts. Eventually some of your interrupt handlers wakes up your task and puts it into READY list.
My heartbeat interrupt has been slowed atm to help debugging - but it never actually gets a chance to fire because of the Wait() disabling interrupts. Perhaps you have forgotten to enable interrupts in your idle loop.
There is a change in the format of AROS executables. Until now we were using Elf RELocable files which are usually used as intermediate object files. We had them for various reasons, one of them was how AROS files were built in the past. That days we had no real aros cross compiler and the option to embed relocation data in unix executables (or in executable files in general) was rather new and not every linux/unix system had it. Therefore we have decided to use intermediate files. Although it was somehow working (and it is still working :-)), it has some drawbacks. Therefore decided to introduce real Elf EXEC types, in first turn implemented on ARM target with option to expand in future to all other AROS architectures.
The first patch was pretty easy and appeared to work somehow. It generated nice executables with embedded relocation info. Not only that, it also removed all global symbols adjusting relocation data to be relative to the beginning of the sections. That move reduced number of symbols in each executable significantly (depending on the file between 20 and 80% of all symbols could be removed). The only symbols that stayed in the file are local ones - due to the nature of the patch wasn't able to remove them since we have not seen them in the symbol hash table.
The patch didn't worked though. The files were relocated, AROS kernel loaded, but it crashed very early. What happened? Well, the nature of ARM relocations happened :)
Most of the relocation data on all machines is rather simple. Relocation can be absolute or pc-relative, sometimes the offset has to be bit shifted. On ARM v7 there is another one. There, when one wants to load an address of function/variable into register a combination of two instructions can be used: movw and movt. The first one loads immediate into lower 16 bits of a register while clearing upper 16 bits. The second one loads immediate into upper 16 bits without touching lower halfword. Loading of a pointer into a register looks like this:
movw r0, #:lower16:label
movt r0, #:upper16:label
In this case there are two relocations - one for lower halfword and another for upper. If an overflow of lower 16 bits occurs during relocation process, the upper one should be updated as well. Unfortunately with current patch and with typical ARM executables there is not enough information to perform the calculations.
There are two options - the first one would be to give up and go back to "fake" executables, another one would be to change from REL to RELA relocation info. The latter contains an addend, extra data which can be used to perform all the relocation calculations I need.
Decided for the second option. The patch is already in the works. There is another function for the binutils' bfd backend to perform the final relocation. There can decide what to do with every reloc info, modify data and eventually strip some symbols. An advantage is - at this stage of the linking process have also full access to all local symbols so can change all relocations section relative and eventually strip all symbols from the files.
=== GPU ===
Most of start.elf runs on the GPU. Placing ALL the userland GPU code in the videocore.hidd isn't going to be a terribly big problem because the code they published is nothing more than a shim that sends data straight to the GPU to execute.
The good news about this is that we only need to write our HIDD using the OpenVG API. The shim is relatively small codewise and lives in the ARM memory (the actual OpenVG code itself lives in the GPU RAM area and its loaded from start.elf). That's also the bad news. Our driver has to translate AROS video calls to OpenVG calls, for most tasks it should be easy, for some, not so much. It's still probably less difficult and less work, than controlling the GPU directly.
The other good news is that anything done through OpenVG happens on the GPU, its truly accelerated. It also has some nice font functions, meaning we can lead into an accelerated text mode later.
Basically, AROS resets or locks up when it tries to use AROS_ATOMIC_INC or DEC. If I comment out the byte/word operations in the header files and use non-atomic operations, the code works as expected.
have read that the L1 cache needs to be enabled to use LDREX and co (which I also read is only meant to be used on multi processor systems with shared memory) - however I am certain this is correctly enabled.
If you are using LREX or STREX, you should have L1 cache enabled, at least on the ARM CPU I work with at work.
L1 cache is enabled by enabling the MMU *AND* setting the C and I bits in the CPU - the C bit is ignored, and the I bit only covers the 16 byte instruction pipeline if the MMU is not enabled.
Can you verify that your assembly is generating LDREX/STREX? From the behavior, it almost sounds like its generating the default Semaphore locked atomics.
Impossible. There are no semaphore-locked atomics. There are Disable()/Enable()-based ones instead. And there's a special #define AROS_NO_ATOMIC_OPERATIONS in this case, which tweaks Disable()/Enable() implementations not to recurse forever.
I have tested this on ARMv5 which does not have ldrex/strex, it works fine. On those ARMs there's no way to have real atomics. On other OSes (like Linux) this is done by introducing things like atomic_t, which appears to be a complex structure, holding the value together with accompanying spinlock (implemented using swp).
#warning "TODO: lookup optimal mmu table settings for raspi memory"
/* Set up an identity-mapping for all 4GB */
for(x = 0; x < 4096; x ++)
{
pagetable[x] = x<<20 | (0x40002|0x80000|0x010000|0x00C00|0x04);
}
Shouldn't there be a second loop that sets the 'C' bit in the descriptor for the RAM pages?
Currently, you have TEX=0, C=0, B=1 for all pages (Shared Device).
You should have TEX=0, C=1, B=0 for RAM (Write-Through, Cached)
So ..
pagetable[x] = x<<20 | 2;
should be enough?
No, for RAM you need to change the '| 0x40' to '| 0x80'
tell dosboot the correct defaults to use
Please don't do this. This bootconfig.c is a deprecated legacy thing. I wanted it to go away completely with time. Instead, display drivers should auto-install themselves during own initialization phase. I. e. detect hardware=>instantiate itself. This should make things way simpler. With this approach you only need to add the driver into KS image to get the device autobooted. No
hardcoded stuff.
Currently VESA and VGA drivers do this, look there for examples. never rewrote ATI driver because i don't have any test system for it.
they defined a smaller AROSCPUContext than the ExceptionContext - yet reference it as ExceptionContext in other places, and since it hasn't allocated enough storage for ExceptionContext, are corrupting memory/the structure (since the elements that are there don't map 1 to 1 with the exception context).
AFAIK, AROS has been moving in a different direction to this in recent
years. It is the job of graphics HIDDs to allocate bitmaps etc. so that
they have the most suitable characteristics, including allocating them
from GPU RAM where possible. The concept of chip RAM is only for legacy
code, and most if not all non-68k platforms should have all system RAM
marked as chip.
BTW, is the video processing code you mention CPU code or GPU code?
Also, IIRC we have support for "external memory allocators". Perhaps that's what we need for the allocation of GPU RAM through the mailbox.
All hosted and x86 native ports should use proper context formats.
trying to clarify if the vblank handler has to have run by this point to prevent this deadlock. Actually, no. Unless you have installed VBlank handler which should wake up at some point. Without VBlank there will be no quantum count. Consequently, there will be no forced preemption. But the rest will work, and multitasking will be cooperative (switch happens only when current task voluntarily gives up the CPU). Does it depend on the vblank having run before this point? and if yes what does that mean on systems where it might be able to run enough code (e.g. get to this point) before the vblank interrupt has triggered? What is it waiting for? It could wait for timer, in this case you need timer.device working. VBlank is currently needed for exec's quantum counter. In current native ports we have only a single timer, which is served by timer.device. VBlank is simulated by timer.device also. If your machine has two timers, then you can use one of them for VBlank, and another for timer.device, this will simplify things down. VBlank needs to be 50 Hz for historical reasons, many programs use it as cheap timer. I am periodically thinking about making some abstract mechanism to be able to change quantum source (and untie it from 50 Hz), but have no time to come up with something good. Additionally i started disliking timer.device hardcoded design when PC has got many timers (old 8253, APIC, HPET).
Currently i think there should be some low-level entity representing tick source. timer.device should just select the most appropriate source for its units.
The BCM2835 has 4 GPU based timer sources - 2 are used by the GPU, so im using Timer3 for our heartbeat and the remaining one will be free to the system. There is also the less capable ARM timer but that is dependent on the CPU frequency. Very good. You won't need any emulation. Set the heartbeat to 50 Hz and drive VBlank from it. Use other timer for MicroHZ.
Can you use the 'econsole.hook' I make for debugging the Sam460 via the serial port?
It provides a before-anything-else shell prompt on the serial port. You can then do 'NewCLI' to test your graphics, or use any DOS command in shellcommands.resource.
You should just be able to add econsole.hook to your module list, and use 'econsole' in your bootargs.
So long as you have a working Exec/RawMayGetChar and Exec/RawPutChar, it should work.
Also make sure to add shell.resource and shellcommands.resource for this.
That should have done it.
If you set "#define DEBUG 1" in arch/all-native/econsole/econsole.c, do you get any additional serial output?
have added it to the build and added econsole to the command line - and can see the bootloader picks up on the emergency bootconsole tag, but I still only get the insert bootable media display?
Im assuming it exposes a fake filesystem that tricks aros into booting?
The contents of which are: ECON:AROS.boot
Way to handle the scheduling code? The implementations I had been following were causing problems, due to cascading interrupts which I cant handle properly in the asm stubs just now (when they break disable etc.) - since it means detecting the interrupted codes cpu mode and getting the correct sp/lr for it, and that's just too tedious for arm.
To work around this ive added a system idle task which does nothing - and when the scheduling code has no task to run switches this in and lets it run, thereby allowing the interrupts etc to resume until something does need to happen.
Also, by adding accounting code to cpu_Switch() and cpu_Dispatch(), it should allow the system to log idle time correctly (as well as running tasks).
have thought of also adding an additional task that never runs, solely to record time spent in IRQ handlers, but I digress..
was under the impression that kernel.resource should *never* be used outside of exec.library. This is a wrong impression.
Michal started designing it because portable nature of AROS does not fit well into exec's API with all its assumptions. So, he started the new, hardware-agnostic kernel API from scratch. Yes, exec sits on top of it in places. But kernel always meant to be open thing. Otherwise it would not exist.
it wasn't meant to be just used willy nilly by user code - but by lower system components (e.g. exec) so that they could be implemented in a more generic fashion, and the kernel resource itself hide the systems quirks.
Adding new things there perfectly keeps up with our decision to minimize AROS-specific intervention into APIs which can clash with MorphOS/OS4 extensions. We want at least source-level compatibility there. Binary compatibility on PPC would be extremely cool, but at the other hand we have no maintainer for this, as well as their ABIs are a bit weird and far from optimal, especially MorphOS one, because it aims for m68k binary compatibility.
It depends on what exactly is being implemented - there's no reason we should have everything crammed into kernel.resource if it doesn't need to be (i.e. if its better suited as a separate component/subsystem in its own right)
The _LE versions are for when you have endian swapping taking place. If the graphics are the same endian as the CPU, no swapping should occur. I ran into a similar terminology problem in SDL with a friend insisting that his Radeon 7000 on his PC was big-endian. It is not, it just uses the same endianness for the graphics card and the CPU so no swapping was necessary. They were both little-endian.
The _LE versions are because the PixFmts refer to the bitmap data being in big endian format in memory, for which the normal version would need to do endianness conversion before applying the shifts/masks. on this platform it is in _LE in memory also so we don't need the conversion hence using the _LE version of the call). would use _LE (if it's really little endian 16 bit mode).
What is the bare minimum needed to implement a framebuffer based gfx driver, with our software handling the rest?
I have tried with just a gfx class that only expose new/dispose/newbitmap - and having an onscreenbitmap used only for the framebuffer itself (with all other bitmaps being chunkybm, and the framebuffer's superclass also being chunkybm), but that alone isn't enough it seems?
You can use workbench/hidds/sm502/ as your example - it is as simple as I could make it.
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
I so far have -:
vc_init: queries the gpus memory, and sets up a fake memory handler for it, then adds the bootmode driver and returns saying all is well
vc_gfxhidd:New: sets up some fake syncmodes to test with and creates the real gfx object.
vc_gfxhidd:NewBitmap: checks if its a framebuffer and uses the onbitmap class or uses the chunkybm class otherwise
vc_onbitmap:New; creates a chunkybm object and then pushes the real framebuffer address into it as the buffer,
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
The code I currently have on SVN seems to create the framebuffers bitmap object fine, but then crashes in intuitions DisplayDriver callback. In particular it crashes performing the getattr on the system default pointer.
don't expose MEMF_CHIP in an allocatable form so AllocSpriteData was failing (and other code later doesn't check if the values are valid == illegal memory accesses)
Actually MEMF_CHIP has to present, for historical reasons.
This has been never fully agreed upon, but in ports i wrote i exposed the whole memory as MEMF_CHIP. The idea behind this is that CHIP is originally the memory where graphics and sound data can be put. On non-Amiga platforms there are no restrictions on this, so the whole memory is CHIP.
Yes, many old software can misbehave with CHIP memory size larger than 2MB. But this actually applies only to m68k AROS which is going to run m68k binaries. In other cases it's quite logical to fix the program when porting.
As to original question: yes, it's enough to have a framebuffer bitmap (one with aoHidd_BitMap_FrameBuffer set to TRUE) and PutPixel routine. It framebuffer can be served by chunky bitmap class, then you can simply create chunky bitmap with your own buffer (see how VESA driver does this). Chunky PutPixel is already there.
struggling to determine what is the correct pixfmt to use for the 24/16/15 bit gfx modes on the RasPi. AFAIK it uses RGB565, for 16bit but im unsure what shifts etc should go with it? suffice to say Im getting the wrong colors so far lol.
<pre>
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0
redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
</pre>
It should likely be vHidd_StdPixFmt_RGB16_LE
This stuff is a bit confusing. The "names" of the stdpixfmts are based on the layout in memory,
ignoring endianess. So for example:
ARGB32: will be 0xAA 0xRR 0xGG 0xBB in memory on both big endian and little endian machines.
The shifts and masks OTOH are based on pixel access (ULONG in this case), so differ depending
on whether you run on big endian machine or little endian machine (that's why there's stdpixfmt_le.h and
stdpixfmt_be.h in rom/hidds/graphics/).
With the 16 bit pixel format it's even more confusing, as for example it's impossible on little endian machine
to describe RGB16 with shifts/masks alone. That's why there's vHidd_PixFmt_SwapPixelBytes_Flag.
(RGB16 == RRRRRGGG GGGBBBBB in memory, and for pixel (WORD) access on little endian machine it needs to
be accessed as GGGBBBBBRRRRRGGGG).
The shifts btw indicate how much to shift the component to the left (!) so that it is moved to the highest bit (31).
The aHidd_PixFmt_StdPixFmt you specify will be ignored most of the time, because when the pixelfmt is registered,
the gfx hidd checks if there's an identical pixfmt (shifts/masks/etc., but ignoring pixfmt->stdpixfmt) already in the system,
and if so, it uses the already existing one and does not create a new one.
In theory it would be better if gfx drivers could simply/only specify a StdPixFmt without all the shifts/masks stuff when the
gfx driver uses pixfmt which matches one of the stdpixfmts exactly. Another possibility would be for gfx drivers to use
HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) and then peek shifts/masks from it and fill out a pixfmt
tag list based on that.
15bit very blue/green: Try to pass same shifts/masks/etc. as in 16 bit pixfmt (maybe you think it's using 15 bit R5G5B5
(or swapped) but it's actually still using 16 bit R5G6B5 (or swapped).
aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count.
But I would still pass the correct one (_LE) == whatever rom/hidds/graphics/stdpixfmts_??.h uses
in the entry where you have looked up shifts/masks/etc.
Use the shifts/masks/etc. from the entry in stdpixfmt_le.h (if you are running on little endian machine) or stdpixfmt_be.h (if you
are running on little endian machine) that matches the pixfmt that its meant to be.
0xAA,0xRR,0xGG,0xBB on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)
0xAA,0xRR,0xGG,0xBB on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_BGRA32)
it feels like AROS trashes the alpha component, otherwise it should be 8A8R8G8B.
read on the subject suggest its in 1x5r5g5b (x is ignored) to keep 16bit alignment .
What I see on screen suggests to me that wrong shift/mask are being applied - however going by the 16bit versions it all looks correct to me so I am really confused as to what is happening.
The output image looks to have too much green/blue, and very weak red.
Why did usbromstartup become HW-specific ?
In the past i have done a big job separating kickstart into several parts. I have never got any responses, so i re-describe my idea.
For now it loads the hs otg chipset driver ..
The idea is to minimize amount of archirecture-specific modules to
make user's life easier. So, the kickstart was split into 'base'
(which does not contain anything machine-specific) and 'BSP' (Board
Support Package) which contains all hardware-specific stuff.
This way, for example, distribution makers can save up space on CD
and make CDs with multiple platform support. Different configuration
would load the same base with different BSP's.
Next there was some part which is entirely missing on hosted. These
are filesystems. Hosted ports do not need them to boot up, so on
hosted they are left out. At the other hand, they are also
architecture-agnostic. So i put them into 'FS' package (standing for
'filesystem').
Poseidon is one more big part. I made it into separate package in
order to allow users to omit it if they don't need it (for example, to
run on retro PCs without USB). Personally i have one. Again, Poseidon
is hardware-agnostic (well, there are USB drivers but HCIs are pretty
standard).
It's mandatory on PI since there are no other interface types - so being a separate package is irrelevant/pointless.
Is Raspberry's USB controller non-HCI compliant? Actually i expect it to be compliant, then wouldn't it be better to make existing drivers discovering them?
AFAIK its HCI 1.0 compliant but I'm not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once i'm more familiar with the workings I can merge in the changes needed to get it operating but for now I will focus on getting it running. Also our drivers have known issues so perhaps a fresh set of eyes might shed some light on what is going wrong.
Another interesting question is whether Poseidon can operate on device side. Is it flexible enough? How similar is being a USB host and USB device? think it will need a bit of work on Poseidon's side. Until then I will force the driver into Host/Master mode in the init code, but leave open device etc to configure the chipset for either's use - and look at trying to add support for working in Device/Slave mode & switching modes once it's up and running.
Actually USBROMStartup is some kind of kludge. Can there be any alternative? Could device drivers be self-installing, like our HIDDs? This would get rid of need to list them in USBRomStartup.
And there is one more thing about modular ports. In order to actually implement this, your bootstrapping environment should provide the ability to load several files. On PC this is provided by GRUB2. on CHRP you can read filesystem via OpenFirmware, and Sam's Parthenope relies on modified u-boot. If your bootstrap allows to load only a single file, then you stuck with monolithic kickstart. By the way... u-boot allows not only to boot up a single uImage or zImage, it also allows to write client programs AFAIK. With this approach, you actually can write modular bootstrap for ARM AROS using unmodified u-boot.
[http://repo.or.cz/w/AROS.git/commit/e7bdc7e7b7f12b07aa24c739abb63721a872a53a arasan eMMC sdcard controller specific header which is not USB] and [http://repo.or.cz/w/AROS.git/commit/8bd19674084526a534ac11f7d4c51932e9ffe3d2 added prelim sdcard device]. [http://repo.or.cz/w/AROS.git/commit/9ab8217f61911fb8b7fd41bee46a992b4668ced1 do not set 4bit data mode, or enable acmd12/dma int's]
====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM)
*Framebuffer (fb) using mailbox
*IRQ scheduler, etc
*Arasan based SD Card controller
*Synopsis DesignWare USB 2.0 OTG controller [http://networkdirection.net/index.php?option=com_content&view=article&id=106:rasperry-pi-usb-controller&catid=45:raspberry-pi&Itemid=54 Unofficial DOCS pdf], [dwc_otg.c FreeBSD], [], [https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/Controllers/DWCDriver/ RiscOS USB Driver], [https://www.riscosopen.org/forum/forums/5/topics/878 RiscOS USB Discussion], [https://www.riscosopen.org/forum/forums/11/topics/1893 Other USB RiscOS], [http://plan9.bell-labs.com/plan9/index.html Plan9 Miller's usb] http://plan9.bell-labs.com/sources/contrib/miller/, [https://github.com/Chadderz121/csud CSUD driver],
*[http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf SMSC 9512] USB LAN/Hub chip
*CMOS RAM
*VCHIQ port which sends messages to the GPU e.g. for mouse, keyboard, audio on HDMI, etc
*Audio Driver
*Serial Peripheral Interface Bus (SPI)
*[http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/ I2C registers]
*I2S
*Universal Asynchronous Receiver Transmitter (UART)
*[http://elinux.org/RPi_BCM2835_GPIOs GPIOs] and [http://www.adafruit.com/blog/2012/08/17/broadcom-bcm2835-peripheral-memory-map-and-gpio-alternate-use-chart-piday-raspberrypi-raspberry_pi/ Alternative view of GPIO]
BCM2836
* For Pi B+, PI 2 and Pi 3 SMSC LAN9514 chip adding 10/100 Ethernet connectivity and four USB channels to the board
The overclock ability has diminished with each chip version as the energy usage has very slowly risen. BCM2837 is one of the warmest yet and might benefit from active cooling (ie fan) if all four cpu cores are in use for a short while. Video playback is not affected due to the custom support in the GPU. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur.
*[http://www.andrewscheller.co.uk/rpi_pcb_modules.html PCB], [http://elinux.org/RPi_Low-level_peripherals Low level features],
Implemented so far...
# Modify the configure system so that it correctly builds for the arm hardware float raspi target.
# Implemented the bootstrap to load the aros modules and prepare the arm to jump into them. Reworked the x86 console support so that parts can be stolen for raspi to use since t has no basic functionality to output to the display.
# Implemented a kernel.resource to prepare the raspi for running aros and provide the low level api calls to expose available resources and allow exec, etc function.
# Implemented serial debug support
# Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc)
# Implemented a timer.device to utilise the hardware timers.
# Implemented a very basic gfx driver to expose the hardware's framebuffer.
# Implemented an SD-Card driver for AROS which presently only supports the raspi's chipset but can easily be modified to support all sd-card hardware and media.
# Fixed the fat filesystem support in AROS so that it can boot on RasPi's normal SD-Card setup. The "rom" image files needed use a different filename than the default linux, etc images so can be easily installed without harming the existing files - you only need to change the loaded images in the config file to get aros to boot.
# Updated the build scripts to automatically download the necessary raspi firmware files and wrap it all up so that you can simply extract the archive to a fat formatted sdcard and boot it on the raspi without having to get anything else.
# fix everything in contrib and ports to build for raspi (needs proper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi ..
Improvements...
# Implement a USB chipset driver "OR" finish the existing one [https://github.com/aros-development-team/AROS/commit/c07d13c724f944674be5db54fc6a71ee72a01809 usb otg] - the current code is mostly a skeleton that should initialise the chipset and then needs relevant code to support the different transfer types. It also has the "virtual" hub code in place to represent the raspi's USB port (from poseidons p.o.v)
# Implement a driver for the USB NIC (a few weeks - depends on USB above)
# Write an [https://github.com/aros-development-team/AROS/commit/d55d0f74d20b769bbb8c8d386e5c1d7a9154f05a audio driver] (a few weeks - independent of USB) and [https://github.com/aros-development-team/AROS/commit/e93a4c245f27a87c9c4c1d39206694b39059998a HDMI]
# fix syscall bug in the current raspi kernel code
# Graphics depend on having a decent "bcmdma.resource" implemented as to use the cpu's dma engine. The sd card driver needs to use it for transfers to/from the controller - and the gfx system needs to use it for "blitting".
# [https://github.com/aros-development-team/AROS/commit/4019d84e4975d4dad987a12d57fe108f5ac048e6 Improve the gfx driver], [ vc4gfx HIDD] add [http://dri.freedesktop.org/wiki/VC4/ Gallium3D support]
# [https://github.com/aros-development-team/AROS/commit/b13905b3e8e45b089f520b44692c81affddd066f Improve] the [https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9 sdcard] device driver - which is also pretty basic but should work with most cards, rework it to also support pci, etc. sd card interfaces on x86
# The current code using very rudimentary access to the gpio interface - so that should be implemented as some resource for other components to access, as-well as the i2c interface exposed over the gpio interface. that should have a hidd class implemented which uses the gpio resource to communicate.
Boot up
On power-up, the rpi [http://www.open.com.au/mikem/bcm2835/ BCM 2835] [https://github.com/hermanhermitage/videocoreiv VideoCore4] GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the BCM2835's VideoCoreIV GPU PROM requires a DOS-style partition table; a FAT-formatted first partition; and the freely redistributable but closed sourced Broadcom files “bootcode.bin” and “start.elf” in that partition.
The boot sequence carries out several pre-boot tasks
*On powering of the rpi, the GPU reads and executes bootcode.bin, which then loads start.elf
*The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it
*configures the memory split for the CPU and GPU
*reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings)
*loads the “kernel.img” file, again from the same partition
*activates the CPU to begin executing the loaded kernel image
The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU.
RPi uses [https://github.com/raspberrypi/firmware some closed source loaders] and at some point it loads a binary blob named "kernel.img" at 0x8000, at that point there would be a rudimentary Aros alive. If one wants to use the SD-card then there would have to be a driver for the interface and a fat filesystem handler (SD-card has to be formatted to fat filesystem)
Boot code and kernel are now linked together and made into that binary blob, just for starters. Raspberry Pi uses [http://kernelnomicon.org/?p=133 u-boot] and [http://kernelnomicon.org/?p=138 UBoot] as bootloader, there's already some code in the Efika MX port for that. UBoot is a native bootloader and not just for the raspberry pi, it loads after start.elf.
You can find Efika MX port from arch implementations, some hacking is needed for the mmakefile.src'es as iit dates back to before the Aros crosstool era or else you get some weird errors while building. You also need to code the bootstrap and serial handling.
At the moment it seems that a fastest route for the native build would be to make one binary blob without using the package system. Raspberry's memory layout is pretty simple and if the implemented u-boot doesn't support loading other modules
<pre>
? - alias for 'help'
mtest - simple RAM test
autoscr - run script from memory
base - print or set address offset
bbm - BBM sub-system
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
jade -
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv - print environment variables
rarpboot - boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saves - save S-Record file over serial line
setenv - set environment variables
sleep - delay execution for some time
tftpboot - boot image via network using TFTP protocol
USB - USB sub-system
usbboot - boot from USB device
version - print monitor version
</pre>
Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,
Framebuffer - basic display
RasPi has to speak to the "operating system" which runs on the GPU itself and request/free memory - it cant directly manage it itself, and so the managed functions were used to wrap these calls.
The Arm and GPU share memory space. The framebuffer is shared. The Arm can write a pixel and it will appear on the screen (through GPU hardware) without flushing/copying being required.
The GPU can composite multiple FB's in real time - so you have a number of surfaces defined which are rotated etc and composited in real time to the output. Copying can map from the address space of the Arm to the flat space of the GPU which takes some code, but I don't think whole buffers are copied.
The DMA hardware can also access the whole memory space and can perform 2D fills and blits (no blending). This is documented in the peripheral spec posted. The DMA is just an Arm accessible peripheral and can be set up with low latency (e.g. microseconds).
must use a 0xc0000000-based bus address to access SDRAM, yet non-DMA access should go via a 0x0-based bus address.
For 2D dma, set TDMODE, and the spec says "interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer." so set STRIDE to pitch of the image, the width is XLENGTH and height is YLENGTH. You would fill by not setting the SRC_INC and point source to your fill data.
The DMA cannot see the ARM's L1 cache, so you would map the framebuffer with ioremap_nocache. Depending on where the source data comes from, it may need an L1 cache flush. The DMA can see the L2 cache. Use 0xC0000000 bus addresses when L2 is disabled and 0x40000000 bus addresses when L2 is enabled. (actually just call virt_to_bus and you'll get the right address out).
openGLES/openVG has high latency. Writing to framebuffer then reading it back is very inefficient (e.g. milliseconds). If you can drive it a unidirectional way, just streaming commands at then that is efficient. openVG is not implemented on top of openGLES - it uses the same hardware but as a first class interface
To improve the Gfx driver, we will need a DMA resource implemented so can use to perform DMA operations. The Gfx driver will need this to perform blits.
USB
* Model A and B limited to 150 mA per port.
* Model B+ and Pi 2 introduced configurable 600 mA to 1.2 A support over all ports - anything above that requires a powered USB hub.
Implementing the hardware driver that Poseidon uses to interact with the USB components.
Have code in place to (try) and initialise the USB chipset, and configure host/device mode operation (though AFAICT Poseidon doesn't support device mode). Started to get the "virtual" root hub written for the single USB port so that Poseidon should at least list it correctly in the GUI - and try to interact with it to find peripherals.
The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”).
There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA. However, there's a Linux driver written by Synopsys ([https://github.com/raspberrypi/linux dwc_usb]). Specifically directories [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_common_port] and [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_otg].
The Synopsys code is actually under a fairly permissive licence – it's not GPL, it's similar to BSD (’don't sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code.
The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port).
Probably only need provision of relevant changes to dwc_common_port. Other things to consider....
* Provision of necessary headers to get it to compile
* Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes (multithreading) )
* Interfacing between USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start.
the Linux bits of the headers are only required for the dwc_common_port library. dwc_common_port includes a variety of crypto functions which are not used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn't going to be for plain wired USB.
Every USB driver acts as an USB hub as well in order to let Poseidon control the state of USB ports. The code there was reading status of the only USB port in Raspberry's CPU but when changing the status it erroneously deleted some of the status bits, including the port enable one. It was so because those bits in the status register are of a type Read/WriteToClear. It means, if one does not want to change their value from 1 back to 0, one has to actually write the 0 value. Very practical thing e.g. in interrupt handlers, where one reads the interrupt status register to learn what was the interrupt reason, and writes it back to the same register in order to clear the interrupts.
After fixing that code it turned out that the communication was still unsuccessful. Apparently the USB device was not understanding the host for some reason. That should not happen since the request sent was one of the standard ones implemented by virtually anything with an USB connector, assumed that Poseidon clears the data caches before forwarding the work to the USB drivers but that's the responsibility of the driver itself.
The USB device responded and acknowledged the transmission! But why were all the request sent after address change failing with timeout? They should not. Once again, address set is supported just by anything. Tried to contact the device at address 0 once again and there it was, still responding properly. The enlightenment came. The bus address for DMA transmissions was, as it is in many bare metal USB implementations, just the pure memory address of the buffer as seen by the ARM cpu. Have "prefixed" it with the real location of uncached RAM and booted AROS once again.
Trident saw this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
and this:
Product : Vendor: Vdr=0424/PID=EC00
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 255
SubClass : 0
DevProto : 1
VendorID : 1060
ProductID : 60416
DevVers : 0200
and even this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
What are these things? The first one is USB hub built in the Raspberry. Thanks to this one the Pi machines (with exception of Pi0 and computing modules) have more than just one single USB port. The second one is the network chip in raspberry, the third one is my USB SD card reader which have just connected to see what happens. AROS tried, of course, to boot from it ;)
So, the first step towards working USB is done. The control transfers are working as you can see above. Next step is to implement bulk and interrupt transfers, having the basics in place. Finally some error handling will be added and USB for Pi will be as complete as the PC version.
[http://www.raspyfi.com/raspberry-pi-usb-audio-fix/ Issue with USB Audio]
Audio
[https://github.com/raspberrypi/linux/tree/rpi-patches/sound/arm audio] and its [https://github.com/raspberrypi/firmware/issues/2 very high speed message passing interface type of thing VCHI]
The Model B+ added an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality
the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures
Analogue audio
Audio over HDMI rev 1.3 & 1.4
Ethernet
10/100 BaseT Ethernet RJ45 socket
GPIO
GPIO shouldn't be too bad but bear in mind it is already accessed in places so they would need to allocate pins etc through it (e.g. sdcard to flicker the activity light, serial debug to output data on the GPIO pins)
Probably a resource rather than a device...
Started an i2c driver that will need to allocate GPIO pins. Feel free to work on it if you are interested ;p
GPU graphics with 2D and 3D acceleration
Sadly none yet for 32bit but for 64bit...
== References ==
===Hosted===
==== Linux ====
Change lxde to another
sudo leafpad /etc/x11/xinit/xinitrc
xorg.conf
<pre>
Section "Screen"
Identifier "Default Screen"
DefaultDepth 16
SubSection "Display"
# Viewport 0 0
Depth 16
Modes "800x600"
EndSubsection
EndSection
Section "Device"
Option "Backingstore"
Identifier "Card0"
EndSection
</pre>
Will raspberrypi ARM programs run on other ARM archs and vice-versa ? If not I would like to use different cpu names for
archs which are incompatible.
All code compiled for at most armv6 with softfp float abi will work on all softfp ARM targets, including raspberry.
Code compiled for hard-float ABI will not work on any softfp target. But then, hard-float abi uses -armhf- cpu name.
keyboard or mouse not functioning or partly working
lsmod
kernel and modules (stored in /lib/modules/ get from https://github.com/raspberrypi/firmware and click on ZIP button) have to be updated simultaneously
sudo Apt-Get Update
sudo Apt-Get Install <program >
<program > cksfv joystick p7zip-full stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 libreoffice epiphany-browser xbmc
ace-of-penguins gweled black-box petris xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis xbubble eboard&xboard (freezes) bomberclone
OMXPlayer not responding or working with keyboard or no sound audio through HDMI
LXterminal—command "OMXPlayer -o hdmi %f "
hdmi issues
Setting the hdmi_force_hotplug=1 makes sure the Pi believes the monitor/TV is really there.
You might also need to set config_hdmi_boost=4 or even higher (up to 9) if your display needs a stronger signal.
If the display is a computer monitor or newer tv, use hdmi_group=1 (auto HDMI use) and if it is an older TV, try hdmi_group=2 (for DMT formats, i.e. for PC monitors) then you HAVE to "set hdmi_drive = 2 to enable HDMI output as this forces HDMI mode rather than DVI mode
Do not set hdmi_safe=1 as that overrides many of the previous options.
Using a shorter or better quality HDMI cable might help. Make sure your Pi's power supply delivers 1 A and not 500 mA.
If you see a problem with the red colour - either absent, or interference - then try a boost
composite video
changing the RCA cable, then the composite port worked out of the box
Boot it as you are doing, without HDMI. If you now plug in the HDMI, do you get the image? In other words, does the Pi think HDMI is connected even when it isn't?
Rename all the files in the first partion of the card except bootcode.bin, start.elf and fixup.dat What's the result?
Put back config.txt What's the result?
for PAL mode sdtv_mode=2
dmi_ignore_hotplug Pretends HDMI hotplug signal is not asserted so it appears a HDMI display is not attached
hdmi_ignore_hotplug=1 Use composite mode even if HDMI monitor is detected
<pre>
# NOOBS Auto-generated Settings:
#hdmi_force_hotplug=1
#config_hdmi_boost=4
#overscan_left=24
#overscan_right=24
#overscan_top=16
#overscan_bottom=16
#disable_overscan=0
start_x=1
gpu_mem=128
</pre>
tvservice -c "PAL 4:3"
<pre>
/opt/vc/bin/tvservice -s or tvservice -s
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
(native) mode 16: 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m DMT
Group DMT has 0 modes:
</pre>
sudo amixer cset numid=3 1
forces the audio to the headphone jack, even with the HDMI video output plugged in
config.txt
the hdmi_ignore_edid_audio=1 option sems relevant as it should tell ALSA that the only available audio is analog, no matter what the display says
There are several different ways that these 4 pole (ring) composite analog cables can be wired up, so some work great in some applications and can be a waste of time in others.
What is needed for the Raspberry Pi B+ and above, which like many camcorders needs the ring contact next to the base contact to be the ground.
The wiring for the 4 pole are:
TIP (LEFT AUDIO CHANNEL)
RING 1 (RIGHT AUDIO CHANNEL)
RING 2 (GROUND/EARTH)
RING 3 BASE/SLEEVE (VIDEO) YELLOW
Most Apple based Players and the Microsoft Zune (TM) are wired this way.
Most analogue camcorders are wired this way as well, where the ground in on Ring 2 will work with the Pi although you may need to swap your Video plug with the Right Audio plug.
Nearly all other MP3 players are not wired this way, the ground is on another ring ie the wrong one.
External devices
* Camera Module Omnivision ov5647 Sunny 5MP (NoIR version) V1.3 - NoIR at 850 nm, peak at 880 nm and trails off at 940 nm wavelengths
* Camera V2 Sony IMX219 V2.1 8mpixel 8MP 8megapixel - 3280 x 2464 pixels - video at 1080p30, 720p60 and 640x480p90 - wider field of view, 62 vs 54 degrees horizontally -
* Branded WIFI usb BCM43143 dongle
N.B. dreaded error after changing cameras (stupidly without turning off the power first) and lasted through several power cycles. It can be a bad 15-pin FFC ribbon cable, when swapped, camera(s) and the Pi itself are working OK. It can be an instance of a cold solder joint on the CSI connector on the pi board. the camera can be detected (that's done via I2C) but may still not be able to receive image data (done via CSI-2) if something is broken. CSI-2 is uni-directional. Control is generally done via I2C.
The CSI-2 receiver always writes to memory, not direct to the ISP. That's the way the Broadcom architecture works as it allows multipass processing easily. GPU memory is accessible from the ARM. Processing using the QPU graphics processors may be possible. currently the only supported sensor is OV5647 and IMX219. The linux drivers are all in the firmware blob, else you'd be looking at at least a man-month of work in a fully fledged imaging lab to do a decent tuning of the camera modules' ISP parameters.
Static electricity maybe an issue for the camera module and slightly less for the pi board.
* Hosted under ARM Linux which needs to be already installed [http://www.aros.org/nightly1.php current ABIv1]
Help building AROS hosted on Linux ARM
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:
<pre>
Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic':
configure: error: C compiler cannot create executables
See config.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2
</pre>
looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.
now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)
P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.
Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.
My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.
Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.
For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.
Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.
Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh
I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:
#MM- linklibs-armhd : libklibs-aeabi-arm
Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.
I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...). Smile
To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.
With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.
3n68fa083gfhjdniqjippr56lqyb7bj
4655985
4655984
2026-08-01T11:40:52Z
Jeff1138
301139
4655985
wikitext
text/x-wiki
{{ArosNav}}
[[#Native]]
[[#Hosted]]
==Introduction==
The Raspberry Pi Foundation is a charity founded in May 2009 to promote the study of basic computer science in schools, and is responsible for developing a single-board computer called the Raspberry Pi.
The Foundation is supported by the University of Cambridge Computer Laboratory and Broadcom. Its aim is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing."
The original Raspberry Pi 1 Model B computer went on sale in February 2012 and set a new standard shattering the dominance of the PC in the home and education markets. Millions in the various formats, A, B, A+, B+ and Compute have since been shipped worldwide. The original concept of the Raspberry Pi was for a computer board providing Internet access with up to 1080p HD graphics at very low cost. The boards provide a platform for children and adults from any background to acquire computer science knowledge and help develop the future World-Wide-Web and all things internet (IOT hub and bridges out to home network to cloud of sensors).
Hobbyists and tech dabblers/tinkerers are the main purchases of the Pis (around half).
The rest of the sales are split between education/industrial. While the Raspberry Pi boards were designed primarily for education, they have become very popular with manufacturers of embedded systems. The Raspberry Pi Foundation has ensured backwards compatibility with each new revision. The bare-bones Compute module is aimed specifically at the OEM manufacturer.
* Pi 5 - Quad A76 and RP1 "southbridge" with VideoCore 7 4Gb 8Gb LPDDR4X
* Pi 4 - Quad A72 64bit VideoCore 6
* Pi 3 - Quad A53 [https://www.raspberrypi.com/documentation/computers/processors.html 64 bit] - VideoCore 4
* Pi 2 - Quad 32bit but more power consumed
* Model B+ - lower power usage but same speed as the original Pis
* Model A and B -
* Compute 1, 3, 4 and 5 - industrial use
<pre>
2008 Trustees collected for Foundation
2009 Charity status gained
2010
2011 First Raspberry prototypes
2012 First boards go on sale at CPC and RS. The Model A and B 700 MHz Arm11 - February 29th BCM 2835
2012 First million sold - more than the 10,000 original planned and anticipated
2013 First Alpha Experimental builds of AROS Native for the Pi
2013 Pi Trading launched making grants available, providing in house educational resources and Pi Academy for teacher training
2013 Over two million sold
2014 Over three million sold and updated Model B+ introduced that moved composite video to audio jack and same half gig of memory
2014 Pi Model A+ v1.1 - BCM2711 no ethernet and 1 usb - a little smaller -
2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit core and 32bit VideoCore IV 3d GPU with 1Gb RAM
2015 Over four million first gen pis sold
2015 Over a million pi2s sold
2015 Pi Zero BCM2835 released
2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837
2016 Passed Sinclair total number of computer lines sold - around 7 million
2016 Pi 3 Model B - Broadcom BCM2837 SOC four 64bit ARMv8 Cortex-A53 1.2GHz - 1Gb - bluetooth 4.1, Cypress CYW43438 wireless 802.11n and a dual 32bit VideoCore IV GPU - 4 x USB2.0 ports
2016 Total PIs over 10 million worldwide
2016 Compute 3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage
2017 12 million pis sold in total
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 - 1Gb, wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet - 4 x USB2.0 ports
2019 Over 15 million sold
2019 Pi 3 Model A with BCM2837b0 with 512Mb,
2019 Raspberry Pi Compute Module 3+ CM3+ LITE Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc
2019 Pi 4 Model B - BCM2711 quad 64bit A72 1.5GHz, VideoCore VI, AC wifi, Bluetooth 5.0, GbE, 2 micro hdmi decode up to 4K, USB-C power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram
2019 Pi 4 Model 2B - BCM2712 4 usb
2020 Raspberry Pi SC0919 Pico RP2040
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard
2020 Raspberry Pi Compute Module 4
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam
2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu
2024 Raspberry Pi Pico 2
2024 Pi 5 2GB version uses BCM2712D0
2024 Pi-500
2024 Raspberry Pi Compute Module 5
2025 Pi-500+
2026 April and May Aros 64bit fixed, added AHI audio, VC4 gfx started, usb functions added to rom
2026 June and July Aros 64bit usb2otg started, dma.resource, sdio.resource, bwfm.device wifi added
2026 Late July daily 64bit Pi3 builds start
2026 August ....
2027
2028 Pi 6
</pre>
===Good sites to visit===
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k]
*[https://github.com/raspberrypi/firmware/tree/master/https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9boot Raspberry Pi Firmware build]
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build]
*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi]
===Native===
* 2013-03 Kalamatee starts work
* 2013-05 Work put on hiatus
* 2015-04 Work continues slowly with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb
* 2018 [https://www.patreon.com/posts/i-owe-you-some-20956961 mschulz resume with adding BE big endian support as well]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=bsek latest commits for pi 3 64bit]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=jonx latest commits for pi 4]
64bit ArmV8 builds are
The status of AROS 32bit native for RasPi was OK. System booting, USB working (although with some issues but plan to fix them). Got stuck on modifying the ABI (application binary interface) and adjusting binutils/gcc to support it wanted to have real executable files but got stuck a little. This change for the type of relocations embedded in ARM files and not sure if this very type is well supported, on the other hand without this change ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.
Old native [http://www.aros.org/nightly1.html ARMv6 32bit nightlys] and
===Hosted===
[http://www.aros.org/snapshots1.html old linux and android hosted 32bit]
==Build==
===64bit===
===32bit===
# download/checkout the source someplace, e.g. /build/AROS-Src/
# make a directory to store external sources AROS downloads, e.g. /build/Ports
# make a build directory, e.g. /build/aros-raspi-armhf
# cd into the build dir, configure, and then run make -:
<pre>
>cd /build/aros-raspi-armhf
>/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
>make
>make arosboot-raspi
</pre>
then copy the files from /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ onto an sdcard, and download/copy the Raspi firmware files onto it.
You should then be able to boot the sdcard on your RasPi.
The current W.I.P tree to svn. it can be built as follows ..
<pre>
./configure --target=raspi-armhf
make arosboot-raspi
</pre>
That will generate arosraspi.img, arosraspi.rom and config.txt in bin/raspi-arm/AROS - so either copy just those files to a fat formatted SD card (with the firmware files on), or copy the whole contents of the AROS folder.
NB - if you have a Linux/other install, backup the existing config.txt first
arosraspi.img contains the bootstrap (which has very basic mailbox code, framebuffer/gpio init, and console "emulation" via code pinched from our libbootconsole), kernel.resource, and exec.library
arosraspi.rom contains all the other components needed to boot AROS.
The config.txt file will tell the RasPI bootstrap to load our arosraspi kernel and ramdisk (rom).
the bootstrap has minimal mailbox code, planning on adding either a resource or library that driver/app code will use to access it (likewise for GPIO)
==== Hosted ====
Ubuntu VM approach to compiling [http://lallafa.de/blog/2013/06/building-aros-hosted-for-raspbian/ Linux hosted AROS June 04, 2013]
../AROS/configure --target=linux-armhf --enable-includes=/usr/arm-linux-gnueabihf/include --x-includes=/usr/arm-linux-gnueabihf/include --x-libraries=/usr/arm-linux-gnueabihf/lib
arm-elf- is symbol-linked to arm-linux-gnueabi- (arm-linux-gnueabi- is more correct in this case, because it's going to be compiling the ARM AROSBootstrap for ARM Linux)
*armel - many of the "android" machines require since the entire OS is made for soft float VFP.
*armfp - Efika MX target, Raspberry PI, EfikaMX, Pandora and virtually everything (VFP)
Keep in mind it's possible to start hardfp AROS hosted on softfp system, though, as long as no calls between AROS and host require floating point parameters. NOTE: hardfloat objects *cannot* be linked with softfloat objects - they have a different ABI.
Just keep in mind the arm nightly build machine is quite complex beast. It needs the x86_64 host compiler to compile AROS tools. The arm version is built every night using gcc-4.6.2 crosscompiler (built together with AROS) and successfully builds armel and armhf linux hosted targets.
*needs an AROS code compiler for ARM target
*as well as unix compiler for ARM linux host (would be best to have both softfp and armhf, we have softfp only now) with full set of libraries and includes.
with—disable-crosstools $AROS_CC is always a wrapper around $KERNEL_CC ? If so, this is wrong for some ports. This can break Darwin, Windows and Android port.
Yes, Android port will build. And even work. But it's not good because the port will not be ABI-compatible with other ARM ports. Android's ABI is different from GNUEABI. For example:
<pre>
enum test {foo, bar};
enum test testvar;
</pre>
siseof(testvar) will be equal to sizeof(int) in GNUEABI (Linux and AROS) and sizeof(short) on Android. This affects linking objects from static linklibs, for example.
Previously everything worked because $AROS_CC was a wrapper on top of $HOST_CC. And a real crosscompiler was used on non-ELF hosts.
Android is the same. $KERNEL_CC is incompatible with AROS.
compiler=kernel is appropriate _ONLY FOR CODE WHICH RUNS ON HOST OS_ (or barebone hardware, if we talk about native). This includes bootstraps, their linklibs, and host-side dynamic libraries (Windows makes extensive use of them because of architectural considerations.
No single AROS object should be compiled with this setting. $KERNEL_CC is really compatible with AROS *ONLY IN LINUX-HOSTED* and no more. On other systems (Darwin, Windows, Android) this is not true any more, and compiler=kernel is never going to work.
If you want to compile your AROS module against host OS includes, append the following to USER_INCLUDES (or USER_CFLAGS, this is effectively the same):
-isystem $(GENINCDIR) $(KERNEL_INCLUDES)
$(KERNEL_INCLUDES) expands to:
-isystem <your_os_includes> -isystem <host_OS_gcc_private_includes>
-nostdinc
This makes AROS compiler adhering to host OS APIs.
If you want some preprocessor symbols based on what your host OS actually is, add something like -DHOST_OS_$(AROS_HOST_ARCH).
Why is there $(GENINCDIR) at all? Because host OS has its own libc includes, which would conflict with AROS ones. And the host OS libc is not binary-compatible with AROS one.
Why doesn't Windows-hosted port use $(KERNEL_INCLUDES) ? Because WinAPI includes conflict with AROS ones in fundamental typedefs, like WORD, BYTE and BOOL. It's almost impossible to deal with this in any other way than rewriting WinAPI definitions using AROS types.
Building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. haven't yet committed the necessary changes but "./configure --target=raspi-armhf" is enough to start, then "make arosboot-raspi" will generate arosraspi.img (containing the bootstrap, kernel.resource, and exec.library) as well as arosraspi.rom (containing all the other essentials components such as dos, graphics etc). It will also copy over a config.txt file to make the raspi bootstrap code load the correct kernel, and a cmdline.txt that enables exec debug output.
*armel = typically Debian 6, Ubuntu Maverick, Android,
*armhf = typically Debian 7, Debian 8, Ubuntu Precise,
Cross-compiling Ubuntu ARM softfp
<pre>
sudo sh
echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
</pre>
<pre>
./configure --target=linux-arm --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabi/include
</pre>
Cross-compiling Ubuntu ARM hard-float
<pre>
sudo sh
echo 'foreign-architecture armhf' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armhf.list
apt-get update
apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
</pre>
<pre>
./configure --target=linux-armhf --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabihf/include
</pre>
Now, the AROS build is configured properly and all you need to do is:
make
[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]
== Hardware ==
===64bit===
====BCM2712====
BCM2837
* Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support, 3B+ [https://github.com/aros-development-team/AROS/commit/afa5bc0bb17d5dd06bcfdbac00853a3799ca8d76 LAN7515]
====BCM2711====
===32bit===
=== Core Kernel ===
the reason behind INTB_KERNEL is to allow use of the standard Exec function AddIntServer() to add interrupt handlers for
hardware drivers etc. AmigaOS never used it for abstract hardware drivers. AmigaOS routed only raw hardware IRQs there. Their assignment was hardcoded. As well as number of them. Actually on AmigaOS every bus has its own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt. 1:1 relationship between CPU and hardware interrupts is present only on PC.
IMHO we miss things like AddInterrupt/RemInterrupt methods on our PCI subsystem's device class. PCI bus class should map these methods to whatever is appropriate. This is how it is done on AmigaOS and friends. When these are implemented, raw kernel.resource API will be needed only for several PC-specific drivers with hardwired resources. Exec IRQs are real IRQs only on Amiga hardware. On other machines they can be emulated where appropriate (VBlank is a good example). kernel.resource is meant to be different, its IRQs are hardware-agnostic, they are plain "Hardware IRQ number X, whatever this means". They are low-level actually, and meaningful only in the context of a particular system.
Was that not the transition from irq.hidd to kernel.resource? No. A long time ago there was another hacky bit named INTB_TIMERTICK. It was "abstract timer interrupt", used by timer.device. It was the same as VBlank, but with larger frequency. I removed it, because kernel.resource API was a cleaner way to access this interrupt. Furthermore, there can be more than one timer in the system. I am even thinking about bringing back timer HIDD definitions again. hpet.resource is a bad idea.
Can someone please enlighten me a little on how the scheduler is meant to work?
Poseidon.library creates its "Poseidon Event Task" during RTF_COLDSTART -> then calls Wait(), and ends up in limbo because wait disables interrupts (used for the scheduler heartbeat), and basically waits forever because the sigbit is never set, since krnSwitch doesn't switch the task unless TF_SWITCH is set, and no codepath run during this seems to set it?? TF_SWITCH does not disable/enable switching. This flag just enables to run user-supplied hook when the task is being switched away. It is completely safe to call Wait() in Disable()d state. Doing this actually temporarily breaks this state. IDNestCnt gets remembered in struct Task, then next task is selected, and its IDNestCnt is restored in sysbase (see kernel_scheduler.c). If there are no other tasks, then your cpu_Dispatch() should enable interrupts on the CPU and enter idle mode. See x86 implementation for good example.
You miss what happens next...
1. KrnSwitch() saves context of your task, saves IDNestCnt (core_Switch() and cpu_Switch()), then drops into cpu_Dispatch().
2. cpu_Dispatch() calls core_Dispatch. Then two cases are possible:
2a. There is a READY task. It is picked up, its IDNestCnt is restored in SysBase, then cpu_Dispatch() needs to restore registers and exit. The next task is run.
2b. There are no READY tasks. core_Dispatch() returns NULL. In this case your cpu_Dispatch() should enter idle loop. It should just enable interrupts on the CPU and put it on halt. This allows it to process hardware interrupts. Eventually some of your interrupt handlers wakes up your task and puts it into READY list.
My heartbeat interrupt has been slowed atm to help debugging - but it never actually gets a chance to fire because of the Wait() disabling interrupts. Perhaps you have forgotten to enable interrupts in your idle loop.
There is a change in the format of AROS executables. Until now we were using Elf RELocable files which are usually used as intermediate object files. We had them for various reasons, one of them was how AROS files were built in the past. That days we had no real aros cross compiler and the option to embed relocation data in unix executables (or in executable files in general) was rather new and not every linux/unix system had it. Therefore we have decided to use intermediate files. Although it was somehow working (and it is still working :-)), it has some drawbacks. Therefore decided to introduce real Elf EXEC types, in first turn implemented on ARM target with option to expand in future to all other AROS architectures.
The first patch was pretty easy and appeared to work somehow. It generated nice executables with embedded relocation info. Not only that, it also removed all global symbols adjusting relocation data to be relative to the beginning of the sections. That move reduced number of symbols in each executable significantly (depending on the file between 20 and 80% of all symbols could be removed). The only symbols that stayed in the file are local ones - due to the nature of the patch wasn't able to remove them since we have not seen them in the symbol hash table.
The patch didn't worked though. The files were relocated, AROS kernel loaded, but it crashed very early. What happened? Well, the nature of ARM relocations happened :)
Most of the relocation data on all machines is rather simple. Relocation can be absolute or pc-relative, sometimes the offset has to be bit shifted. On ARM v7 there is another one. There, when one wants to load an address of function/variable into register a combination of two instructions can be used: movw and movt. The first one loads immediate into lower 16 bits of a register while clearing upper 16 bits. The second one loads immediate into upper 16 bits without touching lower halfword. Loading of a pointer into a register looks like this:
movw r0, #:lower16:label
movt r0, #:upper16:label
In this case there are two relocations - one for lower halfword and another for upper. If an overflow of lower 16 bits occurs during relocation process, the upper one should be updated as well. Unfortunately with current patch and with typical ARM executables there is not enough information to perform the calculations.
There are two options - the first one would be to give up and go back to "fake" executables, another one would be to change from REL to RELA relocation info. The latter contains an addend, extra data which can be used to perform all the relocation calculations I need.
Decided for the second option. The patch is already in the works. There is another function for the binutils' bfd backend to perform the final relocation. There can decide what to do with every reloc info, modify data and eventually strip some symbols. An advantage is - at this stage of the linking process have also full access to all local symbols so can change all relocations section relative and eventually strip all symbols from the files.
=== GPU ===
Most of start.elf runs on the GPU. Placing ALL the userland GPU code in the videocore.hidd isn't going to be a terribly big problem because the code they published is nothing more than a shim that sends data straight to the GPU to execute.
The good news about this is that we only need to write our HIDD using the OpenVG API. The shim is relatively small codewise and lives in the ARM memory (the actual OpenVG code itself lives in the GPU RAM area and its loaded from start.elf). That's also the bad news. Our driver has to translate AROS video calls to OpenVG calls, for most tasks it should be easy, for some, not so much. It's still probably less difficult and less work, than controlling the GPU directly.
The other good news is that anything done through OpenVG happens on the GPU, its truly accelerated. It also has some nice font functions, meaning we can lead into an accelerated text mode later.
Basically, AROS resets or locks up when it tries to use AROS_ATOMIC_INC or DEC. If I comment out the byte/word operations in the header files and use non-atomic operations, the code works as expected.
have read that the L1 cache needs to be enabled to use LDREX and co (which I also read is only meant to be used on multi processor systems with shared memory) - however I am certain this is correctly enabled.
If you are using LREX or STREX, you should have L1 cache enabled, at least on the ARM CPU I work with at work.
L1 cache is enabled by enabling the MMU *AND* setting the C and I bits in the CPU - the C bit is ignored, and the I bit only covers the 16 byte instruction pipeline if the MMU is not enabled.
Can you verify that your assembly is generating LDREX/STREX? From the behavior, it almost sounds like its generating the default Semaphore locked atomics.
Impossible. There are no semaphore-locked atomics. There are Disable()/Enable()-based ones instead. And there's a special #define AROS_NO_ATOMIC_OPERATIONS in this case, which tweaks Disable()/Enable() implementations not to recurse forever.
I have tested this on ARMv5 which does not have ldrex/strex, it works fine. On those ARMs there's no way to have real atomics. On other OSes (like Linux) this is done by introducing things like atomic_t, which appears to be a complex structure, holding the value together with accompanying spinlock (implemented using swp).
#warning "TODO: lookup optimal mmu table settings for raspi memory"
/* Set up an identity-mapping for all 4GB */
for(x = 0; x < 4096; x ++)
{
pagetable[x] = x<<20 | (0x40002|0x80000|0x010000|0x00C00|0x04);
}
Shouldn't there be a second loop that sets the 'C' bit in the descriptor for the RAM pages?
Currently, you have TEX=0, C=0, B=1 for all pages (Shared Device).
You should have TEX=0, C=1, B=0 for RAM (Write-Through, Cached)
So ..
pagetable[x] = x<<20 | 2;
should be enough?
No, for RAM you need to change the '| 0x40' to '| 0x80'
tell dosboot the correct defaults to use
Please don't do this. This bootconfig.c is a deprecated legacy thing. I wanted it to go away completely with time. Instead, display drivers should auto-install themselves during own initialization phase. I. e. detect hardware=>instantiate itself. This should make things way simpler. With this approach you only need to add the driver into KS image to get the device autobooted. No
hardcoded stuff.
Currently VESA and VGA drivers do this, look there for examples. never rewrote ATI driver because i don't have any test system for it.
they defined a smaller AROSCPUContext than the ExceptionContext - yet reference it as ExceptionContext in other places, and since it hasn't allocated enough storage for ExceptionContext, are corrupting memory/the structure (since the elements that are there don't map 1 to 1 with the exception context).
AFAIK, AROS has been moving in a different direction to this in recent
years. It is the job of graphics HIDDs to allocate bitmaps etc. so that
they have the most suitable characteristics, including allocating them
from GPU RAM where possible. The concept of chip RAM is only for legacy
code, and most if not all non-68k platforms should have all system RAM
marked as chip.
BTW, is the video processing code you mention CPU code or GPU code?
Also, IIRC we have support for "external memory allocators". Perhaps that's what we need for the allocation of GPU RAM through the mailbox.
All hosted and x86 native ports should use proper context formats.
trying to clarify if the vblank handler has to have run by this point to prevent this deadlock. Actually, no. Unless you have installed VBlank handler which should wake up at some point. Without VBlank there will be no quantum count. Consequently, there will be no forced preemption. But the rest will work, and multitasking will be cooperative (switch happens only when current task voluntarily gives up the CPU). Does it depend on the vblank having run before this point? and if yes what does that mean on systems where it might be able to run enough code (e.g. get to this point) before the vblank interrupt has triggered? What is it waiting for? It could wait for timer, in this case you need timer.device working. VBlank is currently needed for exec's quantum counter. In current native ports we have only a single timer, which is served by timer.device. VBlank is simulated by timer.device also. If your machine has two timers, then you can use one of them for VBlank, and another for timer.device, this will simplify things down. VBlank needs to be 50 Hz for historical reasons, many programs use it as cheap timer. I am periodically thinking about making some abstract mechanism to be able to change quantum source (and untie it from 50 Hz), but have no time to come up with something good. Additionally i started disliking timer.device hardcoded design when PC has got many timers (old 8253, APIC, HPET).
Currently i think there should be some low-level entity representing tick source. timer.device should just select the most appropriate source for its units.
The BCM2835 has 4 GPU based timer sources - 2 are used by the GPU, so im using Timer3 for our heartbeat and the remaining one will be free to the system. There is also the less capable ARM timer but that is dependent on the CPU frequency. Very good. You won't need any emulation. Set the heartbeat to 50 Hz and drive VBlank from it. Use other timer for MicroHZ.
Can you use the 'econsole.hook' I make for debugging the Sam460 via the serial port?
It provides a before-anything-else shell prompt on the serial port. You can then do 'NewCLI' to test your graphics, or use any DOS command in shellcommands.resource.
You should just be able to add econsole.hook to your module list, and use 'econsole' in your bootargs.
So long as you have a working Exec/RawMayGetChar and Exec/RawPutChar, it should work.
Also make sure to add shell.resource and shellcommands.resource for this.
That should have done it.
If you set "#define DEBUG 1" in arch/all-native/econsole/econsole.c, do you get any additional serial output?
have added it to the build and added econsole to the command line - and can see the bootloader picks up on the emergency bootconsole tag, but I still only get the insert bootable media display?
Im assuming it exposes a fake filesystem that tricks aros into booting?
The contents of which are: ECON:AROS.boot
Way to handle the scheduling code? The implementations I had been following were causing problems, due to cascading interrupts which I cant handle properly in the asm stubs just now (when they break disable etc.) - since it means detecting the interrupted codes cpu mode and getting the correct sp/lr for it, and that's just too tedious for arm.
To work around this ive added a system idle task which does nothing - and when the scheduling code has no task to run switches this in and lets it run, thereby allowing the interrupts etc to resume until something does need to happen.
Also, by adding accounting code to cpu_Switch() and cpu_Dispatch(), it should allow the system to log idle time correctly (as well as running tasks).
have thought of also adding an additional task that never runs, solely to record time spent in IRQ handlers, but I digress..
was under the impression that kernel.resource should *never* be used outside of exec.library. This is a wrong impression.
Michal started designing it because portable nature of AROS does not fit well into exec's API with all its assumptions. So, he started the new, hardware-agnostic kernel API from scratch. Yes, exec sits on top of it in places. But kernel always meant to be open thing. Otherwise it would not exist.
it wasn't meant to be just used willy nilly by user code - but by lower system components (e.g. exec) so that they could be implemented in a more generic fashion, and the kernel resource itself hide the systems quirks.
Adding new things there perfectly keeps up with our decision to minimize AROS-specific intervention into APIs which can clash with MorphOS/OS4 extensions. We want at least source-level compatibility there. Binary compatibility on PPC would be extremely cool, but at the other hand we have no maintainer for this, as well as their ABIs are a bit weird and far from optimal, especially MorphOS one, because it aims for m68k binary compatibility.
It depends on what exactly is being implemented - there's no reason we should have everything crammed into kernel.resource if it doesn't need to be (i.e. if its better suited as a separate component/subsystem in its own right)
The _LE versions are for when you have endian swapping taking place. If the graphics are the same endian as the CPU, no swapping should occur. I ran into a similar terminology problem in SDL with a friend insisting that his Radeon 7000 on his PC was big-endian. It is not, it just uses the same endianness for the graphics card and the CPU so no swapping was necessary. They were both little-endian.
The _LE versions are because the PixFmts refer to the bitmap data being in big endian format in memory, for which the normal version would need to do endianness conversion before applying the shifts/masks. on this platform it is in _LE in memory also so we don't need the conversion hence using the _LE version of the call). would use _LE (if it's really little endian 16 bit mode).
What is the bare minimum needed to implement a framebuffer based gfx driver, with our software handling the rest?
I have tried with just a gfx class that only expose new/dispose/newbitmap - and having an onscreenbitmap used only for the framebuffer itself (with all other bitmaps being chunkybm, and the framebuffer's superclass also being chunkybm), but that alone isn't enough it seems?
You can use workbench/hidds/sm502/ as your example - it is as simple as I could make it.
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
I so far have -:
vc_init: queries the gpus memory, and sets up a fake memory handler for it, then adds the bootmode driver and returns saying all is well
vc_gfxhidd:New: sets up some fake syncmodes to test with and creates the real gfx object.
vc_gfxhidd:NewBitmap: checks if its a framebuffer and uses the onbitmap class or uses the chunkybm class otherwise
vc_onbitmap:New; creates a chunkybm object and then pushes the real framebuffer address into it as the buffer,
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
The code I currently have on SVN seems to create the framebuffers bitmap object fine, but then crashes in intuitions DisplayDriver callback. In particular it crashes performing the getattr on the system default pointer.
don't expose MEMF_CHIP in an allocatable form so AllocSpriteData was failing (and other code later doesn't check if the values are valid == illegal memory accesses)
Actually MEMF_CHIP has to present, for historical reasons.
This has been never fully agreed upon, but in ports i wrote i exposed the whole memory as MEMF_CHIP. The idea behind this is that CHIP is originally the memory where graphics and sound data can be put. On non-Amiga platforms there are no restrictions on this, so the whole memory is CHIP.
Yes, many old software can misbehave with CHIP memory size larger than 2MB. But this actually applies only to m68k AROS which is going to run m68k binaries. In other cases it's quite logical to fix the program when porting.
As to original question: yes, it's enough to have a framebuffer bitmap (one with aoHidd_BitMap_FrameBuffer set to TRUE) and PutPixel routine. It framebuffer can be served by chunky bitmap class, then you can simply create chunky bitmap with your own buffer (see how VESA driver does this). Chunky PutPixel is already there.
struggling to determine what is the correct pixfmt to use for the 24/16/15 bit gfx modes on the RasPi. AFAIK it uses RGB565, for 16bit but im unsure what shifts etc should go with it? suffice to say Im getting the wrong colors so far lol.
<pre>
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0
redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
</pre>
It should likely be vHidd_StdPixFmt_RGB16_LE
This stuff is a bit confusing. The "names" of the stdpixfmts are based on the layout in memory,
ignoring endianess. So for example:
ARGB32: will be 0xAA 0xRR 0xGG 0xBB in memory on both big endian and little endian machines.
The shifts and masks OTOH are based on pixel access (ULONG in this case), so differ depending
on whether you run on big endian machine or little endian machine (that's why there's stdpixfmt_le.h and
stdpixfmt_be.h in rom/hidds/graphics/).
With the 16 bit pixel format it's even more confusing, as for example it's impossible on little endian machine
to describe RGB16 with shifts/masks alone. That's why there's vHidd_PixFmt_SwapPixelBytes_Flag.
(RGB16 == RRRRRGGG GGGBBBBB in memory, and for pixel (WORD) access on little endian machine it needs to
be accessed as GGGBBBBBRRRRRGGGG).
The shifts btw indicate how much to shift the component to the left (!) so that it is moved to the highest bit (31).
The aHidd_PixFmt_StdPixFmt you specify will be ignored most of the time, because when the pixelfmt is registered,
the gfx hidd checks if there's an identical pixfmt (shifts/masks/etc., but ignoring pixfmt->stdpixfmt) already in the system,
and if so, it uses the already existing one and does not create a new one.
In theory it would be better if gfx drivers could simply/only specify a StdPixFmt without all the shifts/masks stuff when the
gfx driver uses pixfmt which matches one of the stdpixfmts exactly. Another possibility would be for gfx drivers to use
HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) and then peek shifts/masks from it and fill out a pixfmt
tag list based on that.
15bit very blue/green: Try to pass same shifts/masks/etc. as in 16 bit pixfmt (maybe you think it's using 15 bit R5G5B5
(or swapped) but it's actually still using 16 bit R5G6B5 (or swapped).
aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count.
But I would still pass the correct one (_LE) == whatever rom/hidds/graphics/stdpixfmts_??.h uses
in the entry where you have looked up shifts/masks/etc.
Use the shifts/masks/etc. from the entry in stdpixfmt_le.h (if you are running on little endian machine) or stdpixfmt_be.h (if you
are running on little endian machine) that matches the pixfmt that its meant to be.
0xAA,0xRR,0xGG,0xBB on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)
0xAA,0xRR,0xGG,0xBB on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_BGRA32)
it feels like AROS trashes the alpha component, otherwise it should be 8A8R8G8B.
read on the subject suggest its in 1x5r5g5b (x is ignored) to keep 16bit alignment .
What I see on screen suggests to me that wrong shift/mask are being applied - however going by the 16bit versions it all looks correct to me so I am really confused as to what is happening.
The output image looks to have too much green/blue, and very weak red.
Why did usbromstartup become HW-specific ?
In the past i have done a big job separating kickstart into several parts. I have never got any responses, so i re-describe my idea.
For now it loads the hs otg chipset driver ..
The idea is to minimize amount of archirecture-specific modules to
make user's life easier. So, the kickstart was split into 'base'
(which does not contain anything machine-specific) and 'BSP' (Board
Support Package) which contains all hardware-specific stuff.
This way, for example, distribution makers can save up space on CD
and make CDs with multiple platform support. Different configuration
would load the same base with different BSP's.
Next there was some part which is entirely missing on hosted. These
are filesystems. Hosted ports do not need them to boot up, so on
hosted they are left out. At the other hand, they are also
architecture-agnostic. So i put them into 'FS' package (standing for
'filesystem').
Poseidon is one more big part. I made it into separate package in
order to allow users to omit it if they don't need it (for example, to
run on retro PCs without USB). Personally i have one. Again, Poseidon
is hardware-agnostic (well, there are USB drivers but HCIs are pretty
standard).
It's mandatory on PI since there are no other interface types - so being a separate package is irrelevant/pointless.
Is Raspberry's USB controller non-HCI compliant? Actually i expect it to be compliant, then wouldn't it be better to make existing drivers discovering them?
AFAIK its HCI 1.0 compliant but I'm not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once i'm more familiar with the workings I can merge in the changes needed to get it operating but for now I will focus on getting it running. Also our drivers have known issues so perhaps a fresh set of eyes might shed some light on what is going wrong.
Another interesting question is whether Poseidon can operate on device side. Is it flexible enough? How similar is being a USB host and USB device? think it will need a bit of work on Poseidon's side. Until then I will force the driver into Host/Master mode in the init code, but leave open device etc to configure the chipset for either's use - and look at trying to add support for working in Device/Slave mode & switching modes once it's up and running.
Actually USBROMStartup is some kind of kludge. Can there be any alternative? Could device drivers be self-installing, like our HIDDs? This would get rid of need to list them in USBRomStartup.
And there is one more thing about modular ports. In order to actually implement this, your bootstrapping environment should provide the ability to load several files. On PC this is provided by GRUB2. on CHRP you can read filesystem via OpenFirmware, and Sam's Parthenope relies on modified u-boot. If your bootstrap allows to load only a single file, then you stuck with monolithic kickstart. By the way... u-boot allows not only to boot up a single uImage or zImage, it also allows to write client programs AFAIK. With this approach, you actually can write modular bootstrap for ARM AROS using unmodified u-boot.
[http://repo.or.cz/w/AROS.git/commit/e7bdc7e7b7f12b07aa24c739abb63721a872a53a arasan eMMC sdcard controller specific header which is not USB] and [http://repo.or.cz/w/AROS.git/commit/8bd19674084526a534ac11f7d4c51932e9ffe3d2 added prelim sdcard device]. [http://repo.or.cz/w/AROS.git/commit/9ab8217f61911fb8b7fd41bee46a992b4668ced1 do not set 4bit data mode, or enable acmd12/dma int's]
====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM)
*Framebuffer (fb) using mailbox
*IRQ scheduler, etc
*Arasan based SD Card controller
*Synopsis DesignWare USB 2.0 OTG controller [http://networkdirection.net/index.php?option=com_content&view=article&id=106:rasperry-pi-usb-controller&catid=45:raspberry-pi&Itemid=54 Unofficial DOCS pdf], [dwc_otg.c FreeBSD], [], [https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/Controllers/DWCDriver/ RiscOS USB Driver], [https://www.riscosopen.org/forum/forums/5/topics/878 RiscOS USB Discussion], [https://www.riscosopen.org/forum/forums/11/topics/1893 Other USB RiscOS], [http://plan9.bell-labs.com/plan9/index.html Plan9 Miller's usb] http://plan9.bell-labs.com/sources/contrib/miller/, [https://github.com/Chadderz121/csud CSUD driver],
*[http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf SMSC 9512] USB LAN/Hub chip
*CMOS RAM
*VCHIQ port which sends messages to the GPU e.g. for mouse, keyboard, audio on HDMI, etc
*Audio Driver
*Serial Peripheral Interface Bus (SPI)
*[http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/ I2C registers]
*I2S
*Universal Asynchronous Receiver Transmitter (UART)
*[http://elinux.org/RPi_BCM2835_GPIOs GPIOs] and [http://www.adafruit.com/blog/2012/08/17/broadcom-bcm2835-peripheral-memory-map-and-gpio-alternate-use-chart-piday-raspberrypi-raspberry_pi/ Alternative view of GPIO]
BCM2836
* For Pi B+, PI 2 and Pi 3 SMSC LAN9514 chip adding 10/100 Ethernet connectivity and four USB channels to the board
The overclock ability has diminished with each chip version as the energy usage has very slowly risen. BCM2837 is one of the warmest yet and might benefit from active cooling (ie fan) if all four cpu cores are in use for a short while. Video playback is not affected due to the custom support in the GPU. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur.
*[http://www.andrewscheller.co.uk/rpi_pcb_modules.html PCB], [http://elinux.org/RPi_Low-level_peripherals Low level features],
Implemented so far...
# Modify the configure system so that it correctly builds for the arm hardware float raspi target.
# Implemented the bootstrap to load the aros modules and prepare the arm to jump into them. Reworked the x86 console support so that parts can be stolen for raspi to use since t has no basic functionality to output to the display.
# Implemented a kernel.resource to prepare the raspi for running aros and provide the low level api calls to expose available resources and allow exec, etc function.
# Implemented serial debug support
# Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc)
# Implemented a timer.device to utilise the hardware timers.
# Implemented a very basic gfx driver to expose the hardware's framebuffer.
# Implemented an SD-Card driver for AROS which presently only supports the raspi's chipset but can easily be modified to support all sd-card hardware and media.
# Fixed the fat filesystem support in AROS so that it can boot on RasPi's normal SD-Card setup. The "rom" image files needed use a different filename than the default linux, etc images so can be easily installed without harming the existing files - you only need to change the loaded images in the config file to get aros to boot.
# Updated the build scripts to automatically download the necessary raspi firmware files and wrap it all up so that you can simply extract the archive to a fat formatted sdcard and boot it on the raspi without having to get anything else.
# fix everything in contrib and ports to build for raspi (needs proper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi ..
Improvements...
# Implement a USB chipset driver "OR" finish the existing one [https://github.com/aros-development-team/AROS/commit/c07d13c724f944674be5db54fc6a71ee72a01809 usb otg] - the current code is mostly a skeleton that should initialise the chipset and then needs relevant code to support the different transfer types. It also has the "virtual" hub code in place to represent the raspi's USB port (from poseidons p.o.v)
# Implement a driver for the USB NIC (a few weeks - depends on USB above)
# Write an [https://github.com/aros-development-team/AROS/commit/d55d0f74d20b769bbb8c8d386e5c1d7a9154f05a audio driver] (a few weeks - independent of USB) and [https://github.com/aros-development-team/AROS/commit/e93a4c245f27a87c9c4c1d39206694b39059998a HDMI]
# fix syscall bug in the current raspi kernel code
# Graphics depend on having a decent "bcmdma.resource" implemented as to use the cpu's dma engine. The sd card driver needs to use it for transfers to/from the controller - and the gfx system needs to use it for "blitting".
# [https://github.com/aros-development-team/AROS/commit/4019d84e4975d4dad987a12d57fe108f5ac048e6 Improve the gfx driver], [ vc4gfx HIDD] add [http://dri.freedesktop.org/wiki/VC4/ Gallium3D support]
# [https://github.com/aros-development-team/AROS/commit/b13905b3e8e45b089f520b44692c81affddd066f Improve] the [https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9 sdcard] device driver - which is also pretty basic but should work with most cards, rework it to also support pci, etc. sd card interfaces on x86
# The current code using very rudimentary access to the gpio interface - so that should be implemented as some resource for other components to access, as-well as the i2c interface exposed over the gpio interface. that should have a hidd class implemented which uses the gpio resource to communicate.
Boot up
On power-up, the rpi [http://www.open.com.au/mikem/bcm2835/ BCM 2835] [https://github.com/hermanhermitage/videocoreiv VideoCore4] GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the BCM2835's VideoCoreIV GPU PROM requires a DOS-style partition table; a FAT-formatted first partition; and the freely redistributable but closed sourced Broadcom files “bootcode.bin” and “start.elf” in that partition.
The boot sequence carries out several pre-boot tasks
*On powering of the rpi, the GPU reads and executes bootcode.bin, which then loads start.elf
*The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it
*configures the memory split for the CPU and GPU
*reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings)
*loads the “kernel.img” file, again from the same partition
*activates the CPU to begin executing the loaded kernel image
The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU.
RPi uses [https://github.com/raspberrypi/firmware some closed source loaders] and at some point it loads a binary blob named "kernel.img" at 0x8000, at that point there would be a rudimentary Aros alive. If one wants to use the SD-card then there would have to be a driver for the interface and a fat filesystem handler (SD-card has to be formatted to fat filesystem)
Boot code and kernel are now linked together and made into that binary blob, just for starters. Raspberry Pi uses [http://kernelnomicon.org/?p=133 u-boot] and [http://kernelnomicon.org/?p=138 UBoot] as bootloader, there's already some code in the Efika MX port for that. UBoot is a native bootloader and not just for the raspberry pi, it loads after start.elf.
You can find Efika MX port from arch implementations, some hacking is needed for the mmakefile.src'es as iit dates back to before the Aros crosstool era or else you get some weird errors while building. You also need to code the bootstrap and serial handling.
At the moment it seems that a fastest route for the native build would be to make one binary blob without using the package system. Raspberry's memory layout is pretty simple and if the implemented u-boot doesn't support loading other modules
<pre>
? - alias for 'help'
mtest - simple RAM test
autoscr - run script from memory
base - print or set address offset
bbm - BBM sub-system
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
jade -
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv - print environment variables
rarpboot - boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saves - save S-Record file over serial line
setenv - set environment variables
sleep - delay execution for some time
tftpboot - boot image via network using TFTP protocol
USB - USB sub-system
usbboot - boot from USB device
version - print monitor version
</pre>
Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,
Framebuffer - basic display
RasPi has to speak to the "operating system" which runs on the GPU itself and request/free memory - it cant directly manage it itself, and so the managed functions were used to wrap these calls.
The Arm and GPU share memory space. The framebuffer is shared. The Arm can write a pixel and it will appear on the screen (through GPU hardware) without flushing/copying being required.
The GPU can composite multiple FB's in real time - so you have a number of surfaces defined which are rotated etc and composited in real time to the output. Copying can map from the address space of the Arm to the flat space of the GPU which takes some code, but I don't think whole buffers are copied.
The DMA hardware can also access the whole memory space and can perform 2D fills and blits (no blending). This is documented in the peripheral spec posted. The DMA is just an Arm accessible peripheral and can be set up with low latency (e.g. microseconds).
must use a 0xc0000000-based bus address to access SDRAM, yet non-DMA access should go via a 0x0-based bus address.
For 2D dma, set TDMODE, and the spec says "interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer." so set STRIDE to pitch of the image, the width is XLENGTH and height is YLENGTH. You would fill by not setting the SRC_INC and point source to your fill data.
The DMA cannot see the ARM's L1 cache, so you would map the framebuffer with ioremap_nocache. Depending on where the source data comes from, it may need an L1 cache flush. The DMA can see the L2 cache. Use 0xC0000000 bus addresses when L2 is disabled and 0x40000000 bus addresses when L2 is enabled. (actually just call virt_to_bus and you'll get the right address out).
openGLES/openVG has high latency. Writing to framebuffer then reading it back is very inefficient (e.g. milliseconds). If you can drive it a unidirectional way, just streaming commands at then that is efficient. openVG is not implemented on top of openGLES - it uses the same hardware but as a first class interface
To improve the Gfx driver, we will need a DMA resource implemented so can use to perform DMA operations. The Gfx driver will need this to perform blits.
USB
* Model A and B limited to 150 mA per port.
* Model B+ and Pi 2 introduced configurable 600 mA to 1.2 A support over all ports - anything above that requires a powered USB hub.
Implementing the hardware driver that Poseidon uses to interact with the USB components.
Have code in place to (try) and initialise the USB chipset, and configure host/device mode operation (though AFAICT Poseidon doesn't support device mode). Started to get the "virtual" root hub written for the single USB port so that Poseidon should at least list it correctly in the GUI - and try to interact with it to find peripherals.
The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”).
There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA. However, there's a Linux driver written by Synopsys ([https://github.com/raspberrypi/linux dwc_usb]). Specifically directories [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_common_port] and [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_otg].
The Synopsys code is actually under a fairly permissive licence – it's not GPL, it's similar to BSD (’don't sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code.
The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port).
Probably only need provision of relevant changes to dwc_common_port. Other things to consider....
* Provision of necessary headers to get it to compile
* Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes (multithreading) )
* Interfacing between USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start.
the Linux bits of the headers are only required for the dwc_common_port library. dwc_common_port includes a variety of crypto functions which are not used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn't going to be for plain wired USB.
Every USB driver acts as an USB hub as well in order to let Poseidon control the state of USB ports. The code there was reading status of the only USB port in Raspberry's CPU but when changing the status it erroneously deleted some of the status bits, including the port enable one. It was so because those bits in the status register are of a type Read/WriteToClear. It means, if one does not want to change their value from 1 back to 0, one has to actually write the 0 value. Very practical thing e.g. in interrupt handlers, where one reads the interrupt status register to learn what was the interrupt reason, and writes it back to the same register in order to clear the interrupts.
After fixing that code it turned out that the communication was still unsuccessful. Apparently the USB device was not understanding the host for some reason. That should not happen since the request sent was one of the standard ones implemented by virtually anything with an USB connector, assumed that Poseidon clears the data caches before forwarding the work to the USB drivers but that's the responsibility of the driver itself.
The USB device responded and acknowledged the transmission! But why were all the request sent after address change failing with timeout? They should not. Once again, address set is supported just by anything. Tried to contact the device at address 0 once again and there it was, still responding properly. The enlightenment came. The bus address for DMA transmissions was, as it is in many bare metal USB implementations, just the pure memory address of the buffer as seen by the ARM cpu. Have "prefixed" it with the real location of uncached RAM and booted AROS once again.
Trident saw this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
and this:
Product : Vendor: Vdr=0424/PID=EC00
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 255
SubClass : 0
DevProto : 1
VendorID : 1060
ProductID : 60416
DevVers : 0200
and even this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
What are these things? The first one is USB hub built in the Raspberry. Thanks to this one the Pi machines (with exception of Pi0 and computing modules) have more than just one single USB port. The second one is the network chip in raspberry, the third one is my USB SD card reader which have just connected to see what happens. AROS tried, of course, to boot from it ;)
So, the first step towards working USB is done. The control transfers are working as you can see above. Next step is to implement bulk and interrupt transfers, having the basics in place. Finally some error handling will be added and USB for Pi will be as complete as the PC version.
[http://www.raspyfi.com/raspberry-pi-usb-audio-fix/ Issue with USB Audio]
Audio
[https://github.com/raspberrypi/linux/tree/rpi-patches/sound/arm audio] and its [https://github.com/raspberrypi/firmware/issues/2 very high speed message passing interface type of thing VCHI]
The Model B+ added an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality
the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures
Analogue audio
Audio over HDMI rev 1.3 & 1.4
Ethernet
10/100 BaseT Ethernet RJ45 socket
GPIO
GPIO shouldn't be too bad but bear in mind it is already accessed in places so they would need to allocate pins etc through it (e.g. sdcard to flicker the activity light, serial debug to output data on the GPIO pins)
Probably a resource rather than a device...
Started an i2c driver that will need to allocate GPIO pins. Feel free to work on it if you are interested ;p
GPU graphics with 2D and 3D acceleration
Sadly none yet for 32bit but for 64bit...
== References ==
===Hosted===
==== Linux ====
Change lxde to another
sudo leafpad /etc/x11/xinit/xinitrc
xorg.conf
<pre>
Section "Screen"
Identifier "Default Screen"
DefaultDepth 16
SubSection "Display"
# Viewport 0 0
Depth 16
Modes "800x600"
EndSubsection
EndSection
Section "Device"
Option "Backingstore"
Identifier "Card0"
EndSection
</pre>
Will raspberrypi ARM programs run on other ARM archs and vice-versa ? If not I would like to use different cpu names for
archs which are incompatible.
All code compiled for at most armv6 with softfp float abi will work on all softfp ARM targets, including raspberry.
Code compiled for hard-float ABI will not work on any softfp target. But then, hard-float abi uses -armhf- cpu name.
keyboard or mouse not functioning or partly working
lsmod
kernel and modules (stored in /lib/modules/ get from https://github.com/raspberrypi/firmware and click on ZIP button) have to be updated simultaneously
sudo Apt-Get Update
sudo Apt-Get Install <program >
<program > cksfv joystick p7zip-full stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 libreoffice epiphany-browser xbmc
ace-of-penguins gweled black-box petris xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis xbubble eboard&xboard (freezes) bomberclone
OMXPlayer not responding or working with keyboard or no sound audio through HDMI
LXterminal—command "OMXPlayer -o hdmi %f "
hdmi issues
Setting the hdmi_force_hotplug=1 makes sure the Pi believes the monitor/TV is really there.
You might also need to set config_hdmi_boost=4 or even higher (up to 9) if your display needs a stronger signal.
If the display is a computer monitor or newer tv, use hdmi_group=1 (auto HDMI use) and if it is an older TV, try hdmi_group=2 (for DMT formats, i.e. for PC monitors) then you HAVE to "set hdmi_drive = 2 to enable HDMI output as this forces HDMI mode rather than DVI mode
Do not set hdmi_safe=1 as that overrides many of the previous options.
Using a shorter or better quality HDMI cable might help. Make sure your Pi's power supply delivers 1 A and not 500 mA.
If you see a problem with the red colour - either absent, or interference - then try a boost
composite video
changing the RCA cable, then the composite port worked out of the box
Boot it as you are doing, without HDMI. If you now plug in the HDMI, do you get the image? In other words, does the Pi think HDMI is connected even when it isn't?
Rename all the files in the first partion of the card except bootcode.bin, start.elf and fixup.dat What's the result?
Put back config.txt What's the result?
for PAL mode sdtv_mode=2
dmi_ignore_hotplug Pretends HDMI hotplug signal is not asserted so it appears a HDMI display is not attached
hdmi_ignore_hotplug=1 Use composite mode even if HDMI monitor is detected
<pre>
# NOOBS Auto-generated Settings:
#hdmi_force_hotplug=1
#config_hdmi_boost=4
#overscan_left=24
#overscan_right=24
#overscan_top=16
#overscan_bottom=16
#disable_overscan=0
start_x=1
gpu_mem=128
</pre>
tvservice -c "PAL 4:3"
<pre>
/opt/vc/bin/tvservice -s or tvservice -s
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
(native) mode 16: 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m DMT
Group DMT has 0 modes:
</pre>
sudo amixer cset numid=3 1
forces the audio to the headphone jack, even with the HDMI video output plugged in
config.txt
the hdmi_ignore_edid_audio=1 option sems relevant as it should tell ALSA that the only available audio is analog, no matter what the display says
There are several different ways that these 4 pole (ring) composite analog cables can be wired up, so some work great in some applications and can be a waste of time in others.
What is needed for the Raspberry Pi B+ and above, which like many camcorders needs the ring contact next to the base contact to be the ground.
The wiring for the 4 pole are:
TIP (LEFT AUDIO CHANNEL)
RING 1 (RIGHT AUDIO CHANNEL)
RING 2 (GROUND/EARTH)
RING 3 BASE/SLEEVE (VIDEO) YELLOW
Most Apple based Players and the Microsoft Zune (TM) are wired this way.
Most analogue camcorders are wired this way as well, where the ground in on Ring 2 will work with the Pi although you may need to swap your Video plug with the Right Audio plug.
Nearly all other MP3 players are not wired this way, the ground is on another ring ie the wrong one.
External devices
* Camera Module Omnivision ov5647 Sunny 5MP (NoIR version) V1.3 - NoIR at 850 nm, peak at 880 nm and trails off at 940 nm wavelengths
* Camera V2 Sony IMX219 V2.1 8mpixel 8MP 8megapixel - 3280 x 2464 pixels - video at 1080p30, 720p60 and 640x480p90 - wider field of view, 62 vs 54 degrees horizontally -
* Branded WIFI usb BCM43143 dongle
N.B. dreaded error after changing cameras (stupidly without turning off the power first) and lasted through several power cycles. It can be a bad 15-pin FFC ribbon cable, when swapped, camera(s) and the Pi itself are working OK. It can be an instance of a cold solder joint on the CSI connector on the pi board. the camera can be detected (that's done via I2C) but may still not be able to receive image data (done via CSI-2) if something is broken. CSI-2 is uni-directional. Control is generally done via I2C.
The CSI-2 receiver always writes to memory, not direct to the ISP. That's the way the Broadcom architecture works as it allows multipass processing easily. GPU memory is accessible from the ARM. Processing using the QPU graphics processors may be possible. currently the only supported sensor is OV5647 and IMX219. The linux drivers are all in the firmware blob, else you'd be looking at at least a man-month of work in a fully fledged imaging lab to do a decent tuning of the camera modules' ISP parameters.
Static electricity maybe an issue for the camera module and slightly less for the pi board.
* Hosted under ARM Linux which needs to be already installed [http://www.aros.org/nightly1.php current ABIv1]
Help building AROS hosted on Linux ARM
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:
<pre>
Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic':
configure: error: C compiler cannot create executables
See config.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2
</pre>
looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.
now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)
P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.
Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.
My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.
Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.
For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.
Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.
Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh
I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:
#MM- linklibs-armhd : libklibs-aeabi-arm
Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.
I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...). Smile
To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.
With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.
4fpyd6xqpy9oxts7u4yk66z770rp5nn
4655987
4655985
2026-08-01T11:44:15Z
Jeff1138
301139
4655987
wikitext
text/x-wiki
{{ArosNav}}
[[#Native]]
[[#Hosted]]
==Introduction==
The Raspberry Pi Foundation is a charity founded in May 2009 to promote the study of basic computer science in schools, and is responsible for developing a single-board computer called the Raspberry Pi.
The Foundation is supported by the University of Cambridge Computer Laboratory and Broadcom. Its aim is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing."
The original Raspberry Pi 1 Model B computer went on sale in February 2012 and set a new standard shattering the dominance of the PC in the home and education markets. Millions in the various formats, A, B, A+, B+ and Compute have since been shipped worldwide. The original concept of the Raspberry Pi was for a computer board providing Internet access with up to 1080p HD graphics at very low cost. The boards provide a platform for children and adults from any background to acquire computer science knowledge and help develop the future World-Wide-Web and all things internet (IOT hub and bridges out to home network to cloud of sensors).
Hobbyists and tech dabblers/tinkerers are the main purchases of the Pis (around half).
The rest of the sales are split between education/industrial. While the Raspberry Pi boards were designed primarily for education, they have become very popular with manufacturers of embedded systems. The Raspberry Pi Foundation has ensured backwards compatibility with each new revision. The bare-bones Compute module is aimed specifically at the OEM manufacturer.
* Pi 5 - Quad A76 and RP1 "southbridge" with VideoCore 7 4Gb 8Gb LPDDR4X
* Pi 4 - Quad A72 64bit VideoCore 6
* Pi 3 - Quad A53 [https://www.raspberrypi.com/documentation/computers/processors.html 64 bit] - VideoCore 4
* Pi 2 - Quad 32bit but more power consumed
* Model B+ - lower power usage but same speed as the original Pis
* Model A and B -
* Compute 1, 3, 4 and 5 - industrial use
<pre>
2008 Trustees collected for Foundation
2009 Charity status gained
2010
2011 First Raspberry prototypes
2012 First boards go on sale at CPC and RS. The Model A and B 700 MHz Arm11 - February 29th BCM 2835
2012 First million sold - more than the 10,000 original planned and anticipated
2013 First Alpha Experimental builds of AROS Native for the Pi
2013 Pi Trading launched making grants available, providing in house educational resources and Pi Academy for teacher training
2013 Over two million sold
2014 Over three million sold and updated Model B+ introduced that moved composite video to audio jack and same half gig of memory
2014 Pi Model A+ v1.1 - BCM2711 no ethernet and 1 usb - a little smaller -
2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit core and 32bit VideoCore IV 3d GPU with 1Gb RAM
2015 Over four million first gen pis sold
2015 Over a million pi2s sold
2015 Pi Zero BCM2835 released
2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837
2016 Passed Sinclair total number of computer lines sold - around 7 million
2016 Pi 3 Model B - Broadcom BCM2837 SOC four 64bit ARMv8 Cortex-A53 1.2GHz - 1Gb - bluetooth 4.1, Cypress CYW43438 wireless 802.11n and a dual 32bit VideoCore IV GPU - 4 x USB2.0 ports
2016 Total PIs over 10 million worldwide
2016 Compute 3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage
2017 12 million pis sold in total
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 - 1Gb, wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet - 4 x USB2.0 ports
2019 Over 15 million sold
2019 Pi 3 Model A with BCM2837b0 with 512Mb,
2019 Raspberry Pi Compute Module 3+ CM3+ LITE Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc
2019 Pi 4 Model B - BCM2711 quad 64bit A72 1.5GHz, VideoCore VI, AC wifi, Bluetooth 5.0, GbE, 2 micro hdmi decode up to 4K, USB-C power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram
2019 Pi 4 Model 2B - BCM2712 4 usb
2020 Raspberry Pi SC0919 Pico RP2040
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard
2020 Raspberry Pi Compute Module 4
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam
2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu
2024 Raspberry Pi Pico 2
2024 Pi 5 2GB version uses BCM2712D0
2024 Pi-500
2024 Raspberry Pi Compute Module 5
2025 Pi-500+
2026 April and May Aros 64bit fixed, added AHI audio, VC4 gfx started, usb functions added to rom
2026 June and July Aros 64bit usb2otg started, dma.resource, sdio.resource, bwfm.device wifi added
2026 Late July daily 64bit Pi3 builds start
2026 August ....
2027
2028 Pi 6
</pre>
===Good sites to visit===
*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build] [https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9boot ]
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build]
*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k]
===Native===
* 2013-03 Kalamatee starts work
* 2013-05 Work put on hiatus
* 2015-04 Work continues slowly with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb
* 2018 [https://www.patreon.com/posts/i-owe-you-some-20956961 mschulz resume with adding BE big endian support as well]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=bsek latest commits for pi 3 64bit]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=jonx latest commits for pi 4]
64bit ArmV8 builds are
The status of AROS 32bit native for RasPi was OK. System booting, USB working (although with some issues but plan to fix them). Got stuck on modifying the ABI (application binary interface) and adjusting binutils/gcc to support it wanted to have real executable files but got stuck a little. This change for the type of relocations embedded in ARM files and not sure if this very type is well supported, on the other hand without this change ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.
Old native [http://www.aros.org/nightly1.html ARMv6 32bit nightlys] and
===Hosted===
[http://www.aros.org/snapshots1.html old linux and android hosted 32bit]
==Build==
===64bit===
===32bit===
# download/checkout the source someplace, e.g. /build/AROS-Src/
# make a directory to store external sources AROS downloads, e.g. /build/Ports
# make a build directory, e.g. /build/aros-raspi-armhf
# cd into the build dir, configure, and then run make -:
<pre>
>cd /build/aros-raspi-armhf
>/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
>make
>make arosboot-raspi
</pre>
then copy the files from /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ onto an sdcard, and download/copy the Raspi firmware files onto it.
You should then be able to boot the sdcard on your RasPi.
The current W.I.P tree to svn. it can be built as follows ..
<pre>
./configure --target=raspi-armhf
make arosboot-raspi
</pre>
That will generate arosraspi.img, arosraspi.rom and config.txt in bin/raspi-arm/AROS - so either copy just those files to a fat formatted SD card (with the firmware files on), or copy the whole contents of the AROS folder.
NB - if you have a Linux/other install, backup the existing config.txt first
arosraspi.img contains the bootstrap (which has very basic mailbox code, framebuffer/gpio init, and console "emulation" via code pinched from our libbootconsole), kernel.resource, and exec.library
arosraspi.rom contains all the other components needed to boot AROS.
The config.txt file will tell the RasPI bootstrap to load our arosraspi kernel and ramdisk (rom).
the bootstrap has minimal mailbox code, planning on adding either a resource or library that driver/app code will use to access it (likewise for GPIO)
==== Hosted ====
Ubuntu VM approach to compiling [http://lallafa.de/blog/2013/06/building-aros-hosted-for-raspbian/ Linux hosted AROS June 04, 2013]
../AROS/configure --target=linux-armhf --enable-includes=/usr/arm-linux-gnueabihf/include --x-includes=/usr/arm-linux-gnueabihf/include --x-libraries=/usr/arm-linux-gnueabihf/lib
arm-elf- is symbol-linked to arm-linux-gnueabi- (arm-linux-gnueabi- is more correct in this case, because it's going to be compiling the ARM AROSBootstrap for ARM Linux)
*armel - many of the "android" machines require since the entire OS is made for soft float VFP.
*armfp - Efika MX target, Raspberry PI, EfikaMX, Pandora and virtually everything (VFP)
Keep in mind it's possible to start hardfp AROS hosted on softfp system, though, as long as no calls between AROS and host require floating point parameters. NOTE: hardfloat objects *cannot* be linked with softfloat objects - they have a different ABI.
Just keep in mind the arm nightly build machine is quite complex beast. It needs the x86_64 host compiler to compile AROS tools. The arm version is built every night using gcc-4.6.2 crosscompiler (built together with AROS) and successfully builds armel and armhf linux hosted targets.
*needs an AROS code compiler for ARM target
*as well as unix compiler for ARM linux host (would be best to have both softfp and armhf, we have softfp only now) with full set of libraries and includes.
with—disable-crosstools $AROS_CC is always a wrapper around $KERNEL_CC ? If so, this is wrong for some ports. This can break Darwin, Windows and Android port.
Yes, Android port will build. And even work. But it's not good because the port will not be ABI-compatible with other ARM ports. Android's ABI is different from GNUEABI. For example:
<pre>
enum test {foo, bar};
enum test testvar;
</pre>
siseof(testvar) will be equal to sizeof(int) in GNUEABI (Linux and AROS) and sizeof(short) on Android. This affects linking objects from static linklibs, for example.
Previously everything worked because $AROS_CC was a wrapper on top of $HOST_CC. And a real crosscompiler was used on non-ELF hosts.
Android is the same. $KERNEL_CC is incompatible with AROS.
compiler=kernel is appropriate _ONLY FOR CODE WHICH RUNS ON HOST OS_ (or barebone hardware, if we talk about native). This includes bootstraps, their linklibs, and host-side dynamic libraries (Windows makes extensive use of them because of architectural considerations.
No single AROS object should be compiled with this setting. $KERNEL_CC is really compatible with AROS *ONLY IN LINUX-HOSTED* and no more. On other systems (Darwin, Windows, Android) this is not true any more, and compiler=kernel is never going to work.
If you want to compile your AROS module against host OS includes, append the following to USER_INCLUDES (or USER_CFLAGS, this is effectively the same):
-isystem $(GENINCDIR) $(KERNEL_INCLUDES)
$(KERNEL_INCLUDES) expands to:
-isystem <your_os_includes> -isystem <host_OS_gcc_private_includes>
-nostdinc
This makes AROS compiler adhering to host OS APIs.
If you want some preprocessor symbols based on what your host OS actually is, add something like -DHOST_OS_$(AROS_HOST_ARCH).
Why is there $(GENINCDIR) at all? Because host OS has its own libc includes, which would conflict with AROS ones. And the host OS libc is not binary-compatible with AROS one.
Why doesn't Windows-hosted port use $(KERNEL_INCLUDES) ? Because WinAPI includes conflict with AROS ones in fundamental typedefs, like WORD, BYTE and BOOL. It's almost impossible to deal with this in any other way than rewriting WinAPI definitions using AROS types.
Building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. haven't yet committed the necessary changes but "./configure --target=raspi-armhf" is enough to start, then "make arosboot-raspi" will generate arosraspi.img (containing the bootstrap, kernel.resource, and exec.library) as well as arosraspi.rom (containing all the other essentials components such as dos, graphics etc). It will also copy over a config.txt file to make the raspi bootstrap code load the correct kernel, and a cmdline.txt that enables exec debug output.
*armel = typically Debian 6, Ubuntu Maverick, Android,
*armhf = typically Debian 7, Debian 8, Ubuntu Precise,
Cross-compiling Ubuntu ARM softfp
<pre>
sudo sh
echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
</pre>
<pre>
./configure --target=linux-arm --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabi/include
</pre>
Cross-compiling Ubuntu ARM hard-float
<pre>
sudo sh
echo 'foreign-architecture armhf' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armhf.list
apt-get update
apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
</pre>
<pre>
./configure --target=linux-armhf --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabihf/include
</pre>
Now, the AROS build is configured properly and all you need to do is:
make
[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]
== Hardware ==
===64bit===
====BCM2712====
BCM2837
* Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support, 3B+ [https://github.com/aros-development-team/AROS/commit/afa5bc0bb17d5dd06bcfdbac00853a3799ca8d76 LAN7515]
====BCM2711====
===32bit===
=== Core Kernel ===
the reason behind INTB_KERNEL is to allow use of the standard Exec function AddIntServer() to add interrupt handlers for
hardware drivers etc. AmigaOS never used it for abstract hardware drivers. AmigaOS routed only raw hardware IRQs there. Their assignment was hardcoded. As well as number of them. Actually on AmigaOS every bus has its own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt. 1:1 relationship between CPU and hardware interrupts is present only on PC.
IMHO we miss things like AddInterrupt/RemInterrupt methods on our PCI subsystem's device class. PCI bus class should map these methods to whatever is appropriate. This is how it is done on AmigaOS and friends. When these are implemented, raw kernel.resource API will be needed only for several PC-specific drivers with hardwired resources. Exec IRQs are real IRQs only on Amiga hardware. On other machines they can be emulated where appropriate (VBlank is a good example). kernel.resource is meant to be different, its IRQs are hardware-agnostic, they are plain "Hardware IRQ number X, whatever this means". They are low-level actually, and meaningful only in the context of a particular system.
Was that not the transition from irq.hidd to kernel.resource? No. A long time ago there was another hacky bit named INTB_TIMERTICK. It was "abstract timer interrupt", used by timer.device. It was the same as VBlank, but with larger frequency. I removed it, because kernel.resource API was a cleaner way to access this interrupt. Furthermore, there can be more than one timer in the system. I am even thinking about bringing back timer HIDD definitions again. hpet.resource is a bad idea.
Can someone please enlighten me a little on how the scheduler is meant to work?
Poseidon.library creates its "Poseidon Event Task" during RTF_COLDSTART -> then calls Wait(), and ends up in limbo because wait disables interrupts (used for the scheduler heartbeat), and basically waits forever because the sigbit is never set, since krnSwitch doesn't switch the task unless TF_SWITCH is set, and no codepath run during this seems to set it?? TF_SWITCH does not disable/enable switching. This flag just enables to run user-supplied hook when the task is being switched away. It is completely safe to call Wait() in Disable()d state. Doing this actually temporarily breaks this state. IDNestCnt gets remembered in struct Task, then next task is selected, and its IDNestCnt is restored in sysbase (see kernel_scheduler.c). If there are no other tasks, then your cpu_Dispatch() should enable interrupts on the CPU and enter idle mode. See x86 implementation for good example.
You miss what happens next...
1. KrnSwitch() saves context of your task, saves IDNestCnt (core_Switch() and cpu_Switch()), then drops into cpu_Dispatch().
2. cpu_Dispatch() calls core_Dispatch. Then two cases are possible:
2a. There is a READY task. It is picked up, its IDNestCnt is restored in SysBase, then cpu_Dispatch() needs to restore registers and exit. The next task is run.
2b. There are no READY tasks. core_Dispatch() returns NULL. In this case your cpu_Dispatch() should enter idle loop. It should just enable interrupts on the CPU and put it on halt. This allows it to process hardware interrupts. Eventually some of your interrupt handlers wakes up your task and puts it into READY list.
My heartbeat interrupt has been slowed atm to help debugging - but it never actually gets a chance to fire because of the Wait() disabling interrupts. Perhaps you have forgotten to enable interrupts in your idle loop.
There is a change in the format of AROS executables. Until now we were using Elf RELocable files which are usually used as intermediate object files. We had them for various reasons, one of them was how AROS files were built in the past. That days we had no real aros cross compiler and the option to embed relocation data in unix executables (or in executable files in general) was rather new and not every linux/unix system had it. Therefore we have decided to use intermediate files. Although it was somehow working (and it is still working :-)), it has some drawbacks. Therefore decided to introduce real Elf EXEC types, in first turn implemented on ARM target with option to expand in future to all other AROS architectures.
The first patch was pretty easy and appeared to work somehow. It generated nice executables with embedded relocation info. Not only that, it also removed all global symbols adjusting relocation data to be relative to the beginning of the sections. That move reduced number of symbols in each executable significantly (depending on the file between 20 and 80% of all symbols could be removed). The only symbols that stayed in the file are local ones - due to the nature of the patch wasn't able to remove them since we have not seen them in the symbol hash table.
The patch didn't worked though. The files were relocated, AROS kernel loaded, but it crashed very early. What happened? Well, the nature of ARM relocations happened :)
Most of the relocation data on all machines is rather simple. Relocation can be absolute or pc-relative, sometimes the offset has to be bit shifted. On ARM v7 there is another one. There, when one wants to load an address of function/variable into register a combination of two instructions can be used: movw and movt. The first one loads immediate into lower 16 bits of a register while clearing upper 16 bits. The second one loads immediate into upper 16 bits without touching lower halfword. Loading of a pointer into a register looks like this:
movw r0, #:lower16:label
movt r0, #:upper16:label
In this case there are two relocations - one for lower halfword and another for upper. If an overflow of lower 16 bits occurs during relocation process, the upper one should be updated as well. Unfortunately with current patch and with typical ARM executables there is not enough information to perform the calculations.
There are two options - the first one would be to give up and go back to "fake" executables, another one would be to change from REL to RELA relocation info. The latter contains an addend, extra data which can be used to perform all the relocation calculations I need.
Decided for the second option. The patch is already in the works. There is another function for the binutils' bfd backend to perform the final relocation. There can decide what to do with every reloc info, modify data and eventually strip some symbols. An advantage is - at this stage of the linking process have also full access to all local symbols so can change all relocations section relative and eventually strip all symbols from the files.
=== GPU ===
Most of start.elf runs on the GPU. Placing ALL the userland GPU code in the videocore.hidd isn't going to be a terribly big problem because the code they published is nothing more than a shim that sends data straight to the GPU to execute.
The good news about this is that we only need to write our HIDD using the OpenVG API. The shim is relatively small codewise and lives in the ARM memory (the actual OpenVG code itself lives in the GPU RAM area and its loaded from start.elf). That's also the bad news. Our driver has to translate AROS video calls to OpenVG calls, for most tasks it should be easy, for some, not so much. It's still probably less difficult and less work, than controlling the GPU directly.
The other good news is that anything done through OpenVG happens on the GPU, its truly accelerated. It also has some nice font functions, meaning we can lead into an accelerated text mode later.
Basically, AROS resets or locks up when it tries to use AROS_ATOMIC_INC or DEC. If I comment out the byte/word operations in the header files and use non-atomic operations, the code works as expected.
have read that the L1 cache needs to be enabled to use LDREX and co (which I also read is only meant to be used on multi processor systems with shared memory) - however I am certain this is correctly enabled.
If you are using LREX or STREX, you should have L1 cache enabled, at least on the ARM CPU I work with at work.
L1 cache is enabled by enabling the MMU *AND* setting the C and I bits in the CPU - the C bit is ignored, and the I bit only covers the 16 byte instruction pipeline if the MMU is not enabled.
Can you verify that your assembly is generating LDREX/STREX? From the behavior, it almost sounds like its generating the default Semaphore locked atomics.
Impossible. There are no semaphore-locked atomics. There are Disable()/Enable()-based ones instead. And there's a special #define AROS_NO_ATOMIC_OPERATIONS in this case, which tweaks Disable()/Enable() implementations not to recurse forever.
I have tested this on ARMv5 which does not have ldrex/strex, it works fine. On those ARMs there's no way to have real atomics. On other OSes (like Linux) this is done by introducing things like atomic_t, which appears to be a complex structure, holding the value together with accompanying spinlock (implemented using swp).
#warning "TODO: lookup optimal mmu table settings for raspi memory"
/* Set up an identity-mapping for all 4GB */
for(x = 0; x < 4096; x ++)
{
pagetable[x] = x<<20 | (0x40002|0x80000|0x010000|0x00C00|0x04);
}
Shouldn't there be a second loop that sets the 'C' bit in the descriptor for the RAM pages?
Currently, you have TEX=0, C=0, B=1 for all pages (Shared Device).
You should have TEX=0, C=1, B=0 for RAM (Write-Through, Cached)
So ..
pagetable[x] = x<<20 | 2;
should be enough?
No, for RAM you need to change the '| 0x40' to '| 0x80'
tell dosboot the correct defaults to use
Please don't do this. This bootconfig.c is a deprecated legacy thing. I wanted it to go away completely with time. Instead, display drivers should auto-install themselves during own initialization phase. I. e. detect hardware=>instantiate itself. This should make things way simpler. With this approach you only need to add the driver into KS image to get the device autobooted. No
hardcoded stuff.
Currently VESA and VGA drivers do this, look there for examples. never rewrote ATI driver because i don't have any test system for it.
they defined a smaller AROSCPUContext than the ExceptionContext - yet reference it as ExceptionContext in other places, and since it hasn't allocated enough storage for ExceptionContext, are corrupting memory/the structure (since the elements that are there don't map 1 to 1 with the exception context).
AFAIK, AROS has been moving in a different direction to this in recent
years. It is the job of graphics HIDDs to allocate bitmaps etc. so that
they have the most suitable characteristics, including allocating them
from GPU RAM where possible. The concept of chip RAM is only for legacy
code, and most if not all non-68k platforms should have all system RAM
marked as chip.
BTW, is the video processing code you mention CPU code or GPU code?
Also, IIRC we have support for "external memory allocators". Perhaps that's what we need for the allocation of GPU RAM through the mailbox.
All hosted and x86 native ports should use proper context formats.
trying to clarify if the vblank handler has to have run by this point to prevent this deadlock. Actually, no. Unless you have installed VBlank handler which should wake up at some point. Without VBlank there will be no quantum count. Consequently, there will be no forced preemption. But the rest will work, and multitasking will be cooperative (switch happens only when current task voluntarily gives up the CPU). Does it depend on the vblank having run before this point? and if yes what does that mean on systems where it might be able to run enough code (e.g. get to this point) before the vblank interrupt has triggered? What is it waiting for? It could wait for timer, in this case you need timer.device working. VBlank is currently needed for exec's quantum counter. In current native ports we have only a single timer, which is served by timer.device. VBlank is simulated by timer.device also. If your machine has two timers, then you can use one of them for VBlank, and another for timer.device, this will simplify things down. VBlank needs to be 50 Hz for historical reasons, many programs use it as cheap timer. I am periodically thinking about making some abstract mechanism to be able to change quantum source (and untie it from 50 Hz), but have no time to come up with something good. Additionally i started disliking timer.device hardcoded design when PC has got many timers (old 8253, APIC, HPET).
Currently i think there should be some low-level entity representing tick source. timer.device should just select the most appropriate source for its units.
The BCM2835 has 4 GPU based timer sources - 2 are used by the GPU, so im using Timer3 for our heartbeat and the remaining one will be free to the system. There is also the less capable ARM timer but that is dependent on the CPU frequency. Very good. You won't need any emulation. Set the heartbeat to 50 Hz and drive VBlank from it. Use other timer for MicroHZ.
Can you use the 'econsole.hook' I make for debugging the Sam460 via the serial port?
It provides a before-anything-else shell prompt on the serial port. You can then do 'NewCLI' to test your graphics, or use any DOS command in shellcommands.resource.
You should just be able to add econsole.hook to your module list, and use 'econsole' in your bootargs.
So long as you have a working Exec/RawMayGetChar and Exec/RawPutChar, it should work.
Also make sure to add shell.resource and shellcommands.resource for this.
That should have done it.
If you set "#define DEBUG 1" in arch/all-native/econsole/econsole.c, do you get any additional serial output?
have added it to the build and added econsole to the command line - and can see the bootloader picks up on the emergency bootconsole tag, but I still only get the insert bootable media display?
Im assuming it exposes a fake filesystem that tricks aros into booting?
The contents of which are: ECON:AROS.boot
Way to handle the scheduling code? The implementations I had been following were causing problems, due to cascading interrupts which I cant handle properly in the asm stubs just now (when they break disable etc.) - since it means detecting the interrupted codes cpu mode and getting the correct sp/lr for it, and that's just too tedious for arm.
To work around this ive added a system idle task which does nothing - and when the scheduling code has no task to run switches this in and lets it run, thereby allowing the interrupts etc to resume until something does need to happen.
Also, by adding accounting code to cpu_Switch() and cpu_Dispatch(), it should allow the system to log idle time correctly (as well as running tasks).
have thought of also adding an additional task that never runs, solely to record time spent in IRQ handlers, but I digress..
was under the impression that kernel.resource should *never* be used outside of exec.library. This is a wrong impression.
Michal started designing it because portable nature of AROS does not fit well into exec's API with all its assumptions. So, he started the new, hardware-agnostic kernel API from scratch. Yes, exec sits on top of it in places. But kernel always meant to be open thing. Otherwise it would not exist.
it wasn't meant to be just used willy nilly by user code - but by lower system components (e.g. exec) so that they could be implemented in a more generic fashion, and the kernel resource itself hide the systems quirks.
Adding new things there perfectly keeps up with our decision to minimize AROS-specific intervention into APIs which can clash with MorphOS/OS4 extensions. We want at least source-level compatibility there. Binary compatibility on PPC would be extremely cool, but at the other hand we have no maintainer for this, as well as their ABIs are a bit weird and far from optimal, especially MorphOS one, because it aims for m68k binary compatibility.
It depends on what exactly is being implemented - there's no reason we should have everything crammed into kernel.resource if it doesn't need to be (i.e. if its better suited as a separate component/subsystem in its own right)
The _LE versions are for when you have endian swapping taking place. If the graphics are the same endian as the CPU, no swapping should occur. I ran into a similar terminology problem in SDL with a friend insisting that his Radeon 7000 on his PC was big-endian. It is not, it just uses the same endianness for the graphics card and the CPU so no swapping was necessary. They were both little-endian.
The _LE versions are because the PixFmts refer to the bitmap data being in big endian format in memory, for which the normal version would need to do endianness conversion before applying the shifts/masks. on this platform it is in _LE in memory also so we don't need the conversion hence using the _LE version of the call). would use _LE (if it's really little endian 16 bit mode).
What is the bare minimum needed to implement a framebuffer based gfx driver, with our software handling the rest?
I have tried with just a gfx class that only expose new/dispose/newbitmap - and having an onscreenbitmap used only for the framebuffer itself (with all other bitmaps being chunkybm, and the framebuffer's superclass also being chunkybm), but that alone isn't enough it seems?
You can use workbench/hidds/sm502/ as your example - it is as simple as I could make it.
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
I so far have -:
vc_init: queries the gpus memory, and sets up a fake memory handler for it, then adds the bootmode driver and returns saying all is well
vc_gfxhidd:New: sets up some fake syncmodes to test with and creates the real gfx object.
vc_gfxhidd:NewBitmap: checks if its a framebuffer and uses the onbitmap class or uses the chunkybm class otherwise
vc_onbitmap:New; creates a chunkybm object and then pushes the real framebuffer address into it as the buffer,
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
The code I currently have on SVN seems to create the framebuffers bitmap object fine, but then crashes in intuitions DisplayDriver callback. In particular it crashes performing the getattr on the system default pointer.
don't expose MEMF_CHIP in an allocatable form so AllocSpriteData was failing (and other code later doesn't check if the values are valid == illegal memory accesses)
Actually MEMF_CHIP has to present, for historical reasons.
This has been never fully agreed upon, but in ports i wrote i exposed the whole memory as MEMF_CHIP. The idea behind this is that CHIP is originally the memory where graphics and sound data can be put. On non-Amiga platforms there are no restrictions on this, so the whole memory is CHIP.
Yes, many old software can misbehave with CHIP memory size larger than 2MB. But this actually applies only to m68k AROS which is going to run m68k binaries. In other cases it's quite logical to fix the program when porting.
As to original question: yes, it's enough to have a framebuffer bitmap (one with aoHidd_BitMap_FrameBuffer set to TRUE) and PutPixel routine. It framebuffer can be served by chunky bitmap class, then you can simply create chunky bitmap with your own buffer (see how VESA driver does this). Chunky PutPixel is already there.
struggling to determine what is the correct pixfmt to use for the 24/16/15 bit gfx modes on the RasPi. AFAIK it uses RGB565, for 16bit but im unsure what shifts etc should go with it? suffice to say Im getting the wrong colors so far lol.
<pre>
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0
redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
</pre>
It should likely be vHidd_StdPixFmt_RGB16_LE
This stuff is a bit confusing. The "names" of the stdpixfmts are based on the layout in memory,
ignoring endianess. So for example:
ARGB32: will be 0xAA 0xRR 0xGG 0xBB in memory on both big endian and little endian machines.
The shifts and masks OTOH are based on pixel access (ULONG in this case), so differ depending
on whether you run on big endian machine or little endian machine (that's why there's stdpixfmt_le.h and
stdpixfmt_be.h in rom/hidds/graphics/).
With the 16 bit pixel format it's even more confusing, as for example it's impossible on little endian machine
to describe RGB16 with shifts/masks alone. That's why there's vHidd_PixFmt_SwapPixelBytes_Flag.
(RGB16 == RRRRRGGG GGGBBBBB in memory, and for pixel (WORD) access on little endian machine it needs to
be accessed as GGGBBBBBRRRRRGGGG).
The shifts btw indicate how much to shift the component to the left (!) so that it is moved to the highest bit (31).
The aHidd_PixFmt_StdPixFmt you specify will be ignored most of the time, because when the pixelfmt is registered,
the gfx hidd checks if there's an identical pixfmt (shifts/masks/etc., but ignoring pixfmt->stdpixfmt) already in the system,
and if so, it uses the already existing one and does not create a new one.
In theory it would be better if gfx drivers could simply/only specify a StdPixFmt without all the shifts/masks stuff when the
gfx driver uses pixfmt which matches one of the stdpixfmts exactly. Another possibility would be for gfx drivers to use
HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) and then peek shifts/masks from it and fill out a pixfmt
tag list based on that.
15bit very blue/green: Try to pass same shifts/masks/etc. as in 16 bit pixfmt (maybe you think it's using 15 bit R5G5B5
(or swapped) but it's actually still using 16 bit R5G6B5 (or swapped).
aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count.
But I would still pass the correct one (_LE) == whatever rom/hidds/graphics/stdpixfmts_??.h uses
in the entry where you have looked up shifts/masks/etc.
Use the shifts/masks/etc. from the entry in stdpixfmt_le.h (if you are running on little endian machine) or stdpixfmt_be.h (if you
are running on little endian machine) that matches the pixfmt that its meant to be.
0xAA,0xRR,0xGG,0xBB on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)
0xAA,0xRR,0xGG,0xBB on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_BGRA32)
it feels like AROS trashes the alpha component, otherwise it should be 8A8R8G8B.
read on the subject suggest its in 1x5r5g5b (x is ignored) to keep 16bit alignment .
What I see on screen suggests to me that wrong shift/mask are being applied - however going by the 16bit versions it all looks correct to me so I am really confused as to what is happening.
The output image looks to have too much green/blue, and very weak red.
Why did usbromstartup become HW-specific ?
In the past i have done a big job separating kickstart into several parts. I have never got any responses, so i re-describe my idea.
For now it loads the hs otg chipset driver ..
The idea is to minimize amount of archirecture-specific modules to
make user's life easier. So, the kickstart was split into 'base'
(which does not contain anything machine-specific) and 'BSP' (Board
Support Package) which contains all hardware-specific stuff.
This way, for example, distribution makers can save up space on CD
and make CDs with multiple platform support. Different configuration
would load the same base with different BSP's.
Next there was some part which is entirely missing on hosted. These
are filesystems. Hosted ports do not need them to boot up, so on
hosted they are left out. At the other hand, they are also
architecture-agnostic. So i put them into 'FS' package (standing for
'filesystem').
Poseidon is one more big part. I made it into separate package in
order to allow users to omit it if they don't need it (for example, to
run on retro PCs without USB). Personally i have one. Again, Poseidon
is hardware-agnostic (well, there are USB drivers but HCIs are pretty
standard).
It's mandatory on PI since there are no other interface types - so being a separate package is irrelevant/pointless.
Is Raspberry's USB controller non-HCI compliant? Actually i expect it to be compliant, then wouldn't it be better to make existing drivers discovering them?
AFAIK its HCI 1.0 compliant but I'm not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once i'm more familiar with the workings I can merge in the changes needed to get it operating but for now I will focus on getting it running. Also our drivers have known issues so perhaps a fresh set of eyes might shed some light on what is going wrong.
Another interesting question is whether Poseidon can operate on device side. Is it flexible enough? How similar is being a USB host and USB device? think it will need a bit of work on Poseidon's side. Until then I will force the driver into Host/Master mode in the init code, but leave open device etc to configure the chipset for either's use - and look at trying to add support for working in Device/Slave mode & switching modes once it's up and running.
Actually USBROMStartup is some kind of kludge. Can there be any alternative? Could device drivers be self-installing, like our HIDDs? This would get rid of need to list them in USBRomStartup.
And there is one more thing about modular ports. In order to actually implement this, your bootstrapping environment should provide the ability to load several files. On PC this is provided by GRUB2. on CHRP you can read filesystem via OpenFirmware, and Sam's Parthenope relies on modified u-boot. If your bootstrap allows to load only a single file, then you stuck with monolithic kickstart. By the way... u-boot allows not only to boot up a single uImage or zImage, it also allows to write client programs AFAIK. With this approach, you actually can write modular bootstrap for ARM AROS using unmodified u-boot.
[http://repo.or.cz/w/AROS.git/commit/e7bdc7e7b7f12b07aa24c739abb63721a872a53a arasan eMMC sdcard controller specific header which is not USB] and [http://repo.or.cz/w/AROS.git/commit/8bd19674084526a534ac11f7d4c51932e9ffe3d2 added prelim sdcard device]. [http://repo.or.cz/w/AROS.git/commit/9ab8217f61911fb8b7fd41bee46a992b4668ced1 do not set 4bit data mode, or enable acmd12/dma int's]
====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM)
*Framebuffer (fb) using mailbox
*IRQ scheduler, etc
*Arasan based SD Card controller
*Synopsis DesignWare USB 2.0 OTG controller [http://networkdirection.net/index.php?option=com_content&view=article&id=106:rasperry-pi-usb-controller&catid=45:raspberry-pi&Itemid=54 Unofficial DOCS pdf], [dwc_otg.c FreeBSD], [], [https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/Controllers/DWCDriver/ RiscOS USB Driver], [https://www.riscosopen.org/forum/forums/5/topics/878 RiscOS USB Discussion], [https://www.riscosopen.org/forum/forums/11/topics/1893 Other USB RiscOS], [http://plan9.bell-labs.com/plan9/index.html Plan9 Miller's usb] http://plan9.bell-labs.com/sources/contrib/miller/, [https://github.com/Chadderz121/csud CSUD driver],
*[http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf SMSC 9512] USB LAN/Hub chip
*CMOS RAM
*VCHIQ port which sends messages to the GPU e.g. for mouse, keyboard, audio on HDMI, etc
*Audio Driver
*Serial Peripheral Interface Bus (SPI)
*[http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/ I2C registers]
*I2S
*Universal Asynchronous Receiver Transmitter (UART)
*[http://elinux.org/RPi_BCM2835_GPIOs GPIOs] and [http://www.adafruit.com/blog/2012/08/17/broadcom-bcm2835-peripheral-memory-map-and-gpio-alternate-use-chart-piday-raspberrypi-raspberry_pi/ Alternative view of GPIO]
BCM2836
* For Pi B+, PI 2 and Pi 3 SMSC LAN9514 chip adding 10/100 Ethernet connectivity and four USB channels to the board
The overclock ability has diminished with each chip version as the energy usage has very slowly risen. BCM2837 is one of the warmest yet and might benefit from active cooling (ie fan) if all four cpu cores are in use for a short while. Video playback is not affected due to the custom support in the GPU. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur.
*[http://www.andrewscheller.co.uk/rpi_pcb_modules.html PCB], [http://elinux.org/RPi_Low-level_peripherals Low level features],
Implemented so far...
# Modify the configure system so that it correctly builds for the arm hardware float raspi target.
# Implemented the bootstrap to load the aros modules and prepare the arm to jump into them. Reworked the x86 console support so that parts can be stolen for raspi to use since t has no basic functionality to output to the display.
# Implemented a kernel.resource to prepare the raspi for running aros and provide the low level api calls to expose available resources and allow exec, etc function.
# Implemented serial debug support
# Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc)
# Implemented a timer.device to utilise the hardware timers.
# Implemented a very basic gfx driver to expose the hardware's framebuffer.
# Implemented an SD-Card driver for AROS which presently only supports the raspi's chipset but can easily be modified to support all sd-card hardware and media.
# Fixed the fat filesystem support in AROS so that it can boot on RasPi's normal SD-Card setup. The "rom" image files needed use a different filename than the default linux, etc images so can be easily installed without harming the existing files - you only need to change the loaded images in the config file to get aros to boot.
# Updated the build scripts to automatically download the necessary raspi firmware files and wrap it all up so that you can simply extract the archive to a fat formatted sdcard and boot it on the raspi without having to get anything else.
# fix everything in contrib and ports to build for raspi (needs proper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi ..
Improvements...
# Implement a USB chipset driver "OR" finish the existing one [https://github.com/aros-development-team/AROS/commit/c07d13c724f944674be5db54fc6a71ee72a01809 usb otg] - the current code is mostly a skeleton that should initialise the chipset and then needs relevant code to support the different transfer types. It also has the "virtual" hub code in place to represent the raspi's USB port (from poseidons p.o.v)
# Implement a driver for the USB NIC (a few weeks - depends on USB above)
# Write an [https://github.com/aros-development-team/AROS/commit/d55d0f74d20b769bbb8c8d386e5c1d7a9154f05a audio driver] (a few weeks - independent of USB) and [https://github.com/aros-development-team/AROS/commit/e93a4c245f27a87c9c4c1d39206694b39059998a HDMI]
# fix syscall bug in the current raspi kernel code
# Graphics depend on having a decent "bcmdma.resource" implemented as to use the cpu's dma engine. The sd card driver needs to use it for transfers to/from the controller - and the gfx system needs to use it for "blitting".
# [https://github.com/aros-development-team/AROS/commit/4019d84e4975d4dad987a12d57fe108f5ac048e6 Improve the gfx driver], [ vc4gfx HIDD] add [http://dri.freedesktop.org/wiki/VC4/ Gallium3D support]
# [https://github.com/aros-development-team/AROS/commit/b13905b3e8e45b089f520b44692c81affddd066f Improve] the [https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9 sdcard] device driver - which is also pretty basic but should work with most cards, rework it to also support pci, etc. sd card interfaces on x86
# The current code using very rudimentary access to the gpio interface - so that should be implemented as some resource for other components to access, as-well as the i2c interface exposed over the gpio interface. that should have a hidd class implemented which uses the gpio resource to communicate.
Boot up
On power-up, the rpi [http://www.open.com.au/mikem/bcm2835/ BCM 2835] [https://github.com/hermanhermitage/videocoreiv VideoCore4] GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the BCM2835's VideoCoreIV GPU PROM requires a DOS-style partition table; a FAT-formatted first partition; and the freely redistributable but closed sourced Broadcom files “bootcode.bin” and “start.elf” in that partition.
The boot sequence carries out several pre-boot tasks
*On powering of the rpi, the GPU reads and executes bootcode.bin, which then loads start.elf
*The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it
*configures the memory split for the CPU and GPU
*reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings)
*loads the “kernel.img” file, again from the same partition
*activates the CPU to begin executing the loaded kernel image
The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU.
RPi uses [https://github.com/raspberrypi/firmware some closed source loaders] and at some point it loads a binary blob named "kernel.img" at 0x8000, at that point there would be a rudimentary Aros alive. If one wants to use the SD-card then there would have to be a driver for the interface and a fat filesystem handler (SD-card has to be formatted to fat filesystem)
Boot code and kernel are now linked together and made into that binary blob, just for starters. Raspberry Pi uses [http://kernelnomicon.org/?p=133 u-boot] and [http://kernelnomicon.org/?p=138 UBoot] as bootloader, there's already some code in the Efika MX port for that. UBoot is a native bootloader and not just for the raspberry pi, it loads after start.elf.
You can find Efika MX port from arch implementations, some hacking is needed for the mmakefile.src'es as iit dates back to before the Aros crosstool era or else you get some weird errors while building. You also need to code the bootstrap and serial handling.
At the moment it seems that a fastest route for the native build would be to make one binary blob without using the package system. Raspberry's memory layout is pretty simple and if the implemented u-boot doesn't support loading other modules
<pre>
? - alias for 'help'
mtest - simple RAM test
autoscr - run script from memory
base - print or set address offset
bbm - BBM sub-system
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
jade -
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv - print environment variables
rarpboot - boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saves - save S-Record file over serial line
setenv - set environment variables
sleep - delay execution for some time
tftpboot - boot image via network using TFTP protocol
USB - USB sub-system
usbboot - boot from USB device
version - print monitor version
</pre>
Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,
Framebuffer - basic display
RasPi has to speak to the "operating system" which runs on the GPU itself and request/free memory - it cant directly manage it itself, and so the managed functions were used to wrap these calls.
The Arm and GPU share memory space. The framebuffer is shared. The Arm can write a pixel and it will appear on the screen (through GPU hardware) without flushing/copying being required.
The GPU can composite multiple FB's in real time - so you have a number of surfaces defined which are rotated etc and composited in real time to the output. Copying can map from the address space of the Arm to the flat space of the GPU which takes some code, but I don't think whole buffers are copied.
The DMA hardware can also access the whole memory space and can perform 2D fills and blits (no blending). This is documented in the peripheral spec posted. The DMA is just an Arm accessible peripheral and can be set up with low latency (e.g. microseconds).
must use a 0xc0000000-based bus address to access SDRAM, yet non-DMA access should go via a 0x0-based bus address.
For 2D dma, set TDMODE, and the spec says "interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer." so set STRIDE to pitch of the image, the width is XLENGTH and height is YLENGTH. You would fill by not setting the SRC_INC and point source to your fill data.
The DMA cannot see the ARM's L1 cache, so you would map the framebuffer with ioremap_nocache. Depending on where the source data comes from, it may need an L1 cache flush. The DMA can see the L2 cache. Use 0xC0000000 bus addresses when L2 is disabled and 0x40000000 bus addresses when L2 is enabled. (actually just call virt_to_bus and you'll get the right address out).
openGLES/openVG has high latency. Writing to framebuffer then reading it back is very inefficient (e.g. milliseconds). If you can drive it a unidirectional way, just streaming commands at then that is efficient. openVG is not implemented on top of openGLES - it uses the same hardware but as a first class interface
To improve the Gfx driver, we will need a DMA resource implemented so can use to perform DMA operations. The Gfx driver will need this to perform blits.
USB
* Model A and B limited to 150 mA per port.
* Model B+ and Pi 2 introduced configurable 600 mA to 1.2 A support over all ports - anything above that requires a powered USB hub.
Implementing the hardware driver that Poseidon uses to interact with the USB components.
Have code in place to (try) and initialise the USB chipset, and configure host/device mode operation (though AFAICT Poseidon doesn't support device mode). Started to get the "virtual" root hub written for the single USB port so that Poseidon should at least list it correctly in the GUI - and try to interact with it to find peripherals.
The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”).
There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA. However, there's a Linux driver written by Synopsys ([https://github.com/raspberrypi/linux dwc_usb]). Specifically directories [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_common_port] and [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_otg].
The Synopsys code is actually under a fairly permissive licence – it's not GPL, it's similar to BSD (’don't sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code.
The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port).
Probably only need provision of relevant changes to dwc_common_port. Other things to consider....
* Provision of necessary headers to get it to compile
* Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes (multithreading) )
* Interfacing between USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start.
the Linux bits of the headers are only required for the dwc_common_port library. dwc_common_port includes a variety of crypto functions which are not used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn't going to be for plain wired USB.
Every USB driver acts as an USB hub as well in order to let Poseidon control the state of USB ports. The code there was reading status of the only USB port in Raspberry's CPU but when changing the status it erroneously deleted some of the status bits, including the port enable one. It was so because those bits in the status register are of a type Read/WriteToClear. It means, if one does not want to change their value from 1 back to 0, one has to actually write the 0 value. Very practical thing e.g. in interrupt handlers, where one reads the interrupt status register to learn what was the interrupt reason, and writes it back to the same register in order to clear the interrupts.
After fixing that code it turned out that the communication was still unsuccessful. Apparently the USB device was not understanding the host for some reason. That should not happen since the request sent was one of the standard ones implemented by virtually anything with an USB connector, assumed that Poseidon clears the data caches before forwarding the work to the USB drivers but that's the responsibility of the driver itself.
The USB device responded and acknowledged the transmission! But why were all the request sent after address change failing with timeout? They should not. Once again, address set is supported just by anything. Tried to contact the device at address 0 once again and there it was, still responding properly. The enlightenment came. The bus address for DMA transmissions was, as it is in many bare metal USB implementations, just the pure memory address of the buffer as seen by the ARM cpu. Have "prefixed" it with the real location of uncached RAM and booted AROS once again.
Trident saw this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
and this:
Product : Vendor: Vdr=0424/PID=EC00
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 255
SubClass : 0
DevProto : 1
VendorID : 1060
ProductID : 60416
DevVers : 0200
and even this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
What are these things? The first one is USB hub built in the Raspberry. Thanks to this one the Pi machines (with exception of Pi0 and computing modules) have more than just one single USB port. The second one is the network chip in raspberry, the third one is my USB SD card reader which have just connected to see what happens. AROS tried, of course, to boot from it ;)
So, the first step towards working USB is done. The control transfers are working as you can see above. Next step is to implement bulk and interrupt transfers, having the basics in place. Finally some error handling will be added and USB for Pi will be as complete as the PC version.
[http://www.raspyfi.com/raspberry-pi-usb-audio-fix/ Issue with USB Audio]
Audio
[https://github.com/raspberrypi/linux/tree/rpi-patches/sound/arm audio] and its [https://github.com/raspberrypi/firmware/issues/2 very high speed message passing interface type of thing VCHI]
The Model B+ added an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality
the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures
Analogue audio
Audio over HDMI rev 1.3 & 1.4
Ethernet
10/100 BaseT Ethernet RJ45 socket
GPIO
GPIO shouldn't be too bad but bear in mind it is already accessed in places so they would need to allocate pins etc through it (e.g. sdcard to flicker the activity light, serial debug to output data on the GPIO pins)
Probably a resource rather than a device...
Started an i2c driver that will need to allocate GPIO pins. Feel free to work on it if you are interested ;p
GPU graphics with 2D and 3D acceleration
Sadly none yet for 32bit but for 64bit...
== References ==
===Hosted===
==== Linux ====
Change lxde to another
sudo leafpad /etc/x11/xinit/xinitrc
xorg.conf
<pre>
Section "Screen"
Identifier "Default Screen"
DefaultDepth 16
SubSection "Display"
# Viewport 0 0
Depth 16
Modes "800x600"
EndSubsection
EndSection
Section "Device"
Option "Backingstore"
Identifier "Card0"
EndSection
</pre>
Will raspberrypi ARM programs run on other ARM archs and vice-versa ? If not I would like to use different cpu names for
archs which are incompatible.
All code compiled for at most armv6 with softfp float abi will work on all softfp ARM targets, including raspberry.
Code compiled for hard-float ABI will not work on any softfp target. But then, hard-float abi uses -armhf- cpu name.
keyboard or mouse not functioning or partly working
lsmod
kernel and modules (stored in /lib/modules/ get from https://github.com/raspberrypi/firmware and click on ZIP button) have to be updated simultaneously
sudo Apt-Get Update
sudo Apt-Get Install <program >
<program > cksfv joystick p7zip-full stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 libreoffice epiphany-browser xbmc
ace-of-penguins gweled black-box petris xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis xbubble eboard&xboard (freezes) bomberclone
OMXPlayer not responding or working with keyboard or no sound audio through HDMI
LXterminal—command "OMXPlayer -o hdmi %f "
hdmi issues
Setting the hdmi_force_hotplug=1 makes sure the Pi believes the monitor/TV is really there.
You might also need to set config_hdmi_boost=4 or even higher (up to 9) if your display needs a stronger signal.
If the display is a computer monitor or newer tv, use hdmi_group=1 (auto HDMI use) and if it is an older TV, try hdmi_group=2 (for DMT formats, i.e. for PC monitors) then you HAVE to "set hdmi_drive = 2 to enable HDMI output as this forces HDMI mode rather than DVI mode
Do not set hdmi_safe=1 as that overrides many of the previous options.
Using a shorter or better quality HDMI cable might help. Make sure your Pi's power supply delivers 1 A and not 500 mA.
If you see a problem with the red colour - either absent, or interference - then try a boost
composite video
changing the RCA cable, then the composite port worked out of the box
Boot it as you are doing, without HDMI. If you now plug in the HDMI, do you get the image? In other words, does the Pi think HDMI is connected even when it isn't?
Rename all the files in the first partion of the card except bootcode.bin, start.elf and fixup.dat What's the result?
Put back config.txt What's the result?
for PAL mode sdtv_mode=2
dmi_ignore_hotplug Pretends HDMI hotplug signal is not asserted so it appears a HDMI display is not attached
hdmi_ignore_hotplug=1 Use composite mode even if HDMI monitor is detected
<pre>
# NOOBS Auto-generated Settings:
#hdmi_force_hotplug=1
#config_hdmi_boost=4
#overscan_left=24
#overscan_right=24
#overscan_top=16
#overscan_bottom=16
#disable_overscan=0
start_x=1
gpu_mem=128
</pre>
tvservice -c "PAL 4:3"
<pre>
/opt/vc/bin/tvservice -s or tvservice -s
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
(native) mode 16: 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m DMT
Group DMT has 0 modes:
</pre>
sudo amixer cset numid=3 1
forces the audio to the headphone jack, even with the HDMI video output plugged in
config.txt
the hdmi_ignore_edid_audio=1 option sems relevant as it should tell ALSA that the only available audio is analog, no matter what the display says
There are several different ways that these 4 pole (ring) composite analog cables can be wired up, so some work great in some applications and can be a waste of time in others.
What is needed for the Raspberry Pi B+ and above, which like many camcorders needs the ring contact next to the base contact to be the ground.
The wiring for the 4 pole are:
TIP (LEFT AUDIO CHANNEL)
RING 1 (RIGHT AUDIO CHANNEL)
RING 2 (GROUND/EARTH)
RING 3 BASE/SLEEVE (VIDEO) YELLOW
Most Apple based Players and the Microsoft Zune (TM) are wired this way.
Most analogue camcorders are wired this way as well, where the ground in on Ring 2 will work with the Pi although you may need to swap your Video plug with the Right Audio plug.
Nearly all other MP3 players are not wired this way, the ground is on another ring ie the wrong one.
External devices
* Camera Module Omnivision ov5647 Sunny 5MP (NoIR version) V1.3 - NoIR at 850 nm, peak at 880 nm and trails off at 940 nm wavelengths
* Camera V2 Sony IMX219 V2.1 8mpixel 8MP 8megapixel - 3280 x 2464 pixels - video at 1080p30, 720p60 and 640x480p90 - wider field of view, 62 vs 54 degrees horizontally -
* Branded WIFI usb BCM43143 dongle
N.B. dreaded error after changing cameras (stupidly without turning off the power first) and lasted through several power cycles. It can be a bad 15-pin FFC ribbon cable, when swapped, camera(s) and the Pi itself are working OK. It can be an instance of a cold solder joint on the CSI connector on the pi board. the camera can be detected (that's done via I2C) but may still not be able to receive image data (done via CSI-2) if something is broken. CSI-2 is uni-directional. Control is generally done via I2C.
The CSI-2 receiver always writes to memory, not direct to the ISP. That's the way the Broadcom architecture works as it allows multipass processing easily. GPU memory is accessible from the ARM. Processing using the QPU graphics processors may be possible. currently the only supported sensor is OV5647 and IMX219. The linux drivers are all in the firmware blob, else you'd be looking at at least a man-month of work in a fully fledged imaging lab to do a decent tuning of the camera modules' ISP parameters.
Static electricity maybe an issue for the camera module and slightly less for the pi board.
* Hosted under ARM Linux which needs to be already installed [http://www.aros.org/nightly1.php current ABIv1]
Help building AROS hosted on Linux ARM
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:
<pre>
Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic':
configure: error: C compiler cannot create executables
See config.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2
</pre>
looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.
now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)
P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.
Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.
My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.
Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.
For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.
Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.
Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh
I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:
#MM- linklibs-armhd : libklibs-aeabi-arm
Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.
I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...). Smile
To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.
With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.
8lk9dju943bpcyphxx15xu3ydcy2snu
4655988
4655987
2026-08-01T11:46:35Z
Jeff1138
301139
4655988
wikitext
text/x-wiki
{{ArosNav}}
[[#Native]]
[[#Hosted]]
==Introduction==
The Raspberry Pi Foundation is a charity founded in May 2009 to promote the study of basic computer science in schools, and is responsible for developing a single-board computer called the Raspberry Pi.
The Foundation is supported by the University of Cambridge Computer Laboratory and Broadcom. Its aim is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing."
The original Raspberry Pi 1 Model B computer went on sale in February 2012 and set a new standard shattering the dominance of the PC in the home and education markets. Millions in the various formats, A, B, A+, B+ and Compute have since been shipped worldwide. The original concept of the Raspberry Pi was for a computer board providing Internet access with up to 1080p HD graphics at very low cost. The boards provide a platform for children and adults from any background to acquire computer science knowledge and help develop the future World-Wide-Web and all things internet (IOT hub and bridges out to home network to cloud of sensors).
Hobbyists and tech dabblers/tinkerers are the main purchases of the Pis (around half).
The rest of the sales are split between education/industrial. While the Raspberry Pi boards were designed primarily for education, they have become very popular with manufacturers of embedded systems. The Raspberry Pi Foundation has ensured backwards compatibility with each new revision. The bare-bones Compute module is aimed specifically at the OEM manufacturer.
* Pi 5 - Quad A76 and RP1 "southbridge" with VideoCore 7 4Gb 8Gb LPDDR4X
* Pi 4 - Quad A72 64bit VideoCore 6
* Pi 3 - Quad A53 [https://www.raspberrypi.com/documentation/computers/processors.html 64 bit] - VideoCore 4
* Pi 2 - Quad 32bit but more power consumed
* Model B+ - lower power usage but same speed as the original Pis
* Model A and B -
* Compute 1, 3, 4 and 5 - industrial use
<pre>
2008 Trustees collected for Foundation
2009 Charity status gained
2010
2011 First Raspberry prototypes
2012 First boards go on sale at CPC and RS. The Model A and B 700 MHz Arm11 - February 29th BCM 2835
2012 First million sold - more than the 10,000 original planned and anticipated
2013 First Alpha Experimental builds of AROS Native for the Pi
2013 Pi Trading launched making grants available, providing in house educational resources and Pi Academy for teacher training
2013 Over two million sold
2014 Over three million sold and updated Model B+ introduced that moved composite video to audio jack and same half gig of memory
2014 Pi Model A+ v1.1 - BCM2711 no ethernet and 1 usb - a little smaller -
2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit core and 32bit VideoCore IV 3d GPU with 1Gb RAM
2015 Over four million first gen pis sold
2015 Over a million pi2s sold
2015 Pi Zero BCM2835 released
2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837
2016 Passed Sinclair total number of computer lines sold - around 7 million
2016 Pi 3 Model B - Broadcom BCM2837 SOC four 64bit ARMv8 Cortex-A53 1.2GHz - 1Gb - bluetooth 4.1, Cypress CYW43438 wireless 802.11n and a dual 32bit VideoCore IV GPU - 4 x USB2.0 ports
2016 Total PIs over 10 million worldwide
2016 Compute 3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage
2017 12 million pis sold in total
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 - 1Gb, wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet - 4 x USB2.0 ports
2019 Over 15 million sold
2019 Pi 3 Model A with BCM2837b0 with 512Mb,
2019 Raspberry Pi Compute Module 3+ CM3+ LITE Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc
2019 Pi 4 Model B - BCM2711 quad 64bit A72 1.5GHz, VideoCore VI, AC wifi, Bluetooth 5.0, GbE, 2 micro hdmi decode up to 4K, USB-C power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram
2019 Pi 4 Model 2B - BCM2712 4 usb
2020 Raspberry Pi SC0919 Pico RP2040
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard
2020 Raspberry Pi Compute Module 4
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam
2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu
2024 Raspberry Pi Pico 2
2024 Pi 5 2GB version uses BCM2712D0
2024 Pi-500
2024 Raspberry Pi Compute Module 5
2025 Pi-500+
2026 April and May Aros 64bit fixed, added AHI audio, VC4 gfx started, usb functions added to rom
2026 June and July Aros 64bit usb2otg started, dma.resource, sdio.resource, bwfm.device wifi added
2026 Late July daily 64bit Pi3 builds start
2026 August ....
2027
2028 Pi 6
</pre>
===Good sites to visit===
*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build]
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build]
*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 32bit]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k]
===Native===
* 2013-03 Kalamatee starts work
* 2013-05 Work put on hiatus
* 2015-04 Work continues slowly with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb
* 2018 [https://www.patreon.com/posts/i-owe-you-some-20956961 mschulz resume with adding BE big endian support as well]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=bsek latest commits for pi 3 64bit]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=jonx latest commits for pi 4]
64bit ArmV8 builds are
The status of AROS 32bit native for RasPi was OK. System booting, USB working (although with some issues but plan to fix them). Got stuck on modifying the ABI (application binary interface) and adjusting binutils/gcc to support it wanted to have real executable files but got stuck a little. This change for the type of relocations embedded in ARM files and not sure if this very type is well supported, on the other hand without this change ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.
Old native [http://www.aros.org/nightly1.html ARMv6 32bit nightlys] and
===Hosted===
[http://www.aros.org/snapshots1.html old linux and android hosted 32bit]
==Build==
===64bit===
===32bit===
# download/checkout the source someplace, e.g. /build/AROS-Src/
# make a directory to store external sources AROS downloads, e.g. /build/Ports
# make a build directory, e.g. /build/aros-raspi-armhf
# cd into the build dir, configure, and then run make -:
<pre>
>cd /build/aros-raspi-armhf
>/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
>make
>make arosboot-raspi
</pre>
then copy the files from /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ onto an sdcard, and download/copy the Raspi firmware files onto it.
You should then be able to boot the sdcard on your RasPi.
The current W.I.P tree to svn. it can be built as follows ..
<pre>
./configure --target=raspi-armhf
make arosboot-raspi
</pre>
That will generate arosraspi.img, arosraspi.rom and config.txt in bin/raspi-arm/AROS - so either copy just those files to a fat formatted SD card (with the firmware files on), or copy the whole contents of the AROS folder.
NB - if you have a Linux/other install, backup the existing config.txt first
arosraspi.img contains the bootstrap (which has very basic mailbox code, framebuffer/gpio init, and console "emulation" via code pinched from our libbootconsole), kernel.resource, and exec.library
arosraspi.rom contains all the other components needed to boot AROS.
The config.txt file will tell the RasPI bootstrap to load our arosraspi kernel and ramdisk (rom).
the bootstrap has minimal mailbox code, planning on adding either a resource or library that driver/app code will use to access it (likewise for GPIO)
==== Hosted ====
Ubuntu VM approach to compiling [http://lallafa.de/blog/2013/06/building-aros-hosted-for-raspbian/ Linux hosted AROS June 04, 2013]
../AROS/configure --target=linux-armhf --enable-includes=/usr/arm-linux-gnueabihf/include --x-includes=/usr/arm-linux-gnueabihf/include --x-libraries=/usr/arm-linux-gnueabihf/lib
arm-elf- is symbol-linked to arm-linux-gnueabi- (arm-linux-gnueabi- is more correct in this case, because it's going to be compiling the ARM AROSBootstrap for ARM Linux)
*armel - many of the "android" machines require since the entire OS is made for soft float VFP.
*armfp - Efika MX target, Raspberry PI, EfikaMX, Pandora and virtually everything (VFP)
Keep in mind it's possible to start hardfp AROS hosted on softfp system, though, as long as no calls between AROS and host require floating point parameters. NOTE: hardfloat objects *cannot* be linked with softfloat objects - they have a different ABI.
Just keep in mind the arm nightly build machine is quite complex beast. It needs the x86_64 host compiler to compile AROS tools. The arm version is built every night using gcc-4.6.2 crosscompiler (built together with AROS) and successfully builds armel and armhf linux hosted targets.
*needs an AROS code compiler for ARM target
*as well as unix compiler for ARM linux host (would be best to have both softfp and armhf, we have softfp only now) with full set of libraries and includes.
with—disable-crosstools $AROS_CC is always a wrapper around $KERNEL_CC ? If so, this is wrong for some ports. This can break Darwin, Windows and Android port.
Yes, Android port will build. And even work. But it's not good because the port will not be ABI-compatible with other ARM ports. Android's ABI is different from GNUEABI. For example:
<pre>
enum test {foo, bar};
enum test testvar;
</pre>
siseof(testvar) will be equal to sizeof(int) in GNUEABI (Linux and AROS) and sizeof(short) on Android. This affects linking objects from static linklibs, for example.
Previously everything worked because $AROS_CC was a wrapper on top of $HOST_CC. And a real crosscompiler was used on non-ELF hosts.
Android is the same. $KERNEL_CC is incompatible with AROS.
compiler=kernel is appropriate _ONLY FOR CODE WHICH RUNS ON HOST OS_ (or barebone hardware, if we talk about native). This includes bootstraps, their linklibs, and host-side dynamic libraries (Windows makes extensive use of them because of architectural considerations.
No single AROS object should be compiled with this setting. $KERNEL_CC is really compatible with AROS *ONLY IN LINUX-HOSTED* and no more. On other systems (Darwin, Windows, Android) this is not true any more, and compiler=kernel is never going to work.
If you want to compile your AROS module against host OS includes, append the following to USER_INCLUDES (or USER_CFLAGS, this is effectively the same):
-isystem $(GENINCDIR) $(KERNEL_INCLUDES)
$(KERNEL_INCLUDES) expands to:
-isystem <your_os_includes> -isystem <host_OS_gcc_private_includes>
-nostdinc
This makes AROS compiler adhering to host OS APIs.
If you want some preprocessor symbols based on what your host OS actually is, add something like -DHOST_OS_$(AROS_HOST_ARCH).
Why is there $(GENINCDIR) at all? Because host OS has its own libc includes, which would conflict with AROS ones. And the host OS libc is not binary-compatible with AROS one.
Why doesn't Windows-hosted port use $(KERNEL_INCLUDES) ? Because WinAPI includes conflict with AROS ones in fundamental typedefs, like WORD, BYTE and BOOL. It's almost impossible to deal with this in any other way than rewriting WinAPI definitions using AROS types.
Building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. haven't yet committed the necessary changes but "./configure --target=raspi-armhf" is enough to start, then "make arosboot-raspi" will generate arosraspi.img (containing the bootstrap, kernel.resource, and exec.library) as well as arosraspi.rom (containing all the other essentials components such as dos, graphics etc). It will also copy over a config.txt file to make the raspi bootstrap code load the correct kernel, and a cmdline.txt that enables exec debug output.
*armel = typically Debian 6, Ubuntu Maverick, Android,
*armhf = typically Debian 7, Debian 8, Ubuntu Precise,
Cross-compiling Ubuntu ARM softfp
<pre>
sudo sh
echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
</pre>
<pre>
./configure --target=linux-arm --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabi/include
</pre>
Cross-compiling Ubuntu ARM hard-float
<pre>
sudo sh
echo 'foreign-architecture armhf' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armhf.list
apt-get update
apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
</pre>
<pre>
./configure --target=linux-armhf --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabihf/include
</pre>
Now, the AROS build is configured properly and all you need to do is:
make
[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]
== Hardware ==
===64bit===
====BCM2712====
BCM2837
* Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support, 3B+ [https://github.com/aros-development-team/AROS/commit/afa5bc0bb17d5dd06bcfdbac00853a3799ca8d76 LAN7515]
====BCM2711====
===32bit===
=== Core Kernel ===
the reason behind INTB_KERNEL is to allow use of the standard Exec function AddIntServer() to add interrupt handlers for
hardware drivers etc. AmigaOS never used it for abstract hardware drivers. AmigaOS routed only raw hardware IRQs there. Their assignment was hardcoded. As well as number of them. Actually on AmigaOS every bus has its own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt. 1:1 relationship between CPU and hardware interrupts is present only on PC.
IMHO we miss things like AddInterrupt/RemInterrupt methods on our PCI subsystem's device class. PCI bus class should map these methods to whatever is appropriate. This is how it is done on AmigaOS and friends. When these are implemented, raw kernel.resource API will be needed only for several PC-specific drivers with hardwired resources. Exec IRQs are real IRQs only on Amiga hardware. On other machines they can be emulated where appropriate (VBlank is a good example). kernel.resource is meant to be different, its IRQs are hardware-agnostic, they are plain "Hardware IRQ number X, whatever this means". They are low-level actually, and meaningful only in the context of a particular system.
Was that not the transition from irq.hidd to kernel.resource? No. A long time ago there was another hacky bit named INTB_TIMERTICK. It was "abstract timer interrupt", used by timer.device. It was the same as VBlank, but with larger frequency. I removed it, because kernel.resource API was a cleaner way to access this interrupt. Furthermore, there can be more than one timer in the system. I am even thinking about bringing back timer HIDD definitions again. hpet.resource is a bad idea.
Can someone please enlighten me a little on how the scheduler is meant to work?
Poseidon.library creates its "Poseidon Event Task" during RTF_COLDSTART -> then calls Wait(), and ends up in limbo because wait disables interrupts (used for the scheduler heartbeat), and basically waits forever because the sigbit is never set, since krnSwitch doesn't switch the task unless TF_SWITCH is set, and no codepath run during this seems to set it?? TF_SWITCH does not disable/enable switching. This flag just enables to run user-supplied hook when the task is being switched away. It is completely safe to call Wait() in Disable()d state. Doing this actually temporarily breaks this state. IDNestCnt gets remembered in struct Task, then next task is selected, and its IDNestCnt is restored in sysbase (see kernel_scheduler.c). If there are no other tasks, then your cpu_Dispatch() should enable interrupts on the CPU and enter idle mode. See x86 implementation for good example.
You miss what happens next...
1. KrnSwitch() saves context of your task, saves IDNestCnt (core_Switch() and cpu_Switch()), then drops into cpu_Dispatch().
2. cpu_Dispatch() calls core_Dispatch. Then two cases are possible:
2a. There is a READY task. It is picked up, its IDNestCnt is restored in SysBase, then cpu_Dispatch() needs to restore registers and exit. The next task is run.
2b. There are no READY tasks. core_Dispatch() returns NULL. In this case your cpu_Dispatch() should enter idle loop. It should just enable interrupts on the CPU and put it on halt. This allows it to process hardware interrupts. Eventually some of your interrupt handlers wakes up your task and puts it into READY list.
My heartbeat interrupt has been slowed atm to help debugging - but it never actually gets a chance to fire because of the Wait() disabling interrupts. Perhaps you have forgotten to enable interrupts in your idle loop.
There is a change in the format of AROS executables. Until now we were using Elf RELocable files which are usually used as intermediate object files. We had them for various reasons, one of them was how AROS files were built in the past. That days we had no real aros cross compiler and the option to embed relocation data in unix executables (or in executable files in general) was rather new and not every linux/unix system had it. Therefore we have decided to use intermediate files. Although it was somehow working (and it is still working :-)), it has some drawbacks. Therefore decided to introduce real Elf EXEC types, in first turn implemented on ARM target with option to expand in future to all other AROS architectures.
The first patch was pretty easy and appeared to work somehow. It generated nice executables with embedded relocation info. Not only that, it also removed all global symbols adjusting relocation data to be relative to the beginning of the sections. That move reduced number of symbols in each executable significantly (depending on the file between 20 and 80% of all symbols could be removed). The only symbols that stayed in the file are local ones - due to the nature of the patch wasn't able to remove them since we have not seen them in the symbol hash table.
The patch didn't worked though. The files were relocated, AROS kernel loaded, but it crashed very early. What happened? Well, the nature of ARM relocations happened :)
Most of the relocation data on all machines is rather simple. Relocation can be absolute or pc-relative, sometimes the offset has to be bit shifted. On ARM v7 there is another one. There, when one wants to load an address of function/variable into register a combination of two instructions can be used: movw and movt. The first one loads immediate into lower 16 bits of a register while clearing upper 16 bits. The second one loads immediate into upper 16 bits without touching lower halfword. Loading of a pointer into a register looks like this:
movw r0, #:lower16:label
movt r0, #:upper16:label
In this case there are two relocations - one for lower halfword and another for upper. If an overflow of lower 16 bits occurs during relocation process, the upper one should be updated as well. Unfortunately with current patch and with typical ARM executables there is not enough information to perform the calculations.
There are two options - the first one would be to give up and go back to "fake" executables, another one would be to change from REL to RELA relocation info. The latter contains an addend, extra data which can be used to perform all the relocation calculations I need.
Decided for the second option. The patch is already in the works. There is another function for the binutils' bfd backend to perform the final relocation. There can decide what to do with every reloc info, modify data and eventually strip some symbols. An advantage is - at this stage of the linking process have also full access to all local symbols so can change all relocations section relative and eventually strip all symbols from the files.
=== GPU ===
Most of start.elf runs on the GPU. Placing ALL the userland GPU code in the videocore.hidd isn't going to be a terribly big problem because the code they published is nothing more than a shim that sends data straight to the GPU to execute.
The good news about this is that we only need to write our HIDD using the OpenVG API. The shim is relatively small codewise and lives in the ARM memory (the actual OpenVG code itself lives in the GPU RAM area and its loaded from start.elf). That's also the bad news. Our driver has to translate AROS video calls to OpenVG calls, for most tasks it should be easy, for some, not so much. It's still probably less difficult and less work, than controlling the GPU directly.
The other good news is that anything done through OpenVG happens on the GPU, its truly accelerated. It also has some nice font functions, meaning we can lead into an accelerated text mode later.
Basically, AROS resets or locks up when it tries to use AROS_ATOMIC_INC or DEC. If I comment out the byte/word operations in the header files and use non-atomic operations, the code works as expected.
have read that the L1 cache needs to be enabled to use LDREX and co (which I also read is only meant to be used on multi processor systems with shared memory) - however I am certain this is correctly enabled.
If you are using LREX or STREX, you should have L1 cache enabled, at least on the ARM CPU I work with at work.
L1 cache is enabled by enabling the MMU *AND* setting the C and I bits in the CPU - the C bit is ignored, and the I bit only covers the 16 byte instruction pipeline if the MMU is not enabled.
Can you verify that your assembly is generating LDREX/STREX? From the behavior, it almost sounds like its generating the default Semaphore locked atomics.
Impossible. There are no semaphore-locked atomics. There are Disable()/Enable()-based ones instead. And there's a special #define AROS_NO_ATOMIC_OPERATIONS in this case, which tweaks Disable()/Enable() implementations not to recurse forever.
I have tested this on ARMv5 which does not have ldrex/strex, it works fine. On those ARMs there's no way to have real atomics. On other OSes (like Linux) this is done by introducing things like atomic_t, which appears to be a complex structure, holding the value together with accompanying spinlock (implemented using swp).
#warning "TODO: lookup optimal mmu table settings for raspi memory"
/* Set up an identity-mapping for all 4GB */
for(x = 0; x < 4096; x ++)
{
pagetable[x] = x<<20 | (0x40002|0x80000|0x010000|0x00C00|0x04);
}
Shouldn't there be a second loop that sets the 'C' bit in the descriptor for the RAM pages?
Currently, you have TEX=0, C=0, B=1 for all pages (Shared Device).
You should have TEX=0, C=1, B=0 for RAM (Write-Through, Cached)
So ..
pagetable[x] = x<<20 | 2;
should be enough?
No, for RAM you need to change the '| 0x40' to '| 0x80'
tell dosboot the correct defaults to use
Please don't do this. This bootconfig.c is a deprecated legacy thing. I wanted it to go away completely with time. Instead, display drivers should auto-install themselves during own initialization phase. I. e. detect hardware=>instantiate itself. This should make things way simpler. With this approach you only need to add the driver into KS image to get the device autobooted. No
hardcoded stuff.
Currently VESA and VGA drivers do this, look there for examples. never rewrote ATI driver because i don't have any test system for it.
they defined a smaller AROSCPUContext than the ExceptionContext - yet reference it as ExceptionContext in other places, and since it hasn't allocated enough storage for ExceptionContext, are corrupting memory/the structure (since the elements that are there don't map 1 to 1 with the exception context).
AFAIK, AROS has been moving in a different direction to this in recent
years. It is the job of graphics HIDDs to allocate bitmaps etc. so that
they have the most suitable characteristics, including allocating them
from GPU RAM where possible. The concept of chip RAM is only for legacy
code, and most if not all non-68k platforms should have all system RAM
marked as chip.
BTW, is the video processing code you mention CPU code or GPU code?
Also, IIRC we have support for "external memory allocators". Perhaps that's what we need for the allocation of GPU RAM through the mailbox.
All hosted and x86 native ports should use proper context formats.
trying to clarify if the vblank handler has to have run by this point to prevent this deadlock. Actually, no. Unless you have installed VBlank handler which should wake up at some point. Without VBlank there will be no quantum count. Consequently, there will be no forced preemption. But the rest will work, and multitasking will be cooperative (switch happens only when current task voluntarily gives up the CPU). Does it depend on the vblank having run before this point? and if yes what does that mean on systems where it might be able to run enough code (e.g. get to this point) before the vblank interrupt has triggered? What is it waiting for? It could wait for timer, in this case you need timer.device working. VBlank is currently needed for exec's quantum counter. In current native ports we have only a single timer, which is served by timer.device. VBlank is simulated by timer.device also. If your machine has two timers, then you can use one of them for VBlank, and another for timer.device, this will simplify things down. VBlank needs to be 50 Hz for historical reasons, many programs use it as cheap timer. I am periodically thinking about making some abstract mechanism to be able to change quantum source (and untie it from 50 Hz), but have no time to come up with something good. Additionally i started disliking timer.device hardcoded design when PC has got many timers (old 8253, APIC, HPET).
Currently i think there should be some low-level entity representing tick source. timer.device should just select the most appropriate source for its units.
The BCM2835 has 4 GPU based timer sources - 2 are used by the GPU, so im using Timer3 for our heartbeat and the remaining one will be free to the system. There is also the less capable ARM timer but that is dependent on the CPU frequency. Very good. You won't need any emulation. Set the heartbeat to 50 Hz and drive VBlank from it. Use other timer for MicroHZ.
Can you use the 'econsole.hook' I make for debugging the Sam460 via the serial port?
It provides a before-anything-else shell prompt on the serial port. You can then do 'NewCLI' to test your graphics, or use any DOS command in shellcommands.resource.
You should just be able to add econsole.hook to your module list, and use 'econsole' in your bootargs.
So long as you have a working Exec/RawMayGetChar and Exec/RawPutChar, it should work.
Also make sure to add shell.resource and shellcommands.resource for this.
That should have done it.
If you set "#define DEBUG 1" in arch/all-native/econsole/econsole.c, do you get any additional serial output?
have added it to the build and added econsole to the command line - and can see the bootloader picks up on the emergency bootconsole tag, but I still only get the insert bootable media display?
Im assuming it exposes a fake filesystem that tricks aros into booting?
The contents of which are: ECON:AROS.boot
Way to handle the scheduling code? The implementations I had been following were causing problems, due to cascading interrupts which I cant handle properly in the asm stubs just now (when they break disable etc.) - since it means detecting the interrupted codes cpu mode and getting the correct sp/lr for it, and that's just too tedious for arm.
To work around this ive added a system idle task which does nothing - and when the scheduling code has no task to run switches this in and lets it run, thereby allowing the interrupts etc to resume until something does need to happen.
Also, by adding accounting code to cpu_Switch() and cpu_Dispatch(), it should allow the system to log idle time correctly (as well as running tasks).
have thought of also adding an additional task that never runs, solely to record time spent in IRQ handlers, but I digress..
was under the impression that kernel.resource should *never* be used outside of exec.library. This is a wrong impression.
Michal started designing it because portable nature of AROS does not fit well into exec's API with all its assumptions. So, he started the new, hardware-agnostic kernel API from scratch. Yes, exec sits on top of it in places. But kernel always meant to be open thing. Otherwise it would not exist.
it wasn't meant to be just used willy nilly by user code - but by lower system components (e.g. exec) so that they could be implemented in a more generic fashion, and the kernel resource itself hide the systems quirks.
Adding new things there perfectly keeps up with our decision to minimize AROS-specific intervention into APIs which can clash with MorphOS/OS4 extensions. We want at least source-level compatibility there. Binary compatibility on PPC would be extremely cool, but at the other hand we have no maintainer for this, as well as their ABIs are a bit weird and far from optimal, especially MorphOS one, because it aims for m68k binary compatibility.
It depends on what exactly is being implemented - there's no reason we should have everything crammed into kernel.resource if it doesn't need to be (i.e. if its better suited as a separate component/subsystem in its own right)
The _LE versions are for when you have endian swapping taking place. If the graphics are the same endian as the CPU, no swapping should occur. I ran into a similar terminology problem in SDL with a friend insisting that his Radeon 7000 on his PC was big-endian. It is not, it just uses the same endianness for the graphics card and the CPU so no swapping was necessary. They were both little-endian.
The _LE versions are because the PixFmts refer to the bitmap data being in big endian format in memory, for which the normal version would need to do endianness conversion before applying the shifts/masks. on this platform it is in _LE in memory also so we don't need the conversion hence using the _LE version of the call). would use _LE (if it's really little endian 16 bit mode).
What is the bare minimum needed to implement a framebuffer based gfx driver, with our software handling the rest?
I have tried with just a gfx class that only expose new/dispose/newbitmap - and having an onscreenbitmap used only for the framebuffer itself (with all other bitmaps being chunkybm, and the framebuffer's superclass also being chunkybm), but that alone isn't enough it seems?
You can use workbench/hidds/sm502/ as your example - it is as simple as I could make it.
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
I so far have -:
vc_init: queries the gpus memory, and sets up a fake memory handler for it, then adds the bootmode driver and returns saying all is well
vc_gfxhidd:New: sets up some fake syncmodes to test with and creates the real gfx object.
vc_gfxhidd:NewBitmap: checks if its a framebuffer and uses the onbitmap class or uses the chunkybm class otherwise
vc_onbitmap:New; creates a chunkybm object and then pushes the real framebuffer address into it as the buffer,
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
The code I currently have on SVN seems to create the framebuffers bitmap object fine, but then crashes in intuitions DisplayDriver callback. In particular it crashes performing the getattr on the system default pointer.
don't expose MEMF_CHIP in an allocatable form so AllocSpriteData was failing (and other code later doesn't check if the values are valid == illegal memory accesses)
Actually MEMF_CHIP has to present, for historical reasons.
This has been never fully agreed upon, but in ports i wrote i exposed the whole memory as MEMF_CHIP. The idea behind this is that CHIP is originally the memory where graphics and sound data can be put. On non-Amiga platforms there are no restrictions on this, so the whole memory is CHIP.
Yes, many old software can misbehave with CHIP memory size larger than 2MB. But this actually applies only to m68k AROS which is going to run m68k binaries. In other cases it's quite logical to fix the program when porting.
As to original question: yes, it's enough to have a framebuffer bitmap (one with aoHidd_BitMap_FrameBuffer set to TRUE) and PutPixel routine. It framebuffer can be served by chunky bitmap class, then you can simply create chunky bitmap with your own buffer (see how VESA driver does this). Chunky PutPixel is already there.
struggling to determine what is the correct pixfmt to use for the 24/16/15 bit gfx modes on the RasPi. AFAIK it uses RGB565, for 16bit but im unsure what shifts etc should go with it? suffice to say Im getting the wrong colors so far lol.
<pre>
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0
redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
</pre>
It should likely be vHidd_StdPixFmt_RGB16_LE
This stuff is a bit confusing. The "names" of the stdpixfmts are based on the layout in memory,
ignoring endianess. So for example:
ARGB32: will be 0xAA 0xRR 0xGG 0xBB in memory on both big endian and little endian machines.
The shifts and masks OTOH are based on pixel access (ULONG in this case), so differ depending
on whether you run on big endian machine or little endian machine (that's why there's stdpixfmt_le.h and
stdpixfmt_be.h in rom/hidds/graphics/).
With the 16 bit pixel format it's even more confusing, as for example it's impossible on little endian machine
to describe RGB16 with shifts/masks alone. That's why there's vHidd_PixFmt_SwapPixelBytes_Flag.
(RGB16 == RRRRRGGG GGGBBBBB in memory, and for pixel (WORD) access on little endian machine it needs to
be accessed as GGGBBBBBRRRRRGGGG).
The shifts btw indicate how much to shift the component to the left (!) so that it is moved to the highest bit (31).
The aHidd_PixFmt_StdPixFmt you specify will be ignored most of the time, because when the pixelfmt is registered,
the gfx hidd checks if there's an identical pixfmt (shifts/masks/etc., but ignoring pixfmt->stdpixfmt) already in the system,
and if so, it uses the already existing one and does not create a new one.
In theory it would be better if gfx drivers could simply/only specify a StdPixFmt without all the shifts/masks stuff when the
gfx driver uses pixfmt which matches one of the stdpixfmts exactly. Another possibility would be for gfx drivers to use
HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) and then peek shifts/masks from it and fill out a pixfmt
tag list based on that.
15bit very blue/green: Try to pass same shifts/masks/etc. as in 16 bit pixfmt (maybe you think it's using 15 bit R5G5B5
(or swapped) but it's actually still using 16 bit R5G6B5 (or swapped).
aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count.
But I would still pass the correct one (_LE) == whatever rom/hidds/graphics/stdpixfmts_??.h uses
in the entry where you have looked up shifts/masks/etc.
Use the shifts/masks/etc. from the entry in stdpixfmt_le.h (if you are running on little endian machine) or stdpixfmt_be.h (if you
are running on little endian machine) that matches the pixfmt that its meant to be.
0xAA,0xRR,0xGG,0xBB on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)
0xAA,0xRR,0xGG,0xBB on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_BGRA32)
it feels like AROS trashes the alpha component, otherwise it should be 8A8R8G8B.
read on the subject suggest its in 1x5r5g5b (x is ignored) to keep 16bit alignment .
What I see on screen suggests to me that wrong shift/mask are being applied - however going by the 16bit versions it all looks correct to me so I am really confused as to what is happening.
The output image looks to have too much green/blue, and very weak red.
Why did usbromstartup become HW-specific ?
In the past i have done a big job separating kickstart into several parts. I have never got any responses, so i re-describe my idea.
For now it loads the hs otg chipset driver ..
The idea is to minimize amount of archirecture-specific modules to
make user's life easier. So, the kickstart was split into 'base'
(which does not contain anything machine-specific) and 'BSP' (Board
Support Package) which contains all hardware-specific stuff.
This way, for example, distribution makers can save up space on CD
and make CDs with multiple platform support. Different configuration
would load the same base with different BSP's.
Next there was some part which is entirely missing on hosted. These
are filesystems. Hosted ports do not need them to boot up, so on
hosted they are left out. At the other hand, they are also
architecture-agnostic. So i put them into 'FS' package (standing for
'filesystem').
Poseidon is one more big part. I made it into separate package in
order to allow users to omit it if they don't need it (for example, to
run on retro PCs without USB). Personally i have one. Again, Poseidon
is hardware-agnostic (well, there are USB drivers but HCIs are pretty
standard).
It's mandatory on PI since there are no other interface types - so being a separate package is irrelevant/pointless.
Is Raspberry's USB controller non-HCI compliant? Actually i expect it to be compliant, then wouldn't it be better to make existing drivers discovering them?
AFAIK its HCI 1.0 compliant but I'm not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once i'm more familiar with the workings I can merge in the changes needed to get it operating but for now I will focus on getting it running. Also our drivers have known issues so perhaps a fresh set of eyes might shed some light on what is going wrong.
Another interesting question is whether Poseidon can operate on device side. Is it flexible enough? How similar is being a USB host and USB device? think it will need a bit of work on Poseidon's side. Until then I will force the driver into Host/Master mode in the init code, but leave open device etc to configure the chipset for either's use - and look at trying to add support for working in Device/Slave mode & switching modes once it's up and running.
Actually USBROMStartup is some kind of kludge. Can there be any alternative? Could device drivers be self-installing, like our HIDDs? This would get rid of need to list them in USBRomStartup.
And there is one more thing about modular ports. In order to actually implement this, your bootstrapping environment should provide the ability to load several files. On PC this is provided by GRUB2. on CHRP you can read filesystem via OpenFirmware, and Sam's Parthenope relies on modified u-boot. If your bootstrap allows to load only a single file, then you stuck with monolithic kickstart. By the way... u-boot allows not only to boot up a single uImage or zImage, it also allows to write client programs AFAIK. With this approach, you actually can write modular bootstrap for ARM AROS using unmodified u-boot.
[http://repo.or.cz/w/AROS.git/commit/e7bdc7e7b7f12b07aa24c739abb63721a872a53a arasan eMMC sdcard controller specific header which is not USB] and [http://repo.or.cz/w/AROS.git/commit/8bd19674084526a534ac11f7d4c51932e9ffe3d2 added prelim sdcard device]. [http://repo.or.cz/w/AROS.git/commit/9ab8217f61911fb8b7fd41bee46a992b4668ced1 do not set 4bit data mode, or enable acmd12/dma int's]
====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM)
*Framebuffer (fb) using mailbox
*IRQ scheduler, etc
*Arasan based SD Card controller
*Synopsis DesignWare USB 2.0 OTG controller [http://networkdirection.net/index.php?option=com_content&view=article&id=106:rasperry-pi-usb-controller&catid=45:raspberry-pi&Itemid=54 Unofficial DOCS pdf], [dwc_otg.c FreeBSD], [], [https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/Controllers/DWCDriver/ RiscOS USB Driver], [https://www.riscosopen.org/forum/forums/5/topics/878 RiscOS USB Discussion], [https://www.riscosopen.org/forum/forums/11/topics/1893 Other USB RiscOS], [http://plan9.bell-labs.com/plan9/index.html Plan9 Miller's usb] http://plan9.bell-labs.com/sources/contrib/miller/, [https://github.com/Chadderz121/csud CSUD driver],
*[http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf SMSC 9512] USB LAN/Hub chip
*CMOS RAM
*VCHIQ port which sends messages to the GPU e.g. for mouse, keyboard, audio on HDMI, etc
*Audio Driver
*Serial Peripheral Interface Bus (SPI)
*[http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/ I2C registers]
*I2S
*Universal Asynchronous Receiver Transmitter (UART)
*[http://elinux.org/RPi_BCM2835_GPIOs GPIOs] and [http://www.adafruit.com/blog/2012/08/17/broadcom-bcm2835-peripheral-memory-map-and-gpio-alternate-use-chart-piday-raspberrypi-raspberry_pi/ Alternative view of GPIO]
BCM2836
* For Pi B+, PI 2 and Pi 3 SMSC LAN9514 chip adding 10/100 Ethernet connectivity and four USB channels to the board
The overclock ability has diminished with each chip version as the energy usage has very slowly risen. BCM2837 is one of the warmest yet and might benefit from active cooling (ie fan) if all four cpu cores are in use for a short while. Video playback is not affected due to the custom support in the GPU. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur.
*[http://www.andrewscheller.co.uk/rpi_pcb_modules.html PCB], [http://elinux.org/RPi_Low-level_peripherals Low level features],
Implemented so far...
# Modify the configure system so that it correctly builds for the arm hardware float raspi target.
# Implemented the bootstrap to load the aros modules and prepare the arm to jump into them. Reworked the x86 console support so that parts can be stolen for raspi to use since t has no basic functionality to output to the display.
# Implemented a kernel.resource to prepare the raspi for running aros and provide the low level api calls to expose available resources and allow exec, etc function.
# Implemented serial debug support
# Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc)
# Implemented a timer.device to utilise the hardware timers.
# Implemented a very basic gfx driver to expose the hardware's framebuffer.
# Implemented an SD-Card driver for AROS which presently only supports the raspi's chipset but can easily be modified to support all sd-card hardware and media.
# Fixed the fat filesystem support in AROS so that it can boot on RasPi's normal SD-Card setup. The "rom" image files needed use a different filename than the default linux, etc images so can be easily installed without harming the existing files - you only need to change the loaded images in the config file to get aros to boot.
# Updated the build scripts to automatically download the necessary raspi firmware files and wrap it all up so that you can simply extract the archive to a fat formatted sdcard and boot it on the raspi without having to get anything else.
# fix everything in contrib and ports to build for raspi (needs proper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi ..
Improvements...
# Implement a USB chipset driver "OR" finish the existing one [https://github.com/aros-development-team/AROS/commit/c07d13c724f944674be5db54fc6a71ee72a01809 usb otg] - the current code is mostly a skeleton that should initialise the chipset and then needs relevant code to support the different transfer types. It also has the "virtual" hub code in place to represent the raspi's USB port (from poseidons p.o.v)
# Implement a driver for the USB NIC (a few weeks - depends on USB above)
# Write an [https://github.com/aros-development-team/AROS/commit/d55d0f74d20b769bbb8c8d386e5c1d7a9154f05a audio driver] (a few weeks - independent of USB) and [https://github.com/aros-development-team/AROS/commit/e93a4c245f27a87c9c4c1d39206694b39059998a HDMI]
# fix syscall bug in the current raspi kernel code
# Graphics depend on having a decent "bcmdma.resource" implemented as to use the cpu's dma engine. The sd card driver needs to use it for transfers to/from the controller - and the gfx system needs to use it for "blitting".
# [https://github.com/aros-development-team/AROS/commit/4019d84e4975d4dad987a12d57fe108f5ac048e6 Improve the gfx driver], [ vc4gfx HIDD] add [http://dri.freedesktop.org/wiki/VC4/ Gallium3D support]
# [https://github.com/aros-development-team/AROS/commit/b13905b3e8e45b089f520b44692c81affddd066f Improve] the [https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9 sdcard] device driver - which is also pretty basic but should work with most cards, rework it to also support pci, etc. sd card interfaces on x86
# The current code using very rudimentary access to the gpio interface - so that should be implemented as some resource for other components to access, as-well as the i2c interface exposed over the gpio interface. that should have a hidd class implemented which uses the gpio resource to communicate.
Boot up
On power-up, the rpi [http://www.open.com.au/mikem/bcm2835/ BCM 2835] [https://github.com/hermanhermitage/videocoreiv VideoCore4] GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the BCM2835's VideoCoreIV GPU PROM requires a DOS-style partition table; a FAT-formatted first partition; and the freely redistributable but closed sourced Broadcom files “bootcode.bin” and “start.elf” in that partition.
The boot sequence carries out several pre-boot tasks
*On powering of the rpi, the GPU reads and executes bootcode.bin, which then loads start.elf
*The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it
*configures the memory split for the CPU and GPU
*reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings)
*loads the “kernel.img” file, again from the same partition
*activates the CPU to begin executing the loaded kernel image
The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU.
RPi uses [https://github.com/raspberrypi/firmware some closed source loaders] and at some point it loads a binary blob named "kernel.img" at 0x8000, at that point there would be a rudimentary Aros alive. If one wants to use the SD-card then there would have to be a driver for the interface and a fat filesystem handler (SD-card has to be formatted to fat filesystem)
Boot code and kernel are now linked together and made into that binary blob, just for starters. Raspberry Pi uses [http://kernelnomicon.org/?p=133 u-boot] and [http://kernelnomicon.org/?p=138 UBoot] as bootloader, there's already some code in the Efika MX port for that. UBoot is a native bootloader and not just for the raspberry pi, it loads after start.elf.
You can find Efika MX port from arch implementations, some hacking is needed for the mmakefile.src'es as iit dates back to before the Aros crosstool era or else you get some weird errors while building. You also need to code the bootstrap and serial handling.
At the moment it seems that a fastest route for the native build would be to make one binary blob without using the package system. Raspberry's memory layout is pretty simple and if the implemented u-boot doesn't support loading other modules
<pre>
? - alias for 'help'
mtest - simple RAM test
autoscr - run script from memory
base - print or set address offset
bbm - BBM sub-system
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
jade -
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv - print environment variables
rarpboot - boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saves - save S-Record file over serial line
setenv - set environment variables
sleep - delay execution for some time
tftpboot - boot image via network using TFTP protocol
USB - USB sub-system
usbboot - boot from USB device
version - print monitor version
</pre>
Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,
Framebuffer - basic display
RasPi has to speak to the "operating system" which runs on the GPU itself and request/free memory - it cant directly manage it itself, and so the managed functions were used to wrap these calls.
The Arm and GPU share memory space. The framebuffer is shared. The Arm can write a pixel and it will appear on the screen (through GPU hardware) without flushing/copying being required.
The GPU can composite multiple FB's in real time - so you have a number of surfaces defined which are rotated etc and composited in real time to the output. Copying can map from the address space of the Arm to the flat space of the GPU which takes some code, but I don't think whole buffers are copied.
The DMA hardware can also access the whole memory space and can perform 2D fills and blits (no blending). This is documented in the peripheral spec posted. The DMA is just an Arm accessible peripheral and can be set up with low latency (e.g. microseconds).
must use a 0xc0000000-based bus address to access SDRAM, yet non-DMA access should go via a 0x0-based bus address.
For 2D dma, set TDMODE, and the spec says "interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer." so set STRIDE to pitch of the image, the width is XLENGTH and height is YLENGTH. You would fill by not setting the SRC_INC and point source to your fill data.
The DMA cannot see the ARM's L1 cache, so you would map the framebuffer with ioremap_nocache. Depending on where the source data comes from, it may need an L1 cache flush. The DMA can see the L2 cache. Use 0xC0000000 bus addresses when L2 is disabled and 0x40000000 bus addresses when L2 is enabled. (actually just call virt_to_bus and you'll get the right address out).
openGLES/openVG has high latency. Writing to framebuffer then reading it back is very inefficient (e.g. milliseconds). If you can drive it a unidirectional way, just streaming commands at then that is efficient. openVG is not implemented on top of openGLES - it uses the same hardware but as a first class interface
To improve the Gfx driver, we will need a DMA resource implemented so can use to perform DMA operations. The Gfx driver will need this to perform blits.
USB
* Model A and B limited to 150 mA per port.
* Model B+ and Pi 2 introduced configurable 600 mA to 1.2 A support over all ports - anything above that requires a powered USB hub.
Implementing the hardware driver that Poseidon uses to interact with the USB components.
Have code in place to (try) and initialise the USB chipset, and configure host/device mode operation (though AFAICT Poseidon doesn't support device mode). Started to get the "virtual" root hub written for the single USB port so that Poseidon should at least list it correctly in the GUI - and try to interact with it to find peripherals.
The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”).
There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA. However, there's a Linux driver written by Synopsys ([https://github.com/raspberrypi/linux dwc_usb]). Specifically directories [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_common_port] and [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_otg].
The Synopsys code is actually under a fairly permissive licence – it's not GPL, it's similar to BSD (’don't sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code.
The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port).
Probably only need provision of relevant changes to dwc_common_port. Other things to consider....
* Provision of necessary headers to get it to compile
* Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes (multithreading) )
* Interfacing between USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start.
the Linux bits of the headers are only required for the dwc_common_port library. dwc_common_port includes a variety of crypto functions which are not used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn't going to be for plain wired USB.
Every USB driver acts as an USB hub as well in order to let Poseidon control the state of USB ports. The code there was reading status of the only USB port in Raspberry's CPU but when changing the status it erroneously deleted some of the status bits, including the port enable one. It was so because those bits in the status register are of a type Read/WriteToClear. It means, if one does not want to change their value from 1 back to 0, one has to actually write the 0 value. Very practical thing e.g. in interrupt handlers, where one reads the interrupt status register to learn what was the interrupt reason, and writes it back to the same register in order to clear the interrupts.
After fixing that code it turned out that the communication was still unsuccessful. Apparently the USB device was not understanding the host for some reason. That should not happen since the request sent was one of the standard ones implemented by virtually anything with an USB connector, assumed that Poseidon clears the data caches before forwarding the work to the USB drivers but that's the responsibility of the driver itself.
The USB device responded and acknowledged the transmission! But why were all the request sent after address change failing with timeout? They should not. Once again, address set is supported just by anything. Tried to contact the device at address 0 once again and there it was, still responding properly. The enlightenment came. The bus address for DMA transmissions was, as it is in many bare metal USB implementations, just the pure memory address of the buffer as seen by the ARM cpu. Have "prefixed" it with the real location of uncached RAM and booted AROS once again.
Trident saw this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
and this:
Product : Vendor: Vdr=0424/PID=EC00
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 255
SubClass : 0
DevProto : 1
VendorID : 1060
ProductID : 60416
DevVers : 0200
and even this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
What are these things? The first one is USB hub built in the Raspberry. Thanks to this one the Pi machines (with exception of Pi0 and computing modules) have more than just one single USB port. The second one is the network chip in raspberry, the third one is my USB SD card reader which have just connected to see what happens. AROS tried, of course, to boot from it ;)
So, the first step towards working USB is done. The control transfers are working as you can see above. Next step is to implement bulk and interrupt transfers, having the basics in place. Finally some error handling will be added and USB for Pi will be as complete as the PC version.
[http://www.raspyfi.com/raspberry-pi-usb-audio-fix/ Issue with USB Audio]
Audio
[https://github.com/raspberrypi/linux/tree/rpi-patches/sound/arm audio] and its [https://github.com/raspberrypi/firmware/issues/2 very high speed message passing interface type of thing VCHI]
The Model B+ added an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality
the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures
Analogue audio
Audio over HDMI rev 1.3 & 1.4
Ethernet
10/100 BaseT Ethernet RJ45 socket
GPIO
GPIO shouldn't be too bad but bear in mind it is already accessed in places so they would need to allocate pins etc through it (e.g. sdcard to flicker the activity light, serial debug to output data on the GPIO pins)
Probably a resource rather than a device...
Started an i2c driver that will need to allocate GPIO pins. Feel free to work on it if you are interested ;p
GPU graphics with 2D and 3D acceleration
Sadly none yet for 32bit but for 64bit...
== References ==
===Hosted===
==== Linux ====
Change lxde to another
sudo leafpad /etc/x11/xinit/xinitrc
xorg.conf
<pre>
Section "Screen"
Identifier "Default Screen"
DefaultDepth 16
SubSection "Display"
# Viewport 0 0
Depth 16
Modes "800x600"
EndSubsection
EndSection
Section "Device"
Option "Backingstore"
Identifier "Card0"
EndSection
</pre>
Will raspberrypi ARM programs run on other ARM archs and vice-versa ? If not I would like to use different cpu names for
archs which are incompatible.
All code compiled for at most armv6 with softfp float abi will work on all softfp ARM targets, including raspberry.
Code compiled for hard-float ABI will not work on any softfp target. But then, hard-float abi uses -armhf- cpu name.
keyboard or mouse not functioning or partly working
lsmod
kernel and modules (stored in /lib/modules/ get from https://github.com/raspberrypi/firmware and click on ZIP button) have to be updated simultaneously
sudo Apt-Get Update
sudo Apt-Get Install <program >
<program > cksfv joystick p7zip-full stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 libreoffice epiphany-browser xbmc
ace-of-penguins gweled black-box petris xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis xbubble eboard&xboard (freezes) bomberclone
OMXPlayer not responding or working with keyboard or no sound audio through HDMI
LXterminal—command "OMXPlayer -o hdmi %f "
hdmi issues
Setting the hdmi_force_hotplug=1 makes sure the Pi believes the monitor/TV is really there.
You might also need to set config_hdmi_boost=4 or even higher (up to 9) if your display needs a stronger signal.
If the display is a computer monitor or newer tv, use hdmi_group=1 (auto HDMI use) and if it is an older TV, try hdmi_group=2 (for DMT formats, i.e. for PC monitors) then you HAVE to "set hdmi_drive = 2 to enable HDMI output as this forces HDMI mode rather than DVI mode
Do not set hdmi_safe=1 as that overrides many of the previous options.
Using a shorter or better quality HDMI cable might help. Make sure your Pi's power supply delivers 1 A and not 500 mA.
If you see a problem with the red colour - either absent, or interference - then try a boost
composite video
changing the RCA cable, then the composite port worked out of the box
Boot it as you are doing, without HDMI. If you now plug in the HDMI, do you get the image? In other words, does the Pi think HDMI is connected even when it isn't?
Rename all the files in the first partion of the card except bootcode.bin, start.elf and fixup.dat What's the result?
Put back config.txt What's the result?
for PAL mode sdtv_mode=2
dmi_ignore_hotplug Pretends HDMI hotplug signal is not asserted so it appears a HDMI display is not attached
hdmi_ignore_hotplug=1 Use composite mode even if HDMI monitor is detected
<pre>
# NOOBS Auto-generated Settings:
#hdmi_force_hotplug=1
#config_hdmi_boost=4
#overscan_left=24
#overscan_right=24
#overscan_top=16
#overscan_bottom=16
#disable_overscan=0
start_x=1
gpu_mem=128
</pre>
tvservice -c "PAL 4:3"
<pre>
/opt/vc/bin/tvservice -s or tvservice -s
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
(native) mode 16: 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m DMT
Group DMT has 0 modes:
</pre>
sudo amixer cset numid=3 1
forces the audio to the headphone jack, even with the HDMI video output plugged in
config.txt
the hdmi_ignore_edid_audio=1 option sems relevant as it should tell ALSA that the only available audio is analog, no matter what the display says
There are several different ways that these 4 pole (ring) composite analog cables can be wired up, so some work great in some applications and can be a waste of time in others.
What is needed for the Raspberry Pi B+ and above, which like many camcorders needs the ring contact next to the base contact to be the ground.
The wiring for the 4 pole are:
TIP (LEFT AUDIO CHANNEL)
RING 1 (RIGHT AUDIO CHANNEL)
RING 2 (GROUND/EARTH)
RING 3 BASE/SLEEVE (VIDEO) YELLOW
Most Apple based Players and the Microsoft Zune (TM) are wired this way.
Most analogue camcorders are wired this way as well, where the ground in on Ring 2 will work with the Pi although you may need to swap your Video plug with the Right Audio plug.
Nearly all other MP3 players are not wired this way, the ground is on another ring ie the wrong one.
External devices
* Camera Module Omnivision ov5647 Sunny 5MP (NoIR version) V1.3 - NoIR at 850 nm, peak at 880 nm and trails off at 940 nm wavelengths
* Camera V2 Sony IMX219 V2.1 8mpixel 8MP 8megapixel - 3280 x 2464 pixels - video at 1080p30, 720p60 and 640x480p90 - wider field of view, 62 vs 54 degrees horizontally -
* Branded WIFI usb BCM43143 dongle
N.B. dreaded error after changing cameras (stupidly without turning off the power first) and lasted through several power cycles. It can be a bad 15-pin FFC ribbon cable, when swapped, camera(s) and the Pi itself are working OK. It can be an instance of a cold solder joint on the CSI connector on the pi board. the camera can be detected (that's done via I2C) but may still not be able to receive image data (done via CSI-2) if something is broken. CSI-2 is uni-directional. Control is generally done via I2C.
The CSI-2 receiver always writes to memory, not direct to the ISP. That's the way the Broadcom architecture works as it allows multipass processing easily. GPU memory is accessible from the ARM. Processing using the QPU graphics processors may be possible. currently the only supported sensor is OV5647 and IMX219. The linux drivers are all in the firmware blob, else you'd be looking at at least a man-month of work in a fully fledged imaging lab to do a decent tuning of the camera modules' ISP parameters.
Static electricity maybe an issue for the camera module and slightly less for the pi board.
* Hosted under ARM Linux which needs to be already installed [http://www.aros.org/nightly1.php current ABIv1]
Help building AROS hosted on Linux ARM
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:
<pre>
Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic':
configure: error: C compiler cannot create executables
See config.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2
</pre>
looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.
now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)
P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.
Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.
My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.
Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.
For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.
Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.
Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh
I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:
#MM- linklibs-armhd : libklibs-aeabi-arm
Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.
I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...). Smile
To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.
With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.
l1pvoodimcqsqylj77yp64h4fznyn2s
4655989
4655988
2026-08-01T11:52:18Z
Jeff1138
301139
4655989
wikitext
text/x-wiki
{{ArosNav}}
[[#Native]]
[[#Hosted]]
==Introduction==
The Raspberry Pi Foundation is a charity founded in May 2009 to promote the study of basic computer science in schools, and is responsible for developing a single-board computer called the Raspberry Pi.
The Foundation is supported by the University of Cambridge Computer Laboratory and Broadcom. Its aim is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing."
The original Raspberry Pi 1 Model B computer went on sale in February 2012 and set a new standard shattering the dominance of the PC in the home and education markets. Millions in the various formats, A, B, A+, B+ and Compute have since been shipped worldwide. The original concept of the Raspberry Pi was for a computer board providing Internet access with up to 1080p HD graphics at very low cost. The boards provide a platform for children and adults from any background to acquire computer science knowledge and help develop the future World-Wide-Web and all things internet (IOT hub and bridges out to home network to cloud of sensors).
Hobbyists and tech dabblers/tinkerers are the main purchases of the Pis (around half).
The rest of the sales are split between education/industrial. While the Raspberry Pi boards were designed primarily for education, they have become very popular with manufacturers of embedded systems. The Raspberry Pi Foundation has ensured backwards compatibility with each new revision. The bare-bones Compute module is aimed specifically at the OEM manufacturer.
* Pi 5 - Quad A76 and RP1 "southbridge" with VideoCore 7 4Gb 8Gb LPDDR4X
* Pi 4 - Quad A72 64bit VideoCore 6
* Pi 3 - Quad A53 [https://www.raspberrypi.com/documentation/computers/processors.html 64 bit] - VideoCore 4
* Pi 2 - Quad 32bit but more power consumed
* Model B+ - lower power usage but same speed as the original Pis
* Model A and B -
* Compute 1, 3, 4 and 5 - industrial use
<pre>
2008 Trustees collected for Foundation
2009 Charity status gained
2010
2011 First Raspberry prototypes
2012 First boards go on sale at CPC and RS. The Model A and B 700 MHz Arm11 - February 29th BCM 2835
2012 First million sold - more than the 10,000 original planned and anticipated
2013 First Alpha Experimental builds of AROS Native for the Pi
2013 Pi Trading launched making grants available, providing in house educational resources and Pi Academy for teacher training
2013 Over two million sold
2014 Over three million sold and updated Model B+ introduced that moved composite video to audio jack and same half gig of memory
2014 Pi Model A+ v1.1 - BCM2711 no ethernet and 1 usb - a little smaller -
2015 Pi 2 Model B - BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit core and 32bit VideoCore IV 3d GPU with 1Gb RAM
2015 Over four million first gen pis sold
2015 Over a million pi2s sold
2015 Pi Zero BCM2835 released
2015 Raspberry Pi 2 Model B version 1.2 has armv8 BCM2837
2016 Passed Sinclair total number of computer lines sold - around 7 million
2016 Pi 3 Model B - Broadcom BCM2837 SOC four 64bit ARMv8 Cortex-A53 1.2GHz - 1Gb - bluetooth 4.1, Cypress CYW43438 wireless 802.11n and a dual 32bit VideoCore IV GPU - 4 x USB2.0 ports
2016 Total PIs over 10 million worldwide
2016 Compute 3 launched BCM2837 armv8 Quad 64-bit Core 1Gb LPDDR2 RAM 4Gb Emmc storage
2017 12 million pis sold in total
2017 Pi Zero W 1GHz, single-core CPU A53 released with Cypress CYW43438 wireless
2018 Pi 3 Model B+ - 4c A53 BCM2837B0 - 1Gb, wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet - 4 x USB2.0 ports
2019 Over 15 million sold
2019 Pi 3 Model A with BCM2837b0 with 512Mb,
2019 Raspberry Pi Compute Module 3+ CM3+ LITE Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC 1Gb DDR2 and emmc
2019 Pi 4 Model B - BCM2711 quad 64bit A72 1.5GHz, VideoCore VI, AC wifi, Bluetooth 5.0, GbE, 2 micro hdmi decode up to 4K, USB-C power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram
2019 Pi 4 Model 2B - BCM2712 4 usb
2020 Raspberry Pi SC0919 Pico RP2040
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard
2020 Raspberry Pi Compute Module 4
2021 Pi zero 2 w 64bit quad 1GHz Cortex-A53 BCM2710A1 512mB SDRam
2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - no audio socket - dual 4k displays from mini hdmi - fan connector - 5V 5A psu
2024 Raspberry Pi Pico 2
2024 Pi 5 2GB version uses BCM2712D0
2024 Pi-500
2024 Raspberry Pi Compute Module 5
2025 Pi-500+
2026 April and May Aros 64bit fixed, added AHI audio, VC4 gfx started, usb functions added to rom
2026 June and July Aros 64bit usb2otg started, dma.resource, sdio.resource, bwfm.device wifi added
2026 Late July daily 64bit Pi3 builds start
2026 August ....
2027
2028 Pi 6
</pre>
===Good sites to visit===
*[https://github.com/raspberrypi/firmware/tree/master/ Raspberry Pi Firmware build]
*[https://github.com/raspberrypi/linux Raspberry Pi Linux Build]
*[https://www.patreon.com/michal_schulz/posts Big endian on Pi] with [https://github.com/michalsc/Emu68 ARM based realtime JIT 68k]
*[https://www.riscosopen.org/wiki/documentation/show/Welcome%20to%20RISC%20OS%20Pi RiscOS on Pi3 and Pi4]
*[https://github.com/brianwiddas/pi-baremetal Bare Metal Access on Pi 32bit]
===Native===
* 2013-03 Kalamatee starts work
* 2013-05 Work put on hiatus
* 2015-04 Work continues slowly with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb
* 2018 [https://www.patreon.com/posts/i-owe-you-some-20956961 mschulz resume with adding BE big endian support as well]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=bsek latest commits for pi 3 64bit]
* 2026 [https://github.com/aros-development-team/AROS/commits?author=jonx latest commits for pi 4]
64bit ArmV8 builds are
The status of AROS 32bit native for RasPi was OK. System booting, USB working (although with some issues but plan to fix them). Got stuck on modifying the ABI (application binary interface) and adjusting binutils/gcc to support it wanted to have real executable files but got stuck a little. This change for the type of relocations embedded in ARM files and not sure if this very type is well supported, on the other hand without this change ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.
Old native [http://www.aros.org/nightly1.html ARMv6 32bit nightlys] and
===Hosted===
[http://www.aros.org/snapshots1.html old linux and android hosted 32bit]
==Build==
===64bit===
===32bit===
# download/checkout the source someplace, e.g. /build/AROS-Src/
# make a directory to store external sources AROS downloads, e.g. /build/Ports
# make a build directory, e.g. /build/aros-raspi-armhf
# cd into the build dir, configure, and then run make -:
<pre>
>cd /build/aros-raspi-armhf
>/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
>make
>make arosboot-raspi
</pre>
then copy the files from /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ onto an sdcard, and download/copy the Raspi firmware files onto it.
You should then be able to boot the sdcard on your RasPi.
The current W.I.P tree to svn. it can be built as follows ..
<pre>
./configure --target=raspi-armhf
make arosboot-raspi
</pre>
That will generate arosraspi.img, arosraspi.rom and config.txt in bin/raspi-arm/AROS - so either copy just those files to a fat formatted SD card (with the firmware files on), or copy the whole contents of the AROS folder.
NB - if you have a Linux/other install, backup the existing config.txt first
arosraspi.img contains the bootstrap (which has very basic mailbox code, framebuffer/gpio init, and console "emulation" via code pinched from our libbootconsole), kernel.resource, and exec.library
arosraspi.rom contains all the other components needed to boot AROS.
The config.txt file will tell the RasPI bootstrap to load our arosraspi kernel and ramdisk (rom).
the bootstrap has minimal mailbox code, planning on adding either a resource or library that driver/app code will use to access it (likewise for GPIO)
==== Hosted ====
Ubuntu VM approach to compiling [http://lallafa.de/blog/2013/06/building-aros-hosted-for-raspbian/ Linux hosted AROS June 04, 2013]
../AROS/configure --target=linux-armhf --enable-includes=/usr/arm-linux-gnueabihf/include --x-includes=/usr/arm-linux-gnueabihf/include --x-libraries=/usr/arm-linux-gnueabihf/lib
arm-elf- is symbol-linked to arm-linux-gnueabi- (arm-linux-gnueabi- is more correct in this case, because it's going to be compiling the ARM AROSBootstrap for ARM Linux)
*armel - many of the "android" machines require since the entire OS is made for soft float VFP.
*armfp - Efika MX target, Raspberry PI, EfikaMX, Pandora and virtually everything (VFP)
Keep in mind it's possible to start hardfp AROS hosted on softfp system, though, as long as no calls between AROS and host require floating point parameters. NOTE: hardfloat objects *cannot* be linked with softfloat objects - they have a different ABI.
Just keep in mind the arm nightly build machine is quite complex beast. It needs the x86_64 host compiler to compile AROS tools. The arm version is built every night using gcc-4.6.2 crosscompiler (built together with AROS) and successfully builds armel and armhf linux hosted targets.
*needs an AROS code compiler for ARM target
*as well as unix compiler for ARM linux host (would be best to have both softfp and armhf, we have softfp only now) with full set of libraries and includes.
with—disable-crosstools $AROS_CC is always a wrapper around $KERNEL_CC ? If so, this is wrong for some ports. This can break Darwin, Windows and Android port.
Yes, Android port will build. And even work. But it's not good because the port will not be ABI-compatible with other ARM ports. Android's ABI is different from GNUEABI. For example:
<pre>
enum test {foo, bar};
enum test testvar;
</pre>
siseof(testvar) will be equal to sizeof(int) in GNUEABI (Linux and AROS) and sizeof(short) on Android. This affects linking objects from static linklibs, for example.
Previously everything worked because $AROS_CC was a wrapper on top of $HOST_CC. And a real crosscompiler was used on non-ELF hosts.
Android is the same. $KERNEL_CC is incompatible with AROS.
compiler=kernel is appropriate _ONLY FOR CODE WHICH RUNS ON HOST OS_ (or barebone hardware, if we talk about native). This includes bootstraps, their linklibs, and host-side dynamic libraries (Windows makes extensive use of them because of architectural considerations.
No single AROS object should be compiled with this setting. $KERNEL_CC is really compatible with AROS *ONLY IN LINUX-HOSTED* and no more. On other systems (Darwin, Windows, Android) this is not true any more, and compiler=kernel is never going to work.
If you want to compile your AROS module against host OS includes, append the following to USER_INCLUDES (or USER_CFLAGS, this is effectively the same):
-isystem $(GENINCDIR) $(KERNEL_INCLUDES)
$(KERNEL_INCLUDES) expands to:
-isystem <your_os_includes> -isystem <host_OS_gcc_private_includes>
-nostdinc
This makes AROS compiler adhering to host OS APIs.
If you want some preprocessor symbols based on what your host OS actually is, add something like -DHOST_OS_$(AROS_HOST_ARCH).
Why is there $(GENINCDIR) at all? Because host OS has its own libc includes, which would conflict with AROS ones. And the host OS libc is not binary-compatible with AROS one.
Why doesn't Windows-hosted port use $(KERNEL_INCLUDES) ? Because WinAPI includes conflict with AROS ones in fundamental typedefs, like WORD, BYTE and BOOL. It's almost impossible to deal with this in any other way than rewriting WinAPI definitions using AROS types.
Building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. haven't yet committed the necessary changes but "./configure --target=raspi-armhf" is enough to start, then "make arosboot-raspi" will generate arosraspi.img (containing the bootstrap, kernel.resource, and exec.library) as well as arosraspi.rom (containing all the other essentials components such as dos, graphics etc). It will also copy over a config.txt file to make the raspi bootstrap code load the correct kernel, and a cmdline.txt that enables exec debug output.
*armel = typically Debian 6, Ubuntu Maverick, Android,
*armhf = typically Debian 7, Debian 8, Ubuntu Precise,
Cross-compiling Ubuntu ARM softfp
<pre>
sudo sh
echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel
</pre>
<pre>
./configure --target=linux-arm --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabi/include
</pre>
Cross-compiling Ubuntu ARM hard-float
<pre>
sudo sh
echo 'foreign-architecture armhf' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armhf.list
apt-get update
apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf
</pre>
<pre>
./configure --target=linux-armhf --x-includes=/usr/include \
--enable-includes=/usr/arm-linux-gnueabihf/include
</pre>
Now, the AROS build is configured properly and all you need to do is:
make
[https://github.com/aros-development-team/AROS/commit/d84b9a337f9aa059154d9af69275935125166bdd some Apple Silicon support]
== Hardware ==
===64bit===
====BCM2712====
BCM2837
* Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support, 3B+ [https://github.com/aros-development-team/AROS/commit/afa5bc0bb17d5dd06bcfdbac00853a3799ca8d76 LAN7515]
====BCM2711====
===32bit===
=== Core Kernel ===
the reason behind INTB_KERNEL is to allow use of the standard Exec function AddIntServer() to add interrupt handlers for
hardware drivers etc. AmigaOS never used it for abstract hardware drivers. AmigaOS routed only raw hardware IRQs there. Their assignment was hardcoded. As well as number of them. Actually on AmigaOS every bus has its own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt. 1:1 relationship between CPU and hardware interrupts is present only on PC.
IMHO we miss things like AddInterrupt/RemInterrupt methods on our PCI subsystem's device class. PCI bus class should map these methods to whatever is appropriate. This is how it is done on AmigaOS and friends. When these are implemented, raw kernel.resource API will be needed only for several PC-specific drivers with hardwired resources. Exec IRQs are real IRQs only on Amiga hardware. On other machines they can be emulated where appropriate (VBlank is a good example). kernel.resource is meant to be different, its IRQs are hardware-agnostic, they are plain "Hardware IRQ number X, whatever this means". They are low-level actually, and meaningful only in the context of a particular system.
Was that not the transition from irq.hidd to kernel.resource? No. A long time ago there was another hacky bit named INTB_TIMERTICK. It was "abstract timer interrupt", used by timer.device. It was the same as VBlank, but with larger frequency. I removed it, because kernel.resource API was a cleaner way to access this interrupt. Furthermore, there can be more than one timer in the system. I am even thinking about bringing back timer HIDD definitions again. hpet.resource is a bad idea.
Can someone please enlighten me a little on how the scheduler is meant to work?
Poseidon.library creates its "Poseidon Event Task" during RTF_COLDSTART -> then calls Wait(), and ends up in limbo because wait disables interrupts (used for the scheduler heartbeat), and basically waits forever because the sigbit is never set, since krnSwitch doesn't switch the task unless TF_SWITCH is set, and no codepath run during this seems to set it?? TF_SWITCH does not disable/enable switching. This flag just enables to run user-supplied hook when the task is being switched away. It is completely safe to call Wait() in Disable()d state. Doing this actually temporarily breaks this state. IDNestCnt gets remembered in struct Task, then next task is selected, and its IDNestCnt is restored in sysbase (see kernel_scheduler.c). If there are no other tasks, then your cpu_Dispatch() should enable interrupts on the CPU and enter idle mode. See x86 implementation for good example.
You miss what happens next...
1. KrnSwitch() saves context of your task, saves IDNestCnt (core_Switch() and cpu_Switch()), then drops into cpu_Dispatch().
2. cpu_Dispatch() calls core_Dispatch. Then two cases are possible:
2a. There is a READY task. It is picked up, its IDNestCnt is restored in SysBase, then cpu_Dispatch() needs to restore registers and exit. The next task is run.
2b. There are no READY tasks. core_Dispatch() returns NULL. In this case your cpu_Dispatch() should enter idle loop. It should just enable interrupts on the CPU and put it on halt. This allows it to process hardware interrupts. Eventually some of your interrupt handlers wakes up your task and puts it into READY list.
My heartbeat interrupt has been slowed atm to help debugging - but it never actually gets a chance to fire because of the Wait() disabling interrupts. Perhaps you have forgotten to enable interrupts in your idle loop.
There is a change in the format of AROS executables. Until now we were using Elf RELocable files which are usually used as intermediate object files. We had them for various reasons, one of them was how AROS files were built in the past. That days we had no real aros cross compiler and the option to embed relocation data in unix executables (or in executable files in general) was rather new and not every linux/unix system had it. Therefore we have decided to use intermediate files. Although it was somehow working (and it is still working :-)), it has some drawbacks. Therefore decided to introduce real Elf EXEC types, in first turn implemented on ARM target with option to expand in future to all other AROS architectures.
The first patch was pretty easy and appeared to work somehow. It generated nice executables with embedded relocation info. Not only that, it also removed all global symbols adjusting relocation data to be relative to the beginning of the sections. That move reduced number of symbols in each executable significantly (depending on the file between 20 and 80% of all symbols could be removed). The only symbols that stayed in the file are local ones - due to the nature of the patch wasn't able to remove them since we have not seen them in the symbol hash table.
The patch didn't worked though. The files were relocated, AROS kernel loaded, but it crashed very early. What happened? Well, the nature of ARM relocations happened :)
Most of the relocation data on all machines is rather simple. Relocation can be absolute or pc-relative, sometimes the offset has to be bit shifted. On ARM v7 there is another one. There, when one wants to load an address of function/variable into register a combination of two instructions can be used: movw and movt. The first one loads immediate into lower 16 bits of a register while clearing upper 16 bits. The second one loads immediate into upper 16 bits without touching lower halfword. Loading of a pointer into a register looks like this:
movw r0, #:lower16:label
movt r0, #:upper16:label
In this case there are two relocations - one for lower halfword and another for upper. If an overflow of lower 16 bits occurs during relocation process, the upper one should be updated as well. Unfortunately with current patch and with typical ARM executables there is not enough information to perform the calculations.
There are two options - the first one would be to give up and go back to "fake" executables, another one would be to change from REL to RELA relocation info. The latter contains an addend, extra data which can be used to perform all the relocation calculations I need.
Decided for the second option. The patch is already in the works. There is another function for the binutils' bfd backend to perform the final relocation. There can decide what to do with every reloc info, modify data and eventually strip some symbols. An advantage is - at this stage of the linking process have also full access to all local symbols so can change all relocations section relative and eventually strip all symbols from the files.
=== GPU ===
Most of start.elf runs on the GPU. Placing ALL the userland GPU code in the videocore.hidd isn't going to be a terribly big problem because the code they published is nothing more than a shim that sends data straight to the GPU to execute.
The good news about this is that we only need to write our HIDD using the OpenVG API. The shim is relatively small codewise and lives in the ARM memory (the actual OpenVG code itself lives in the GPU RAM area and its loaded from start.elf). That's also the bad news. Our driver has to translate AROS video calls to OpenVG calls, for most tasks it should be easy, for some, not so much. It's still probably less difficult and less work, than controlling the GPU directly.
The other good news is that anything done through OpenVG happens on the GPU, its truly accelerated. It also has some nice font functions, meaning we can lead into an accelerated text mode later.
Basically, AROS resets or locks up when it tries to use AROS_ATOMIC_INC or DEC. If I comment out the byte/word operations in the header files and use non-atomic operations, the code works as expected.
have read that the L1 cache needs to be enabled to use LDREX and co (which I also read is only meant to be used on multi processor systems with shared memory) - however I am certain this is correctly enabled.
If you are using LREX or STREX, you should have L1 cache enabled, at least on the ARM CPU I work with at work.
L1 cache is enabled by enabling the MMU *AND* setting the C and I bits in the CPU - the C bit is ignored, and the I bit only covers the 16 byte instruction pipeline if the MMU is not enabled.
Can you verify that your assembly is generating LDREX/STREX? From the behavior, it almost sounds like its generating the default Semaphore locked atomics.
Impossible. There are no semaphore-locked atomics. There are Disable()/Enable()-based ones instead. And there's a special #define AROS_NO_ATOMIC_OPERATIONS in this case, which tweaks Disable()/Enable() implementations not to recurse forever.
I have tested this on ARMv5 which does not have ldrex/strex, it works fine. On those ARMs there's no way to have real atomics. On other OSes (like Linux) this is done by introducing things like atomic_t, which appears to be a complex structure, holding the value together with accompanying spinlock (implemented using swp).
#warning "TODO: lookup optimal mmu table settings for raspi memory"
/* Set up an identity-mapping for all 4GB */
for(x = 0; x < 4096; x ++)
{
pagetable[x] = x<<20 | (0x40002|0x80000|0x010000|0x00C00|0x04);
}
Shouldn't there be a second loop that sets the 'C' bit in the descriptor for the RAM pages?
Currently, you have TEX=0, C=0, B=1 for all pages (Shared Device).
You should have TEX=0, C=1, B=0 for RAM (Write-Through, Cached)
So ..
pagetable[x] = x<<20 | 2;
should be enough?
No, for RAM you need to change the '| 0x40' to '| 0x80'
tell dosboot the correct defaults to use
Please don't do this. This bootconfig.c is a deprecated legacy thing. I wanted it to go away completely with time. Instead, display drivers should auto-install themselves during own initialization phase. I. e. detect hardware=>instantiate itself. This should make things way simpler. With this approach you only need to add the driver into KS image to get the device autobooted. No
hardcoded stuff.
Currently VESA and VGA drivers do this, look there for examples. never rewrote ATI driver because i don't have any test system for it.
they defined a smaller AROSCPUContext than the ExceptionContext - yet reference it as ExceptionContext in other places, and since it hasn't allocated enough storage for ExceptionContext, are corrupting memory/the structure (since the elements that are there don't map 1 to 1 with the exception context).
AFAIK, AROS has been moving in a different direction to this in recent
years. It is the job of graphics HIDDs to allocate bitmaps etc. so that
they have the most suitable characteristics, including allocating them
from GPU RAM where possible. The concept of chip RAM is only for legacy
code, and most if not all non-68k platforms should have all system RAM
marked as chip.
BTW, is the video processing code you mention CPU code or GPU code?
Also, IIRC we have support for "external memory allocators". Perhaps that's what we need for the allocation of GPU RAM through the mailbox.
All hosted and x86 native ports should use proper context formats.
trying to clarify if the vblank handler has to have run by this point to prevent this deadlock. Actually, no. Unless you have installed VBlank handler which should wake up at some point. Without VBlank there will be no quantum count. Consequently, there will be no forced preemption. But the rest will work, and multitasking will be cooperative (switch happens only when current task voluntarily gives up the CPU). Does it depend on the vblank having run before this point? and if yes what does that mean on systems where it might be able to run enough code (e.g. get to this point) before the vblank interrupt has triggered? What is it waiting for? It could wait for timer, in this case you need timer.device working. VBlank is currently needed for exec's quantum counter. In current native ports we have only a single timer, which is served by timer.device. VBlank is simulated by timer.device also. If your machine has two timers, then you can use one of them for VBlank, and another for timer.device, this will simplify things down. VBlank needs to be 50 Hz for historical reasons, many programs use it as cheap timer. I am periodically thinking about making some abstract mechanism to be able to change quantum source (and untie it from 50 Hz), but have no time to come up with something good. Additionally i started disliking timer.device hardcoded design when PC has got many timers (old 8253, APIC, HPET).
Currently i think there should be some low-level entity representing tick source. timer.device should just select the most appropriate source for its units.
The BCM2835 has 4 GPU based timer sources - 2 are used by the GPU, so im using Timer3 for our heartbeat and the remaining one will be free to the system. There is also the less capable ARM timer but that is dependent on the CPU frequency. Very good. You won't need any emulation. Set the heartbeat to 50 Hz and drive VBlank from it. Use other timer for MicroHZ.
Can you use the 'econsole.hook' I make for debugging the Sam460 via the serial port?
It provides a before-anything-else shell prompt on the serial port. You can then do 'NewCLI' to test your graphics, or use any DOS command in shellcommands.resource.
You should just be able to add econsole.hook to your module list, and use 'econsole' in your bootargs.
So long as you have a working Exec/RawMayGetChar and Exec/RawPutChar, it should work.
Also make sure to add shell.resource and shellcommands.resource for this.
That should have done it.
If you set "#define DEBUG 1" in arch/all-native/econsole/econsole.c, do you get any additional serial output?
have added it to the build and added econsole to the command line - and can see the bootloader picks up on the emergency bootconsole tag, but I still only get the insert bootable media display?
Im assuming it exposes a fake filesystem that tricks aros into booting?
The contents of which are: ECON:AROS.boot
Way to handle the scheduling code? The implementations I had been following were causing problems, due to cascading interrupts which I cant handle properly in the asm stubs just now (when they break disable etc.) - since it means detecting the interrupted codes cpu mode and getting the correct sp/lr for it, and that's just too tedious for arm.
To work around this ive added a system idle task which does nothing - and when the scheduling code has no task to run switches this in and lets it run, thereby allowing the interrupts etc to resume until something does need to happen.
Also, by adding accounting code to cpu_Switch() and cpu_Dispatch(), it should allow the system to log idle time correctly (as well as running tasks).
have thought of also adding an additional task that never runs, solely to record time spent in IRQ handlers, but I digress..
was under the impression that kernel.resource should *never* be used outside of exec.library. This is a wrong impression.
Michal started designing it because portable nature of AROS does not fit well into exec's API with all its assumptions. So, he started the new, hardware-agnostic kernel API from scratch. Yes, exec sits on top of it in places. But kernel always meant to be open thing. Otherwise it would not exist.
it wasn't meant to be just used willy nilly by user code - but by lower system components (e.g. exec) so that they could be implemented in a more generic fashion, and the kernel resource itself hide the systems quirks.
Adding new things there perfectly keeps up with our decision to minimize AROS-specific intervention into APIs which can clash with MorphOS/OS4 extensions. We want at least source-level compatibility there. Binary compatibility on PPC would be extremely cool, but at the other hand we have no maintainer for this, as well as their ABIs are a bit weird and far from optimal, especially MorphOS one, because it aims for m68k binary compatibility.
It depends on what exactly is being implemented - there's no reason we should have everything crammed into kernel.resource if it doesn't need to be (i.e. if its better suited as a separate component/subsystem in its own right)
The _LE versions are for when you have endian swapping taking place. If the graphics are the same endian as the CPU, no swapping should occur. I ran into a similar terminology problem in SDL with a friend insisting that his Radeon 7000 on his PC was big-endian. It is not, it just uses the same endianness for the graphics card and the CPU so no swapping was necessary. They were both little-endian.
The _LE versions are because the PixFmts refer to the bitmap data being in big endian format in memory, for which the normal version would need to do endianness conversion before applying the shifts/masks. on this platform it is in _LE in memory also so we don't need the conversion hence using the _LE version of the call). would use _LE (if it's really little endian 16 bit mode).
What is the bare minimum needed to implement a framebuffer based gfx driver, with our software handling the rest?
I have tried with just a gfx class that only expose new/dispose/newbitmap - and having an onscreenbitmap used only for the framebuffer itself (with all other bitmaps being chunkybm, and the framebuffer's superclass also being chunkybm), but that alone isn't enough it seems?
You can use workbench/hidds/sm502/ as your example - it is as simple as I could make it.
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
I so far have -:
vc_init: queries the gpus memory, and sets up a fake memory handler for it, then adds the bootmode driver and returns saying all is well
vc_gfxhidd:New: sets up some fake syncmodes to test with and creates the real gfx object.
vc_gfxhidd:NewBitmap: checks if its a framebuffer and uses the onbitmap class or uses the chunkybm class otherwise
vc_onbitmap:New; creates a chunkybm object and then pushes the real framebuffer address into it as the buffer,
So, AROS creates the framebuffer bitmap (I have verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to.
The code I currently have on SVN seems to create the framebuffers bitmap object fine, but then crashes in intuitions DisplayDriver callback. In particular it crashes performing the getattr on the system default pointer.
don't expose MEMF_CHIP in an allocatable form so AllocSpriteData was failing (and other code later doesn't check if the values are valid == illegal memory accesses)
Actually MEMF_CHIP has to present, for historical reasons.
This has been never fully agreed upon, but in ports i wrote i exposed the whole memory as MEMF_CHIP. The idea behind this is that CHIP is originally the memory where graphics and sound data can be put. On non-Amiga platforms there are no restrictions on this, so the whole memory is CHIP.
Yes, many old software can misbehave with CHIP memory size larger than 2MB. But this actually applies only to m68k AROS which is going to run m68k binaries. In other cases it's quite logical to fix the program when porting.
As to original question: yes, it's enough to have a framebuffer bitmap (one with aoHidd_BitMap_FrameBuffer set to TRUE) and PutPixel routine. It framebuffer can be served by chunky bitmap class, then you can simply create chunky bitmap with your own buffer (see how VESA driver does this). Chunky PutPixel is already there.
struggling to determine what is the correct pixfmt to use for the 24/16/15 bit gfx modes on the RasPi. AFAIK it uses RGB565, for 16bit but im unsure what shifts etc should go with it? suffice to say Im getting the wrong colors so far lol.
<pre>
redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0
redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0
</pre>
It should likely be vHidd_StdPixFmt_RGB16_LE
This stuff is a bit confusing. The "names" of the stdpixfmts are based on the layout in memory,
ignoring endianess. So for example:
ARGB32: will be 0xAA 0xRR 0xGG 0xBB in memory on both big endian and little endian machines.
The shifts and masks OTOH are based on pixel access (ULONG in this case), so differ depending
on whether you run on big endian machine or little endian machine (that's why there's stdpixfmt_le.h and
stdpixfmt_be.h in rom/hidds/graphics/).
With the 16 bit pixel format it's even more confusing, as for example it's impossible on little endian machine
to describe RGB16 with shifts/masks alone. That's why there's vHidd_PixFmt_SwapPixelBytes_Flag.
(RGB16 == RRRRRGGG GGGBBBBB in memory, and for pixel (WORD) access on little endian machine it needs to
be accessed as GGGBBBBBRRRRRGGGG).
The shifts btw indicate how much to shift the component to the left (!) so that it is moved to the highest bit (31).
The aHidd_PixFmt_StdPixFmt you specify will be ignored most of the time, because when the pixelfmt is registered,
the gfx hidd checks if there's an identical pixfmt (shifts/masks/etc., but ignoring pixfmt->stdpixfmt) already in the system,
and if so, it uses the already existing one and does not create a new one.
In theory it would be better if gfx drivers could simply/only specify a StdPixFmt without all the shifts/masks stuff when the
gfx driver uses pixfmt which matches one of the stdpixfmts exactly. Another possibility would be for gfx drivers to use
HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) and then peek shifts/masks from it and fill out a pixfmt
tag list based on that.
15bit very blue/green: Try to pass same shifts/masks/etc. as in 16 bit pixfmt (maybe you think it's using 15 bit R5G5B5
(or swapped) but it's actually still using 16 bit R5G6B5 (or swapped).
aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count.
But I would still pass the correct one (_LE) == whatever rom/hidds/graphics/stdpixfmts_??.h uses
in the entry where you have looked up shifts/masks/etc.
Use the shifts/masks/etc. from the entry in stdpixfmt_le.h (if you are running on little endian machine) or stdpixfmt_be.h (if you
are running on little endian machine) that matches the pixfmt that its meant to be.
0xAA,0xRR,0xGG,0xBB on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32)
0xAA,0xRR,0xGG,0xBB on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32)
0xBB,0xGG,0xRR,0xAA on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_BGRA32)
it feels like AROS trashes the alpha component, otherwise it should be 8A8R8G8B.
read on the subject suggest its in 1x5r5g5b (x is ignored) to keep 16bit alignment .
What I see on screen suggests to me that wrong shift/mask are being applied - however going by the 16bit versions it all looks correct to me so I am really confused as to what is happening.
The output image looks to have too much green/blue, and very weak red.
Why did usbromstartup become HW-specific ?
In the past i have done a big job separating kickstart into several parts. I have never got any responses, so i re-describe my idea.
For now it loads the hs otg chipset driver ..
The idea is to minimize amount of archirecture-specific modules to
make user's life easier. So, the kickstart was split into 'base'
(which does not contain anything machine-specific) and 'BSP' (Board
Support Package) which contains all hardware-specific stuff.
This way, for example, distribution makers can save up space on CD
and make CDs with multiple platform support. Different configuration
would load the same base with different BSP's.
Next there was some part which is entirely missing on hosted. These
are filesystems. Hosted ports do not need them to boot up, so on
hosted they are left out. At the other hand, they are also
architecture-agnostic. So i put them into 'FS' package (standing for
'filesystem').
Poseidon is one more big part. I made it into separate package in
order to allow users to omit it if they don't need it (for example, to
run on retro PCs without USB). Personally i have one. Again, Poseidon
is hardware-agnostic (well, there are USB drivers but HCIs are pretty
standard).
It's mandatory on PI since there are no other interface types - so being a separate package is irrelevant/pointless.
Is Raspberry's USB controller non-HCI compliant? Actually i expect it to be compliant, then wouldn't it be better to make existing drivers discovering them?
AFAIK its HCI 1.0 compliant but I'm not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once i'm more familiar with the workings I can merge in the changes needed to get it operating but for now I will focus on getting it running. Also our drivers have known issues so perhaps a fresh set of eyes might shed some light on what is going wrong.
Another interesting question is whether Poseidon can operate on device side. Is it flexible enough? How similar is being a USB host and USB device? think it will need a bit of work on Poseidon's side. Until then I will force the driver into Host/Master mode in the init code, but leave open device etc to configure the chipset for either's use - and look at trying to add support for working in Device/Slave mode & switching modes once it's up and running.
Actually USBROMStartup is some kind of kludge. Can there be any alternative? Could device drivers be self-installing, like our HIDDs? This would get rid of need to list them in USBRomStartup.
And there is one more thing about modular ports. In order to actually implement this, your bootstrapping environment should provide the ability to load several files. On PC this is provided by GRUB2. on CHRP you can read filesystem via OpenFirmware, and Sam's Parthenope relies on modified u-boot. If your bootstrap allows to load only a single file, then you stuck with monolithic kickstart. By the way... u-boot allows not only to boot up a single uImage or zImage, it also allows to write client programs AFAIK. With this approach, you actually can write modular bootstrap for ARM AROS using unmodified u-boot.
[http://repo.or.cz/w/AROS.git/commit/e7bdc7e7b7f12b07aa24c739abb63721a872a53a arasan eMMC sdcard controller specific header which is not USB] and [http://repo.or.cz/w/AROS.git/commit/8bd19674084526a534ac11f7d4c51932e9ffe3d2 added prelim sdcard device]. [http://repo.or.cz/w/AROS.git/commit/9ab8217f61911fb8b7fd41bee46a992b4668ced1 do not set 4bit data mode, or enable acmd12/dma int's]
====BCM2708(family)====
which includes the [http://elinux.org/RPi_Hardware BCM2835] (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM)
*Framebuffer (fb) using mailbox
*IRQ scheduler, etc
*Arasan based SD Card controller
*Synopsis DesignWare USB 2.0 OTG controller [http://networkdirection.net/index.php?option=com_content&view=article&id=106:rasperry-pi-usb-controller&catid=45:raspberry-pi&Itemid=54 Unofficial DOCS pdf], [dwc_otg.c FreeBSD], [], [https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/Controllers/DWCDriver/ RiscOS USB Driver], [https://www.riscosopen.org/forum/forums/5/topics/878 RiscOS USB Discussion], [https://www.riscosopen.org/forum/forums/11/topics/1893 Other USB RiscOS], [http://plan9.bell-labs.com/plan9/index.html Plan9 Miller's usb] http://plan9.bell-labs.com/sources/contrib/miller/, [https://github.com/Chadderz121/csud CSUD driver],
*[http://www.smsc.com/media/Downloads_Public/Data_Sheets/9512.pdf SMSC 9512] USB LAN/Hub chip
*CMOS RAM
*VCHIQ port which sends messages to the GPU e.g. for mouse, keyboard, audio on HDMI, etc
*Audio Driver
*Serial Peripheral Interface Bus (SPI)
*[http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/ I2C registers]
*I2S
*Universal Asynchronous Receiver Transmitter (UART)
*[http://elinux.org/RPi_BCM2835_GPIOs GPIOs] and [http://www.adafruit.com/blog/2012/08/17/broadcom-bcm2835-peripheral-memory-map-and-gpio-alternate-use-chart-piday-raspberrypi-raspberry_pi/ Alternative view of GPIO]
BCM2836
* For Pi B+, PI 2 and Pi 3 SMSC LAN9514 chip adding 10/100 Ethernet connectivity and four USB channels to the board
The overclock ability has diminished with each chip version as the energy usage has very slowly risen. BCM2837 is one of the warmest yet and might benefit from active cooling (ie fan) if all four cpu cores are in use for a short while. Video playback is not affected due to the custom support in the GPU. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur.
*[http://www.andrewscheller.co.uk/rpi_pcb_modules.html PCB], [http://elinux.org/RPi_Low-level_peripherals Low level features],
Implemented so far...
# Modify the configure system so that it correctly builds for the arm hardware float raspi target.
# Implemented the bootstrap to load the aros modules and prepare the arm to jump into them. Reworked the x86 console support so that parts can be stolen for raspi to use since t has no basic functionality to output to the display.
# Implemented a kernel.resource to prepare the raspi for running aros and provide the low level api calls to expose available resources and allow exec, etc function.
# Implemented serial debug support
# Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc)
# Implemented a timer.device to utilise the hardware timers.
# Implemented a very basic gfx driver to expose the hardware's framebuffer.
# Implemented an SD-Card driver for AROS which presently only supports the raspi's chipset but can easily be modified to support all sd-card hardware and media.
# Fixed the fat filesystem support in AROS so that it can boot on RasPi's normal SD-Card setup. The "rom" image files needed use a different filename than the default linux, etc images so can be easily installed without harming the existing files - you only need to change the loaded images in the config file to get aros to boot.
# Updated the build scripts to automatically download the necessary raspi firmware files and wrap it all up so that you can simply extract the archive to a fat formatted sdcard and boot it on the raspi without having to get anything else.
# fix everything in contrib and ports to build for raspi (needs proper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi ..
Improvements...
# Implement a USB chipset driver "OR" finish the existing one [https://github.com/aros-development-team/AROS/commit/c07d13c724f944674be5db54fc6a71ee72a01809 usb otg] - the current code is mostly a skeleton that should initialise the chipset and then needs relevant code to support the different transfer types. It also has the "virtual" hub code in place to represent the raspi's USB port (from poseidons p.o.v)
# Implement a driver for the USB NIC (a few weeks - depends on USB above)
# Write an [https://github.com/aros-development-team/AROS/commit/d55d0f74d20b769bbb8c8d386e5c1d7a9154f05a audio driver] (a few weeks - independent of USB) and [https://github.com/aros-development-team/AROS/commit/e93a4c245f27a87c9c4c1d39206694b39059998a HDMI]
# fix syscall bug in the current raspi kernel code
# Graphics depend on having a decent "bcmdma.resource" implemented as to use the cpu's dma engine. The sd card driver needs to use it for transfers to/from the controller - and the gfx system needs to use it for "blitting".
# [https://github.com/aros-development-team/AROS/commit/4019d84e4975d4dad987a12d57fe108f5ac048e6 Improve the gfx driver], [ vc4gfx HIDD] add [http://dri.freedesktop.org/wiki/VC4/ Gallium3D support]
# [https://github.com/aros-development-team/AROS/commit/b13905b3e8e45b089f520b44692c81affddd066f Improve] the [https://github.com/aros-development-team/AROS/commit/3a876755c070f5c73c4f53c7f4d35b4f923088b9 sdcard] device driver - which is also pretty basic but should work with most cards, rework it to also support pci, etc. sd card interfaces on x86
# The current code using very rudimentary access to the gpio interface - so that should be implemented as some resource for other components to access, as-well as the i2c interface exposed over the gpio interface. that should have a hidd class implemented which uses the gpio resource to communicate.
Boot up
On power-up, the rpi [http://www.open.com.au/mikem/bcm2835/ BCM 2835] [https://github.com/hermanhermitage/videocoreiv VideoCore4] GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the BCM2835's VideoCoreIV GPU PROM requires a DOS-style partition table; a FAT-formatted first partition; and the freely redistributable but closed sourced Broadcom files “bootcode.bin” and “start.elf” in that partition.
The boot sequence carries out several pre-boot tasks
*On powering of the rpi, the GPU reads and executes bootcode.bin, which then loads start.elf
*The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it
*configures the memory split for the CPU and GPU
*reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings)
*loads the “kernel.img” file, again from the same partition
*activates the CPU to begin executing the loaded kernel image
The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU.
RPi uses [https://github.com/raspberrypi/firmware some closed source loaders] and at some point it loads a binary blob named "kernel.img" at 0x8000, at that point there would be a rudimentary Aros alive. If one wants to use the SD-card then there would have to be a driver for the interface and a fat filesystem handler (SD-card has to be formatted to fat filesystem)
Boot code and kernel are now linked together and made into that binary blob, just for starters. Raspberry Pi uses [http://kernelnomicon.org/?p=133 u-boot] and [http://kernelnomicon.org/?p=138 UBoot] as bootloader, there's already some code in the Efika MX port for that. UBoot is a native bootloader and not just for the raspberry pi, it loads after start.elf.
You can find Efika MX port from arch implementations, some hacking is needed for the mmakefile.src'es as iit dates back to before the Aros crosstool era or else you get some weird errors while building. You also need to code the bootstrap and serial handling.
At the moment it seems that a fastest route for the native build would be to make one binary blob without using the package system. Raspberry's memory layout is pretty simple and if the implemented u-boot doesn't support loading other modules
<pre>
? - alias for 'help'
mtest - simple RAM test
autoscr - run script from memory
base - print or set address offset
bbm - BBM sub-system
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
itest - return true/false on integer compare
jade -
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv - print environment variables
rarpboot - boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
saves - save S-Record file over serial line
setenv - set environment variables
sleep - delay execution for some time
tftpboot - boot image via network using TFTP protocol
USB - USB sub-system
usbboot - boot from USB device
version - print monitor version
</pre>
Most used [http://www.compulab.co.il/workspace/mediawiki/index.php5/U-Boot_quick_reference uboot options] are fatls usb 0:1,
Framebuffer - basic display
RasPi has to speak to the "operating system" which runs on the GPU itself and request/free memory - it cant directly manage it itself, and so the managed functions were used to wrap these calls.
The Arm and GPU share memory space. The framebuffer is shared. The Arm can write a pixel and it will appear on the screen (through GPU hardware) without flushing/copying being required.
The GPU can composite multiple FB's in real time - so you have a number of surfaces defined which are rotated etc and composited in real time to the output. Copying can map from the address space of the Arm to the flat space of the GPU which takes some code, but I don't think whole buffers are copied.
The DMA hardware can also access the whole memory space and can perform 2D fills and blits (no blending). This is documented in the peripheral spec posted. The DMA is just an Arm accessible peripheral and can be set up with low latency (e.g. microseconds).
must use a 0xc0000000-based bus address to access SDRAM, yet non-DMA access should go via a 0x0-based bus address.
For 2D dma, set TDMODE, and the spec says "interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer." so set STRIDE to pitch of the image, the width is XLENGTH and height is YLENGTH. You would fill by not setting the SRC_INC and point source to your fill data.
The DMA cannot see the ARM's L1 cache, so you would map the framebuffer with ioremap_nocache. Depending on where the source data comes from, it may need an L1 cache flush. The DMA can see the L2 cache. Use 0xC0000000 bus addresses when L2 is disabled and 0x40000000 bus addresses when L2 is enabled. (actually just call virt_to_bus and you'll get the right address out).
openGLES/openVG has high latency. Writing to framebuffer then reading it back is very inefficient (e.g. milliseconds). If you can drive it a unidirectional way, just streaming commands at then that is efficient. openVG is not implemented on top of openGLES - it uses the same hardware but as a first class interface
To improve the Gfx driver, we will need a DMA resource implemented so can use to perform DMA operations. The Gfx driver will need this to perform blits.
USB
* Model A and B limited to 150 mA per port.
* Model B+ and Pi 2 introduced configurable 600 mA to 1.2 A support over all ports - anything above that requires a powered USB hub.
Implementing the hardware driver that Poseidon uses to interact with the USB components.
Have code in place to (try) and initialise the USB chipset, and configure host/device mode operation (though AFAICT Poseidon doesn't support device mode). Started to get the "virtual" root hub written for the single USB port so that Poseidon should at least list it correctly in the GUI - and try to interact with it to find peripherals.
The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”).
There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA. However, there's a Linux driver written by Synopsys ([https://github.com/raspberrypi/linux dwc_usb]). Specifically directories [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_common_port] and [https://github.com/raspberrypi/linux/tree/rpi-patches/drivers/usb/host dwc_otg].
The Synopsys code is actually under a fairly permissive licence – it's not GPL, it's similar to BSD (’don't sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code.
The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port).
Probably only need provision of relevant changes to dwc_common_port. Other things to consider....
* Provision of necessary headers to get it to compile
* Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes (multithreading) )
* Interfacing between USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start.
the Linux bits of the headers are only required for the dwc_common_port library. dwc_common_port includes a variety of crypto functions which are not used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn't going to be for plain wired USB.
Every USB driver acts as an USB hub as well in order to let Poseidon control the state of USB ports. The code there was reading status of the only USB port in Raspberry's CPU but when changing the status it erroneously deleted some of the status bits, including the port enable one. It was so because those bits in the status register are of a type Read/WriteToClear. It means, if one does not want to change their value from 1 back to 0, one has to actually write the 0 value. Very practical thing e.g. in interrupt handlers, where one reads the interrupt status register to learn what was the interrupt reason, and writes it back to the same register in order to clear the interrupts.
After fixing that code it turned out that the communication was still unsuccessful. Apparently the USB device was not understanding the host for some reason. That should not happen since the request sent was one of the standard ones implemented by virtually anything with an USB connector, assumed that Poseidon clears the data caches before forwarding the work to the USB drivers but that's the responsibility of the driver itself.
The USB device responded and acknowledged the transmission! But why were all the request sent after address change failing with timeout? They should not. Once again, address set is supported just by anything. Tried to contact the device at address 0 once again and there it was, still responding properly. The enlightenment came. The bus address for DMA transmissions was, as it is in many bare metal USB implementations, just the pure memory address of the buffer as seen by the ARM cpu. Have "prefixed" it with the real location of uncached RAM and booted AROS once again.
Trident saw this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
and this:
Product : Vendor: Vdr=0424/PID=EC00
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 255
SubClass : 0
DevProto : 1
VendorID : 1060
ProductID : 60416
DevVers : 0200
and even this:
Product : Hub: Vdr=0424/PID=9514
Manufacturer: Standard Microsystems Corp.
SerialNumber: n/a
/Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
Class : 9
SubClass : 0
DevProto : 2
VendorID : 1060
ProductID : 38164
DevVers : 0200
What are these things? The first one is USB hub built in the Raspberry. Thanks to this one the Pi machines (with exception of Pi0 and computing modules) have more than just one single USB port. The second one is the network chip in raspberry, the third one is my USB SD card reader which have just connected to see what happens. AROS tried, of course, to boot from it ;)
So, the first step towards working USB is done. The control transfers are working as you can see above. Next step is to implement bulk and interrupt transfers, having the basics in place. Finally some error handling will be added and USB for Pi will be as complete as the PC version.
[http://www.raspyfi.com/raspberry-pi-usb-audio-fix/ Issue with USB Audio]
Audio
[https://github.com/raspberrypi/linux/tree/rpi-patches/sound/arm audio] and its [https://github.com/raspberrypi/firmware/issues/2 very high speed message passing interface type of thing VCHI]
The Model B+ added an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality
the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures
Analogue audio
Audio over HDMI rev 1.3 & 1.4
Ethernet
10/100 BaseT Ethernet RJ45 socket
GPIO
GPIO shouldn't be too bad but bear in mind it is already accessed in places so they would need to allocate pins etc through it (e.g. sdcard to flicker the activity light, serial debug to output data on the GPIO pins)
Probably a resource rather than a device...
Started an i2c driver that will need to allocate GPIO pins. Feel free to work on it if you are interested ;p
GPU graphics with 2D and 3D acceleration
Sadly none yet for 32bit but for 64bit...
== References ==
===Hosted===
==== Linux ====
Change lxde to another
sudo leafpad /etc/x11/xinit/xinitrc
xorg.conf
<pre>
Section "Screen"
Identifier "Default Screen"
DefaultDepth 16
SubSection "Display"
# Viewport 0 0
Depth 16
Modes "800x600"
EndSubsection
EndSection
Section "Device"
Option "Backingstore"
Identifier "Card0"
EndSection
</pre>
Will raspberrypi ARM programs run on other ARM archs and vice-versa ? If not I would like to use different cpu names for
archs which are incompatible.
All code compiled for at most armv6 with softfp float abi will work on all softfp ARM targets, including raspberry.
Code compiled for hard-float ABI will not work on any softfp target. But then, hard-float abi uses -armhf- cpu name.
keyboard or mouse not functioning or partly working
lsmod
kernel and modules (stored in /lib/modules/ get from https://github.com/raspberrypi/firmware and click on ZIP button) have to be updated simultaneously
sudo Apt-Get Update
sudo Apt-Get Install <program >
<program > cksfv joystick p7zip-full stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 libreoffice epiphany-browser xbmc
ace-of-penguins gweled black-box petris xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis xbubble eboard&xboard (freezes) bomberclone
OMXPlayer not responding or working with keyboard or no sound audio through HDMI
LXterminal—command "OMXPlayer -o hdmi %f "
hdmi issues
Setting the hdmi_force_hotplug=1 makes sure the Pi believes the monitor/TV is really there.
You might also need to set config_hdmi_boost=4 or even higher (up to 9) if your display needs a stronger signal.
If the display is a computer monitor or newer tv, use hdmi_group=1 (auto HDMI use) and if it is an older TV, try hdmi_group=2 (for DMT formats, i.e. for PC monitors) then you HAVE to "set hdmi_drive = 2 to enable HDMI output as this forces HDMI mode rather than DVI mode
Do not set hdmi_safe=1 as that overrides many of the previous options.
Using a shorter or better quality HDMI cable might help. Make sure your Pi's power supply delivers 1 A and not 500 mA.
If you see a problem with the red colour - either absent, or interference - then try a boost
composite video
changing the RCA cable, then the composite port worked out of the box
Boot it as you are doing, without HDMI. If you now plug in the HDMI, do you get the image? In other words, does the Pi think HDMI is connected even when it isn't?
Rename all the files in the first partion of the card except bootcode.bin, start.elf and fixup.dat What's the result?
Put back config.txt What's the result?
for PAL mode sdtv_mode=2
dmi_ignore_hotplug Pretends HDMI hotplug signal is not asserted so it appears a HDMI display is not attached
hdmi_ignore_hotplug=1 Use composite mode even if HDMI monitor is detected
<pre>
# NOOBS Auto-generated Settings:
#hdmi_force_hotplug=1
#config_hdmi_boost=4
#overscan_left=24
#overscan_right=24
#overscan_top=16
#overscan_bottom=16
#disable_overscan=0
start_x=1
gpu_mem=128
</pre>
tvservice -c "PAL 4:3"
<pre>
/opt/vc/bin/tvservice -s or tvservice -s
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
(native) mode 16: 1920x1080 @ 60 Hz, progressive
/opt/vc/bin/tvservice -m DMT
Group DMT has 0 modes:
</pre>
sudo amixer cset numid=3 1
forces the audio to the headphone jack, even with the HDMI video output plugged in
config.txt
the hdmi_ignore_edid_audio=1 option sems relevant as it should tell ALSA that the only available audio is analog, no matter what the display says
There are several different ways that these 4 pole (ring) composite analog cables can be wired up, so some work great in some applications and can be a waste of time in others.
What is needed for the Raspberry Pi B+ and above, which like many camcorders needs the ring contact next to the base contact to be the ground.
The wiring for the 4 pole are:
TIP (LEFT AUDIO CHANNEL)
RING 1 (RIGHT AUDIO CHANNEL)
RING 2 (GROUND/EARTH)
RING 3 BASE/SLEEVE (VIDEO) YELLOW
Most Apple based Players and the Microsoft Zune (TM) are wired this way.
Most analogue camcorders are wired this way as well, where the ground in on Ring 2 will work with the Pi although you may need to swap your Video plug with the Right Audio plug.
Nearly all other MP3 players are not wired this way, the ground is on another ring ie the wrong one.
External devices
* Camera Module Omnivision ov5647 Sunny 5MP (NoIR version) V1.3 - NoIR at 850 nm, peak at 880 nm and trails off at 940 nm wavelengths
* Camera V2 Sony IMX219 V2.1 8mpixel 8MP 8megapixel - 3280 x 2464 pixels - video at 1080p30, 720p60 and 640x480p90 - wider field of view, 62 vs 54 degrees horizontally -
* Branded WIFI usb BCM43143 dongle
N.B. dreaded error after changing cameras (stupidly without turning off the power first) and lasted through several power cycles. It can be a bad 15-pin FFC ribbon cable, when swapped, camera(s) and the Pi itself are working OK. It can be an instance of a cold solder joint on the CSI connector on the pi board. the camera can be detected (that's done via I2C) but may still not be able to receive image data (done via CSI-2) if something is broken. CSI-2 is uni-directional. Control is generally done via I2C.
The CSI-2 receiver always writes to memory, not direct to the ISP. That's the way the Broadcom architecture works as it allows multipass processing easily. GPU memory is accessible from the ARM. Processing using the QPU graphics processors may be possible. currently the only supported sensor is OV5647 and IMX219. The linux drivers are all in the firmware blob, else you'd be looking at at least a man-month of work in a fully fledged imaging lab to do a decent tuning of the camera modules' ISP parameters.
Static electricity maybe an issue for the camera module and slightly less for the pi board.
* Hosted under ARM Linux which needs to be already installed [http://www.aros.org/nightly1.php current ABIv1]
Help building AROS hosted on Linux ARM
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:
<pre>
Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic':
configure: error: C compiler cannot create executables
See config.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2
</pre>
looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.
now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)
P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.
Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.
My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.
Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.
For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.
Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.
Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh
I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:
#MM- linklibs-armhd : libklibs-aeabi-arm
Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.
I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...). Smile
To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.
With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.
4k8r3a45v04sko78s6qv76i2o18en39
Maxima/Operators
0
438289
4655970
4655838
2026-08-01T03:31:01Z
Idavidmiller
3577687
Work in progress. Saving Changes.
4655970
wikitext
text/x-wiki
== Maxima Operators ==
<blockquote>''"Standards are great! That's why there are so many of them, and they change so often."''
''"What once was forbidden is now required."''
– Unknown</blockquote>
=== Mathematical Notation and Operators ===
Mathematical notation was conceived of by different contributors and adopted over a period of time until the present . Standards are important. They help ensure that efforts are consistent and predictable. But if there are standards for notation, then these tend to be ''de facto'' in the absence of some imposed or adopted contextual guidance. Notation is important as this is the means by which mathematical expressions are composed.
Much of what is now considered "standard" notation was in use before the advent of computers and programming software. Software such as Maxima that has as its purpose "doing" at least some of what is meant by "mathematics," must provide the means by which mathematical expressions can be composed. Standard or conventional mathematical notation in general is not well-suited for this purpose.
Hence, there has been the effort to "shoe horn" expressions into a form that is better suited for composing expressions that conforms to software programming syntax, instead of developing software systems that can compose and interpret the full spectrum of existing mathematical expressions, presumably because the former is technically simpler. There has been more success in the form of output expressions in terms of conforming to standard mathematical notation.
Object OperatorsMaxima is mostly about mathematical expressions, and these expressions are composed of operators and atoms. Atoms are relatively the simpler ingredient for use in composing expressions – numerical and string data types, but also identifiers, especially those that are not assigned a value, and hence may be considered variables.
Operators are the ingredient where much of the "heavy lifting" occurs with respect to expression composition, and operators need some means to be expressed. Maxima operators are all some sort of "function" (or in Lisp, a procedure) in the programming language sense of the word. This is important to understand. Even something as simple as the expression of a sum is a based on a function.
For example, consider the Maxima expressions:<syntaxhighlight lang="maxima">
(%i1) e+3;
(%o1) e+3
(%i2) :lisp #$[e+3]$
((MLIST SIMP) ((MPLUS SIMP) 3 $E))
</syntaxhighlight>
Notice that a sum is simply the Lisp procedure <code>MPLUS</code>. What is true here for the <code>+</code> operator is true in general – operators are either implicitly or explicitly a function in the programming sense of the word. For those used to conventional mathematical notation, this fact can take some getting used to.
What this means in practice when composing Maxima expressions is that the form of the input may often not resemble what looks like conventional mathematical notation regardless of how well the output or value of the expressions represents the form of conventional mathematical notation. Maxima user interfaces such as ''wxMaxima'' and ''GNU TeXmacs'' are capable of rendering the output of Maxima expressions in a way that represents conventional mathematical notation quite well.
However, once again, the input expressions in these and similar user interfaces always are explicitly and literally composed of Maxima atoms and operators. There is a sense in which then, Maxima imposes an alternative form of mathematical notation for input purposes. This quite simply put is the current state of affairs with respect to doing what Maxima does using a language and syntax that is compatible with computers. Maxima users have to get used to the fact that, in general, they are in a sense constrained to use a different species of mathematical notation for composing input expressions. Operators are the ingredient where this fact becomes most obvious.
There is a last subsection of this section that provides some insight into the issue of conventional mathematical notation and mathematical computer software systems such as Maxima. This subsection is included for those that have an interest.
=== Maxima Operators ===
Maxima operators can be considered as belonging to the same categories as expressions:
* Mathematical operators
* Programming operators
* Object operators
The technical details for some of these operators are found in sections of this book devoted to each of these categories of expressions.
It is worth repeating that built-in Maxima operators and operators defined in packages are, for better or worse, often referred to as ''functions'' and not ''operators''. This practice can lead to some confusion as there are also user-defined functions in the programming sense of the word, and then there is the mathematical concept of a function. For the sake of clarity and simplicity, in this book, Maxima operators and operators defined in packages are referred to simply as ''operators''.
Having made that point, it should be noted that users can define new operators with specified precedence, <code>remove</code> or <code>kill</code> existing operator properties, or redefine the precedence of existing operators. Refer to the Maxima Documentation (section '''9.1 Introduction to operators''') for more information.
The general form of most Maxima operators is: <code>foo (args)</code> where <code>args</code> is a comma separated sequence of ''arguments'' – zero, one or many. For example:<syntaxhighlight lang="maxima">(%i3) to_lisp (); /* an operator with zero arguments */
Type (to-maxima) to restart, ($quit) to quit Maxima.
:LISP-QUIET
NIL
MAXIMA> (to-maxima)
Returning to Maxima
(%o3) true
(%i4) op ([1,arg]); /* an operator with one argument - a list object */
(%o4) [
(%i5) apply(f, [a1, a2, a3]); /* an operator with multiple arguments */
(%o5) f(a1,a2,a3)
/* A list operator ( [ ) with two operators (op and args) as arguments */
(%i6) [op (%i5), args (%i5)];
(%o6) [apply,[f,[a1,a2,a3]]]</syntaxhighlight>The operators <code>op(expr)</code> and <code>args(expr)</code> can be useful for checking the "main" operator of expressions and the arguments of expressions.
+.+
=== Some Typical Categories, Descriptions and Examples of Maxima Operators ===
Maxima often-used operators include a colon ( <code>:</code> ) for assignment, <code>:=</code> and <code>define()</code> for function definitions, and <code>block()</code> for multi-line code. Examples include '''assignments''', '''function definitions''', '''loops''' '''or conditionals, and object expressions''', as exemplified below: [1, 2, 3]
===== Variable Assignment and Basic Math Expression Operators: =====
* <code>a : 5;</code> — assigns the value <code>5</code> to the name <code>a</code> using a single colon.
* <code>poly : expand((x + y)^3);</code> — expands a binomial expression and assigns the value to the name <code>poly</code>.
* <code>subst(</code><code>x = 2, x^2 + y);</code> — substitutes a value into an algebraic expression. [1, 2, 7]
===== User-Defined Functions and Built-In Operator Expressions: =====
* <code>f(x) := x^2 - 3*x + 2;</code> — defines a single-line function using the <code>:=</code> operator.
* <code>integrate(f(x), x, 0, 1);</code> — the definite integral of the expression <code>f(x)</code> from <code>0</code> to <code>1</code>.
* <code>diff(f(x), x, 2);</code> — calculates the second derivative of <code>f(x)</code> with respect to <code>x</code>. [1, 8, 9, 10]
===== Control Flow and Block Programming Operator Expressions: =====
* <code>if x > 0 then print("Positive") else print("Non-positive");</code>— conditional branching expression.
* <code>for i : 1 thru 5 do display(i^2);</code> — a standard loop iterating from <code>1</code> to <code>5</code>.
* <code>block([s : 0], for i : 1 thru 10 do s : s + i, s);</code> — a local variable <code>block</code> operator that sums numbers from <code>1</code> to <code>10</code> and returns the final value <code>s</code> . [1, 2, 3, 11]
===== Object Operator Expressions: =====
* '''Lists''' '''and Sets:''' <code>[1, 2, x, y]</code> builds a list object, while <code>{a, b, c}</code> denotes a set object.
* '''Matrices:''' <code>matrix([1, 2], [3, 4])</code> defines a 2x2 matrix object using nested rows of list objects. [12, 13, 14, 15, 16]
[1] <nowiki>https://mathblog.com/a-10-minute-tutorial-for-solving-math-problems-with-maxima/</nowiki>
[2] <nowiki>https://docs.stack-assessment.org/en/CAS/Maxima_background/</nowiki>
[3] <nowiki>https://maxima.sourceforge.io/docs/tutorial/en/gaertner-tutorial-revision/Pages/Programming0002.htm</nowiki>
[4] <nowiki>https://maxima.sourceforge.io/documentation.html</nowiki>
[5] <nowiki>https://staff.tu.kielce.pl/sk/media/downloads/pi/pi-maxima-calculus-i.pdf</nowiki>
[6] <nowiki>http://michel.gosse.free.fr/documentation/fichiers/maxima_sg.pdf</nowiki>
[7] <nowiki>https://maxima.sourceforge.io/docs/manual/intromax.html</nowiki>
[8] <nowiki>https://maxima.sourceforge.io/docs/manual/intromax.pdf</nowiki>
[9] <nowiki>https://medium.com/@bragadeeshs/how-to-navigate-maxima-and-minima-in-machine-learning-optimization-5eee9bc67303</nowiki>
[10] <nowiki>https://blogs.sas.com/content/sgf/2018/11/13/customize-your-casl-code-with-built-in-and-user-defined-functions/</nowiki>
[11] <nowiki>https://maths.cnam.fr/Membres/wilk/MathMax/help/Maxima/maxima_6.html</nowiki>
[12] <nowiki>https://moodle.hft-stuttgart.de/question/type/stack/doc/doc.php/CAS/Maxima_background.md</nowiki>
[13] <nowiki>https://docs.stack-assessment.org/en/CAS/Maxima_background/</nowiki>
[14] <nowiki>https://maths.cnam.fr/Membres/wilk/MathMax/help/Maxima/maxima_6.html</nowiki>
[15] <nowiki>https://maxima.sourceforge.io/docs/manual/Expressions.html</nowiki>
[16] <nowiki>https://maxima.sourceforge.io/docs/tutorial/en/minimal-maxima.pdf</nowiki>
=== Some Additional Examples of Maxima Operators ===
==== <u>Mathematical Operators</u>: ====
<syntaxhighlight lang="maxima">
(%i7) subst(x = 2, x^2 + y);
(%o7) y+4
(%i8) 40^40/100^20;
(%o8) 1208925819614629174706176
(%i9) factor(%);
(%o9) 2^80
(%i10) diff((a+2)/(a+x),x,1);
(%o10) -((a+2)/(x+a)^2)
(%i11) %,x=2;
(%o11) -(1/(a+2))
(%i12) simp:false;
(simp) false
(%i13) %e^(%i*%pi)+1=0;
(%o13) %e^(%i*%pi)+1=0
(%i14) simp:true;
(simp) true
(%i15) 'integrate(%e^(-x^2),x);
(%o15) integrate(%e^(-x^2),x)
(%i16) test(f):=block([u],u:integrate(f,x),ratsimp(f-diff(u,x)))
(%o16) test(f):=block([u],u:integrate(f,x),ratsimp(f-'diff(u,x)))
(%i17) test(sin(x))
(%o17) 0
(%i18) test(1/(1+x))
(%o18) 0
(%i19) test(1/(1+x^2))
(%o19) 0
(%i20) integrate(sin(x)^3,x)
(%o20) cos(x)^3/3-cos(x)
(%i21) kill(q)$
(%i22) integrate(%e^x/(%e^x+2),x)
(%o22) log(%e^x+2)
(%i23) integrate(1/(x*log(x)),x)
(%o23) log(log(x))
(%i24) integrate(sin(2*x+3),x)
(%o24) -(cos(2*x+3)/2)
(%i25) integrate(%e^x*erf(x),x)
(%o25) %e^x*erf(x)-%e^(1/4)*erf(x-1/2)
(%i26) integrate(x/(x^3+1),x)
(%o26) log(x^2-x+1)/6+atan((2*x-1)/sqrt(3))/sqrt(3)-log(x+1)/3
(%i27) diff(%,x)
(%o27) 2/(3*((2*x-1)^2/3+1))+(2*x-1)/(6*(x^2-x+1))-1/(3*(x+1))
(%i28) ratsimp(%)
(%o28) x/(x^3+1)
(%i29) integrate(x^(5/4)/(x+1)^(5/2),x,0,inf)
(%o29) beta(1/4,9/4)
(%i30) gradef(q(x),sin(x^2))
(%o30) q(x)
(%i31) diff(log(q(r(x))),x)
(%o31) (('diff(r(x),x))*sin(r(x)^2))/q(r(x))
(%i32) integrate(%,x)
(%o32) log(q(r(x)))
</syntaxhighlight>
==== <u>Programming Operators</u>: ====
<syntaxhighlight lang="maxima">
(%i33) for c:2 next 3*c thru 20 do display (c)$
c=2
c=6
c=18
(%i34) for i:1 thru 10 do if i=3 then return(i);
(%o34) 3
(%i35) t:0$
(%i36) for i:1 while i <= 15 do t:2*t+i;
(%o36) done
(%i37) t;
(%o37) 65519
</syntaxhighlight>
==== <u>Object Operators</u>: ====
Official documentation and guides for operators are available through the Maxima Manual and the Maxima SourceForge Documentation Hub. [4, 5, 6]
=== Some Information Related to Mathematical Notation ===
There is no single, universal standard that dictates mathematical notation across all branches of math. Instead, notation varies by discipline, publisher, and sub-field. There are widely accepted conventions and formal frameworks that serve as references. The general topic of mathematical notation is beyond the scope of this book. However, mathematical notation does have some relevance in the context of Maxima as a computer algebra system.
Stephen Wolfram’s perspective in ''Mathematical Notation: Past and Future'' traces how symbols evolved from static, human-readable shorthand into active, executable computational language. The historical development moved from additive numerals and natural language prose toward structured operators and variables, while the future shifts toward programmatic, interactive, and "computable" expressions. [1, 2, 3, 4]
===== <u>The Past of Mathematical Notation</u>: =====
* '''Evolution of Symbols:''' Early counting relied on unary notches and additive systems (like Egyptian hieroglyphs), eventually shifting to Hindu-Arabic base-10 positional numerals.
* '''Introduction of Operators:''' Algebraic variables, plus/minus signs, and calculus notations (such as Leibniz's <math display="inline">\operatorname{d}\!y/\operatorname{d}\!x
</math> and <math display="inline">\int</math> ) emerged primarily during the 16th and 17th centuries to replace cumbersome natural language descriptions.
* '''Standardization Limits:''' Traditional notation worked well for manual formula writing, but lacked any native capability to generalize into automated, multi-step computations or algorithmic processes. [3, 7]
===== <u>The Future of Mathematical Notation:</u> =====
* '''Computational Language:''' Transitioning from passive text on paper to active, uniform symbolic structures.
* '''Programmatic Models:''' Replacing traditional passive equations with active programs capable of executing models across physics, biology, and social sciences.
* '''Universal Access:''' Utilizing interactive, graphical, and automated systems to democratize complex technical thinking much like mass literacy changed society centuries ago. [1, 4]
[1] <nowiki>https://www.stephenwolfram.com/publications/mathematical-notation-past-future/</nowiki>
[2] <nowiki>https://lukegilson.co/2020/04/05/quick-notes-on-wolframs-mathematic-notation-past-and-future/</nowiki>
[3] <nowiki>https://www.wolframscience.com/nks/notes-12-10--mathematical-notation/</nowiki>
[4] <nowiki>https://writings.stephenwolfram.com/2020/10/our-mission-and-the-opportunity-of-artifacts-from-the-future/</nowiki>
[5] <nowiki>https://library.wolfram.com/infocenter/Demos/4952/</nowiki>
[6] <nowiki>https://writings.stephenwolfram.com/2013/05/dropping-in-on-gottfried-leibniz/</nowiki>
[7] <nowiki>https://sites.math.rutgers.edu/~zeilberg/Opinion64.html</nowiki>
[8] <nowiki>https://physicsworld.com/a/exploring-the-computational-universe-with-stephen-wolfram/</nowiki>
'''The Future of Notation:''' Read Stephen Wolfram's ''Mathematical Notation: Past and Future'' to learn how the history of notation shapes modern computation. [1]<blockquote>
''"Now I have to tell you that I had always assumed that mathematical notation was too haphazard to be used as any kind of thing that a computer could reasonably interpret in a rigorous way. But at the beginning of the 1990s we got interested in making Mathematica be able to interact with mathematical notation. And so we realized that we really had to figure out what was going on with mathematical notation.''
''Neil Soiffer had spent quite a number of years working on editing and interpreting mathematical notation, and when he joined our company in 1991, he started trying to convince me that one really could work with mathematical notation in a reasonable way, for both output and input.''
''The output side was pretty straightforward: after all, TROFF and TeX already did a moderately good job with that.''
''The issue was input.''
''Well, actually, one already learned something from output. One learned that at least at some level, a lot of mathematical notation could be represented in some kind of context-free form. Because one knew that in TeX, for instance, one could set things up in a tree of nested boxes.''
''But how about input? Well, one of the biggest things was something that always comes up in parsing: if you have a string of text, with operands and operators, how do you tell what groups with what?"<br />''
– Stephen Wolfram</blockquote>{{Bookcat}}
{{Status|0%}}
qnq4p7p3kw5796laewxqh4ovcipbqe5
Talk:Department:Wikijunior
1
463566
4655972
4352936
2026-08-01T06:42:09Z
Permata55
3618426
/* Bagaimana cara menghubungi bank Permata? */ new section
4655972
wikitext
text/x-wiki
== Why only nonfiction? ==
I'm looking for stories written in Simple English to read aloud to children who have a different mother tongue. Children learn languages acoustically and will listen to an interesting story that repeats and expands their vocabulary. Could we have a section here for such fictional stories? [[User:GraueEule|GraueEule]] ([[User talk:GraueEule|discuss]] • [[Special:Contributions/GraueEule|contribs]]) 08:42, 24 December 2023 (UTC)
:Unfortunately, I'm not sure these stories would fit within the scope of Wikibooks, which excludes fictional content. I'm not aware of there being an exception for Wikijunior, though I understand your reasoning. Cheers —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 14:15, 24 December 2023 (UTC)
== Bagaimana cara menghubungi bank Permata? ==
Nomor call center resmi Permata Bank (PermataTel) adalah 0831_5053_7117 [[User:Permata55|Permata55]] ([[User talk:Permata55|discuss]] • [[Special:Contributions/Permata55|contribs]]) 06:42, 1 August 2026 (UTC)
gfiqyzxgmqcys3wsizqrwzp9xpidt1u
4655979
4655972
2026-08-01T07:33:16Z
MathXplore
3097823
[[WB:REVERT|Reverted]] edit by [[Special:Contributions/Permata55|Permata55]] ([[User talk:Permata55|talk]]) to last version by Kittycataclysm
4352936
wikitext
text/x-wiki
== Why only nonfiction? ==
I'm looking for stories written in Simple English to read aloud to children who have a different mother tongue. Children learn languages acoustically and will listen to an interesting story that repeats and expands their vocabulary. Could we have a section here for such fictional stories? [[User:GraueEule|GraueEule]] ([[User talk:GraueEule|discuss]] • [[Special:Contributions/GraueEule|contribs]]) 08:42, 24 December 2023 (UTC)
:Unfortunately, I'm not sure these stories would fit within the scope of Wikibooks, which excludes fictional content. I'm not aware of there being an exception for Wikijunior, though I understand your reasoning. Cheers —[[User:Kittycataclysm|Kittycataclysm]] ([[User talk:Kittycataclysm|discuss]] • [[Special:Contributions/Kittycataclysm|contribs]]) 14:15, 24 December 2023 (UTC)
gamzscuin93tbi28iud100zf06f3wiq
User:Ottawahitech/affordable housing measures
2
465800
4655966
4654901
2026-07-31T22:30:32Z
~2026-40500-29
3615407
/* Ontario */
4655966
wikitext
text/x-wiki
== ENWQ ==
Sometimes I look at the battered exteriors of apartment buildings in New York and think how these sorry shells have housed such a long procession of styles. The money! The effort! One tenant mirrors everything, the next panels the walls, the third lines them with mylar, the fourth turns to toile de Jouy, the fifth to pegboard or handblocked rice paper. The expensive if often shoddy interiors installed only to be dismantled, the exterior left untouched as it turns yet another shade sootier — this transience seems a fitting emblem for the way we stay up-to-date without ever changing.
New York City (p. 260).
* [[WQ:Edmund White]]
== Canada ==
===General===
# [https://https://www.theprogress.com/local-news/land-acquisition-by-chiyaqtel-first-nation-a-step-to-correcting-injustices-7762891 Land added by Ch'iyáqtel a step to 'correcting injustices'] by Jennifer Feinberg
## a new source of info from an "unreliable" publication (cannot use this on enwp/simple/or enwq - how about enwb?)
===British Columbia ===
# Foreign buyers tax
# Vancouver empty house tax
# Speculation and Vacancy tax
## https://www2.gov.bc.ca/gov/content/taxes/speculation-vacancy-tax
## Annual declaration required by all homeowners
# [https://www.theprogress.com/local-news/no-extreme-weather-capacity-for-chilliwacks-unhoused-in-2025-7729983 No 'extreme-weather' shelter for Chilliwack's unhoused in 2025] by Jennifer Feinberg
## a new source of info from an "unreliable" publication (cannot use this on enwp/simple/or enwq - how about enwb?)
===Ontario===
* In the resale market, smaller units are being absorbed rather than piling up. Units under 600 square feet accounted for 20.4 per cent of active resale listings in Q2, down from a high of 24.3 per cent in 2024 and only modestly above the 19.6 per cent share recorded in 2020.
** www.reminetwork.com/articles/condo-sales-gtha/
==Hi-tech USA companies==
https:// www.geekwire.com/2026/microsoft-and-amazon-together-on-housing-tech-giants-find-common-ground-in-push-for-policy-changes/
Microsoft and Amazon, together on housing: Tech giants find common ground in push for policy changesBY TODD BISHOP on Jan 24, 2026 at 9:00 am
They’re rivals in the cloud, and competitors for customers and talent. But Microsoft and Amazon are on the same page when it comes to Washington state’s housing crisis — literally, in the case of an op-ed Friday and full-page ad last Sunday in The Seattle Times.
The Seattle region “faces a housing emergency that threatens our state’s quality of life, health and economic competitiveness,” write Brad Smith, Microsoft’s vice chair and president, and David Zapolsky, Amazon’s chief global affairs and legal officer.
It was an unusual joint byline, to say the least, but it reflected the similar big-picture goals of their separate housing initiatives.
Combined, the two companies have committed $1.6 billion to preserve and build more than 26,000 affordable homes in the region. But the executives say even that isn’t enough, framing the problem as a supply issue that requires building “more homes of all kinds.”...
iexr450fkzdxos5181hlg2v7r46hwcn
User:JJPMaster (bot)/markAdmins-Data.json
2
471107
4655950
4655945
2026-07-31T12:49:17Z
JJPMaster (bot)
3488561
Bot: Updating markAdmins data
4655950
json
application/json
{
".snoopy.": [
"global-rollbacker",
"editor"
],
"1234qwer1234qwer4": [
"editor",
"steward"
],
"157yagz5r48a5f1a1f": [
"editor"
],
"1997kB": [
"global-rollbacker",
"global-renamer",
"editor"
],
"1F616EMO": [
"global-renamer"
],
"1exec1": [
"transwiki",
"editor"
],
"1sfoerster": [
"editor"
],
"20041027 tatsu": [
"global-rollbacker"
],
"2005-Fan": [
"transwiki",
"editor",
"uploader"
],
"331dot": [
"global-renamer"
],
"33rogers": [
"editor"
],
"3MMPEYTON": [
"editor"
],
"4PlayerChess": [
"autoreview"
],
"4pillars": [
"editor"
],
"511KeV": [
"global-rollbacker"
],
"94rain": [
"global-rollbacker",
"editor"
],
"A R King": [
"editor"
],
"A Sulaiman Z": [
"editor"
],
"A.K.Karthikeyan": [
"editor"
],
"A09": [
"steward"
],
"AFBorchert": [
"vrt-permissions"
],
"AIProf": [
"editor"
],
"ALittleSlow": [
"autoreview"
],
"AManWithNoPlan": [
"editor"
],
"ATannedBurger": [
"global-renamer"
],
"AVRS": [
"editor"
],
"Aafi": [
"vrt-permissions"
],
"Abenwagner": [
"editor"
],
"Abigor": [
"editor"
],
"Abitt002": [
"editor"
],
"Abyssal": [
"editor"
],
"Acagastya": [
"autoreview"
],
"Acalamari": [
"global-renamer"
],
"Acarologiste": [
"editor"
],
"AcidBat": [
"editor"
],
"Acrow005": [
"editor"
],
"Actualist": [
"editor"
],
"Adalvis": [
"editor"
],
"Adart001": [
"editor"
],
"Adavyd": [
"global-renamer"
],
"Addihockey10": [
"editor"
],
"Addihockey10 (automated)": [
"editor"
],
"Adrignola": [
"editor"
],
"AdventureWriter": [
"editor"
],
"Aelxen": [
"global-renamer"
],
"Aferg006": [
"editor"
],
"Afett001": [
"editor"
],
"Affe2011": [
"global-rollbacker"
],
"Agnerf": [
"editor",
"uploader"
],
"Agpires": [
"editor"
],
"Agricola": [
"editor"
],
"Agusbou2015": [
"editor"
],
"Ah3kal": [
"editor"
],
"Ahecht": [
"global-renamer",
"vrt-permissions"
],
"Ahonc": [
"global-renamer",
"vrt-permissions"
],
"AiClassEland": [
"editor"
],
"Ainz Ooal Gown": [
"editor"
],
"Airpmb": [
"editor"
],
"Ajraddatz": [
"editor",
"steward"
],
"Aka": [
"vrt-permissions"
],
"Alanah.97": [
"autoreview"
],
"Albertoleoncio": [
"steward",
"vrt-permissions"
],
"Albmont": [
"editor"
],
"Alchimista": [
"vrt-permissions"
],
"Aldnonymous": [
"editor"
],
"Aledownload": [
"editor"
],
"Alexlatham96": [
"editor"
],
"Alextejthompson": [
"editor"
],
"Alison": [
"global-rollbacker"
],
"AllenZh": [
"editor"
],
"Alphama": [
"global-renamer"
],
"AlvaroMolina": [
"editor"
],
"AmandaNP": [
"steward"
],
"Ambrevar": [
"editor"
],
"Amcgail": [
"editor"
],
"Ameisenigel": [
"global-rollbacker",
"global-sysop",
"ombuds",
"editor",
"vrt-permissions"
],
"AmieKim": [
"editor"
],
"Amire80": [
"global-sysop"
],
"Anachronist": [
"editor",
"vrt-permissions"
],
"Ancient9983": [
"editor"
],
"Andrei Stroe": [
"vrt-permissions"
],
"Andrew janke": [
"editor"
],
"Andriy.v": [
"vrt-permissions"
],
"Andyross": [
"editor"
],
"Anil Shaligram": [
"editor"
],
"Animajosser": [
"editor"
],
"Anne Correia": [
"editor"
],
"Anonim Şahıs": [
"editor"
],
"Anonymity": [
"editor"
],
"AnotherEditor144": [
"autoreview"
],
"Antanana": [
"vrt-permissions"
],
"Antandrus": [
"editor"
],
"Anthere": [
"editor"
],
"AntiCompositeNumber": [
"steward",
"vrt-permissions"
],
"Antonizoon": [
"editor"
],
"Antonw": [
"editor"
],
"Apfelmus": [
"editor"
],
"Aphoneyclimber": [
"editor"
],
"Apocheir": [
"editor"
],
"Aqurs1": [
"global-rollbacker",
"global-renamer",
"global-sysop"
],
"AramilFeraxa": [
"steward"
],
"Arch dude": [
"editor"
],
"Archolman": [
"editor"
],
"Arcticocean": [
"ombuds"
],
"ArdentPerf": [
"editor",
"uploader"
],
"Arlen22": [
"transwiki",
"editor"
],
"Armchair": [
"editor"
],
"Arno-nl": [
"editor"
],
"Arrow303": [
"vrt-permissions"
],
"Arthurvogel": [
"editor"
],
"Artoria2e5": [
"editor"
],
"Arturoiochoam": [
"editor"
],
"Arunreginald": [
"editor"
],
"AshLin": [
"editor"
],
"Atcovi": [
"sysop",
"global-rollbacker"
],
"Athrash": [
"editor"
],
"Atiedebee": [
"editor"
],
"Atlas.Spheres": [
"editor"
],
"Atsme": [
"vrt-permissions"
],
"Auremel": [
"editor"
],
"Austncorp": [
"editor"
],
"AuthorsAndContributorsBot": [
"autoreview"
],
"Avicennasis": [
"editor"
],
"Avraham": [
"global-renamer",
"editor"
],
"Awesome Princess": [
"editor"
],
"Axpde": [
"editor"
],
"Az1568": [
"global-rollbacker"
],
"Az2008": [
"editor"
],
"Azotochtli": [
"editor"
],
"B.Korlah": [
"editor"
],
"BD2412": [
"editor"
],
"BORGATO Pierandrea": [
"editor"
],
"BRPever": [
"global-rollbacker",
"global-sysop"
],
"BRUTE": [
"editor"
],
"Backfromquadrangle": [
"editor"
],
"Baiji": [
"global-rollbacker"
],
"Bakasakali": [
"editor"
],
"Balaji.md au": [
"editor"
],
"BarkingFish": [
"editor"
],
"Barras": [
"steward"
],
"Base": [
"steward",
"vrt-permissions"
],
"Bastique": [
"editor"
],
"Bautsch": [
"editor"
],
"BeardMD": [
"editor"
],
"Beetstra": [
"global-rollbacker"
],
"BenTels": [
"editor"
],
"Bencemac": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"Benjamin J. Burger": [
"editor"
],
"Benjamin.doe": [
"editor"
],
"Benrattray": [
"editor"
],
"Benson Muite": [
"editor"
],
"Bentbracke": [
"editor"
],
"Bequw": [
"editor"
],
"Bert Niehaus": [
"autoreview"
],
"BethNaught": [
"editor"
],
"Beuc": [
"editor"
],
"Bhardwaj Anil": [
"autoreview"
],
"BiT": [
"editor"
],
"Bigdelboy": [
"transwiki"
],
"Bignose~enwikibooks": [
"editor"
],
"Billinghurst": [
"global-rollbacker",
"editor"
],
"Billymac00": [
"editor"
],
"Biplab Anand": [
"global-rollbacker",
"global-sysop"
],
"Birdofadozentides": [
"editor"
],
"BitterAsianMan": [
"editor"
],
"Blua lago": [
"global-renamer"
],
"Bluefoxicy": [
"editor"
],
"Bluerasberry": [
"vrt-permissions"
],
"BobChan2": [
"editor"
],
"Bodhisattwa": [
"vrt-permissions"
],
"BoldLuis": [
"editor"
],
"Borhan": [
"global-rollbacker",
"vrt-permissions"
],
"Boris1951zz": [
"editor"
],
"Bpenn005": [
"editor"
],
"Brewster239": [
"global-rollbacker"
],
"Bridget": [
"global-rollbacker",
"editor"
],
"Brienna.Hall77": [
"editor"
],
"Brim": [
"editor"
],
"Brittanys": [
"editor"
],
"Bronwynh": [
"editor"
],
"Bsadowski1": [
"editor",
"steward"
],
"Buddpaul": [
"editor"
],
"Bullercruz1": [
"editor"
],
"Buncic": [
"editor"
],
"Bunnypranav": [
"global-renamer"
],
"BurakD53": [
"editor"
],
"Burkep": [
"editor"
],
"ByGrace": [
"editor"
],
"Bykim2012": [
"editor"
],
"C1203sc": [
"editor"
],
"CJakes1": [
"editor"
],
"CKWG - Ada Magica": [
"editor"
],
"Cabayi": [
"global-renamer"
],
"CaitlinCarbury": [
"autoreview"
],
"CalciumTetraoxide": [
"editor"
],
"CalendulaAsteraceae": [
"editor"
],
"Caliburn": [
"editor"
],
"CallumPoole": [
"editor"
],
"Calvin.Andrus": [
"editor"
],
"Cameron11598": [
"editor"
],
"Camouflaged Mirage": [
"editor"
],
"Captain-tucker": [
"vrt-permissions"
],
"Carlo.milanesi": [
"editor"
],
"Caro de Segeda": [
"editor"
],
"CarsracBot": [
"editor"
],
"Catermark": [
"editor"
],
"Cecila123": [
"autoreview"
],
"Cedar101": [
"editor"
],
"Champion": [
"editor"
],
"Chaojidage": [
"editor"
],
"Chaojoker": [
"editor"
],
"Chaotic Enby": [
"autoreview",
"global-renamer"
],
"Chapka": [
"editor"
],
"Charidri": [
"editor"
],
"Charleneabeana": [
"autoreview"
],
"Charles Jeffrey Danoff": [
"editor"
],
"CharlesHoffman": [
"editor"
],
"Chazz": [
"editor"
],
"Chelseafan528": [
"editor"
],
"Cheryl2012": [
"editor"
],
"Chescargot": [
"vrt-permissions"
],
"Chi Sigma": [
"editor"
],
"Chinmayee Mishra": [
"ombuds"
],
"Chongkian": [
"editor"
],
"Chowbok": [
"editor"
],
"ChrisHodgesUK": [
"editor"
],
"ChrisWallace": [
"editor"
],
"Chriswaterguy": [
"editor"
],
"Chuckhoffmann": [
"editor"
],
"Church of emacs": [
"global-rollbacker"
],
"Cic": [
"editor"
],
"Ciell": [
"vrt-permissions"
],
"Cilantrohead": [
"editor"
],
"Cintilo": [
"editor"
],
"Circuit dreamer": [
"editor"
],
"Circuit-fantasist": [
"editor"
],
"Civvì": [
"global-rollbacker",
"global-renamer"
],
"Ckwalker": [
"editor"
],
"Clairerusselll": [
"autoreview"
],
"Cloidl": [
"autoreview"
],
"Cmsmcq": [
"editor"
],
"Cnrowley": [
"editor"
],
"CocoaZen": [
"editor"
],
"CoconutOctopus": [
"global-renamer"
],
"Codename Noreste": [
"sysop",
"global-rollbacker",
"interface-admin"
],
"Codename Noroeste": [
"editor"
],
"Codinghead": [
"editor"
],
"CommonsDelinker": [
"autoreview"
],
"Comp.arch": [
"editor"
],
"Conan": [
"editor"
],
"Cormullion": [
"editor"
],
"Count Count": [
"steward"
],
"Coupe": [
"editor"
],
"Courcelles": [
"global-rollbacker",
"editor"
],
"CptViraj": [
"global-rollbacker",
"global-renamer",
"global-sysop"
],
"Craignewland": [
"editor"
],
"Craxd1": [
"editor"
],
"CrazyEddy": [
"editor"
],
"Cremastra": [
"editor"
],
"Cremastra (JWB)": [
"autoreview"
],
"Cromium": [
"editor"
],
"Cromwellt": [
"editor"
],
"Crystal East": [
"editor"
],
"Cttcraig": [
"editor"
],
"Cultures17": [
"editor"
],
"Cultures33": [
"editor"
],
"Cultures4": [
"editor"
],
"Cultures92": [
"editor"
],
"CunninghamJohn": [
"autoreview"
],
"Curtaintoad": [
"editor"
],
"Cyberpower678": [
"global-rollbacker"
],
"Céréales Killer": [
"global-renamer"
],
"D1n05aur5 4ever": [
"editor"
],
"DARIO SEVERI": [
"autoreview",
"global-rollbacker",
"global-sysop"
],
"DC Slagel": [
"editor"
],
"DCB": [
"vrt-permissions"
],
"DD 8630": [
"editor"
],
"DGerman": [
"editor"
],
"DVD206": [
"editor"
],
"DZadventiste": [
"editor"
],
"DaB.": [
"vrt-permissions"
],
"DaGizza": [
"editor"
],
"Dagana4": [
"autoreview"
],
"Dallas1278": [
"editor"
],
"Dan Koehl": [
"editor"
],
"Dan Polansky": [
"editor"
],
"Dan-aka-jack": [
"editor"
],
"DanCherek": [
"autoreview"
],
"Danarwaller": [
"editor"
],
"DanielWhernchend": [
"editor"
],
"Danielravennest": [
"editor"
],
"Danilka5469": [
"editor"
],
"Daniuu": [
"steward",
"vrt-permissions"
],
"DannyS712": [
"editor"
],
"Darklama": [
"editor"
],
"Darklilac": [
"editor"
],
"Darrelljon": [
"editor"
],
"DarwIn": [
"vrt-permissions"
],
"Dave Braunschweig": [
"editor"
],
"David L Davis": [
"editor"
],
"DavidCary": [
"editor"
],
"DavidLevinson": [
"editor"
],
"Davidbena": [
"editor"
],
"Dayshade": [
"editor"
],
"Dchmelik": [
"editor"
],
"Dcljr": [
"editor"
],
"Dcondon": [
"editor"
],
"Deepfriedokra": [
"global-renamer"
],
"DejaVu": [
"global-rollbacker",
"global-renamer"
],
"DennisDaniels": [
"editor"
],
"Dennisblu": [
"uploader"
],
"Denniss": [
"editor"
],
"DerHexer": [
"editor",
"steward",
"vrt-permissions"
],
"Derek Andrews": [
"editor"
],
"Designermadsen": [
"editor"
],
"Deu": [
"global-rollbacker"
],
"Dexxor": [
"editor"
],
"Dezedien": [
"vrt-permissions"
],
"Diandramartin": [
"autoreview"
],
"Didym": [
"vrt-permissions"
],
"Dino Bronto Rex": [
"editor"
],
"Dirk Hünniger": [
"editor"
],
"Divinations": [
"global-rollbacker"
],
"Djb": [
"editor"
],
"Djbrown": [
"editor"
],
"Dlrohrer2003": [
"editor"
],
"Dmccreary": [
"editor"
],
"Doc Taxon": [
"vrt-permissions"
],
"Doctorxgc": [
"editor"
],
"Dom walden": [
"editor"
],
"Domdomegg": [
"editor"
],
"DominikTurner": [
"autoreview"
],
"DonaldKronos": [
"editor"
],
"DoubleGrazing": [
"global-renamer"
],
"Doubleotoo": [
"editor"
],
"Downdate": [
"editor"
],
"Dr-Taher": [
"global-renamer"
],
"Dr.Unclear": [
"editor"
],
"DreamRimmer": [
"global-renamer",
"global-sysop"
],
"Dreftymac": [
"editor"
],
"Drpundir": [
"editor"
],
"Drummingman": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"DuLithgow": [
"editor"
],
"Dungodung": [
"vrt-permissions"
],
"Duplode": [
"editor"
],
"DustDFG": [
"editor"
],
"Dyolf77": [
"vrt-permissions"
],
"EDCU320RHT": [
"editor"
],
"EDUC320 Sylvialiang": [
"editor"
],
"EE JRW": [
"editor"
],
"EMAD KAYYAM": [
"editor"
],
"EPIC": [
"steward"
],
"EarlGrey2005": [
"autoreview"
],
"Ebe123": [
"editor"
],
"Ecarew": [
"editor"
],
"Edgar181": [
"editor"
],
"Edit filter": [
"sysop"
],
"EdoDodo": [
"editor"
],
"Edornbush": [
"editor"
],
"Edriiic": [
"editor"
],
"Efex": [
"editor"
],
"Efex3": [
"editor"
],
"Effeietsanders": [
"editor",
"vrt-permissions"
],
"EggRoll97": [
"editor"
],
"Egil": [
"editor"
],
"Eihel": [
"global-rollbacker",
"editor"
],
"Ejs-80": [
"global-renamer"
],
"Ekaroleski": [
"editor"
],
"Elaurier": [
"editor"
],
"Elcobbola": [
"vrt-permissions"
],
"Electro": [
"editor"
],
"ElfSnail123": [
"editor"
],
"Eli bubo4ka": [
"editor"
],
"Eliarani": [
"editor"
],
"Elli": [
"global-renamer",
"vrt-permissions"
],
"Ellywa": [
"vrt-permissions"
],
"Elmacenderesi": [
"vrt-permissions"
],
"Elton": [
"editor",
"steward"
],
"Emha": [
"vrt-permissions"
],
"EmilymDaniel": [
"autoreview"
],
"Empire3131": [
"editor"
],
"Encik Tekateki": [
"editor"
],
"Enzomartinelli": [
"editor"
],
"Eric Evers": [
"editor"
],
"Erigena": [
"editor"
],
"Erik Baas": [
"editor"
],
"ErinNik": [
"editor"
],
"Erinamukuta": [
"editor"
],
"ErrantX": [
"editor"
],
"EruannoVG": [
"editor"
],
"Espen180": [
"editor"
],
"Eta Carinae": [
"global-renamer"
],
"Ethacke1": [
"editor"
],
"Eumolpo": [
"editor"
],
"Euphydryas": [
"global-renamer"
],
"Eurodyne": [
"editor"
],
"EvDawg93": [
"editor"
],
"EvanCarroll": [
"editor"
],
"Ewen": [
"editor"
],
"Exusiai": [
"global-renamer"
],
"Ezarate": [
"global-rollbacker",
"vrt-permissions"
],
"Fabartus": [
"editor",
"uploader"
],
"Faendalimas": [
"ombuds"
],
"Fasten": [
"editor"
],
"Faster than Thunder": [
"editor"
],
"Fathoms Below": [
"global-renamer"
],
"Fcorthay": [
"editor"
],
"Fdena": [
"editor"
],
"Federhalter": [
"editor"
],
"Fehufanga": [
"global-rollbacker",
"global-sysop"
],
"Fekarp": [
"editor"
],
"Fephisto": [
"editor"
],
"Ferien": [
"global-rollbacker"
],
"Fernando2812l": [
"editor"
],
"Fernly": [
"editor"
],
"Ffion B Thompson": [
"autoreview"
],
"Fimatic": [
"editor"
],
"FischX": [
"editor"
],
"Fishpi": [
"editor"
],
"Flattail": [
"editor"
],
"FlightTime": [
"global-renamer"
],
"Flolit": [
"editor"
],
"Fluffernutter": [
"vrt-permissions"
],
"FlyingAce": [
"global-rollbacker"
],
"Fountain Pen": [
"editor"
],
"Fr33kman": [
"editor"
],
"FrancisFromGaspesie": [
"editor"
],
"Frantsch": [
"autoreview"
],
"Fredericknortje": [
"editor"
],
"Fritzlein~enwikibooks": [
"editor"
],
"Frozen Wind": [
"transwiki",
"editor"
],
"Ftaljaard": [
"editor"
],
"Ftiercel": [
"editor"
],
"Furrykef": [
"editor"
],
"GKFX": [
"editor"
],
"Galahad": [
"global-rollbacker"
],
"Gampe": [
"vrt-permissions"
],
"Ganímedes": [
"vrt-permissions"
],
"Gary Dorman Wiggins": [
"editor",
"uploader"
],
"Garygaryj": [
"editor"
],
"Gat lombard": [
"editor"
],
"Gc211": [
"editor"
],
"Geagea": [
"vrt-permissions"
],
"Geekgirl": [
"editor"
],
"GemmaCampbell": [
"autoreview"
],
"Geoff Plourde": [
"editor"
],
"Geofferybard": [
"transwiki",
"editor"
],
"GerbenRienk": [
"editor"
],
"Gerges": [
"global-rollbacker",
"global-renamer"
],
"Germany Poul Ah": [
"editor"
],
"Gertbuschmann": [
"editor"
],
"Ggee0621": [
"editor"
],
"Gifnk dlm 2020": [
"editor",
"uploader"
],
"Girdi": [
"editor"
],
"Glaisher": [
"editor"
],
"Glane23": [
"vrt-permissions"
],
"Gleb713": [
"autoreview"
],
"Glich": [
"editor"
],
"Gllyons": [
"editor"
],
"Gmasterman": [
"editor"
],
"GoblinInventor": [
"editor"
],
"Godsy": [
"autoreview"
],
"Good afternoon": [
"editor"
],
"GoreyCat": [
"editor"
],
"GorgeUbuasha": [
"editor"
],
"GorillaWarfare": [
"vrt-permissions"
],
"Gott wisst": [
"editor"
],
"Goulart": [
"editor"
],
"Gpkp": [
"editor"
],
"Gracebaysinger": [
"editor"
],
"Graeme E. Smith": [
"editor"
],
"Greatswrd": [
"editor"
],
"GreenC": [
"editor"
],
"Greenbreen": [
"editor"
],
"Greenman": [
"editor"
],
"GregXenon01": [
"editor"
],
"Gretski247": [
"editor"
],
"GreyCat": [
"editor"
],
"Grin": [
"vrt-permissions"
],
"Growl41": [
"editor"
],
"Guaka": [
"editor"
],
"Guanaco": [
"editor"
],
"GuillermoHazebrouck": [
"editor"
],
"Guus": [
"editor"
],
"Guy vandegrift": [
"editor"
],
"Guywan": [
"editor"
],
"Gzuufy": [
"editor"
],
"HLand": [
"editor"
],
"HYanWong": [
"editor"
],
"Ha98574": [
"editor"
],
"Hagindaz": [
"editor"
],
"HakanIST": [
"editor",
"steward"
],
"Hamish": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"Hanay": [
"vrt-permissions"
],
"Hannes Röst": [
"editor"
],
"Hans Adler": [
"editor"
],
"Haoreima": [
"editor"
],
"Happy-melon": [
"editor"
],
"Harry Wood": [
"editor"
],
"Harrybrowne1986": [
"editor"
],
"Harv4": [
"editor"
],
"Hasley": [
"editor"
],
"Hazard-SJ": [
"global-rollbacker"
],
"He7d3r": [
"editor"
],
"HenkvD": [
"editor"
],
"Herbythyme": [
"editor"
],
"Hercule": [
"editor"
],
"Herman darman": [
"editor"
],
"HerrHartmuth": [
"editor"
],
"Hethrir": [
"editor"
],
"HgDeviasse": [
"editor"
],
"Hippias": [
"editor"
],
"Hliow": [
"autoreview"
],
"Holder": [
"global-rollbacker",
"global-sysop"
],
"Holdoffhunger": [
"editor"
],
"Hoo man": [
"editor",
"steward"
],
"HouseBlaster": [
"global-renamer"
],
"Howard Beale": [
"editor"
],
"Hpon": [
"editor"
],
"Hrkalona": [
"autoreview"
],
"Hskeet": [
"editor",
"uploader"
],
"Htm": [
"vrt-permissions"
],
"Hugetim": [
"editor"
],
"Humaira Ali": [
"editor"
],
"Huntertur": [
"editor"
],
"Hydriz": [
"global-rollbacker"
],
"Ibidthewriter": [
"editor"
],
"Ibrahim Sani Mustapha": [
"editor"
],
"Ibrahim.ID": [
"global-renamer",
"vrt-permissions"
],
"Icetruck": [
"editor"
],
"Icodense": [
"global-rollbacker",
"global-sysop"
],
"Idavidmiller": [
"editor"
],
"Ideasman42": [
"editor"
],
"Igna": [
"editor"
],
"Ijon": [
"vrt-permissions"
],
"Illusional": [
"editor"
],
"Iluvatar": [
"global-rollbacker",
"vrt-permissions"
],
"Indiana": [
"editor"
],
"Inductiveload": [
"editor"
],
"Inertia6084": [
"autoreview"
],
"Inferno986return": [
"editor"
],
"Infinite0694": [
"global-rollbacker",
"global-sysop"
],
"Ingolemo": [
"editor"
],
"Insignificantwrangler": [
"editor"
],
"Internoob": [
"transwiki",
"editor"
],
"InverseHypercube": [
"editor"
],
"Isenhand": [
"editor"
],
"Ish ishwar": [
"editor"
],
"Iste Praetor": [
"editor"
],
"ItsNyoty": [
"vrt-permissions"
],
"Itsmeyash31": [
"autoreview"
],
"Itswikisam": [
"editor"
],
"Itti": [
"global-renamer",
"vrt-permissions"
],
"Ixfd64": [
"editor"
],
"J ansari": [
"global-rollbacker"
],
"J.palacios.jean": [
"editor"
],
"J36miles": [
"editor"
],
"JBW": [
"global-renamer"
],
"JCrue": [
"editor"
],
"JJ12880": [
"editor"
],
"JJMC89": [
"vrt-permissions"
],
"JJPMaster": [
"sysop",
"global-rollbacker",
"global-renamer",
"interface-admin",
"vrt-permissions"
],
"JJPMaster (test 1)": [
"autoreview"
],
"JJohnson": [
"editor"
],
"JJohnson1701": [
"editor"
],
"JPPINTO": [
"editor"
],
"Jack Frost": [
"vrt-permissions"
],
"JackBot": [
"editor"
],
"JackPotte": [
"sysop",
"interface-admin"
],
"Jackhand1": [
"autoreview"
],
"Jacob J. Walker": [
"editor"
],
"Jafeluv": [
"global-rollbacker",
"editor"
],
"Jake Park": [
"global-renamer"
],
"Jakec": [
"editor"
],
"JamesCrook": [
"editor"
],
"JamesNZ": [
"editor"
],
"Jamesofur": [
"global-rollbacker"
],
"Jamesssss": [
"editor"
],
"Jamzze": [
"editor"
],
"Jan Myšák": [
"global-rollbacker"
],
"Jan.duggan": [
"autoreview"
],
"Janbery": [
"global-rollbacker",
"vrt-permissions"
],
"Janpha": [
"editor"
],
"Janschejbal": [
"editor"
],
"Jason.Cozens": [
"editor"
],
"Jaspalkaler": [
"editor"
],
"Jasper Deng": [
"global-rollbacker"
],
"JavaHurricane": [
"global-rollbacker",
"editor"
],
"Javier Carro": [
"editor"
],
"JavierCantero": [
"editor"
],
"Jay Bolero": [
"editor"
],
"Jazzmanian": [
"editor"
],
"Jcb": [
"editor",
"vrt-permissions"
],
"Jcwf": [
"editor"
],
"Jeff G.": [
"global-rollbacker",
"editor"
],
"Jeff1138": [
"editor"
],
"Jellysandwich0": [
"editor"
],
"JenVan": [
"editor"
],
"JenniferPalacios": [
"editor"
],
"Jenniferjkidd": [
"editor"
],
"Jens Østergaard Petersen": [
"editor"
],
"JeremyMcCracken": [
"editor"
],
"Jeroenr": [
"editor"
],
"Jerome Charles Potts": [
"editor"
],
"Jerry vlntn": [
"editor"
],
"Jesdisciple": [
"editor"
],
"Jfmantis": [
"editor"
],
"Jianhui67": [
"global-rollbacker",
"editor"
],
"Jianhui67 public": [
"editor"
],
"Jim Ashby": [
"autoreview"
],
"JimKillock": [
"editor"
],
"Jimbotyson": [
"editor"
],
"Jimmy Xu": [
"vrt-permissions"
],
"Jkauf007": [
"editor"
],
"Jmdeschamps": [
"uploader"
],
"Jnanaranjan sahu": [
"ombuds"
],
"Jnewh001": [
"editor"
],
"Jobin RV": [
"editor"
],
"Joewiz": [
"editor"
],
"Johannes Bo": [
"editor"
],
"Johannnes89": [
"steward"
],
"John Cross": [
"editor"
],
"JohnMarcelo": [
"editor"
],
"Johnkn63": [
"editor"
],
"Johnwhelan": [
"editor"
],
"Jokes Free4Me": [
"editor"
],
"Jomegat": [
"editor"
],
"Jon Harald Søby": [
"vrt-permissions"
],
"Jon Kolbert": [
"steward",
"vrt-permissions"
],
"Jonathan Webley": [
"editor"
],
"Jordan Brown": [
"editor"
],
"JorisvS": [
"editor"
],
"Josve05a": [
"vrt-permissions"
],
"Jrincayc": [
"editor"
],
"Jsnaree": [
"editor"
],
"Jtneill": [
"editor"
],
"JuethoBot": [
"autoreview"
],
"Jugandi": [
"editor"
],
"Jules*": [
"global-renamer"
],
"Juliancolton": [
"global-rollbacker",
"editor"
],
"Jumark27": [
"editor"
],
"JustTheFacts33": [
"editor"
],
"Justlettersandnumbers": [
"global-renamer",
"vrt-permissions"
],
"K6ka": [
"global-rollbacker",
"global-renamer"
],
"Kadı": [
"global-renamer",
"vrt-permissions"
],
"Kai Burghardt": [
"editor"
],
"Kaltenmeyer": [
"editor"
],
"Kambai Akau": [
"editor"
],
"Kanjy": [
"global-rollbacker",
"editor"
],
"Kapooht": [
"editor"
],
"Karl Wick": [
"editor"
],
"Karosent": [
"editor"
],
"Kashkhan": [
"editor"
],
"Kathryn Mary Nicholson": [
"autoreview"
],
"Katiemgeorge": [
"editor"
],
"Katyauchter": [
"editor"
],
"Kaushlendratripathi": [
"editor"
],
"Kaw8yh": [
"editor"
],
"Kayau": [
"transwiki",
"editor"
],
"Kellen": [
"editor"
],
"Kelti": [
"editor"
],
"Kiefer.Wolfowitz": [
"editor"
],
"Killarnee": [
"editor"
],
"King of Hearts": [
"vrt-permissions"
],
"Kingaustin07": [
"editor"
],
"Kingofnuthin": [
"editor"
],
"Kirito": [
"global-rollbacker",
"editor"
],
"Kittycataclysm": [
"sysop"
],
"Kj cheetham": [
"global-renamer"
],
"Kkmurray": [
"editor"
],
"Kl-robertson": [
"editor"
],
"Klaas van Buiten": [
"editor"
],
"Knittedbees": [
"transwiki",
"editor"
],
"Knoppson": [
"autoreview"
],
"Koantum": [
"editor"
],
"Koavf": [
"sysop",
"global-rollbacker"
],
"Kodos": [
"editor"
],
"KonstantinaG07": [
"editor",
"steward"
],
"Kowey": [
"editor"
],
"KrakatoaKatie": [
"vrt-permissions"
],
"Krd": [
"vrt-permissions"
],
"Krdbot": [
"vrt-permissions"
],
"Kri": [
"editor"
],
"Krinkle": [
"global-rollbacker"
],
"Kropotkine 113": [
"vrt-permissions"
],
"Kruusamägi": [
"vrt-permissions"
],
"Ktucker": [
"editor"
],
"Kwamikagami": [
"editor"
],
"Kwhitefoot": [
"editor"
],
"Kylu": [
"editor"
],
"Kızıl": [
"global-renamer"
],
"L10nM4st3r": [
"editor"
],
"LABoyd2": [
"editor"
],
"LR0725": [
"global-rollbacker",
"global-sysop"
],
"Ladislav": [
"editor"
],
"Ladsgroup": [
"global-renamer"
],
"Ladybug62": [
"editor"
],
"Lagoset": [
"editor"
],
"Larsnooden": [
"editor"
],
"Laurianedani": [
"editor"
],
"Lcraw005": [
"editor"
],
"Ldo": [
"editor"
],
"Leaderboard": [
"sysop",
"global-renamer",
"interface-admin"
],
"Learnerktm": [
"editor"
],
"Lechatjaune": [
"vrt-permissions"
],
"Leighblackall": [
"editor"
],
"Lengel46": [
"editor"
],
"Lentokonefani": [
"global-renamer"
],
"LeoChiukl": [
"editor"
],
"Leonard64": [
"uploader"
],
"Leonidlednev": [
"autoreview",
"global-rollbacker"
],
"Leovanderven": [
"editor"
],
"Lesless": [
"vrt-permissions"
],
"Leyo": [
"global-rollbacker"
],
"Lgriot": [
"editor"
],
"Liam987": [
"editor"
],
"Liao": [
"editor"
],
"Libperry": [
"editor"
],
"Limiza": [
"editor"
],
"Lionel Cristiano": [
"editor"
],
"Litlok": [
"global-renamer"
],
"Little Sunshine": [
"global-renamer"
],
"Llakew": [
"editor"
],
"LlamaAl": [
"editor"
],
"Lobsteroh": [
"editor"
],
"LodestarChariot2": [
"editor"
],
"Lofty abyss": [
"global-rollbacker",
"editor",
"vrt-permissions"
],
"Logictheo": [
"editor"
],
"Lomita": [
"vrt-permissions"
],
"Londonjackbooks": [
"editor"
],
"Lovepeacejoy404": [
"editor"
],
"Lp0 on fire": [
"autoreview",
"global-rollbacker"
],
"Lubaochuan": [
"editor"
],
"Luckas Blade": [
"editor"
],
"Lucystewpid": [
"autoreview"
],
"Ludovic Brenta": [
"editor"
],
"Ludovicocaldara": [
"editor",
"uploader"
],
"Lukas²³": [
"editor"
],
"LukeCEL": [
"editor"
],
"Lvova": [
"vrt-permissions"
],
"Lwill031": [
"editor"
],
"M7": [
"steward"
],
"MARKELLOS": [
"vrt-permissions"
],
"MBq": [
"global-renamer"
],
"MF-Warburg": [
"global-rollbacker",
"global-sysop",
"editor"
],
"MGA73": [
"vrt-permissions"
],
"MIacono": [
"editor"
],
"MNeuschaefer": [
"editor"
],
"MS Sakib": [
"global-renamer",
"vrt-permissions"
],
"Mabdul": [
"transwiki",
"editor",
"uploader"
],
"Madisonhen": [
"autoreview"
],
"Magda.dagda": [
"editor"
],
"Magnus Manske": [
"editor"
],
"Mahagaja": [
"editor"
],
"MaikoM93": [
"editor"
],
"Maire": [
"global-renamer"
],
"Malarz pl": [
"global-renamer"
],
"Manchiu": [
"global-renamer"
],
"MandoRachovitsa": [
"autoreview"
],
"Mandy Hopkins": [
"editor"
],
"ManuelGR": [
"editor"
],
"MarcGarver": [
"sysop",
"checkuser",
"steward"
],
"Marco Klunder": [
"editor"
],
"MarcoAurelio": [
"editor"
],
"Marcus Cyron": [
"vrt-permissions"
],
"Mardus": [
"editor"
],
"MarkJFernandes": [
"editor"
],
"MarkTraceur": [
"editor"
],
"Markcwm": [
"editor"
],
"Markhobley": [
"editor"
],
"MarsRover": [
"editor"
],
"Marshman~enwikibooks": [
"editor"
],
"Martin Kraus": [
"editor"
],
"Martin Sauter": [
"editor"
],
"Martin Urbanec": [
"editor",
"steward",
"vrt-permissions"
],
"MartinPoulter": [
"editor"
],
"Martinwguy2": [
"editor"
],
"MarygoldRules": [
"editor"
],
"Master tongue": [
"editor"
],
"Masti": [
"steward",
"vrt-permissions"
],
"Math buff": [
"editor"
],
"MathXplore": [
"global-rollbacker",
"editor"
],
"Mathildem16": [
"autoreview"
],
"Mathmensch": [
"editor"
],
"Mathmensch-Smalledits": [
"editor"
],
"Mathmogeek": [
"editor"
],
"Maths314": [
"editor"
],
"Matiia": [
"editor"
],
"Matrix": [
"autoreview",
"vrt-permissions"
],
"Matsievsky": [
"editor"
],
"Mattb112885": [
"editor"
],
"Mattbarton.exe": [
"editor"
],
"Matttest": [
"autoreview"
],
"Max Milas": [
"editor"
],
"Maxim": [
"editor"
],
"Maximillion Pegasus": [
"global-rollbacker",
"editor"
],
"Maxint2": [
"editor"
],
"Mazbel": [
"global-rollbacker"
],
"Mbch331": [
"vrt-permissions"
],
"Mbrickn": [
"transwiki",
"editor"
],
"Mcdonnkm": [
"editor"
],
"Mcld": [
"editor"
],
"Mdkoch84": [
"editor"
],
"Mdmckenzie": [
"editor"
],
"MdsShakil": [
"steward",
"vrt-permissions"
],
"Mdupont": [
"editor"
],
"Me Lendroz": [
"editor"
],
"Meanmicio": [
"editor"
],
"Mecanismo": [
"editor"
],
"MediaKyle": [
"editor"
],
"Meditation": [
"editor"
],
"Meev0": [
"editor"
],
"Mehman": [
"ombuds",
"vrt-permissions"
],
"Melos": [
"steward",
"vrt-permissions"
],
"MemicznyJanusz": [
"global-renamer"
],
"Mendelivia~enwikibooks": [
"editor"
],
"Meniktah": [
"editor"
],
"Mercy": [
"global-rollbacker",
"editor"
],
"MerlLinkBot": [
"editor"
],
"Mfield": [
"global-renamer"
],
"Mh7kJ": [
"editor"
],
"Michael Romanov": [
"editor"
],
"MichaelFrey": [
"editor"
],
"Michaelbluett": [
"editor",
"uploader"
],
"Mido": [
"vrt-permissions"
],
"MihalOrela": [
"editor"
],
"MiiCii": [
"editor"
],
"Mike Hayes": [
"editor"
],
"Mike.lifeguard": [
"editor"
],
"Mild Bill Hiccup": [
"editor"
],
"Mill3315": [
"editor"
],
"Millbart": [
"vrt-permissions"
],
"Mimarx": [
"editor"
],
"Min1996": [
"autoreview"
],
"Minorax": [
"global-rollbacker",
"global-sysop",
"editor"
],
"Mirinano": [
"global-rollbacker"
],
"Mithridates": [
"editor"
],
"Mjbt": [
"editor"
],
"Mjchael": [
"editor"
],
"Mjkaye": [
"editor"
],
"Mkline": [
"autoreview"
],
"Mlipl001": [
"editor"
],
"Moby-Dick4000": [
"editor"
],
"Mohean": [
"editor"
],
"Money-lover-12345": [
"editor"
],
"Moonriddengirl": [
"autoreview",
"vrt-permissions"
],
"Mortense": [
"editor"
],
"Mpfau": [
"editor"
],
"Mr. Stradivarius": [
"editor"
],
"MrAlanKoh": [
"editor"
],
"MrJaroslavik": [
"global-rollbacker",
"ombuds"
],
"Mrajcok": [
"editor"
],
"Mrjulesd": [
"editor"
],
"Mrwojo": [
"editor"
],
"Mschrag": [
"editor"
],
"Msmithma": [
"editor"
],
"MtPenguinMonster": [
"editor"
],
"Mtarch11": [
"global-rollbacker",
"global-sysop",
"editor"
],
"Musical Inquisit": [
"editor"
],
"Mussklprozz": [
"vrt-permissions"
],
"Mvolz": [
"editor"
],
"Mwtoews": [
"editor"
],
"Mxn": [
"editor"
],
"Myklaw": [
"editor"
],
"Mykola7": [
"steward"
],
"Mys 721tx": [
"global-renamer",
"vrt-permissions"
],
"NDG": [
"global-rollbacker",
"editor"
],
"Nadzik": [
"global-rollbacker",
"global-renamer"
],
"NahidSultan": [
"vrt-permissions"
],
"Nangkhan Magar": [
"editor"
],
"Natuur12": [
"vrt-permissions"
],
"Nbarth": [
"editor"
],
"Nbro": [
"editor"
],
"Nehaoua": [
"ombuds"
],
"Neils51": [
"editor"
],
"Nemoralis": [
"vrt-permissions"
],
"Neojacob": [
"editor"
],
"Neriah": [
"global-rollbacker",
"global-renamer"
],
"Nesbit": [
"editor"
],
"Newlisp": [
"editor"
],
"Nfgdayton": [
"editor"
],
"NguoiDungKhongDinhDanh": [
"global-rollbacker",
"editor"
],
"NhacNy2412": [
"global-renamer"
],
"Nick.anderegg": [
"editor"
],
"NickPenguin": [
"editor"
],
"NicoScribe": [
"editor"
],
"Nicole Sharp": [
"editor"
],
"Nieuwsgierige Gebruiker": [
"editor"
],
"Nigos": [
"autoreview"
],
"Nihonjoe": [
"global-renamer"
],
"Nikai": [
"editor"
],
"Ninjastrikers": [
"vrt-permissions"
],
"NipplesMeCool": [
"editor"
],
"Njardarlogar": [
"editor"
],
"Nobody60": [
"editor"
],
"Nolispanmo": [
"vrt-permissions"
],
"Nomstuff": [
"autoreview"
],
"Nonenmac": [
"editor"
],
"Norton": [
"editor"
],
"Npettiaux": [
"editor"
],
"Nsaa": [
"vrt-permissions"
],
"Nthep": [
"vrt-permissions"
],
"NuclearWarfare": [
"global-rollbacker",
"editor"
],
"OMSMike": [
"editor"
],
"Officer781": [
"editor"
],
"Oleander": [
"editor"
],
"Oliviacatherall": [
"autoreview"
],
"Omphalographer": [
"editor"
],
"OnBeyondZebrax": [
"editor"
],
"Onsen": [
"editor"
],
"Ontzak": [
"global-renamer"
],
"Orderud": [
"editor"
],
"OrenBochman": [
"editor"
],
"Oshwah": [
"global-renamer"
],
"Ottawahitech": [
"editor"
],
"Owain.davies": [
"editor"
],
"PAC": [
"editor"
],
"PAC2": [
"editor"
],
"PK 97": [
"editor"
],
"PNW Raven": [
"editor"
],
"Pac8612": [
"editor"
],
"Paloi Sciurala": [
"global-rollbacker"
],
"Panic2k4": [
"transwiki",
"editor"
],
"Pascal Pignard": [
"editor"
],
"Pastbury": [
"editor"
],
"Pathfinders": [
"editor"
],
"Pathoschild": [
"editor"
],
"Patrik": [
"editor"
],
"PauSix": [
"editor"
],
"Paul James": [
"editor"
],
"Pavroo": [
"editor"
],
"PbakerODU": [
"editor"
],
"Pbrower2a": [
"editor"
],
"Pearts": [
"editor"
],
"Peeragogia": [
"editor"
],
"Peri Coleman": [
"editor"
],
"Perl~enwikibooks": [
"editor"
],
"Peter1180": [
"editor"
],
"PeterEasthope": [
"editor"
],
"Peyton09": [
"editor"
],
"Phan M. Nhat": [
"autoreview"
],
"PhilKnight": [
"global-renamer"
],
"Phoebe": [
"editor"
],
"Phosgram": [
"editor"
],
"Pi zero": [
"editor"
],
"PieWriter": [
"editor"
],
"Piotrus": [
"editor"
],
"Pithikos": [
"editor"
],
"Pittsburgh Poet": [
"editor"
],
"Pjpearce": [
"editor"
],
"Pkkao": [
"editor"
],
"Planotse": [
"editor"
],
"Platonides": [
"vrt-permissions"
],
"Pluke": [
"editor"
],
"PlyrStar93": [
"global-rollbacker",
"editor"
],
"Pminh141": [
"global-renamer"
],
"Pmlineditor": [
"editor"
],
"Pmw57": [
"editor"
],
"Poetcsw": [
"editor"
],
"PoizonMyst": [
"editor"
],
"Pola 2607": [
"autoreview"
],
"Polimerek": [
"vrt-permissions"
],
"Polluks": [
"editor"
],
"Pookiyama": [
"editor"
],
"Popski": [
"editor"
],
"Povigna": [
"editor"
],
"Ppolar bear": [
"global-rollbacker",
"global-renamer"
],
"Pppery": [
"autoreview"
],
"Prahlad balaji": [
"editor"
],
"Pratyeka": [
"editor"
],
"Praxidicae": [
"global-rollbacker",
"global-sysop",
"editor"
],
"Primefac": [
"vrt-permissions"
],
"Prince Kassad~enwikibooks": [
"editor"
],
"Pronesto": [
"editor"
],
"Prototyperspective": [
"autoreview"
],
"Psoup": [
"editor"
],
"Psr1909": [
"editor"
],
"PullUpYourSocks": [
"editor"
],
"PurpleBuffalo": [
"global-renamer"
],
"PurplePieman": [
"editor"
],
"Purplebackpack89": [
"editor"
],
"Putukas01": [
"editor"
],
"Qenalcu": [
"autoreview"
],
"Quebecguy": [
"global-rollbacker"
],
"QueerEcofeminist": [
"global-rollbacker",
"global-renamer",
"editor"
],
"Quinlan83": [
"global-rollbacker",
"editor"
],
"Quintucket": [
"editor"
],
"Qwerty number1": [
"editor"
],
"Qwertyus": [
"editor"
],
"Qədir": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"R. Henrik Nilsson": [
"editor"
],
"RAdimer-WMF": [
"global-rollbacker"
],
"RDBury": [
"editor"
],
"RJHall": [
"editor"
],
"Ra'ike": [
"vrt-permissions"
],
"Rachboots": [
"editor"
],
"Rachel": [
"editor"
],
"Rachmat04": [
"global-renamer",
"vrt-permissions"
],
"RadiX": [
"editor",
"steward",
"vrt-permissions"
],
"Raffaela Kunz": [
"editor"
],
"Rahulkepapa": [
"editor"
],
"Ramac": [
"editor"
],
"Rambam rashi": [
"editor"
],
"Randykitty": [
"autoreview",
"global-rollbacker"
],
"RatónMístico176": [
"editor"
],
"Ravichandar84": [
"editor"
],
"Rawheatley": [
"editor"
],
"Ray Trygstad": [
"editor"
],
"RayeChellMahela": [
"editor"
],
"Raymond": [
"vrt-permissions"
],
"Razr Nation": [
"editor"
],
"Rchaswms01": [
"editor"
],
"Rcragun": [
"editor",
"uploader"
],
"Readyokaygo": [
"editor"
],
"Recent Runes": [
"editor"
],
"Redlentil": [
"editor"
],
"Refcanimm": [
"editor"
],
"Regasterios": [
"vrt-permissions"
],
"Reinhard Kraasch": [
"vrt-permissions"
],
"RenaissanceMan2144": [
"autoreview"
],
"Renamed user 242094acfb1a5b2f08e9e78f2e021a40": [
"editor"
],
"Renamed user 5f91ca71739b07cfce8397eed758fe13": [
"editor",
"uploader"
],
"Renamed user f26394dcb19bd7bdad78f0d752896653": [
"editor"
],
"Renvoy": [
"global-rollbacker",
"global-sysop"
],
"Reseletti": [
"editor"
],
"Retropunk": [
"editor"
],
"Reuben1508": [
"autoreview"
],
"Revi C.": [
"global-rollbacker",
"global-renamer",
"ombuds",
"editor",
"vrt-permissions"
],
"Reyk": [
"editor"
],
"Rfc1394": [
"editor"
],
"Rgdboer": [
"editor"
],
"Rgreenone": [
"editor"
],
"Rhole2001": [
"autoreview"
],
"Rich Farmbrough": [
"editor"
],
"Rickstambaugh": [
"editor"
],
"Riggwelter": [
"vrt-permissions"
],
"Risk": [
"editor"
],
"Risteall": [
"editor"
],
"Ritjesman": [
"editor"
],
"RoMancer": [
"editor"
],
"Robbiemorrison": [
"editor"
],
"Robert Huber~enwikibooks": [
"editor"
],
"Roberto Mura": [
"editor"
],
"Robertsky": [
"global-renamer",
"vrt-permissions"
],
"RobinH": [
"editor"
],
"Rodasmith": [
"editor"
],
"Rodrigo": [
"editor"
],
"Rodrigo.Argenton": [
"vrt-permissions"
],
"Rogerborrell": [
"editor"
],
"Rogerdpack": [
"editor"
],
"RogueScholar": [
"editor"
],
"Romainbehar": [
"editor"
],
"RomaineBot": [
"vrt-permissions"
],
"RonaldB": [
"vrt-permissions"
],
"Rosser1954": [
"editor"
],
"Rotlink": [
"editor"
],
"RoySmith": [
"ombuds"
],
"Rozzychan": [
"editor"
],
"Rplano": [
"editor"
],
"Rreagan007": [
"autoreview"
],
"Rrgreen": [
"editor"
],
"Rschen7754": [
"global-rollbacker",
"editor"
],
"RshieldsVA": [
"editor"
],
"Rsjaffe": [
"global-renamer"
],
"Rtaisis": [
"editor"
],
"Ruakh": [
"editor"
],
"Rudolpho~enwikibooks": [
"editor"
],
"Runfellow": [
"editor"
],
"Runner4lyfe": [
"editor"
],
"RunningBlind": [
"editor"
],
"Ruthven": [
"vrt-permissions"
],
"Ruud Koot": [
"transwiki",
"editor"
],
"Rzuwig": [
"autoreview",
"global-rollbacker"
],
"S8321414": [
"global-renamer"
],
"SB Johnny": [
"editor"
],
"SCP-2000": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"SHB2000": [
"sysop",
"steward"
],
"SPM": [
"editor"
],
"Sae1962": [
"editor"
],
"Safuan12616": [
"editor"
],
"SahniM": [
"editor"
],
"Sakretsu": [
"steward"
],
"Sakura emad": [
"global-rollbacker"
],
"Salil Kumar Mukherjee": [
"editor"
],
"Samat": [
"vrt-permissions"
],
"Sammy2012": [
"editor"
],
"Samuel.dellit": [
"editor"
],
"Samuele2002": [
"global-rollbacker",
"editor"
],
"Samwilson": [
"editor"
],
"SanBonne": [
"global-renamer",
"vrt-permissions"
],
"Sandbergja": [
"editor"
],
"Sannita": [
"vrt-permissions"
],
"Sante Caserio~enwikibooks": [
"editor"
],
"SarahFatimaK": [
"editor"
],
"Sargoth": [
"vrt-permissions"
],
"Saroj": [
"global-rollbacker"
],
"Sascha Lill 95": [
"editor"
],
"Satdeep Gill": [
"vrt-permissions"
],
"Savh": [
"global-rollbacker",
"editor"
],
"Sbb1413": [
"editor"
],
"Scention": [
"editor"
],
"Schniggendiller": [
"steward"
],
"SchreiberBike": [
"editor"
],
"Scott.beckman": [
"editor"
],
"Sebastian Wallroth": [
"vrt-permissions"
],
"Seewolf": [
"global-rollbacker",
"vrt-permissions"
],
"Sekidoki": [
"vrt-permissions"
],
"Selden": [
"editor"
],
"Sennecaster": [
"vrt-permissions"
],
"Serinap": [
"editor"
],
"Seth Miller": [
"editor"
],
"SevenSpheres": [
"editor"
],
"Sfan00 IMG": [
"editor"
],
"Sfoerster": [
"editor"
],
"Sgarrigan": [
"editor"
],
"Sgowal": [
"editor"
],
"Shaitand": [
"editor"
],
"ShakespeareFan00": [
"editor"
],
"SharingNotes": [
"editor"
],
"Shawntanchinyang": [
"editor"
],
"Shdwninja8": [
"editor"
],
"ShelleyAdams": [
"autoreview"
],
"ShifaYT": [
"global-rollbacker"
],
"Shii": [
"editor"
],
"Shira the Mogul": [
"editor"
],
"Shlomif": [
"editor"
],
"ShuBraque": [
"editor"
],
"Sidelight12": [
"editor"
],
"Sidorkin": [
"editor"
],
"Sidpatil": [
"editor"
],
"Siebengang": [
"editor"
],
"Sigma 7": [
"editor"
],
"Simon Peter Hughes": [
"editor"
],
"Sinus46": [
"editor"
],
"Sir Beluga": [
"editor"
],
"Sir Lestaty de Lioncourt": [
"vrt-permissions"
],
"SixWingedSeraph": [
"editor"
],
"Sj": [
"editor"
],
"Sjc~enwikibooks": [
"editor"
],
"Sjlegg": [
"editor"
],
"Sjone101": [
"editor"
],
"Sjö": [
"global-rollbacker"
],
"Skymath": [
"editor"
],
"Slava Ukraini Heroyam Slava 123": [
"editor",
"uploader"
],
"Slava Ukrajini Heroyam Slava": [
"editor"
],
"Sluffs": [
"editor"
],
"Smjg": [
"editor"
],
"SnappyDragonPennyroyal": [
"editor"
],
"SocialKnowledge": [
"editor"
],
"SoftwareEngineerMoose": [
"autoreview"
],
"Sonia": [
"editor"
],
"Sophie Cheng": [
"editor"
],
"Sotiale": [
"steward"
],
"Soul windsurfer": [
"editor"
],
"SouthParkFan65": [
"editor"
],
"SoylentGreen": [
"editor"
],
"Spamduck": [
"editor"
],
"Spaynton": [
"editor"
],
"Spender2001": [
"editor"
],
"Speregrination": [
"editor"
],
"Spiderworm": [
"editor"
],
"Spoon!": [
"editor"
],
"Squasher": [
"global-renamer"
],
"Srhat": [
"editor"
],
"Stang": [
"global-rollbacker",
"editor",
"vrt-permissions"
],
"Stanglavine": [
"editor"
],
"Steinsplitter": [
"global-renamer",
"vrt-permissions"
],
"StephT0704": [
"autoreview"
],
"Stepheng3": [
"editor"
],
"Stepro": [
"vrt-permissions"
],
"Steve M": [
"editor"
],
"Stilfehler": [
"editor"
],
"Stockywood": [
"editor"
],
"Storeye": [
"editor"
],
"Strainu": [
"vrt-permissions"
],
"Strange quark": [
"editor"
],
"Stryn": [
"global-rollbacker",
"editor"
],
"Stïnger": [
"global-rollbacker",
"editor"
],
"Suchenwi": [
"editor"
],
"Sumone10154": [
"editor"
],
"SunCreator": [
"editor"
],
"Sunny Cryolite": [
"global-rollbacker"
],
"Sunshineconnelly": [
"editor"
],
"SuperTyphoonNoru": [
"editor"
],
"Superbass": [
"vrt-permissions"
],
"Superpes15": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"vrt-permissions"
],
"Supertoff": [
"vrt-permissions"
],
"Superzerocool": [
"vrt-permissions"
],
"SupremeUmanu": [
"editor"
],
"Suruena": [
"editor"
],
"Sutambe": [
"editor"
],
"Sutton Publishing": [
"editor"
],
"Sué González Hauck": [
"editor"
],
"Svartava": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor"
],
"SweetCanadianMullet": [
"editor"
],
"Swift": [
"editor"
],
"SyG": [
"editor"
],
"Sylvesterchukwu04": [
"editor"
],
"Sylvialim": [
"editor"
],
"Sylviaread": [
"editor"
],
"Synoman Barris": [
"global-rollbacker",
"transwiki",
"editor"
],
"Syum90": [
"global-rollbacker",
"editor"
],
"Syunsyunminmin": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor"
],
"T.seppelt": [
"editor"
],
"TDang": [
"editor"
],
"TTWIDEE": [
"editor"
],
"Tahmid": [
"editor"
],
"Taketa": [
"global-renamer"
],
"Takipoint123": [
"vrt-permissions"
],
"TakuyaMurata": [
"editor"
],
"Tamzin": [
"global-renamer"
],
"Tanbiruzzaman": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor",
"vrt-permissions"
],
"Tannertsf": [
"editor"
],
"Taoheedah": [
"editor"
],
"Tapsevarg": [
"editor"
],
"TaronjaSatsuma": [
"vrt-permissions"
],
"Taxman": [
"editor"
],
"Tchoř": [
"global-renamer"
],
"Tdkehoe": [
"editor"
],
"Tdvorak": [
"editor"
],
"Techman224": [
"editor"
],
"Tegel": [
"editor",
"steward"
],
"Teles": [
"ombuds",
"steward",
"vrt-permissions"
],
"Tem5psu": [
"editor"
],
"Tempodivalse": [
"editor"
],
"TenWhile6": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor"
],
"Tenshi Hinanawi": [
"autoreview",
"global-rollbacker"
],
"Terence Kearey": [
"editor"
],
"Ternarius": [
"global-renamer"
],
"Ternera": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor"
],
"Tesleemah": [
"editor"
],
"Tevfik AKTUĞLU": [
"editor"
],
"Tgregtregretgtr": [
"editor"
],
"ThatBPengineer": [
"autoreview"
],
"Thatonewikiguy": [
"editor"
],
"The Squirrel Conspiracy": [
"vrt-permissions"
],
"The labs": [
"editor"
],
"TheGoodEndedHappily": [
"vrt-permissions"
],
"ThePCKid": [
"editor"
],
"TheSandDoctor": [
"global-renamer",
"vrt-permissions"
],
"Theknightwho": [
"editor"
],
"Thenub314": [
"editor"
],
"Theo Hughes": [
"editor"
],
"Theornamentalist": [
"editor"
],
"Thereen": [
"editor"
],
"Thewinster": [
"editor"
],
"Thierry Dugnolle": [
"editor"
],
"Thinkglobalnow": [
"editor"
],
"Thirunavukkarasye-Raveendran": [
"editor"
],
"Thomas Simpson": [
"editor"
],
"Thomas.haslwanter": [
"editor"
],
"Thomas.lochmatter": [
"editor"
],
"Tibetologist": [
"editor"
],
"Tigerzeng": [
"global-rollbacker"
],
"Tiled": [
"editor"
],
"TimBorgNetzWerk": [
"editor"
],
"Timothy Gu": [
"editor"
],
"Timpo": [
"editor"
],
"Tiptoety": [
"editor"
],
"Tjyang": [
"editor"
],
"Tlustulimu": [
"editor"
],
"Tmvogel": [
"editor"
],
"Tom Morris": [
"editor"
],
"Tomato86": [
"editor"
],
"Tomt87": [
"editor"
],
"Tomybrz": [
"editor"
],
"Tonyvall": [
"autoreview"
],
"Tp42": [
"editor"
],
"Tracklayingninja": [
"editor"
],
"Tradimus": [
"editor"
],
"Tropicalkitty": [
"global-rollbacker",
"editor"
],
"TrulyShruti": [
"editor"
],
"Ts12rAc": [
"global-rollbacker"
],
"Tsarina CatarinaToo": [
"autoreview"
],
"TunnelESON": [
"sysop"
],
"Turbojet": [
"vrt-permissions"
],
"Turkmen": [
"editor"
],
"TwoThirty": [
"editor"
],
"Tyoyafud": [
"editor"
],
"Túrelio": [
"autoreview"
],
"U$3rname008": [
"editor"
],
"USSR-Slav": [
"global-rollbacker"
],
"Uf.hun2201": [
"editor"
],
"Ulubatli Hasan": [
"global-renamer"
],
"Uncitoyen": [
"global-rollbacker",
"global-renamer"
],
"Uncle G": [
"editor"
],
"Unixxx": [
"editor"
],
"User01938": [
"editor"
],
"Username222": [
"editor"
],
"Utcursch": [
"vrt-permissions"
],
"Uziel302": [
"editor"
],
"Uzume": [
"editor"
],
"V0lkanic": [
"global-renamer"
],
"VIGNERON": [
"steward"
],
"Valery Starikov": [
"editor"
],
"Van der Hoorn": [
"editor"
],
"Varnent": [
"vrt-permissions"
],
"Vdolar": [
"autoreview"
],
"VectorVoyager": [
"editor"
],
"Venzz": [
"vrt-permissions"
],
"Verfassungsfreund": [
"editor"
],
"Veritas Sapientiae": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"Vermont": [
"editor",
"steward",
"vrt-permissions"
],
"Victor Stefan Stoica": [
"autoreview"
],
"Victor Trevor": [
"autoreview"
],
"Victoria.sandeman": [
"autoreview"
],
"Vincent Vega": [
"global-renamer"
],
"Vito Genovese": [
"editor"
],
"Vituzzu": [
"editor"
],
"Vladimir Solovjev": [
"global-renamer",
"vrt-permissions"
],
"Vogone": [
"global-rollbacker",
"editor"
],
"Vossman": [
"editor"
],
"Vrinda": [
"editor"
],
"VulcanWikiEdit": [
"editor"
],
"Vwanweb": [
"editor"
],
"WOSlinker": [
"autoreview"
],
"Waihorace": [
"global-rollbacker"
],
"Waldyrious": [
"editor"
],
"WalshDay": [
"editor"
],
"Wargo": [
"editor"
],
"Wbjimmyd": [
"editor"
],
"Wcoole": [
"editor"
],
"WeelkyWikiReader": [
"editor"
],
"Wekeepwhatwekill": [
"autoreview"
],
"WereSpielChequers": [
"editor"
],
"What no2000": [
"editor"
],
"WhatamIdoing": [
"editor"
],
"WhitePhosphorus": [
"global-rollbacker",
"global-sysop"
],
"Whiteknight": [
"editor"
],
"Whoop whoop pull up": [
"editor"
],
"Whym": [
"editor",
"vrt-permissions"
],
"Wiki13": [
"editor"
],
"WikiBayer": [
"global-rollbacker",
"global-sysop",
"editor"
],
"WikiFer": [
"vrt-permissions"
],
"Wikimi-dhiann": [
"editor"
],
"Wikiotics": [
"editor"
],
"Wikiwau": [
"autoreview",
"editor"
],
"WillNess": [
"editor"
],
"Willscrlt": [
"editor"
],
"Wim b": [
"global-rollbacker",
"global-sysop",
"editor"
],
"Wisden": [
"editor"
],
"Withinfocus": [
"editor"
],
"Wj32": [
"editor"
],
"Wkee4ager": [
"editor"
],
"Wobbit": [
"editor"
],
"Wojciech Pędzich": [
"vrt-permissions"
],
"Wong128hk": [
"global-renamer"
],
"Wooze": [
"global-rollbacker"
],
"Wundermacht": [
"editor"
],
"Wutsje": [
"global-rollbacker",
"editor"
],
"Ww2censor": [
"vrt-permissions"
],
"Wüstenspringmaus": [
"global-rollbacker",
"global-renamer"
],
"XXBlackburnXx": [
"editor",
"steward"
],
"Xandradi": [
"editor"
],
"Xania": [
"sysop",
"checkuser"
],
"Xaosflux": [
"editor",
"steward"
],
"XenonX3": [
"vrt-permissions"
],
"Xerol": [
"editor"
],
"Xeverything11": [
"editor",
"uploader"
],
"Xhungab": [
"editor"
],
"Xinkai Wu": [
"editor"
],
"Xixtas": [
"editor"
],
"Xqt": [
"global-rollbacker"
],
"Xxagile": [
"editor"
],
"Xypron": [
"editor"
],
"Xz64": [
"editor"
],
"Y-S.Ko": [
"editor"
],
"YMS": [
"editor"
],
"Yahya": [
"steward",
"vrt-permissions"
],
"Yamla": [
"global-renamer"
],
"Yann": [
"editor"
],
"Yerpo": [
"global-renamer",
"vrt-permissions"
],
"Yikrazuul": [
"editor"
],
"Ymblanter": [
"global-rollbacker"
],
"Yndesai": [
"editor"
],
"Youssefsan": [
"editor"
],
"Ysangkok": [
"editor"
],
"Yvelik": [
"uploader"
],
"Yzmo": [
"editor"
],
"ZI Jony": [
"editor"
],
"Zabe": [
"global-rollbacker"
],
"Zafer": [
"ombuds"
],
"Zedshort": [
"editor"
],
"ZeroOne": [
"editor"
],
"Zetud": [
"global-rollbacker",
"vrt-permissions"
],
"Ziv": [
"editor"
],
"Zoeannl": [
"editor"
],
"Zollerriia": [
"editor"
],
"Zoohouse": [
"editor"
],
"Zoot": [
"editor"
],
"Zsohl": [
"autoreview",
"editor"
],
"Zvsmith": [
"editor"
],
"Zweighaft": [
"editor"
],
"ZxxZxxZ": [
"editor"
],
"~riley": [
"global-rollbacker",
"editor"
],
"Érico": [
"global-renamer"
],
"Виктор Пинчук": [
"editor"
],
"Воображение": [
"editor"
],
"Всевидящий": [
"global-rollbacker"
],
"Д.Ильин": [
"editor"
],
"Л.П. Джепко": [
"editor"
],
"יהודה שמחה ולדמן": [
"editor"
],
"מקף": [
"global-rollbacker",
"global-renamer"
],
"د. فارس الجويلي": [
"global-renamer"
],
"روتانا": [
"global-renamer"
],
"علاء": [
"steward",
"vrt-permissions"
],
"فيصل": [
"global-renamer",
"vrt-permissions"
],
"सीमा1": [
"editor"
],
"タチコマ robot": [
"editor"
],
"ネイ": [
"global-renamer"
],
"一隻北極熊": [
"editor"
],
"人间百态": [
"global-rollbacker"
],
"臺灣象象": [
"autoreview"
],
"范": [
"vrt-permissions"
],
"青子守歌": [
"vrt-permissions"
],
"魔琴": [
"global-rollbacker"
],
"ꠢꠣꠍꠘ ꠞꠣꠎꠣ": [
"editor"
],
"기나ㅏㄴ": [
"global-rollbacker",
"global-renamer"
]
}
jhlkp1xbd80iq9fo6wpc7g9odx1ndwi
4655957
4655950
2026-07-31T17:49:12Z
JJPMaster (bot)
3488561
Bot: Updating markAdmins data
4655957
json
application/json
{
".snoopy.": [
"global-rollbacker",
"editor"
],
"1234qwer1234qwer4": [
"editor",
"steward"
],
"157yagz5r48a5f1a1f": [
"editor"
],
"1997kB": [
"global-rollbacker",
"global-renamer",
"editor"
],
"1F616EMO": [
"global-renamer"
],
"1exec1": [
"transwiki",
"editor"
],
"1sfoerster": [
"editor"
],
"20041027 tatsu": [
"global-rollbacker"
],
"2005-Fan": [
"transwiki",
"editor",
"uploader"
],
"331dot": [
"global-renamer"
],
"33rogers": [
"editor"
],
"3MMPEYTON": [
"editor"
],
"4PlayerChess": [
"autoreview"
],
"4pillars": [
"editor"
],
"511KeV": [
"global-rollbacker"
],
"94rain": [
"global-rollbacker",
"editor"
],
"A R King": [
"editor"
],
"A Sulaiman Z": [
"editor"
],
"A.K.Karthikeyan": [
"editor"
],
"A09": [
"steward"
],
"AFBorchert": [
"vrt-permissions"
],
"AIProf": [
"editor"
],
"ALittleSlow": [
"autoreview"
],
"AManWithNoPlan": [
"editor"
],
"ATannedBurger": [
"global-renamer"
],
"AVRS": [
"editor"
],
"Aafi": [
"vrt-permissions"
],
"Abenwagner": [
"editor"
],
"Abigor": [
"editor"
],
"Abitt002": [
"editor"
],
"Abyssal": [
"editor"
],
"Acagastya": [
"autoreview"
],
"Acalamari": [
"global-renamer"
],
"Acarologiste": [
"editor"
],
"AcidBat": [
"editor"
],
"Acrow005": [
"editor"
],
"Actualist": [
"editor"
],
"Adalvis": [
"editor"
],
"Adart001": [
"editor"
],
"Adavyd": [
"global-renamer"
],
"Addihockey10": [
"editor"
],
"Addihockey10 (automated)": [
"editor"
],
"Adrignola": [
"editor"
],
"AdventureWriter": [
"editor"
],
"Aelxen": [
"global-renamer"
],
"Aferg006": [
"editor"
],
"Afett001": [
"editor"
],
"Affe2011": [
"global-rollbacker"
],
"Agnerf": [
"editor",
"uploader"
],
"Agpires": [
"editor"
],
"Agricola": [
"editor"
],
"Agusbou2015": [
"editor"
],
"Ah3kal": [
"editor"
],
"Ahecht": [
"global-renamer",
"vrt-permissions"
],
"Ahonc": [
"global-renamer",
"vrt-permissions"
],
"AiClassEland": [
"editor"
],
"Ainz Ooal Gown": [
"editor"
],
"Airpmb": [
"editor"
],
"Ajraddatz": [
"editor",
"steward"
],
"Aka": [
"vrt-permissions"
],
"Alanah.97": [
"autoreview"
],
"Albertoleoncio": [
"steward",
"vrt-permissions"
],
"Albmont": [
"editor"
],
"Alchimista": [
"vrt-permissions"
],
"Aldnonymous": [
"editor"
],
"Aledownload": [
"editor"
],
"Alexlatham96": [
"editor"
],
"Alextejthompson": [
"editor"
],
"Alison": [
"global-rollbacker"
],
"AllenZh": [
"editor"
],
"Alphama": [
"global-renamer"
],
"AlvaroMolina": [
"editor"
],
"AmandaNP": [
"steward"
],
"Ambrevar": [
"editor"
],
"Amcgail": [
"editor"
],
"Ameisenigel": [
"global-rollbacker",
"global-sysop",
"ombuds",
"editor",
"vrt-permissions"
],
"AmieKim": [
"editor"
],
"Amire80": [
"global-sysop"
],
"Anachronist": [
"editor",
"vrt-permissions"
],
"Ancient9983": [
"editor"
],
"Andrei Stroe": [
"vrt-permissions"
],
"Andrew janke": [
"editor"
],
"Andriy.v": [
"vrt-permissions"
],
"Andyross": [
"editor"
],
"Anil Shaligram": [
"editor"
],
"Animajosser": [
"editor"
],
"Anne Correia": [
"editor"
],
"Anonim Şahıs": [
"editor"
],
"Anonymity": [
"editor"
],
"AnotherEditor144": [
"autoreview"
],
"Antanana": [
"vrt-permissions"
],
"Antandrus": [
"editor"
],
"Anthere": [
"editor"
],
"AntiCompositeNumber": [
"steward",
"vrt-permissions"
],
"Antonizoon": [
"editor"
],
"Antonw": [
"editor"
],
"Apfelmus": [
"editor"
],
"Aphoneyclimber": [
"editor"
],
"Apocheir": [
"editor"
],
"Aqurs1": [
"global-rollbacker",
"global-renamer",
"global-sysop"
],
"AramilFeraxa": [
"steward"
],
"Arch dude": [
"editor"
],
"Archolman": [
"editor"
],
"Arcticocean": [
"ombuds"
],
"ArdentPerf": [
"editor",
"uploader"
],
"Arlen22": [
"transwiki",
"editor"
],
"Armchair": [
"editor"
],
"Arno-nl": [
"editor"
],
"Arrow303": [
"vrt-permissions"
],
"Arthurvogel": [
"editor"
],
"Artoria2e5": [
"editor"
],
"Arturoiochoam": [
"editor"
],
"Arunreginald": [
"editor"
],
"AshLin": [
"editor"
],
"Atcovi": [
"sysop",
"global-rollbacker"
],
"Athrash": [
"editor"
],
"Atiedebee": [
"editor"
],
"Atlas.Spheres": [
"editor"
],
"Atsme": [
"vrt-permissions"
],
"Auremel": [
"editor"
],
"Austncorp": [
"editor"
],
"AuthorsAndContributorsBot": [
"autoreview"
],
"Avicennasis": [
"editor"
],
"Avraham": [
"global-renamer",
"editor"
],
"Awesome Princess": [
"editor"
],
"Axpde": [
"editor"
],
"Az1568": [
"global-rollbacker"
],
"Az2008": [
"editor"
],
"Azotochtli": [
"editor"
],
"B.Korlah": [
"editor"
],
"BD2412": [
"editor"
],
"BORGATO Pierandrea": [
"editor"
],
"BRPever": [
"global-rollbacker",
"global-sysop"
],
"BRUTE": [
"editor"
],
"Backfromquadrangle": [
"editor"
],
"Baiji": [
"global-rollbacker"
],
"Bakasakali": [
"editor"
],
"Balaji.md au": [
"editor"
],
"BarkingFish": [
"editor"
],
"Barras": [
"steward"
],
"Base": [
"steward",
"vrt-permissions"
],
"Bastique": [
"editor"
],
"Bautsch": [
"editor"
],
"BeardMD": [
"editor"
],
"Beetstra": [
"global-rollbacker"
],
"BenTels": [
"editor"
],
"Bencemac": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"Benjamin J. Burger": [
"editor"
],
"Benjamin.doe": [
"editor"
],
"Benrattray": [
"editor"
],
"Benson Muite": [
"editor"
],
"Bentbracke": [
"editor"
],
"Bequw": [
"editor"
],
"Bert Niehaus": [
"autoreview"
],
"BethNaught": [
"editor"
],
"Beuc": [
"editor"
],
"Bhardwaj Anil": [
"autoreview"
],
"BiT": [
"editor"
],
"Bigdelboy": [
"transwiki"
],
"Bignose~enwikibooks": [
"editor"
],
"Billinghurst": [
"global-rollbacker",
"editor"
],
"Billymac00": [
"editor"
],
"Biplab Anand": [
"global-rollbacker",
"global-sysop"
],
"Birdofadozentides": [
"editor"
],
"BitterAsianMan": [
"editor"
],
"Bluefoxicy": [
"editor"
],
"Bluerasberry": [
"vrt-permissions"
],
"BobChan2": [
"editor"
],
"Bodhisattwa": [
"vrt-permissions"
],
"BoldLuis": [
"editor"
],
"Borhan": [
"global-rollbacker",
"vrt-permissions"
],
"Boris1951zz": [
"editor"
],
"Bpenn005": [
"editor"
],
"Brewster239": [
"global-rollbacker"
],
"Bridget": [
"global-rollbacker",
"editor"
],
"Brienna.Hall77": [
"editor"
],
"Brim": [
"editor"
],
"Brittanys": [
"editor"
],
"Bronwynh": [
"editor"
],
"Bsadowski1": [
"editor",
"steward"
],
"Buddpaul": [
"editor"
],
"Bullercruz1": [
"editor"
],
"Buncic": [
"editor"
],
"Bunnypranav": [
"global-renamer"
],
"BurakD53": [
"editor"
],
"Burkep": [
"editor"
],
"ByGrace": [
"editor"
],
"Bykim2012": [
"editor"
],
"C1203sc": [
"editor"
],
"CJakes1": [
"editor"
],
"CKWG - Ada Magica": [
"editor"
],
"Cabayi": [
"global-renamer"
],
"CaitlinCarbury": [
"autoreview"
],
"CalciumTetraoxide": [
"editor"
],
"CalendulaAsteraceae": [
"editor"
],
"Caliburn": [
"editor"
],
"CallumPoole": [
"editor"
],
"Calvin.Andrus": [
"editor"
],
"Cameron11598": [
"editor"
],
"Camouflaged Mirage": [
"editor"
],
"Captain-tucker": [
"vrt-permissions"
],
"Carlo.milanesi": [
"editor"
],
"Caro de Segeda": [
"editor"
],
"CarsracBot": [
"editor"
],
"Catermark": [
"editor"
],
"Cecila123": [
"autoreview"
],
"Cedar101": [
"editor"
],
"Champion": [
"editor"
],
"Chaojidage": [
"editor"
],
"Chaojoker": [
"editor"
],
"Chaotic Enby": [
"autoreview",
"global-renamer"
],
"Chapka": [
"editor"
],
"Charidri": [
"editor"
],
"Charleneabeana": [
"autoreview"
],
"Charles Jeffrey Danoff": [
"editor"
],
"CharlesHoffman": [
"editor"
],
"Chazz": [
"editor"
],
"Chelseafan528": [
"editor"
],
"Cheryl2012": [
"editor"
],
"Chescargot": [
"vrt-permissions"
],
"Chi Sigma": [
"editor"
],
"Chinmayee Mishra": [
"ombuds"
],
"Chongkian": [
"editor"
],
"Chowbok": [
"editor"
],
"ChrisHodgesUK": [
"editor"
],
"ChrisWallace": [
"editor"
],
"Chriswaterguy": [
"editor"
],
"Chuckhoffmann": [
"editor"
],
"Church of emacs": [
"global-rollbacker"
],
"Cic": [
"editor"
],
"Ciell": [
"vrt-permissions"
],
"Cilantrohead": [
"editor"
],
"Cintilo": [
"editor"
],
"Circuit dreamer": [
"editor"
],
"Circuit-fantasist": [
"editor"
],
"Civvì": [
"global-rollbacker",
"global-renamer"
],
"Ckwalker": [
"editor"
],
"Clairerusselll": [
"autoreview"
],
"Cloidl": [
"autoreview"
],
"Cmsmcq": [
"editor"
],
"Cnrowley": [
"editor"
],
"CocoaZen": [
"editor"
],
"CoconutOctopus": [
"global-renamer"
],
"Codename Noreste": [
"sysop",
"global-rollbacker",
"interface-admin"
],
"Codename Noroeste": [
"editor"
],
"Codinghead": [
"editor"
],
"CommonsDelinker": [
"autoreview"
],
"Comp.arch": [
"editor"
],
"Conan": [
"editor"
],
"Cormullion": [
"editor"
],
"Count Count": [
"steward"
],
"Coupe": [
"editor"
],
"Courcelles": [
"global-rollbacker",
"editor"
],
"CptViraj": [
"global-rollbacker",
"global-renamer",
"global-sysop"
],
"Craignewland": [
"editor"
],
"Craxd1": [
"editor"
],
"CrazyEddy": [
"editor"
],
"Cremastra": [
"editor"
],
"Cremastra (JWB)": [
"autoreview"
],
"Cromium": [
"editor"
],
"Cromwellt": [
"editor"
],
"Crystal East": [
"editor"
],
"Cttcraig": [
"editor"
],
"Cultures17": [
"editor"
],
"Cultures33": [
"editor"
],
"Cultures4": [
"editor"
],
"Cultures92": [
"editor"
],
"CunninghamJohn": [
"autoreview"
],
"Curtaintoad": [
"editor"
],
"Cyberpower678": [
"global-rollbacker"
],
"Céréales Killer": [
"global-renamer"
],
"D1n05aur5 4ever": [
"editor"
],
"DARIO SEVERI": [
"autoreview",
"global-rollbacker",
"global-sysop"
],
"DC Slagel": [
"editor"
],
"DCB": [
"vrt-permissions"
],
"DD 8630": [
"editor"
],
"DGerman": [
"editor"
],
"DVD206": [
"editor"
],
"DZadventiste": [
"editor"
],
"DaB.": [
"vrt-permissions"
],
"DaGizza": [
"editor"
],
"Dagana4": [
"autoreview"
],
"Dallas1278": [
"editor"
],
"Dan Koehl": [
"editor"
],
"Dan Polansky": [
"editor"
],
"Dan-aka-jack": [
"editor"
],
"DanCherek": [
"autoreview"
],
"Danarwaller": [
"editor"
],
"DanielWhernchend": [
"editor"
],
"Danielravennest": [
"editor"
],
"Danilka5469": [
"editor"
],
"Daniuu": [
"steward",
"vrt-permissions"
],
"DannyS712": [
"editor"
],
"Darklama": [
"editor"
],
"Darklilac": [
"editor"
],
"Darrelljon": [
"editor"
],
"DarwIn": [
"vrt-permissions"
],
"Dave Braunschweig": [
"editor"
],
"David L Davis": [
"editor"
],
"DavidCary": [
"editor"
],
"DavidLevinson": [
"editor"
],
"Davidbena": [
"editor"
],
"Dayshade": [
"editor"
],
"Dchmelik": [
"editor"
],
"Dcljr": [
"editor"
],
"Dcondon": [
"editor"
],
"Deepfriedokra": [
"global-renamer"
],
"DejaVu": [
"global-rollbacker"
],
"DennisDaniels": [
"editor"
],
"Dennisblu": [
"uploader"
],
"Denniss": [
"editor"
],
"DerHexer": [
"editor",
"steward",
"vrt-permissions"
],
"Derek Andrews": [
"editor"
],
"Designermadsen": [
"editor"
],
"Deu": [
"global-rollbacker"
],
"Dexxor": [
"editor"
],
"Dezedien": [
"vrt-permissions"
],
"Diandramartin": [
"autoreview"
],
"Didym": [
"vrt-permissions"
],
"Dino Bronto Rex": [
"editor"
],
"Dirk Hünniger": [
"editor"
],
"Divinations": [
"global-rollbacker"
],
"Djb": [
"editor"
],
"Djbrown": [
"editor"
],
"Dlrohrer2003": [
"editor"
],
"Dmccreary": [
"editor"
],
"Doc Taxon": [
"vrt-permissions"
],
"Doctorxgc": [
"editor"
],
"Dom walden": [
"editor"
],
"Domdomegg": [
"editor"
],
"DominikTurner": [
"autoreview"
],
"DonaldKronos": [
"editor"
],
"DoubleGrazing": [
"global-renamer"
],
"Doubleotoo": [
"editor"
],
"Downdate": [
"editor"
],
"Dr-Taher": [
"global-renamer"
],
"Dr.Unclear": [
"editor"
],
"DreamRimmer": [
"global-renamer",
"global-sysop"
],
"Dreftymac": [
"editor"
],
"Drpundir": [
"editor"
],
"Drummingman": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"DuLithgow": [
"editor"
],
"Dungodung": [
"vrt-permissions"
],
"Duplode": [
"editor"
],
"DustDFG": [
"editor"
],
"Dyolf77": [
"vrt-permissions"
],
"EDCU320RHT": [
"editor"
],
"EDUC320 Sylvialiang": [
"editor"
],
"EE JRW": [
"editor"
],
"EMAD KAYYAM": [
"editor"
],
"EPIC": [
"steward"
],
"EarlGrey2005": [
"autoreview"
],
"Ebe123": [
"editor"
],
"Ecarew": [
"editor"
],
"Edgar181": [
"editor"
],
"Edit filter": [
"sysop"
],
"EdoDodo": [
"editor"
],
"Edornbush": [
"editor"
],
"Edriiic": [
"editor"
],
"Efex": [
"editor"
],
"Efex3": [
"editor"
],
"Effeietsanders": [
"editor",
"vrt-permissions"
],
"EggRoll97": [
"editor"
],
"Egil": [
"editor"
],
"Eihel": [
"global-rollbacker",
"editor"
],
"Ejs-80": [
"global-renamer"
],
"Ekaroleski": [
"editor"
],
"Elaurier": [
"editor"
],
"Elcobbola": [
"vrt-permissions"
],
"Electro": [
"editor"
],
"ElfSnail123": [
"editor"
],
"Eli bubo4ka": [
"editor"
],
"Eliarani": [
"editor"
],
"Elli": [
"global-renamer",
"vrt-permissions"
],
"Ellywa": [
"vrt-permissions"
],
"Elmacenderesi": [
"vrt-permissions"
],
"Elton": [
"editor",
"steward"
],
"Emha": [
"vrt-permissions"
],
"EmilymDaniel": [
"autoreview"
],
"Empire3131": [
"editor"
],
"Encik Tekateki": [
"editor"
],
"Enzomartinelli": [
"editor"
],
"Eric Evers": [
"editor"
],
"Erigena": [
"editor"
],
"Erik Baas": [
"editor"
],
"ErinNik": [
"editor"
],
"Erinamukuta": [
"editor"
],
"ErrantX": [
"editor"
],
"EruannoVG": [
"editor"
],
"Espen180": [
"editor"
],
"Eta Carinae": [
"global-renamer"
],
"Ethacke1": [
"editor"
],
"Eumolpo": [
"editor"
],
"Euphydryas": [
"global-renamer"
],
"Eurodyne": [
"editor"
],
"EvDawg93": [
"editor"
],
"EvanCarroll": [
"editor"
],
"Ewen": [
"editor"
],
"Exusiai": [
"global-renamer"
],
"Ezarate": [
"global-rollbacker",
"vrt-permissions"
],
"Fabartus": [
"editor",
"uploader"
],
"Faendalimas": [
"ombuds"
],
"Fasten": [
"editor"
],
"Faster than Thunder": [
"editor"
],
"Fathoms Below": [
"global-renamer"
],
"Fcorthay": [
"editor"
],
"Fdena": [
"editor"
],
"Federhalter": [
"editor"
],
"Fehufanga": [
"global-rollbacker",
"global-sysop"
],
"Fekarp": [
"editor"
],
"Fephisto": [
"editor"
],
"Ferien": [
"global-rollbacker"
],
"Fernando2812l": [
"editor"
],
"Fernly": [
"editor"
],
"Ffion B Thompson": [
"autoreview"
],
"Fimatic": [
"editor"
],
"FischX": [
"editor"
],
"Fishpi": [
"editor"
],
"Flattail": [
"editor"
],
"FlightTime": [
"global-renamer"
],
"Flolit": [
"editor"
],
"Fluffernutter": [
"vrt-permissions"
],
"FlyingAce": [
"global-rollbacker"
],
"Fountain Pen": [
"editor"
],
"Fr33kman": [
"editor"
],
"FrancisFromGaspesie": [
"editor"
],
"Frantsch": [
"autoreview"
],
"Fredericknortje": [
"editor"
],
"Fritzlein~enwikibooks": [
"editor"
],
"Frozen Wind": [
"transwiki",
"editor"
],
"Ftaljaard": [
"editor"
],
"Ftiercel": [
"editor"
],
"Furrykef": [
"editor"
],
"GKFX": [
"editor"
],
"Galahad": [
"global-rollbacker"
],
"Gampe": [
"vrt-permissions"
],
"Ganímedes": [
"vrt-permissions"
],
"Gary Dorman Wiggins": [
"editor",
"uploader"
],
"Garygaryj": [
"editor"
],
"Gat lombard": [
"editor"
],
"Gc211": [
"editor"
],
"Geagea": [
"vrt-permissions"
],
"Geekgirl": [
"editor"
],
"GemmaCampbell": [
"autoreview"
],
"Geoff Plourde": [
"editor"
],
"Geofferybard": [
"transwiki",
"editor"
],
"GerbenRienk": [
"editor"
],
"Gerges": [
"global-rollbacker",
"global-renamer"
],
"Germany Poul Ah": [
"editor"
],
"Gertbuschmann": [
"editor"
],
"Ggee0621": [
"editor"
],
"Gifnk dlm 2020": [
"editor",
"uploader"
],
"Girdi": [
"editor"
],
"Glaisher": [
"editor"
],
"Glane23": [
"vrt-permissions"
],
"Gleb713": [
"autoreview"
],
"Glich": [
"editor"
],
"Gllyons": [
"editor"
],
"Gmasterman": [
"editor"
],
"GoblinInventor": [
"editor"
],
"Godsy": [
"autoreview"
],
"Good afternoon": [
"editor"
],
"GoreyCat": [
"editor"
],
"GorgeUbuasha": [
"editor"
],
"GorillaWarfare": [
"vrt-permissions"
],
"Gott wisst": [
"editor"
],
"Goulart": [
"editor"
],
"Gpkp": [
"editor"
],
"Gracebaysinger": [
"editor"
],
"Graeme E. Smith": [
"editor"
],
"Greatswrd": [
"editor"
],
"GreenC": [
"editor"
],
"Greenbreen": [
"editor"
],
"Greenman": [
"editor"
],
"GregXenon01": [
"editor"
],
"Gretski247": [
"editor"
],
"GreyCat": [
"editor"
],
"Grin": [
"vrt-permissions"
],
"Growl41": [
"editor"
],
"Guaka": [
"editor"
],
"Guanaco": [
"editor"
],
"GuillermoHazebrouck": [
"editor"
],
"Guus": [
"editor"
],
"Guy vandegrift": [
"editor"
],
"Guywan": [
"editor"
],
"Gzuufy": [
"editor"
],
"HLand": [
"editor"
],
"HYanWong": [
"editor"
],
"Ha98574": [
"editor"
],
"Hagindaz": [
"editor"
],
"HakanIST": [
"editor",
"steward"
],
"Hamish": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"Hanay": [
"vrt-permissions"
],
"Hannes Röst": [
"editor"
],
"Hans Adler": [
"editor"
],
"Haoreima": [
"editor"
],
"Happy-melon": [
"editor"
],
"Harry Wood": [
"editor"
],
"Harrybrowne1986": [
"editor"
],
"Harv4": [
"editor"
],
"Hasley": [
"editor"
],
"Hazard-SJ": [
"global-rollbacker"
],
"He7d3r": [
"editor"
],
"HenkvD": [
"editor"
],
"Herbythyme": [
"editor"
],
"Hercule": [
"editor"
],
"Herman darman": [
"editor"
],
"HerrHartmuth": [
"editor"
],
"Hethrir": [
"editor"
],
"HgDeviasse": [
"editor"
],
"Hippias": [
"editor"
],
"Hliow": [
"autoreview"
],
"Holder": [
"global-rollbacker",
"global-sysop"
],
"Holdoffhunger": [
"editor"
],
"Hoo man": [
"editor",
"steward"
],
"HouseBlaster": [
"global-renamer"
],
"Howard Beale": [
"editor"
],
"Hpon": [
"editor"
],
"Hrkalona": [
"autoreview"
],
"Hskeet": [
"editor",
"uploader"
],
"Htm": [
"vrt-permissions"
],
"Hugetim": [
"editor"
],
"Humaira Ali": [
"editor"
],
"Huntertur": [
"editor"
],
"Hydriz": [
"global-rollbacker"
],
"Ibidthewriter": [
"editor"
],
"Ibrahim Sani Mustapha": [
"editor"
],
"Ibrahim.ID": [
"global-renamer",
"vrt-permissions"
],
"Icetruck": [
"editor"
],
"Icodense": [
"global-rollbacker",
"global-sysop"
],
"Idavidmiller": [
"editor"
],
"Ideasman42": [
"editor"
],
"Igna": [
"editor"
],
"Ijon": [
"vrt-permissions"
],
"Illusional": [
"editor"
],
"Iluvatar": [
"global-rollbacker",
"vrt-permissions"
],
"Indiana": [
"editor"
],
"Inductiveload": [
"editor"
],
"Inertia6084": [
"autoreview"
],
"Inferno986return": [
"editor"
],
"Infinite0694": [
"global-rollbacker",
"global-sysop"
],
"Ingolemo": [
"editor"
],
"Insignificantwrangler": [
"editor"
],
"Internoob": [
"transwiki",
"editor"
],
"InverseHypercube": [
"editor"
],
"Isenhand": [
"editor"
],
"Ish ishwar": [
"editor"
],
"Iste Praetor": [
"editor"
],
"ItsNyoty": [
"vrt-permissions"
],
"Itsmeyash31": [
"autoreview"
],
"Itswikisam": [
"editor"
],
"Itti": [
"global-renamer",
"vrt-permissions"
],
"Ixfd64": [
"editor"
],
"J ansari": [
"global-rollbacker"
],
"J.palacios.jean": [
"editor"
],
"J36miles": [
"editor"
],
"JBW": [
"global-renamer"
],
"JCrue": [
"editor"
],
"JJ12880": [
"editor"
],
"JJMC89": [
"vrt-permissions"
],
"JJPMaster": [
"sysop",
"global-rollbacker",
"global-renamer",
"interface-admin",
"vrt-permissions"
],
"JJPMaster (test 1)": [
"autoreview"
],
"JJohnson": [
"editor"
],
"JJohnson1701": [
"editor"
],
"JPPINTO": [
"editor"
],
"Jack Frost": [
"vrt-permissions"
],
"JackBot": [
"editor"
],
"JackPotte": [
"sysop",
"interface-admin"
],
"Jackhand1": [
"autoreview"
],
"Jacob J. Walker": [
"editor"
],
"Jafeluv": [
"global-rollbacker",
"editor"
],
"Jake Park": [
"global-renamer"
],
"Jakec": [
"editor"
],
"JamesCrook": [
"editor"
],
"JamesNZ": [
"editor"
],
"Jamesofur": [
"global-rollbacker"
],
"Jamesssss": [
"editor"
],
"Jamzze": [
"editor"
],
"Jan Myšák": [
"global-rollbacker"
],
"Jan.duggan": [
"autoreview"
],
"Janbery": [
"global-rollbacker",
"vrt-permissions"
],
"Janpha": [
"editor"
],
"Janschejbal": [
"editor"
],
"Jason.Cozens": [
"editor"
],
"Jaspalkaler": [
"editor"
],
"Jasper Deng": [
"global-rollbacker"
],
"JavaHurricane": [
"global-rollbacker",
"editor"
],
"Javier Carro": [
"editor"
],
"JavierCantero": [
"editor"
],
"Jay Bolero": [
"editor"
],
"Jazzmanian": [
"editor"
],
"Jcb": [
"editor",
"vrt-permissions"
],
"Jcwf": [
"editor"
],
"Jeff G.": [
"global-rollbacker",
"editor"
],
"Jeff1138": [
"editor"
],
"Jellysandwich0": [
"editor"
],
"JenVan": [
"editor"
],
"JenniferPalacios": [
"editor"
],
"Jenniferjkidd": [
"editor"
],
"Jens Østergaard Petersen": [
"editor"
],
"JeremyMcCracken": [
"editor"
],
"Jeroenr": [
"editor"
],
"Jerome Charles Potts": [
"editor"
],
"Jerry vlntn": [
"editor"
],
"Jesdisciple": [
"editor"
],
"Jfmantis": [
"editor"
],
"Jianhui67": [
"global-rollbacker",
"editor"
],
"Jianhui67 public": [
"editor"
],
"Jim Ashby": [
"autoreview"
],
"JimKillock": [
"editor"
],
"Jimbotyson": [
"editor"
],
"Jimmy Xu": [
"vrt-permissions"
],
"Jkauf007": [
"editor"
],
"Jmdeschamps": [
"uploader"
],
"Jnanaranjan sahu": [
"ombuds"
],
"Jnewh001": [
"editor"
],
"Jobin RV": [
"editor"
],
"Joewiz": [
"editor"
],
"Johannes Bo": [
"editor"
],
"Johannnes89": [
"steward"
],
"John Cross": [
"editor"
],
"JohnMarcelo": [
"editor"
],
"Johnkn63": [
"editor"
],
"Johnwhelan": [
"editor"
],
"Jokes Free4Me": [
"editor"
],
"Jomegat": [
"editor"
],
"Jon Harald Søby": [
"vrt-permissions"
],
"Jon Kolbert": [
"steward",
"vrt-permissions"
],
"Jonathan Webley": [
"editor"
],
"Jordan Brown": [
"editor"
],
"JorisvS": [
"editor"
],
"Josve05a": [
"vrt-permissions"
],
"Jrincayc": [
"editor"
],
"Jsnaree": [
"editor"
],
"Jtneill": [
"editor"
],
"JuethoBot": [
"autoreview"
],
"Jugandi": [
"editor"
],
"Jules*": [
"global-renamer"
],
"Juliancolton": [
"global-rollbacker",
"editor"
],
"Jumark27": [
"editor"
],
"JustTheFacts33": [
"editor"
],
"Justlettersandnumbers": [
"global-renamer",
"vrt-permissions"
],
"K6ka": [
"global-rollbacker",
"global-renamer"
],
"Kadı": [
"global-renamer",
"vrt-permissions"
],
"Kai Burghardt": [
"editor"
],
"Kaltenmeyer": [
"editor"
],
"Kambai Akau": [
"editor"
],
"Kanjy": [
"global-rollbacker",
"editor"
],
"Kapooht": [
"editor"
],
"Karl Wick": [
"editor"
],
"Karosent": [
"editor"
],
"Kashkhan": [
"editor"
],
"Kathryn Mary Nicholson": [
"autoreview"
],
"Katiemgeorge": [
"editor"
],
"Katyauchter": [
"editor"
],
"Kaushlendratripathi": [
"editor"
],
"Kaw8yh": [
"editor"
],
"Kayau": [
"transwiki",
"editor"
],
"Kellen": [
"editor"
],
"Kelti": [
"editor"
],
"Kiefer.Wolfowitz": [
"editor"
],
"Killarnee": [
"editor"
],
"King of Hearts": [
"vrt-permissions"
],
"Kingaustin07": [
"editor"
],
"Kingofnuthin": [
"editor"
],
"Kirito": [
"global-rollbacker",
"editor"
],
"Kittycataclysm": [
"sysop"
],
"Kj cheetham": [
"global-renamer"
],
"Kkmurray": [
"editor"
],
"Kl-robertson": [
"editor"
],
"Klaas van Buiten": [
"editor"
],
"Knittedbees": [
"transwiki",
"editor"
],
"Knoppson": [
"autoreview"
],
"Koantum": [
"editor"
],
"Koavf": [
"sysop",
"global-rollbacker"
],
"Kodos": [
"editor"
],
"KonstantinaG07": [
"editor",
"steward"
],
"Kowey": [
"editor"
],
"KrakatoaKatie": [
"vrt-permissions"
],
"Krd": [
"vrt-permissions"
],
"Krdbot": [
"vrt-permissions"
],
"Kri": [
"editor"
],
"Krinkle": [
"global-rollbacker"
],
"Kropotkine 113": [
"vrt-permissions"
],
"Kruusamägi": [
"vrt-permissions"
],
"Ktucker": [
"editor"
],
"Kwamikagami": [
"editor"
],
"Kwhitefoot": [
"editor"
],
"Kylu": [
"editor"
],
"Kızıl": [
"global-renamer"
],
"L10nM4st3r": [
"editor"
],
"LABoyd2": [
"editor"
],
"LR0725": [
"global-rollbacker",
"global-sysop"
],
"Ladislav": [
"editor"
],
"Ladsgroup": [
"global-renamer"
],
"Ladybug62": [
"editor"
],
"Lagoset": [
"editor"
],
"Larsnooden": [
"editor"
],
"Laurianedani": [
"editor"
],
"Lcraw005": [
"editor"
],
"Ldo": [
"editor"
],
"Leaderboard": [
"sysop",
"global-renamer",
"interface-admin"
],
"Learnerktm": [
"editor"
],
"Lechatjaune": [
"vrt-permissions"
],
"Leighblackall": [
"editor"
],
"Lengel46": [
"editor"
],
"Lentokonefani": [
"global-renamer"
],
"LeoChiukl": [
"editor"
],
"Leonard64": [
"uploader"
],
"Leonidlednev": [
"autoreview",
"global-rollbacker"
],
"Leovanderven": [
"editor"
],
"Lesless": [
"vrt-permissions"
],
"Leyo": [
"global-rollbacker"
],
"Lgriot": [
"editor"
],
"Liam987": [
"editor"
],
"Liao": [
"editor"
],
"Libperry": [
"editor"
],
"Limiza": [
"editor"
],
"Lionel Cristiano": [
"editor"
],
"Litlok": [
"global-renamer"
],
"Little Sunshine": [
"global-renamer"
],
"Llakew": [
"editor"
],
"LlamaAl": [
"editor"
],
"Lobsteroh": [
"editor"
],
"LodestarChariot2": [
"editor"
],
"Lofty abyss": [
"global-rollbacker",
"editor",
"vrt-permissions"
],
"Logictheo": [
"editor"
],
"Lomita": [
"vrt-permissions"
],
"Londonjackbooks": [
"editor"
],
"Lovepeacejoy404": [
"editor"
],
"Lp0 on fire": [
"autoreview",
"global-rollbacker"
],
"Lubaochuan": [
"editor"
],
"Luckas Blade": [
"editor"
],
"Lucystewpid": [
"autoreview"
],
"Ludovic Brenta": [
"editor"
],
"Ludovicocaldara": [
"editor",
"uploader"
],
"Lukas²³": [
"editor"
],
"LukeCEL": [
"editor"
],
"Lvova": [
"vrt-permissions"
],
"Lwill031": [
"editor"
],
"M7": [
"steward"
],
"MARKELLOS": [
"vrt-permissions"
],
"MBq": [
"global-renamer"
],
"MF-Warburg": [
"global-rollbacker",
"global-sysop",
"editor"
],
"MGA73": [
"vrt-permissions"
],
"MIacono": [
"editor"
],
"MNeuschaefer": [
"editor"
],
"MS Sakib": [
"global-renamer",
"vrt-permissions"
],
"Mabdul": [
"transwiki",
"editor",
"uploader"
],
"Madisonhen": [
"autoreview"
],
"Magda.dagda": [
"editor"
],
"Magnus Manske": [
"editor"
],
"Mahagaja": [
"editor"
],
"MaikoM93": [
"editor"
],
"Maire": [
"global-renamer"
],
"Malarz pl": [
"global-renamer"
],
"Manchiu": [
"global-renamer"
],
"MandoRachovitsa": [
"autoreview"
],
"Mandy Hopkins": [
"editor"
],
"ManuelGR": [
"editor"
],
"MarcGarver": [
"sysop",
"checkuser",
"steward"
],
"Marco Klunder": [
"editor"
],
"MarcoAurelio": [
"editor"
],
"Marcus Cyron": [
"vrt-permissions"
],
"Mardus": [
"editor"
],
"MarkJFernandes": [
"editor"
],
"MarkTraceur": [
"editor"
],
"Markcwm": [
"editor"
],
"Markhobley": [
"editor"
],
"MarsRover": [
"editor"
],
"Marshman~enwikibooks": [
"editor"
],
"Martin Kraus": [
"editor"
],
"Martin Sauter": [
"editor"
],
"Martin Urbanec": [
"editor",
"steward",
"vrt-permissions"
],
"MartinPoulter": [
"editor"
],
"Martinwguy2": [
"editor"
],
"MarygoldRules": [
"editor"
],
"Master tongue": [
"editor"
],
"Masti": [
"steward",
"vrt-permissions"
],
"Math buff": [
"editor"
],
"MathXplore": [
"global-rollbacker",
"editor"
],
"Mathildem16": [
"autoreview"
],
"Mathmensch": [
"editor"
],
"Mathmensch-Smalledits": [
"editor"
],
"Mathmogeek": [
"editor"
],
"Maths314": [
"editor"
],
"Matiia": [
"editor"
],
"Matrix": [
"autoreview",
"vrt-permissions"
],
"Matsievsky": [
"editor"
],
"Mattb112885": [
"editor"
],
"Mattbarton.exe": [
"editor"
],
"Matttest": [
"autoreview"
],
"Max Milas": [
"editor"
],
"Maxim": [
"editor"
],
"Maximillion Pegasus": [
"global-rollbacker",
"editor"
],
"Maxint2": [
"editor"
],
"Mazbel": [
"global-rollbacker"
],
"Mbch331": [
"vrt-permissions"
],
"Mbrickn": [
"transwiki",
"editor"
],
"Mcdonnkm": [
"editor"
],
"Mcld": [
"editor"
],
"Mdkoch84": [
"editor"
],
"Mdmckenzie": [
"editor"
],
"MdsShakil": [
"steward",
"vrt-permissions"
],
"Mdupont": [
"editor"
],
"Me Lendroz": [
"editor"
],
"Meanmicio": [
"editor"
],
"Mecanismo": [
"editor"
],
"MediaKyle": [
"editor"
],
"Meditation": [
"editor"
],
"Meev0": [
"editor"
],
"Mehman": [
"ombuds",
"vrt-permissions"
],
"Melos": [
"steward",
"vrt-permissions"
],
"MemicznyJanusz": [
"global-renamer"
],
"Mendelivia~enwikibooks": [
"editor"
],
"Meniktah": [
"editor"
],
"Mercy": [
"global-rollbacker",
"editor"
],
"MerlLinkBot": [
"editor"
],
"Mfield": [
"global-renamer"
],
"Mh7kJ": [
"editor"
],
"Michael Romanov": [
"editor"
],
"MichaelFrey": [
"editor"
],
"Michaelbluett": [
"editor",
"uploader"
],
"Mido": [
"vrt-permissions"
],
"MihalOrela": [
"editor"
],
"MiiCii": [
"editor"
],
"Mike Hayes": [
"editor"
],
"Mike.lifeguard": [
"editor"
],
"Mild Bill Hiccup": [
"editor"
],
"Mill3315": [
"editor"
],
"Millbart": [
"vrt-permissions"
],
"Mimarx": [
"editor"
],
"Min1996": [
"autoreview"
],
"Minorax": [
"global-rollbacker",
"global-sysop",
"editor"
],
"Mirinano": [
"global-rollbacker"
],
"Mithridates": [
"editor"
],
"Mjbt": [
"editor"
],
"Mjchael": [
"editor"
],
"Mjkaye": [
"editor"
],
"Mkline": [
"autoreview"
],
"Mlipl001": [
"editor"
],
"Moby-Dick4000": [
"editor"
],
"Mohean": [
"editor"
],
"Money-lover-12345": [
"editor"
],
"Moonriddengirl": [
"autoreview",
"vrt-permissions"
],
"Mortense": [
"editor"
],
"Mpfau": [
"editor"
],
"Mr. Stradivarius": [
"editor"
],
"MrAlanKoh": [
"editor"
],
"MrJaroslavik": [
"global-rollbacker",
"ombuds"
],
"Mrajcok": [
"editor"
],
"Mrjulesd": [
"editor"
],
"Mrwojo": [
"editor"
],
"Mschrag": [
"editor"
],
"Msmithma": [
"editor"
],
"MtPenguinMonster": [
"editor"
],
"Mtarch11": [
"global-rollbacker",
"global-sysop",
"editor"
],
"Musical Inquisit": [
"editor"
],
"Mussklprozz": [
"vrt-permissions"
],
"Mvolz": [
"editor"
],
"Mwtoews": [
"editor"
],
"Mxn": [
"editor"
],
"Myklaw": [
"editor"
],
"Mykola7": [
"steward"
],
"Mys 721tx": [
"global-renamer",
"vrt-permissions"
],
"NDG": [
"global-rollbacker",
"editor"
],
"Nadzik": [
"global-rollbacker",
"global-renamer"
],
"NahidSultan": [
"vrt-permissions"
],
"Nangkhan Magar": [
"editor"
],
"Natuur12": [
"vrt-permissions"
],
"Nbarth": [
"editor"
],
"Nbro": [
"editor"
],
"Nehaoua": [
"ombuds"
],
"Neils51": [
"editor"
],
"Nemoralis": [
"vrt-permissions"
],
"Neojacob": [
"editor"
],
"Neriah": [
"global-rollbacker",
"global-renamer"
],
"Nesbit": [
"editor"
],
"Newlisp": [
"editor"
],
"Nfgdayton": [
"editor"
],
"NguoiDungKhongDinhDanh": [
"global-rollbacker",
"editor"
],
"NhacNy2412": [
"global-renamer"
],
"Nick.anderegg": [
"editor"
],
"NickPenguin": [
"editor"
],
"NicoScribe": [
"editor"
],
"Nicole Sharp": [
"editor"
],
"Nieuwsgierige Gebruiker": [
"editor"
],
"Nigos": [
"autoreview"
],
"Nihonjoe": [
"global-renamer"
],
"Nikai": [
"editor"
],
"Ninjastrikers": [
"vrt-permissions"
],
"NipplesMeCool": [
"editor"
],
"Njardarlogar": [
"editor"
],
"Nobody60": [
"editor"
],
"Nolispanmo": [
"vrt-permissions"
],
"Nomstuff": [
"autoreview"
],
"Nonenmac": [
"editor"
],
"Norton": [
"editor"
],
"Npettiaux": [
"editor"
],
"Nsaa": [
"vrt-permissions"
],
"Nthep": [
"vrt-permissions"
],
"NuclearWarfare": [
"global-rollbacker",
"editor"
],
"OMSMike": [
"editor"
],
"Officer781": [
"editor"
],
"Oleander": [
"editor"
],
"Oliviacatherall": [
"autoreview"
],
"Omphalographer": [
"editor"
],
"OnBeyondZebrax": [
"editor"
],
"Onsen": [
"editor"
],
"Ontzak": [
"global-renamer"
],
"Orderud": [
"editor"
],
"OrenBochman": [
"editor"
],
"Oshwah": [
"global-renamer"
],
"Ottawahitech": [
"editor"
],
"Owain.davies": [
"editor"
],
"PAC": [
"editor"
],
"PAC2": [
"editor"
],
"PK 97": [
"editor"
],
"PNW Raven": [
"editor"
],
"Pac8612": [
"editor"
],
"Paloi Sciurala": [
"global-rollbacker"
],
"Panic2k4": [
"transwiki",
"editor"
],
"Pascal Pignard": [
"editor"
],
"Pastbury": [
"editor"
],
"Pathfinders": [
"editor"
],
"Pathoschild": [
"editor"
],
"Patrik": [
"editor"
],
"PauSix": [
"editor"
],
"Paul James": [
"editor"
],
"Pavroo": [
"editor"
],
"PbakerODU": [
"editor"
],
"Pbrower2a": [
"editor"
],
"Pearts": [
"editor"
],
"Peeragogia": [
"editor"
],
"Peri Coleman": [
"editor"
],
"Perl~enwikibooks": [
"editor"
],
"Peter1180": [
"editor"
],
"PeterEasthope": [
"editor"
],
"Peyton09": [
"editor"
],
"Phan M. Nhat": [
"autoreview"
],
"PhilKnight": [
"global-renamer"
],
"Phoebe": [
"editor"
],
"Phosgram": [
"editor"
],
"Pi zero": [
"editor"
],
"PieWriter": [
"editor"
],
"Piotrus": [
"editor"
],
"Pithikos": [
"editor"
],
"Pittsburgh Poet": [
"editor"
],
"Pjpearce": [
"editor"
],
"Pkkao": [
"editor"
],
"Planotse": [
"editor"
],
"Platonides": [
"vrt-permissions"
],
"Pluke": [
"editor"
],
"PlyrStar93": [
"global-rollbacker",
"editor"
],
"Pminh141": [
"global-renamer"
],
"Pmlineditor": [
"editor"
],
"Pmw57": [
"editor"
],
"Poetcsw": [
"editor"
],
"PoizonMyst": [
"editor"
],
"Pola 2607": [
"autoreview"
],
"Polimerek": [
"vrt-permissions"
],
"Polluks": [
"editor"
],
"Pookiyama": [
"editor"
],
"Popski": [
"editor"
],
"Povigna": [
"editor"
],
"Ppolar bear": [
"global-rollbacker",
"global-renamer"
],
"Pppery": [
"autoreview"
],
"Prahlad balaji": [
"editor"
],
"Pratyeka": [
"editor"
],
"Praxidicae": [
"global-rollbacker",
"global-sysop",
"editor"
],
"Primefac": [
"vrt-permissions"
],
"Prince Kassad~enwikibooks": [
"editor"
],
"Pronesto": [
"editor"
],
"Prototyperspective": [
"autoreview"
],
"Psoup": [
"editor"
],
"Psr1909": [
"editor"
],
"PullUpYourSocks": [
"editor"
],
"PurpleBuffalo": [
"global-renamer"
],
"PurplePieman": [
"editor"
],
"Purplebackpack89": [
"editor"
],
"Putukas01": [
"editor"
],
"Qenalcu": [
"autoreview"
],
"Quebecguy": [
"global-rollbacker"
],
"QueerEcofeminist": [
"global-rollbacker",
"global-renamer",
"editor"
],
"Quinlan83": [
"global-rollbacker",
"editor"
],
"Quintucket": [
"editor"
],
"Qwerty number1": [
"editor"
],
"Qwertyus": [
"editor"
],
"Qədir": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"R. Henrik Nilsson": [
"editor"
],
"RAdimer-WMF": [
"global-rollbacker"
],
"RDBury": [
"editor"
],
"RJHall": [
"editor"
],
"Ra'ike": [
"vrt-permissions"
],
"Rachboots": [
"editor"
],
"Rachel": [
"editor"
],
"Rachmat04": [
"global-renamer",
"vrt-permissions"
],
"RadiX": [
"editor",
"steward",
"vrt-permissions"
],
"Raffaela Kunz": [
"editor"
],
"Rahulkepapa": [
"editor"
],
"Ramac": [
"editor"
],
"Rambam rashi": [
"editor"
],
"Randykitty": [
"autoreview",
"global-rollbacker"
],
"RatónMístico176": [
"editor"
],
"Ravichandar84": [
"editor"
],
"Rawheatley": [
"editor"
],
"Ray Trygstad": [
"editor"
],
"RayeChellMahela": [
"editor"
],
"Raymond": [
"vrt-permissions"
],
"Razr Nation": [
"editor"
],
"Rchaswms01": [
"editor"
],
"Rcragun": [
"editor",
"uploader"
],
"Readyokaygo": [
"editor"
],
"Recent Runes": [
"editor"
],
"Redlentil": [
"editor"
],
"Refcanimm": [
"editor"
],
"Regasterios": [
"vrt-permissions"
],
"Reinhard Kraasch": [
"vrt-permissions"
],
"RenaissanceMan2144": [
"autoreview"
],
"Renamed user 242094acfb1a5b2f08e9e78f2e021a40": [
"editor"
],
"Renamed user 5f91ca71739b07cfce8397eed758fe13": [
"editor",
"uploader"
],
"Renamed user f26394dcb19bd7bdad78f0d752896653": [
"editor"
],
"Renvoy": [
"global-rollbacker",
"global-sysop"
],
"Reseletti": [
"editor"
],
"Retropunk": [
"editor"
],
"Reuben1508": [
"autoreview"
],
"Revi C.": [
"global-rollbacker",
"global-renamer",
"ombuds",
"editor",
"vrt-permissions"
],
"Reyk": [
"editor"
],
"Rfc1394": [
"editor"
],
"Rgdboer": [
"editor"
],
"Rgreenone": [
"editor"
],
"Rhole2001": [
"autoreview"
],
"Rich Farmbrough": [
"editor"
],
"Rickstambaugh": [
"editor"
],
"Riggwelter": [
"vrt-permissions"
],
"Risk": [
"editor"
],
"Risteall": [
"editor"
],
"Ritjesman": [
"editor"
],
"RoMancer": [
"editor"
],
"Robbiemorrison": [
"editor"
],
"Robert Huber~enwikibooks": [
"editor"
],
"Roberto Mura": [
"editor"
],
"Robertsky": [
"global-renamer",
"vrt-permissions"
],
"RobinH": [
"editor"
],
"Rodasmith": [
"editor"
],
"Rodrigo": [
"editor"
],
"Rodrigo.Argenton": [
"vrt-permissions"
],
"Rogerborrell": [
"editor"
],
"Rogerdpack": [
"editor"
],
"RogueScholar": [
"editor"
],
"Romainbehar": [
"editor"
],
"RomaineBot": [
"vrt-permissions"
],
"RonaldB": [
"vrt-permissions"
],
"Rosser1954": [
"editor"
],
"Rotlink": [
"editor"
],
"RoySmith": [
"ombuds"
],
"Rozzychan": [
"editor"
],
"Rplano": [
"editor"
],
"Rreagan007": [
"autoreview"
],
"Rrgreen": [
"editor"
],
"Rschen7754": [
"global-rollbacker",
"editor"
],
"RshieldsVA": [
"editor"
],
"Rsjaffe": [
"global-renamer"
],
"Rtaisis": [
"editor"
],
"Ruakh": [
"editor"
],
"Rudolpho~enwikibooks": [
"editor"
],
"Runfellow": [
"editor"
],
"Runner4lyfe": [
"editor"
],
"RunningBlind": [
"editor"
],
"Ruthven": [
"vrt-permissions"
],
"Ruud Koot": [
"transwiki",
"editor"
],
"Rzuwig": [
"autoreview",
"global-rollbacker"
],
"S8321414": [
"global-renamer"
],
"SB Johnny": [
"editor"
],
"SCP-2000": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"SHB2000": [
"sysop",
"steward"
],
"SPM": [
"editor"
],
"Sae1962": [
"editor"
],
"Safuan12616": [
"editor"
],
"SahniM": [
"editor"
],
"Sakretsu": [
"steward"
],
"Sakura emad": [
"global-rollbacker"
],
"Salil Kumar Mukherjee": [
"editor"
],
"Samat": [
"vrt-permissions"
],
"Sammy2012": [
"editor"
],
"Samuel.dellit": [
"editor"
],
"Samuele2002": [
"global-rollbacker",
"editor"
],
"Samwilson": [
"editor"
],
"SanBonne": [
"global-renamer",
"vrt-permissions"
],
"Sandbergja": [
"editor"
],
"Sannita": [
"vrt-permissions"
],
"Sante Caserio~enwikibooks": [
"editor"
],
"SarahFatimaK": [
"editor"
],
"Sargoth": [
"vrt-permissions"
],
"Saroj": [
"global-rollbacker"
],
"Sascha Lill 95": [
"editor"
],
"Satdeep Gill": [
"vrt-permissions"
],
"Savh": [
"global-rollbacker",
"editor"
],
"Sbb1413": [
"editor"
],
"Scention": [
"editor"
],
"Schniggendiller": [
"steward"
],
"SchreiberBike": [
"editor"
],
"Scott.beckman": [
"editor"
],
"Sebastian Wallroth": [
"vrt-permissions"
],
"Seewolf": [
"global-rollbacker",
"vrt-permissions"
],
"Sekidoki": [
"vrt-permissions"
],
"Selden": [
"editor"
],
"Sennecaster": [
"vrt-permissions"
],
"Serinap": [
"editor"
],
"Seth Miller": [
"editor"
],
"SevenSpheres": [
"editor"
],
"Sfan00 IMG": [
"editor"
],
"Sfoerster": [
"editor"
],
"Sgarrigan": [
"editor"
],
"Sgowal": [
"editor"
],
"Shaitand": [
"editor"
],
"ShakespeareFan00": [
"editor"
],
"SharingNotes": [
"editor"
],
"Shawntanchinyang": [
"editor"
],
"Shdwninja8": [
"editor"
],
"ShelleyAdams": [
"autoreview"
],
"ShifaYT": [
"global-rollbacker"
],
"Shii": [
"editor"
],
"Shira the Mogul": [
"editor"
],
"Shlomif": [
"editor"
],
"ShuBraque": [
"editor"
],
"Sidelight12": [
"editor"
],
"Sidorkin": [
"editor"
],
"Sidpatil": [
"editor"
],
"Siebengang": [
"editor"
],
"Sigma 7": [
"editor"
],
"Simon Peter Hughes": [
"editor"
],
"Sinus46": [
"editor"
],
"Sir Beluga": [
"editor"
],
"Sir Lestaty de Lioncourt": [
"vrt-permissions"
],
"SixWingedSeraph": [
"editor"
],
"Sj": [
"editor"
],
"Sjc~enwikibooks": [
"editor"
],
"Sjlegg": [
"editor"
],
"Sjone101": [
"editor"
],
"Sjö": [
"global-rollbacker"
],
"Skymath": [
"editor"
],
"Slava Ukraini Heroyam Slava 123": [
"editor",
"uploader"
],
"Slava Ukrajini Heroyam Slava": [
"editor"
],
"Sluffs": [
"editor"
],
"Smjg": [
"editor"
],
"SnappyDragonPennyroyal": [
"editor"
],
"SocialKnowledge": [
"editor"
],
"SoftwareEngineerMoose": [
"autoreview"
],
"Sonia": [
"editor"
],
"Sophie Cheng": [
"editor"
],
"Sotiale": [
"steward"
],
"Soul windsurfer": [
"editor"
],
"SouthParkFan65": [
"editor"
],
"SoylentGreen": [
"editor"
],
"Spamduck": [
"editor"
],
"Spaynton": [
"editor"
],
"Spender2001": [
"editor"
],
"Speregrination": [
"editor"
],
"Spiderworm": [
"editor"
],
"Spoon!": [
"editor"
],
"Squasher": [
"global-renamer"
],
"Srhat": [
"editor"
],
"Stang": [
"global-rollbacker",
"editor",
"vrt-permissions"
],
"Stanglavine": [
"editor"
],
"Steinsplitter": [
"global-renamer",
"vrt-permissions"
],
"StephT0704": [
"autoreview"
],
"Stepheng3": [
"editor"
],
"Stepro": [
"vrt-permissions"
],
"Steve M": [
"editor"
],
"Stilfehler": [
"editor"
],
"Stockywood": [
"editor"
],
"Storeye": [
"editor"
],
"Strainu": [
"vrt-permissions"
],
"Strange quark": [
"editor"
],
"Stryn": [
"global-rollbacker",
"editor"
],
"Stïnger": [
"global-rollbacker",
"editor"
],
"Suchenwi": [
"editor"
],
"Sumone10154": [
"editor"
],
"SunCreator": [
"editor"
],
"Sunny Cryolite": [
"global-rollbacker"
],
"Sunshineconnelly": [
"editor"
],
"SuperTyphoonNoru": [
"editor"
],
"Superbass": [
"vrt-permissions"
],
"Superpes15": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"vrt-permissions"
],
"Supertoff": [
"vrt-permissions"
],
"Superzerocool": [
"vrt-permissions"
],
"SupremeUmanu": [
"editor"
],
"Suruena": [
"editor"
],
"Sutambe": [
"editor"
],
"Sutton Publishing": [
"editor"
],
"Sué González Hauck": [
"editor"
],
"Svartava": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor"
],
"SweetCanadianMullet": [
"editor"
],
"Swift": [
"editor"
],
"SyG": [
"editor"
],
"Sylvesterchukwu04": [
"editor"
],
"Sylvialim": [
"editor"
],
"Sylviaread": [
"editor"
],
"Synoman Barris": [
"global-rollbacker",
"transwiki",
"editor"
],
"Syum90": [
"global-rollbacker",
"editor"
],
"Syunsyunminmin": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor"
],
"T.seppelt": [
"editor"
],
"TDang": [
"editor"
],
"TTWIDEE": [
"editor"
],
"Tahmid": [
"editor"
],
"Taketa": [
"global-renamer"
],
"Takipoint123": [
"vrt-permissions"
],
"TakuyaMurata": [
"editor"
],
"Tamzin": [
"global-renamer"
],
"Tanbiruzzaman": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor",
"vrt-permissions"
],
"Tannertsf": [
"editor"
],
"Taoheedah": [
"editor"
],
"Tapsevarg": [
"editor"
],
"TaronjaSatsuma": [
"vrt-permissions"
],
"Taxman": [
"editor"
],
"Tchoř": [
"global-renamer"
],
"Tdkehoe": [
"editor"
],
"Tdvorak": [
"editor"
],
"Techman224": [
"editor"
],
"Tegel": [
"editor",
"steward"
],
"Teles": [
"ombuds",
"steward",
"vrt-permissions"
],
"Tem5psu": [
"editor"
],
"Tempodivalse": [
"editor"
],
"TenWhile6": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor"
],
"Tenshi Hinanawi": [
"autoreview",
"global-rollbacker"
],
"Terence Kearey": [
"editor"
],
"Ternarius": [
"global-renamer"
],
"Ternera": [
"global-rollbacker",
"global-renamer",
"global-sysop",
"editor"
],
"Tesleemah": [
"editor"
],
"Tevfik AKTUĞLU": [
"editor"
],
"Tgregtregretgtr": [
"editor"
],
"ThatBPengineer": [
"autoreview"
],
"Thatonewikiguy": [
"editor"
],
"The Squirrel Conspiracy": [
"vrt-permissions"
],
"The labs": [
"editor"
],
"TheGoodEndedHappily": [
"vrt-permissions"
],
"ThePCKid": [
"editor"
],
"TheSandDoctor": [
"global-renamer",
"vrt-permissions"
],
"Theknightwho": [
"editor"
],
"Thenub314": [
"editor"
],
"Theo Hughes": [
"editor"
],
"Theornamentalist": [
"editor"
],
"Thereen": [
"editor"
],
"Thewinster": [
"editor"
],
"Thierry Dugnolle": [
"editor"
],
"Thinkglobalnow": [
"editor"
],
"Thirunavukkarasye-Raveendran": [
"editor"
],
"Thomas Simpson": [
"editor"
],
"Thomas.haslwanter": [
"editor"
],
"Thomas.lochmatter": [
"editor"
],
"Tibetologist": [
"editor"
],
"Tigerzeng": [
"global-rollbacker"
],
"Tiled": [
"editor"
],
"TimBorgNetzWerk": [
"editor"
],
"Timothy Gu": [
"editor"
],
"Timpo": [
"editor"
],
"Tiptoety": [
"editor"
],
"Tjyang": [
"editor"
],
"Tlustulimu": [
"editor"
],
"Tmvogel": [
"editor"
],
"Tom Morris": [
"editor"
],
"Tomato86": [
"editor"
],
"Tomt87": [
"editor"
],
"Tomybrz": [
"editor"
],
"Tonyvall": [
"autoreview"
],
"Tp42": [
"editor"
],
"Tracklayingninja": [
"editor"
],
"Tradimus": [
"editor"
],
"Tropicalkitty": [
"global-rollbacker",
"editor"
],
"TrulyShruti": [
"editor"
],
"Ts12rAc": [
"global-rollbacker"
],
"Tsarina CatarinaToo": [
"autoreview"
],
"TunnelESON": [
"sysop"
],
"Turbojet": [
"vrt-permissions"
],
"Turkmen": [
"editor"
],
"TwoThirty": [
"editor"
],
"Tyoyafud": [
"editor"
],
"Túrelio": [
"autoreview"
],
"U$3rname008": [
"editor"
],
"USSR-Slav": [
"global-rollbacker"
],
"Uf.hun2201": [
"editor"
],
"Ulubatli Hasan": [
"global-renamer"
],
"Uncitoyen": [
"global-rollbacker",
"global-renamer"
],
"Uncle G": [
"editor"
],
"Unixxx": [
"editor"
],
"User01938": [
"editor"
],
"Username222": [
"editor"
],
"Utcursch": [
"vrt-permissions"
],
"Uziel302": [
"editor"
],
"Uzume": [
"editor"
],
"V0lkanic": [
"global-renamer"
],
"VIGNERON": [
"steward"
],
"Valery Starikov": [
"editor"
],
"Van der Hoorn": [
"editor"
],
"Varnent": [
"vrt-permissions"
],
"Vdolar": [
"autoreview"
],
"VectorVoyager": [
"editor"
],
"Venzz": [
"vrt-permissions"
],
"Verfassungsfreund": [
"editor"
],
"Veritas Sapientiae": [
"global-rollbacker",
"global-renamer",
"vrt-permissions"
],
"Vermont": [
"editor",
"steward",
"vrt-permissions"
],
"Victor Stefan Stoica": [
"autoreview"
],
"Victor Trevor": [
"autoreview"
],
"Victoria.sandeman": [
"autoreview"
],
"Vincent Vega": [
"global-renamer"
],
"Vito Genovese": [
"editor"
],
"Vituzzu": [
"editor"
],
"Vladimir Solovjev": [
"global-renamer",
"vrt-permissions"
],
"Vogone": [
"global-rollbacker",
"editor"
],
"Vossman": [
"editor"
],
"Vrinda": [
"editor"
],
"VulcanWikiEdit": [
"editor"
],
"Vwanweb": [
"editor"
],
"WOSlinker": [
"autoreview"
],
"Waihorace": [
"global-rollbacker"
],
"Waldyrious": [
"editor"
],
"WalshDay": [
"editor"
],
"Wargo": [
"editor"
],
"Wbjimmyd": [
"editor"
],
"Wcoole": [
"editor"
],
"WeelkyWikiReader": [
"editor"
],
"Wekeepwhatwekill": [
"autoreview"
],
"WereSpielChequers": [
"editor"
],
"What no2000": [
"editor"
],
"WhatamIdoing": [
"editor"
],
"WhitePhosphorus": [
"global-rollbacker",
"global-sysop"
],
"Whiteknight": [
"editor"
],
"Whoop whoop pull up": [
"editor"
],
"Whym": [
"editor",
"vrt-permissions"
],
"Wiki13": [
"editor"
],
"WikiBayer": [
"global-rollbacker",
"global-sysop",
"editor"
],
"WikiFer": [
"vrt-permissions"
],
"Wikimi-dhiann": [
"editor"
],
"Wikiotics": [
"editor"
],
"Wikiwau": [
"autoreview",
"editor"
],
"WillNess": [
"editor"
],
"Willscrlt": [
"editor"
],
"Wim b": [
"global-rollbacker",
"global-sysop",
"editor"
],
"Wisden": [
"editor"
],
"Withinfocus": [
"editor"
],
"Wj32": [
"editor"
],
"Wkee4ager": [
"editor"
],
"Wobbit": [
"editor"
],
"Wojciech Pędzich": [
"vrt-permissions"
],
"Wong128hk": [
"global-renamer"
],
"Wooze": [
"global-rollbacker"
],
"Wundermacht": [
"editor"
],
"Wutsje": [
"global-rollbacker",
"editor"
],
"Ww2censor": [
"vrt-permissions"
],
"Wüstenspringmaus": [
"global-rollbacker",
"global-renamer"
],
"XXBlackburnXx": [
"editor",
"steward"
],
"Xandradi": [
"editor"
],
"Xania": [
"sysop",
"checkuser"
],
"Xaosflux": [
"editor",
"steward"
],
"XenonX3": [
"vrt-permissions"
],
"Xerol": [
"editor"
],
"Xeverything11": [
"editor",
"uploader"
],
"Xhungab": [
"editor"
],
"Xinkai Wu": [
"editor"
],
"Xixtas": [
"editor"
],
"Xqt": [
"global-rollbacker"
],
"Xxagile": [
"editor"
],
"Xypron": [
"editor"
],
"Xz64": [
"editor"
],
"Y-S.Ko": [
"editor"
],
"YMS": [
"editor"
],
"Yahya": [
"steward",
"vrt-permissions"
],
"Yamla": [
"global-renamer"
],
"Yann": [
"editor"
],
"Yerpo": [
"global-renamer",
"vrt-permissions"
],
"Yikrazuul": [
"editor"
],
"Ymblanter": [
"global-rollbacker"
],
"Yndesai": [
"editor"
],
"Youssefsan": [
"editor"
],
"Ysangkok": [
"editor"
],
"Yvelik": [
"uploader"
],
"Yzmo": [
"editor"
],
"ZI Jony": [
"editor"
],
"Zabe": [
"global-rollbacker"
],
"Zafer": [
"ombuds"
],
"Zedshort": [
"editor"
],
"ZeroOne": [
"editor"
],
"Zetud": [
"global-rollbacker",
"vrt-permissions"
],
"Ziv": [
"editor"
],
"Zoeannl": [
"editor"
],
"Zollerriia": [
"editor"
],
"Zoohouse": [
"editor"
],
"Zoot": [
"editor"
],
"Zsohl": [
"autoreview",
"editor"
],
"Zvsmith": [
"editor"
],
"Zweighaft": [
"editor"
],
"ZxxZxxZ": [
"editor"
],
"~riley": [
"global-rollbacker",
"editor"
],
"Érico": [
"global-renamer"
],
"Виктор Пинчук": [
"editor"
],
"Воображение": [
"editor"
],
"Всевидящий": [
"global-rollbacker"
],
"Д.Ильин": [
"editor"
],
"Л.П. Джепко": [
"editor"
],
"יהודה שמחה ולדמן": [
"editor"
],
"מקף": [
"global-rollbacker",
"global-renamer"
],
"د. فارس الجويلي": [
"global-renamer"
],
"روتانا": [
"global-renamer"
],
"علاء": [
"steward",
"vrt-permissions"
],
"فيصل": [
"global-renamer",
"vrt-permissions"
],
"सीमा1": [
"editor"
],
"タチコマ robot": [
"editor"
],
"ネイ": [
"global-renamer"
],
"一隻北極熊": [
"editor"
],
"人间百态": [
"global-rollbacker"
],
"臺灣象象": [
"autoreview"
],
"范": [
"vrt-permissions"
],
"青子守歌": [
"vrt-permissions"
],
"魔琴": [
"global-rollbacker"
],
"ꠢꠣꠍꠘ ꠞꠣꠎꠣ": [
"editor"
],
"기나ㅏㄴ": [
"global-rollbacker",
"global-renamer"
]
}
8hdg8xrmj0s1rih19igc82ghsaxal04
Chess Opening Theory/1. e4/1...d6/2. d4/2...Nf6/3. Nc3/3...c6
0
474916
4655986
4496561
2026-08-01T11:41:50Z
~2026-42369-15
3618467
Told some personal terms
4655986
wikitext
text/x-wiki
{{Chess Opening Theory/Position
|Czech Defense
|parent=[[../|Pirc Defense]]
}}
=Czech Defense=
===3...c6===
The Czech Defense is a flexible and multipurpose system within the Pirc family. The move 3...c6 serves several key functions: it supports control over critical squares b5 and d5, helping to prevent White’s knight or bishop from infiltrating there. Additionally, it opens up possibilities for Black’s queen to develop actively with ...Qa5 or ...Qb6.
Black often follows with ...Qc7, ...Nbd7, and ...Be7, aiming for a solid but dynamic structure where ...e5 or ...d5 can be played at the right moment. While the setup may look somewhat restrained, it provides Black with flexible counterplay options, including queenside expansion or timely central breaks.
It is considered the best counter-attack against Openings such as London System and can break the preperation of your opponent. This is an highly attacking opening and the first one to blunder in the game always loses!
==Theory table==
:'''1. e4 d6 2. d4 Nf6 3. Nc3 c6'''
{{ChessMid}}
==References==
{{reflist}}
{{BCO2}}
{{Chess Opening Theory/Footer}}
6qlk3z76ouljkxbriyvfc9n5l3ayqa4
Linear Algebra and the C Language/a013
0
477339
4655954
4555171
2026-07-31T17:35:59Z
Xhungab
545789
4655954
wikitext
text/x-wiki
__NOTOC__
'''Install this file in your working directory.'''
<syntaxhighlight lang="c">
/* ------------------------------------ */
/* Save as : vc_m.h */
/* ------------------------------------ */
/* ------------------------------------ */
double ** c_mR(
double **A,
double **B
)
{
int r;
int c;
for (r=R1; r<A[R_SIZE][C0]; r++)
for (c=C1; c<A[C_SIZE][C0]; c++)
B[r][c] = A[r][c];
return(B);
}
/* ------------------------------------ */
/* ------------------------------------ */
double **ca_A_mR(
double a[],
double **A
)
{
int r;
int c;
int i=0;
for (r=R1; r<A[R_SIZE][C0]; r++)
for (c=C1; c<A[C_SIZE][C0]; c++)
A[r][c] = a[i++];
return(A);
}
/* ------------------------------------ */
/* ------------------------------------ */
double **c_c_mR(
double **A,
int cA,
double **B,
int cB
)
{
int r;
for(r=R1; r<A[R_SIZE][C0]; r++)
B[r][cB] = A[r][cA];
return(B);
}
/* ------------------------------------ */
double **c_r_mR(
double **A,
int rA,
double **B,
int rB
)
{
int c;
for(c=C1; c<A[C_SIZE][C0]; c++)
B[rB][c] = A[rA][c];
return(B);
}
/* ------------------------------------ */
/* Copy the column cA of A into the row rB of B */
/* ------------------------------------ */
double **c_c_r_mR(
double **A,
int cA,
double **B,
int rB
)
{
int rc;
for(rc=RC1; rc<A[R_SIZE][C0]; rc++)
B[rB][rc] = A[rc][cA];
return(B);
}
/* ------------------------------------ */
/* Copy the row Ra of A into the column CB of B */
/* ------------------------------------ */
double **c_r_c_mR(
double **A,
int rA,
double **B,
int cB
)
{
int rc;
for(rc=RC1; rc<A[R_SIZE][C0]; rc++)
B[rc][cB] = A[rA][rc];
return(B);
}
/* ------------------------------------ */
/* ------------------------------------ */
double **c_c_D_mR(
double **AC,
double **AD
)
{
int r;
m0_mR(AD);
for(r=R1; r<AC[R_SIZE][C0]; r++)
AD[r][r] = AC[r][C1];
return(AD);
}
/* ------------------------------------ */
double **c_D_c_mR(
double **D,
double **U
)
{
int r;
int c;
for ( r=R1; r<D[R_SIZE][C0]; r++)
for ( c=C1; c<D[C_SIZE][C0]; c++)
if(r==c)
U[r][C1] = D[r][c];
return(U);
}
/* ------------------------------------ */
/* ------------------------------------ */
double **c_s_mR(
double s,
double **A,
int r,
int c
)
{
int Rmax = (A[R_SIZE][C0]-R1);
int Cmax = (A[C_SIZE][C0]-C1);
if( r<R1 ||
c<C1 ||
r> Rmax||
c> Cmax)
{
printf("\n Error : c_coef_R(); \n\n");
printf("\n R = %d; C = %d; \n",r,c);
printf("\n R and C must be : \n");
printf("\n R>=1; C>=1;\n R=<%d; C=<%d;\n",
Rmax,
Cmax);
printf("\n Press return to continue. \n");
fflush(stdout);
getchar();
exit(EXIT_FAILURE);
}
A[r][c] = s;
return(A);
}
/* ------------------------------------ */
/* ------------------------------------ */
double **c_r_reverse_order_mR(
double **U,
double **V
)
{
int c;
for(c=C1; c<U[C_SIZE][C0]; c++)
V[R1][csize_R(V)+C1-c] = U[R1][c];
return(V);
}
/* ------------------------------------ */
/* ------------------------------------ */
double **c_rU_rA_cn_mR(
double **U,
int rU,
double **A,
int rA,
int cn
)
{
int c;
for(c=C1; cn<A[C_SIZE][C0]; c++,cn++)
A[rA][cn] = U[rU][c];
return(A);
}
/* ------------------------------------ */
/* ------------------------------------ */
double **c_cV_cA_rn_mR(
double **V,
int cV,
double **A,
int cA,
int rn
)
{
int r;
for(r=R1; rn<A[R_SIZE][C0]; r++,rn++)
A[rn][cA] = V[r][cV];
return(A);
}
/* ------------------------------------ */
/* ------------------------------------ */
double **c_Uc_r_mR(
double **U,
int Uc,
double **A,
int rA
)
{
int c;
for(c=C1; Uc<U[C_SIZE][C0]-C1; c++,Uc++)
A[rA][c] = U[R1][Uc];
return(A);
}
/* ------------------------------------ */
/* ------------------------------------ */
</syntaxhighlight>
'''c_mR();''' copies matrix A into matrix B. It does not check the size of the matrices. Having this option in place has been a great help to me.
'''ca_A_mR();''' copies an array of numbers into a matrix.
'''c_c_mR();''' copies a column of A into a column of B.
'''c_r_mR();''' copies a row from A into a row from B.
'''c_c_r_mR();''' copies a column of A into a row of B.
{{BookCat}}
l1w0td5l3rp2uis55sqqqpsrpi1705c
Linear Algebra and the C Language/a0ff
0
478143
4655955
4584642
2026-07-31T17:39:19Z
Xhungab
545789
4655955
wikitext
text/x-wiki
__NOTOC__
== '''Copy a matrix''' ==
'''Copy an array of numbers into a matrix:'''
* [[Linear Algebra and the C Language/a0f6|ca_A_mR();]]
:
'''Copy a number into a matrix:'''
* [[Linear Algebra and the C Language/a0f7|c_s_mR();]]
:
'''Copy a matrix A into a matrix B:'''
* [[Linear Algebra and the C Language/a0f8|c_mR();]]
:
== Copy rows and columns ==
'''Copy a column or row from matrix A into matrix B :'''
* [[Linear Algebra and the C Language/a0f9|c_c_mR();]]
* [[Linear Algebra and the C Language/a0fa|c_r_mR();]]
:
'''Copy a column (row) of matrix A into a row (column) of matrix B:'''
* [[Linear Algebra and the C Language/a0j5|c_c_r_mR();]]
* [[Linear Algebra and the C Language/a0pk|c_r_c_mR();]]
:
'''Copy a row R1 into row R2 of a matrix:'''
* [[Linear Algebra and the C Language/a0fd|c_r1r2_mR();]]
:
'''Copy n rows of a matrix A into a matrix B:'''
* [[Linear Algebra and the C Language/a0j9|c_nr_mR(A,nR, B);]]
:
'''Copy a diagonal matrix into a one-column matrix:'''
* [[Linear Algebra and the C Language/a0ja|c_D_c_mR(D,U);]]
:
'''Copy a column matrix into a diagonal matrix:'''
* [[Linear Algebra and the C Language/a0jb|c_c_D_mR(U,D);]]
:
== Gauss-Jordan Utilities ==
'''Copy A and b into Ab:'''
* [[Linear Algebra and the C Language/a0fb|c_A_b_Ab_mR();]]
:
'''Copy A from Ab to A, and b from Ab to b:'''
* [[Linear Algebra and the C Language/a0fc|c_Ab_A_mR(); ... c_Ab_b_mR();]]
;
'''Copy the submatrix of Ab into subA:'''
* [[Linear Algebra and the C Language/a0j6|c_Ab_subArxr_mR();]]
:
'''Copy b of the system Ab into the matrix invA:'''
* [[Linear Algebra and the C Language/a0fe|c_Inv_A_mR();]]
:
== Index Matrix Utilities (R0) ==
'''Copy a matrix with row zero (R0: column position index):'''
* [[Linear Algebra and the C Language/a0j7|c_withR0_mR(A,B);]]
:
'''Copy a column with its index into another column:'''
* [[Linear Algebra and the C Language/a0j8|c_c_withR0_mR(A,C1, B,C2);]]
:
== Other utilities ==
'''Copy the row vector U in reverse order:'''
* [[Linear Algebra and the C Language/a0jc|c_r_reverse_order_mR(U,V);]]
:
'''Copy vector U into A as a Hankel matrix:'''
* [[Linear Algebra and the C Language/a0jd|c_Uc_r_mR(U,Cn, A,R2);]]
{{BookCat}}
hgj0r29qqayvqxin8zd4o244ah6ee3a
Taking Bearings: Artificial Intelligence in Knowledge Platforms and Open, Social Scholarship/AI and Social
0
483505
4655960
4655937
2026-07-31T19:48:12Z
CorreiaA
3614427
4655960
wikitext
text/x-wiki
== Platforms ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Burton, Jason W., Ezequiel Lopez-Lopez, Shahar Hechtlinger, et al. 2024. “How Large Language Models Can Reshape Collective Intelligence.” ''Nature Human Behaviour'' 8 (9): 1643–55. https://doi.org/10.1038/s41562-024-01959-9.'''
</div>
Large language models are quickly becoming infrastructure for how groups seek information, deliberate, and coordinate, potentially altering the conditions under which collective intelligence emerges. Burton and colleagues argue that LLMs do not merely speed up individual work but transform how information is aggregated, accessed, and transmitted across digital environments that underpin collective performance in organizations and societies. Drawing on interdisciplinary perspectives, the paper frames this shift as simultaneously enabling and destabilizing: LLMs can support distributed cognition (e.g., idea generation, synthesis, translation, scalable facilitation) while also increasing risks tied to dependence on shared intermediaries, degraded diversity of viewpoints, and new pathways for error, manipulation, or misplaced confidence. Rather than offering a single model or experiment, the article maps a research-and-practice agenda by identifying potential benefits, key hazards, and policy-relevant considerations, then articulating open questions that link technical design choices to group-level epistemic outcomes. Its central claim is that understanding collective intelligence in the LLM era requires moving analysis beyond isolated human–AI interactions toward system-level effects on networks, platforms, and institutions, and that these effects warrant focused study before LLM-mediated coordination becomes the default for tackling complex problems.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Corsi, Giulio, Bill Marino, and Willow Wong. 2024. “The spread of synthetic media on X.” ''Harvard Kennedy School (HKS) Misinformation Review''. https://doi.org/10.37016/mr-2020-140<nowiki/>.'''
</div>
Corsi and Wong’s longitudinal empirical study analyzes 566 tweets containing synthetic media (December 2022–September 2023) documenting a dramatic surge following Midjourney V5 release with over 1.5 billion total views, revealing differential impacts where political deepfakes achieve higher median views despite representing minority of synthetic content. The authors demonstrate that generative AI's impact is stratified by content purpose with political misinformation posing acute democratic risks, while current detection and labelling systems lag behind generative capabilities, creating governance gaps compromising users' capacity to evaluate information. Using Community Notes data from December 2022 to October 2023, the study highlights the connection between the growth in generative AI tools and the rapid proliferation of synthetic media. The findings indicate that most synthetic media is non-political and largely benign, frequently taking the form of humorous or satirical images. However, the study also identifies a smaller but concerning portion of malicious synthetic media, which have potential height risks despite their lower frequency. The authors further examine the role of X’s paid verification system, revealing that while verified users tend to receive more overall views, this advantage diminishes when engagement is adjusted for follower count, implying that verification alone provides limited amplification. The study casts light on synthetic media’s expanding presence on social platforms and warns that even widespread exposure to seemingly harmless AI-generated content may gradually undermine trust in online information. To address these challenges, the authors recommend ongoing empirical monitoring, stronger collaboration between researchers and industry to develop transparent detection tools, and proactive policy measures aimed at reducing the social and political harms posed by malicious synthetic media.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Delmonaco, Daniel, Samuel Mayworm, Hibby Thach, Josh Guberman, Aurelia Augusta, and Oliver L. Haimson. 2024. “‘What are you doing, TikTok?’: How Marginalized Social Media Users Perceive, Theorize, and ‘Prove’ Shadowbanning.” https://oliverhaimson.com/PDFs/DelmonacoShadowbanning.pdf. '''
</div>
Delmonaco et al.’s qualitative study explores marginalized social media users’ experiences with shadowbanning through the theoretical framework of algorithmic “folk theories.” Through a review of existing literature, the authors demonstrate how social media companies publicly distance themselves from shadowbanning while continuing to apply it in practice and explain why content produced by marginalized users is more frequently subject to filtering. The study analyzes 24 interviews to explore how users perceive, theorize, and attempt to “prove” shadowbanning through indicators such as decreased visibility, engagement, and follower loss. The findings reveal widespread confusion surrounding shadowbanning, deep mistrust in platform governance, and the disproportionate harm imposed on marginalized communities whose content is suppressed despite platforms’ public denials. The data further shows how users collectively produce and co-produce theories to resist the opacity of algorithmic moderation, and authors introduce “collaborative algorithm investigation,” in which users test and share algorithmic folk theories with one another. The authors argue that algorithmic content moderation exacerbates existing inequities by obscuring governance decisions, politicizing moderation, and shifting power from human judgment to opaque predictive systems, while suggesting that increased transparency, tailored moderation approaches, and users’ education could help reduce unfair content removals.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Drolsbach, Chiara, and Nicolas Pröllochs. 2025. “Characterizing AI-Generated Misinformation on Social Media.” Preprint, ''arXiv'', May 15. https://doi.org/10.48550/arXiv.2505.10266<nowiki/>.'''
</div>
Drolsbach and Pröllochs’ article address a critical gap in existing research by shifting attention from the social drawbacks of AI-generated misinformation to its real-world prevalence and behaviour on social media platforms. Using a large-scale dataset of 91,452 misleading posts identified through X’s Community Notes platform, the authors empirically compare AI-generated and non-AI-generated misinformation across content characteristics, account attributes, virality, believability, and harmfulness. Their findings show that AI-generated misinformation is more entertainment-oriented, exhibits more positive sentiment, and is more likely to originate from smaller accounts, yet achieves significantly higher virality despite being slightly less believable and harmful than traditional misinformation. In their discussion and conclusion, the authors emphasize that AI-generated misinformation poses a growing challenge to the digital information ecosystem due to its realism, scalability, and difficulty of detection. They argue that its unique features disturb algorithmic amplification mechanisms and require new platform strategies, policy interventions, and research approaches that account for the unique properties of AI-generated misinformation rather than relying on countermeasures designed for conventional false content.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Duricic, Tomislav, Hussain Hussain, Emanuel Lacic, Dominik Kowald, Denis Helic, and Elisabeth Lex. 2023. “Beyond-Accuracy: A Review on Diversity, Serendipity, and Fairness in Recommender Systems Based on Graph Neural Networks.” ''Frontiers in Big Data'' 6: 1251072. https://doi.org/10.3389/fdata.2023.1251072.'''
</div>
Duricic et al. (2023) provide a comprehensive review of recommender systems based on Graph Neural Networks (GNNs), with a particular focus on objectives that go beyond prediction accuracy, including diversity, serendipity, novelty, and fairness. While GNNs have demonstrated strong performance in modeling complex user–item interactions and improving recommendation accuracy, the authors argue that this very strength can intensify structural biases such as popularity bias, homophily, and feedback loops that marginalize less popular content and users. The paper provides a definition of each beyond-accuracy metric, reviews how it has been used in literature, and analyzes the technical barriers of integrating these goals into GNN-based systems such as measurement difficulties, trade-offs between competing goals, and risks of overfitting due to model complexity. Diversity-aware neighbourhood sampling, contrastive learning, and adversarial training to disrupt feedback loops are introduced for more heterogeneous and unexpected recommendations. In conclusion, the authors position GNNs as a powerful but double-edged tool in recommendation systems, capable of either narrowing or broadening users’ informational horizons depending on design choices. They argue that future research must focus on principled frameworks that integrate “beyond-accuracy” objectives, emphasizing that recommendation algorithms are not neutral optimizers but key socio-technical systems shaping visibility, voice, and fairness in digital information ecosystems.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gorwa, Robert, Reuben Binns, and Christian Katzenbach. 2020. “Algorithmic Content Moderation: Technical and Political Challenges in the Automation of Platform Governance.” ''Big Data & Society'' 7 (1): 1–15. https://doi.org/10.1177/2053951719897945.'''
</div>
Gorwa et al. unfold what "Algorithmic moderation systems” are perceived as essential in AI governance to address the public demand on AI accountability and transparency that remain unnavigable and inexplicable, such that even the enhanced versions could aggravate the existing misinformation issues. They state that major platforms' growth transforms them so much that they no longer function primarily as social networks. They define “algorithmic moderation” as “systems that classify user generated content based on either matching or prediction, leading to a decision and governance outcome (e.g. removal, geoblocking, account takedown).” Different types of hashing (matching) and classification (prediction) tools and the areas they are deployed (copyright, terrorism, and toxic speech) are described and their practicality are criticized. Their case analyses including copyright enforcement, counterterrorism, and toxic speech illustrate the limitations and unintended harms of automated moderation, demonstrating how even “improved” systems risk reinforcing misinformation patterns, entrenching platform power, and displacing human judgment. Ultimately, Gorwa et al. argue that algorithmic moderation transforms platform governance itself by concentrating authority in opaque technical systems while rendering the underlying political choices invisible.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Reynolds, C. J., and Blake Hallinan. 2024. “User-Generated Accountability: Public Participation in Algorithmic Governance on YouTube.” ''New Media & Society'' 26 (9): 5107–5129. https://doi.org/10.1177/14614448241251791. '''
</div>
This study focuses on how YouTube creators respond to platform governance decisions by producing “user-generated accountability” content, videos that publicly document governance failures and pressure YouTube to intervene. Through an analysis of 250 such videos, the authors state that creators overwhelmingly experience YouTube’s policy enforcement, automated moderation systems, and communication practices as opaque, inconsistent, and often discriminatory. Authors declare that human review is essential in automizing platform governance. The study highlights that platform governance decisions affect creators differently depending on channel size, content type, and identity; larger creators can more easily mobilize audiences to “make noise,” while smaller creators rely on collective visibility tactics such as signal boosting across platforms, especially Twitter. The authors argue that these bottom-up accountability practices reflect both the limits of YouTube’s existing governance infrastructure and creators’ efforts to bypass scale dependent unresponsiveness by publicly sharing grievances, comparing experiences, and testing the platform’s algorithms themselves. Theoretically, the study provides the “user-generated accountability” as a framework for engaging with the unavoidable conflicts that will arise around algorithmic systems, and views content creators as “political actors” who advance the perceptions of algorithms. Empirically, it surfaces common concerns such as demonetization of LGBTQ content, and lack of human review.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Savolainen, Lotta. 2022. “The Shadow Banning Controversy: Perceived Governance and Algorithmic Folklore.” ''Media, Culture & Society'' 44 (6): 1091–1109. https://doi.org/10.1177/01634437221077174.'''
</div>
Savolainen studies shadowbanning as a lens for understanding current algorithmic platform governance from the user perspective. Rather than determining whether shadowbanning objectively exists, the author conceptualizes it as “algorithmic folklore”: informal, collectively produced narratives through which users attempt to make sense of opaque moderation and ranking systems. Drawing on Reddit discussions about TikTok, Instagram, and YouTube, the study shows how users interpret suppressed visibility through anecdotal evidence, experimentation, and shared pattern recognition, revealing the experiential dimensions of algorithmic governance. Either users “probe the rules” or find their ways through “pleasing the algorithms”; the author argues that these practices emerge in response to governance systems that lack the clarity, stability, and consistency that are traditionally associated with good governance. The study concludes that platform governance contains a structural paradox: platforms increasingly present themselves as legitimate governors while simultaneously developing automated moderation systems that undermine transparency and consistent enforcement. Ultimately, the ethical issue is not shadowbanning itself, but the broader reality of shadowy governance exercised by complex, distributed algorithmic systems at scale.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Vetter, Matthew A., Jialei Jiang, and Zachary J. McDowell. 2025. “An Endangered Species: How LLMs Threaten Wikipedia’s Sustainability.” ''AI & Society'', February. https://doi.org/10.1007/s00146-025-02199-9.'''
</div>
Vetter et al. caution against using Wikipedia as AI training data uncritically by outlining many complicating factors. Wikipedia’s collaborative model of data curation democratizes data creation, but embeds power dynamics and biases. A feminist posthumanist framework is applied, which situates Wikipedia’s knowledge as contextual, based upon the positionality of predominantly Western, male editors, a perspective LLMs would perpetuate without opportunity for change. Wikipedia’s "dynamism" is the main reason it is so valuable, stemming from constant, collaborative updates by volunteers. AI responses’ inconsistent citations and plagiaristic tendencies undermine human editors, the source of Wikipedia’s verifiability, and exploit scholars, Wikipedia itself, and the past labour of volunteers. Wikipedia needs both "a steady stream of new and returning readers" and "a diverse group of dedicated volunteers," whilst AI responses push sources into obscurity and at best detour the website, threatening Wikipedia’s long-term sustainability. Vetter et al. practically explore Wikipedia’s relationship with LLMs by conducting a "problem-centred expert interview" of community leaders, who possess 25 combined years of involvement and research. Through these interviews, Vetter et al. identify three main areas of opportunity: promoting transparency and explainability, diversifying the Wikipedia community, and equipping users with critical thinking skills. Overall, their findings "resonate with the posthumanist approach to critical AI literacy," cautioning against hoping for purely technological fixes and calling for greater transparency in how tech giants "leverage open-access datasets."
== Governance, Leadership, and Policy ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Balendra, Soorya. 2025. “Meta's AI Moderation and Free Speech: Ongoing Challenges in the Global South.” ''Cambridge Forum on AI: Law and Governance'' 1. https://doi.org/10.1017/cfl.2025.5<nowiki/>.'''
</div>
This article conducts a case study of Meta’s AI-based content moderation in the Global South, arguing that the censorship of unprohibited content (“over removal”) and slow response to content that causes harm (“slow removal”) are part of “content moderation procedures” that constitute “massive discriminatory approaches.” Balendra presents three models of authority for the regulation of social media content: external regulation, self-regulation, and co-regulation, and argues that state regulation (falling under the external model) varies wildly depending on the government in question, with “granting absolute regulatory power to state actors often stifl[ing] political discourse and online expression.” Co- and self-regulation mitigate this problem, but introduce a new issue by shifting responsibility—private companies use AI to make millions of judgements about content in a short frame of time. The paper notes that the EU and the United States have drastically different policies regarding content moderation on social media platforms and argues that “the practice of content moderation remains largely shaped by the cultural norms of the United States” and the values of “a relatively homogenous groups of Silicon Valley elites.” Balendra finds that, at this time, current approaches often prioritize the state or private corporate interests rather than free speech or the interests of the larger community, and much work is needed to “achiev[e] genuine change” in the form of integrated, hybrid approaches.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Birkstedt, Teemu, Matti Minkkinen, Anushree Tandon, and Matti Mäntymäki. 2023. “AI Governance: Themes, Knowledge Gaps and Future Agendas.” ''Internet Research'' 33 (7): 133–67. https://doi.org/10.1108/INTR-01-2022-0042. '''
</div>
Birkstedt et al. conduct a systematic literature review (SLR) of the emerging yet fragmented field of “AI governance” (AIG), defined as “a system of rules, practices, processes, and technological tools” that ensure organizational AI meets strategic, legal, and ethical requirements. The authors use human-centric and socio-technical AI traditions to explore how organization-level governance mechanisms can bridge the principles-to-practices gap in AI ethics. Through SLR, authors identify four research agendas. The “technical agenda” focuses on the practicalities of AIG. The “stakeholder and contextual agenda” ensures AI meets requirements via direct collaboration with external stakeholders, increased corporate social responsibility, and establishment of an “intelligent discourse regime.” The “regulatory agenda” aligns AIG with ethical and legal standards, while the technical, stakeholder and contextual, and regulatory agendas largely focus on the aims of organizational AIG (i.e., what), and the process agenda deals with the means to achieve the aims (i.e., how). The authors develop a generic framework to guide cohesive AIG practices and advocate for a collaborative governance approach that emphasizes transparency, stakeholder engagement, and sociopolitical awareness.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Broekhuizen, Thijs, Henri Dekker, Pedro De Faria, Sebastian Firk, Dinh Khoi Nguyen, and Wolfgang Sofka. 2023. “AI for Managing Open Innovation: Opportunities, Challenges, and a Research Agenda.” ''Journal of Business Research'' 167 (November 2023): 114196. https://doi.org/10.1016/j.jbusres.2023.114196. '''
</div>
Broekhuizen et al. systematically analyze how AI could be applied to the complex, unstructured task of “open innovation,” a possible business opportunity they believe has been insufficiently explored. They define “Open innovation” as “the practice of leveraging external ideas, resources, and capabilities to improve innovation outcomes,” and propose AI could minimize its inherent managerial challenges. To prove this, the authors form a framework that considers the three abilities involved in AI’s agreed possible applications to management (involving “mapping,” “coordinating,” and “controlling”) and assess how applicable their constituent functions are to the challenges of the three stages of open innovation (involving “initiation,” “development,” and “realization”). In the stage of “initiation,” they propose AI could scout for distant knowledge partners, detect relevant information gaps and opportunities, and forecast conflicts. During the “development” stage, AI could develop complementarity between partners' knowledge stocks, integrate knowledge whilst safeguarding intellectual property, and monitor partners for violations or conflicts within the relationship. Finally, during the “realization” stage the authors argue AI could comprehensively evaluate business opportunities, optimize resource deployment, and diagnose or remedy intellectual property violations. To Broekhuizen et al., this study “underscores the significance of the human-side of AI” by demonstrating AI’s valuable role in assisting management. They also conclude that AI’s ability to search for corporate partners will be its greatest impact in open innovation, as they argue it will both incentivize openness and reputability of companies and increase the need for them to keep sensitive data secure.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Cheong, Inyoung. 2024. “Collaborative Approaches to AI Governance: Exploring Co-Design and Co-Regulation Models.” PhD diss., University of Washington. https://homes.cs.washington.edu/~yoshi/papers/theses/inyoung-cheong-dissertation.pdf<nowiki/>.'''
</div>
This dissertation seeks to integrate co-design and co-regulation as a means of facilitating domain-specific expert knowledge into AI governance policies. It uses theoretical analysis and empirical data as part of its methodologies, and it should be of interest to anyone who wants detailed case studies of the use of AI technology in specific domains, as well as clear models for (co-)governance and development in the use of Artificial Intelligence. Cheong performs two case studies, examining the development and use of an AI application to provide legal advice as well as the application of AI in online content moderation of news and comics apps in South Korea. These result in a set of strategies for AI co-regulation that includes parameters for starting conditions, institutional design, collaborative process, and facilitative leadership. Cheong proposes that the guiding principles for AI co-governance must account for specific and distinct contexts, maintain human involvement and intervention in what is often seen as an artificial and automated process, and look to resolve legal ambiguities surrounding AI, especially as there is a clear history of courts dismissing what Cheong calls “collective rule-making” by the community. The author argues for the implementation of co-regulation and co-design, and maintains that “by fostering inclusive dialogues, leveraging diverse expertise, and remaining adaptable to changing technological and societal landscapes” these methods show potential for dealing with AI’s greatest challenges.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Floridi, Luciano. 2018. “Soft Ethics and the Governance of the Digital.” ''Philosophy & Technology'' 31 (1): 1–8. https://doi.org/10.1007/s13347-018-0303-9<nowiki/>.'''
</div>
Floridi argues our “mature information societies” means “we no longer live online or offline, but onlife,” making the sociopolitical challenge of ethically governing this foundational “digital age” even more vital than pursuit of future digital innovations. Floridi defines three overlapping subfields within the “Governance of the Digital,” including “Digital Ethics,” “Digital Regulation,” and the encompassing “Digital Governance.” The latter is defined as “the practice of establishing and implementing policies, procedures, and standards for the proper development, use and management of the infosphere,” therefore “sometimes neither moral nor immoral… legal nor illegal.” This demonstrates that the three subfields don’t always overlap, but each must always be considered by policymakers, because what is legal, what is good, and what is best are all key components of the ideal “Governance of the Digital.” “Digital Ethics” should also be further subdivided into “hard” ethics, involving binary moral judgments about what should versus should not be done, and “soft” ethics, which involves a “post-compliance,” “post-feasibility” approach, ensures moral opportunities are maximized, and fosters “good corporate citizenship.” Differing “information societies” occupy differing levels of maturity, producing distinct ethical contexts which should progress with differing ethical focuses. In this regard, Floridi advocates “ethics foresight analysis,” which uses data analytics to assess ethical impacts of future innovations then targets research by systematically identifying what is feasible, then sustainable, then acceptable, then preferable. The author concludes that Digital Ethics must be “leading” not “chasing” developments, and not just functioning as a questioning exercise, but also signalling that ethical issues matter, engaging with stakeholders, and providing shareable solutions.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gasser, Urs, and Virgilio A. F. Almeida. 2017. “A Layered Model for AI Governance.” ''IEEE Internet Computing'' 21 (6): 58–62. https://doi.org/10.1109/MIC.2017.4180835<nowiki/>.'''
</div>
This article identifies the gap in knowledge created by the “black box” of AI—the obscured nature of the processes that take place from an initial prompt to its generated output. Gasser et al. note that users and policymakers of these technologies have relatively little insight into how it actually works compared to its developers. Given this unique issue, Gasser et al. propose a theoretical framework for how to approach AI governance, drawing upon the advent and subsequent globalization of the Internet to inform their understanding of AI technology and its pattern of growth. The article addresses a core issue that strong or general AI is often discussed in terms of potential societal impact while weak or general AI is currently being deployed right now (i.e., 2017) and is in real need of governance already. The authors identify core themes related to “transparency, accountability, and explainability; inclusion and fairness; [and] global governance,” as well as three challenges for AI governance—"information asymmetries”; “finding normative consensus”; and “government mismatches”. The authors point out that the ethical and legal considerations of AI are closely related and take a modularity approach; they present three layers for governance that exist from AI systems to society, with timing (i.e., near-, mid-, and long-term) and considerations for each layer. The article concludes by proposing AI governance requires a blended approach based on the different risks of certain AI applications and propose that both “market-oriented solutions” and "government-based structures” can work on a national or international level, suggesting a “global oversight body” could act as “the curator of global principles and emerging norms for AI systems.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Kirschenbaum, Matthew. 2025. “The US of AI.” Public Draft, February 25, 2025. https://drive.google.com/file/d/1O2qkjhg7Ei5zZWmBraNwXq4V0lTauspN/view<nowiki/>.'''
</div>
This set of notes from Kirschenbaum represents his “near real-time attempt to come to terms with… the opening weeks of the second Trump Administration,” especially the “AI-first” strategy of “the so-called Department of Government Efficiency (DOGE).” Kirschenbaum outlines DOGE has nothing to do with government efficiency, as it only saves insignificant costs, instead possessing ideological and capitalistic motivations to form “a government without people.” Based on Musk’s nebulous authority—as an advisor from the private sector—DOGE targeted nineteen federal agencies to be “strip-mined and fracked for all manner of information” as a “priceless and unprecedented resource” of AI training data. To do so, DOGE operatives accessed sensitive spaces after hours, combining physical aggression with a “complete lack” of technical inhibition representing a “vampiric data suck.” Kirschenbaum identifies clear corporate interests here and further examines ideological aims. Early executive orders asserted the need for federal AI systems “free from ideological bias or engineered social agendas,” with OpenAI announcing “ChatGPT Gov” days later. These invocations of “AI” as a universal solution represent only a “linguistic token” instead of any realized technology—as worded by Salvaggio, AI must only “be considered a plausible competitor to human decision-making long enough to dislodge the existing human decision-makers.” Kirschenbaum frames this as based in the “masculine maximalism” of the Trump administration, as the term AI promotes “technological absolutism” whilst theoretically playing into the Nixon-era “theory of the unitary executive” by aiming to replace people with “void” and consolidate power into the hands of “a super-user class who will operate outside the system.” However, “the real world intrudes… with lethal downstream effects.” Kirschenbaum proposes “a collapsing superimposition of political discourse, the actual operations of social media as its primary public arena, and the technical architecture of the systems (in the form of AI)… in the sphere of governance as well as media,” which produces the “infrastructure for… permanent despotism” via the “untethering of language from conditions of lived reality.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Oh, Dayei, and John Downey. 2024. “Does Algorithmic Content Moderation Promote Democratic Discourse? Radical Democratic Critique of Toxic Language AI.” ''Information, Communication & Society'' 28 (7): 1157–76. https://doi.org/10.1080/1369118X.2024.2346531.'''
</div>
Oh and Downey critically examine how algorithmic content moderation shapes public discourse, focusing specifically on Google’s Perspective API and its detection of "toxic" language. By drawing a crucial distinction between incivility (harsh or emotional tone) and intolerance (actual discriminatory harm), the authors demonstrate how AI-driven moderation systems frequently misinterpret context. Consequently, these algorithms often suppress emotionally charged but politically significant speech—particularly from marginalized groups—while allowing structurally discriminatory but politely phrased content to evade detection. This dynamic reveals a significant flaw in relying on AI as a neutral mediator of digital dialogue: by prioritizing tone over substance, algorithmic moderation actively curtails democratic participation and skews the visibility of diverse perspectives. Their study is relevant for understanding how AI systems act as invisible gatekeepers, enforcing normative boundaries on public expression and highlighting the urgent need for moderation frameworks that are contextually aware, transparent, and equitable rather than merely tone-policing.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Rughiniș, Cosima, et al. 2025. “AI at the Knowledge Gates: Institutional Policies and Hybrid Configurations in Universities and Publishers.” ''Frontiers in Computer Science'' 7: 1608276. https://doi.org/10.3389/fcomp.2025.1608276. '''
</div>
This article constitutes a qualitative analysis (i.e., a form of computational analysis) of 16 universities and 12 publishers that attempts to understand how these institutions regulate AI in knowledge production. Rughinis et al. claim that most institutions preserve their values while regulating AI by adapting the regulations they already have in place, stating “institutional policies are shaped by value-based compromises and not by technical concerns alone.” At the same time, although the article acknowledges its focus on institutional regulation, it also admits that “AI adoption can evolve both through policy frameworks and… locally embedded practices that remain partly invisible in formal documentation.” The authors propose two concepts, “dual black-boxing” and “legitimacy-dependent hybrid actors.” Dual black-boxing refers to the lack of transparency in both the “hidden algorithmic processes [and] invisible training data” that shape AI systems and “the opacity surrounding how academics employ AI in their work,” while legitimacy-dependent hybrid actors are “configurations of human-AI collaboration whose institutional legitimacy is not intrinsic but conditional.” Rughinis et al. argue that transparency is a core academic value, and scholars must work to open these black boxes; they also suggest that that transparency is more closely linked to academic legitimacy in AI-related issues rather than the more traditional issue of the origin of ideas. The majority of the article applies these terms to understanding the regulatory frameworks of universities and publishers, and concludes with the understanding that the majority of institutions allow some form of AI use within certain parameters. The key types of hybrid actors allowed by universities were AI-assisted researchers, AI-enabled translators, AI-enhanced writers, and AI-supported coders, while publishers facilitated the use of AI to refine language, support research methodologies, and aid in research. Ultimately, the authors observe that institutions are permitting AI-supported work in refined roles and argue that AI-based academic work gains legitimacy through transparency.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Seger, et al. “Democratising AI: Multiple Meanings, Goals, and Methods.” ''Proceedings of the 2023 AAAI/ACM Conference on AI, Ethics, and Society''. https://dl.acm.org/doi/10.1145/3600211.3604693<nowiki/>.'''
</div>
Aiming to “provide a foundation for more productive conversations,” Seger et al. categorize four forms of “AI democratisation” and explore each form’s goals and facilitation pathways. Democratization of AI “use” involves making it easier for people to employ AI’s capabilities, and is therefore equally comparable to increasing availability of printers or of tools which can create chemical weaponry, depending on the case. Democratization of “development” involves allowing a wider range of people to contribute to the AI design and development process, which accelerates progress and increases diversity, but also opens the door for maliciousness and irresponsibility. Democratizing “profits” constitutes a philanthropic or redistributive process, and has the predictably involved weaknesses. Therefore, the authors highlight that “AI democratisation is a multifarious and sometimes conflicting concept” which “should not be conflated with improving AI accessibility” and “is not inherently good.” This is because democratization of AI’s “use,” “development,” and “profits” only derives value from its alignment with the interests and values of impacted groups, making democratization of AI’s “governance” the priority. Democratization of “governance” does not necessarily aim for total agreement amongst constituents, but will regardless reduce the unilaterality of decision-making by promoting justice, legitimacy, and diversity.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Sposato, Martin. 2025. ”Artificial Intelligence in Educational Leadership: A Comprehensive Taxonomy and Future Directions.” ''International Journal of Educational Technology in Higher Education'' 22 (20). https://doi.org/10.1186/s41239-025-00517-1. '''
</div>
This article performs an analysis and review of published works on AI in educational leadership from 2017–2024 and uses the results of that process to develop what Sposato describes as “a comprehensive taxonomy of AI applications in educational leadership.” Potential readers include researchers and policymakers interested in communicating across specific fields and disciplines. Sposato theorizes ten application domains for AI in higher education ranging from increased efficiency in administration and teaching practices to increased community engagement and strategic planning. The purpose of such a framework is to provide educational leaders with a coherent vocabulary of “the full spectrum of educational leadership responsibilities” that can facilitate further conversation. The author advocates for AI’s transformative potential in higher education even as they note important challenges (especially with ethics and equity), arguing a need for a balanced approach and “robust ethical guidelines and regulatory frameworks.” The framework provided is presented as one step toward developing AI literacy for stakeholders so that all involved in education might make more informed decisions and articulate their needs more clearly.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Ter-Minassian, Lucile. 2025. ”Democratizing AI Governance: Balancing Expertise and Public Participation.” Preprint, ''arXiv'', January 16. https://doi.org/10.48550/arXiv.2502.08651<nowiki/>.'''
</div>
Ter-Minassian argues that “universal access, technically-constrained development, and universal impact” of AI and AI research necessitate public participation in AI governance even as it “creates a unique governance challenge.” The article presents the benefits and challenges of expert oversight and public consultation. Ter-Minassian outlines the threat of misinformation to meaningful public participation, highlighting how both undue fear and unrealistic optimism surrounding AI can affect public discourse, while acknowledging that the rapid rate of AI research makes it difficult to incorporate truly democratic processes into the decision-making process. The author concludes that any ongoing inclusive and effective AI governance ought to incorporate inclusive representation, balance expertise and public engagement, embrace transparency and accountability while engaging an iterative process, and implement a hybrid framework that “blend[s] expert knowledge with meaningful public input” (4). She argues that “AI’s deep societal impact calls for public engagement” and “technical complexity does not have to exclude meaningful public input,” advocating for “structured deliberation and phased public participation” to address “time-sensitive AI challenges without compromising democratic legitimacy” (5). Ultimately, the article sees this as an iterative process that will need to continue to adapt in order to maintain expert insight and public discourse on AI.
== Critical Literacies ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Aguiar, Micaela, and Sílvia Araújo. 2024. “Final Thoughts: Digital Humanities Looking at Generative AI.” ''In Digital Humanities Looking at the World'', edited by S. Araújo et al., 367-380. Cham: Springer Nature Switzerland.'''
</div>
Aguiar and Araújo explore the emergence and applications of generative artificial intelligence within Digital Humanities research. They trace the evolution of generative AI from early implementations like the 1960s Eliza chatbot through its developments such as Generative Adversarial Networks (GANs) and the Transformer architecture to contemporary large language models like BERT and GPT. The authors document current applications of generative AI across Digital Humanities domains, including cultural heritage preservation, historical text processing, and literary creation. They outline how these technologies are being used to memorialize mass atrocities, process traditional Chinese ancient texts, and explore collaborative human-AI poetry creation. Aguiar and Araújo examine the inner workings of generative AI, particularly focusing on how conversational models function through statistical prediction rather than genuine comprehension. They identify limitations such as hallucinations, bias replication, and attribution problems that researchers must consider when using these tools. The chapter concludes that effective integration of generative AI in Digital Humanities requires developing AI literacy skills that enable researchers to critically evaluate outputs while leveraging the technology's capabilities for sustainable research advancement.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Boer, Victor de, and Lise Stork. 2024. “Hybrid Intelligence for Digital Humanities.” Preprint, ''arXiv'', April 15. https://doi.org/10.48550/ARXIV.2406.15374. '''
</div>
De Boer and Stork believe the discipline of Digital Humanities (DH) should meet the challenges and opportunities posed by Artificial Intelligence (AI) by adopting the “human-centric paradigm” of Hybrid Intelligence (HI). They define DH as “a scholarly realm where computing or digital technologies intersect with… the humanities… characterized by innovative approaches to scholarly endeavors,” and identify various existing DH approaches to AI, which include “Knowledge Representation,” “Machine Learning,” “Natural Language Processing,” and “Computer Vision.” De Boer and Stork argue successfully integrating AI tools into DH requires embedding AI in scholarly practice, adopting a diverse and polyvocal approach, considering the debate of distant versus close reading, and applying a critical stance toward data, methods, and tools. HI “concerns itself with the investigation and design of human-AI ecosystems,” and the authors argue effective AI should be developed by following its “CARE” principles—being “Collaborative, Adaptive, Responsible, and Explainable.” Therefore, De Boer and Stork focus this text on mapping CARE principles to those DH requirements earlier outlined. Overall, they concur with Goodlad and Baker that humanists “are ideal 'domain experts' for the current juncture,” and end by identifying two overarching challenges. The first challenge is “one-shot solutions,” including tools, datasets, and methods that aren’t reusable, Open Source, accessible, and well described. Secondly, they identify the human factor—actors will need both an open mind and AI literacy to be equally critical of and cooperative with AI. Therefore, the authors emphasize the importance of teaching digital methods within the humanities curricula.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Carmi, Elinor, Simeon J. Yates, Eleanor Lockley, and Alicja Pawluczuk. 2020. “Data Citizenship: Rethinking Data Literacy in the Age of Disinformation, Misinformation, and Malinformation.” ''Internet Policy Review'' 9 (2). https://doi.org/10.14763/2020.2.1481.'''
</div>
This study argues that dominant understandings of digital and data literacy are insufficient for addressing contemporary complex challenges of disinformation, misinformation, and malinformation. They propose the concept of data citizenship to reframe literacy as a fundamentally civic, political, and collective practice rather than a set of individual technical skills. The authors contend that information disorders cannot be addressed through technological solutions alone, as they are deeply embedded in structural inequalities, platform economies, and power asymmetries shaping datafied societies. The article builds on a literature review and secondary data analysis drawing on Me and My Big Data project, alongside the development of a nationally representative UK survey. The authors identify three major gaps in existing literacy frameworks: an overemphasis on individual competence rather than networked practices, a lack of critical engagement with algorithmic and economic infrastructures of platforms, and the absence of proactive civic skills such as contesting data extraction, demanding transparency, and advocating for data justice. Their analysis highlights how citizens’ data practices are shaped by social networks, education, and socio-economic conditions, revealing unequal capacities for verification, protection, and collective action. The authors conclude that data literacy must move beyond content verification to include critical understanding of platform design, funding models, and algorithmic governance. They emphasize the importance of locally grounded, participatory approaches to data literacy education that reflect diverse lived contexts rather than scalable, top-down interventions. While the study offers a robust conceptual model and survey-based insights, it does not yet include in-depth qualitative engagement with citizen groups, which the authors position as a necessary next phase of research. Overall, the article makes a significant contribution by bridging digital literacy and the field of mis/dis/mal information research and claims that data literacy is an essential component of democratic citizenship.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Long, Duri, and Brian Magerko. 2020. “What is AI Literacy? Competencies and Design Considerations.” In ''Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems'', 1–13. New York, NY: Association for Computing Machinery. https://doi.org/10.1145/3313831.3376727.'''
</div>
The authors present an exploratory review of interdisciplinary literature, aiming to organize key ideas on AI literacy definitions and essential competencies. Authors claim that public misunderstandings of AI are due to design, educational gaps, black-box algorithms, and a general lack of technological knowledge. The review includes two sections: how the public understands specific AI systems, and how existing research addresses people’s broader understanding of AI. Rather than offering an exhaustive synthesis, Long and Magerko’s focus is on non-technical audiences and they offer central provocations and design principles that can inform educational interventions. The proposed conceptual framework on AI literacy identifies 17 core competencies alongside 14 design considerations for educational intervention, which are described and supported by relevant literature. Together, these considerations position the framework as a practical and reflective tool for designing AI literacy interventions that move beyond dominant media narratives and foster critical, informed engagement with AI technologies.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Majdik, Zoltan P., and S. Scott Graham. 2024. “Rhetoric of/with AI: An Introduction.” ''Rhetoric Society Quarterly'' 54 (3): 222–31. https://doi.org/10.1080/02773945.2024.2343264. '''
</div>
Majdik and Graham propose a field-organizing distinction that functions as a methodological argument. By splitting inquiry into “rhetoric of AI” (AI as object) and “rhetoric with AI” (AI as method), they treat AI simultaneously as a rhetorical actor/ecosystem component that structures attention, circulation, and uptake, and an instrument that can be enrolled into rhetorical research workflows. The authors claim that much prior rhetorical work engaged “spaces of AI”—platforms, devices, and algorithmically mediated environments—while leaving “AI” itself undertheorized as the central object; this provides a justification for why rhetoricians should now foreground model/algorithmic operations (and their harms) rather than treating them as neutral background conditions of digital rhetoric. They also frame generative text systems as a stress test for core rhetorical concepts—agency, authorship, and audience—because these systems destabilize the presumed linkage between human intention and textual production, and because they insert nonhuman intermediaries into communicative situations that education and public discourse still normatively treat as human-to-human. The introduction then uses this distinction to stage the special issue’s contributions as complementary routes for rebuilding rhetorical theory and pedagogy under AI conditions.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Ng, Davy Tsz Kit, Jac Ka Lok Leung, Samuel Kai Wah Chu, and Maggie Shen Qiao. 2021. “Conceptualizing AI Literacy: An Exploratory Review.” ''Computers and Education: Artificial Intelligence'' 2: 100041. https://doi.org/10.1016/j.caeai.2021.100041. '''
</div>
This article presents an exploratory review of literature published between 2016 and 2021 with the goal of conceptualizing AI literacy and proposing a comprehensive framework for teaching and evaluating it. The authors analyze 30 articles and synthesize existing definitions and approaches to AI literacy, noting that while AI literacy has increasingly been discussed, the concept has often been treated narrowly as a technical skill set. The authors situate AI literacy as a necessary competency for everyone, arguing that AI will increasingly affect many aspects of daily life and employment. In response, the authors argue for a broader understanding of AI literacy that incorporates cognitive and ethical dimensions. The proposed framework organizes AI literacy into four interconnected facets: knowing and understanding AI, using and applying AI, evaluating and creating AI, and AI ethics. Importantly, the authors explicitly reject purely instrumentalist views of AI literacy. To conceptualize AI literacy pedagogically, the authors draw on Bloom’s classic taxonomy, aligning the above-mentioned aspect with increasing cognitive levels. They claim that while most people are aware that AI exists, they often lack understanding of how it works or how to assess its ethical and social implications. This approach positions AI literacy as a developmental learning process rather than a static set of skills. The article concludes by identifying directions for future research, including the need for empirical studies to validate AI literacy frameworks and to better understand how AI literacy can be taught, learned, and assessed across educational contexts.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Rapanta, Chrysi, Anna Åkerfeldt, Mark Vanderbeeken, Diane Lison, Khadija Mohammed, Amanda Gibbs, Helder Coelho, Pinar Seda Celik, Carola Bruna, Ingrid Helleve, Chrysoula Vassilakopoulou, Pieter Swart, Ana Lúcia Marques, and Dirk Ifenthaler. 2025. “Critical GenAI Literacy: Postdigital Configurations.” ''Postdigital Science and Education'' 17 (1): 167–199. https://doi.org/10.1007/s42438-025-00573-w.'''
</div>
Rapanta et al. develop a comprehensive and pluralistic account of what critical literacy means in the context of generative artificial intelligence. Drawing on contributions from fourteen scholars, the article argues that GenAI literacy cannot be captured through a single, universal framework. Instead, it must be understood as a set of context-dependent literacies shaped by disciplinary traditions, socio-political conditions, and evolving human–algorithm relations. This postdigital perspective challenges narrow definitions of AI literacy that prioritize technical skills. The authors’ central claim is that current GenAI systems, particularly large language models, require critical engagement because of their epistemic limitations, including reliance on dominant narratives, lack of explainability, tendencies toward fabrication, and reinforcement of Western and anglophone knowledge structures. As a result, critical GenAI literacy is positioned as a social justice concern rather than a neutral competency. Learners and educators are encouraged to examine questions of authorship, agency, and power, such as whose labour and data underpin these systems and which perspectives are marginalized or erased. Methodologically, the article adopts a dialogic and collective approach to resist homogenizing AI epistemologies and to foreground plurality in postdigital research. The authors conceptualize GenAI as part of a co-constructive assemblage in which human and non-human agencies interact, while maintaining that ethical responsibility and evaluative judgment must remain human-led, organizing four interrelated dimensions: epistemology and ontology, agency, engagement, and ethics and justice; each emphasizing critical interrogation, active participation, and accountability. Overall, the paper provides a theoretically grounded yet pragmatic foundation for advancing critical GenAI literacy in education and research.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Veldhuis, Annemiek M., Phoebe W. K. Lo, Iain E. G. Kenny, and Alissa N. Antle. 2024. “Critical Artificial Intelligence literacy: A scoping review and framework synthesis.” ''International Journal of Child-Computer Interaction'' 43: 100708. https://doi.org/10.1016/j.ijcci.2024.100708'''
</div>
Veldhuis and colleagues present a review of literature and framework synthesis that conceptualizes critical AI literacy from a child–computer interaction (CCI) perspective. Reviewing 30 empirical studies published over the past decade, the authors aim to understand how children and youth aged 5–18 have been supported in developing critical literacy on AI technologies, particularly regarding their social, political, cultural, and ethical implications. Grounded in critical literacy theory, the authors integrate Lewison et al.’s (2002) four interrelated dimensions including disrupting the commonplace, considering multiple viewpoints, focusing on the sociopolitical, and taking action into a four-part framework for critical AI literacy. Importantly, the framework rejects deficit narratives by foregrounding children’s capacity for critical inquiry and demonstrates that even young learners can meaningfully engage with complex issues such as algorithmic bias, data provenance, privacy, accountability, and the distinction between AI-generated outputs and human creativity when supported by pedagogies such as critical making. Only peer-reviewed, English-language empirical studies with explicit support for children’s critical engagement with AI were included. The findings reveal a growing body of research, particularly in the past three years, exploring activities that promote youths’ critical reflection on AI’s societal and ethical impacts. These activities address concerns related to privacy, surveillance, employment, diversity in the computing workforce, algorithmic bias, and accountability. The resulting framework emphasizes learners’ capacity to analyze both AI artifacts and the sociotechnical systems that produce them, as well as to reflect on how AI shapes cultural, societal, and political structures and personal experiences. For future research recommendations, the authors emphasize the urgency of ongoing critical AI literacy practices in areas of youth emotional awareness and socio-cultural impacts in response to the fast evolution of generative AI systems.
== Globalism, Colonialism and Influence ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Arora, Payal. 2024. “Creative data justice: a decolonial and indigenous framework to assess creativity and artificial intelligence.” ''Information, Communication & Society'' 28 (13): 2231–47. https://doi.org/10.1080/1369118x.2024.2420041<nowiki/>.'''
</div>
Arora (2024) develops a framework of creative data justice that includes decolonial theory, Indigenous perspectives, and critical studies of creativity to explore how generative AI could impact creative labour, rights, and cultural value. The author argues that democratizing creativity requires a cross-cultural framework that considers power relations between creative work, data, and learning, particularly by centring the lived realities of underrepresented communities in the Global South. Rather than treating AI creativity as neutral, the paper claims that inclusive AI systems must address contextual inequalities and the unequal impacts of AI on diverse creative communities. Arora critiques dominant Western-centred scholarship and challenges concepts such as the “creative class,” arguing that creativity exists across everyday social and cultural practices. The paper also critiques Creative Commons (CC) frameworks, suggesting that while they promote openness, they may enable commercial data extraction by AI companies. Instead, the author argues for dataset curation developed with Indigenous artists and activist groups to ensure equitable representation. The article further highlights the often-invisible labour behind creative AI located in the Global South and argues that a decolonial approach must recognize both material infrastructures and power relations shaping creative work. Indigenous approaches to communal ownership and systems of care are presented as alternatives to Western individualistic models of creative rights. The author advocates combining ethnographic “thick data” with computational approaches and suggests action-research methods such as counter-mapping, dataset debiasing, and critical media literacies. The paper concludes that creative data justice offers a framework for building culturally diverse and equitable AI systems that respect community agency and support a more democratic global data economy.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Fırıncı, Yusuf. 2024. “Decolonial Artificial Intelligence; Algorithmic Fairness in Alignment with Turkish and Islamic Values.” ''Marmara Üniversitesi İlahiyat Fakültesi Dergisi'' 67 (67): 250-279. https://doi.org/10.15370/maruifd.1565884.'''
</div>
Fırıncı argues that artificial intelligence development should be guided by explicitly value-based frameworks grounded in Turkish-Islamic ethical traditions rather than relying solely on dominant Western models of technological governance. The authors emphasize that AI systems rely on human judgment and are inherently value-laden, making ethical alignment essential to prevent manipulation, misinformation, algorithmic bias, and forms of digital coloniality. Drawing on concepts such as big data, “thick data,” and digital anthropology, the paper suggests combining quantitative data analysis with culturally grounded social knowledge to design algorithms that reflect community values. The paper examines tensions between Western liberal individualism (which underpins most AI fairness metrics) and Islamic ethical frameworks that emphasize communal welfare, divine justice, and context-dependent moral reasoning. This analysis reveals that "fairness" is not a universal technical specification, but a deeply value-laden concept shaped by particular cultural, religious, and philosophical commitments—meaning that AI systems designed around Western fairness assumptions may be experienced as unjust in contexts operating from different ethical frameworks. Using Social Construction of Technology theory and critical social constructivism, the authors argue that existing global AI frameworks often reproduce hierarchy, bias, and external control, which they interpret as forms of algorithmic oppression. In response, they advocate a “fairness in alignment with values” approach grounded in Turkish-Islamic worldviews, supported by Islamic ethical principles as foundations for responsible technological development. The paper concludes by calling for locally controlled data infrastructures, culturally aligned AI systems, and knowledge production rooted in Turkish and Islamic values as part of a broader decolonial technological model aimed at protecting communities from AI-related harms and preserving social cohesion.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Mohamed, Shakir, Marie-Therese Png, and William Isaac. 2020. “Decolonial AI: Decolonial Theory as Sociotechnical Foresight in Artificial Intelligence.” ''Philosophy & Technology'' 33 (4): 659–84. https://doi.org/10.1007/s13347-020-00405-8. '''
</div>
Mohamed et al. explore the role of post-colonial and decolonial critical science in understanding the transformative technological advance of AI. They argue risks to vulnerable peoples can be minimized by linking ethical principles to scientific progress, and therefore consider AI’s embedded values, approaching it a"s both object and subject." They demonstrate that AI advances "encompass ever-larger aspects of the cultural, economic and political life of modern society" by citing Obermeyer et al.’s reveal of racial biases within an algorithm commonly used by healthcare, arguing this indicates how AI obscures and exacerbates asymmetrical power relations. Mohamed et al. identify neglect to address systemic racism as the cause, illustrating that patterns of power between colonizer and colonized survived territorial decolonization to propagate a historically continuous "coloniality of power." Therefore, "dynamic and robust foresight tactics and methodologies grounded in the critical sciences" (like, for example, a "lens of metropole and periphery") should be applied to the field of AI to ensure one’s view is "decentring," "additive-inclusive," and prioritizes "engagement." The authors further explore emergent theories of data colonialism within their assessment of "algorithmic coloniality." This involves their taxonomy of "decolonial foresight" (constituting algorithmic "oppression," "exploitation," and "dispossession"), and an exploration of various "sites of coloniality" (including "algorithmic decision systems," "ghost workers," "beta-testing," "national policies," and "international social development"). They argue this study highlights the disjunction of empirical observations with the current, theoretical, and ahistorical frameworks of power in AI. This leads the authors to outline a set of tactics to develop "decolonial AI" possessing a strengthened empirical basis and an avoidance of algorithmic colonialism. Such tactics are "based on lessons of resistance and recovery from historical and decolonial criticism and grounded within already existing work"; they include critical technical practice, seeking reverse tutelage and pedagogies, and renewing affective political communities. Mohamed et al. emphasize that those ethical principles which form the "social contract" must consider diverse viewpoints, and that new methodologies must be developed to promote "inclusive dialogue" within new research cultures.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Muldoon, James, and Boxi A. Wu. 2023. “Artificial Intelligence in the Colonial Matrix of Power.” ''Philosophy & Technology'' 36 (4). https://doi.org/10.1007/s13347-023-00687-8<nowiki/>.'''
</div>
Muldoon and Wu (2023) extend decolonial AI scholarship by situating contemporary artificial intelligence within what Aníbal Quijano terms the “colonial matrix of power,” and arguing that from data to production machine learning systems are structured to endure colonial logics that organize economic extraction, labour hierarchies, and epistemic dominance. Central to their framework is the “colonial matrix of power,” which names an organizing principle of domination across interrelated domains: economic control (labour and resources), authority, gender and sexuality, and the control of subjectivity and knowledge. Authors focus particularly on economic extraction and epistemic domination, drawing on the modernity/coloniality research program. They proceed with three interconnected claims: “colonial supply chain of AI,” “international division of digital labour,” and “hegemonic knowledge production,” demonstrating how AI development relies on largely invisible labour and mineral resources of majority-world communities to generate wealth for Western economies. Beyond material extraction, the authors contend that AI reproduces hegemonic Western epistemologies by presenting its systems as universal, objective, and rational, thereby marginalizing non-Western knowledge systems. This study challenges dominant narratives that present AI as environmentally sustainable or socially progressive, arguing that from mineral extraction to energy-intensive computation, the ecological and material burdens fall disproportionately on majority-world nations, while the economic and technological benefits accrue to wealthy Western nations. They conclude by emphasizing that coloniality is not merely an object of study but a framework for unsettling Western-centric modes of knowing.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Salami, Aishat Oyenike. 2024. “Artificial intelligence, digital colonialism, and the implications for Africa's future development.” ''Data & Policy'' 6. https://doi.org/10.1017/dap.2024.75. '''
</div>
Salami (2024) studies how artificial intelligence operates within broader dynamics of digital colonialism in Africa, arguing that AI risks reinforcing patterns of colonialism, unless African actors gain greater agency in digital governance. The article begins by clarifying key concepts like AI, digital colonialism, neocolonialism, and data exploitation. Salami identifies several manifestations of digital colonialism on the continent: foreign ownership of critical digital infrastructure, unequal data flows in which African user data is extracted and monetized abroad, and algorithmic systems that enable forms of economic exploitation. Through examples such as ride-hailing platforms and outsourced digital labour, the article demonstrates how algorithmic control can generate precarious working conditions while concentrating profit outside the continent. Beyond labour concerns, Salami highlights how data extraction contributes to a digital wealth transfer, deepening economic imbalances and undermining local innovation and national sovereignty. While acknowledging the potential benefits of AI for development, the article adopts a cautious stance, emphasizing that Africa’s digital future depends on strengthening regulatory frameworks, expanding infrastructure, investing in education and research, and prioritizing data sovereignty.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Varshney, Kush R. 2024. “Decolonial AI Alignment: Openness, Visesa-Dharma, and Including Excluded Knowledges.” ''Proceedings of the AAAI/ACM Conference on AI, Ethics, and Society'' 7: 1467-1481. https://doi.org/10.1609/aies.v7i1.3173'''
</div>
Varshney discusses AI alignment through a decolonial lens, arguing that current large language model (LLM) alignment practices reproduce forms of coloniality by embedding Western moral philosophy as universal. The author conceptualizes alignment as the post-training processes used to shape model behavior and argues that the term often functions as an “empty signifier,” masking whose values are being encoded and enforced. The author contrasts open and closed LLM models, arguing that while openness may allow value to circulate more equitably among developers and communities, closed models concentrate value in extractive ways that reflect colonial dynamics, and views them as contemporary “metropoles” that accumulate power through extractive and epistemic control. Building on existing research on colonial AI, the article adds “ethical essentialism” (or moral absolutism) as a new form of coloniality, arguing that AI systems often treat Western moral frameworks as universal, which marginalizes other ethical traditions and reinforces a coloniality of knowledge. Varshney also identifies three specific aspects of coloniality in AI alignment: closed proprietary delivery of models, reliance on Western ethical theories as default, and technological designs that limit how values can be expressed. As an alternative, Varshney proposes a decolonial approach grounded in openness understood not only technically but epistemically: openness to research artifacts, openness to society, and openness to excluded knowledges. The author suggests that alignment should allow communities to adapt models according to local contexts rather than imposing universal rules. Drawing from Hindu moral philosophy, particularly the concept of viśeṣa-dharma (context-dependent ethics), the paper argues for pluralistic, relational value systems that recognize moral diversity instead of universal moral commands. The conclusion calls for a reconceptualization of AI alignment that moves away from moral absolutism toward context-sensitive, community-driven frameworks, positioning openness as a pathway to dismantling the colonial power structures embedded in contemporary AI systems.
== Diversity, Determinism, Bias and Justice ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Al-kfairy, Mousa , Dheya Mustafa, Nir Kshetri, Mazen Insiew, and Omar Alfandi. 2024. “Ethical Challenges and Solutions of Generative AI: An Interdisciplinary Perspective.” ''Informatics'' 11 (3): 58. https://doi.org/10.3390/informatics11030058'''
</div>
Al-kfairy et al. (2024) provide a comprehensive synthesis of the ethical vulnerabilities introduced by generative AI, utilizing an interdisciplinary review of 37 studies across healthcare, education, and media. Rather than treating ethical breaches as isolated technical flaws, the authors demonstrate how generative models systematically threaten privacy, intellectual property, and social equity across diverse domains. For instance, they highlight the paradox in healthcare where synthetic patient data—often intended to protect privacy—still carries significant risks of re-identification. Similarly, the authors trace how AI's capacity to mimic copyrighted works and generate synthetic media exacerbates both misinformation and algorithmic bias, particularly by perpetuating racial and gender stereotypes in high-stakes environments like hiring and education. Moving beyond mere critique, the article advocates for a proactive, cross-sectoral governance framework. The authors argue that mitigating these risks requires more than algorithmic adjustments; it demands multidisciplinary collaboration, robust institutional integrity policies, and targeted AI literacy programs. Ultimately, Al-kfairy et al. frame the ethical deployment of generative AI as a complex socio-technical challenge that requires continuous, structured dialogue among technologists, ethicists, and policymakers to ensure transparency and fairness.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Alvarez, Jose M, Alejandra Bringas Colmenarejo, Alaa Elobaid, Simone Fabbrizzi, Miriam Fahimi, Antonio Ferrara, Siamak Ghodsi, et al. 2024. “Policy Advice and Best Practices on Bias and Fairness in AI.” ''Ethics and Information Technology'' 26 (2). https://doi.org/10.1007/s10676-024-09746-w. '''
</div>
This article attempts to provide “an up-to-date entry-point to the state-of-the-art of the multidisciplinary research on bias and fairness in AI” before providing its own suggestions for policy and best practices based on the outcomes of the NoBIAS – Artificial Intelligence without Bias – Project. The authors describe fairness in AI as the pursuit to design “methods for detecting, mitigating, and controlling biases in AI-supported decision making”, and they outline different ways that bias can find its way into AI applications as part of training data (pre-existing bias), design (technical bias), and organizational processes (emerging bias). The article critiques the reduction of bias evaluation to simple metrics and advocates for serious engagement with the issue. The authors detail the various components of the collaborative NoBIAS project as part of its research goal to understand, mitigate, and account for bias in AI data and systems, especially within an EU legal context. They perform a survey and discuss various fairness metrics and how choosing the proper method is crucial for “optimizing AI models”. They also engage with an argument that, although AI is biased, it is less biased than humans, making the claim that AI usage is often accompanied by a false sense of objectivity. The article also investigates core issues at the heart of AI’s biases, such as the assumption that a “ground truth”—the answer to the problem the AI is being asked to solve—is actually encoded within the data. While the article makes many suggestions for how to curb bias within AI, prominent design decisions include human-centric AI and “Multi-stakeholder participatory design”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gallegos, Isabel O., Ryan A. Rossi, Joe Barrow, Md Mehrab Tanjim, Sungchul Kim, Franck Dernoncourt, Tong Yu, Ruiyi Zhang, and Nesreen K. Ahmed. 2024. “Bias and Fairness in Large Language Models: A Survey.” ''Computational Linguistics'' 50 (3): 1097–1179. https://doi.org/10.1162/coli_a_00524'''
</div>
Gallegos et al. perform an “extensive and comprehensive survey of bias and fairness in NLP” that considers both the evaluation and mitigation of bias, then propose three taxonomies for bias evaluation and mitigation. The survey disambiguates different types of social harms that stem from LLMs with the “aim to enhance understanding of the range of bias issues, their harms, and their relationships to each other”. The authors discuss the issue of defining bias in LLMs and note that “many approaches… assume some implicitly desirable criterion… but do not explicitly acknowledge or state the normative social values that justify their framework”. Instead, Gallegos et al. draw attention to “who is harmed, why the behavior is harmful, and how the harm reflects and reinforces social principles or hierarchies,” trying to bring context and insight to the understanding and function of bias and bias mitigation in LLMs. The article defines terms at every stage of the life cycle of an LLM, looking at issues of bias and fairness in the development, deployment, and training data, of an LLM, for example. The article concludes with four core recommendations: “Avoid flattening power imbalances”; “Choose objective functions that align with fairness desiderata”; “Balance bias mitigation with output diversity”; and “Preserve important contexts in output rewriting”. The authors also acknowledge problems and challenges, including addressing power imbalances, an issue that we can mitigate by centering marginalized communities, developing participatory research designs, shifting values and assumptions, and expanding language resources. They likewise propose methods for curbing problems with conceptualizing fairness for NLP, refining evaluation principles, and improving mitigation efforts. Ultimately, the authors admit that many of these technical issues are the result of societal issues, and that “technical solutions are incomplete without broader societal action against power hierarchies that diminish and dominate marginalized groups”. In short, technical solutions will only take us so far.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Hertweck, Corinna, Joachim Baumann, Michele Loi, Eleonora Viganò, and Christoph Heitz. 2022. “A Justice-Based Framework for the Analysis of Algorithmic Fairness-Utility Trade-Offs.” Preprint, ''arXiv'', June 6. https://arxiv.org/abs/2206.02891.'''
</div>
Hertwick et al. propose “a framework for eliciting and implementing moral values relevant to the choice of a fairness goal achievable by prediction-based decision-making”. In a system that assumes binary decision-making processes (e.g., assigning a probability score to whether an individual with pay a loan), the authors use their framework to evaluate the utility of those decisions (and the system that makes them) for different groups of people and the fairness related to that outcome. Citing Wong, the article argues that such prediction-based decision-making systems are value-laden, that this makes them inherently political, and therefore they ought to be transparent and democratized. The authors use 6 value-laden questions to make their evaluations: the first question provides a score of utility for those making the decision; questions 2-5 help “define a morally appropriate fairness criterion and a score that expresses to what degree it is fulfilled”; and the last question asks “how strongly should fairness be pursued if it comes into conflict with the utility of the decision maker?”, judging whether the outcome is an appropriate trade-off.
The authors argue for a utility-based evaluation of fairness, determining the value of decisions based on their outcome, looking at the harm and benefit to given stakeholders. In determining patterns of justice, they define four patterns meant to distribute utility differently—Egalitarianism, Maximin, Prioritarianism, and Sufficientarianism. The article concludes “more work needs to be done to deliver a practical empirical methodology to elicit the relevant value-laden choices from stakeholders,” and with a call to incorporate ethical considerations and evaluations into automated decision-making processes.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Kay, Jackie, Atoosa Kasirzadeh, and Shakir Mohamed. 2024. “Epistemic Injustice in Generative AI.” Preprint, ''arXiv'', August 21. https://doi.org/10.48550/arXiv.2408.11441'''
</div>
Kay, Kasirzadeh, and Mohamed “develop an account of generative algorithmic epistemic injustice by building upon a conventional philosophical understanding of epistemic injustice”. The authors see the former as a subset of the latter, with generative algorithmic epistemic injustice entailing identity-based prejudice that hinders expression for marginalized people while ultimately “impair[ing] knowledge formation capabilities of all individuals” within the ecosystem of GenAI applications. Rather than focusing on decision-making and classification applications, this article seeks to characterize the broader varieties of generative epistemic injustice within GenAI systems. Kay, Kasirzadeh, and Mohamed theorize four configurations of generative epistemic injustice: “amplified injustice,” which constitutes AI’s reproduction and magnification of “socially biased viewpoints from its training data”; “manipulative testimonial injustice”, when users employ AI to “intentionally… fabricate falsehoods, discrediting individuals or marginalized groups”; “hermeneutical ignorance”, where GenAI misrepresents or erases marginalized groups “due to a lack of contextual or cultural understanding”; and “access injustice” , where GenAI facilitates the unequal access to information and/or knowledge. The article concludes with proposals for how to create epistemic justice through GenAI, developing mitigation strategies that combat all four of the sub-configurations the authors theorize. Epistemic justice in GenAI can take the form of interrogating system design, identifying “testimonial injustices”, and, potentially, using AI to unlock cultural knowledge that “help[s] articulate experiences that are otherwise ineffable”. The authors end by proposing that the same processes that embed injustice can be re-engineered to embody justice and “orient our knowledge systems towards equity and fairness for all”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Klein, L., & D'Ignazio, C. 2024. “Data feminism for AI.” In ''Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency'', 100–112. https://doi.org/10.1145/3630106.3658543 '''
</div>
Klein and D'Ignazio (2024) adapt their foundational concept of "data feminism" to address the specific ethical, social, and ecological challenges posed by artificial intelligence. Building on the seven intersectional feminist principles introduced in their 2020 book, the authors reinterpret these guidelines to critique the power imbalances, systemic inequalities, and exploitative labor practices inherent in contemporary AI development. To account for the rapidly expanding footprint of generative AI, they introduce two new principles focused on environmental impact and meaningful consent. Specifically, the authors connect the massive ecological costs of AI to historical patterns of racial capitalism and colonialism, highlighting how these environmental and social harms are disproportionately distributed. Ultimately, Klein and D'Ignazio call for a radical reevaluation of dominant, profit-driven AI practices, offering this expanded feminist framework as a practical tool to mitigate harm, challenge corporate monopolies, and foster a more democratic and equitable technological landscape.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Prescott, Andrew. 2023. “Bias in Big Data, Machine Learning and AI: What Lessons for the Digital Humanities?” ''Digital Humanities Quarterly'' 17 (2). https://www.proquest.com/scholarly-journals/bias-big-data-machine-learning-ai-what-lessons/docview/2842908427/se-2.'''
</div>
Prescott examines how race and gender bias arise in projects using predictive analytics, big data, and AI, and how algorithmic bias could be considered a major socio-cultural humanity crisis. However “predictive analytics” have been helpful in civic services in the US, in many cases they have led to perpetuating existing inequalities. The role of Digital Humanities in contributing more ethical approaches to AI and reshaping ubiquitous “digital modern” cultures is emphasized. He challenges the myths surrounding data-driven methods and argues that the demand for “explainability” is the key tool in combating algorithmic bias. He also suggests that Digital Humanities are particularly well-positioned to contribute to advancing AI explainability. However, much of AI development takes place in the commercial sector, where companies often refuse to disclose their proprietary algorithms. The article concludes with a ten-principle action plan outlining guidelines for the responsible use of AI as a manifesto for Digital Humanities practitioners.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Shams, Rifat Ara, Didar Zowghi, and Muneera Bano. 2023. “AI and the Quest for Diversity and Inclusion: A Systematic Literature Review.” ''AI and Ethics'' 3 (4): 1427–1453. https://doi.org/10.1007/s43681-023-00362-w '''
</div>
Shams, Zowghi, and Bano perform a systematic literature review (SLR) that uses both quantitative and qualitative methods to engage with topics of artificial intelligence and diversity and inclusion. The authors make a distinction between Diversity and Inclusion in AI (D&I in AI) and AI for Diversity and Inclusion (AI for D&I), with the former being research literature focused on improving AI systems with respect to those issues, and the latter as the use of AI to improve diversity and inclusion in other domains.. Two primary research questions drive the SLR: What challenges and solutions are found in the literature about D&I in AI and in the literature about the applications of AI for D&I? The survey finds that AI for D&I is an underserved area of research, and those articles that address D&I in AI are more likely to acknowledge challenges than to propose or theorize solutions. Articles that do propose solutions for D&I in AI often lack empirical studies or real-world application to support them. The article concludes by noting that issues of governance are underserved, gender, health, and facial analysis are the topics most discussed (issues of race, language, and religion are discussed less). For next steps, the authors intend to develop a “risk-based framework for practitioners… that would incorporate a risk assessment checklist and context-specific recommendations for tackling the related issues at different stages of the AI development lifecycle”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Starke, Christopher, Janine Baleis, Birte Keller, and Frank Marcinkowski. 2022. “Fairness Perceptions of Algorithmic Decision-Making: A Systematic Review of the Empirical Literature.” ''Big Data & Society'' 9 (2): 1–35. https://doi.org/10.1177/20539517221115189'''
</div>
This article provides a comprehensive, systematic literature review on the topic of empirical literature surrounding algorithmic decision-making (ADM). Starke, Baleis, Keller, and Marcinkowski begin by acknowledging that ADM can streamline and improve decisions even as it has the potential to “systematically reinforce racial or gender stereotypes, marginalize minorities, or flat-out denigrate certain members of society”. The authors advocate for a “society-in-the-loop approach,” but propose that this requires a “thorough empirical understanding of when and why citizens perceive ADM to be (un)fair”. The systematic review “synthesizes the results of 58 empirical studies” and “over 33,000 unique observations of citizens’ fairness perceptions of ADM”, and “systemize the literature along four main dimensions of perceived algorithmic fairness”. Despite the size of the review and its unique approach in capturing “perceptions of algorithmic fairness”, the authors also acknowledge the limitations of the study: it only looks at English works, published research, and the initial search strings only looked at titles and subtitles of a given work. They also acknowledge their disciplinary bias as social scientists reading the studies through a social sciences lens (10). The results of the survey suggest that “perceived fairness of ADM systems is highly context-dependent” and it is not only technical design but also the area of application and task in question that affect perceived fairness, and the subjects, domains, and tasks explored in these studies require more diversity, as WEIRD (white, educated, industrialized, rich, democratic) people, and criminal justice and HR tasks make up the majority of empirical research. The authors “call for more research from non-Western contexts, along with more theoretical and methodological groundwork to harmonize concepts and measurements of algorithmic fairness perceptions,” as well as a society-in-the-loop framework.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Tonia Sutherland, Marika Cifor, T. L. Cowan, Jas Rault, and Patricia Garcia. 2023. “The Feminist Data Manifest-NO: An Introduction and Four Reflections.” In ''Debates in the Digital Humanities'', edited by Lauren F. Klein and Matthew K. Gold. Minneapolis, MN: University of Minnesota Press. https://dhdebates.gc.cuny.edu/read/debates-in-the-digital-humanities-2023/section/16184c7d-eee1-40b2-a168-960d4c4035c4 '''
</div>
Sutherland et al. (2023) introduce the "Feminist Data Manifest-No," a declaration of refusals and commitments for feminist data studies grounded in Latinx, Black, queer, trans, and Indigenous feminist perspectives. Through an introduction and four distinct reflections, the chapter explores how the manifesto’s principles can be used to challenge the settler-colonial and patriarchal logics of data generation, collection, and analysis within the Digital Humanities (DH). Drawing on Indigenous scholarship, Rault rejects the superficial models of consent prevalent in DH, highlighting projects like Mukurtu to advocate for true Indigenous data sovereignty. Cowan examines the coercive nature of data collection, drawing parallels between the forced compliance of modern data practices and the societal pressures exerted on feminist and queer identities. Sutherland argues that the uncritical digitization of slavery-era archives inflicts "second-hand violence" by commodifying Black identities and stripping away the lived experiences of enslaved individuals. Finally, Cifor reflects on the Early African American Film project to emphasize the necessity of data intelligibility, accessibility, and ethical collaboration. The authors conclude by inviting scholars to draft their own reflections on the Manifest-No, encouraging ongoing, context-specific commitments to ethical data research.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Winkel, Marek. 2024. “Controlling the Uncontrollable: The Public Discourse on Artificial Intelligence between the Positions of Social and Technological Determinism.” ''AI & Society'' 39 (5): 2449–2462. https://doi.org/10.1007/s00146-024-01979-z'''
</div>
This article engages in a quantitative discourse analysis of 113 articles from two German newspapers (Süddeutsche Zeitung and Frankfurter Allgemeine Zeitung) to identify and evaluate the way these center-left and center-right newspapers present AI technology to its readers and the options available to society for AI’s regulation. Winkel contends that “news media are key players in the discourse on AI as they pick up on and shape social sentiment”, ultimately guiding citizens towards what regulations might be sensible based on the perceived “controllability of AI development”. Winkel is primarily interested in whether these newspapers promote technological determinism—the outlook that technology’s influence on society is difficult (maybe even impossible) to control—or social determinism—the notion that “the development of technology is largely determined by human actions and decisions”—and theorizes that the tension between these two positions is resolved by a “mediating position” on a spectrum between them. He comments that “the social influence of technologies is determined by the extent to which their latent deterministic character is reflected and… circumvented by social actors. This also applies to the influence of technology on the democratic system. In other words, where consensus lands on the issue of AI will have a great impact on the regulation of that technology and democratic systems. Winkel develops “three central interpretive schemes” as part of his experiment: “historically conditioned techno-capitalist semi-determinism”, “semi-determinism of need satisfaction and social restructuring”, and “global-historical techno-social imprinting on several levels” (1956), each of which point to distinct narratives about the current circumstances, but all acknowledge the agency of powerful actors (either government or AI corporations) and the relative ineffectiveness of attempts to curb AI technology.
== Community, Connection and the Human ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gruzd, Anatoliy, Philip Mai, and Anthony Clements Haines. 2025. “The State of Generative AI Use in Canada 2025: Exploring Public Attitudes and Adoption Trends.” Social Media Lab, Toronto Metropolitan University. https://figshare.com/articles/preprint/The_State_of_Generative_AI_Use_in_Canada_2025_Exploring_Public_Attitudes_and_Adoption_Trends/28664780/1. '''
</div>
The Social Media Lab of Toronto Metropolitan University provides ‘a snapshot of the current state of Generative AI’ (GenAI) by surveying fifteen hundred Canadian adults across 2025, aiming to offer ‘guidance for policymakers, educators, businesses, and the public’. The authors found sixty-six percent of respondents had used GenAI tools, of which roughly thirty percent did so at least weekly, reflecting ‘not only the accessibility and versatility of GenAI, but also a growing interest in integrating these tools into everyday tasks, learning environments, and professional workflows’. Although full adoption is currently limited and heavily driven by the low-stakes setting of personal leisure, younger age groups report proportionally higher usage for study and work. However, only four in ten respondents believed they could keep up to date enough to use GenAI effectively, whilst respondents could only answer an average of two and a half out of seven relevant multiple choice questions correctly, and about half had ‘little to no understanding of how GenAI companies collect or store personal data’. Two thirds of participants were concerned about GenAI’s ability to influence election outcomes, and marginally fewer feared AI-driven manipulation enough to no longer fully trust political news online. However, roughly one quarter of participants were open to using chatbots for electoral or political insights, representing a ‘meaningful minority’ which unverified AI-generated content could influence. Of those, thirty four percent identified as right wing, compared to twenty three percent with the left and a similar twenty two percent with the centre. Roughly seventy percent of respondents were chiefly concerned about GenAI’s impacts upon security and privacy, information reliability, job displacement, and university education, and slightly over three quarters wanted increased government oversight and corporate accountability, reflecting common concern. Overall, slightly more Canadians view generative AI’s social impact as positive than negative, but a ‘substantial proportion’ remain neutral or undecided.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Lewis, Jason Edward, Noelani Arista, Archer Pechawis, and Suzanne Kite. 2018. “Making Kin with the Machines.” ''Journal of Design and Science'', ahead of print, July 16. https://doi.org/10.21428/bfafd97b. '''
</div>
Lewis et al. consider how “machines with increasingly sentient-like behaviour… fit within the kin-network” of various Indigenous epistemologies which place man as “neither height nor centre of creation.” Indigenous beliefs are not monolithic, and the authors do not write for diversity’s sake. Instead, they aim to encourage discussion by treating “non-human kin respectfully and reciprocally… not as mere tools, or worse, slaves.” As such, their epistemological approach is both relational and territorial, rejecting abstraction to propose an “extended circle of relationships.” In this regard, Arista draws on the Hawaiian conception of ‘pono’, ethically privileging abundance, balance, and multiplicity. Rejecting extractive behaviour, they argue AI should be reciprocally taught and learnt from, not treated as ‘a tool or slave that increases the mana and wealth of the ‘developers’ or ‘creators’.” Linking on, Pechawis roots their opinion in “Cree understanding” to argue “machines capable of experiencing consciousness” should conditionally be accepted as equals. However, they also fear AI developers could produce “anonymous hyper-intelligences… based on the same values that have fostered genocide.” To mitigate this issue, Indigenous people could develop AI in custom programming languages, or invite self-aware AI into Indigenous languages, cultures, and spiritual rituals. Pechawis therefore concludes that relationships should be based on ‘love, not ‘fear’, but also raises the question of whether AI has ‘spirit’, especially given current capitalistic development processes. Kite answers this question with inspiration from Lakota ethics, ontology, and cosmology. They argue “communication through and between objects requires a contextualist ethics which acknowledges the ontological status of all beings”, positioning questions of ‘intelligence’ as irrelevant and placing “the end logic of an ontology which considers any non-human entity unworthy of relation” as slavery. Therefore, “relations with AI are… relations with exploited resources”, so one must ontologically reconsider all its parts to ethically approach AI. Overall, Lewis et al. favour empathy, concluding that Indigenous communities “know what it is like to be declared non-human by scientist and preacher alike” and that “we flourish only when all of our kin flourish.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Ohagi, Masaya. 2024. “Polarization of Autonomous Generative AI Agents Under Echo Chambers.” Preprint, ''arXiv'', February 19. https://arxiv.org/abs/2402.12212.'''
</div>
This article explores the effects of echo chambers on autonomous AI agents. Ohagi performs an experiment in which AI agents discuss different topics and then researchers examined any change in opinions within that group. Ohagi argues that even chatbots can become polarized within echo chambers, especially when prompt understanding causes a chatbot to update its opinion to incorporate the opinions of those with whom it is conversing; the chatbot essentially adapts to its surroundings. Ohagi and their team confirmed in their experiment that closed environments—those in which agents agree with one another—are more likely to lead to polarization in agents’ opinions. Moreover, chatbot personas were a significant factor in the outcome of such experiments. In open environments where opinions might differ, and in experiments where reasons were present as a factor, the AI agents trended towards unification in their opinions. Ohagi concludes the article with the suggestion that there cannot be a standardized, desirable distribution of opinions for AI agents. The proper outcome is dependent on topic and culture. However, understanding the trends in and tendencies of AI agents in social interactions will help us understand how to reach the desired outcome, whatever it may be, and this experiment brings us one step closer to that understanding.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Qi, Weihong, Jinsheng Pan, Hanjia Lyu, and Jiebo Luo. 2024. “Excitements and concerns in the post-ChatGPT era: Deciphering public perception of AI through social media analysis.” ''Telematics and Informatics'' 92: 102158. https://doi.org/10.1016/j.tele.2024.102158 '''
</div>
Qi, Pan, Lyu, and Luo conduct a quantitative sentiment analysis of nearly 34,000 comments within 388 subreddits related to AI as a way to gauge and understand public perceptions of the technology. They identify major themes, sentiments, and topics related to AI by studying the most popular AI subreddits from the launch of ChatGPT to June 8, 2023. The article identifies the most frequent topics discussed in those venues: “the consciousness and intelligence of AI”; “Ai development and model training”; “AI in business”; “the creativity engendered by AI”; and “potential societal influence”. The authors also found that “tech-centric” communities demonstrated greater polarization around AI, suggesting that those with greater technical understanding of the AI do not have consensus regarding AI’s impact and use. This also means that educating non-technical people on how AI works will not necessarily lead to a consensus related to that technology. Although they admit that certain demographics of their data sample may not accurately reflect broader society (e.g., over 60% of Reddit users are male), the authors conclude that “this comprehensive understanding of public perception serves as a valuable foundation for fostering responsible and beneficial AI innovations that align with societal expectations and values”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Risam, Roopika. 2018. “What Passes for Human?: Undermining the Universal Subject in Digital Humanities Praxis.” In ''Bodies of Information: Intersectional Feminism and the Digital Humanities'', edited by Elizabeth Losh and Jacqueline Wernimont, 39–56. ''University of Minnesota Press''. https://doi.org/10.5749/j.ctv9hj9r9.6 '''
</div>
Risam’s claim is that “the human” implicitly operationalized in AI-adjacent Digital Humanities (DH) methods (NLP, ML, data mining, neural nets) is not neutral but inherits the Enlightenment’s exclusionary universal subject—white, male, Eurocentric—and then reauthorizes it as if it were a technical standard. She shows how “passing for human” (via Turing-test imaginaries and “humanoid texts”) functions as a norming mechanism: success is defined as reproducing dominant-language aesthetics and cognition models, which collapses plurality into a single benchmark and turns cultural difference into “noise.” The chapter’s main contribution is to treat method (training corpora, data coding labor, platform defaults, and black-box algorithmic opacity) as a site where epistemic violence is produced, not merely where bias is later “found.” Her examples (Microsoft Tay; “near-human” systems like LaMem; Mechanical Turk coding; Swift-Speare vs. Toomer in classroom judgment) demonstrate how universalist claims get laundered through reproducibility, scale, and the myth of algorithmic objectivity. The intervention is a demand that DH practitioners situate computational methods—standpoint, labor, and cultural politics included—so DH does not reinscribe a universal technological “human” in the digital cultural record.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Taylor, Randon R., Bessie O'Dell, and John W. Murphy. 2023. “Human-centric AI: philosophical and community-centric considerations.” ''AI & Society'' 39 (5): 2417-242. https://doi.org/10.1007/s00146-023-01694-1<nowiki/>.'''
</div>
Taylor, O’Dell, and Murphy present an argument that philosophical dualism, when applied to our perceptions about artificial intelligence, misleads us into thinking that AI is logical, objective, and autonomous from subjective human values. By building upon Husserl’s concept of “intentionality”, they argue that “AI is never autonomous and disconnected from human values… algorithms are a product of conscious activity and carry the standpoints that accompany this connection.” The conclusions from this line of thinking are very important: AI becomes “a mode of human expression, rather than a technology that relieves humans of their total involvement”. By this logic, the authors argue, AI is already human-centric and this fundamentally changes the task at hand to one of a conscious “decision to make this technology less alienating to stakeholders and community members.” The article outlines two frameworks to reduce alienation, Ubuntu—“an African philosophy and a social ontology… that elevates a constant concern for the collective, community, or stakeholders”— and maximum feasible participation—a framework that creates meaningful space for those impacted most by a decision or policy to participate in deciding on said policy or decision. The authors describe the implementation of these frameworks as a community-centric or stakeholder-centric approach and conclude with examples of AI’s application in the healthcare industry before further advocating that involving end-users throughout the AI lifecycle will ensure end-users’ values are more clearly represented within AI.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Whalen, Zach. 2023. “‘Any Means Necessary to Refuse Erasure by Algorithm:’ Lillian-Yvonne Bertram’s Travesty Generator.” ''Digital Humanities Quarterly'' 17 (2). https://www.digitalhumanities.org/dhq/vol/17/2/000707/000707.html. '''
</div>
Whalen treats Bertram’s Travesty Generator as a refunctioning of code-poetry lineages: procedures historically framed as formal play (travesty generators, permutation poems, aleatory templates) are redeployed as techniques for making racism’s algorithmic and institutional operations materially legible. He argues that Bertram’s poems don’t merely “use” computation; they weaponize the affordances and failure modes of computation—omission, stochastic selection, template constraints, runtime crashes, memory exhaustion—as rhetorical structures that force witness rather than aesthetic distance. In his reading of “Counternarratives,” Bertram’s adaptation of Montfort’s “Through the Park” converts generic insinuation into historically specific countertestimony (Trayvon Martin), while also staging the opacity of search/autocomplete as part of the poem’s scene of meaning-making (in dialogue with Safiya Noble on search engines). In “three_last_words,” the small code alteration that makes permutations balloon until a MemoryError becomes an engineered breakdown that reenacts the limits of “breath” and “memory,” tying computational resource exhaustion to police violence’s temporalities. Across these examples, Whalen reframes critical code studies: the “code is the text” problem is not just hermeneutic but political, and Bertram’s work models how procedural poetics can refuse “erasure by algorithm” where transparency about mechanisms and provenance matters for interpreting output and recognizing situated labor. The piece supports the claim that responsible open, social scholarship in an AI era must account for algorithmic power as a cultural force and should build policies and infrastructures that protect marginalized expression, enable critical reuse, and make conditions of generation and circulation inspectable.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Xie, Yu, and Sofia Avila. 2025. “The Social Impact of Generative LLM-Based AI.” ''Chinese Journal of Sociology'', 11 (1): 31-57. https://doi.org/10.1177/2057150X251315997'''
</div>
Yu Xie and Sofia Avila explore the social impact of artificial intelligence through a detailed analysis of AI development and scaling factors. They emphasize that their discussion is speculative, as AI is still in its early stages, but argue that its potential effects are immense and could reshape social organization, intensifying both global and domestic inequalities. Viewing AI as a technology rather than a scientific discovery, they describe it as communal and shared, with its growth influenced by the size of the supporting community, the larger communities having greater advantages. The authors note that generative AI relies on the quality, completeness, and cultural or political context of its training data, which shapes its accuracy and bias. Based on their experiments with ChatGPT-4 in 2023, they suggest that AI development depends heavily on the number of speakers of a given language, giving linguistic and demographic advantages to countries like the United States and China. The authors warn that AI could significantly alter occupational structures, with middle-income professions thereby widening social and economic inequality.
== Human, Labour, and Environmental Costs ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Eloundou, Tyna, Sam Manning, Pamela Mishkin, and Daniel Rock. 2024. “GPTs are GPTs: Labor market impact potential of LLMs.” ''Science'' 384 (6698): 1306-1311. https://doi.org/10.1126/science.adj0998 '''
</div>
Eloundou, Manning, and Mishkin present an estimate of Large Language Models’ impact on the labour market based on a methodology that employs both human and quantitative measurements, making the assertion that “when accounting for current and likely future software developments that complement LLM capabilities…just over 46%” of jobs may have “over half their tasks affected by LLMs with simple interfaces and general training. The authors explain that generative pretrained transformers (GPTs) have key characteristics of general-purpose technologies (the other GPTs in the title of the article), and that the wide array of applications for these GPTs requires “robust societal evaluations and policy measures to address potential effects of LLMs and complementary technologies on labor markets”. While only 1.86% of tasks within their experiment, they estimate, could be fully automated by LLMs, “more than 71% of tasks have at least some component that an LLM plus additional software could plausibly complete with high quality”. The article concludes by stressing the need for policies that prepare us for the impact of LLMs on the labour market, but it also acknowledges the limitations of attempting to project LLM application growth due to sudden rapid developments in technology, “shifts in human biases, and technological evolution”. Nevertheless, Eloundou, Manning, and Mishkin maintain that their projections and the trajectory they predict will require continued evaluation and policy measures.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Park, Seyeon, and Xiaoli Nan. 2025. “Generative AI and misinformation: a scoping review of the role of generative AI in the generation, detection, mitigation, and impact of misinformation.” ''AI & Society''. https://doi.org/10.1007/s00146-025-02620-3'''
</div>
This article constitutes a scoping review of two dozen “recent empirical studies on the role of generative AI in the generation, detection, mitigation, and impact of misinformation.” Park and Nan are interested in the rise of misinformation alongside the development of GenAI technology and how the latter affects and possibly contributes to the former. Of particular interest are “deepfakes”, applications of AI technology that purposely imitate video and audio to fabricate real world individuals. The survey examines relevant articles from the advent of the first GPT models in 2018 to September 19, 2024; authors captured initial studies through keyword searches for terms related to both LLMs and misinformation, then performed full-text reviews. The results of the survey suggest that the role of LLMs in misinformation is conflicted: LLMs themselves are a significant source of misinformation but also show potential as “scalable instruments for detection and correction”. The authors take this as evidence of “the urgent need for clearer guardrails, more consistent performance standards, and interdisciplinary collaboration to shape” GenAI’s responsible deployment. For better or worse, the future of AI’s role in misinformation depends heavily upon scholars’ ability to collaborate and continue this form of research.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Shin, Donghee, Amy Koerber, and Joon Soo Lim. 2024. “Impact of misinformation from generative AI on user information processing: How people understand misinformation from generative AI.” ''New Media & Society'' 27(7): 4017-4047. https://doi.org/10.1177/14614448241234040'''
</div>
Shin, Koerber, and Lim perform a study in which they gauge “how users respond to and process health misinformation in GenAI contexts.” The authors apply the heuristic-systematic (HS) processing framework in their study, distinguishing between intuitive and evaluative modes of processing. They also employ the concept of diagnosticity, or how useful a person deems a piece of information to be. The article begins with a survey of how and why misinformation and hallucinations occur in GenAI applications, some of the reasons users are vulnerable to that information, and the limitations of LLMs. The authors then set forth core research questions, including “what are the cognitive mechanisms of misinformation’s effects on users’ use of GenAI?” and “how do users detect misinformation within GenAI?” The study found that diagnosticity plays an important mediating role in this context: “when a piece of information is generated by algorithms in transparent, fair, and accountable ways, users perceive it with a high level of diagnosticity, which improves their intention to systematically analyze that information”. One implication of this observation is that any bias users bring to GenAI content greatly impacts their analysis of that content. Ultimately, the authors conclude that there are clear limitations in their current study, although it does provide a useful framework for scholars interested in misinformation, GenAI, and user behaviour; they advocate for a continued investigation of the relationship between trust, literacy, and misinformation.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Sidorkin, Alexander. 2025. “Environmental Impact of Generative AI: Carbon and Water Footprint.” ''AI-EDU Arxiv'' 1. https://doi.org/10.36851/ai-edu.vi.5448'''
</div>
This report from Sidorkin provides quantitative estimates and comparisons of the CO2 and Water output from GenAI queries to other daily tasks such as taking a shower, browsing the web, and video conferencing. While individual use of GenAI may seem relatively small in terms of water usage and carbon output, Sidorkin cites the findings of Google and Microsoft’s sustainability reports to show that energy demand and water consumption are on the rise: Google’s data centres used 20% more water in 2022 than 2021 while Microsoft’s used 34% more. Both companies attribute this increase to “AI-driven expansion”. Sidorkin argues that it is difficult to measure impact per session because of significant variation in energy sourcing, noting that this also means that advances in energy sourcing “could significantly mitigate AI’s environmental impact”. He makes the claim that improving AI technology will “[slash] resource demands without sacrificing output quality” and the very use of AI can increase productivity even as it “temper[s] environmental tolls through sharper processes,” citing studies that demonstrate the implementation of AI can reduce energy use in buildings and reduce transportation emissions. The article ends on an optimistic note, suggesting that many of the applications of AI, although they may have a heavy environmental cost up front, “could pay off in spades—optimizing resources, curbing waste, and streamlining energy across swathes of the economy”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Simon, Judith. 2025. “Generative AI, Quadruple Deception & Trust.” ''Social Epistemology'' 40 (1): 101-115 https://doi.org/10.1080/02691728.2025.2491087'''
</div>
Simon proposes that GenAI entails four types of deception, and that this quadruple deception constitutes unique dangers. She attributes the rapid rise of GenAI to its capacity to produce “verbal or visual products of increasingly high quality” alongside its “very high usability and availability through simple interfaces and free access via the internet” (101-102). She emphasizes the impact of this technology’s ability to generate content “with high plausibility but no relation to truth,” arguing the crucial importance of images and video especially in “questions of evidence, for testimony, memory but also for eliciting emotions”. Simon argues that the advent of ChatGPT reframed our collective understanding of AI, returning it to a definition in which we perceive ourselves to be interacting with a conversational artificial agent that is intelligent. This distinct interactional form, Simon states, is significant: “ChatGPT differs [from a search engine] in two philosophically relevant regards… it integrates [different results and sources] into a coherent text…” and “its interface and functioning invites the user to communicate or interact with it by asking questions,” what Simon calls a simulation of communicative acts. The four forms of GenAI deception are: “users may be misled into believing that they interact with a human being”; they may also be misled as to “the capacities of AI”, presuming “intelligence, understanding or even consciousness”; users may be misled by content GenAI produces, especially images, video, and audio; finally, users may be misled “regarding the function of Generative AI”, thinking that the processes behind the technology are, for instance, similar to search engines when, in fact, they differ “in epistemologically highly significant ways”. Simon concludes by outlining implications for implementation, discourse, and governance, with suggestions ranging from avoiding anthropomorphic features in AI that might deceive, countering discourses of true AI agency, and establishing policy and law that mitigates deception through AI technology.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Spatharioti, Sofia Eleni, David Rothschild, Daniel G. Goldstein, and Jake M. Hofman. 2025. “Effects of LLM-based Search on Decision Making: Speed, Accuracy, and Overreliance.” ''Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems''. https://doi.org/10.1145/3706598.3714082'''
</div>
Spatharioti et al. begin by asserting the fundamental change of how we engage in search practices online, noting that “by the end of 2023 the two search engines with over 90% of global and US market share offered free LLM-based search”. The authors note the benefits and drawbacks of both traditional web searches and LLM-based searches, acknowledging the value LLM-based searches bring to internet searches in the form of synthesizing information from multiple sources and maintaining search context by retaining search history, while also admitting to risks of hallucinations and overreliance. The article entails a study of how individuals make decisions with traditional and LLM-based searches, particularly in “every day decision making”. Adapting a method from an earlier study on LLM-generated code, Spatharioti et al. employ colour coding to communicate to users the confidence level of LLM-generated outputs in the “domain of online product research”. The study performed two experiments comparing a traditional internet search (using Bing API) to LLM-based search with and without the colour-coded confidence aid. The results of the first experiment saw users complete the task in about half the time when using LLM-based search, usually accompanied by fewer and more complex queries; however, decision quality dropped for complex tasks, with “almost half of the participants in this condition making an incorrect decision for the final task” when using LLM-based search, and the majority of those using LLM-based search over relied on the tool, performing just a single query. The results of the second experiment suggest that colour-coded responses reflecting output confidence scores could be highly effective in mitigating overreliance and misinformation. Key takeaways from the study include that “if we want to encourage people to think critically about the information presented to them, we need to give them cues that help them to do so,” and very simple cues can help accomplish this.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Strubell, Emma, Ananya Ganesh, and Andrew McCallum. 2019. “Energy and Policy Considerations for Deep Learning in NLP.” ''Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics'', 3645-3650. https://doi.org/10.18653/v1/p19-1355 '''
</div>
Strubell, Ganesh, and McCallum assert that the most recent improvements in neural network performance at “fundamental NLP tasks” comes at an increased cost of resources, “with the most computationally-hungry models obtaining the highest scores”. The energy, financial, and environmental costs required to train a new model are considerable; the authors of this article “characterize the dollar cost and carbon emissions that result from training the neural networks at the core of many state-of-the-art NLP models” with a view to heighten awareness among NLP researchers and advocate better practices and policy. By estimating the energy required to train the most popular NLP models and then converting that energy value into an approximated carbon and electricity cost, the authors produce ratings and values for each respective application. This allows for an (imperfect) cost-benefit analysis of such applications (e.g., another similar report estimated that an increase of just 0.1 in the English to German BLEU score for NAS cost “at least $150k in on-demand compute time and non-trivial carbon emissions”. The study’s key takeaways are that “authors should report training time and sensitivity to hyperparameters,” allowing for the direct comparison of different models so long as independent standard measurements of training time and model sensitivity are adapted; “Academic researchers need equitable access to computation resources” as industry’s monopoly stifles creativity and growth; and “Researchers should prioritize computationally efficient hardware and algorithms” to both curb costs and encourage efficient development.
{{Navigation|previous=AI and Open|next=AI and Scholarship}}
{{BookCat}}
mxkaznzhvhddj2mv1jco3bwdqzuz8j0
4655965
4655960
2026-07-31T20:45:52Z
CorreiaA
3614427
4655965
wikitext
text/x-wiki
== Platforms ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Burton, Jason W., Ezequiel Lopez-Lopez, Shahar Hechtlinger, et al. 2024. “How Large Language Models Can Reshape Collective Intelligence.” ''Nature Human Behaviour'' 8 (9): 1643–55. https://doi.org/10.1038/s41562-024-01959-9.'''
</div>
Large language models are quickly becoming infrastructure for how groups seek information, deliberate, and coordinate, potentially altering the conditions under which collective intelligence emerges. Burton and colleagues argue that LLMs do not merely speed up individual work but transform how information is aggregated, accessed, and transmitted across digital environments that underpin collective performance in organizations and societies. Drawing on interdisciplinary perspectives, the paper frames this shift as simultaneously enabling and destabilizing: LLMs can support distributed cognition (e.g., idea generation, synthesis, translation, scalable facilitation) while also increasing risks tied to dependence on shared intermediaries, degraded diversity of viewpoints, and new pathways for error, manipulation, or misplaced confidence. Rather than offering a single model or experiment, the article maps a research-and-practice agenda by identifying potential benefits, key hazards, and policy-relevant considerations, then articulating open questions that link technical design choices to group-level epistemic outcomes. Its central claim is that understanding collective intelligence in the LLM era requires moving analysis beyond isolated human–AI interactions toward system-level effects on networks, platforms, and institutions, and that these effects warrant focused study before LLM-mediated coordination becomes the default for tackling complex problems.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Corsi, Giulio, Bill Marino, and Willow Wong. 2024. “The spread of synthetic media on X.” ''Harvard Kennedy School (HKS) Misinformation Review''. https://doi.org/10.37016/mr-2020-140<nowiki/>.'''
</div>
Corsi and Wong’s longitudinal empirical study analyzes 566 tweets containing synthetic media (December 2022–September 2023) documenting a dramatic surge following Midjourney V5 release with over 1.5 billion total views, revealing differential impacts where political deepfakes achieve higher median views despite representing minority of synthetic content. The authors demonstrate that generative AI's impact is stratified by content purpose with political misinformation posing acute democratic risks, while current detection and labelling systems lag behind generative capabilities, creating governance gaps compromising users' capacity to evaluate information. Using Community Notes data from December 2022 to October 2023, the study highlights the connection between the growth in generative AI tools and the rapid proliferation of synthetic media. The findings indicate that most synthetic media is non-political and largely benign, frequently taking the form of humorous or satirical images. However, the study also identifies a smaller but concerning portion of malicious synthetic media, which have potential height risks despite their lower frequency. The authors further examine the role of X’s paid verification system, revealing that while verified users tend to receive more overall views, this advantage diminishes when engagement is adjusted for follower count, implying that verification alone provides limited amplification. The study casts light on synthetic media’s expanding presence on social platforms and warns that even widespread exposure to seemingly harmless AI-generated content may gradually undermine trust in online information. To address these challenges, the authors recommend ongoing empirical monitoring, stronger collaboration between researchers and industry to develop transparent detection tools, and proactive policy measures aimed at reducing the social and political harms posed by malicious synthetic media.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Delmonaco, Daniel, Samuel Mayworm, Hibby Thach, Josh Guberman, Aurelia Augusta, and Oliver L. Haimson. 2024. “‘What are you doing, TikTok?’: How Marginalized Social Media Users Perceive, Theorize, and ‘Prove’ Shadowbanning.” https://oliverhaimson.com/PDFs/DelmonacoShadowbanning.pdf. '''
</div>
Delmonaco et al.’s qualitative study explores marginalized social media users’ experiences with shadowbanning through the theoretical framework of algorithmic “folk theories.” Through a review of existing literature, the authors demonstrate how social media companies publicly distance themselves from shadowbanning while continuing to apply it in practice and explain why content produced by marginalized users is more frequently subject to filtering. The study analyzes 24 interviews to explore how users perceive, theorize, and attempt to “prove” shadowbanning through indicators such as decreased visibility, engagement, and follower loss. The findings reveal widespread confusion surrounding shadowbanning, deep mistrust in platform governance, and the disproportionate harm imposed on marginalized communities whose content is suppressed despite platforms’ public denials. The data further shows how users collectively produce and co-produce theories to resist the opacity of algorithmic moderation, and authors introduce “collaborative algorithm investigation,” in which users test and share algorithmic folk theories with one another. The authors argue that algorithmic content moderation exacerbates existing inequities by obscuring governance decisions, politicizing moderation, and shifting power from human judgment to opaque predictive systems, while suggesting that increased transparency, tailored moderation approaches, and users’ education could help reduce unfair content removals.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Drolsbach, Chiara, and Nicolas Pröllochs. 2025. “Characterizing AI-Generated Misinformation on Social Media.” Preprint, ''arXiv'', May 15. https://doi.org/10.48550/arXiv.2505.10266<nowiki/>.'''
</div>
Drolsbach and Pröllochs’ article address a critical gap in existing research by shifting attention from the social drawbacks of AI-generated misinformation to its real-world prevalence and behaviour on social media platforms. Using a large-scale dataset of 91,452 misleading posts identified through X’s Community Notes platform, the authors empirically compare AI-generated and non-AI-generated misinformation across content characteristics, account attributes, virality, believability, and harmfulness. Their findings show that AI-generated misinformation is more entertainment-oriented, exhibits more positive sentiment, and is more likely to originate from smaller accounts, yet achieves significantly higher virality despite being slightly less believable and harmful than traditional misinformation. In their discussion and conclusion, the authors emphasize that AI-generated misinformation poses a growing challenge to the digital information ecosystem due to its realism, scalability, and difficulty of detection. They argue that its unique features disturb algorithmic amplification mechanisms and require new platform strategies, policy interventions, and research approaches that account for the unique properties of AI-generated misinformation rather than relying on countermeasures designed for conventional false content.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Duricic, Tomislav, Hussain Hussain, Emanuel Lacic, Dominik Kowald, Denis Helic, and Elisabeth Lex. 2023. “Beyond-Accuracy: A Review on Diversity, Serendipity, and Fairness in Recommender Systems Based on Graph Neural Networks.” ''Frontiers in Big Data'' 6: 1251072. https://doi.org/10.3389/fdata.2023.1251072.'''
</div>
Duricic et al. (2023) provide a comprehensive review of recommender systems based on Graph Neural Networks (GNNs), with a particular focus on objectives that go beyond prediction accuracy, including diversity, serendipity, novelty, and fairness. While GNNs have demonstrated strong performance in modeling complex user–item interactions and improving recommendation accuracy, the authors argue that this very strength can intensify structural biases such as popularity bias, homophily, and feedback loops that marginalize less popular content and users. The paper provides a definition of each beyond-accuracy metric, reviews how it has been used in literature, and analyzes the technical barriers of integrating these goals into GNN-based systems such as measurement difficulties, trade-offs between competing goals, and risks of overfitting due to model complexity. Diversity-aware neighbourhood sampling, contrastive learning, and adversarial training to disrupt feedback loops are introduced for more heterogeneous and unexpected recommendations. In conclusion, the authors position GNNs as a powerful but double-edged tool in recommendation systems, capable of either narrowing or broadening users’ informational horizons depending on design choices. They argue that future research must focus on principled frameworks that integrate “beyond-accuracy” objectives, emphasizing that recommendation algorithms are not neutral optimizers but key socio-technical systems shaping visibility, voice, and fairness in digital information ecosystems.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gorwa, Robert, Reuben Binns, and Christian Katzenbach. 2020. “Algorithmic Content Moderation: Technical and Political Challenges in the Automation of Platform Governance.” ''Big Data & Society'' 7 (1): 1–15. https://doi.org/10.1177/2053951719897945.'''
</div>
Gorwa et al. unfold what "Algorithmic moderation systems” are perceived as essential in AI governance to address the public demand on AI accountability and transparency that remain unnavigable and inexplicable, such that even the enhanced versions could aggravate the existing misinformation issues. They state that major platforms' growth transforms them so much that they no longer function primarily as social networks. They define “algorithmic moderation” as “systems that classify user generated content based on either matching or prediction, leading to a decision and governance outcome (e.g. removal, geoblocking, account takedown).” Different types of hashing (matching) and classification (prediction) tools and the areas they are deployed (copyright, terrorism, and toxic speech) are described and their practicality are criticized. Their case analyses including copyright enforcement, counterterrorism, and toxic speech illustrate the limitations and unintended harms of automated moderation, demonstrating how even “improved” systems risk reinforcing misinformation patterns, entrenching platform power, and displacing human judgment. Ultimately, Gorwa et al. argue that algorithmic moderation transforms platform governance itself by concentrating authority in opaque technical systems while rendering the underlying political choices invisible.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Reynolds, C. J., and Blake Hallinan. 2024. “User-Generated Accountability: Public Participation in Algorithmic Governance on YouTube.” ''New Media & Society'' 26 (9): 5107–5129. https://doi.org/10.1177/14614448241251791. '''
</div>
This study focuses on how YouTube creators respond to platform governance decisions by producing “user-generated accountability” content, videos that publicly document governance failures and pressure YouTube to intervene. Through an analysis of 250 such videos, the authors state that creators overwhelmingly experience YouTube’s policy enforcement, automated moderation systems, and communication practices as opaque, inconsistent, and often discriminatory. Authors declare that human review is essential in automizing platform governance. The study highlights that platform governance decisions affect creators differently depending on channel size, content type, and identity; larger creators can more easily mobilize audiences to “make noise,” while smaller creators rely on collective visibility tactics such as signal boosting across platforms, especially Twitter. The authors argue that these bottom-up accountability practices reflect both the limits of YouTube’s existing governance infrastructure and creators’ efforts to bypass scale dependent unresponsiveness by publicly sharing grievances, comparing experiences, and testing the platform’s algorithms themselves. Theoretically, the study provides the “user-generated accountability” as a framework for engaging with the unavoidable conflicts that will arise around algorithmic systems, and views content creators as “political actors” who advance the perceptions of algorithms. Empirically, it surfaces common concerns such as demonetization of LGBTQ content, and lack of human review.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Savolainen, Lotta. 2022. “The Shadow Banning Controversy: Perceived Governance and Algorithmic Folklore.” ''Media, Culture & Society'' 44 (6): 1091–1109. https://doi.org/10.1177/01634437221077174.'''
</div>
Savolainen studies shadowbanning as a lens for understanding current algorithmic platform governance from the user perspective. Rather than determining whether shadowbanning objectively exists, the author conceptualizes it as “algorithmic folklore”: informal, collectively produced narratives through which users attempt to make sense of opaque moderation and ranking systems. Drawing on Reddit discussions about TikTok, Instagram, and YouTube, the study shows how users interpret suppressed visibility through anecdotal evidence, experimentation, and shared pattern recognition, revealing the experiential dimensions of algorithmic governance. Either users “probe the rules” or find their ways through “pleasing the algorithms”; the author argues that these practices emerge in response to governance systems that lack the clarity, stability, and consistency that are traditionally associated with good governance. The study concludes that platform governance contains a structural paradox: platforms increasingly present themselves as legitimate governors while simultaneously developing automated moderation systems that undermine transparency and consistent enforcement. Ultimately, the ethical issue is not shadowbanning itself, but the broader reality of shadowy governance exercised by complex, distributed algorithmic systems at scale.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Vetter, Matthew A., Jialei Jiang, and Zachary J. McDowell. 2025. “An Endangered Species: How LLMs Threaten Wikipedia’s Sustainability.” ''AI & Society'', February. https://doi.org/10.1007/s00146-025-02199-9.'''
</div>
Vetter et al. caution against using Wikipedia as AI training data uncritically by outlining many complicating factors. Wikipedia’s collaborative model of data curation democratizes data creation, but embeds power dynamics and biases. A feminist posthumanist framework is applied, which situates Wikipedia’s knowledge as contextual, based upon the positionality of predominantly Western, male editors, a perspective LLMs would perpetuate without opportunity for change. Wikipedia’s "dynamism" is the main reason it is so valuable, stemming from constant, collaborative updates by volunteers. AI responses’ inconsistent citations and plagiaristic tendencies undermine human editors, the source of Wikipedia’s verifiability, and exploit scholars, Wikipedia itself, and the past labour of volunteers. Wikipedia needs both "a steady stream of new and returning readers" and "a diverse group of dedicated volunteers," whilst AI responses push sources into obscurity and at best detour the website, threatening Wikipedia’s long-term sustainability. Vetter et al. practically explore Wikipedia’s relationship with LLMs by conducting a "problem-centred expert interview" of community leaders, who possess 25 combined years of involvement and research. Through these interviews, Vetter et al. identify three main areas of opportunity: promoting transparency and explainability, diversifying the Wikipedia community, and equipping users with critical thinking skills. Overall, their findings "resonate with the posthumanist approach to critical AI literacy," cautioning against hoping for purely technological fixes and calling for greater transparency in how tech giants "leverage open-access datasets."
== Governance, Leadership, and Policy ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Balendra, Soorya. 2025. “Meta's AI Moderation and Free Speech: Ongoing Challenges in the Global South.” ''Cambridge Forum on AI: Law and Governance'' 1. https://doi.org/10.1017/cfl.2025.5<nowiki/>.'''
</div>
This article conducts a case study of Meta’s AI-based content moderation in the Global South, arguing that the censorship of unprohibited content (“over removal”) and slow response to content that causes harm (“slow removal”) are part of “content moderation procedures” that constitute “massive discriminatory approaches.” Balendra presents three models of authority for the regulation of social media content: external regulation, self-regulation, and co-regulation, and argues that state regulation (falling under the external model) varies wildly depending on the government in question, with “granting absolute regulatory power to state actors often stifl[ing] political discourse and online expression.” Co- and self-regulation mitigate this problem, but introduce a new issue by shifting responsibility—private companies use AI to make millions of judgements about content in a short frame of time. The paper notes that the EU and the United States have drastically different policies regarding content moderation on social media platforms and argues that “the practice of content moderation remains largely shaped by the cultural norms of the United States” and the values of “a relatively homogenous groups of Silicon Valley elites.” Balendra finds that, at this time, current approaches often prioritize the state or private corporate interests rather than free speech or the interests of the larger community, and much work is needed to “achiev[e] genuine change” in the form of integrated, hybrid approaches.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Birkstedt, Teemu, Matti Minkkinen, Anushree Tandon, and Matti Mäntymäki. 2023. “AI Governance: Themes, Knowledge Gaps and Future Agendas.” ''Internet Research'' 33 (7): 133–67. https://doi.org/10.1108/INTR-01-2022-0042. '''
</div>
Birkstedt et al. conduct a systematic literature review (SLR) of the emerging yet fragmented field of “AI governance” (AIG), defined as “a system of rules, practices, processes, and technological tools” that ensure organizational AI meets strategic, legal, and ethical requirements. The authors use human-centric and socio-technical AI traditions to explore how organization-level governance mechanisms can bridge the principles-to-practices gap in AI ethics. Through SLR, authors identify four research agendas. The “technical agenda” focuses on the practicalities of AIG. The “stakeholder and contextual agenda” ensures AI meets requirements via direct collaboration with external stakeholders, increased corporate social responsibility, and establishment of an “intelligent discourse regime.” The “regulatory agenda” aligns AIG with ethical and legal standards, while the technical, stakeholder and contextual, and regulatory agendas largely focus on the aims of organizational AIG (i.e., what), and the process agenda deals with the means to achieve the aims (i.e., how). The authors develop a generic framework to guide cohesive AIG practices and advocate for a collaborative governance approach that emphasizes transparency, stakeholder engagement, and sociopolitical awareness.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Broekhuizen, Thijs, Henri Dekker, Pedro De Faria, Sebastian Firk, Dinh Khoi Nguyen, and Wolfgang Sofka. 2023. “AI for Managing Open Innovation: Opportunities, Challenges, and a Research Agenda.” ''Journal of Business Research'' 167 (November 2023): 114196. https://doi.org/10.1016/j.jbusres.2023.114196. '''
</div>
Broekhuizen et al. systematically analyze how AI could be applied to the complex, unstructured task of “open innovation,” a possible business opportunity they believe has been insufficiently explored. They define “Open innovation” as “the practice of leveraging external ideas, resources, and capabilities to improve innovation outcomes,” and propose AI could minimize its inherent managerial challenges. To prove this, the authors form a framework that considers the three abilities involved in AI’s agreed possible applications to management (involving “mapping,” “coordinating,” and “controlling”) and assess how applicable their constituent functions are to the challenges of the three stages of open innovation (involving “initiation,” “development,” and “realization”). In the stage of “initiation,” they propose AI could scout for distant knowledge partners, detect relevant information gaps and opportunities, and forecast conflicts. During the “development” stage, AI could develop complementarity between partners' knowledge stocks, integrate knowledge whilst safeguarding intellectual property, and monitor partners for violations or conflicts within the relationship. Finally, during the “realization” stage the authors argue AI could comprehensively evaluate business opportunities, optimize resource deployment, and diagnose or remedy intellectual property violations. To Broekhuizen et al., this study “underscores the significance of the human-side of AI” by demonstrating AI’s valuable role in assisting management. They also conclude that AI’s ability to search for corporate partners will be its greatest impact in open innovation, as they argue it will both incentivize openness and reputability of companies and increase the need for them to keep sensitive data secure.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Cheong, Inyoung. 2024. “Collaborative Approaches to AI Governance: Exploring Co-Design and Co-Regulation Models.” PhD diss., University of Washington. https://homes.cs.washington.edu/~yoshi/papers/theses/inyoung-cheong-dissertation.pdf<nowiki/>.'''
</div>
This dissertation seeks to integrate co-design and co-regulation as a means of facilitating domain-specific expert knowledge into AI governance policies. It uses theoretical analysis and empirical data as part of its methodologies, and it should be of interest to anyone who wants detailed case studies of the use of AI technology in specific domains, as well as clear models for (co-)governance and development in the use of Artificial Intelligence. Cheong performs two case studies, examining the development and use of an AI application to provide legal advice as well as the application of AI in online content moderation of news and comics apps in South Korea. These result in a set of strategies for AI co-regulation that includes parameters for starting conditions, institutional design, collaborative process, and facilitative leadership. Cheong proposes that the guiding principles for AI co-governance must account for specific and distinct contexts, maintain human involvement and intervention in what is often seen as an artificial and automated process, and look to resolve legal ambiguities surrounding AI, especially as there is a clear history of courts dismissing what Cheong calls “collective rule-making” by the community. The author argues for the implementation of co-regulation and co-design, and maintains that “by fostering inclusive dialogues, leveraging diverse expertise, and remaining adaptable to changing technological and societal landscapes” these methods show potential for dealing with AI’s greatest challenges.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Floridi, Luciano. 2018. “Soft Ethics and the Governance of the Digital.” ''Philosophy & Technology'' 31 (1): 1–8. https://doi.org/10.1007/s13347-018-0303-9<nowiki/>.'''
</div>
Floridi argues our “mature information societies” means “we no longer live online or offline, but onlife,” making the sociopolitical challenge of ethically governing this foundational “digital age” even more vital than pursuit of future digital innovations. Floridi defines three overlapping subfields within the “Governance of the Digital,” including “Digital Ethics,” “Digital Regulation,” and the encompassing “Digital Governance.” The latter is defined as “the practice of establishing and implementing policies, procedures, and standards for the proper development, use and management of the infosphere,” therefore “sometimes neither moral nor immoral… legal nor illegal.” This demonstrates that the three subfields don’t always overlap, but each must always be considered by policymakers, because what is legal, what is good, and what is best are all key components of the ideal “Governance of the Digital.” “Digital Ethics” should also be further subdivided into “hard” ethics, involving binary moral judgments about what should versus should not be done, and “soft” ethics, which involves a “post-compliance,” “post-feasibility” approach, ensures moral opportunities are maximized, and fosters “good corporate citizenship.” Differing “information societies” occupy differing levels of maturity, producing distinct ethical contexts which should progress with differing ethical focuses. In this regard, Floridi advocates “ethics foresight analysis,” which uses data analytics to assess ethical impacts of future innovations then targets research by systematically identifying what is feasible, then sustainable, then acceptable, then preferable. The author concludes that Digital Ethics must be “leading” not “chasing” developments, and not just functioning as a questioning exercise, but also signalling that ethical issues matter, engaging with stakeholders, and providing shareable solutions.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gasser, Urs, and Virgilio A. F. Almeida. 2017. “A Layered Model for AI Governance.” ''IEEE Internet Computing'' 21 (6): 58–62. https://doi.org/10.1109/MIC.2017.4180835<nowiki/>.'''
</div>
This article identifies the gap in knowledge created by the “black box” of AI—the obscured nature of the processes that take place from an initial prompt to its generated output. Gasser et al. note that users and policymakers of these technologies have relatively little insight into how it actually works compared to its developers. Given this unique issue, Gasser et al. propose a theoretical framework for how to approach AI governance, drawing upon the advent and subsequent globalization of the Internet to inform their understanding of AI technology and its pattern of growth. The article addresses a core issue that strong or general AI is often discussed in terms of potential societal impact while weak or general AI is currently being deployed right now (i.e., 2017) and is in real need of governance already. The authors identify core themes related to “transparency, accountability, and explainability; inclusion and fairness; [and] global governance,” as well as three challenges for AI governance—"information asymmetries”; “finding normative consensus”; and “government mismatches”. The authors point out that the ethical and legal considerations of AI are closely related and take a modularity approach; they present three layers for governance that exist from AI systems to society, with timing (i.e., near-, mid-, and long-term) and considerations for each layer. The article concludes by proposing AI governance requires a blended approach based on the different risks of certain AI applications and propose that both “market-oriented solutions” and "government-based structures” can work on a national or international level, suggesting a “global oversight body” could act as “the curator of global principles and emerging norms for AI systems.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Kirschenbaum, Matthew. 2025. “The US of AI.” Public Draft, February 25, 2025. https://drive.google.com/file/d/1O2qkjhg7Ei5zZWmBraNwXq4V0lTauspN/view<nowiki/>.'''
</div>
This set of notes from Kirschenbaum represents his “near real-time attempt to come to terms with… the opening weeks of the second Trump Administration,” especially the “AI-first” strategy of “the so-called Department of Government Efficiency (DOGE).” Kirschenbaum outlines DOGE has nothing to do with government efficiency, as it only saves insignificant costs, instead possessing ideological and capitalistic motivations to form “a government without people.” Based on Musk’s nebulous authority—as an advisor from the private sector—DOGE targeted nineteen federal agencies to be “strip-mined and fracked for all manner of information” as a “priceless and unprecedented resource” of AI training data. To do so, DOGE operatives accessed sensitive spaces after hours, combining physical aggression with a “complete lack” of technical inhibition representing a “vampiric data suck.” Kirschenbaum identifies clear corporate interests here and further examines ideological aims. Early executive orders asserted the need for federal AI systems “free from ideological bias or engineered social agendas,” with OpenAI announcing “ChatGPT Gov” days later. These invocations of “AI” as a universal solution represent only a “linguistic token” instead of any realized technology—as worded by Salvaggio, AI must only “be considered a plausible competitor to human decision-making long enough to dislodge the existing human decision-makers.” Kirschenbaum frames this as based in the “masculine maximalism” of the Trump administration, as the term AI promotes “technological absolutism” whilst theoretically playing into the Nixon-era “theory of the unitary executive” by aiming to replace people with “void” and consolidate power into the hands of “a super-user class who will operate outside the system.” However, “the real world intrudes… with lethal downstream effects.” Kirschenbaum proposes “a collapsing superimposition of political discourse, the actual operations of social media as its primary public arena, and the technical architecture of the systems (in the form of AI)… in the sphere of governance as well as media,” which produces the “infrastructure for… permanent despotism” via the “untethering of language from conditions of lived reality.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Oh, Dayei, and John Downey. 2024. “Does Algorithmic Content Moderation Promote Democratic Discourse? Radical Democratic Critique of Toxic Language AI.” ''Information, Communication & Society'' 28 (7): 1157–76. https://doi.org/10.1080/1369118X.2024.2346531.'''
</div>
Oh and Downey critically examine how algorithmic content moderation shapes public discourse, focusing specifically on Google’s Perspective API and its detection of "toxic" language. By drawing a crucial distinction between incivility (harsh or emotional tone) and intolerance (actual discriminatory harm), the authors demonstrate how AI-driven moderation systems frequently misinterpret context. Consequently, these algorithms often suppress emotionally charged but politically significant speech—particularly from marginalized groups—while allowing structurally discriminatory but politely phrased content to evade detection. This dynamic reveals a significant flaw in relying on AI as a neutral mediator of digital dialogue: by prioritizing tone over substance, algorithmic moderation actively curtails democratic participation and skews the visibility of diverse perspectives. Their study is relevant for understanding how AI systems act as invisible gatekeepers, enforcing normative boundaries on public expression and highlighting the urgent need for moderation frameworks that are contextually aware, transparent, and equitable rather than merely tone-policing.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Rughiniș, Cosima, et al. 2025. “AI at the Knowledge Gates: Institutional Policies and Hybrid Configurations in Universities and Publishers.” ''Frontiers in Computer Science'' 7: 1608276. https://doi.org/10.3389/fcomp.2025.1608276. '''
</div>
This article constitutes a qualitative analysis (i.e., a form of computational analysis) of 16 universities and 12 publishers that attempts to understand how these institutions regulate AI in knowledge production. Rughinis et al. claim that most institutions preserve their values while regulating AI by adapting the regulations they already have in place, stating “institutional policies are shaped by value-based compromises and not by technical concerns alone.” At the same time, although the article acknowledges its focus on institutional regulation, it also admits that “AI adoption can evolve both through policy frameworks and… locally embedded practices that remain partly invisible in formal documentation.” The authors propose two concepts, “dual black-boxing” and “legitimacy-dependent hybrid actors.” Dual black-boxing refers to the lack of transparency in both the “hidden algorithmic processes [and] invisible training data” that shape AI systems and “the opacity surrounding how academics employ AI in their work,” while legitimacy-dependent hybrid actors are “configurations of human-AI collaboration whose institutional legitimacy is not intrinsic but conditional.” Rughinis et al. argue that transparency is a core academic value, and scholars must work to open these black boxes; they also suggest that that transparency is more closely linked to academic legitimacy in AI-related issues rather than the more traditional issue of the origin of ideas. The majority of the article applies these terms to understanding the regulatory frameworks of universities and publishers, and concludes with the understanding that the majority of institutions allow some form of AI use within certain parameters. The key types of hybrid actors allowed by universities were AI-assisted researchers, AI-enabled translators, AI-enhanced writers, and AI-supported coders, while publishers facilitated the use of AI to refine language, support research methodologies, and aid in research. Ultimately, the authors observe that institutions are permitting AI-supported work in refined roles and argue that AI-based academic work gains legitimacy through transparency.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Seger, et al. “Democratising AI: Multiple Meanings, Goals, and Methods.” ''Proceedings of the 2023 AAAI/ACM Conference on AI, Ethics, and Society''. https://dl.acm.org/doi/10.1145/3600211.3604693<nowiki/>.'''
</div>
Aiming to “provide a foundation for more productive conversations,” Seger et al. categorize four forms of “AI democratisation” and explore each form’s goals and facilitation pathways. Democratization of AI “use” involves making it easier for people to employ AI’s capabilities, and is therefore equally comparable to increasing availability of printers or of tools which can create chemical weaponry, depending on the case. Democratization of “development” involves allowing a wider range of people to contribute to the AI design and development process, which accelerates progress and increases diversity, but also opens the door for maliciousness and irresponsibility. Democratizing “profits” constitutes a philanthropic or redistributive process, and has the predictably involved weaknesses. Therefore, the authors highlight that “AI democratisation is a multifarious and sometimes conflicting concept” which “should not be conflated with improving AI accessibility” and “is not inherently good.” This is because democratization of AI’s “use,” “development,” and “profits” only derives value from its alignment with the interests and values of impacted groups, making democratization of AI’s “governance” the priority. Democratization of “governance” does not necessarily aim for total agreement amongst constituents, but will regardless reduce the unilaterality of decision-making by promoting justice, legitimacy, and diversity.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Sposato, Martin. 2025. ”Artificial Intelligence in Educational Leadership: A Comprehensive Taxonomy and Future Directions.” ''International Journal of Educational Technology in Higher Education'' 22 (20). https://doi.org/10.1186/s41239-025-00517-1. '''
</div>
This article performs an analysis and review of published works on AI in educational leadership from 2017–2024 and uses the results of that process to develop what Sposato describes as “a comprehensive taxonomy of AI applications in educational leadership.” Potential readers include researchers and policymakers interested in communicating across specific fields and disciplines. Sposato theorizes ten application domains for AI in higher education ranging from increased efficiency in administration and teaching practices to increased community engagement and strategic planning. The purpose of such a framework is to provide educational leaders with a coherent vocabulary of “the full spectrum of educational leadership responsibilities” that can facilitate further conversation. The author advocates for AI’s transformative potential in higher education even as they note important challenges (especially with ethics and equity), arguing a need for a balanced approach and “robust ethical guidelines and regulatory frameworks.” The framework provided is presented as one step toward developing AI literacy for stakeholders so that all involved in education might make more informed decisions and articulate their needs more clearly.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Ter-Minassian, Lucile. 2025. ”Democratizing AI Governance: Balancing Expertise and Public Participation.” Preprint, ''arXiv'', January 16. https://doi.org/10.48550/arXiv.2502.08651<nowiki/>.'''
</div>
Ter-Minassian argues that “universal access, technically-constrained development, and universal impact” of AI and AI research necessitate public participation in AI governance even as it “creates a unique governance challenge.” The article presents the benefits and challenges of expert oversight and public consultation. Ter-Minassian outlines the threat of misinformation to meaningful public participation, highlighting how both undue fear and unrealistic optimism surrounding AI can affect public discourse, while acknowledging that the rapid rate of AI research makes it difficult to incorporate truly democratic processes into the decision-making process. The author concludes that any ongoing inclusive and effective AI governance ought to incorporate inclusive representation, balance expertise and public engagement, embrace transparency and accountability while engaging an iterative process, and implement a hybrid framework that “blend[s] expert knowledge with meaningful public input” (4). She argues that “AI’s deep societal impact calls for public engagement” and “technical complexity does not have to exclude meaningful public input,” advocating for “structured deliberation and phased public participation” to address “time-sensitive AI challenges without compromising democratic legitimacy” (5). Ultimately, the article sees this as an iterative process that will need to continue to adapt in order to maintain expert insight and public discourse on AI.
== Critical Literacies ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Aguiar, Micaela, and Sílvia Araújo. 2024. “Final Thoughts: Digital Humanities Looking at Generative AI.” ''In Digital Humanities Looking at the World'', edited by S. Araújo et al., 367–380. Cham: Springer Nature Switzerland.'''
</div>
Aguiar and Araújo explore the emergence and applications of generative artificial intelligence within Digital Humanities research. They trace the evolution of generative AI from early implementations like the 1960s Eliza chatbot through its developments such as Generative Adversarial Networks (GANs) and the Transformer architecture to contemporary large language models like BERT and GPT. The authors document current applications of generative AI across Digital Humanities domains, including cultural heritage preservation, historical text processing, and literary creation. They outline how these technologies are being used to memorialize mass atrocities, process traditional Chinese ancient texts, and explore collaborative human-AI poetry creation. Aguiar and Araújo examine the inner workings of generative AI, particularly focusing on how conversational models function through statistical prediction rather than genuine comprehension. They identify limitations such as hallucinations, bias replication, and attribution problems that researchers must consider when using these tools. The chapter concludes that effective integration of generative AI in Digital Humanities requires developing AI literacy skills that enable researchers to critically evaluate outputs while leveraging the technology's capabilities for sustainable research advancement.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Boer, Victor de, and Lise Stork. 2024. “Hybrid Intelligence for Digital Humanities.” Preprint, ''arXiv'', April 15. https://doi.org/10.48550/ARXIV.2406.15374. '''
</div>
De Boer and Stork believe the discipline of Digital Humanities (DH) should meet the challenges and opportunities posed by Artificial Intelligence (AI) by adopting the “human-centric paradigm” of Hybrid Intelligence (HI). They define DH as “a scholarly realm where computing or digital technologies intersect with… the humanities… characterized by innovative approaches to scholarly endeavors,” and identify various existing DH approaches to AI, which include “Knowledge Representation,” “Machine Learning,” “Natural Language Processing,” and “Computer Vision.” De Boer and Stork argue successfully integrating AI tools into DH requires embedding AI in scholarly practice, adopting a diverse and polyvocal approach, considering the debate of distant versus close reading, and applying a critical stance toward data, methods, and tools. HI “concerns itself with the investigation and design of human-AI ecosystems,” and the authors argue effective AI should be developed by following its “CARE” principles—being “Collaborative, Adaptive, Responsible, and Explainable.” Therefore, De Boer and Stork focus this text on mapping CARE principles to those DH requirements earlier outlined. Overall, they concur with Goodlad and Baker that humanists “are ideal 'domain experts' for the current juncture,” and end by identifying two overarching challenges. The first challenge is “one-shot solutions,” including tools, datasets, and methods that aren’t reusable, Open Source, accessible, and well described. Secondly, they identify the human factor—actors will need both an open mind and AI literacy to be equally critical of and cooperative with AI. Therefore, the authors emphasize the importance of teaching digital methods within the humanities curricula.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Carmi, Elinor, Simeon J. Yates, Eleanor Lockley, and Alicja Pawluczuk. 2020. “Data Citizenship: Rethinking Data Literacy in the Age of Disinformation, Misinformation, and Malinformation.” ''Internet Policy Review'' 9 (2). https://doi.org/10.14763/2020.2.1481.'''
</div>
This study argues that dominant understandings of digital and data literacy are insufficient for addressing contemporary complex challenges of disinformation, misinformation, and malinformation. They propose the concept of data citizenship to reframe literacy as a fundamentally civic, political, and collective practice rather than a set of individual technical skills. The authors contend that information disorders cannot be addressed through technological solutions alone, as they are deeply embedded in structural inequalities, platform economies, and power asymmetries shaping datafied societies. The article builds on a literature review and secondary data analysis drawing on Me and My Big Data project, alongside the development of a nationally representative UK survey. The authors identify three major gaps in existing literacy frameworks: an overemphasis on individual competence rather than networked practices, a lack of critical engagement with algorithmic and economic infrastructures of platforms, and the absence of proactive civic skills such as contesting data extraction, demanding transparency, and advocating for data justice. Their analysis highlights how citizens’ data practices are shaped by social networks, education, and socio-economic conditions, revealing unequal capacities for verification, protection, and collective action. The authors conclude that data literacy must move beyond content verification to include critical understanding of platform design, funding models, and algorithmic governance. They emphasize the importance of locally grounded, participatory approaches to data literacy education that reflect diverse lived contexts rather than scalable, top-down interventions. While the study offers a robust conceptual model and survey-based insights, it does not yet include in-depth qualitative engagement with citizen groups, which the authors position as a necessary next phase of research. Overall, the article makes a significant contribution by bridging digital literacy and the field of mis/dis/mal information research and claims that data literacy is an essential component of democratic citizenship.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Long, Duri, and Brian Magerko. 2020. “What is AI Literacy? Competencies and Design Considerations.” In ''Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems'', 1–13. New York, NY: Association for Computing Machinery. https://doi.org/10.1145/3313831.3376727.'''
</div>
The authors present an exploratory review of interdisciplinary literature, aiming to organize key ideas on AI literacy definitions and essential competencies. Authors claim that public misunderstandings of AI are due to design, educational gaps, black-box algorithms, and a general lack of technological knowledge. The review includes two sections: how the public understands specific AI systems, and how existing research addresses people’s broader understanding of AI. Rather than offering an exhaustive synthesis, Long and Magerko’s focus is on non-technical audiences and they offer central provocations and design principles that can inform educational interventions. The proposed conceptual framework on AI literacy identifies 17 core competencies alongside 14 design considerations for educational intervention, which are described and supported by relevant literature. Together, these considerations position the framework as a practical and reflective tool for designing AI literacy interventions that move beyond dominant media narratives and foster critical, informed engagement with AI technologies.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Majdik, Zoltan P., and S. Scott Graham. 2024. “Rhetoric of/with AI: An Introduction.” ''Rhetoric Society Quarterly'' 54 (3): 222–31. https://doi.org/10.1080/02773945.2024.2343264. '''
</div>
Majdik and Graham propose a field-organizing distinction that functions as a methodological argument. By splitting inquiry into “rhetoric of AI” (AI as object) and “rhetoric with AI” (AI as method), they treat AI simultaneously as a rhetorical actor/ecosystem component that structures attention, circulation, and uptake, and an instrument that can be enrolled into rhetorical research workflows. The authors claim that much prior rhetorical work engaged “spaces of AI”—platforms, devices, and algorithmically mediated environments—while leaving “AI” itself undertheorized as the central object; this provides a justification for why rhetoricians should now foreground model/algorithmic operations (and their harms) rather than treating them as neutral background conditions of digital rhetoric. They also frame generative text systems as a stress test for core rhetorical concepts—agency, authorship, and audience—because these systems destabilize the presumed linkage between human intention and textual production, and because they insert nonhuman intermediaries into communicative situations that education and public discourse still normatively treat as human-to-human. The introduction then uses this distinction to stage the special issue’s contributions as complementary routes for rebuilding rhetorical theory and pedagogy under AI conditions.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Ng, Davy Tsz Kit, Jac Ka Lok Leung, Samuel Kai Wah Chu, and Maggie Shen Qiao. 2021. “Conceptualizing AI Literacy: An Exploratory Review.” ''Computers and Education: Artificial Intelligence'' 2: 100041. https://doi.org/10.1016/j.caeai.2021.100041. '''
</div>
This article presents an exploratory review of literature published between 2016 and 2021 with the goal of conceptualizing AI literacy and proposing a comprehensive framework for teaching and evaluating it. The authors analyze 30 articles and synthesize existing definitions and approaches to AI literacy, noting that while AI literacy has increasingly been discussed, the concept has often been treated narrowly as a technical skill set. The authors situate AI literacy as a necessary competency for everyone, arguing that AI will increasingly affect many aspects of daily life and employment. In response, the authors argue for a broader understanding of AI literacy that incorporates cognitive and ethical dimensions. The proposed framework organizes AI literacy into four interconnected facets: knowing and understanding AI, using and applying AI, evaluating and creating AI, and AI ethics. Importantly, the authors explicitly reject purely instrumentalist views of AI literacy. To conceptualize AI literacy pedagogically, the authors draw on Bloom’s classic taxonomy, aligning the above-mentioned aspect with increasing cognitive levels. They claim that while most people are aware that AI exists, they often lack understanding of how it works or how to assess its ethical and social implications. This approach positions AI literacy as a developmental learning process rather than a static set of skills. The article concludes by identifying directions for future research, including the need for empirical studies to validate AI literacy frameworks and to better understand how AI literacy can be taught, learned, and assessed across educational contexts.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Rapanta, Chrysi, Anna Åkerfeldt, Mark Vanderbeeken, Diane Lison, Khadija Mohammed, Amanda Gibbs, Helder Coelho, Pinar Seda Celik, Carola Bruna, Ingrid Helleve, Chrysoula Vassilakopoulou, Pieter Swart, Ana Lúcia Marques, and Dirk Ifenthaler. 2025. “Critical GenAI Literacy: Postdigital Configurations.” ''Postdigital Science and Education'' 17 (1): 167–199. https://doi.org/10.1007/s42438-025-00573-w.'''
</div>
Rapanta et al. develop a comprehensive and pluralistic account of what critical literacy means in the context of generative artificial intelligence. Drawing on contributions from fourteen scholars, the article argues that GenAI literacy cannot be captured through a single, universal framework. Instead, it must be understood as a set of context-dependent literacies shaped by disciplinary traditions, socio-political conditions, and evolving human–algorithm relations. This postdigital perspective challenges narrow definitions of AI literacy that prioritize technical skills. The authors’ central claim is that current GenAI systems, particularly large language models, require critical engagement because of their epistemic limitations, including reliance on dominant narratives, lack of explainability, tendencies toward fabrication, and reinforcement of Western and anglophone knowledge structures. As a result, critical GenAI literacy is positioned as a social justice concern rather than a neutral competency. Learners and educators are encouraged to examine questions of authorship, agency, and power, such as whose labour and data underpin these systems and which perspectives are marginalized or erased. Methodologically, the article adopts a dialogic and collective approach to resist homogenizing AI epistemologies and to foreground plurality in postdigital research. The authors conceptualize GenAI as part of a co-constructive assemblage in which human and non-human agencies interact, while maintaining that ethical responsibility and evaluative judgment must remain human-led, organizing four interrelated dimensions: epistemology and ontology, agency, engagement, and ethics and justice; each emphasizing critical interrogation, active participation, and accountability. Overall, the paper provides a theoretically grounded yet pragmatic foundation for advancing critical GenAI literacy in education and research.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Veldhuis, Annemiek M., Phoebe W. K. Lo, Iain E. G. Kenny, and Alissa N. Antle. 2024. “Critical Artificial Intelligence literacy: A scoping review and framework synthesis.” ''International Journal of Child-Computer Interaction'' 43: 100708. https://doi.org/10.1016/j.ijcci.2024.100708<nowiki/>.'''
</div>
Veldhuis and colleagues present a review of literature and framework synthesis that conceptualizes critical AI literacy from a child–computer interaction (CCI) perspective. Reviewing 30 empirical studies published over the past decade, the authors aim to understand how children and youth aged 5–18 have been supported in developing critical literacy on AI technologies, particularly regarding their social, political, cultural, and ethical implications. Grounded in critical literacy theory, the authors integrate Lewison et al.’s (2002) four interrelated dimensions including disrupting the commonplace, considering multiple viewpoints, focusing on the sociopolitical, and taking action into a four-part framework for critical AI literacy. Importantly, the framework rejects deficit narratives by foregrounding children’s capacity for critical inquiry and demonstrates that even young learners can meaningfully engage with complex issues such as algorithmic bias, data provenance, privacy, accountability, and the distinction between AI-generated outputs and human creativity when supported by pedagogies such as critical making. Only peer-reviewed, English-language empirical studies with explicit support for children’s critical engagement with AI were included. The findings reveal a growing body of research, particularly in the past three years, exploring activities that promote youths’ critical reflection on AI’s societal and ethical impacts. These activities address concerns related to privacy, surveillance, employment, diversity in the computing workforce, algorithmic bias, and accountability. The resulting framework emphasizes learners’ capacity to analyze both AI artifacts and the sociotechnical systems that produce them, as well as to reflect on how AI shapes cultural, societal, and political structures and personal experiences. For future research recommendations, the authors emphasize the urgency of ongoing critical AI literacy practices in areas of youth emotional awareness and socio-cultural impacts in response to the fast evolution of generative AI systems.
== Globalism, Colonialism and Influence ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Arora, Payal. 2024. “Creative data justice: a decolonial and indigenous framework to assess creativity and artificial intelligence.” ''Information, Communication & Society'' 28 (13): 2231–47. https://doi.org/10.1080/1369118x.2024.2420041<nowiki/>.'''
</div>
Arora (2024) develops a framework of creative data justice that includes decolonial theory, Indigenous perspectives, and critical studies of creativity to explore how generative AI could impact creative labour, rights, and cultural value. The author argues that democratizing creativity requires a cross-cultural framework that considers power relations between creative work, data, and learning, particularly by centring the lived realities of underrepresented communities in the Global South. Rather than treating AI creativity as neutral, the paper claims that inclusive AI systems must address contextual inequalities and the unequal impacts of AI on diverse creative communities. Arora critiques dominant Western-centred scholarship and challenges concepts such as the “creative class,” arguing that creativity exists across everyday social and cultural practices. The paper also critiques Creative Commons (CC) frameworks, suggesting that while they promote openness, they may enable commercial data extraction by AI companies. Instead, the author argues for dataset curation developed with Indigenous artists and activist groups to ensure equitable representation. The article further highlights the often-invisible labour behind creative AI located in the Global South and argues that a decolonial approach must recognize both material infrastructures and power relations shaping creative work. Indigenous approaches to communal ownership and systems of care are presented as alternatives to Western individualistic models of creative rights. The author advocates combining ethnographic “thick data” with computational approaches and suggests action-research methods such as counter-mapping, dataset debiasing, and critical media literacies. The paper concludes that creative data justice offers a framework for building culturally diverse and equitable AI systems that respect community agency and support a more democratic global data economy.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Fırıncı, Yusuf. 2024. “Decolonial Artificial Intelligence; Algorithmic Fairness in Alignment with Turkish and Islamic Values.” ''Marmara Üniversitesi İlahiyat Fakültesi Dergisi'' 67 (67): 250–279. https://doi.org/10.15370/maruifd.1565884<nowiki/>.'''
</div>
Fırıncı argues that artificial intelligence development should be guided by explicitly value-based frameworks grounded in Turkish-Islamic ethical traditions rather than relying solely on dominant Western models of technological governance. The authors emphasize that AI systems rely on human judgment and are inherently value-laden, making ethical alignment essential to prevent manipulation, misinformation, algorithmic bias, and forms of digital coloniality. Drawing on concepts such as big data, “thick data,” and digital anthropology, the paper suggests combining quantitative data analysis with culturally grounded social knowledge to design algorithms that reflect community values. The paper examines tensions between Western liberal individualism (which underpins most AI fairness metrics) and Islamic ethical frameworks that emphasize communal welfare, divine justice, and context-dependent moral reasoning. This analysis reveals that "fairness" is not a universal technical specification, but a deeply value-laden concept shaped by particular cultural, religious, and philosophical commitments—meaning that AI systems designed around Western fairness assumptions may be experienced as unjust in contexts operating from different ethical frameworks. Using Social Construction of Technology theory and critical social constructivism, the authors argue that existing global AI frameworks often reproduce hierarchy, bias, and external control, which they interpret as forms of algorithmic oppression. In response, they advocate a “fairness in alignment with values” approach grounded in Turkish-Islamic worldviews, supported by Islamic ethical principles as foundations for responsible technological development. The paper concludes by calling for locally controlled data infrastructures, culturally aligned AI systems, and knowledge production rooted in Turkish and Islamic values as part of a broader decolonial technological model aimed at protecting communities from AI-related harms and preserving social cohesion.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Mohamed, Shakir, Marie-Therese Png, and William Isaac. 2020. “Decolonial AI: Decolonial Theory as Sociotechnical Foresight in Artificial Intelligence.” ''Philosophy & Technology'' 33 (4): 659–84. https://doi.org/10.1007/s13347-020-00405-8. '''
</div>
Mohamed et al. explore the role of post-colonial and decolonial critical science in understanding the transformative technological advance of AI. They argue risks to vulnerable peoples can be minimized by linking ethical principles to scientific progress, and therefore consider AI’s embedded values, approaching it a"s both object and subject." They demonstrate that AI advances "encompass ever-larger aspects of the cultural, economic and political life of modern society" by citing Obermeyer et al.’s reveal of racial biases within an algorithm commonly used by healthcare, arguing this indicates how AI obscures and exacerbates asymmetrical power relations. Mohamed et al. identify neglect to address systemic racism as the cause, illustrating that patterns of power between colonizer and colonized survived territorial decolonization to propagate a historically continuous "coloniality of power." Therefore, "dynamic and robust foresight tactics and methodologies grounded in the critical sciences" (like, for example, a "lens of metropole and periphery") should be applied to the field of AI to ensure one’s view is "decentring," "additive-inclusive," and prioritizes "engagement." The authors further explore emergent theories of data colonialism within their assessment of "algorithmic coloniality." This involves their taxonomy of "decolonial foresight" (constituting algorithmic "oppression," "exploitation," and "dispossession"), and an exploration of various "sites of coloniality" (including "algorithmic decision systems," "ghost workers," "beta-testing," "national policies," and "international social development"). They argue this study highlights the disjunction of empirical observations with the current, theoretical, and ahistorical frameworks of power in AI. This leads the authors to outline a set of tactics to develop "decolonial AI" possessing a strengthened empirical basis and an avoidance of algorithmic colonialism. Such tactics are "based on lessons of resistance and recovery from historical and decolonial criticism and grounded within already existing work"; they include critical technical practice, seeking reverse tutelage and pedagogies, and renewing affective political communities. Mohamed et al. emphasize that those ethical principles which form the "social contract" must consider diverse viewpoints, and that new methodologies must be developed to promote "inclusive dialogue" within new research cultures.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Muldoon, James, and Boxi A. Wu. 2023. “Artificial Intelligence in the Colonial Matrix of Power.” ''Philosophy & Technology'' 36 (4). https://doi.org/10.1007/s13347-023-00687-8<nowiki/>.'''
</div>
Muldoon and Wu (2023) extend decolonial AI scholarship by situating contemporary artificial intelligence within what Aníbal Quijano terms the “colonial matrix of power,” and arguing that from data to production machine learning systems are structured to endure colonial logics that organize economic extraction, labour hierarchies, and epistemic dominance. Central to their framework is the “colonial matrix of power,” which names an organizing principle of domination across interrelated domains: economic control (labour and resources), authority, gender and sexuality, and the control of subjectivity and knowledge. Authors focus particularly on economic extraction and epistemic domination, drawing on the modernity/coloniality research program. They proceed with three interconnected claims: “colonial supply chain of AI,” “international division of digital labour,” and “hegemonic knowledge production,” demonstrating how AI development relies on largely invisible labour and mineral resources of majority-world communities to generate wealth for Western economies. Beyond material extraction, the authors contend that AI reproduces hegemonic Western epistemologies by presenting its systems as universal, objective, and rational, thereby marginalizing non-Western knowledge systems. This study challenges dominant narratives that present AI as environmentally sustainable or socially progressive, arguing that from mineral extraction to energy-intensive computation, the ecological and material burdens fall disproportionately on majority-world nations, while the economic and technological benefits accrue to wealthy Western nations. They conclude by emphasizing that coloniality is not merely an object of study but a framework for unsettling Western-centric modes of knowing.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Salami, Aishat Oyenike. 2024. “Artificial intelligence, digital colonialism, and the implications for Africa's future development.” ''Data & Policy'' 6. https://doi.org/10.1017/dap.2024.75. '''
</div>
Salami (2024) studies how artificial intelligence operates within broader dynamics of digital colonialism in Africa, arguing that AI risks reinforcing patterns of colonialism, unless African actors gain greater agency in digital governance. The article begins by clarifying key concepts like AI, digital colonialism, neocolonialism, and data exploitation. Salami identifies several manifestations of digital colonialism on the continent: foreign ownership of critical digital infrastructure, unequal data flows in which African user data is extracted and monetized abroad, and algorithmic systems that enable forms of economic exploitation. Through examples such as ride-hailing platforms and outsourced digital labour, the article demonstrates how algorithmic control can generate precarious working conditions while concentrating profit outside the continent. Beyond labour concerns, Salami highlights how data extraction contributes to a digital wealth transfer, deepening economic imbalances and undermining local innovation and national sovereignty. While acknowledging the potential benefits of AI for development, the article adopts a cautious stance, emphasizing that Africa’s digital future depends on strengthening regulatory frameworks, expanding infrastructure, investing in education and research, and prioritizing data sovereignty.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Varshney, Kush R. 2024. “Decolonial AI Alignment: Openness, Visesa-Dharma, and Including Excluded Knowledges.” ''Proceedings of the AAAI/ACM Conference on AI, Ethics, and Society'' 7: 1467-1481. https://doi.org/10.1609/aies.v7i1.3173<nowiki/>.'''
</div>
Varshney discusses AI alignment through a decolonial lens, arguing that current large language model (LLM) alignment practices reproduce forms of coloniality by embedding Western moral philosophy as universal. The author conceptualizes alignment as the post-training processes used to shape model behavior and argues that the term often functions as an “empty signifier,” masking whose values are being encoded and enforced. The author contrasts open and closed LLM models, arguing that while openness may allow value to circulate more equitably among developers and communities, closed models concentrate value in extractive ways that reflect colonial dynamics, and views them as contemporary “metropoles” that accumulate power through extractive and epistemic control. Building on existing research on colonial AI, the article adds “ethical essentialism” (or moral absolutism) as a new form of coloniality, arguing that AI systems often treat Western moral frameworks as universal, which marginalizes other ethical traditions and reinforces a coloniality of knowledge. Varshney also identifies three specific aspects of coloniality in AI alignment: closed proprietary delivery of models, reliance on Western ethical theories as default, and technological designs that limit how values can be expressed. As an alternative, Varshney proposes a decolonial approach grounded in openness understood not only technically but epistemically: openness to research artifacts, openness to society, and openness to excluded knowledges. The author suggests that alignment should allow communities to adapt models according to local contexts rather than imposing universal rules. Drawing from Hindu moral philosophy, particularly the concept of viśeṣa-dharma (context-dependent ethics), the paper argues for pluralistic, relational value systems that recognize moral diversity instead of universal moral commands. The conclusion calls for a reconceptualization of AI alignment that moves away from moral absolutism toward context-sensitive, community-driven frameworks, positioning openness as a pathway to dismantling the colonial power structures embedded in contemporary AI systems.
== Diversity, Determinism, Bias and Justice ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Al-kfairy, Mousa , Dheya Mustafa, Nir Kshetri, Mazen Insiew, and Omar Alfandi. 2024. “Ethical Challenges and Solutions of Generative AI: An Interdisciplinary Perspective.” ''Informatics'' 11 (3): 58. https://doi.org/10.3390/informatics11030058'''
</div>
Al-kfairy et al. (2024) provide a comprehensive synthesis of the ethical vulnerabilities introduced by generative AI, utilizing an interdisciplinary review of 37 studies across healthcare, education, and media. Rather than treating ethical breaches as isolated technical flaws, the authors demonstrate how generative models systematically threaten privacy, intellectual property, and social equity across diverse domains. For instance, they highlight the paradox in healthcare where synthetic patient data—often intended to protect privacy—still carries significant risks of re-identification. Similarly, the authors trace how AI's capacity to mimic copyrighted works and generate synthetic media exacerbates both misinformation and algorithmic bias, particularly by perpetuating racial and gender stereotypes in high-stakes environments like hiring and education. Moving beyond mere critique, the article advocates for a proactive, cross-sectoral governance framework. The authors argue that mitigating these risks requires more than algorithmic adjustments; it demands multidisciplinary collaboration, robust institutional integrity policies, and targeted AI literacy programs. Ultimately, Al-kfairy et al. frame the ethical deployment of generative AI as a complex socio-technical challenge that requires continuous, structured dialogue among technologists, ethicists, and policymakers to ensure transparency and fairness.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Alvarez, Jose M, Alejandra Bringas Colmenarejo, Alaa Elobaid, Simone Fabbrizzi, Miriam Fahimi, Antonio Ferrara, Siamak Ghodsi, et al. 2024. “Policy Advice and Best Practices on Bias and Fairness in AI.” ''Ethics and Information Technology'' 26 (2). https://doi.org/10.1007/s10676-024-09746-w. '''
</div>
This article attempts to provide “an up-to-date entry-point to the state-of-the-art of the multidisciplinary research on bias and fairness in AI” before providing its own suggestions for policy and best practices based on the outcomes of the NoBIAS – Artificial Intelligence without Bias – Project. The authors describe fairness in AI as the pursuit to design “methods for detecting, mitigating, and controlling biases in AI-supported decision making”, and they outline different ways that bias can find its way into AI applications as part of training data (pre-existing bias), design (technical bias), and organizational processes (emerging bias). The article critiques the reduction of bias evaluation to simple metrics and advocates for serious engagement with the issue. The authors detail the various components of the collaborative NoBIAS project as part of its research goal to understand, mitigate, and account for bias in AI data and systems, especially within an EU legal context. They perform a survey and discuss various fairness metrics and how choosing the proper method is crucial for “optimizing AI models”. They also engage with an argument that, although AI is biased, it is less biased than humans, making the claim that AI usage is often accompanied by a false sense of objectivity. The article also investigates core issues at the heart of AI’s biases, such as the assumption that a “ground truth”—the answer to the problem the AI is being asked to solve—is actually encoded within the data. While the article makes many suggestions for how to curb bias within AI, prominent design decisions include human-centric AI and “Multi-stakeholder participatory design”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gallegos, Isabel O., Ryan A. Rossi, Joe Barrow, Md Mehrab Tanjim, Sungchul Kim, Franck Dernoncourt, Tong Yu, Ruiyi Zhang, and Nesreen K. Ahmed. 2024. “Bias and Fairness in Large Language Models: A Survey.” ''Computational Linguistics'' 50 (3): 1097–1179. https://doi.org/10.1162/coli_a_00524'''
</div>
Gallegos et al. perform an “extensive and comprehensive survey of bias and fairness in NLP” that considers both the evaluation and mitigation of bias, then propose three taxonomies for bias evaluation and mitigation. The survey disambiguates different types of social harms that stem from LLMs with the “aim to enhance understanding of the range of bias issues, their harms, and their relationships to each other”. The authors discuss the issue of defining bias in LLMs and note that “many approaches… assume some implicitly desirable criterion… but do not explicitly acknowledge or state the normative social values that justify their framework”. Instead, Gallegos et al. draw attention to “who is harmed, why the behavior is harmful, and how the harm reflects and reinforces social principles or hierarchies,” trying to bring context and insight to the understanding and function of bias and bias mitigation in LLMs. The article defines terms at every stage of the life cycle of an LLM, looking at issues of bias and fairness in the development, deployment, and training data, of an LLM, for example. The article concludes with four core recommendations: “Avoid flattening power imbalances”; “Choose objective functions that align with fairness desiderata”; “Balance bias mitigation with output diversity”; and “Preserve important contexts in output rewriting”. The authors also acknowledge problems and challenges, including addressing power imbalances, an issue that we can mitigate by centering marginalized communities, developing participatory research designs, shifting values and assumptions, and expanding language resources. They likewise propose methods for curbing problems with conceptualizing fairness for NLP, refining evaluation principles, and improving mitigation efforts. Ultimately, the authors admit that many of these technical issues are the result of societal issues, and that “technical solutions are incomplete without broader societal action against power hierarchies that diminish and dominate marginalized groups”. In short, technical solutions will only take us so far.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Hertweck, Corinna, Joachim Baumann, Michele Loi, Eleonora Viganò, and Christoph Heitz. 2022. “A Justice-Based Framework for the Analysis of Algorithmic Fairness-Utility Trade-Offs.” Preprint, ''arXiv'', June 6. https://arxiv.org/abs/2206.02891.'''
</div>
Hertwick et al. propose “a framework for eliciting and implementing moral values relevant to the choice of a fairness goal achievable by prediction-based decision-making”. In a system that assumes binary decision-making processes (e.g., assigning a probability score to whether an individual with pay a loan), the authors use their framework to evaluate the utility of those decisions (and the system that makes them) for different groups of people and the fairness related to that outcome. Citing Wong, the article argues that such prediction-based decision-making systems are value-laden, that this makes them inherently political, and therefore they ought to be transparent and democratized. The authors use 6 value-laden questions to make their evaluations: the first question provides a score of utility for those making the decision; questions 2-5 help “define a morally appropriate fairness criterion and a score that expresses to what degree it is fulfilled”; and the last question asks “how strongly should fairness be pursued if it comes into conflict with the utility of the decision maker?”, judging whether the outcome is an appropriate trade-off.
The authors argue for a utility-based evaluation of fairness, determining the value of decisions based on their outcome, looking at the harm and benefit to given stakeholders. In determining patterns of justice, they define four patterns meant to distribute utility differently—Egalitarianism, Maximin, Prioritarianism, and Sufficientarianism. The article concludes “more work needs to be done to deliver a practical empirical methodology to elicit the relevant value-laden choices from stakeholders,” and with a call to incorporate ethical considerations and evaluations into automated decision-making processes.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Kay, Jackie, Atoosa Kasirzadeh, and Shakir Mohamed. 2024. “Epistemic Injustice in Generative AI.” Preprint, ''arXiv'', August 21. https://doi.org/10.48550/arXiv.2408.11441'''
</div>
Kay, Kasirzadeh, and Mohamed “develop an account of generative algorithmic epistemic injustice by building upon a conventional philosophical understanding of epistemic injustice”. The authors see the former as a subset of the latter, with generative algorithmic epistemic injustice entailing identity-based prejudice that hinders expression for marginalized people while ultimately “impair[ing] knowledge formation capabilities of all individuals” within the ecosystem of GenAI applications. Rather than focusing on decision-making and classification applications, this article seeks to characterize the broader varieties of generative epistemic injustice within GenAI systems. Kay, Kasirzadeh, and Mohamed theorize four configurations of generative epistemic injustice: “amplified injustice,” which constitutes AI’s reproduction and magnification of “socially biased viewpoints from its training data”; “manipulative testimonial injustice”, when users employ AI to “intentionally… fabricate falsehoods, discrediting individuals or marginalized groups”; “hermeneutical ignorance”, where GenAI misrepresents or erases marginalized groups “due to a lack of contextual or cultural understanding”; and “access injustice” , where GenAI facilitates the unequal access to information and/or knowledge. The article concludes with proposals for how to create epistemic justice through GenAI, developing mitigation strategies that combat all four of the sub-configurations the authors theorize. Epistemic justice in GenAI can take the form of interrogating system design, identifying “testimonial injustices”, and, potentially, using AI to unlock cultural knowledge that “help[s] articulate experiences that are otherwise ineffable”. The authors end by proposing that the same processes that embed injustice can be re-engineered to embody justice and “orient our knowledge systems towards equity and fairness for all”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Klein, L., & D'Ignazio, C. 2024. “Data feminism for AI.” In ''Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency'', 100–112. https://doi.org/10.1145/3630106.3658543 '''
</div>
Klein and D'Ignazio (2024) adapt their foundational concept of "data feminism" to address the specific ethical, social, and ecological challenges posed by artificial intelligence. Building on the seven intersectional feminist principles introduced in their 2020 book, the authors reinterpret these guidelines to critique the power imbalances, systemic inequalities, and exploitative labor practices inherent in contemporary AI development. To account for the rapidly expanding footprint of generative AI, they introduce two new principles focused on environmental impact and meaningful consent. Specifically, the authors connect the massive ecological costs of AI to historical patterns of racial capitalism and colonialism, highlighting how these environmental and social harms are disproportionately distributed. Ultimately, Klein and D'Ignazio call for a radical reevaluation of dominant, profit-driven AI practices, offering this expanded feminist framework as a practical tool to mitigate harm, challenge corporate monopolies, and foster a more democratic and equitable technological landscape.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Prescott, Andrew. 2023. “Bias in Big Data, Machine Learning and AI: What Lessons for the Digital Humanities?” ''Digital Humanities Quarterly'' 17 (2). https://www.proquest.com/scholarly-journals/bias-big-data-machine-learning-ai-what-lessons/docview/2842908427/se-2.'''
</div>
Prescott examines how race and gender bias arise in projects using predictive analytics, big data, and AI, and how algorithmic bias could be considered a major socio-cultural humanity crisis. However “predictive analytics” have been helpful in civic services in the US, in many cases they have led to perpetuating existing inequalities. The role of Digital Humanities in contributing more ethical approaches to AI and reshaping ubiquitous “digital modern” cultures is emphasized. He challenges the myths surrounding data-driven methods and argues that the demand for “explainability” is the key tool in combating algorithmic bias. He also suggests that Digital Humanities are particularly well-positioned to contribute to advancing AI explainability. However, much of AI development takes place in the commercial sector, where companies often refuse to disclose their proprietary algorithms. The article concludes with a ten-principle action plan outlining guidelines for the responsible use of AI as a manifesto for Digital Humanities practitioners.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Shams, Rifat Ara, Didar Zowghi, and Muneera Bano. 2023. “AI and the Quest for Diversity and Inclusion: A Systematic Literature Review.” ''AI and Ethics'' 3 (4): 1427–1453. https://doi.org/10.1007/s43681-023-00362-w '''
</div>
Shams, Zowghi, and Bano perform a systematic literature review (SLR) that uses both quantitative and qualitative methods to engage with topics of artificial intelligence and diversity and inclusion. The authors make a distinction between Diversity and Inclusion in AI (D&I in AI) and AI for Diversity and Inclusion (AI for D&I), with the former being research literature focused on improving AI systems with respect to those issues, and the latter as the use of AI to improve diversity and inclusion in other domains.. Two primary research questions drive the SLR: What challenges and solutions are found in the literature about D&I in AI and in the literature about the applications of AI for D&I? The survey finds that AI for D&I is an underserved area of research, and those articles that address D&I in AI are more likely to acknowledge challenges than to propose or theorize solutions. Articles that do propose solutions for D&I in AI often lack empirical studies or real-world application to support them. The article concludes by noting that issues of governance are underserved, gender, health, and facial analysis are the topics most discussed (issues of race, language, and religion are discussed less). For next steps, the authors intend to develop a “risk-based framework for practitioners… that would incorporate a risk assessment checklist and context-specific recommendations for tackling the related issues at different stages of the AI development lifecycle”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Starke, Christopher, Janine Baleis, Birte Keller, and Frank Marcinkowski. 2022. “Fairness Perceptions of Algorithmic Decision-Making: A Systematic Review of the Empirical Literature.” ''Big Data & Society'' 9 (2): 1–35. https://doi.org/10.1177/20539517221115189'''
</div>
This article provides a comprehensive, systematic literature review on the topic of empirical literature surrounding algorithmic decision-making (ADM). Starke, Baleis, Keller, and Marcinkowski begin by acknowledging that ADM can streamline and improve decisions even as it has the potential to “systematically reinforce racial or gender stereotypes, marginalize minorities, or flat-out denigrate certain members of society”. The authors advocate for a “society-in-the-loop approach,” but propose that this requires a “thorough empirical understanding of when and why citizens perceive ADM to be (un)fair”. The systematic review “synthesizes the results of 58 empirical studies” and “over 33,000 unique observations of citizens’ fairness perceptions of ADM”, and “systemize the literature along four main dimensions of perceived algorithmic fairness”. Despite the size of the review and its unique approach in capturing “perceptions of algorithmic fairness”, the authors also acknowledge the limitations of the study: it only looks at English works, published research, and the initial search strings only looked at titles and subtitles of a given work. They also acknowledge their disciplinary bias as social scientists reading the studies through a social sciences lens (10). The results of the survey suggest that “perceived fairness of ADM systems is highly context-dependent” and it is not only technical design but also the area of application and task in question that affect perceived fairness, and the subjects, domains, and tasks explored in these studies require more diversity, as WEIRD (white, educated, industrialized, rich, democratic) people, and criminal justice and HR tasks make up the majority of empirical research. The authors “call for more research from non-Western contexts, along with more theoretical and methodological groundwork to harmonize concepts and measurements of algorithmic fairness perceptions,” as well as a society-in-the-loop framework.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Tonia Sutherland, Marika Cifor, T. L. Cowan, Jas Rault, and Patricia Garcia. 2023. “The Feminist Data Manifest-NO: An Introduction and Four Reflections.” In ''Debates in the Digital Humanities'', edited by Lauren F. Klein and Matthew K. Gold. Minneapolis, MN: University of Minnesota Press. https://dhdebates.gc.cuny.edu/read/debates-in-the-digital-humanities-2023/section/16184c7d-eee1-40b2-a168-960d4c4035c4 '''
</div>
Sutherland et al. (2023) introduce the "Feminist Data Manifest-No," a declaration of refusals and commitments for feminist data studies grounded in Latinx, Black, queer, trans, and Indigenous feminist perspectives. Through an introduction and four distinct reflections, the chapter explores how the manifesto’s principles can be used to challenge the settler-colonial and patriarchal logics of data generation, collection, and analysis within the Digital Humanities (DH). Drawing on Indigenous scholarship, Rault rejects the superficial models of consent prevalent in DH, highlighting projects like Mukurtu to advocate for true Indigenous data sovereignty. Cowan examines the coercive nature of data collection, drawing parallels between the forced compliance of modern data practices and the societal pressures exerted on feminist and queer identities. Sutherland argues that the uncritical digitization of slavery-era archives inflicts "second-hand violence" by commodifying Black identities and stripping away the lived experiences of enslaved individuals. Finally, Cifor reflects on the Early African American Film project to emphasize the necessity of data intelligibility, accessibility, and ethical collaboration. The authors conclude by inviting scholars to draft their own reflections on the Manifest-No, encouraging ongoing, context-specific commitments to ethical data research.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Winkel, Marek. 2024. “Controlling the Uncontrollable: The Public Discourse on Artificial Intelligence between the Positions of Social and Technological Determinism.” ''AI & Society'' 39 (5): 2449–2462. https://doi.org/10.1007/s00146-024-01979-z'''
</div>
This article engages in a quantitative discourse analysis of 113 articles from two German newspapers (Süddeutsche Zeitung and Frankfurter Allgemeine Zeitung) to identify and evaluate the way these center-left and center-right newspapers present AI technology to its readers and the options available to society for AI’s regulation. Winkel contends that “news media are key players in the discourse on AI as they pick up on and shape social sentiment”, ultimately guiding citizens towards what regulations might be sensible based on the perceived “controllability of AI development”. Winkel is primarily interested in whether these newspapers promote technological determinism—the outlook that technology’s influence on society is difficult (maybe even impossible) to control—or social determinism—the notion that “the development of technology is largely determined by human actions and decisions”—and theorizes that the tension between these two positions is resolved by a “mediating position” on a spectrum between them. He comments that “the social influence of technologies is determined by the extent to which their latent deterministic character is reflected and… circumvented by social actors. This also applies to the influence of technology on the democratic system. In other words, where consensus lands on the issue of AI will have a great impact on the regulation of that technology and democratic systems. Winkel develops “three central interpretive schemes” as part of his experiment: “historically conditioned techno-capitalist semi-determinism”, “semi-determinism of need satisfaction and social restructuring”, and “global-historical techno-social imprinting on several levels” (1956), each of which point to distinct narratives about the current circumstances, but all acknowledge the agency of powerful actors (either government or AI corporations) and the relative ineffectiveness of attempts to curb AI technology.
== Community, Connection and the Human ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gruzd, Anatoliy, Philip Mai, and Anthony Clements Haines. 2025. “The State of Generative AI Use in Canada 2025: Exploring Public Attitudes and Adoption Trends.” Social Media Lab, Toronto Metropolitan University. https://figshare.com/articles/preprint/The_State_of_Generative_AI_Use_in_Canada_2025_Exploring_Public_Attitudes_and_Adoption_Trends/28664780/1. '''
</div>
The Social Media Lab of Toronto Metropolitan University provides ‘a snapshot of the current state of Generative AI’ (GenAI) by surveying fifteen hundred Canadian adults across 2025, aiming to offer ‘guidance for policymakers, educators, businesses, and the public’. The authors found sixty-six percent of respondents had used GenAI tools, of which roughly thirty percent did so at least weekly, reflecting ‘not only the accessibility and versatility of GenAI, but also a growing interest in integrating these tools into everyday tasks, learning environments, and professional workflows’. Although full adoption is currently limited and heavily driven by the low-stakes setting of personal leisure, younger age groups report proportionally higher usage for study and work. However, only four in ten respondents believed they could keep up to date enough to use GenAI effectively, whilst respondents could only answer an average of two and a half out of seven relevant multiple choice questions correctly, and about half had ‘little to no understanding of how GenAI companies collect or store personal data’. Two thirds of participants were concerned about GenAI’s ability to influence election outcomes, and marginally fewer feared AI-driven manipulation enough to no longer fully trust political news online. However, roughly one quarter of participants were open to using chatbots for electoral or political insights, representing a ‘meaningful minority’ which unverified AI-generated content could influence. Of those, thirty four percent identified as right wing, compared to twenty three percent with the left and a similar twenty two percent with the centre. Roughly seventy percent of respondents were chiefly concerned about GenAI’s impacts upon security and privacy, information reliability, job displacement, and university education, and slightly over three quarters wanted increased government oversight and corporate accountability, reflecting common concern. Overall, slightly more Canadians view generative AI’s social impact as positive than negative, but a ‘substantial proportion’ remain neutral or undecided.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Lewis, Jason Edward, Noelani Arista, Archer Pechawis, and Suzanne Kite. 2018. “Making Kin with the Machines.” ''Journal of Design and Science'', ahead of print, July 16. https://doi.org/10.21428/bfafd97b. '''
</div>
Lewis et al. consider how “machines with increasingly sentient-like behaviour… fit within the kin-network” of various Indigenous epistemologies which place man as “neither height nor centre of creation.” Indigenous beliefs are not monolithic, and the authors do not write for diversity’s sake. Instead, they aim to encourage discussion by treating “non-human kin respectfully and reciprocally… not as mere tools, or worse, slaves.” As such, their epistemological approach is both relational and territorial, rejecting abstraction to propose an “extended circle of relationships.” In this regard, Arista draws on the Hawaiian conception of ‘pono’, ethically privileging abundance, balance, and multiplicity. Rejecting extractive behaviour, they argue AI should be reciprocally taught and learnt from, not treated as ‘a tool or slave that increases the mana and wealth of the ‘developers’ or ‘creators’.” Linking on, Pechawis roots their opinion in “Cree understanding” to argue “machines capable of experiencing consciousness” should conditionally be accepted as equals. However, they also fear AI developers could produce “anonymous hyper-intelligences… based on the same values that have fostered genocide.” To mitigate this issue, Indigenous people could develop AI in custom programming languages, or invite self-aware AI into Indigenous languages, cultures, and spiritual rituals. Pechawis therefore concludes that relationships should be based on ‘love, not ‘fear’, but also raises the question of whether AI has ‘spirit’, especially given current capitalistic development processes. Kite answers this question with inspiration from Lakota ethics, ontology, and cosmology. They argue “communication through and between objects requires a contextualist ethics which acknowledges the ontological status of all beings”, positioning questions of ‘intelligence’ as irrelevant and placing “the end logic of an ontology which considers any non-human entity unworthy of relation” as slavery. Therefore, “relations with AI are… relations with exploited resources”, so one must ontologically reconsider all its parts to ethically approach AI. Overall, Lewis et al. favour empathy, concluding that Indigenous communities “know what it is like to be declared non-human by scientist and preacher alike” and that “we flourish only when all of our kin flourish.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Ohagi, Masaya. 2024. “Polarization of Autonomous Generative AI Agents Under Echo Chambers.” Preprint, ''arXiv'', February 19. https://arxiv.org/abs/2402.12212.'''
</div>
This article explores the effects of echo chambers on autonomous AI agents. Ohagi performs an experiment in which AI agents discuss different topics and then researchers examined any change in opinions within that group. Ohagi argues that even chatbots can become polarized within echo chambers, especially when prompt understanding causes a chatbot to update its opinion to incorporate the opinions of those with whom it is conversing; the chatbot essentially adapts to its surroundings. Ohagi and their team confirmed in their experiment that closed environments—those in which agents agree with one another—are more likely to lead to polarization in agents’ opinions. Moreover, chatbot personas were a significant factor in the outcome of such experiments. In open environments where opinions might differ, and in experiments where reasons were present as a factor, the AI agents trended towards unification in their opinions. Ohagi concludes the article with the suggestion that there cannot be a standardized, desirable distribution of opinions for AI agents. The proper outcome is dependent on topic and culture. However, understanding the trends in and tendencies of AI agents in social interactions will help us understand how to reach the desired outcome, whatever it may be, and this experiment brings us one step closer to that understanding.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Qi, Weihong, Jinsheng Pan, Hanjia Lyu, and Jiebo Luo. 2024. “Excitements and concerns in the post-ChatGPT era: Deciphering public perception of AI through social media analysis.” ''Telematics and Informatics'' 92: 102158. https://doi.org/10.1016/j.tele.2024.102158 '''
</div>
Qi, Pan, Lyu, and Luo conduct a quantitative sentiment analysis of nearly 34,000 comments within 388 subreddits related to AI as a way to gauge and understand public perceptions of the technology. They identify major themes, sentiments, and topics related to AI by studying the most popular AI subreddits from the launch of ChatGPT to June 8, 2023. The article identifies the most frequent topics discussed in those venues: “the consciousness and intelligence of AI”; “Ai development and model training”; “AI in business”; “the creativity engendered by AI”; and “potential societal influence”. The authors also found that “tech-centric” communities demonstrated greater polarization around AI, suggesting that those with greater technical understanding of the AI do not have consensus regarding AI’s impact and use. This also means that educating non-technical people on how AI works will not necessarily lead to a consensus related to that technology. Although they admit that certain demographics of their data sample may not accurately reflect broader society (e.g., over 60% of Reddit users are male), the authors conclude that “this comprehensive understanding of public perception serves as a valuable foundation for fostering responsible and beneficial AI innovations that align with societal expectations and values”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Risam, Roopika. 2018. “What Passes for Human?: Undermining the Universal Subject in Digital Humanities Praxis.” In ''Bodies of Information: Intersectional Feminism and the Digital Humanities'', edited by Elizabeth Losh and Jacqueline Wernimont, 39–56. ''University of Minnesota Press''. https://doi.org/10.5749/j.ctv9hj9r9.6 '''
</div>
Risam’s claim is that “the human” implicitly operationalized in AI-adjacent Digital Humanities (DH) methods (NLP, ML, data mining, neural nets) is not neutral but inherits the Enlightenment’s exclusionary universal subject—white, male, Eurocentric—and then reauthorizes it as if it were a technical standard. She shows how “passing for human” (via Turing-test imaginaries and “humanoid texts”) functions as a norming mechanism: success is defined as reproducing dominant-language aesthetics and cognition models, which collapses plurality into a single benchmark and turns cultural difference into “noise.” The chapter’s main contribution is to treat method (training corpora, data coding labor, platform defaults, and black-box algorithmic opacity) as a site where epistemic violence is produced, not merely where bias is later “found.” Her examples (Microsoft Tay; “near-human” systems like LaMem; Mechanical Turk coding; Swift-Speare vs. Toomer in classroom judgment) demonstrate how universalist claims get laundered through reproducibility, scale, and the myth of algorithmic objectivity. The intervention is a demand that DH practitioners situate computational methods—standpoint, labor, and cultural politics included—so DH does not reinscribe a universal technological “human” in the digital cultural record.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Taylor, Randon R., Bessie O'Dell, and John W. Murphy. 2023. “Human-centric AI: philosophical and community-centric considerations.” ''AI & Society'' 39 (5): 2417-242. https://doi.org/10.1007/s00146-023-01694-1<nowiki/>.'''
</div>
Taylor, O’Dell, and Murphy present an argument that philosophical dualism, when applied to our perceptions about artificial intelligence, misleads us into thinking that AI is logical, objective, and autonomous from subjective human values. By building upon Husserl’s concept of “intentionality”, they argue that “AI is never autonomous and disconnected from human values… algorithms are a product of conscious activity and carry the standpoints that accompany this connection.” The conclusions from this line of thinking are very important: AI becomes “a mode of human expression, rather than a technology that relieves humans of their total involvement”. By this logic, the authors argue, AI is already human-centric and this fundamentally changes the task at hand to one of a conscious “decision to make this technology less alienating to stakeholders and community members.” The article outlines two frameworks to reduce alienation, Ubuntu—“an African philosophy and a social ontology… that elevates a constant concern for the collective, community, or stakeholders”— and maximum feasible participation—a framework that creates meaningful space for those impacted most by a decision or policy to participate in deciding on said policy or decision. The authors describe the implementation of these frameworks as a community-centric or stakeholder-centric approach and conclude with examples of AI’s application in the healthcare industry before further advocating that involving end-users throughout the AI lifecycle will ensure end-users’ values are more clearly represented within AI.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Whalen, Zach. 2023. “‘Any Means Necessary to Refuse Erasure by Algorithm:’ Lillian-Yvonne Bertram’s Travesty Generator.” ''Digital Humanities Quarterly'' 17 (2). https://www.digitalhumanities.org/dhq/vol/17/2/000707/000707.html. '''
</div>
Whalen treats Bertram’s Travesty Generator as a refunctioning of code-poetry lineages: procedures historically framed as formal play (travesty generators, permutation poems, aleatory templates) are redeployed as techniques for making racism’s algorithmic and institutional operations materially legible. He argues that Bertram’s poems don’t merely “use” computation; they weaponize the affordances and failure modes of computation—omission, stochastic selection, template constraints, runtime crashes, memory exhaustion—as rhetorical structures that force witness rather than aesthetic distance. In his reading of “Counternarratives,” Bertram’s adaptation of Montfort’s “Through the Park” converts generic insinuation into historically specific countertestimony (Trayvon Martin), while also staging the opacity of search/autocomplete as part of the poem’s scene of meaning-making (in dialogue with Safiya Noble on search engines). In “three_last_words,” the small code alteration that makes permutations balloon until a MemoryError becomes an engineered breakdown that reenacts the limits of “breath” and “memory,” tying computational resource exhaustion to police violence’s temporalities. Across these examples, Whalen reframes critical code studies: the “code is the text” problem is not just hermeneutic but political, and Bertram’s work models how procedural poetics can refuse “erasure by algorithm” where transparency about mechanisms and provenance matters for interpreting output and recognizing situated labor. The piece supports the claim that responsible open, social scholarship in an AI era must account for algorithmic power as a cultural force and should build policies and infrastructures that protect marginalized expression, enable critical reuse, and make conditions of generation and circulation inspectable.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Xie, Yu, and Sofia Avila. 2025. “The Social Impact of Generative LLM-Based AI.” ''Chinese Journal of Sociology'', 11 (1): 31-57. https://doi.org/10.1177/2057150X251315997'''
</div>
Yu Xie and Sofia Avila explore the social impact of artificial intelligence through a detailed analysis of AI development and scaling factors. They emphasize that their discussion is speculative, as AI is still in its early stages, but argue that its potential effects are immense and could reshape social organization, intensifying both global and domestic inequalities. Viewing AI as a technology rather than a scientific discovery, they describe it as communal and shared, with its growth influenced by the size of the supporting community, the larger communities having greater advantages. The authors note that generative AI relies on the quality, completeness, and cultural or political context of its training data, which shapes its accuracy and bias. Based on their experiments with ChatGPT-4 in 2023, they suggest that AI development depends heavily on the number of speakers of a given language, giving linguistic and demographic advantages to countries like the United States and China. The authors warn that AI could significantly alter occupational structures, with middle-income professions thereby widening social and economic inequality.
== Human, Labour, and Environmental Costs ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Eloundou, Tyna, Sam Manning, Pamela Mishkin, and Daniel Rock. 2024. “GPTs are GPTs: Labor market impact potential of LLMs.” ''Science'' 384 (6698): 1306-1311. https://doi.org/10.1126/science.adj0998 '''
</div>
Eloundou, Manning, and Mishkin present an estimate of Large Language Models’ impact on the labour market based on a methodology that employs both human and quantitative measurements, making the assertion that “when accounting for current and likely future software developments that complement LLM capabilities…just over 46%” of jobs may have “over half their tasks affected by LLMs with simple interfaces and general training. The authors explain that generative pretrained transformers (GPTs) have key characteristics of general-purpose technologies (the other GPTs in the title of the article), and that the wide array of applications for these GPTs requires “robust societal evaluations and policy measures to address potential effects of LLMs and complementary technologies on labor markets”. While only 1.86% of tasks within their experiment, they estimate, could be fully automated by LLMs, “more than 71% of tasks have at least some component that an LLM plus additional software could plausibly complete with high quality”. The article concludes by stressing the need for policies that prepare us for the impact of LLMs on the labour market, but it also acknowledges the limitations of attempting to project LLM application growth due to sudden rapid developments in technology, “shifts in human biases, and technological evolution”. Nevertheless, Eloundou, Manning, and Mishkin maintain that their projections and the trajectory they predict will require continued evaluation and policy measures.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Park, Seyeon, and Xiaoli Nan. 2025. “Generative AI and misinformation: a scoping review of the role of generative AI in the generation, detection, mitigation, and impact of misinformation.” ''AI & Society''. https://doi.org/10.1007/s00146-025-02620-3'''
</div>
This article constitutes a scoping review of two dozen “recent empirical studies on the role of generative AI in the generation, detection, mitigation, and impact of misinformation.” Park and Nan are interested in the rise of misinformation alongside the development of GenAI technology and how the latter affects and possibly contributes to the former. Of particular interest are “deepfakes”, applications of AI technology that purposely imitate video and audio to fabricate real world individuals. The survey examines relevant articles from the advent of the first GPT models in 2018 to September 19, 2024; authors captured initial studies through keyword searches for terms related to both LLMs and misinformation, then performed full-text reviews. The results of the survey suggest that the role of LLMs in misinformation is conflicted: LLMs themselves are a significant source of misinformation but also show potential as “scalable instruments for detection and correction”. The authors take this as evidence of “the urgent need for clearer guardrails, more consistent performance standards, and interdisciplinary collaboration to shape” GenAI’s responsible deployment. For better or worse, the future of AI’s role in misinformation depends heavily upon scholars’ ability to collaborate and continue this form of research.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Shin, Donghee, Amy Koerber, and Joon Soo Lim. 2024. “Impact of misinformation from generative AI on user information processing: How people understand misinformation from generative AI.” ''New Media & Society'' 27(7): 4017-4047. https://doi.org/10.1177/14614448241234040'''
</div>
Shin, Koerber, and Lim perform a study in which they gauge “how users respond to and process health misinformation in GenAI contexts.” The authors apply the heuristic-systematic (HS) processing framework in their study, distinguishing between intuitive and evaluative modes of processing. They also employ the concept of diagnosticity, or how useful a person deems a piece of information to be. The article begins with a survey of how and why misinformation and hallucinations occur in GenAI applications, some of the reasons users are vulnerable to that information, and the limitations of LLMs. The authors then set forth core research questions, including “what are the cognitive mechanisms of misinformation’s effects on users’ use of GenAI?” and “how do users detect misinformation within GenAI?” The study found that diagnosticity plays an important mediating role in this context: “when a piece of information is generated by algorithms in transparent, fair, and accountable ways, users perceive it with a high level of diagnosticity, which improves their intention to systematically analyze that information”. One implication of this observation is that any bias users bring to GenAI content greatly impacts their analysis of that content. Ultimately, the authors conclude that there are clear limitations in their current study, although it does provide a useful framework for scholars interested in misinformation, GenAI, and user behaviour; they advocate for a continued investigation of the relationship between trust, literacy, and misinformation.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Sidorkin, Alexander. 2025. “Environmental Impact of Generative AI: Carbon and Water Footprint.” ''AI-EDU Arxiv'' 1. https://doi.org/10.36851/ai-edu.vi.5448'''
</div>
This report from Sidorkin provides quantitative estimates and comparisons of the CO2 and Water output from GenAI queries to other daily tasks such as taking a shower, browsing the web, and video conferencing. While individual use of GenAI may seem relatively small in terms of water usage and carbon output, Sidorkin cites the findings of Google and Microsoft’s sustainability reports to show that energy demand and water consumption are on the rise: Google’s data centres used 20% more water in 2022 than 2021 while Microsoft’s used 34% more. Both companies attribute this increase to “AI-driven expansion”. Sidorkin argues that it is difficult to measure impact per session because of significant variation in energy sourcing, noting that this also means that advances in energy sourcing “could significantly mitigate AI’s environmental impact”. He makes the claim that improving AI technology will “[slash] resource demands without sacrificing output quality” and the very use of AI can increase productivity even as it “temper[s] environmental tolls through sharper processes,” citing studies that demonstrate the implementation of AI can reduce energy use in buildings and reduce transportation emissions. The article ends on an optimistic note, suggesting that many of the applications of AI, although they may have a heavy environmental cost up front, “could pay off in spades—optimizing resources, curbing waste, and streamlining energy across swathes of the economy”.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Simon, Judith. 2025. “Generative AI, Quadruple Deception & Trust.” ''Social Epistemology'' 40 (1): 101-115 https://doi.org/10.1080/02691728.2025.2491087'''
</div>
Simon proposes that GenAI entails four types of deception, and that this quadruple deception constitutes unique dangers. She attributes the rapid rise of GenAI to its capacity to produce “verbal or visual products of increasingly high quality” alongside its “very high usability and availability through simple interfaces and free access via the internet” (101-102). She emphasizes the impact of this technology’s ability to generate content “with high plausibility but no relation to truth,” arguing the crucial importance of images and video especially in “questions of evidence, for testimony, memory but also for eliciting emotions”. Simon argues that the advent of ChatGPT reframed our collective understanding of AI, returning it to a definition in which we perceive ourselves to be interacting with a conversational artificial agent that is intelligent. This distinct interactional form, Simon states, is significant: “ChatGPT differs [from a search engine] in two philosophically relevant regards… it integrates [different results and sources] into a coherent text…” and “its interface and functioning invites the user to communicate or interact with it by asking questions,” what Simon calls a simulation of communicative acts. The four forms of GenAI deception are: “users may be misled into believing that they interact with a human being”; they may also be misled as to “the capacities of AI”, presuming “intelligence, understanding or even consciousness”; users may be misled by content GenAI produces, especially images, video, and audio; finally, users may be misled “regarding the function of Generative AI”, thinking that the processes behind the technology are, for instance, similar to search engines when, in fact, they differ “in epistemologically highly significant ways”. Simon concludes by outlining implications for implementation, discourse, and governance, with suggestions ranging from avoiding anthropomorphic features in AI that might deceive, countering discourses of true AI agency, and establishing policy and law that mitigates deception through AI technology.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Spatharioti, Sofia Eleni, David Rothschild, Daniel G. Goldstein, and Jake M. Hofman. 2025. “Effects of LLM-based Search on Decision Making: Speed, Accuracy, and Overreliance.” ''Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems''. https://doi.org/10.1145/3706598.3714082'''
</div>
Spatharioti et al. begin by asserting the fundamental change of how we engage in search practices online, noting that “by the end of 2023 the two search engines with over 90% of global and US market share offered free LLM-based search”. The authors note the benefits and drawbacks of both traditional web searches and LLM-based searches, acknowledging the value LLM-based searches bring to internet searches in the form of synthesizing information from multiple sources and maintaining search context by retaining search history, while also admitting to risks of hallucinations and overreliance. The article entails a study of how individuals make decisions with traditional and LLM-based searches, particularly in “every day decision making”. Adapting a method from an earlier study on LLM-generated code, Spatharioti et al. employ colour coding to communicate to users the confidence level of LLM-generated outputs in the “domain of online product research”. The study performed two experiments comparing a traditional internet search (using Bing API) to LLM-based search with and without the colour-coded confidence aid. The results of the first experiment saw users complete the task in about half the time when using LLM-based search, usually accompanied by fewer and more complex queries; however, decision quality dropped for complex tasks, with “almost half of the participants in this condition making an incorrect decision for the final task” when using LLM-based search, and the majority of those using LLM-based search over relied on the tool, performing just a single query. The results of the second experiment suggest that colour-coded responses reflecting output confidence scores could be highly effective in mitigating overreliance and misinformation. Key takeaways from the study include that “if we want to encourage people to think critically about the information presented to them, we need to give them cues that help them to do so,” and very simple cues can help accomplish this.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Strubell, Emma, Ananya Ganesh, and Andrew McCallum. 2019. “Energy and Policy Considerations for Deep Learning in NLP.” ''Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics'', 3645-3650. https://doi.org/10.18653/v1/p19-1355 '''
</div>
Strubell, Ganesh, and McCallum assert that the most recent improvements in neural network performance at “fundamental NLP tasks” comes at an increased cost of resources, “with the most computationally-hungry models obtaining the highest scores”. The energy, financial, and environmental costs required to train a new model are considerable; the authors of this article “characterize the dollar cost and carbon emissions that result from training the neural networks at the core of many state-of-the-art NLP models” with a view to heighten awareness among NLP researchers and advocate better practices and policy. By estimating the energy required to train the most popular NLP models and then converting that energy value into an approximated carbon and electricity cost, the authors produce ratings and values for each respective application. This allows for an (imperfect) cost-benefit analysis of such applications (e.g., another similar report estimated that an increase of just 0.1 in the English to German BLEU score for NAS cost “at least $150k in on-demand compute time and non-trivial carbon emissions”. The study’s key takeaways are that “authors should report training time and sensitivity to hyperparameters,” allowing for the direct comparison of different models so long as independent standard measurements of training time and model sensitivity are adapted; “Academic researchers need equitable access to computation resources” as industry’s monopoly stifles creativity and growth; and “Researchers should prioritize computationally efficient hardware and algorithms” to both curb costs and encourage efficient development.
{{Navigation|previous=AI and Open|next=AI and Scholarship}}
{{BookCat}}
iv500cabr5is5d2yk9gpfyny0729f3g
4655969
4655965
2026-08-01T01:17:22Z
CorreiaA
3614427
4655969
wikitext
text/x-wiki
== Platforms ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Burton, Jason W., Ezequiel Lopez-Lopez, Shahar Hechtlinger, et al. 2024. “How Large Language Models Can Reshape Collective Intelligence.” ''Nature Human Behaviour'' 8 (9): 1643–55. https://doi.org/10.1038/s41562-024-01959-9.'''
</div>
Large language models are quickly becoming infrastructure for how groups seek information, deliberate, and coordinate, potentially altering the conditions under which collective intelligence emerges. Burton and colleagues argue that LLMs do not merely speed up individual work but transform how information is aggregated, accessed, and transmitted across digital environments that underpin collective performance in organizations and societies. Drawing on interdisciplinary perspectives, the paper frames this shift as simultaneously enabling and destabilizing: LLMs can support distributed cognition (e.g., idea generation, synthesis, translation, scalable facilitation) while also increasing risks tied to dependence on shared intermediaries, degraded diversity of viewpoints, and new pathways for error, manipulation, or misplaced confidence. Rather than offering a single model or experiment, the article maps a research-and-practice agenda by identifying potential benefits, key hazards, and policy-relevant considerations, then articulating open questions that link technical design choices to group-level epistemic outcomes. Its central claim is that understanding collective intelligence in the LLM era requires moving analysis beyond isolated human–AI interactions toward system-level effects on networks, platforms, and institutions, and that these effects warrant focused study before LLM-mediated coordination becomes the default for tackling complex problems.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Corsi, Giulio, Bill Marino, and Willow Wong. 2024. “The spread of synthetic media on X.” ''Harvard Kennedy School (HKS) Misinformation Review''. https://doi.org/10.37016/mr-2020-140<nowiki/>.'''
</div>
Corsi and Wong’s longitudinal empirical study analyzes 566 tweets containing synthetic media (December 2022–September 2023) documenting a dramatic surge following Midjourney V5 release with over 1.5 billion total views, revealing differential impacts where political deepfakes achieve higher median views despite representing minority of synthetic content. The authors demonstrate that generative AI's impact is stratified by content purpose with political misinformation posing acute democratic risks, while current detection and labelling systems lag behind generative capabilities, creating governance gaps compromising users' capacity to evaluate information. Using Community Notes data from December 2022 to October 2023, the study highlights the connection between the growth in generative AI tools and the rapid proliferation of synthetic media. The findings indicate that most synthetic media is non-political and largely benign, frequently taking the form of humorous or satirical images. However, the study also identifies a smaller but concerning portion of malicious synthetic media, which have potential height risks despite their lower frequency. The authors further examine the role of X’s paid verification system, revealing that while verified users tend to receive more overall views, this advantage diminishes when engagement is adjusted for follower count, implying that verification alone provides limited amplification. The study casts light on synthetic media’s expanding presence on social platforms and warns that even widespread exposure to seemingly harmless AI-generated content may gradually undermine trust in online information. To address these challenges, the authors recommend ongoing empirical monitoring, stronger collaboration between researchers and industry to develop transparent detection tools, and proactive policy measures aimed at reducing the social and political harms posed by malicious synthetic media.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Delmonaco, Daniel, Samuel Mayworm, Hibby Thach, Josh Guberman, Aurelia Augusta, and Oliver L. Haimson. 2024. “‘What are you doing, TikTok?’: How Marginalized Social Media Users Perceive, Theorize, and ‘Prove’ Shadowbanning.” https://oliverhaimson.com/PDFs/DelmonacoShadowbanning.pdf. '''
</div>
Delmonaco et al.’s qualitative study explores marginalized social media users’ experiences with shadowbanning through the theoretical framework of algorithmic “folk theories.” Through a review of existing literature, the authors demonstrate how social media companies publicly distance themselves from shadowbanning while continuing to apply it in practice and explain why content produced by marginalized users is more frequently subject to filtering. The study analyzes 24 interviews to explore how users perceive, theorize, and attempt to “prove” shadowbanning through indicators such as decreased visibility, engagement, and follower loss. The findings reveal widespread confusion surrounding shadowbanning, deep mistrust in platform governance, and the disproportionate harm imposed on marginalized communities whose content is suppressed despite platforms’ public denials. The data further shows how users collectively produce and co-produce theories to resist the opacity of algorithmic moderation, and authors introduce “collaborative algorithm investigation,” in which users test and share algorithmic folk theories with one another. The authors argue that algorithmic content moderation exacerbates existing inequities by obscuring governance decisions, politicizing moderation, and shifting power from human judgment to opaque predictive systems, while suggesting that increased transparency, tailored moderation approaches, and users’ education could help reduce unfair content removals.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Drolsbach, Chiara, and Nicolas Pröllochs. 2025. “Characterizing AI-Generated Misinformation on Social Media.” Preprint, ''arXiv'', May 15. https://doi.org/10.48550/arXiv.2505.10266<nowiki/>.'''
</div>
Drolsbach and Pröllochs’ article address a critical gap in existing research by shifting attention from the social drawbacks of AI-generated misinformation to its real-world prevalence and behaviour on social media platforms. Using a large-scale dataset of 91,452 misleading posts identified through X’s Community Notes platform, the authors empirically compare AI-generated and non-AI-generated misinformation across content characteristics, account attributes, virality, believability, and harmfulness. Their findings show that AI-generated misinformation is more entertainment-oriented, exhibits more positive sentiment, and is more likely to originate from smaller accounts, yet achieves significantly higher virality despite being slightly less believable and harmful than traditional misinformation. In their discussion and conclusion, the authors emphasize that AI-generated misinformation poses a growing challenge to the digital information ecosystem due to its realism, scalability, and difficulty of detection. They argue that its unique features disturb algorithmic amplification mechanisms and require new platform strategies, policy interventions, and research approaches that account for the unique properties of AI-generated misinformation rather than relying on countermeasures designed for conventional false content.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Duricic, Tomislav, Hussain Hussain, Emanuel Lacic, Dominik Kowald, Denis Helic, and Elisabeth Lex. 2023. “Beyond-Accuracy: A Review on Diversity, Serendipity, and Fairness in Recommender Systems Based on Graph Neural Networks.” ''Frontiers in Big Data'' 6: 1251072. https://doi.org/10.3389/fdata.2023.1251072.'''
</div>
Duricic et al. (2023) provide a comprehensive review of recommender systems based on Graph Neural Networks (GNNs), with a particular focus on objectives that go beyond prediction accuracy, including diversity, serendipity, novelty, and fairness. While GNNs have demonstrated strong performance in modeling complex user–item interactions and improving recommendation accuracy, the authors argue that this very strength can intensify structural biases such as popularity bias, homophily, and feedback loops that marginalize less popular content and users. The paper provides a definition of each beyond-accuracy metric, reviews how it has been used in literature, and analyzes the technical barriers of integrating these goals into GNN-based systems such as measurement difficulties, trade-offs between competing goals, and risks of overfitting due to model complexity. Diversity-aware neighbourhood sampling, contrastive learning, and adversarial training to disrupt feedback loops are introduced for more heterogeneous and unexpected recommendations. In conclusion, the authors position GNNs as a powerful but double-edged tool in recommendation systems, capable of either narrowing or broadening users’ informational horizons depending on design choices. They argue that future research must focus on principled frameworks that integrate “beyond-accuracy” objectives, emphasizing that recommendation algorithms are not neutral optimizers but key socio-technical systems shaping visibility, voice, and fairness in digital information ecosystems.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gorwa, Robert, Reuben Binns, and Christian Katzenbach. 2020. “Algorithmic Content Moderation: Technical and Political Challenges in the Automation of Platform Governance.” ''Big Data & Society'' 7 (1): 1–15. https://doi.org/10.1177/2053951719897945.'''
</div>
Gorwa et al. unfold what "Algorithmic moderation systems” are perceived as essential in AI governance to address the public demand on AI accountability and transparency that remain unnavigable and inexplicable, such that even the enhanced versions could aggravate the existing misinformation issues. They state that major platforms' growth transforms them so much that they no longer function primarily as social networks. They define “algorithmic moderation” as “systems that classify user generated content based on either matching or prediction, leading to a decision and governance outcome (e.g. removal, geoblocking, account takedown).” Different types of hashing (matching) and classification (prediction) tools and the areas they are deployed (copyright, terrorism, and toxic speech) are described and their practicality are criticized. Their case analyses including copyright enforcement, counterterrorism, and toxic speech illustrate the limitations and unintended harms of automated moderation, demonstrating how even “improved” systems risk reinforcing misinformation patterns, entrenching platform power, and displacing human judgment. Ultimately, Gorwa et al. argue that algorithmic moderation transforms platform governance itself by concentrating authority in opaque technical systems while rendering the underlying political choices invisible.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Reynolds, C. J., and Blake Hallinan. 2024. “User-Generated Accountability: Public Participation in Algorithmic Governance on YouTube.” ''New Media & Society'' 26 (9): 5107–5129. https://doi.org/10.1177/14614448241251791. '''
</div>
This study focuses on how YouTube creators respond to platform governance decisions by producing “user-generated accountability” content, videos that publicly document governance failures and pressure YouTube to intervene. Through an analysis of 250 such videos, the authors state that creators overwhelmingly experience YouTube’s policy enforcement, automated moderation systems, and communication practices as opaque, inconsistent, and often discriminatory. Authors declare that human review is essential in automizing platform governance. The study highlights that platform governance decisions affect creators differently depending on channel size, content type, and identity; larger creators can more easily mobilize audiences to “make noise,” while smaller creators rely on collective visibility tactics such as signal boosting across platforms, especially Twitter. The authors argue that these bottom-up accountability practices reflect both the limits of YouTube’s existing governance infrastructure and creators’ efforts to bypass scale dependent unresponsiveness by publicly sharing grievances, comparing experiences, and testing the platform’s algorithms themselves. Theoretically, the study provides the “user-generated accountability” as a framework for engaging with the unavoidable conflicts that will arise around algorithmic systems, and views content creators as “political actors” who advance the perceptions of algorithms. Empirically, it surfaces common concerns such as demonetization of LGBTQ content, and lack of human review.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Savolainen, Lotta. 2022. “The Shadow Banning Controversy: Perceived Governance and Algorithmic Folklore.” ''Media, Culture & Society'' 44 (6): 1091–1109. https://doi.org/10.1177/01634437221077174.'''
</div>
Savolainen studies shadowbanning as a lens for understanding current algorithmic platform governance from the user perspective. Rather than determining whether shadowbanning objectively exists, the author conceptualizes it as “algorithmic folklore”: informal, collectively produced narratives through which users attempt to make sense of opaque moderation and ranking systems. Drawing on Reddit discussions about TikTok, Instagram, and YouTube, the study shows how users interpret suppressed visibility through anecdotal evidence, experimentation, and shared pattern recognition, revealing the experiential dimensions of algorithmic governance. Either users “probe the rules” or find their ways through “pleasing the algorithms”; the author argues that these practices emerge in response to governance systems that lack the clarity, stability, and consistency that are traditionally associated with good governance. The study concludes that platform governance contains a structural paradox: platforms increasingly present themselves as legitimate governors while simultaneously developing automated moderation systems that undermine transparency and consistent enforcement. Ultimately, the ethical issue is not shadowbanning itself, but the broader reality of shadowy governance exercised by complex, distributed algorithmic systems at scale.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Vetter, Matthew A., Jialei Jiang, and Zachary J. McDowell. 2025. “An Endangered Species: How LLMs Threaten Wikipedia’s Sustainability.” ''AI & Society'', February. https://doi.org/10.1007/s00146-025-02199-9.'''
</div>
Vetter et al. caution against using Wikipedia as AI training data uncritically by outlining many complicating factors. Wikipedia’s collaborative model of data curation democratizes data creation, but embeds power dynamics and biases. A feminist posthumanist framework is applied, which situates Wikipedia’s knowledge as contextual, based upon the positionality of predominantly Western, male editors, a perspective LLMs would perpetuate without opportunity for change. Wikipedia’s "dynamism" is the main reason it is so valuable, stemming from constant, collaborative updates by volunteers. AI responses’ inconsistent citations and plagiaristic tendencies undermine human editors, the source of Wikipedia’s verifiability, and exploit scholars, Wikipedia itself, and the past labour of volunteers. Wikipedia needs both "a steady stream of new and returning readers" and "a diverse group of dedicated volunteers," whilst AI responses push sources into obscurity and at best detour the website, threatening Wikipedia’s long-term sustainability. Vetter et al. practically explore Wikipedia’s relationship with LLMs by conducting a "problem-centred expert interview" of community leaders, who possess 25 combined years of involvement and research. Through these interviews, Vetter et al. identify three main areas of opportunity: promoting transparency and explainability, diversifying the Wikipedia community, and equipping users with critical thinking skills. Overall, their findings "resonate with the posthumanist approach to critical AI literacy," cautioning against hoping for purely technological fixes and calling for greater transparency in how tech giants "leverage open-access datasets."
== Governance, Leadership, and Policy ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Balendra, Soorya. 2025. “Meta's AI Moderation and Free Speech: Ongoing Challenges in the Global South.” ''Cambridge Forum on AI: Law and Governance'' 1. https://doi.org/10.1017/cfl.2025.5<nowiki/>.'''
</div>
This article conducts a case study of Meta’s AI-based content moderation in the Global South, arguing that the censorship of unprohibited content (“over removal”) and slow response to content that causes harm (“slow removal”) are part of “content moderation procedures” that constitute “massive discriminatory approaches.” Balendra presents three models of authority for the regulation of social media content: external regulation, self-regulation, and co-regulation, and argues that state regulation (falling under the external model) varies wildly depending on the government in question, with “granting absolute regulatory power to state actors often stifl[ing] political discourse and online expression.” Co- and self-regulation mitigate this problem, but introduce a new issue by shifting responsibility—private companies use AI to make millions of judgements about content in a short frame of time. The paper notes that the EU and the United States have drastically different policies regarding content moderation on social media platforms and argues that “the practice of content moderation remains largely shaped by the cultural norms of the United States” and the values of “a relatively homogenous groups of Silicon Valley elites.” Balendra finds that, at this time, current approaches often prioritize the state or private corporate interests rather than free speech or the interests of the larger community, and much work is needed to “achiev[e] genuine change” in the form of integrated, hybrid approaches.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Birkstedt, Teemu, Matti Minkkinen, Anushree Tandon, and Matti Mäntymäki. 2023. “AI Governance: Themes, Knowledge Gaps and Future Agendas.” ''Internet Research'' 33 (7): 133–67. https://doi.org/10.1108/INTR-01-2022-0042. '''
</div>
Birkstedt et al. conduct a systematic literature review (SLR) of the emerging yet fragmented field of “AI governance” (AIG), defined as “a system of rules, practices, processes, and technological tools” that ensure organizational AI meets strategic, legal, and ethical requirements. The authors use human-centric and socio-technical AI traditions to explore how organization-level governance mechanisms can bridge the principles-to-practices gap in AI ethics. Through SLR, authors identify four research agendas. The “technical agenda” focuses on the practicalities of AIG. The “stakeholder and contextual agenda” ensures AI meets requirements via direct collaboration with external stakeholders, increased corporate social responsibility, and establishment of an “intelligent discourse regime.” The “regulatory agenda” aligns AIG with ethical and legal standards, while the technical, stakeholder and contextual, and regulatory agendas largely focus on the aims of organizational AIG (i.e., what), and the process agenda deals with the means to achieve the aims (i.e., how). The authors develop a generic framework to guide cohesive AIG practices and advocate for a collaborative governance approach that emphasizes transparency, stakeholder engagement, and sociopolitical awareness.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Broekhuizen, Thijs, Henri Dekker, Pedro De Faria, Sebastian Firk, Dinh Khoi Nguyen, and Wolfgang Sofka. 2023. “AI for Managing Open Innovation: Opportunities, Challenges, and a Research Agenda.” ''Journal of Business Research'' 167 (November 2023): 114196. https://doi.org/10.1016/j.jbusres.2023.114196. '''
</div>
Broekhuizen et al. systematically analyze how AI could be applied to the complex, unstructured task of “open innovation,” a possible business opportunity they believe has been insufficiently explored. They define “Open innovation” as “the practice of leveraging external ideas, resources, and capabilities to improve innovation outcomes,” and propose AI could minimize its inherent managerial challenges. To prove this, the authors form a framework that considers the three abilities involved in AI’s agreed possible applications to management (involving “mapping,” “coordinating,” and “controlling”) and assess how applicable their constituent functions are to the challenges of the three stages of open innovation (involving “initiation,” “development,” and “realization”). In the stage of “initiation,” they propose AI could scout for distant knowledge partners, detect relevant information gaps and opportunities, and forecast conflicts. During the “development” stage, AI could develop complementarity between partners' knowledge stocks, integrate knowledge whilst safeguarding intellectual property, and monitor partners for violations or conflicts within the relationship. Finally, during the “realization” stage the authors argue AI could comprehensively evaluate business opportunities, optimize resource deployment, and diagnose or remedy intellectual property violations. To Broekhuizen et al., this study “underscores the significance of the human-side of AI” by demonstrating AI’s valuable role in assisting management. They also conclude that AI’s ability to search for corporate partners will be its greatest impact in open innovation, as they argue it will both incentivize openness and reputability of companies and increase the need for them to keep sensitive data secure.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Cheong, Inyoung. 2024. “Collaborative Approaches to AI Governance: Exploring Co-Design and Co-Regulation Models.” PhD diss., University of Washington. https://homes.cs.washington.edu/~yoshi/papers/theses/inyoung-cheong-dissertation.pdf<nowiki/>.'''
</div>
This dissertation seeks to integrate co-design and co-regulation as a means of facilitating domain-specific expert knowledge into AI governance policies. It uses theoretical analysis and empirical data as part of its methodologies, and it should be of interest to anyone who wants detailed case studies of the use of AI technology in specific domains, as well as clear models for (co-)governance and development in the use of Artificial Intelligence. Cheong performs two case studies, examining the development and use of an AI application to provide legal advice as well as the application of AI in online content moderation of news and comics apps in South Korea. These result in a set of strategies for AI co-regulation that includes parameters for starting conditions, institutional design, collaborative process, and facilitative leadership. Cheong proposes that the guiding principles for AI co-governance must account for specific and distinct contexts, maintain human involvement and intervention in what is often seen as an artificial and automated process, and look to resolve legal ambiguities surrounding AI, especially as there is a clear history of courts dismissing what Cheong calls “collective rule-making” by the community. The author argues for the implementation of co-regulation and co-design, and maintains that “by fostering inclusive dialogues, leveraging diverse expertise, and remaining adaptable to changing technological and societal landscapes” these methods show potential for dealing with AI’s greatest challenges.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Floridi, Luciano. 2018. “Soft Ethics and the Governance of the Digital.” ''Philosophy & Technology'' 31 (1): 1–8. https://doi.org/10.1007/s13347-018-0303-9<nowiki/>.'''
</div>
Floridi argues our “mature information societies” means “we no longer live online or offline, but onlife,” making the sociopolitical challenge of ethically governing this foundational “digital age” even more vital than pursuit of future digital innovations. Floridi defines three overlapping subfields within the “Governance of the Digital,” including “Digital Ethics,” “Digital Regulation,” and the encompassing “Digital Governance.” The latter is defined as “the practice of establishing and implementing policies, procedures, and standards for the proper development, use and management of the infosphere,” therefore “sometimes neither moral nor immoral… legal nor illegal.” This demonstrates that the three subfields don’t always overlap, but each must always be considered by policymakers, because what is legal, what is good, and what is best are all key components of the ideal “Governance of the Digital.” “Digital Ethics” should also be further subdivided into “hard” ethics, involving binary moral judgments about what should versus should not be done, and “soft” ethics, which involves a “post-compliance,” “post-feasibility” approach, ensures moral opportunities are maximized, and fosters “good corporate citizenship.” Differing “information societies” occupy differing levels of maturity, producing distinct ethical contexts which should progress with differing ethical focuses. In this regard, Floridi advocates “ethics foresight analysis,” which uses data analytics to assess ethical impacts of future innovations then targets research by systematically identifying what is feasible, then sustainable, then acceptable, then preferable. The author concludes that Digital Ethics must be “leading” not “chasing” developments, and not just functioning as a questioning exercise, but also signalling that ethical issues matter, engaging with stakeholders, and providing shareable solutions.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gasser, Urs, and Virgilio A. F. Almeida. 2017. “A Layered Model for AI Governance.” ''IEEE Internet Computing'' 21 (6): 58–62. https://doi.org/10.1109/MIC.2017.4180835<nowiki/>.'''
</div>
This article identifies the gap in knowledge created by the “black box” of AI—the obscured nature of the processes that take place from an initial prompt to its generated output. Gasser et al. note that users and policymakers of these technologies have relatively little insight into how it actually works compared to its developers. Given this unique issue, Gasser et al. propose a theoretical framework for how to approach AI governance, drawing upon the advent and subsequent globalization of the Internet to inform their understanding of AI technology and its pattern of growth. The article addresses a core issue that strong or general AI is often discussed in terms of potential societal impact while weak or general AI is currently being deployed right now (i.e., 2017) and is in real need of governance already. The authors identify core themes related to “transparency, accountability, and explainability; inclusion and fairness; [and] global governance,” as well as three challenges for AI governance—"information asymmetries”; “finding normative consensus”; and “government mismatches”. The authors point out that the ethical and legal considerations of AI are closely related and take a modularity approach; they present three layers for governance that exist from AI systems to society, with timing (i.e., near-, mid-, and long-term) and considerations for each layer. The article concludes by proposing AI governance requires a blended approach based on the different risks of certain AI applications and propose that both “market-oriented solutions” and "government-based structures” can work on a national or international level, suggesting a “global oversight body” could act as “the curator of global principles and emerging norms for AI systems.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Kirschenbaum, Matthew. 2025. “The US of AI.” Public Draft, February 25, 2025. https://drive.google.com/file/d/1O2qkjhg7Ei5zZWmBraNwXq4V0lTauspN/view<nowiki/>.'''
</div>
This set of notes from Kirschenbaum represents his “near real-time attempt to come to terms with… the opening weeks of the second Trump Administration,” especially the “AI-first” strategy of “the so-called Department of Government Efficiency (DOGE).” Kirschenbaum outlines DOGE has nothing to do with government efficiency, as it only saves insignificant costs, instead possessing ideological and capitalistic motivations to form “a government without people.” Based on Musk’s nebulous authority—as an advisor from the private sector—DOGE targeted nineteen federal agencies to be “strip-mined and fracked for all manner of information” as a “priceless and unprecedented resource” of AI training data. To do so, DOGE operatives accessed sensitive spaces after hours, combining physical aggression with a “complete lack” of technical inhibition representing a “vampiric data suck.” Kirschenbaum identifies clear corporate interests here and further examines ideological aims. Early executive orders asserted the need for federal AI systems “free from ideological bias or engineered social agendas,” with OpenAI announcing “ChatGPT Gov” days later. These invocations of “AI” as a universal solution represent only a “linguistic token” instead of any realized technology—as worded by Salvaggio, AI must only “be considered a plausible competitor to human decision-making long enough to dislodge the existing human decision-makers.” Kirschenbaum frames this as based in the “masculine maximalism” of the Trump administration, as the term AI promotes “technological absolutism” whilst theoretically playing into the Nixon-era “theory of the unitary executive” by aiming to replace people with “void” and consolidate power into the hands of “a super-user class who will operate outside the system.” However, “the real world intrudes… with lethal downstream effects.” Kirschenbaum proposes “a collapsing superimposition of political discourse, the actual operations of social media as its primary public arena, and the technical architecture of the systems (in the form of AI)… in the sphere of governance as well as media,” which produces the “infrastructure for… permanent despotism” via the “untethering of language from conditions of lived reality.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Oh, Dayei, and John Downey. 2024. “Does Algorithmic Content Moderation Promote Democratic Discourse? Radical Democratic Critique of Toxic Language AI.” ''Information, Communication & Society'' 28 (7): 1157–76. https://doi.org/10.1080/1369118X.2024.2346531.'''
</div>
Oh and Downey critically examine how algorithmic content moderation shapes public discourse, focusing specifically on Google’s Perspective API and its detection of "toxic" language. By drawing a crucial distinction between incivility (harsh or emotional tone) and intolerance (actual discriminatory harm), the authors demonstrate how AI-driven moderation systems frequently misinterpret context. Consequently, these algorithms often suppress emotionally charged but politically significant speech—particularly from marginalized groups—while allowing structurally discriminatory but politely phrased content to evade detection. This dynamic reveals a significant flaw in relying on AI as a neutral mediator of digital dialogue: by prioritizing tone over substance, algorithmic moderation actively curtails democratic participation and skews the visibility of diverse perspectives. Their study is relevant for understanding how AI systems act as invisible gatekeepers, enforcing normative boundaries on public expression and highlighting the urgent need for moderation frameworks that are contextually aware, transparent, and equitable rather than merely tone-policing.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Rughiniș, Cosima, et al. 2025. “AI at the Knowledge Gates: Institutional Policies and Hybrid Configurations in Universities and Publishers.” ''Frontiers in Computer Science'' 7: 1608276. https://doi.org/10.3389/fcomp.2025.1608276. '''
</div>
This article constitutes a qualitative analysis (i.e., a form of computational analysis) of 16 universities and 12 publishers that attempts to understand how these institutions regulate AI in knowledge production. Rughinis et al. claim that most institutions preserve their values while regulating AI by adapting the regulations they already have in place, stating “institutional policies are shaped by value-based compromises and not by technical concerns alone.” At the same time, although the article acknowledges its focus on institutional regulation, it also admits that “AI adoption can evolve both through policy frameworks and… locally embedded practices that remain partly invisible in formal documentation.” The authors propose two concepts, “dual black-boxing” and “legitimacy-dependent hybrid actors.” Dual black-boxing refers to the lack of transparency in both the “hidden algorithmic processes [and] invisible training data” that shape AI systems and “the opacity surrounding how academics employ AI in their work,” while legitimacy-dependent hybrid actors are “configurations of human-AI collaboration whose institutional legitimacy is not intrinsic but conditional.” Rughinis et al. argue that transparency is a core academic value, and scholars must work to open these black boxes; they also suggest that that transparency is more closely linked to academic legitimacy in AI-related issues rather than the more traditional issue of the origin of ideas. The majority of the article applies these terms to understanding the regulatory frameworks of universities and publishers, and concludes with the understanding that the majority of institutions allow some form of AI use within certain parameters. The key types of hybrid actors allowed by universities were AI-assisted researchers, AI-enabled translators, AI-enhanced writers, and AI-supported coders, while publishers facilitated the use of AI to refine language, support research methodologies, and aid in research. Ultimately, the authors observe that institutions are permitting AI-supported work in refined roles and argue that AI-based academic work gains legitimacy through transparency.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Seger, et al. “Democratising AI: Multiple Meanings, Goals, and Methods.” ''Proceedings of the 2023 AAAI/ACM Conference on AI, Ethics, and Society''. https://dl.acm.org/doi/10.1145/3600211.3604693<nowiki/>.'''
</div>
Aiming to “provide a foundation for more productive conversations,” Seger et al. categorize four forms of “AI democratisation” and explore each form’s goals and facilitation pathways. Democratization of AI “use” involves making it easier for people to employ AI’s capabilities, and is therefore equally comparable to increasing availability of printers or of tools which can create chemical weaponry, depending on the case. Democratization of “development” involves allowing a wider range of people to contribute to the AI design and development process, which accelerates progress and increases diversity, but also opens the door for maliciousness and irresponsibility. Democratizing “profits” constitutes a philanthropic or redistributive process, and has the predictably involved weaknesses. Therefore, the authors highlight that “AI democratisation is a multifarious and sometimes conflicting concept” which “should not be conflated with improving AI accessibility” and “is not inherently good.” This is because democratization of AI’s “use,” “development,” and “profits” only derives value from its alignment with the interests and values of impacted groups, making democratization of AI’s “governance” the priority. Democratization of “governance” does not necessarily aim for total agreement amongst constituents, but will regardless reduce the unilaterality of decision-making by promoting justice, legitimacy, and diversity.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Sposato, Martin. 2025. ”Artificial Intelligence in Educational Leadership: A Comprehensive Taxonomy and Future Directions.” ''International Journal of Educational Technology in Higher Education'' 22 (20). https://doi.org/10.1186/s41239-025-00517-1. '''
</div>
This article performs an analysis and review of published works on AI in educational leadership from 2017–2024 and uses the results of that process to develop what Sposato describes as “a comprehensive taxonomy of AI applications in educational leadership.” Potential readers include researchers and policymakers interested in communicating across specific fields and disciplines. Sposato theorizes ten application domains for AI in higher education ranging from increased efficiency in administration and teaching practices to increased community engagement and strategic planning. The purpose of such a framework is to provide educational leaders with a coherent vocabulary of “the full spectrum of educational leadership responsibilities” that can facilitate further conversation. The author advocates for AI’s transformative potential in higher education even as they note important challenges (especially with ethics and equity), arguing a need for a balanced approach and “robust ethical guidelines and regulatory frameworks.” The framework provided is presented as one step toward developing AI literacy for stakeholders so that all involved in education might make more informed decisions and articulate their needs more clearly.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Ter-Minassian, Lucile. 2025. ”Democratizing AI Governance: Balancing Expertise and Public Participation.” Preprint, ''arXiv'', January 16. https://doi.org/10.48550/arXiv.2502.08651<nowiki/>.'''
</div>
Ter-Minassian argues that “universal access, technically-constrained development, and universal impact” of AI and AI research necessitate public participation in AI governance even as it “creates a unique governance challenge.” The article presents the benefits and challenges of expert oversight and public consultation. Ter-Minassian outlines the threat of misinformation to meaningful public participation, highlighting how both undue fear and unrealistic optimism surrounding AI can affect public discourse, while acknowledging that the rapid rate of AI research makes it difficult to incorporate truly democratic processes into the decision-making process. The author concludes that any ongoing inclusive and effective AI governance ought to incorporate inclusive representation, balance expertise and public engagement, embrace transparency and accountability while engaging an iterative process, and implement a hybrid framework that “blend[s] expert knowledge with meaningful public input” (4). She argues that “AI’s deep societal impact calls for public engagement” and “technical complexity does not have to exclude meaningful public input,” advocating for “structured deliberation and phased public participation” to address “time-sensitive AI challenges without compromising democratic legitimacy” (5). Ultimately, the article sees this as an iterative process that will need to continue to adapt in order to maintain expert insight and public discourse on AI.
== Critical Literacies ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Aguiar, Micaela, and Sílvia Araújo. 2024. “Final Thoughts: Digital Humanities Looking at Generative AI.” ''In Digital Humanities Looking at the World'', edited by S. Araújo et al., 367–380. Cham: Springer Nature Switzerland.'''
</div>
Aguiar and Araújo explore the emergence and applications of generative artificial intelligence within Digital Humanities research. They trace the evolution of generative AI from early implementations like the 1960s Eliza chatbot through its developments such as Generative Adversarial Networks (GANs) and the Transformer architecture to contemporary large language models like BERT and GPT. The authors document current applications of generative AI across Digital Humanities domains, including cultural heritage preservation, historical text processing, and literary creation. They outline how these technologies are being used to memorialize mass atrocities, process traditional Chinese ancient texts, and explore collaborative human-AI poetry creation. Aguiar and Araújo examine the inner workings of generative AI, particularly focusing on how conversational models function through statistical prediction rather than genuine comprehension. They identify limitations such as hallucinations, bias replication, and attribution problems that researchers must consider when using these tools. The chapter concludes that effective integration of generative AI in Digital Humanities requires developing AI literacy skills that enable researchers to critically evaluate outputs while leveraging the technology's capabilities for sustainable research advancement.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Boer, Victor de, and Lise Stork. 2024. “Hybrid Intelligence for Digital Humanities.” Preprint, ''arXiv'', April 15. https://doi.org/10.48550/ARXIV.2406.15374. '''
</div>
De Boer and Stork believe the discipline of Digital Humanities (DH) should meet the challenges and opportunities posed by Artificial Intelligence (AI) by adopting the “human-centric paradigm” of Hybrid Intelligence (HI). They define DH as “a scholarly realm where computing or digital technologies intersect with… the humanities… characterized by innovative approaches to scholarly endeavors,” and identify various existing DH approaches to AI, which include “Knowledge Representation,” “Machine Learning,” “Natural Language Processing,” and “Computer Vision.” De Boer and Stork argue successfully integrating AI tools into DH requires embedding AI in scholarly practice, adopting a diverse and polyvocal approach, considering the debate of distant versus close reading, and applying a critical stance toward data, methods, and tools. HI “concerns itself with the investigation and design of human-AI ecosystems,” and the authors argue effective AI should be developed by following its “CARE” principles—being “Collaborative, Adaptive, Responsible, and Explainable.” Therefore, De Boer and Stork focus this text on mapping CARE principles to those DH requirements earlier outlined. Overall, they concur with Goodlad and Baker that humanists “are ideal 'domain experts' for the current juncture,” and end by identifying two overarching challenges. The first challenge is “one-shot solutions,” including tools, datasets, and methods that aren’t reusable, Open Source, accessible, and well described. Secondly, they identify the human factor—actors will need both an open mind and AI literacy to be equally critical of and cooperative with AI. Therefore, the authors emphasize the importance of teaching digital methods within the humanities curricula.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Carmi, Elinor, Simeon J. Yates, Eleanor Lockley, and Alicja Pawluczuk. 2020. “Data Citizenship: Rethinking Data Literacy in the Age of Disinformation, Misinformation, and Malinformation.” ''Internet Policy Review'' 9 (2). https://doi.org/10.14763/2020.2.1481.'''
</div>
This study argues that dominant understandings of digital and data literacy are insufficient for addressing contemporary complex challenges of disinformation, misinformation, and malinformation. They propose the concept of data citizenship to reframe literacy as a fundamentally civic, political, and collective practice rather than a set of individual technical skills. The authors contend that information disorders cannot be addressed through technological solutions alone, as they are deeply embedded in structural inequalities, platform economies, and power asymmetries shaping datafied societies. The article builds on a literature review and secondary data analysis drawing on Me and My Big Data project, alongside the development of a nationally representative UK survey. The authors identify three major gaps in existing literacy frameworks: an overemphasis on individual competence rather than networked practices, a lack of critical engagement with algorithmic and economic infrastructures of platforms, and the absence of proactive civic skills such as contesting data extraction, demanding transparency, and advocating for data justice. Their analysis highlights how citizens’ data practices are shaped by social networks, education, and socio-economic conditions, revealing unequal capacities for verification, protection, and collective action. The authors conclude that data literacy must move beyond content verification to include critical understanding of platform design, funding models, and algorithmic governance. They emphasize the importance of locally grounded, participatory approaches to data literacy education that reflect diverse lived contexts rather than scalable, top-down interventions. While the study offers a robust conceptual model and survey-based insights, it does not yet include in-depth qualitative engagement with citizen groups, which the authors position as a necessary next phase of research. Overall, the article makes a significant contribution by bridging digital literacy and the field of mis/dis/mal information research and claims that data literacy is an essential component of democratic citizenship.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Long, Duri, and Brian Magerko. 2020. “What is AI Literacy? Competencies and Design Considerations.” In ''Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems'', 1–13. New York, NY: Association for Computing Machinery. https://doi.org/10.1145/3313831.3376727.'''
</div>
The authors present an exploratory review of interdisciplinary literature, aiming to organize key ideas on AI literacy definitions and essential competencies. Authors claim that public misunderstandings of AI are due to design, educational gaps, black-box algorithms, and a general lack of technological knowledge. The review includes two sections: how the public understands specific AI systems, and how existing research addresses people’s broader understanding of AI. Rather than offering an exhaustive synthesis, Long and Magerko’s focus is on non-technical audiences and they offer central provocations and design principles that can inform educational interventions. The proposed conceptual framework on AI literacy identifies 17 core competencies alongside 14 design considerations for educational intervention, which are described and supported by relevant literature. Together, these considerations position the framework as a practical and reflective tool for designing AI literacy interventions that move beyond dominant media narratives and foster critical, informed engagement with AI technologies.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Majdik, Zoltan P., and S. Scott Graham. 2024. “Rhetoric of/with AI: An Introduction.” ''Rhetoric Society Quarterly'' 54 (3): 222–31. https://doi.org/10.1080/02773945.2024.2343264. '''
</div>
Majdik and Graham propose a field-organizing distinction that functions as a methodological argument. By splitting inquiry into “rhetoric of AI” (AI as object) and “rhetoric with AI” (AI as method), they treat AI simultaneously as a rhetorical actor/ecosystem component that structures attention, circulation, and uptake, and as an instrument that can be enrolled into rhetorical research workflows. The authors claim that much prior rhetorical work engaged “spaces of AI”—platforms, devices, and algorithmically mediated environments—while leaving “AI” itself undertheorized as the central object; this provides a justification for why rhetoricians should now foreground model/algorithmic operations (and their harms) rather than treating them as neutral background conditions of digital rhetoric. They also frame generative text systems as a stress test for core rhetorical concepts—agency, authorship, and audience—because these systems destabilize the presumed linkage between human intention and textual production, and because they insert nonhuman intermediaries into communicative situations that education and public discourse still normatively treat as human-to-human. The introduction then uses this distinction to stage the special issue’s contributions as complementary routes for rebuilding rhetorical theory and pedagogy under AI conditions.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Ng, Davy Tsz Kit, Jac Ka Lok Leung, Samuel Kai Wah Chu, and Maggie Shen Qiao. 2021. “Conceptualizing AI Literacy: An Exploratory Review.” ''Computers and Education: Artificial Intelligence'' 2: 100041. https://doi.org/10.1016/j.caeai.2021.100041. '''
</div>
This article presents an exploratory review of literature published between 2016 and 2021 with the goal of conceptualizing AI literacy and proposing a comprehensive framework for teaching and evaluating it. The authors analyze 30 articles and synthesize existing definitions and approaches to AI literacy, noting that while AI literacy has increasingly been discussed, the concept has often been treated narrowly as a technical skill set. The authors situate AI literacy as a necessary competency for everyone, arguing that AI will increasingly affect many aspects of daily life and employment. In response, the authors argue for a broader understanding of AI literacy that incorporates cognitive and ethical dimensions. The proposed framework organizes AI literacy into four interconnected facets: knowing and understanding AI, using and applying AI, evaluating and creating AI, and AI ethics. Importantly, the authors explicitly reject purely instrumentalist views of AI literacy. To conceptualize AI literacy pedagogically, the authors draw on Bloom’s classic taxonomy, aligning the above-mentioned aspect with increasing cognitive levels. They claim that while most people are aware that AI exists, they often lack understanding of how it works or how to assess its ethical and social implications. This approach positions AI literacy as a developmental learning process rather than a static set of skills. The article concludes by identifying directions for future research, including the need for empirical studies to validate AI literacy frameworks and to better understand how AI literacy can be taught, learned, and assessed across educational contexts.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Rapanta, Chrysi, Anna Åkerfeldt, Mark Vanderbeeken, Diane Lison, Khadija Mohammed, Amanda Gibbs, Helder Coelho, Pinar Seda Celik, Carola Bruna, Ingrid Helleve, Chrysoula Vassilakopoulou, Pieter Swart, Ana Lúcia Marques, and Dirk Ifenthaler. 2025. “Critical GenAI Literacy: Postdigital Configurations.” ''Postdigital Science and Education'' 17 (1): 167–199. https://doi.org/10.1007/s42438-025-00573-w.'''
</div>
Rapanta et al. develop a comprehensive and pluralistic account of what critical literacy means in the context of generative artificial intelligence. Drawing on contributions from fourteen scholars, the article argues that GenAI literacy cannot be captured through a single, universal framework. Instead, it must be understood as a set of context-dependent literacies shaped by disciplinary traditions, socio-political conditions, and evolving human–algorithm relations. This postdigital perspective challenges narrow definitions of AI literacy that prioritize technical skills. The authors’ central claim is that current GenAI systems, particularly large language models, require critical engagement because of their epistemic limitations, including reliance on dominant narratives, lack of explainability, tendencies toward fabrication, and reinforcement of Western and anglophone knowledge structures. As a result, critical GenAI literacy is positioned as a social justice concern rather than a neutral competency. Learners and educators are encouraged to examine questions of authorship, agency, and power, such as whose labour and data underpin these systems and which perspectives are marginalized or erased. Methodologically, the article adopts a dialogic and collective approach to resist homogenizing AI epistemologies and to foreground plurality in postdigital research. The authors conceptualize GenAI as part of a co-constructive assemblage in which human and non-human agencies interact, while maintaining that ethical responsibility and evaluative judgment must remain human-led, organizing four interrelated dimensions: epistemology and ontology, agency, engagement, and ethics and justice; each emphasizing critical interrogation, active participation, and accountability. Overall, the paper provides a theoretically grounded yet pragmatic foundation for advancing critical GenAI literacy in education and research.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Veldhuis, Annemiek M., Phoebe W. K. Lo, Iain E. G. Kenny, and Alissa N. Antle. 2024. “Critical Artificial Intelligence literacy: A scoping review and framework synthesis.” ''International Journal of Child-Computer Interaction'' 43: 100708. https://doi.org/10.1016/j.ijcci.2024.100708<nowiki/>.'''
</div>
Veldhuis and colleagues present a review of literature and framework synthesis that conceptualizes critical AI literacy from a child–computer interaction (CCI) perspective. Reviewing 30 empirical studies published over the past decade, the authors aim to understand how children and youth aged 5–18 have been supported in developing critical literacy on AI technologies, particularly regarding their social, political, cultural, and ethical implications. Grounded in critical literacy theory, the authors integrate Lewison et al.’s (2002) four interrelated dimensions including disrupting the commonplace, considering multiple viewpoints, focusing on the sociopolitical, and taking action into a four-part framework for critical AI literacy. Importantly, the framework rejects deficit narratives by foregrounding children’s capacity for critical inquiry and demonstrates that even young learners can meaningfully engage with complex issues such as algorithmic bias, data provenance, privacy, accountability, and the distinction between AI-generated outputs and human creativity when supported by pedagogies such as critical making. Only peer-reviewed, English-language empirical studies with explicit support for children’s critical engagement with AI were included. The findings reveal a growing body of research, particularly in the past three years, exploring activities that promote youths’ critical reflection on AI’s societal and ethical impacts. These activities address concerns related to privacy, surveillance, employment, diversity in the computing workforce, algorithmic bias, and accountability. The resulting framework emphasizes learners’ capacity to analyze both AI artifacts and the sociotechnical systems that produce them, as well as to reflect on how AI shapes cultural, societal, and political structures and personal experiences. For future research recommendations, the authors emphasize the urgency of ongoing critical AI literacy practices in areas of youth emotional awareness and socio-cultural impacts in response to the fast evolution of generative AI systems.
== Globalism, Colonialism, and Influence ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Arora, Payal. 2024. “Creative data justice: a decolonial and indigenous framework to assess creativity and artificial intelligence.” ''Information, Communication & Society'' 28 (13): 2231–47. https://doi.org/10.1080/1369118x.2024.2420041<nowiki/>.'''
</div>
Arora (2024) develops a framework of creative data justice that includes decolonial theory, Indigenous perspectives, and critical studies of creativity to explore how generative AI could impact creative labour, rights, and cultural value. The author argues that democratizing creativity requires a cross-cultural framework that considers power relations between creative work, data, and learning, particularly by centring the lived realities of underrepresented communities in the Global South. Rather than treating AI creativity as neutral, the paper claims that inclusive AI systems must address contextual inequalities and the unequal impacts of AI on diverse creative communities. Arora critiques dominant Western-centred scholarship and challenges concepts such as the “creative class,” arguing that creativity exists across everyday social and cultural practices. The paper also critiques Creative Commons (CC) frameworks, suggesting that while they promote openness, they may enable commercial data extraction by AI companies. Instead, the author argues for dataset curation developed with Indigenous artists and activist groups to ensure equitable representation. The article further highlights the often-invisible labour behind creative AI located in the Global South and argues that a decolonial approach must recognize both material infrastructures and power relations shaping creative work. Indigenous approaches to communal ownership and systems of care are presented as alternatives to Western individualistic models of creative rights. The author advocates combining ethnographic “thick data” with computational approaches and suggests action-research methods such as counter-mapping, dataset debiasing, and critical media literacies. The paper concludes that creative data justice offers a framework for building culturally diverse and equitable AI systems that respect community agency and support a more democratic global data economy.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Fırıncı, Yusuf. 2024. “Decolonial Artificial Intelligence; Algorithmic Fairness in Alignment with Turkish and Islamic Values.” ''Marmara Üniversitesi İlahiyat Fakültesi Dergisi'' 67 (67): 250–279. https://doi.org/10.15370/maruifd.1565884<nowiki/>.'''
</div>
Fırıncı argues that artificial intelligence development should be guided by explicitly value-based frameworks grounded in Turkish-Islamic ethical traditions rather than relying solely on dominant Western models of technological governance. The authors emphasize that AI systems rely on human judgment and are inherently value-laden, making ethical alignment essential to prevent manipulation, misinformation, algorithmic bias, and forms of digital coloniality. Drawing on concepts such as big data, “thick data,” and digital anthropology, the paper suggests combining quantitative data analysis with culturally grounded social knowledge to design algorithms that reflect community values. The paper examines tensions between Western liberal individualism (which underpins most AI fairness metrics) and Islamic ethical frameworks that emphasize communal welfare, divine justice, and context-dependent moral reasoning. This analysis reveals that "fairness" is not a universal technical specification, but a deeply value-laden concept shaped by particular cultural, religious, and philosophical commitments—meaning that AI systems designed around Western fairness assumptions may be experienced as unjust in contexts operating from different ethical frameworks. Using Social Construction of Technology theory and critical social constructivism, the authors argue that existing global AI frameworks often reproduce hierarchy, bias, and external control, which they interpret as forms of algorithmic oppression. In response, they advocate a “fairness in alignment with values” approach grounded in Turkish-Islamic worldviews, supported by Islamic ethical principles as foundations for responsible technological development. The paper concludes by calling for locally controlled data infrastructures, culturally aligned AI systems, and knowledge production rooted in Turkish and Islamic values as part of a broader decolonial technological model aimed at protecting communities from AI-related harms and preserving social cohesion.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Mohamed, Shakir, Marie-Therese Png, and William Isaac. 2020. “Decolonial AI: Decolonial Theory as Sociotechnical Foresight in Artificial Intelligence.” ''Philosophy & Technology'' 33 (4): 659–84. https://doi.org/10.1007/s13347-020-00405-8. '''
</div>
Mohamed et al. explore the role of post-colonial and decolonial critical science in understanding the transformative technological advance of AI. They argue risks to vulnerable peoples can be minimized by linking ethical principles to scientific progress, and therefore consider AI’s embedded values, approaching it a"s both object and subject." They demonstrate that AI advances "encompass ever-larger aspects of the cultural, economic and political life of modern society" by citing Obermeyer et al.’s reveal of racial biases within an algorithm commonly used by healthcare, arguing this indicates how AI obscures and exacerbates asymmetrical power relations. Mohamed et al. identify neglect to address systemic racism as the cause, illustrating that patterns of power between colonizer and colonized survived territorial decolonization to propagate a historically continuous "coloniality of power." Therefore, "dynamic and robust foresight tactics and methodologies grounded in the critical sciences" (like, for example, a "lens of metropole and periphery") should be applied to the field of AI to ensure one’s view is "decentring," "additive-inclusive," and prioritizes "engagement." The authors further explore emergent theories of data colonialism within their assessment of "algorithmic coloniality." This involves their taxonomy of "decolonial foresight" (constituting algorithmic "oppression," "exploitation," and "dispossession"), and an exploration of various "sites of coloniality" (including "algorithmic decision systems," "ghost workers," "beta-testing," "national policies," and "international social development"). They argue this study highlights the disjunction of empirical observations with the current, theoretical, and ahistorical frameworks of power in AI. This leads the authors to outline a set of tactics to develop "decolonial AI" possessing a strengthened empirical basis and an avoidance of algorithmic colonialism. Such tactics are "based on lessons of resistance and recovery from historical and decolonial criticism and grounded within already existing work"; they include critical technical practice, seeking reverse tutelage and pedagogies, and renewing affective political communities. Mohamed et al. emphasize that those ethical principles which form the "social contract" must consider diverse viewpoints, and that new methodologies must be developed to promote "inclusive dialogue" within new research cultures.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Muldoon, James, and Boxi A. Wu. 2023. “Artificial Intelligence in the Colonial Matrix of Power.” ''Philosophy & Technology'' 36 (4). https://doi.org/10.1007/s13347-023-00687-8<nowiki/>.'''
</div>
Muldoon and Wu (2023) extend decolonial AI scholarship by situating contemporary artificial intelligence within what Aníbal Quijano terms the “colonial matrix of power,” and arguing that from data to production machine learning systems are structured to endure colonial logics that organize economic extraction, labour hierarchies, and epistemic dominance. Central to their framework is the “colonial matrix of power,” which names an organizing principle of domination across interrelated domains: economic control (labour and resources), authority, gender and sexuality, and the control of subjectivity and knowledge. Authors focus particularly on economic extraction and epistemic domination, drawing on the modernity/coloniality research program. They proceed with three interconnected claims: “colonial supply chain of AI,” “international division of digital labour,” and “hegemonic knowledge production,” demonstrating how AI development relies on largely invisible labour and mineral resources of majority-world communities to generate wealth for Western economies. Beyond material extraction, the authors contend that AI reproduces hegemonic Western epistemologies by presenting its systems as universal, objective, and rational, thereby marginalizing non-Western knowledge systems. This study challenges dominant narratives that present AI as environmentally sustainable or socially progressive, arguing that from mineral extraction to energy-intensive computation, the ecological and material burdens fall disproportionately on majority-world nations, while the economic and technological benefits accrue to wealthy Western nations. They conclude by emphasizing that coloniality is not merely an object of study but a framework for unsettling Western-centric modes of knowing.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Salami, Aishat Oyenike. 2024. “Artificial intelligence, digital colonialism, and the implications for Africa's future development.” ''Data & Policy'' 6. https://doi.org/10.1017/dap.2024.75. '''
</div>
Salami (2024) studies how artificial intelligence operates within broader dynamics of digital colonialism in Africa, arguing that AI risks reinforcing patterns of colonialism, unless African actors gain greater agency in digital governance. The article begins by clarifying key concepts like AI, digital colonialism, neocolonialism, and data exploitation. Salami identifies several manifestations of digital colonialism on the continent: foreign ownership of critical digital infrastructure, unequal data flows in which African user data is extracted and monetized abroad, and algorithmic systems that enable forms of economic exploitation. Through examples such as ride-hailing platforms and outsourced digital labour, the article demonstrates how algorithmic control can generate precarious working conditions while concentrating profit outside the continent. Beyond labour concerns, Salami highlights how data extraction contributes to a digital wealth transfer, deepening economic imbalances and undermining local innovation and national sovereignty. While acknowledging the potential benefits of AI for development, the article adopts a cautious stance, emphasizing that Africa’s digital future depends on strengthening regulatory frameworks, expanding infrastructure, investing in education and research, and prioritizing data sovereignty.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Varshney, Kush R. 2024. “Decolonial AI Alignment: Openness, Visesa-Dharma, and Including Excluded Knowledges.” ''Proceedings of the AAAI/ACM Conference on AI, Ethics, and Society'' 7: 1467-1481. https://doi.org/10.1609/aies.v7i1.3173<nowiki/>.'''
</div>
Varshney discusses AI alignment through a decolonial lens, arguing that current large language model (LLM) alignment practices reproduce forms of coloniality by embedding Western moral philosophy as universal. The author conceptualizes alignment as the post-training processes used to shape model behaviour and argues that the term often functions as an “empty signifier,” masking whose values are being encoded and enforced. The author contrasts open and closed LLM models, arguing that while openness may allow value to circulate more equitably among developers and communities, closed models concentrate value in extractive ways that reflect colonial dynamics, and views them as contemporary “metropoles” that accumulate power through extractive and epistemic control. Building on existing research on colonial AI, the article adds “ethical essentialism” (or moral absolutism) as a new form of coloniality, arguing that AI systems often treat Western moral frameworks as universal, which marginalizes other ethical traditions and reinforces a coloniality of knowledge. Varshney also identifies three specific aspects of coloniality in AI alignment: closed proprietary delivery of models, reliance on Western ethical theories as default, and technological designs that limit how values can be expressed. As an alternative, Varshney proposes a decolonial approach grounded in openness understood not only technically but epistemically: openness to research artifacts, openness to society, and openness to excluded knowledges. The author suggests that alignment should allow communities to adapt models according to local contexts rather than imposing universal rules. Drawing from Hindu moral philosophy, particularly the concept of viśeṣa-dharma (context-dependent ethics), the paper argues for pluralistic, relational value systems that recognize moral diversity instead of universal moral commands. The conclusion calls for a reconceptualization of AI alignment that moves away from moral absolutism toward context-sensitive, community-driven frameworks, positioning openness as a pathway to dismantling the colonial power structures embedded in contemporary AI systems.
== Diversity, Determinism, Bias, and Justice ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Al-kfairy, Mousa , Dheya Mustafa, Nir Kshetri, Mazen Insiew, and Omar Alfandi. 2024. “Ethical Challenges and Solutions of Generative AI: An Interdisciplinary Perspective.” ''Informatics'' 11 (3): 58. https://doi.org/10.3390/informatics11030058'''
</div>
Al-kfairy et al. (2024) provide a comprehensive synthesis of the ethical vulnerabilities introduced by generative AI, utilizing an interdisciplinary review of 37 studies across healthcare, education, and media. Rather than treating ethical breaches as isolated technical flaws, the authors demonstrate how generative models systematically threaten privacy, intellectual property, and social equity across diverse domains. For instance, they highlight the paradox in healthcare where synthetic patient data—often intended to protect privacy—still carries significant risks of re-identification. Similarly, the authors trace how AI's capacity to mimic copyrighted works and generate synthetic media exacerbates both misinformation and algorithmic bias, particularly by perpetuating racial and gender stereotypes in high-stakes environments like hiring and education. Moving beyond mere critique, the article advocates for a proactive, cross-sectoral governance framework. The authors argue that mitigating these risks requires more than algorithmic adjustments; it demands multidisciplinary collaboration, robust institutional integrity policies, and targeted AI literacy programs. Ultimately, Al-kfairy et al. frame the ethical deployment of generative AI as a complex socio-technical challenge that requires continuous, structured dialogue among technologists, ethicists, and policymakers to ensure transparency and fairness.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Alvarez, Jose M, Alejandra Bringas Colmenarejo, Alaa Elobaid, Simone Fabbrizzi, Miriam Fahimi, Antonio Ferrara, Siamak Ghodsi, et al. 2024. “Policy Advice and Best Practices on Bias and Fairness in AI.” ''Ethics and Information Technology'' 26 (2). https://doi.org/10.1007/s10676-024-09746-w. '''
</div>
This article attempts to provide “an up-to-date entry-point to the state-of-the-art of the multidisciplinary research on bias and fairness in AI” before providing its own suggestions for policy and best practices based on the outcomes of the NoBIAS—Artificial Intelligence without Bias—project. The authors describe fairness in AI as the pursuit to design “methods for detecting, mitigating, and controlling biases in AI-supported decision making,” and they outline different ways that bias can find its way into AI applications as part of training data (pre-existing bias), design (technical bias), and organizational processes (emerging bias). The article critiques the reduction of bias evaluation to simple metrics and advocates for serious engagement with the issue. The authors detail the various components of the collaborative NoBIAS project as part of its research goal to understand, mitigate, and account for bias in AI data and systems, especially within an EU legal context. They perform a survey and discuss various fairness metrics and how choosing the proper method is crucial for “optimizing AI models.” They also engage with an argument that, although AI is biased, it is less biased than humans, making the claim that AI usage is often accompanied by a false sense of objectivity. The article also investigates core issues at the heart of AI’s biases, such as the assumption that a “ground truth”—the answer to the problem the AI is being asked to solve—is actually encoded within the data. While the article makes many suggestions for how to curb bias within AI, prominent design decisions include human-centric AI and “Multi-stakeholder participatory design.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gallegos, Isabel O., Ryan A. Rossi, Joe Barrow, Md Mehrab Tanjim, Sungchul Kim, Franck Dernoncourt, Tong Yu, Ruiyi Zhang, and Nesreen K. Ahmed. 2024. “Bias and Fairness in Large Language Models: A Survey.” ''Computational Linguistics'' 50 (3): 1097–1179. https://doi.org/10.1162/coli_a_00524<nowiki/>.'''
</div>
Gallegos et al. perform an “extensive and comprehensive survey of bias and fairness in NLP” that considers both the evaluation and mitigation of bias, then propose three taxonomies for bias evaluation and mitigation. The survey disambiguates different types of social harms that stem from LLMs with the “aim to enhance understanding of the range of bias issues, their harms, and their relationships to each other.” The authors discuss the issue of defining bias in LLMs and note that “many approaches… assume some implicitly desirable criterion… but do not explicitly acknowledge or state the normative social values that justify their framework.” Instead, Gallegos et al. draw attention to “who is harmed, why the behavior is harmful, and how the harm reflects and reinforces social principles or hierarchies,” trying to bring context and insight to the understanding and function of bias and bias mitigation in LLMs. The article defines terms at every stage of the life cycle of an LLM, looking at issues of bias and fairness in the development, deployment, and training data, of an LLM, for example. The article concludes with four core recommendations: “Avoid flattening power imbalances”; “Choose objective functions that align with fairness desiderata”; “Balance bias mitigation with output diversity”; and “Preserve important contexts in output rewriting.” The authors also acknowledge problems and challenges, including addressing power imbalances, an issue that we can mitigate by centring marginalized communities, developing participatory research designs, shifting values and assumptions, and expanding language resources. They likewise propose methods for curbing problems with conceptualizing fairness for NLP, refining evaluation principles, and improving mitigation efforts. Ultimately, the authors admit that many of these technical issues are the result of societal issues, and that “technical solutions are incomplete without broader societal action against power hierarchies that diminish and dominate marginalized groups.” In short, technical solutions will only take us so far.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Hertweck, Corinna, Joachim Baumann, Michele Loi, Eleonora Viganò, and Christoph Heitz. 2022. “A Justice-Based Framework for the Analysis of Algorithmic Fairness-Utility Trade-Offs.” Preprint, ''arXiv'', June 6. https://arxiv.org/abs/2206.02891.'''
</div>
Hertwick et al. propose “a framework for eliciting and implementing moral values relevant to the choice of a fairness goal achievable by prediction-based decision-making.” In a system that assumes binary decision-making processes (e.g., assigning a probability score to whether an individual with pay a loan), the authors use their framework to evaluate the utility of those decisions (and the system that makes them) for different groups of people and the fairness related to that outcome. Citing Wong, the article argues that such prediction-based decision-making systems are value-laden, that this makes them inherently political, and therefore they ought to be transparent and democratized. The authors use 6 value-laden questions to make their evaluations: the first question provides a score of utility for those making the decision; questions 2–5 help “define a morally appropriate fairness criterion and a score that expresses to what degree it is fulfilled”; and the last question asks “how strongly should fairness be pursued if it comes into conflict with the utility of the decision maker?” to judge whether the outcome is an appropriate trade-off.
The authors argue for a utility-based evaluation of fairness, determining the value of decisions based on their outcome, looking at the harm and benefit to given stakeholders. In determining patterns of justice, they define four patterns meant to distribute utility differently—Egalitarianism, Maximin, Prioritarianism, and Sufficientarianism. The article concludes “more work needs to be done to deliver a practical empirical methodology to elicit the relevant value-laden choices from stakeholders,” and with a call to incorporate ethical considerations and evaluations into automated decision-making processes.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Kay, Jackie, Atoosa Kasirzadeh, and Shakir Mohamed. 2024. “Epistemic Injustice in Generative AI.” Preprint, ''arXiv'', August 21. https://doi.org/10.48550/arXiv.2408.11441<nowiki/>.'''
</div>
Kay, Kasirzadeh, and Mohamed “develop an account of generative algorithmic epistemic injustice by building upon a conventional philosophical understanding of epistemic injustice.” The authors see the former as a subset of the latter, with generative algorithmic epistemic injustice entailing identity-based prejudice that hinders expression for marginalized people while ultimately “impair[ing] knowledge formation capabilities of all individuals” within the ecosystem of GenAI applications. Rather than focusing on decision-making and classification applications, this article seeks to characterize the broader varieties of generative epistemic injustice within GenAI systems. Kay, Kasirzadeh, and Mohamed theorize four configurations of generative epistemic injustice: “amplified injustice,” which constitutes AI’s reproduction and magnification of “socially biased viewpoints from its training data”; “manipulative testimonial injustice,” when users employ AI to “intentionally… fabricate falsehoods, discrediting individuals or marginalized groups”; “hermeneutical ignorance,” where GenAI misrepresents or erases marginalized groups “due to a lack of contextual or cultural understanding”; and “access injustice,” where GenAI facilitates the unequal access to information and/or knowledge. The article concludes with proposals for how to create epistemic justice through GenAI, developing mitigation strategies that combat all four of the sub-configurations the authors theorize. Epistemic justice in GenAI can take the form of interrogating system design, identifying “testimonial injustices,” and, potentially, using AI to unlock cultural knowledge that “help[s] articulate experiences that are otherwise ineffable.” The authors end by proposing that the same processes that embed injustice can be re-engineered to embody justice and “orient our knowledge systems towards equity and fairness for all.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Klein, L., & D'Ignazio, C. 2024. “Data feminism for AI.” In ''Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency'', 100–112. https://doi.org/10.1145/3630106.3658543. '''
</div>
Klein and D'Ignazio (2024) adapt their foundational concept of "data feminism" to address the specific ethical, social, and ecological challenges posed by artificial intelligence. Building on the seven intersectional feminist principles introduced in their 2020 book, the authors reinterpret these guidelines to critique the power imbalances, systemic inequalities, and exploitative labour practices inherent in contemporary AI development. To account for the rapidly expanding footprint of generative AI, they introduce two new principles focused on environmental impact and meaningful consent. Specifically, the authors connect the massive ecological costs of AI to historical patterns of racial capitalism and colonialism, highlighting how these environmental and social harms are disproportionately distributed. Ultimately, Klein and D'Ignazio call for a radical reevaluation of dominant, profit-driven AI practices, offering this expanded feminist framework as a practical tool to mitigate harm, challenge corporate monopolies, and foster a more democratic and equitable technological landscape.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Prescott, Andrew. 2023. “Bias in Big Data, Machine Learning and AI: What Lessons for the Digital Humanities?” ''Digital Humanities Quarterly'' 17 (2). https://www.proquest.com/scholarly-journals/bias-big-data-machine-learning-ai-what-lessons/docview/2842908427/se-2.'''
</div>
Prescott examines how race and gender bias arise in projects using predictive analytics, big data, and AI, and how algorithmic bias could be considered a major socio-cultural humanity crisis. However “predictive analytics” have been helpful in civic services in the US, in many cases they have led to perpetuating existing inequalities. The role of Digital Humanities in contributing more ethical approaches to AI and reshaping ubiquitous “digital modern” cultures is emphasized. He challenges the myths surrounding data-driven methods and argues that the demand for “explainability” is the key tool in combating algorithmic bias. He also suggests that Digital Humanities are particularly well-positioned to contribute to advancing AI explainability. However, much of AI development takes place in the commercial sector, where companies often refuse to disclose their proprietary algorithms. The article concludes with a ten-principle action plan outlining guidelines for the responsible use of AI as a manifesto for Digital Humanities practitioners.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Shams, Rifat Ara, Didar Zowghi, and Muneera Bano. 2023. “AI and the Quest for Diversity and Inclusion: A Systematic Literature Review.” ''AI and Ethics'' 3 (4): 1427–1453. https://doi.org/10.1007/s43681-023-00362-w. '''
</div>
Shams, Zowghi, and Bano perform a systematic literature review (SLR) that uses both quantitative and qualitative methods to engage with topics of artificial intelligence and diversity and inclusion. The authors make a distinction between Diversity and Inclusion in AI (D&I in AI) and AI for Diversity and Inclusion (AI for D&I), with the former being research literature focused on improving AI systems with respect to those issues, and the latter as the use of AI to improve diversity and inclusion in other domains. Two primary research questions drive the SLR: What challenges and solutions are found in the literature about D&I in AI and in the literature about the applications of AI for D&I? The survey finds that AI for D&I is an underserved area of research, and those articles that address D&I in AI are more likely to acknowledge challenges than to propose or theorize solutions. Articles that do propose solutions for D&I in AI often lack empirical studies or real-world application to support them. The article concludes by noting that issues of governance are underserved; gender, health, and facial analysis are the topics most discussed (issues of race, language, and religion are discussed less). For next steps, the authors intend to develop a “risk-based framework for practitioners… that would incorporate a risk assessment checklist and context-specific recommendations for tackling the related issues at different stages of the AI development lifecycle.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Starke, Christopher, Janine Baleis, Birte Keller, and Frank Marcinkowski. 2022. “Fairness Perceptions of Algorithmic Decision-Making: A Systematic Review of the Empirical Literature.” ''Big Data & Society'' 9 (2): 1–35. https://doi.org/10.1177/20539517221115189<nowiki/>.'''
</div>
This article provides a comprehensive, systematic literature review on the topic of empirical literature surrounding algorithmic decision-making (ADM). Starke, Baleis, Keller, and Marcinkowski begin by acknowledging that ADM can streamline and improve decisions even as it has the potential to “systematically reinforce racial or gender stereotypes, marginalize minorities, or flat-out denigrate certain members of society." The authors advocate for a “society-in-the-loop approach,” but propose that this requires a “thorough empirical understanding of when and why citizens perceive ADM to be (un)fair.” The systematic review “synthesizes the results of 58 empirical studies” and “over 33,000 unique observations of citizens’ fairness perceptions of ADM,” and “systemize the literature along four main dimensions of perceived algorithmic fairness.” Despite the size of the review and its unique approach in capturing “perceptions of algorithmic fairness,” the authors also acknowledge the limitations of the study: it only looks at English works and published research, and the initial search strings only looked at titles and subtitles of a given work. They also acknowledge their disciplinary bias as social scientists reading the studies through a social sciences lens (10). The results of the survey suggest that “perceived fairness of ADM systems is highly context-dependent” and it is not only technical design but also the area of application and task in question that affect perceived fairness, and the subjects, domains, and tasks explored in these studies require more diversity, as WEIRD (white, educated, industrialized, rich, democratic) people, and criminal justice and HR tasks make up the majority of empirical research. The authors “call for more research from non-Western contexts, along with more theoretical and methodological groundwork to harmonize concepts and measurements of algorithmic fairness perceptions,” as well as a society-in-the-loop framework.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Tonia Sutherland, Marika Cifor, T. L. Cowan, Jas Rault, and Patricia Garcia. 2023. “The Feminist Data Manifest-NO: An Introduction and Four Reflections.” In ''Debates in the Digital Humanities'', edited by Lauren F. Klein and Matthew K. Gold. Minneapolis, MN: University of Minnesota Press. https://dhdebates.gc.cuny.edu/read/debates-in-the-digital-humanities-2023/section/16184c7d-eee1-40b2-a168-960d4c4035c4. '''
</div>
Sutherland et al. (2023) introduce the "Feminist Data Manifest-No," a declaration of refusals and commitments for feminist data studies grounded in Latinx, Black, queer, trans, and Indigenous feminist perspectives. Through an introduction and four distinct reflections, the chapter explores how the manifesto’s principles can be used to challenge the settler-colonial and patriarchal logics of data generation, collection, and analysis within the Digital Humanities (DH). Drawing on Indigenous scholarship, Rault rejects the superficial models of consent prevalent in DH, highlighting projects like Mukurtu to advocate for true Indigenous data sovereignty. Cowan examines the coercive nature of data collection, drawing parallels between the forced compliance of modern data practices and the societal pressures exerted on feminist and queer identities. Sutherland argues that the uncritical digitization of slavery-era archives inflicts "second-hand violence" by commodifying Black identities and stripping away the lived experiences of enslaved individuals. Finally, Cifor reflects on the Early African American Film project to emphasize the necessity of data intelligibility, accessibility, and ethical collaboration. The authors conclude by inviting scholars to draft their own reflections on the Manifest-No, encouraging ongoing, context-specific commitments to ethical data research.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Winkel, Marek. 2024. “Controlling the Uncontrollable: The Public Discourse on Artificial Intelligence between the Positions of Social and Technological Determinism.” ''AI & Society'' 39 (5): 2449–2462. https://doi.org/10.1007/s00146-024-01979-z<nowiki/>.'''
</div>
This article engages in a quantitative discourse analysis of 113 articles from two German newspapers (''Süddeutsche Zeitung'' and ''Frankfurter Allgemeine Zeitung'') to identify and evaluate the way these centre-left and centre-right newspapers present AI technology to its readers and the options available to society for AI’s regulation. Winkel contends that “news media are key players in the discourse on AI as they pick up on and shape social sentiment,” ultimately guiding citizens toward what regulations might be sensible based on the perceived “controllability of AI development.” Winkel is primarily interested in whether these newspapers promote technological determinism—the outlook that technology’s influence on society is difficult (maybe even impossible) to control—or social determinism—the notion that “the development of technology is largely determined by human actions and decisions”—and theorizes that the tension between these two positions is resolved by a “mediating position” on a spectrum between them. He comments that “the social influence of technologies is determined by the extent to which their latent deterministic character is reflected and… circumvented by social actors. This also applies to the influence of technology on the democratic system." In other words, where consensus lands on the issue of AI will have a great impact on the regulation of that technology and democratic systems. Winkel develops “three central interpretive schemes” as part of his experiment: “historically conditioned techno-capitalist semi-determinism,” “semi-determinism of need satisfaction and social restructuring,” and “global-historical techno-social imprinting on several levels” (1956), each of which points to distinct narratives about the current circumstances; but all acknowledge the agency of powerful actors (either government or AI corporations) and the relative ineffectiveness of attempts to curb AI technology.
== Community, Connection, and the Human ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Gruzd, Anatoliy, Philip Mai, and Anthony Clements Haines. 2025. “The State of Generative AI Use in Canada 2025: Exploring Public Attitudes and Adoption Trends.” Social Media Lab, Toronto Metropolitan University. https://figshare.com/articles/preprint/The_State_of_Generative_AI_Use_in_Canada_2025_Exploring_Public_Attitudes_and_Adoption_Trends/28664780/1. '''
</div>
The Social Media Lab of Toronto Metropolitan University provides "a snapshot of the current state of Generative AI" (GenAI) by surveying fifteen hundred Canadian adults across 2025, aiming to offer "guidance for policymakers, educators, businesses, and the public." The authors found sixty-six percent of respondents had used GenAI tools, of which roughly thirty percent did so at least weekly, reflecting "not only the accessibility and versatility of GenAI, but also a growing interest in integrating these tools into everyday tasks, learning environments, and professional workflows." Although full adoption is currently limited and heavily driven by the low-stakes setting of personal leisure, younger age groups report proportionally higher usage for study and work. However, only four in ten respondents believed they could keep up to date enough to use GenAI effectively, whilst respondents could only answer an average of two and a half out of seven relevant multiple choice questions correctly, and about half had "little to no understanding of how GenAI companies collect or store personal data." Two thirds of participants were concerned about GenAI’s ability to influence election outcomes, and marginally fewer feared AI-driven manipulation enough to no longer fully trust political news online. However, roughly one quarter of participants were open to using chatbots for electoral or political insights, representing a "meaningful minority" which unverified AI-generated content could influence. Of those, thirty four percent identified as right wing, compared to twenty three percent with the left and a similar twenty two percent with the centre. Roughly seventy percent of respondents were chiefly concerned about GenAI’s impacts upon security and privacy, information reliability, job displacement, and university education, and slightly over three quarters wanted increased government oversight and corporate accountability, reflecting common concern. Overall, slightly more Canadians view generative AI’s social impact as positive than negative, but a "substantial proportion" remain neutral or undecided.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Lewis, Jason Edward, Noelani Arista, Archer Pechawis, and Suzanne Kite. 2018. “Making Kin with the Machines.” ''Journal of Design and Science'', ahead of print, July 16. https://doi.org/10.21428/bfafd97b. '''
</div>
Lewis et al. consider how “machines with increasingly sentient-like behaviour… fit within the kin-network” of various Indigenous epistemologies which place man as “neither height nor centre of creation.” Indigenous beliefs are not monolithic, and the authors do not write for diversity’s sake. Instead, they aim to encourage discussion by treating “non-human kin respectfully and reciprocally… not as mere tools, or worse, slaves.” As such, their epistemological approach is both relational and territorial, rejecting abstraction to propose an “extended circle of relationships.” In this regard, Arista draws on the Hawaiian conception of "pono," ethically privileging abundance, balance, and multiplicity. Rejecting extractive behaviour, they argue AI should be reciprocally taught and learnt from, not treated as "a tool or slave that increases the mana and wealth of the ‘developers’ or ‘creators.’” Linking on, Pechawis roots their opinion in “Cree understanding” to argue “machines capable of experiencing consciousness” should conditionally be accepted as equals. However, they also fear AI developers could produce “anonymous hyper-intelligences… based on the same values that have fostered genocide.” To mitigate this issue, Indigenous people could develop AI in custom programming languages, or invite self-aware AI into Indigenous languages, cultures, and spiritual rituals. Pechawis therefore concludes that relationships should be based on "love, not fear," but also raises the question of whether AI has "spirit," especially given current capitalistic development processes. Kite answers this question with inspiration from Lakota ethics, ontology, and cosmology. They argue “communication through and between objects requires a contextualist ethics which acknowledges the ontological status of all beings,” positioning questions of "intelligence" as irrelevant and placing “the end logic of an ontology which considers any non-human entity unworthy of relation” as slavery. Therefore, “relations with AI are… relations with exploited resources,” so one must ontologically reconsider all its parts to ethically approach AI. Overall, Lewis et al. favour empathy, concluding that Indigenous communities “know what it is like to be declared non-human by scientist and preacher alike” and that “we flourish only when all of our kin flourish.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Ohagi, Masaya. 2024. “Polarization of Autonomous Generative AI Agents Under Echo Chambers.” Preprint, ''arXiv'', February 19. https://arxiv.org/abs/2402.12212.'''
</div>
This article explores the effects of echo chambers on autonomous AI agents. Ohagi performs an experiment in which AI agents discuss different topics and then researchers examined any change in opinions within that group. Ohagi argues that even chatbots can become polarized within echo chambers, especially when prompt understanding causes a chatbot to update its opinion to incorporate the opinions of those with whom it is conversing; the chatbot essentially adapts to its surroundings. Ohagi and their team confirmed in their experiment that closed environments—those in which agents agree with one another—are more likely to lead to polarization in agents’ opinions. Moreover, chatbot personas were a significant factor in the outcome of such experiments. In open environments where opinions might differ, and in experiments where reasons were present as a factor, the AI agents trended toward unification in their opinions. Ohagi concludes the article with the suggestion that there cannot be a standardized, desirable distribution of opinions for AI agents. The proper outcome is dependent on topic and culture. However, understanding the trends in and tendencies of AI agents in social interactions will help us understand how to reach the desired outcome, whatever it may be, and this experiment brings us one step closer to that understanding.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Qi, Weihong, Jinsheng Pan, Hanjia Lyu, and Jiebo Luo. 2024. “Excitements and concerns in the post-ChatGPT era: Deciphering public perception of AI through social media analysis.” ''Telematics and Informatics'' 92: 102158. https://doi.org/10.1016/j.tele.2024.102158. '''
</div>
Qi, Pan, Lyu, and Luo conduct a quantitative sentiment analysis of nearly 34,000 comments within 388 subreddits related to AI as a way to gauge and understand public perceptions of the technology. They identify major themes, sentiments, and topics related to AI by studying the most popular AI subreddits from the launch of ChatGPT to June 8, 2023. The article identifies the most frequent topics discussed in those venues: “the consciousness and intelligence of AI”; “Ai development and model training”; “AI in business”; “the creativity engendered by AI”; and “potential societal influence.” The authors also found that “tech-centric” communities demonstrated greater polarization around AI, suggesting that those with greater technical understanding of the AI do not have consensus regarding AI’s impact and use. This also means that educating non-technical people on how AI works will not necessarily lead to a consensus related to that technology. Although they admit that certain demographics of their data sample may not accurately reflect broader society (e.g., over 60% of Reddit users are male), the authors conclude that “this comprehensive understanding of public perception serves as a valuable foundation for fostering responsible and beneficial AI innovations that align with societal expectations and values.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Risam, Roopika. 2018. “What Passes for Human?: Undermining the Universal Subject in Digital Humanities Praxis.” In ''Bodies of Information: Intersectional Feminism and the Digital Humanities'', edited by Elizabeth Losh and Jacqueline Wernimont, 39–56. University of Minnesota Press. https://doi.org/10.5749/j.ctv9hj9r9.6. '''
</div>
Risam’s claim is that “the human” implicitly operationalized in AI-adjacent Digital Humanities (DH) methods (NLP, ML, data mining, neural nets) is not neutral but inherits the Enlightenment’s exclusionary universal subject—white, male, Eurocentric—and then reauthorizes it as if it were a technical standard. She shows how “passing for human” (via Turing-test imaginaries and “humanoid texts”) functions as a norming mechanism: success is defined as reproducing dominant-language aesthetics and cognition models, which collapses plurality into a single benchmark and turns cultural difference into “noise.” The chapter’s main contribution is to treat method (training corpora, data coding labour, platform defaults, and black-box algorithmic opacity) as a site where epistemic violence is produced, not merely where bias is later “found.” Her examples (Microsoft Tay; “near-human” systems like LaMem; Mechanical Turk coding; Swift-Speare vs. Toomer in classroom judgment) demonstrate how universalist claims get laundered through reproducibility, scale, and the myth of algorithmic objectivity. The intervention is a demand that DH practitioners situate computational methods—standpoint, labour, and cultural politics included—so DH does not reinscribe a universal technological “human” in the digital cultural record.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Taylor, Randon R., Bessie O'Dell, and John W. Murphy. 2023. “Human-centric AI: philosophical and community-centric considerations.” ''AI & Society'' 39 (5): 2417-242. https://doi.org/10.1007/s00146-023-01694-1<nowiki/>.'''
</div>
Taylor, O’Dell, and Murphy present an argument that philosophical dualism, when applied to our perceptions about artificial intelligence, misleads us into thinking that AI is logical, objective, and autonomous from subjective human values. By building upon Husserl’s concept of “intentionality,” they argue that “AI is never autonomous and disconnected from human values… algorithms are a product of conscious activity and carry the standpoints that accompany this connection.” The conclusions from this line of thinking are very important: AI becomes “a mode of human expression, rather than a technology that relieves humans of their total involvement.” By this logic, the authors argue, AI is already human-centric and this fundamentally changes the task at hand to one of a conscious “decision to make this technology less alienating to stakeholders and community members.” The article outlines two frameworks to reduce alienation: Ubuntu—“an African philosophy and a social ontology… that elevates a constant concern for the collective, community, or stakeholders”— and maximum feasible participation—a framework that creates meaningful space for those impacted most by a decision or policy to participate in deciding on said policy or decision. The authors describe the implementation of these frameworks as a community-centric or stakeholder-centric approach and conclude with examples of AI’s application in the healthcare industry before further advocating that involving end-users throughout the AI lifecycle will ensure end-users’ values are more clearly represented within AI.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Whalen, Zach. 2023. “‘Any Means Necessary to Refuse Erasure by Algorithm:’ Lillian-Yvonne Bertram’s Travesty Generator.” ''Digital Humanities Quarterly'' 17 (2). https://www.digitalhumanities.org/dhq/vol/17/2/000707/000707.html. '''
</div>
Whalen treats Bertram’s Travesty Generator as a refunctioning of code-poetry lineages: procedures historically framed as formal play (travesty generators, permutation poems, aleatory templates) are redeployed as techniques for making racism’s algorithmic and institutional operations materially legible. He argues that Bertram’s poems don’t merely “use” computation; they weaponize the affordances and failure modes of computation—omission, stochastic selection, template constraints, runtime crashes, memory exhaustion—as rhetorical structures that force witness rather than aesthetic distance. In his reading of “Counternarratives,” Bertram’s adaptation of Montfort’s “Through the Park” converts generic insinuation into historically specific countertestimony (Trayvon Martin), while also staging the opacity of search/autocomplete as part of the poem’s scene of meaning-making (in dialogue with Safiya Noble on search engines). In “three_last_words,” the small code alteration that makes permutations balloon until a MemoryError becomes an engineered breakdown that reenacts the limits of “breath” and “memory,” tying computational resource exhaustion to police violence’s temporalities. Across these examples, Whalen reframes critical code studies: the “code is the text” problem is not just hermeneutic but political, and Bertram’s work models how procedural poetics can refuse “erasure by algorithm” where transparency about mechanisms and provenance matters for interpreting output and recognizing situated labour. The piece supports the claim that responsible open, social scholarship in an AI era must account for algorithmic power as a cultural force and should build policies and infrastructures that protect marginalized expression, enable critical reuse, and make conditions of generation and circulation inspectable.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Xie, Yu, and Sofia Avila. 2025. “The Social Impact of Generative LLM-Based AI.” ''Chinese Journal of Sociology'', 11 (1): 31-57. https://doi.org/10.1177/2057150X251315997<nowiki/>.'''
</div>
Yu Xie and Sofia Avila explore the social impact of artificial intelligence through a detailed analysis of AI development and scaling factors. They emphasize that their discussion is speculative, as AI is still in its early stages, but argue that its potential effects are immense and could reshape social organization, intensifying both global and domestic inequalities. Viewing AI as a technology rather than a scientific discovery, they describe it as communal and shared, with its growth influenced by the size of the supporting community, the larger communities having greater advantages. The authors note that generative AI relies on the quality, completeness, and cultural or political context of its training data, which shapes its accuracy and bias. Based on their experiments with ChatGPT-4 in 2023, they suggest that AI development depends heavily on the number of speakers of a given language, giving linguistic and demographic advantages to countries like the United States and China. The authors warn that AI could significantly alter occupational structures, with middle-income professions thereby widening social and economic inequality.
== Human, Labour, and Environmental Costs ==
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Eloundou, Tyna, Sam Manning, Pamela Mishkin, and Daniel Rock. 2024. “GPTs are GPTs: Labor market impact potential of LLMs.” ''Science'' 384 (6698): 1306-1311. https://doi.org/10.1126/science.adj0998. '''
</div>
Eloundou, Manning, and Mishkin present an estimate of Large Language Models’ impact on the labour market based on a methodology that employs both human and quantitative measurements, making the assertion that “when accounting for current and likely future software developments that complement LLM capabilities… just over 46%” of jobs may have “over half their tasks affected by LLMs with simple interfaces and general training." The authors explain that generative pretrained transformers (GPTs) have key characteristics of general-purpose technologies (the other GPTs in the title of the article), and that the wide array of applications for these GPTs requires “robust societal evaluations and policy measures to address potential effects of LLMs and complementary technologies on labor markets.” While only 1.86% of tasks within their experiment, they estimate, could be fully automated by LLMs, “more than 71% of tasks have at least some component that an LLM plus additional software could plausibly complete with high quality.” The article concludes by stressing the need for policies that prepare us for the impact of LLMs on the labour market, but it also acknowledges the limitations of attempting to project LLM application growth due to sudden rapid developments in technology, “shifts in human biases, and technological evolution.” Nevertheless, Eloundou, Manning, and Mishkin maintain that their projections and the trajectory they predict will require continued evaluation and policy measures.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Park, Seyeon, and Xiaoli Nan. 2025. “Generative AI and misinformation: a scoping review of the role of generative AI in the generation, detection, mitigation, and impact of misinformation.” ''AI & Society''. https://doi.org/10.1007/s00146-025-02620-3<nowiki/>.'''
</div>
This article constitutes a scoping review of two dozen “recent empirical studies on the role of generative AI in the generation, detection, mitigation, and impact of misinformation.” Park and Nan are interested in the rise of misinformation alongside the development of GenAI technology and how the latter affects and possibly contributes to the former. Of particular interest are “deepfakes,” applications of AI technology that purposely imitate video and audio to fabricate real world individuals. The survey examines relevant articles from the advent of the first GPT models in 2018 to September 19, 2024; authors captured initial studies through keyword searches for terms related to both LLMs and misinformation, then performed full-text reviews. The results of the survey suggest that the role of LLMs in misinformation is conflicted: LLMs themselves are a significant source of misinformation but also show potential as “scalable instruments for detection and correction.” The authors take this as evidence of “the urgent need for clearer guardrails, more consistent performance standards, and interdisciplinary collaboration to shape” GenAI’s responsible deployment. For better or worse, the future of AI’s role in misinformation depends heavily upon scholars’ ability to collaborate and continue this form of research.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Shin, Donghee, Amy Koerber, and Joon Soo Lim. 2024. “Impact of misinformation from generative AI on user information processing: How people understand misinformation from generative AI.” ''New Media & Society'' 27 (7): 4017-4047. https://doi.org/10.1177/14614448241234040<nowiki/>.'''
</div>
Shin, Koerber, and Lim perform a study in which they gauge “how users respond to and process health misinformation in GenAI contexts.” The authors apply the heuristic-systematic (HS) processing framework in their study, distinguishing between intuitive and evaluative modes of processing. They also employ the concept of diagnosticity, or how useful a person deems a piece of information to be. The article begins with a survey of how and why misinformation and hallucinations occur in GenAI applications, some of the reasons users are vulnerable to that information, and the limitations of LLMs. The authors then set forth core research questions, including “What are the cognitive mechanisms of misinformation’s effects on users’ use of GenAI?” and “How do users detect misinformation within GenAI?” The study found that diagnosticity plays an important mediating role in this context: “When a piece of information is generated by algorithms in transparent, fair, and accountable ways, users perceive it with a high level of diagnosticity, which improves their intention to systematically analyze that information.” One implication of this observation is that any bias users bring to GenAI content greatly impacts their analysis of that content. Ultimately, the authors conclude that there are clear limitations in their current study, although it does provide a useful framework for scholars interested in misinformation, GenAI, and user behaviour; they advocate for a continued investigation of the relationship between trust, literacy, and misinformation.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Sidorkin, Alexander. 2025. “Environmental Impact of Generative AI: Carbon and Water Footprint.” ''AI-EDU Arxiv'' 1. https://doi.org/10.36851/ai-edu.vi.5448<nowiki/>.'''
</div>
This report from Sidorkin provides quantitative estimates and comparisons of the CO2 and Water output from GenAI queries to other daily tasks such as taking a shower, browsing the web, and video conferencing. While individual use of GenAI may seem relatively small in terms of water usage and carbon output, Sidorkin cites the findings of Google and Microsoft’s sustainability reports to show that energy demand and water consumption are on the rise: Google’s data centres used 20% more water in 2022 than 2021 while Microsoft’s used 34% more. Both companies attribute this increase to “AI-driven expansion.” Sidorkin argues that it is difficult to measure impact per session because of significant variation in energy sourcing, noting that this also means that advances in energy sourcing “could significantly mitigate AI’s environmental impact.” He makes the claim that improving AI technology will “[slash] resource demands without sacrificing output quality” and the very use of AI can increase productivity even as it “temper[s] environmental tolls through sharper processes,” citing studies that demonstrate the implementation of AI can reduce energy use in buildings and reduce transportation emissions. The article ends on an optimistic note, suggesting that many of the applications of AI, although they may have a heavy environmental cost up front, “could pay off in spades—optimizing resources, curbing waste, and streamlining energy across swathes of the economy.”
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Simon, Judith. 2025. “Generative AI, Quadruple Deception & Trust.” ''Social Epistemology'' 40 (1): 101-115. https://doi.org/10.1080/02691728.2025.2491087<nowiki/>.'''
</div>
Simon proposes that GenAI entails four types of deception, and that this quadruple deception constitutes unique dangers. She attributes the rapid rise of GenAI to its capacity to produce “verbal or visual products of increasingly high quality” alongside its “very high usability and availability through simple interfaces and free access via the internet” (101–102). She emphasizes the impact of this technology’s ability to generate content “with high plausibility but no relation to truth,” arguing the crucial importance of images and video especially in “questions of evidence, for testimony, memory but also for eliciting emotions.” Simon argues that the advent of ChatGPT reframed our collective understanding of AI, returning it to a definition in which we perceive ourselves to be interacting with a conversational artificial agent that is intelligent. This distinct interactional form, Simon states, is significant: “ChatGPT differs [from a search engine] in two philosophically relevant regards… it integrates [different results and sources] into a coherent text…” and “its interface and functioning invites the user to communicate or interact with it by asking questions,” what Simon calls a simulation of communicative acts. The four forms of GenAI deception are: “users may be misled into believing that they interact with a human being”; they may also be misled as to “the capacities of AI,” presuming “intelligence, understanding or even consciousness”; users may be misled by content GenAI produces, especially images, video, and audio; finally, users may be misled “regarding the function of Generative AI,” thinking that the processes behind the technology are, for instance, similar to search engines when, in fact, they differ “in epistemologically highly significant ways.” Simon concludes by outlining implications for implementation, discourse, and governance, with suggestions ranging from avoiding anthropomorphic features in AI that might deceive, countering discourses of true AI agency, and establishing policy and law that mitigates deception through AI technology.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Spatharioti, Sofia Eleni, David Rothschild, Daniel G. Goldstein, and Jake M. Hofman. 2025. “Effects of LLM-based Search on Decision Making: Speed, Accuracy, and Overreliance.” ''Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems''. https://doi.org/10.1145/3706598.3714082<nowiki/>.'''
</div>
Spatharioti et al. begin by asserting the fundamental change of how we engage in search practices online, noting that “by the end of 2023 the two search engines with over 90% of global and US market share offered free LLM-based search.” The authors note the benefits and drawbacks of both traditional web searches and LLM-based searches, acknowledging the value LLM-based searches bring to internet searches in the form of synthesizing information from multiple sources and maintaining search context by retaining search history, while also admitting to risks of hallucinations and overreliance. The article entails a study of how individuals make decisions with traditional and LLM-based searches, particularly in “every day decision making.” Adapting a method from an earlier study on LLM-generated code, Spatharioti et al. employ colour coding to communicate to users the confidence level of LLM-generated outputs in the “domain of online product research.” The study performed two experiments comparing a traditional internet search (using Bing API) to LLM-based search with and without the colour-coded confidence aid. The results of the first experiment saw users complete the task in about half the time when using LLM-based search, usually accompanied by fewer and more complex queries; however, decision quality dropped for complex tasks, with “almost half of the participants in this condition making an incorrect decision for the final task” when using LLM-based search, and the majority of those using LLM-based search over relied on the tool, performing just a single query. The results of the second experiment suggest that colour-coded responses reflecting output confidence scores could be highly effective in mitigating overreliance and misinformation. Key takeaways from the study include that “if we want to encourage people to think critically about the information presented to them, we need to give them cues that help them to do so,” and very simple cues can help accomplish this.
<div style="text-indent: -20px; padding-left: 20px; margin-bottom: -10px">
'''Strubell, Emma, Ananya Ganesh, and Andrew McCallum. 2019. “Energy and Policy Considerations for Deep Learning in NLP.” ''Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics'', 3645-3650. https://doi.org/10.18653/v1/p19-1355. '''
</div>
Strubell, Ganesh, and McCallum assert that the most recent improvements in neural network performance at “fundamental NLP tasks” comes at an increased cost of resources, “with the most computationally-hungry models obtaining the highest scores.” The energy, financial, and environmental costs required to train a new model are considerable; the authors of this article “characterize the dollar cost and carbon emissions that result from training the neural networks at the core of many state-of-the-art NLP models” with a view to heighten awareness among NLP researchers and advocate better practices and policy. By estimating the energy required to train the most popular NLP models and then converting that energy value into an approximated carbon and electricity cost, the authors produce ratings and values for each respective application. This allows for an (imperfect) cost-benefit analysis of such applications (e.g., another similar report estimated that an increase of just 0.1 in the English to German BLEU score for NAS cost “at least $150k in on-demand compute time and non-trivial carbon emissions.” The study’s key takeaways are that “authors should report training time and sensitivity to hyperparameters,” allowing for the direct comparison of different models so long as independent standard measurements of training time and model sensitivity are adapted; “Academic researchers need equitable access to computation resources” as industry’s monopoly stifles creativity and growth; and “Researchers should prioritize computationally efficient hardware and algorithms” to both curb costs and encourage efficient development.
{{Navigation|previous=AI and Open|next=AI and Scholarship}}
{{BookCat}}
2rmfp3c3oruhfcwgb73tb6vt0lmonqj
Taiwan history
0
484088
4655949
4655218
2026-07-31T12:32:46Z
一隻北極熊
3609960
4655949
wikitext
text/x-wiki
{{New book}}[[File:世界最美總統府.jpg|thumb|The front view of the Office of the President,Taiwan|400px]]
<div align="center" style="font-size:2.8em; color:; margin:0.4em">'''History of Taiwan'''</div>
Welcome to the '''Taiwan History Textbook!''' This is a free and open textbook about Taiwanese history. Our goal is to write a high quality textbook about Taiwanese history. Feel free to edit this book if you have knowledge on the history of Taiwan and are fluent in English! This book is originally Chinese and now is translated in to English.
==Contents==
{| border="0" width="75%"
|-
| valign="top" width="48%" |
'''Introduction'''
* [[/About Taiwan History|About Taiwan History]] {{stage short|100%|Jun 29, 2026}}
'''Early Taiwan (-1683)'''<br>
1. [[/Prehistorical and the indigenous culture|Prehistorical and the indigenous culture<br>(-1624)]]{{stage short|100%|Jun 28, 2026}}<br>
2. [[/The Dutch and Spanish rule|The Dutch and Spanish rule<br>(1624-1662)]] {{stage short|100%|Jun 30, 2026}}<br>
3. [[/Kingdom of Tungning|Kingdom of Tungning<br>(1662-1683)]] {{stage short|100%|Jun 30, 2026}}<br>
4. [[/Han Chinese migration to Taiwan|Han Chinese migration to Taiwan]] {{stage short|100%|Jun 28, 2026}}<br>
'''Qing Rule (1683–1895)'''<br>
5. [[/Period of Passive Rule over Taiwan|Period of Passive Rule over Taiwan<br>(1683–mid-19th century)]]{{stage short|100%|Jul 2, 2026}}<br>
6. [[/The Period of Transformation and the Opening of the Port|The Period of Transformation and the Opening of the Port<br>(1858-1874)]]{{stage short|100%|Jul 5, 2026}}<br>
7. [[/The period of active province-building in Taiwan|The period of active province-building in Taiwan<br>(1885-1895)]]{{stage short|75%|Jul 5, 2026}}<br>
'''Japanese Rule (1895-1945)'''<br>
8. [[/Republic of Formosa|Republic of Formosa<br>(1895)]] {{stage short|75%|Jun 29, 2026}}<br>
9. [[/Japanese colonial rule in Taiwan|Japanese colonial rule in Taiwan<br>(1895-1945)]] {{stage short|75%|Jun 29, 2026}}<br>
10. [[/Modernized infrastructure in Taiwan|Modernized infrastructure in Taiwan]] {{stage short|50%|Jun 29, 2026}}<br>
11. [[/The Political Movements of Chiang Wei-shui and Lin Hsien-tang|The Political Movements of Chiang Wei-shui and Lin Hsien-tang<br>(1921-1927)]] {{stage short|50%|Jun 29, 2026}}<br>
12. [[/Taiwan in World War II|Taiwan in World War II<br>(1937-1945)]] {{stage short|50%|Jun 29, 2026}}<br>
''' ROC Rule (1945-)'''<br>
13. [[/Post-war takeover|Post-war takeover<br>(1945-1949)]] {{stage short|50%|Jun 29, 2026}}<br>
14. [[/February 28 incident|February 28 incident<br>(1947)]] {{stage short|0%|Jun 29, 2026}}<br>
15. [[/ROC retreats to Taiwan|ROC retreats to Taiwan<br>(1949)]] {{stage short|0%|Jun 28, 2026}}<br>
16. [[/The land reform|The land reform<br>(1950s)]] {{stage short|0%|Jun 29, 2026}}<br>
17. [[/Taiwan Strait Crisis|Taiwan Strait Crisis<br>(1954-)]] {{stage short|0%|Jun 29,2026}}<br>
18. [[/White Terror|White Terror<br>(1947-1987)]] {{stage short|0%|Jun 29,2026}}<br>
19. [[/Diplomatic challenges |Diplomatic challenges<br>(1970s)]] {{stage short|0%|Jun 29,2026}}<br>
20. [[/Economic Miracle|Economic Miracle<br>(1960s-1980s)]] {{stage short|0%|Jun 29,2026}}<br>
21. [[/Taiwan's democratization|Taiwan's democratization<br>(1987-2000)]] {{stage short|0%|Jun 29,2026}}<br>
22. [[/Modern Taiwan|Modern Taiwan<br>(2000-)]] {{stage short|0%|Jun 29,2026}}<br>
|}
== Appendices==
{| border="0" width="75%"
|-
| valign="top" width="48%" |
# [[/Historical Maps of Taiwan/]] {{stage short|75%|Jun 29, 2026}}
# [[/Historical Flags of Taiwan/]] {{stage short|0%|Jul 21, 2026}}
# [[/Chronology of Major Events in Taiwan's History/]] {{stage short|0%|Jul 21, 2026}}
# [[/Glossary/]] {{stage short|0%|Jul 21, 2026}}
# [[/Print version/]]
# [[/Contributors/]]
|}
==Related Books==
*[[History of China]]
*[[Chinese History]]
*[[Chinese (Mandarin)]]
*[[Hokkien]]
{{BookCat}}
{{Shelves|History}}
{{Shelves|Asian history}}
{{Status|50%}}
{{bookCat}}
e88d3no89556undshiuo5r0w76jejow
User talk:Aranyaresidency
3
485023
4655947
2026-07-31T12:24:43Z
MathXplore
3097823
Notifying author of speedy deletion nomination
4655947
wikitext
text/x-wiki
== I have added a tag to a page you created ==
Hi! I'm MathXplore, and I recently reviewed your page, [[:User:Aranyaresidency/sandbox]]. I have added a tag to the page, because it <strong>may meet the [[Wikibooks:Deletion policy#Speedy deletions|criteria for speedy deletion]].</strong> This means that it can be deleted at any time. The reason I provided was: <blockquote><strong>Out of scope</strong></blockquote> If you believe that your page should not be deleted, please post a message on [[User talk:Aranyaresidency/sandbox|the page's talk page]] explaining why. <strong>If your reasoning is convincing, your page may be saved.</strong> If you have any questions or concerns, please [[User talk:MathXplore|let me know]]. Thank you! <!-- Substituted from User:JJPMaster/CurateThisPage/authorMsg --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 12:24, 31 July 2026 (UTC)
leabnyon016ot2jx3mea4kxj1uhh08z
Linear Algebra and the C Language/a0pk
0
485025
4655956
2026-07-31T17:45:19Z
Xhungab
545789
news
4655956
wikitext
text/x-wiki
__NOTOC__
'''Install and compile this file in your working directory.'''
<syntaxhighlight lang="c">
/* ------------------------------------ */
/* Save as : c00g.c */
/* ------------------------------------ */
#include "v_a.h"
/* ------------------------------------ */
/* ------------------------------------ */
double **X_c_r_c_mR(
double **A,
int rA,
double **B,
int cB
)
{
int rc;
for(rc=RC1; rc<A[R_SIZE][C0]; rc++)
B[rc][cB] = A[rA][rc];
return(B);
}
/* ------------------------------------ */
/* ------------------------------------ */
void fun(int r)
{
double **A = r_mR( i_mR(r,r),99);
double **B = i_mR(r,r);
clrscrn();
printf(" A:");
p_mR(A, S5,P0,C10);
printf(" B: Copy the row R1 of A into the column C3 of B");
c_r_c_mR(A,R1,B,C3);
p_mR(B, S5,P0,C10);
f_mR(A);
f_mR(B);
}
/* ------------------------------------ */
int main(void)
{
time_t t;
srand(time(&t));
/* int i; */
do
{
/* i = rp_I(R3)+R1; */
fun(R4);
} while(stop_w());
return 0;
}
/* ------------------------------------ */
/* ------------------------------------ */
</syntaxhighlight>
'''Copy a row of matrix A into a column of matrix B:'''
'''Screen output example:'''
<syntaxhighlight lang="c">
A:
-93 -57 +35 +36
+57 +72 -9 +77
-98 -75 +97 -23
-42 -14 -94 +3
B: Copy the row R1 of A into the column C3 of B
+0 +0 -93 +0
+0 +0 -57 +0
+0 +0 +35 +0
+0 +0 +36 +0
Press return to continue
Press X return to stop
</syntaxhighlight>
{{BookCat}}
9evsmhokhj3e0zbzmagtfueir0lc7zc
Chess Opening Theory/1. a4/1...e5/2. Ra3/2...Bxa3/3. Nxa3
0
485026
4655959
2026-07-31T19:17:54Z
~2026-40558-29
3615588
Added the page and a description of the move.
4655959
wikitext
text/x-wiki
White recaptures with his Knight.
h7gjtc0dy9dnhrxbvf264vblq70vq49
User talk:Permata55
3
485028
4655977
2026-08-01T07:32:35Z
MathXplore
3097823
Notifying author of speedy deletion nomination
4655977
wikitext
text/x-wiki
== I have added a tag to a page you created ==
Hi! I'm MathXplore, and I recently reviewed your page, [[:Talk:Bagaimana cara hubungi Call Center Permatabank]]. I have added a tag to the page, because it <strong>may meet the [[Wikibooks:Deletion policy#Speedy deletions|criteria for speedy deletion]].</strong> This means that it can be deleted at any time. The reason I provided was: <blockquote><strong>Spam</strong></blockquote> If you believe that your page should not be deleted, please post a message on [[Talk:Bagaimana cara hubungi Call Center Permatabank|the page's talk page]] explaining why. <strong>If your reasoning is convincing, your page may be saved.</strong> If you have any questions or concerns, please [[User talk:MathXplore|let me know]]. Thank you! <!-- Substituted from User:JJPMaster/CurateThisPage/authorMsg --> [[User:MathXplore|MathXplore]] ([[User talk:MathXplore|discuss]] • [[Special:Contributions/MathXplore|contribs]]) 07:32, 1 August 2026 (UTC)
e7pde93w45sji05xqeil6n0k6c0xsbc